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=235012 Mon, 15 Jun 2026 16:39:20 +0300 <p>Система аудита и защиты файловых хранилищ (DCAP) «СёрчИнформ Файловый Аудитор» поддержала новый источник данных. Теперь решение может проводить аудит корпоративного облачного рабочего пространства Google Workspace.</p> <p>Решение сканирует хранилища Google Drive внутри Google Workspace и присваивает документам метки в зависимости от содержимого: «Персональные данные», «Договоры с клиентами», «Файлы с паролями» и т.д. Затем ИБ-специалист может отследить историю их изменений и расследовать инциденты, связанные с нежелательными действиями пользователей. Также «СёрчИнформ Файловый аудитор» может сохранять теневые копии файлов в собственной базе, чтобы уберечь их от нежелательных правок и потери.</p> <p>Аудит корпоративных облачных пространств позволяет находить в них документы, требующие защиты, и проверять, соответствует ли работа сотрудников с ними правилам безопасности. Это облегчает расследования и помогает создать единые политики защиты критичных данных независимо от места их хранения.</p> <p>«Облачные рабочие пространства прочно вошли в практику компаний, особенно если сотрудники распределены по разным городам или странам, — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности „СёрчИнформ“. — Люди загружают туда документы, правят их, пересылают ссылки коллегам. Без контроля в таком хаосе легко потерять критичные данные или случайно открыть к ним доступ посторонним. Поэтому мы выстроили защиту на двух уровнях: „СёрчИнформ Файловый аудитор“ следит за порядком внутри хранилищ — как локальных, так и облачных, в том числе Google Workspace — а система защиты от утечек информации (DLP) „СёрчИнформ КИБ“ контролирует, чтобы файлы с конфиденциальными данными не покидали корпоративный периметр».</p> <p>«СёрчИнформ» продолжает расширять список поддерживаемых облачных бизнес-сервисов. «Файловый Аудитор» контролирует файлы в Jira и Confluence, совместно с КИБ интегрирован с облачными пространствами «Мой Офис», VK Workspace, Яндекс 360, Microsoft 365, в том числе отслеживает перемещение документов из «закрытых» папок в общий доступ.</p> Система аудита и защиты файловых хранилищ (DCAP) «СёрчИнформ Файловый Аудитор» поддержала новый источник данных. Теперь … message https://www.itweek.ru/themes/detail.php?ID=235011 Mon, 15 Jun 2026 16:37:08 +0300 <p>«Тантор Лабс» представила новую версию Платформы Tantor 6.4, решения для централизованного администрирования, мониторинга и эксплуатации PostgreSQL-инфраструктуры. Обновление включает расширенные возможности аналитики и мониторинга, поддержку используемой в машине баз данных Tantor XData Gen3 СУБД Tantor Polar, улучшения ИИ-ассистента и дальнейшее развитие средств администрирования и безопасности.</p> <p>ИИ-ассистент Платформы получил поддержку подключения к внешним OpenAI-совместимым серверам через настройку LLM_BASE_URL, ключа API и модели. Кроме того, улучшен поиск по базе знаний: теперь используются гибридный поиск BM25 + vector search, переписывание пользовательских запросов и reranker-модель для повышения релевантности ответов ассистента.</p> <p>В новой версии Платформы Tantor появилась история изменений конфигурации для одиночных экземпляров и Patroni-кластеров. Платформа фиксирует измененные параметры, старые и новые значения, файл конфигурации, дату изменения, пользователя и источник операции. Для синхронизации с группами конфигураций отображается список затронутых параметров. Историю можно просматривать в виде списка или сгруппированного журнала и при необходимости быстро откатывать изменения. Новый механизм упрощает аудит и анализ причин изменения настроек.</p> <p>Платформа получила сразу несколько улучшений в области мониторинга: тепловые карты бэкапов с визуализацией успешных и проблемных резервных копий за период до одного года, тепловые карты сработавших алертов по дням для анализа инцидентов и повторяющихся проблем, возможность временно отключать уведомления по отдельным триггерам без остановки самого мониторинга, массовое закрытие алертов с единым комментарием и историю потребления памяти SQL-запросами в разделе текущей активности. Новые инструменты позволяют быстрее анализировать состояние инфраструктуры и снижать нагрузку на команды эксплуатации.</p> <p>Одним из ключевых нововведений стала поддержка СУБД Tantor Polar — распределенной СУБД на базе PostgreSQL, построенной на архитектуре разделения вычислений и хранилища (применяется в представленной в апреле 2026 г. машине баз данных Tantor XData Gen3). Платформа теперь отображает топологию Compute-, Proxy- и Storage-узлов Polar-кластера, а также предоставляет данные по активности, ролям и состоянию компонентов через интерфейс и API. Для СУБД Tantor Polar используются отдельные типы метрик, что позволяет полноценно администрировать такие кластеры в едином контуре управления.</p> <p>В Query Profiler добавлен мастер автоконфигурации расширенной аналитики. Платформа автоматически проверяет состояние экземпляра, предлагает необходимые параметры PostgreSQL и инициализирует нужные расширения. Реализован автоматический перерасчет рекомендаций при изменении параметра max_connections. Связанные настройки, включая work_mem и temp_buffers, пересчитываются автоматически с учетом актуального количества соединений.</p> <p>В версии 6.4 расширены возможности интеграции с LDAP и Active Directory. Так, обеспечена поддержка нескольких LDAP/AD-подключений в рамках одного tenant, реализована изоляция пользователей и групп между LDAP-профилями, добавлена поддержка tls skip verify для LDAPS-подключений с внутренними или самоподписанными сертификатами. Появилась интеграция с YCHAT как новым каналом уведомлений: сообщения алертов отправляются в markdown-формате и содержат ключевую информацию о событии.</p> <p>В DB Browser появилась возможность создавать базы данных напрямую из интерфейса платформы. В составе pg_anon реализованы импорт и экспорт словарей анонимизации, а также обновлена версия самого расширения для повышения совместимости с новыми версиями СУБД.</p> <p>В новой версии значительно переработан раздел Overview. Теперь на одной странице доступны карточки с ключевыми метриками: сессии, QPS/TPS, среднее время запроса, CPU, RAM, block I/O, WAL, автовакуум, хранилище, топ-запросы и другие показатели. Виджеты, мини-графики и alert-статусы используют унифицированную стилистику, проблемные зоны подсвечиваются без необходимости переходить в детализированные разделы. Загрузка данных в виджетах выполняется по требованию, что заметно ускоряет отображение страницы и повышает отзывчивость системы. Дополнительно в разделе управления доступом появилась подсветка пересечений и конфликтов правил pg_hba.conf, включая дублирующиеся записи и некорректные диапазоны.</p> <p>«Платформа Tantor — многолетний технологический лидер среди продуктов для управления корпоративными СУБД, и в версии 6.4 мы сделали акцент на улучшениях ИИ-ассистента, развитии эксплуатационной аналитики и повышении удобства администрирования крупных PostgreSQL-инфраструктур. Поддерживается и новая СУБД Tantor Polar, реализующая уникальную для российского рынка возможность горизонтального масштабирования без шардирования и без потери совместимости с PostgreSQL, расширениями и бизнес-приложениями, включая 1С», — отметил генеральный директор Вадим Яценко.</p> «Тантор Лабс» представила новую версию Платформы Tantor 6.4, решения для централизованного администрирования, мониторинга … message https://www.itweek.ru/themes/detail.php?ID=235009 Mon, 15 Jun 2026 16:36:16 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ выделил с помощью системы анализа больших данных iFORA приоритетные технологии, меняющие облик металлургической промышленности.</p> <p>Наиболее высокий индекс значимости в проанализированном массиве источников имеют аддитивные технологии (№ 1 в рейтинге). Из инструмента быстрого прототипирования металлических изделий они постепенно превратились в одно из ключевых направлений развития современной металлургии. С их помощью производят заготовки, близкие к конечному изделию по форме и размерам, а также детали сложной геометрии, недоступной для традиционных методов литья. Широкое применение в аддитивном производстве получило лазерное сплавление в порошковом слое (powder bed fusion) (№ 4), используемое при изготовлении сложных компонентов для аэрокосмической и автомобильной промышленности, биомедицины и других высокотехнологичных сфер.</p> <p>Другим важным вектором технологического развития металлургии является создание новых типов сплавов. Альтернативой традиционным становятся высокоэнтропийные сплавы (№ 5), получаемые путем сочетания нескольких основных элементов в значительных концентрациях. Суперсплавы (№ 6) используются в изделиях и конструкциях, эксплуатируемых в экстремальных условиях. Высокопрочная сталь (№ 7), относящаяся к классу конструкционных сталей с улучшенными характеристиками, обеспечивает оптимальный баланс прочности, свариваемости, пластичности и коррозионной стойкости. Благодаря такому набору характеристик она востребована в разных сферах, включая автомобильную промышленность, производство промышленного оборудования и инфраструктурные проекты. Среди перспективных новых материалов выделяются металлогидриды (№ 9). Их применяют прежде всего в технологиях хранения и транспортировки водорода благодаря способности его удерживать в кристаллической структуре, а также в некоторых металлургических и химико-технологических процессах, например, в очистке металлов.</p> <p>Растущий спрос на более качественные материалы и конкуренция со стороны композитов стимулируют развитие оборудования, позволяющего выпускать продукцию с требуемыми характеристиками при меньших затратах. Электрометаллургия и электродуговые печи (№ 8) стали стандартом выплавки стали, постепенно вытесняя традиционные мартеновские печи. Благодаря внедрению новых типов электродуговых печей можно получать металл высокой чистоты, а также увеличивать степень автоматизации и экологичности производства.</p> <p>По мере усложнения производственных процессов в металлургии и усиления требований к качеству продукции растет потребность в инструментах мониторинга и контроля на разных этапах производства и эксплуатации изделий. Для этих задач все шире используются цифровые двойники (№ 2). В частности, их применяют для анализа деформаций стальных конструкций. С помощью технологий предиктивного обслуживания (№ 10) на основе искусственного интеллекта можно в режиме реального времени анализировать данные промышленных датчиков, оценивать состояние оборудования, в целом оптимизировать техническое обслуживание. Среди методов исследования структуры и состава металлов и сплавов важное место занимает рентгеновская дифракция (№ 3). В последние годы активно развивается энергодисперсионная рентгеновская дифракция и другие модификации метода.</p> <p>Металлургия, одна из старейших отраслей промышленности, проходит через комплексную технологическую трансформацию. Ее проявления затрагивают различные этапы производственного процесса: от разработки новых материалов и сплавов до внедрения высокотехнологичного оборудования и цифровых инструментов мониторинга и управления. В совокупности эти изменения способствуют повышению эффективности производства, обеспечивая контроль качества и сокращение издержек.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ выделил с помощью системы анализа больших … message https://www.itweek.ru/themes/detail.php?ID=235007 Mon, 15 Jun 2026 16:34:52 +0300 <p>ЦСР впервые представил исследование рынка средств защиты «конечных точек» в России, охватывающее перспективы его развития до 2031 года.</p> <p>Заместитель генерального директора ЦСР Екатерина Кваша отметила: «Российский рынок средств защиты конечных точек (Endpoint Security) сохраняет устойчивую положительную динамику и остается одним из крупнейших сегментов рынка средств защиты информации. По итогам 2025 года его объем превысил 40 млрд рублей, увеличившись на 14,9% год к году, что сопоставимо с общемировыми темпами роста данного класса решений. Ожидаем, что до 2031 года российский рынок Endpoint Security вырастет до 78,3 млрд рублей при среднегодовом темпе роста 11,3%».</p> <p>EPP-решения остаются крупнейшей категорией рынка и формируют основную часть выручки производителей, однако наиболее быстро растущим направлением является категория EDR. Ожидается, что его доля составит 26 млрд руб. в 2031 году против 7,3 млрд руб. в 2025 году, т.е. вырастет в 3,5 раза. Рост ЕРР-решений составит 59,5% (32,8 млрд руб. и 52,3 млрд руб. в 2025 и 2031 годах соответственно). Это отражает общий сдвиг спроса от базовой превентивной защиты к более сложным сценариям обнаружения, расследования и реагирования на атаки на рабочих станциях, серверах, удаленных рабочих местах и других конечных узлах.</p> <p>Доля иностранных решений в новых продажах упала с 26% в 2021 году до 4,6% в 2025 году. Пять ведущих игроков теперь полностью российские. В сфере Endpoint Security традиционно лидируют «Лаборатория Касперского» и Dr.Web. Постепенно формируется сильная группа российских компаний, таких как Positive Technologies, BI.ZONE, «Код Безопасности», F6 и другие, которые стремятся занять ведущие позиции, особенно в свете тенденции к платформизации информационной безопасности.</p> <p>Развитие рынка будет поддерживаться несколькими долгосрочными факторами: усложнением угроз, ростом требований к киберустойчивости компаний, развитием MDR- и SOC-as-a-Service-моделей, регуляторным давлением, распространением облачных и гибридных инфраструктур, а также появлением новых рисков, связанных с внедрением искусственного интеллекта и усложнением управления доступами в корпоративной среде. Требования к защите персональных данных, ГИС, КИИ и иных систем фактически предполагают наличие механизмов защиты от вредоносного ПО, контроля запуска программ и устройств, регистрации и анализа событий, выявления атак, реагирования на инциденты и восстановления работоспособности. Дополнительное значение имеет обновление требований ФСТЭК, усиливающее роль мониторинга и реагирования на уровне конечных устройств.</p> ЦСР впервые представил исследование рынка средств защиты «конечных точек» в России, охватывающее перспективы его развития … message https://www.itweek.ru/themes/detail.php?ID=235006 Mon, 15 Jun 2026 16:33:22 +0300 <p>Экспертно-аналитический центр (ЭАЦ) ГК InfoWatch представил отчёт по результатам исследования мировых тенденций в сфере обеспечения безопасности облачной и гибридной инфраструктуры. Как отмечают аналитики, вместе с ростом облачных мощностей растет внимание злоумышленников к ним — каждая четвертая атака в мире приходится именно на облака. При этом человеческий фактор по-прежнему играет важную роль и с точки зрения защиты, и как потенциальная уязвимость.</p> <p>Специалисты ЭАЦ InfoWatch отмечают, что в концепциях защиты сетей предприятий происходят фундаментальные изменения. 82% организаций поддерживают гибридную инфраструктуру, объединяющую локальные центры обработки данных с общедоступными облаками. И хотя эта модель обеспечивает гибкость и масштабируемость, она также разрушает традиционные сетевые границы, создавая сложную сеть соединений, которую трудно отслеживать и защищать, подчеркивают аналитики.</p> <p>«Пользователи и приложения выходят за пределы традиционного сетевого периметра — 53% облачных рабочих нагрузок в мире размещаются на общедоступных облачных платформах, что на 8% больше, чем в прошлом году. Вместе с тем, наблюдается резкое увеличение интенсивности атак на облачные и гибридные инфраструктуры. Злоумышленники хорошо осведомлены об облачных средствах защиты и все чаще используют тактики их обхода, чтобы как можно дольше оставаться незамеченными и извлечь максимум выгоды из атаки», — отметил главный аналитик ЭАЦ InfoWatch Сергей Слепцов.</p> <p>По данным компании SentinelOne, которые аналитики приводят в исследовании, сегодня каждая четвертая кибератака в мире (25%) приходится на облачную инфраструктуру. Число атак растет в среднем на 21% в годовом исчислении, причем Россия по этому показателю опережает зарубежные страны — в нашей стране рост числа атак на облачные и гибридные инфраструктуры в 2025 году составил 30%. Самый большой интерес для злоумышленников представляют российские ИТ и телеком — на компании этой отрасли пришлось 26% атак, на втором месте финансы (19%), замыкают тройку сферы торговли и электронная коммерция (14%). Также в пятерке самых привлекательных целей промышленные предприятия (12%) и медицинские организации (9%).</p> <p>Специалисты ЭАЦ InfoWatch обращают внимание, что злоумышленники хорошо понимают проблемные точки гибридной инфраструктуры, где многие функции не просто не устраняют существующие угрозы, а увеличивают их.</p> <p>«Атакующие не видят разделения между локальным центром обработки данных и облачной средой — они видят единую расширенную сеть. Их стратегии все чаще предполагают „межсредовую интеграцию“, то есть закрепление в менее защищенной облачной среде с последующим переходом к критически важным локальным системам. Обнаружение злоумышленников становится все более проблематичным из-за пробелов в видимости, присущих гибридным инфраструктурам. В том числе поэтому сегодня высокий процент облачных взломов остается незамеченным в течение нескольких месяцев, а время ожидания обнаружения иногда превышает 200 дней», — подчеркнул Сергей Слепцов.</p> <p>Методы защиты тоже совершенствуются — на первый план выходит повсеместное использование принципа нулевого доверия, платформенных решений в области безопасности и межсетевых экранов нового поколения, микросегментация и непрерывный мониторинг сети, активное применение технологий ИИ для защиты и повышенное внимание к безопасности приложений. При этом текущих мер явно недостаточно — по данным Cloud Security Report 2025 от Trend Micro, только 25% компаний в мире доверяют своим инструментам обнаружения сложных угроз.</p> <p>«Одно из главных препятствий на пути внедрения эффективных решений в области безопасности облачных и гибридных инфраструктур — это отсутствие достаточного числа квалифицированных специалистов. Причем как по информационной безопасности в целом, так и в сфере противодействия угрозам в облачных и гибридных средах в частности. Около трех четвертей компаний испытывают нехватку специалистов в области облачной безопасности, эта тенденция прослеживается и в России, и в мире. И это одна из важнейших проблем, которую предстоит решать как в рамках отдельных предприятий, так и на национальном уровне в целом», — заключил Сергей Слепцов.</p> Экспертно-аналитический центр (ЭАЦ) ГК InfoWatch представил отчёт по результатам исследования мировых тенденций … message https://www.itweek.ru/themes/detail.php?ID=235005 Mon, 15 Jun 2026 16:24:27 +0300 <p>PlatformCraft, технологическая платформа ООО «ПК», объявила о запуске холодного объектного хранилища PC-Storage для файлов, к которым редко обращаются, но которые важно хранить долго, надежно и с понятной экономикой. Новый формат дополняет уже доступное в PlatformCraft горячее хранилище и дает компаниям возможность разделить активно используемые данные и архивный контур.</p> <p>Среди базовых сценариев:</p> <ul> <li>хранение архивов, в том числе медиаконтента (исходников, фото- и видеоматериалов, рекламных креативов), которые нужны для юридического хранения, повторного использования или редкого доступа по запросу;</li> <li>размещение резервных копий, закрытых проектных материалов и технических архивов, к которым команда обращается не постоянно, но должна иметь возможность быстро найти их при необходимости.</li> </ul> <p>«Мы добавили в PlatformCraft не просто еще один тариф, а отдельный сценарий работы с файлами. У многих компаний есть большой слой данных, которые нужно хранить долго, но обращаться к ним лишь изредка. Раньше для таких задач в рамках PC-Storage был только горячий контур. С запуском холодного хранилища у клиентов появляется возможность разделить активные и архивные данные и управлять экономикой хранения заметно точнее», — отметил коммерческий директор PlatformCraft, Надир Хамзин.</p> <p>Запуск расширяет линейку сервисов хранения PlatformCraft и позволяет компаниям гибко выбирать модель работы с файлами в зависимости от частоты доступа и характера нагрузки. Подключение холодного хранения будет доступно по подписке с 15 июня, а для новых пользователей предусмотрен пробный период и бесплатный исходящий трафик 30 дней. </p> PlatformCraft, технологическая платформа ООО «ПК», объявила о запуске холодного объектного хранилища PC-Storage для файлов … message https://www.itweek.ru/themes/detail.php?ID=235002 Mon, 15 Jun 2026 10:59:58 +0300 <p><em>Агенты искусственного интеллекта могут строить древовидные структуры данных (B±деревья) и диспетчеры буферов, но, по словам доцента кафедры компьютерных наук Университета Карнеги-Меллона Энди Павло, оптимизатор запросов и автономная база данных остаются их самой сложной нерешенной задачей, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>По мере того, как большие языковые модели (LLM) развиваются от простых чат-ботов до автономных агентов, способных рассуждать, планировать и действовать, они начинают самостоятельно управлять сложными стеками приложений. Однако сейчас эти агенты сталкиваются со своим самым серьезным препятствием — базой данных.</p> <p>«Базы данных представляют собой самую сложную и важную проблему для агентов из-за их бескомпромиссных требований к корректности и производительности», — заявил Энди Павло на недавней конференции «Percona Live 2026» в Калифорнии.</p> <p>В ходе обсуждения взаимодействия ИИ и Open Source-инфраструктуры он утверждал, что, хотя агенты-кодировщики могут легко воспроизводить стандартные структуры данных, база данных остается самой сложной частью любой системы для автоматизации и оптимизации.</p> <p>«Например, если агент генерирует галлюцинации компонента пользовательского интерфейса, страница выглядит немного некорректно; если он генерирует галлюцинации на уровне запроса или изменения конфигурации в производственной базе данных, вся система может исчезнуть», — сказал Павло.</p> <p>Вот это действительно должно вызвать тревогу.</p> <h3>Мультиагентное перетягивание каната</h3> <p>Павло выделил два основных способа влияния ИИ на мир баз данных: агенты-настройщики и агенты-кодировщики. Первые стремятся избавить нас от «черной магии» оптимизации баз данных, автоматически корректируя параметры системы, физические схемы (такие как индексы) и стратегии выполнения запросов. Исторически это требовало от администратора базы данных (DBA) многолетней работы над развитием интуиции, чтобы понять, какая конфигурация обеспечит лучшую задержку или пропускную способность.</p> <p>Проблема в том, что эти специализированные агенты часто работают изолированно, отметил Павло. Агент, регулирующий параметры, может не знать, что делает агент, регулирующий индексы, что приводит к локальным минимумам, где система лучше стандартной, но далека от оптимальной. По его словам, исследования Университета Карнеги-Меллона в области многораундовой и последовательной настройки направлены на решение этой проблемы путем создания координирующей структуры, хотя даже она сталкивается с «проклятием размерности».</p> <p>Университетская группа баз данных является пионером в области разработки концепции самоуправляемой и управляемой машинным обучением оптимизации баз данных. Последовательная и многораундовая настройка являются основными компонентами их проектов по автономным СУБД.</p> <p>Многораундовая и последовательная настройка баз данных ИИ относится к передовым методам машинного обучения и инженерии данных, в которых модели ИИ совершенствуются для многошагового рассуждения, использования инструментов или сложных историй диалогов. Эти структуры гарантируют, что модели ИИ не только реагируют изолированными одношаговыми импульсами, но и сохраняют контекст и логику в сложных взаимодействиях.</p> <p>С триллионами возможных комбинаций конфигураций пространство поиска идеальной базы данных фактически экспоненциально.</p> <h3>Преимущества агентов-кодировщиков и проблема оптимизатора запросов</h3> <p>Что касается разработки, агенты-кодировщики уже доказали свою высокую эффективность в качестве партнеров. Павло отметил, что в Университете Карнеги-Меллона количество строк кода, представленных студентами для проектов по базам данных, резко возросло после того, как было разрешено использовать LLM. «Агенты-кодировщики очень хорошо справляются с созданием практически всех частей базы данных — B±деревьев, хеш-таблиц, диспетчеры буферов — потому что они могут воспроизводить стандартные реализации, найденные в учебниках и Open Source-репозиториях», — сказал он.</p> <p>Однако, по его словам, «двойной черный ромб» (экстремальные сложность и непредстказуемость) по-прежнему остается проблемой оптимизатора запросов. В отличие от базовых структур данных, оптимизаторы запросов редко доступны в виде чистых, модульных Open Source-ссылок. Они часто тесно связаны с системами, для которых были созданы. Кроме того, доказательство семантической корректности правила преобразования, сгенерированного ИИ, — то есть, что оно дает тот же результат, что и исходный запрос, но быстрее, — остается нерешенной проблемой.</p> <h3>Риски включают галлюцинации и проблемы безопасности</h3> <p>Переход к агентному управлению базами данных сопряжен со значительными рисками. Павло и некоторые лидеры отрасли, такие как соучредитель Percona Питер Зайцев, предупреждают, что делегирование оркестровки агентам создает огромные пробелы в стабильности и безопасности. Уже задокументированы случаи, когда агенты, направленные на базу данных, случайно выводят из строя всю систему или допускают утечку конфиденциальной информации, поскольку не понимают нюансов контроля доступа, сказал Зайцев.</p> <p>Кроме того, LLM страдают от так называемой проблемы «ИИ-помоев» («AI slop»), когда они генерируют код, узкоспециализированный для конкретного запроса, но не способный к обобщению. Например, если разработчик использует агента для оптимизации пункта «Извлечь год», агент может создать внутреннюю структуру данных, которая сломается в тот момент, когда разработчик попытается выполнить «Извлечь месяц».</p> <h3>Автоматизация как помощник, а не замена</h3> <p>Несмотря на эти препятствия, Павло выразил оптимизм по поводу модели «агент-оператор». Она предполагает, что агенты будут обрабатывать ситуации типа «в 3 часа ночи всё идёт наперекосяк» — внезапные аномалии производительности и проблемы со стабильностью, — в то время как люди сосредоточатся на проектировании архитектуры более высокого уровня. По словам Павло, использование методов Agent Boosting (практики, направленные на повышение эффективности работы ИИ-агентов в сфере кодирования) для получения обучающих данных из ранее настроенных баз данных позволяет сократить время, необходимое для оптимизации системы, с 12 часов до менее чем 15 минут.</p> <p>В новую эру ИИ цель состоит не только в том, чтобы иметь ИИ, который пишет код, но и в том, чтобы система могла рассуждать о собственной производительности и корректности. По мнению Павло, база данных является основой знаний для любого агента. «Если мы хотим автономных систем, мы должны сначала освоить непрощающее искусство автономных баз данных», — сказал он.</p> Агенты искусственного интеллекта могут строить древовидные структуры данных (B±деревья) и диспетчеры буферов, но … article https://www.itweek.ru/themes/detail.php?ID=235000 Mon, 15 Jun 2026 10:29:40 +0300 <p>У нейросетей много полезных сценариев: от автоматизации простых рутинных задач до участия в нетривиальной творческой работе руководителя. На уровне менеджмента ИИ-модели успешно помогают распределять задачи в команде, оценивать риски и принимать решения. Ограничения у такого подхода тоже есть, и важно понимать, как правильно пользоваться технологиями.</p> <p>Ниже расскажу о наблюдениях и рекомендациях по использованию ИИ-агентов в работе тимлида.</p> <h3>Как подготовить агента к работе с вашим проектом</h3> <p>Чтобы ИИ мог давать правильные подсказки и советы, его нужно ввести в курс дела. Тогда он становится контекстным помощником, который знает проект, документацию и внутренние ограничения, поэтому может оценивать задачи ближе к тому, как это сделал бы человек из команды.</p> <p>В сценарии взаимодействия тимлида и нейросети важен не столько конкретный инструмент, сколько накопленный контекст. Человек постепенно превращает ИИ в рабочее пространство проекта: добавляет документацию, описывает правила, хранит заметки по сотрудникам и ограничениям. В итоге модель может оценивать задания не абстрактно, а с опорой на собранную информацию.</p> <p>Контекст нужно собрать как маленькую рабочую папку проекта: с описанием команды, задач и решений. Тогда при работе не нужно каждый раз пересказывать все заново, а достаточно дать инструкцию: работать с конкретной папкой, использовать определённые файлы как источник правды.</p> <p>Чем больше тимлид складывает в рабочее пространство правил и рабочих решений, тем ближе ответы ИИ к логике конкретной команды. Когда такой контекст собран, агента можно использовать не только для технических задач, но и для управленческой работы.</p> <h3>Работа с командой</h3> <p>Один из главных полезных сценариев — помощь с пониманием возможностей команды и распределением задач. Этот вариант применения ИИ позволяет закрыть довольно много реальных задач.</p> <p><strong>Составление тестовых заданий для новых участников.</strong> Когда в команде появляется вакансия, агент может помочь составить тестовое задание, по которому проще оценить подходящих кандидатов.</p> <p>Нейросеть может составить такое задание с учетом контекста реальной работы команды: документации, REST API, типичных задач. В этом случае тестовое становится менее абстрактным и ближе к тому, с чем человеку действительно предстоит работать.</p> <p>Одна и та же задача может показать разные навыки и подходы. Один человек, даже не зная конкретного языка или технологии, попробует рассуждать логически и понять, что делает код, а другой просто остановится. Для тимлида такая разница важна, потому что показывает не только уровень знаний, но и готовность разбираться, учиться и двигаться дальше.</p> <p>Особенно хорошо такой сценарий может проявиться, когда кто-то из команды переходит на другое место работы. Чаще всего каждый человек выполняет немного разные функции и наверняка обладает определенными уникальными компетенциями. Когда агент знает, кого именно нужно заменить, он может подготовить персонализированное пробное задание и проанализировать, как его выполнили разные кандидаты.</p> <p><strong>Распределение задач.</strong> Для этого нужно, чтобы ИИ-ассистент был в контексте компетенций сотрудников. Это можно сделать через составление рабочих профилей каждого члена команды с указанием слабых и сильных сторон.</p> <p>Когда агент понимает возможности разных людей, он может составить оптимальный план выполнения по каждому проекту с указанием состава задач для каждого и примерными сроками выполнения. Например, при проектировании архитектуры проекта нейросеть может посоветовать ответственных за разные части в зависимости от навыков и предпочтений.</p> <p><strong>Анализ рисков.</strong> Когда ИИ-ассистент знает компетенции сотрудников, он может подсветить потенциальные проблемы еще до начала работы. Например, заметить, что у команды не хватает опыта в конкретной технологии или что сроки выглядят слишком оптимистично.</p> <h3>ИИ как психолог</h3> <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> </ul> <h3>Связки с другими инструментами и источниками данных</h3> <p>В более продвинутом сценарии ИИ-ассистента можно связать с другими источниками данных, например таск-трекером или внутренней базой знаний. Тогда агент сможет не просто рассуждать на основе заранее подготовленных файлов, а видеть более актуальную картину на основе текущей ситуации.</p> <p>Но такие подключения стоит делать осторожно: ИИ может стать бесконтрольным наблюдателем за всей внутренней жизнью компании. Чем шире доступ, тем выше риск утечки, поэтому крайне нежелательно давать доступ машине к любой чувствительной информации.</p> <p>Начинать лучше с передачи агенту нужных материалов вручную: описание проекта, чек-листы, обезличенные профили команды. Если этого недостаточно, можно попробовать подключать отдельные сервисы в режиме чтения и только к тем данным, которые необходимы для конкретного сценария.</p> <h3>Есть ли отличия в разных моделях</h3> <p>В сценарии помощи тимлиду разница между моделями и инструментами не всегда решающая. Главное, чтобы агент умел работать в одном проектном контексте: читать файлы, помнить правила, обращаться к документации. Поэтому схожий сценарий можно собрать почти в любом ИИ-агенте.</p> <p>Лучший способ найти подходящую модель — попробовать несколько инструментов на реальных задачах команды. Одни модели лучше подходят для кода и анализа репозитория, другие хорошо работают с длинными документами и планированием. Поэтому выбирать инструмент стоит под конкретную работу команды и иногда менять его в зависимости от задач.</p> <h3>ИИ в роли помощника тимлида</h3> <p>ИИ в команде можно описать как второго тимлида или заместителя, но с важной оговоркой: финальная ответственность все равно остается за человеком. Агент может предложить распределение задач, подсветить слабые места, помочь с тестовым заданием. Главное ограничение модели — машина не знает людей лучше руководителя и не должна принимать управленческие решения. Задача ИИ в том, чтобы усилить тимлида. Это значит держать больше контекста, задавать дополнительные вопросы и брать на себя часть рутинной подготовки.</p> <p>Сильная сторона агента проявляется, когда он долго работает внутри одного проектного контекста: тогда он лучше понимает состав команды, ограничения, принятые решения. В таком режиме он становится дополнительным собеседником, с которым можно обсудить план, проверить идею и увидеть риски.</p> <p>#IMAGE_235001#</p> У нейросетей много полезных сценариев: от автоматизации простых рутинных задач до участия в нетривиальной … article Владимир Верхотуров, тимлид отдела ”Продуктовый DevRel” компании ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=234997 Thu, 11 Jun 2026 09:44:30 +0300 <p><em>Стивен Эллиот, вице-президент группы </em><em>IDC</em> <em>по инфраструктуре и операциям, облачным операциям и DevOps, рассказывает в корпоративном блоге, как руководители предприятий могут снизить риски и превратить системы искусственного интеллекта в конкурентное преимущество.</em></p> <p>Эра ИИ-помощников подходит к концу.</p> <p>Чат-боты, помощники, составители резюме — полезны, да, но это разминка. Следующим шагом станет агентный ИИ: системы, которые не просто реагируют на запросы, но и планируют, рассуждают и выполняют работу в ваших системах, рабочих процессах и на ваших данных, с участием человека или без него. Сегодня руководители предприятий ставят агентный ИИ в центр своих бизнес-трансформаций, переосмысливая то, как люди взаимодействуют с рабочими процессами на основе ИИ.</p> <blockquote> <p><em>IDC прогнозирует развертывание к 2029 г. 1,15 млрд. активных агентов, выполняющих 217 млрд. действий в день, что в 40 раз больше показателя 2025 г.</em></p> <p>#IMAGE_234998#</p> </blockquote> <h3>Ставки не теоретические</h3> <p>Бизнес-модели, навыки, экономика, управление, соответствие нормативным требованиям и требования к безопасности быстро меняются, создавая масштабные и быстро развивающиеся риски. Цифры из опроса IDC «State of Enterprise Agent Adoption 2025» это подтверждают:</p> <ul> <li> Более 30% предприятий уже внедрили формальные метрики ценности ИИ.</li> <li> До 20% компаний из списка G1000 могут к 2030 г. столкнуться с юридическими и управленческими последствиями из-за плохо управляемых агентов.</li> <li> 60% компаний из списка G2000 к 2028 г. внедрят формальный жизненный цикл разработки агентов.</li> </ul> <p>Генеральные директора, члены совета директоров и акционеры требуют результатов от ИИ уже сейчас. Ожидание затормозит рост доли рынка, возможностей для роста и инноваций. Первые добившиеся успеха расширят свои преимущества, применяя проверенные знания ИИ в новых сценариях использования. В ИИ-экономике непрерывное обучение обеспечивает скорость и кумулятивные результаты.</p> <h3>Это не апгрейд. Это новая операционная модель</h3> <p>Если «второй пилот» составляет электронное письмо, то агент управляет всем рабочим процессом: сбором данных, принятием решений, эскалацией исключений, замыканием цикла. Автономно. Постоянно. В разных системах. С участием человека или без него. Это требует от руководителей перепроектирования процессов с ИИ в центре, не как дополнительной функцией, а как сердцем каждого рабочего процесса.</p> <p>По данным IDC, к 2027 г. предприятиям потребуются архитектуры, поддерживающие синхронное перемещение данных, приложений, рабочих процессов и агентов. Если ваша текущая система не была разработана для этого, время уже идет.</p> <blockquote> <p><em>Агентные системы создают принципиально иной профиль риска, чем инструменты ИИ, которые большинство предприятий развернули в 2023 и 2024 гг.</em></p> </blockquote> <p>Последствия выходят за рамки архитектуры. Копилоты работали под наблюдением человека — каждый результат проверялся, каждое действие подтверждалось. Агенты работают иначе: они инициируют, объединяют решения и действуют в разных системах в режиме реального времени. Неправильно настроенный агент не просто выдает неправильный ответ; он принимает неверное решение, потенциально в больших масштабах, прежде чем кто-либо это заметит. Именно этот переход от результатов, проверенных человеком, к автономным действиям приводит к полному краху систем управления, созданных для эпохи помощников. Управление, безопасность и координация являются критически важными инвестиционными требованиями, а не второстепенным аспектом для эффективных и результативных результатов ИИ. Управление и безопасность должны быть заложены с самого начала, поскольку риски для бизнеса и карьеры слишком высоки, чтобы рассматривать их как второстепенные. Каждый цифровой работник будет управляться как обычный сотрудник.</p> <p>Руководители, которые осознают это различие на раннем этапе, получат структурное преимущество. Они будут не просто быстрее развертывать системы — они создадут операционные возможности, инфраструктуру аудита и системы доверия, необходимые для безопасного масштабирования. Те, кто рассматривает агентный ИИ как продолжение своей стратегии «второго пилота», столкнутся с растущими затратами на исправление ошибок по мере роста портфелей агентов и расширения пробелов в управлении.</p> <p>Конкурентный разрыв, формирующийся сейчас, — не между компаниями, которые используют ИИ, и теми, которые его не используют. Речь идёт о противостоянии организаций, которые научились дисциплинированно внедрять агентов, и тех, кто всё ещё импровизирует. Скорость без структуры — это уязвимость. Структура без скорости — это неактуальность. Руководители, которые ориентируются в обоих аспектах, устанавливают правила игры.</p> <h3>Семь областей. Одна структура</h3> <p>Предлагаемая IDC структура внедрения ИИ выявляет семь областей, где ранние решения оказывают огромное влияние на последующие этапы. Правильно их примите, и вы нарастите темп:</p> <ul> <li> Бизнес-результаты.</li> <li> Проектирование рабочих процессов.</li> <li> Готовность данных.</li> <li> Архитектура среды выполнения.</li> <li> Управление.</li> <li> Операционная модель.</li> <li> Кадры.</li> </ul> <p>В каждой области выделены ключевые моменты, которые руководители должны учитывать для оценки своей готовности к внедрению и управлению ИИ. После проведения самооценки исследование предоставляет подробный анализ критически важных областей трансформации — разработка ПО, выбор партнёров и инфраструктуры ИИ, а также ИТ-операции. Эти рекомендации служат руководством для обсуждения вашего пути внедрения агентного ИИ.</p> <h3>Ключевые выводы для руководителей</h3> <ul> <li> Рассматривайте агентный ИИ как новую операционную модель, а не как обновление вашей стратегии «второго пилота».</li> <li> Управление и безопасность теперь являются конкурентным преимуществом, а не просто мерами по обеспечению соответствия ИТ-требованиям.</li> <li> Семидоменная структура — это ваша шпаргалка: используйте её, чтобы снизить риски развертывания и извлечь выгоду за счет накопления ценности.</li> <li> Те, кто первыми начнут, установят правила игры. Ожидание — это не нейтральная позиция, а стратегическая уступка.</li> </ul> Стивен Эллиот, вице-президент группы IDC по инфраструктуре и операциям, облачным операциям и DevOps, рассказывает … article https://www.itweek.ru/themes/detail.php?ID=234995 Thu, 11 Jun 2026 09:39:00 +0300 <p>В классической ИТ-архитектуре понятие Disaster Recovery (DR), как правило, является синонимом «запасного плана». Это страховка, которая требует огромных капитальных вложений, но остается пассивной до самого момента аварии. Однако в настоящее время в ключевых отраслях — таких как непрерывное производство, финансовый сектор, государственное управление, электронные госуслуги и здравоохранение — предъявляются повышенные требования к отказоустойчивости бизнес-процессов в режиме 24/7/365.</p> <p>Необходимость повышения экономической эффективности заставляет рынок пересматривать этот классический подход. Сегодня мы наблюдаем тектонический сдвиг: переход от ИТ-инфраструктуры «пассивного ожидания» к распределенным зонам доступности (Availability Zones).</p> <h3>Эволюция стратегий: От «холодного» резерва к «живому» облаку</h3> <p>Для сравнения эффективности подходов рассмотрим три основные модели организации инфраструктуры.</p> <p><strong>1.</strong> <strong>Классический DR (Active-Passive). </strong>Это традиционная модель: основной центр обработки данных (ЦОД А) несет 100% полезной нагрузки, а резервный (ЦОД B) находится в режиме ожидания. Данные между ними реплицируются синхронно или асинхронно. Преимущество такого подхода заключается в относительно простой настройке. В то же время схеме присущ серьезный недостаток: оборудование резервного ЦОДа простаивает, но при этом требует постоянного технического обслуживания и лицензирования программного обеспечения. Кроме того, Active-Passive несет в себе скрытые риски — в частности, риск сбоя при переключении на резервную площадку из-за рассинхронизации настроек системного ПО или человеческого фактора.</p> <p><strong>2. Две «площадки» (Active-Active). </strong>Инфраструктура распределена между двумя площадками, каждая из которых активно обрабатывает транзакции. Ключевые преимущества этой модели — 100%-ное использование доступных ресурсов и отсутствие рисков, связанных с ручным или автоматическим переключением нагрузок: при аварии «выживший» ЦОД просто продолжает работу.</p> <p>Однако подход имеет ряд серьезных ограничений. Первая проблема — сугубо технологическая: эффект «расщепления мозга» (split-brain). В случае разрыва связности между ЦОДами возникает риск того, что сервисы на обеих площадках начнут считать себя изолированными мастерами, что неизбежно ведет к консистентным сбоям и повреждению данных. Для предотвращения split-brain требуется третья независимая сторона — арбитр (Quorum Witness). Вторая сложность носит экономический характер: при отказе одного из дата-центров вся нагрузка локализуется на оставшейся площадке. Чтобы минимизировать дефицит производительности и пропускной способности в момент аварии, компании приходится постоянно держать до 50% вычислительных ресурсов в горячем резерве на каждом узле.</p> <p><strong>3. </strong><strong>Три зоны доступности — три «площадки» (Multi-AZ/3-site). </strong>Это «золотой стандарт» современной ИТ-отрасли. Инфраструктура распределяется по трем независимым локациям с минимальными задержками (latency) между ними. Схема обладает рядом неоспоримых преимуществ.</p> <p>Первое — технологическое: наличие кворума по умолчанию. Система всегда имеет математическое «большинство». Если одна из площадок выходит из строя, две оставшиеся подтверждают целостность и непротиворечивость данных, продолжая работу без риска рассинхронизации. Второе преимущество — нулевое окно обслуживания. Вы можете полностью остановить одну из зон для планового обновления программного или аппаратного обеспечения, пока система сохраняет высокую доступность (High Availability) за счет двух оставшихся площадок. Наконец, третье преимущество — экономическое, которое часто упускают из виду. Чтобы минимизировать дефицит производительности при отказе одного плеча, в модели Multi-AZ достаточно иметь всего порядка <nobr>8-10%</nobr> избыточных мощностей на каждой из площадок. Подобный резерв, чаще всего, у компаний уже заложен под пиковые нагрузки или под будущий рост бизнеса.</p> <h3>Почему стоит выбрать концепцию трех зон доступности?</h3> <ol> <li><strong> Математическая гарантия целостности данных. </strong>В бизнес-транзакциях — будь то бухгалтерская проводка или межбанковский перевод — «потерять» или «удвоить» запись абсолютно недопустимо. Трехзонная архитектура на базе алгоритмов распределенного консенсуса (таких как Raft или Paxos) гарантирует, что любая транзакция будет подтверждена как минимум двумя вычислительными узлами, физически расположенными в разных дата-центрах.</li> <li><strong> Соответствие жестким требованиям КИИ и регуляторов. </strong>Для объектов критической информационной инфраструктуры (КИИ) требование устойчивости к региональным и техногенным катастрофам становится обязательным. Развертывание в трех зонах доступности позволяет разнести оборудование на безопасное географическое расстояние, полностью сохраняя непрерывную репликацию данных и гарантируя их постоянную доступность.</li> <li><strong> Экономика масштабируемых систем. </strong>Современные программно-определяемые технологии (SDS/SDN) позволяют строить распределенную отказоустойчивую сеть на базе стандартного серверного оборудования (Commodity Hardware). Отказ от покупки дорогостоящих проприетарных СХД для организации репликации делает трехзонную модель Active-Active сопоставимой по стоимости владения (TCO) с классическим пассивным DR, но при этом в разы более эффективной.</li> </ol> <h3>Резюме</h3> <p>Переход на архитектуру трех зон доступности (Multi-AZ) — это стратегический сдвиг от <em>реактивной</em> модели управления (когда инфраструктуру приходится восстанавливать после аварии) к <em>превентивной</em> (когда система физически не замечает отказа отдельных узлов или площадок). По сути, это полная смена парадигмы управления рисками. Для предприятий и организаций такой подход означает гарантированное сохранение лояльности клиентов, минимизацию рисков простоя критических технологических циклов и прямую экономию на потенциальных штрафах регуляторов. Сегодня, в 2026 году, современное предприятие уже не может позволить себе тратить время на то, чтобы «восстанавливаться» после сбоя. Оно должно этот сбой просто игнорировать, непрерывно продолжая работу в распределенной среде.</p> <p>#IMAGE_234996#</p> В классической ИТ-архитектуре понятие Disaster Recovery (DR), как правило, является синонимом «запасного плана». Это … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=234993 Thu, 11 Jun 2026 09:32:41 +0300 <p>За последние два года искусственный интеллект превратился из экспериментальной технологии в обязательный пункт корпоративной стратегии. Практически каждая крупная компания уже запустила пилот, тестирует генеративный ИИ или заявляет о намерении автоматизировать часть бизнес-процессов. На рынке сформировалось ощущение, что внедрение ИИ — вопрос конкурентоспособности и выживания.</p> <p>Однако за громкими анонсами скрывается менее привлекательная реальность. Большинство проектов так и не доходят до промышленной эксплуатации. По данным ряда международных исследований, подавляющая часть инициатив в области генеративного ИИ не демонстрирует ожидаемого экономического эффекта и остается на уровне экспериментов.</p> <p>Парадокс заключается в том, что проблема редко связана с самими технологиями.</p> <h3>Бизнес пытается автоматизировать не процессы, а надежды</h3> <p>Каждый новый технологический цикл рождает собственный набор иллюзий. В эпоху CRM считалось, что достаточно внедрить систему управления клиентами, чтобы автоматически выросли продажи. Позже аналогичные ожидания связывали с большими данными, RPA и цифровой трансформацией.</p> <p>Сегодня такая же судьба постигла генеративный ИИ.</p> <p>Во многих компаниях решение о внедрении принимается не потому, что существует конкретная бизнес-проблема, а потому что технология находится на пике внимания. В результате организации начинают создавать универсальных ИИ-агентов, не понимая, какую именно задачу те должны решать и каким образом будет измеряться результат.</p> <p>На практике искусственный интеллект часто становится новым интерфейсом для старых неэффективных процессов. Если компания не понимает собственную клиентскую воронку, не знает структуру обращений и не может определить стоимость одного контакта, то ИИ не устранит эти проблемы. Он лишь ускорит их масштабирование.</p> <p>Автоматизация хаоса остается хаосом.</p> <h3>Самый дорогой риск — человеческий</h3> <p>Существует еще одна причина, о которой редко говорят публично.</p> <p>Руководители контакт-центров и клиентских служб оцениваются не по количеству внедренных инноваций, а по отсутствию ошибок. Любое решение, способное создать дополнительный риск для клиентского опыта, воспринимается крайне осторожно.</p> <p>Когда ошибается оператор, организация воспринимает это как рабочий процесс. Когда ошибается ИИ, инцидент воспринимается как системная проблема.</p> <p>В результате компании предъявляют к ИИ более жесткие требования, чем к людям.</p> <p>Представим контакт-центр, где сотрудники допускают ошибки в <nobr>10-15%</nobr> нестандартных обращений. Это считается допустимым уровнем. Но если ИИ-агент ошибается в одном разговоре из ста пятидесяти, обсуждение быстро смещается от экономического эффекта к вопросу о том, можно ли вообще использовать такую технологию.</p> <p>Подобная логика понятна с точки зрения личной ответственности менеджеров, но часто приводит к отказу от проектов, которые уже доказали свою экономическую эффективность.</p> <h3>Почему большинство компаний оценивают не те показатели</h3> <p>Еще одна распространенная ошибка — выбор неправильных метрик.</p> <p>Во многих проектах успех ИИ измеряется временем ответа, количеством обработанных запросов или стоимостью токена. Эти показатели удобны для разработчиков, но практически ничего не говорят бизнесу.</p> <p>Клиентский сервис существует не для того, чтобы быстро отвечать на вопросы. Его задача — решать проблемы клиентов.</p> <p>Поэтому для оценки ИИ-агентов гораздо важнее показатели уровня решенных обращений без участия оператора, точность ответов, количество повторных контактов и стоимость обработки одного запроса.</p> <p>Когда компания начинает смотреть на эти метрики, выясняется, что эффективность ИИ определяется не качеством модели как таковой, а глубиной интеграции в реальные бизнес-процессы.</p> <h3>Где экономика ИИ действительно работает</h3> <p>При этом говорить о том, что генеративный ИИ не окупается, было бы ошибкой.</p> <p>Существуют сегменты, где экономический эффект уже подтверждается практикой. В первую очередь это клиентский сервис крупных B2C-компаний, контакт-центры, страхование, телеком, банковский сектор, девелопмент и подписочные сервисы.</p> <p>Общая черта таких проектов — высокая стоимость человеческого труда и большой объем однотипных коммуникаций.</p> <p>Например, в девелопменте ИИ может работать со «спящей» клиентской базой, которую компания физически не способна регулярно обрабатывать силами операторов. В страховании — автоматизировать первую линию поддержки. В фитнес-индустрии — заниматься пролонгацией абонементов и реактивацией клиентов.</p> <p>Во всех этих сценариях ценность создается не за счет замены людей, а за счет возможности выполнять работу, которая ранее вообще не выполнялась из-за ограниченности ресурсов.</p> <p>Именно поэтому многие успешные проекты связаны не с сокращением штата, а с масштабированием бизнеса без пропорционального роста расходов.</p> <h3>Главный вопрос — не «какая модель», а «какой процесс»</h3> <p>Рынок искусственного интеллекта постепенно проходит классический цикл взросления.</p> <p>Фокус смещается с обсуждения моделей и параметров на вопросы экономики и операционной эффективности. Компании начинают понимать, что ценность создается не в момент запуска пилота, а в момент интеграции технологии в ежедневную работу бизнеса.</p> <p>Для этого необходимы три вещи.</p> <p>Во-первых, внедрение должно начинаться с <em>конкретной бизнес-задачи</em>, а не с желания использовать модную технологию.</p> <p>Во-вторых, <em>проект должен иметь владельца</em> внутри компании, отвечающего за бизнес-результат, а не только за техническую реализацию.</p> <p>В-третьих, ИИ необходимо <em>рассматривать как постоянно развивающуюся систему</em>, а не как программный продукт, который можно внедрить один раз и забыть о нем.</p> <h3>От хайпа к эффективности</h3> <p>Сегодня рынок находится в точке, когда первая волна энтузиазма начинает уступать место прагматизму.</p> <p>Компании больше не спрашивают, нужен ли им искусственный интеллект. Они задают гораздо более важный вопрос: способен ли он приносить деньги.</p> <p>Именно этот вопрос в ближайшие годы разделит рынок на две группы. Одни организации продолжат собирать коллекцию пилотных проектов и презентаций для совета директоров. Другие научатся превращать ИИ в инструмент повышения выручки и снижения издержек.</p> <p>Разница между ними будет определяться не качеством используемой модели и не объемом инвестиций.</p> <p>Разница будет заключаться в способности связать технологию с реальными бизнес-процессами и измеримым экономическим результатом.</p> <p>#IMAGE_234994#</p> За последние два года искусственный интеллект превратился из экспериментальной технологии в обязательный пункт … article Андрей Зименков, фаундер и CEO targetai https://www.itweek.ru/themes/detail.php?ID=234992 Wed, 10 Jun 2026 17:54:53 +0300 <p>Аналитическое агентство Apple Hills Digital совместно с Selectel, Cloud.ru и VK Tech презентуют результаты исследования трендов облачного потребления в корпоративном секторе России. Согласно результатам опроса, 65% компаний увеличили инвестиции в IT в 2026 году, а внедрение искусственного интеллекта стало главным направлением развития.</p> <p>По результатам исследования, 65% компаний сообщили об увеличении инвестиций в IT в 2026 году, из которых 48% увеличили бюджеты в пределах 15%, а 17% компаний — более чем на 15%. При этом 24% компаний сохраняют бюджет на уровне 2025 года и только 12% планируют его сокращать.</p> <p>Среди драйверов роста инвестиций в IT компании отмечают развитие бизнеса (39%), рост объема данных (33%), модернизацию инфраструктуры (32%), а также рост требований в сфере информационной безопасности (30%).</p> <p>Среди направлений инвестиций компании чаще всего отмечают развитие искусственного интеллекта (35%), обеспечение кибербезопасности (34%) и использование облачной IT-инфраструктуры (23%).</p> <p>При этом почти половина российских компаний (46%) использует облачную инфраструктуру для задач искусственного интеллекта, тестирует такие решения или планирует их внедрение в течение ближайшего года. Одновременно с этим 11% компаний предпочитают развертывать ИИ локально на собственных мощностях. Еще 7% используют искусственный интеллект по модели SaaS (Software-as-a-Service). </p> <p>Главными причинами использования облака для задач искусственного интеллекта являются доступ к готовым ИИ-моделям и сервисам (36%) и возможность ускорить запуск экспериментов (32%). Также компании отмечают преимущества облачной инфраструктуры в обеспечении безопасности ИИ-проектов (27%), масштабировании решений (23%) и снижении стоимости разработки (20%).</p> <p>Александр Тугов, директор AI-вертикали Selectel, отметил: «Сегодня для большинства компаний развертывать ИИ в облачной инфраструктуре выгоднее, чем строить собственный контур. Рынок развивается настолько быстро, что GPU морально устаревают за два-три года, а потребности бизнеса постоянно меняются. Облако позволяет быстро проверить гипотезу, масштабировать успешные кейсы и гибко управлять ресурсами без крупных капитальных затрат и риска ошибиться с выбором оборудования.</p> <p>При этом локальная инфраструктура по-прежнему остается востребованной в отраслях с повышенными требованиями к безопасности и регуляторике. Для таких сценариев Selectel предоставляет выделенные серверы с GPU, включая варианты размещения оборудования на площадке заказчика, что позволяет внедрять искусственный интеллект без выноса данных за пределы собственного контура».</p> Аналитическое агентство Apple Hills Digital совместно с Selectel, Cloud.ru и VK Tech презентуют результаты … message https://www.itweek.ru/themes/detail.php?ID=234991 Wed, 10 Jun 2026 17:53:47 +0300 <p>Эксперты компании «Информзащита» зафиксировали рост обращений, связанных с проверкой npm-зависимостей и расследованием подозрительной активности в цепочках поставки ПО. В январе-мае 2026 года их количество выросло на 42% по сравнению с аналогичным периодом 2025 года. Изменился и характер запросов: компании стали чаще обращаться не после подтвержденной компрометации, а на этапе раннего анализа риска, когда вредоносная версия уже появилась в экосистеме, но еще не успела попасть в продуктивный контур. По данным анализа «Информзащиты», доля таких превентивных запросов выросла с 31% до 54%, а число случаев, где потенциально опасный пакет удавалось изолировать до использования в production-сборке, увеличилось на 38%.</p> <p>Такая динамика показывает не только рост активности злоумышленников, но и более зрелое отношение бизнеса к open source-рискам. npm остается одной из самых удобных для атакующих экосистем из-за большого числа транзитивных зависимостей, автоматического выполнения lifecycle-скриптов и высокой скорости распространения новых версий. Команда разработки может не устанавливать вредоносный пакет напрямую: он попадает в проект через служебную библиотеку, клиент API, компонент сборки или optional-зависимость. Внешне процесс выглядит штатно, поэтому классические проверки на уровне периметра часто не дают нужного контекста. Защита начинает работать эффективнее там, где контроль зависимостей встроен в пайплайн, а не проводится вручную уже после инцидента.</p> <p>В 2026 году атаки на npm все чаще нацелены не на конечное приложение, а на среду разработки. Вредоносные пакеты ищут npm-токены, GitHub PAT, SSH-ключи, переменные окружения, cloud credentials, секреты GitHub Actions, GitLab CI, CircleCI, Vercel, Netlify и других платформ. По оценке «Информзащиты», в 61% проанализированных случаев подозрительный пакет пытался получить доступ сразу к нескольким классам секретов. В 34% случаев код содержал признаки самораспространения через публикацию новых версий пакетов от имени скомпрометированного мейнтейнера. В 22% случаев вредоносная активность маскировалась под телеметрию, загрузку runtime-компонентов или стандартные операции сборочного пайплайна. При наличии мониторинга поведения в CI/CD такие сценарии можно выявлять раньше, чем они превращаются в масштабную компрометацию.</p> <p>Ключевая причина роста таких атак — разрыв между скоростью разработки и глубиной контроля supply chain. Во многих компаниях SBOM формируется ближе к релизу, хотя вредоносный пакет может выполниться еще в тестовой или сборочной среде. Lock-файлы используются не во всех проектах, а npm install по-прежнему встречается в пайплайнах там, где должен применяться npm ci. CI/CD-раннеры нередко имеют избыточный доступ к секретам, а права на сборку, публикацию и работу с облаками объединены в одном контуре. Отдельный риск связан с доверием к формальным признакам легитимности. Подпись пакета и корректный provenance помогают подтвердить происхождение артефакта, но не отвечают на главный вопрос: что делает код при установке, сборке и запуске в CI/CD. Поэтому эти механизмы должны дополнять анализ lifecycle-скриптов, изменений в зависимостях, сетевой активности и доступа к секретам, а не заменять его. Компании, которые совмещают анализ пакетов, контроль секретов и мониторинг поведения сборочной инфраструктуры, сокращают окно риска без остановки разработки.</p> <p>В отраслевом разрезе наиболее заметная доля обращений пришлась на технологические компании и разработчиков SaaS-решений — 26%. Финансовый сектор занял 19%, в основном из-за развитых внутренних frontend-платформ, SDK и автоматизированных пайплайнов поставки. На ритейл и e-commerce пришлось 16% случаев: риск повышают распределенные веб-команды, подрядчики и большое число клиентских интеграций. Промышленность и энергетика составили 14%, где npm-зависимости чаще встречаются во внутренних порталах, системах мониторинга и сервисах аналитики. Телеком занял 11%, логистика и транспорт — 8%, медиа и образовательные платформы — 6%. Такая картина показывает, что npm-риски перестали быть вопросом только для производителей программного обеспечения. Под удар попадает любой бизнес, где разработка связана с облаками, CI/CD, внешними пакетами и автоматизированной доставкой кода.</p> <p>«Главная сложность npm-атак в том, что они редко выглядят как классическое заражение. Разработчик запускает обычную установку зависимости, CI получает привычный набор команд, пакет может быть подписан и опубликован из легитимного аккаунта. Проблема становится заметной позже, когда токен уже использован для доступа к репозиторию или публикации следующей вредоносной версии. Во второй половине 2026 года мы ожидаем больше комбинированных сценариев: компрометацию мейнтейнеров, отравление CI/CD-кеша и злоупотребление доверенными publisher-механизмами. Если компания проверяет только имя пакета и наличие подписи, она увидит атаку слишком поздно», — прокомментировал Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащита». </p> <p>Для снижения риска компаниям необходимо выстроить управляемую модель доверия к npm-зависимостям и сборочной инфраструктуре. Новые версии пакетов стоит помещать в карантин на <nobr>24-72</nobr> часа и пропускать в продуктивные сборки только после проверки изменений в package.json, lifecycle-скриптов, резких скачков размера файлов и появления новых внешних соединений. В CI/CD важно ограничить доступ раннеров к секретам по принципу минимальных привилегий, разделить права на сборку и публикацию, использовать lock-файлы и npm ci вместо npm install, отключать install-скрипты там, где это допустимо, контролировать egress-трафик и направлять загрузку зависимостей через приватный registry или прокси с политиками блокировки. После любого подозрения на компрометацию зависимости требуется ротация npm-токенов, GitHub PAT, SSH-ключей и облачных секретов. Такой подход не останавливает разработку, а переводит open source-компоненты в контролируемый процесс, где риск можно обнаружить до влияния на бизнес-системы.</p> Эксперты компании «Информзащита» зафиксировали рост обращений, связанных с проверкой npm-зависимостей и расследованием … message https://www.itweek.ru/themes/detail.php?ID=234989 Wed, 10 Jun 2026 15:04:55 +0300 <p>Подписав соглашение о стратегическом партнерстве, «Группа Астра» и компания «Аладдин» объявили о подготовке к выпуску на рынок первого совместно разработанного продукта — Astra Server Core.</p> <p>Ключевые свойства нового продукта, как пояснили на его презентации директор серверного ПО «Группы Астра» Алексей Фоменко и генеральный директор компании «Аладдин» Сергей Груздев, заключаются в возможности закрыть актуальную потребность заказчиков в доверенной самодостаточной корпоративной инфраструктурной ИТ-платформе, способной заместить комплекс решений ОС Windows + AD + SCCM + CA, который до сих пор доминирует во многих российских компаниях.</p> <p>Как полагают разработчики Astra Server Core, новый продукт позволяет сформировать новый стандарт построения зрелой, доверенной, безопасной и надежной корпоративной ИТ-инфраструктуры. Продукт включает в себя серверную ОС Astra Linux Server, службу каталога корпоративного класса ALD Pro, менеджер конфигураций Astra Configuration Manager и корпоративный центр сертификации Aladdin Enterprise CA. Как заявляют «Аладдин» и «Группа Астра», все компоненты соответствуют актуальной нормативной баз; в первую очередь они обращают внимание на соответствие <nobr>117-му</nobr> приказу ФСТЭК России.</p> <p>Создатели Astra Server Core объявили, что все компоненты решения доступны для пользователей прямо «из коробки», что избавляет их от необходимости самостоятельно собирать ядро своих корпоративных ИТ-инфраструктур из решений разных вендоров и тестировать их на совместимость. Они также обещают, что техподдержка пользователей Astra Server Core будет реализована партнерами в режиме единого окна.</p> <p>Рассказывая о нынешних возможностях Astra Server Core и планах развития партнерства, Сергей Груздев пояснил, что сразу после выхода на рынок продукт будет на базе перечисленных выше компонентов обеспечивать выдачу машинных и программных сертификатов для сервисов. В дальнейшем будет создана платформа, ориентированная в своем функциональном наполнении в большей мере на клиентскую часть инфраструктуры: на доверенную загрузку, прозрачное шифрование данных, двухфакторную и строгую аутентификации... Фактически, по словам Сергея Груздева, партнеры намерены в недалеком будущем реализовать «из коробки» соответствие регуляторным требованиям.</p> Подписав соглашение о стратегическом партнерстве, «Группа Астра» и компания «Аладдин» объявили о подготовке … message Валерий Васильев https://www.itweek.ru/themes/detail.php?ID=234985 Wed, 10 Jun 2026 13:14:25 +0300 <p>Рассмотрим, почему поддержка корпоративных систем больше не может ограничиваться «закрытием заявок» и как выбрать подрядчика, который отвечает за стабильность бизнес-процессов, а не только за отдельные ИТ-компоненты.</p> <p>Российский бизнес все чаще сталкивается с кибератаками, сбоями и дефицитом ИТ-компетенций. Для компаний, в которых ERP-система, СУБД, серверы и интеграции поддерживают закупки, производство, финансы и отчетность, любой cбой превращается в операционные и финансовые потери.</p> <p>Высоки риски для предприятий из ключевых отраслей: уязвимость в приложении, СУБД, операционной системе или сетевой инфраструктуре может привести к потере контроля над бизнес-приложениями, уничтожению данных, остановке процессов и прямым убыткам. Поддержка ИТ-ландшафта — один из элементов устойчивости бизнеса.</p> <h3>Безопасность систем — следствие зрелости бизнеса</h3> <p>Подход к защите данных напрямую зависит от зрелости ИТ-контура и управленческой зрелости бизнеса. Рост последней делает более понятными ИТ-стратегию, критичные процессы, целевую архитектуру, зоны ответственности, требования к доступности и восстановлению систем.</p> <p>Если ИТ-стратегии нет, а информационная безопасность финансируется по остаточному принципу, выбор между собственной командой и внешним подрядчиком не решит проблему. Риск потери данных и нарушения целостности систем снижается, когда есть регламенты, контроль изменений, резервное копирование, понятные целевые показатели восстановления (RTO/RPO) и регулярная проверка готовности к инцидентам.</p> <p>Меры безопасности часто внедряются уже после сбоя или атаки. Компаниям, в которых ИТ не является основным бизнесом, сложно постоянно держать внутри всю экспертизу: отслеживать новые угрозы, проверять гипотезы защиты, обновлять регламенты и обучать команду. В этой ситуации внешнее сопровождение может дать эффект, если оно встроено в управление рисками.</p> <h3>Что должен обеспечивать внешний поставщик?</h3> <p>Ценность внешнего подрядчика поддержки заключается в том, чтобы заранее выстроить процессы, которые снижают вероятность критичных событий и ускоряют восстановление.</p> <p>Первая задача провайдера — собрать компетенции и ресурсы, которые обеспечивают непрерывность работы всего ИТ-ландшафта: от бизнес-приложений до инфраструктуры, на которой они работают.</p> <p>Для этого аутсорсер отслеживает технологические тренды и реальные инциденты, обучает специалистов, формирует регламенты, выстраивает процессы поддержки, развивает мониторинг, базы знаний, инструменты управления изменениями и техническую инфраструктуру сопровождения. Для многих компаний реального сектора поддерживать такой набор компетенций внутри экономически сложно.</p> <p>Клиент в этой модели получает людей «на линию», накопленные практики, экспертизу и готовые сценарии решения типовых проблем. По нашему опыту, в большинстве случаев проблему можно решать по уже апробированному сценарию, а уровень сервиса должен быть закреплен соглашением об уровне обслуживания (SLA) и финансовой ответственностью поставщика.</p> <h3>Комплексный подход как залог эффективности поддержки</h3> <p>Оптимальная модель — целостное сопровождение, когда один провайдер отвечает и за бизнес-приложения, и за платформенные компоненты: серверы, операционные системы, СУБД, интеграции, мониторинг и резервное копирование. Защита исключительно прикладного слоя недостаточна: сбой инфраструктуры неизбежно приведет к остановке бизнес-системы.</p> <p>На реальных инцидентах видно, что приложение, база данных, серверная инфраструктура и процессы эксплуатации тесно связаны. Поэтому устойчивость ИТ-ландшафта лучше обеспечивать через единый подход, единое окно взаимодействия и понятную модель ответственности. Это снижает риск «мертвых зон» на стыке ERP-системы и инфраструктурных компонентов.</p> <p>С этой целью сопровождение целесообразно строить вокруг трех направлений: техническое администрирование; функциональная поддержка и развитие; поддержка пользователей и сервисов данных.</p> <p>Техническое администрирование охватывает приложения ERP-системы, СУБД, операционную среду и инфраструктурные компоненты. Его цель — стабильность, производительность, информационная безопасность и управляемая стоимость владения.</p> <p>Ключевые принципы технического администрирования:</p> <ul> <li> актуализируемая база знаний об угрозах, инцидентах и методах их предотвращения;</li> <li> проактивный мониторинг доступности, производительности и потенциальных сбоев;</li> <li> документирование работ и контроль жизненного цикла изменений;</li> <li> перенос в продуктив только согласованных и протестированных изменений;</li> <li> разграничение прав доступа и регулярный пересмотр ролей;</li> <li> экспертный совет для диагностики повторяющихся и критичных проблем;</li> <li> подключение специалистов по любому элементу технологического стека — от ERP-системы до СУБД и инфраструктуры;</li> <li> отсутствие мертвых зон на стыке технологий и единая ответственность за результат;</li> <li> закрепление уровня сервиса в SLA, включая приоритеты, время реакции, эскалацию и отчетность;</li> <li> регулярная проверка резервного копирования и сценариев восстановления для критичных систем.</li> </ul> <p>По нашим данным, применение этих принципов в среднем по проектам позволяет сократить количество нештатных ситуаций до 70%, время их устранения — до 60%, а затраты на обслуживание — до 30%. Эти показатели зависят от исходной зрелости ИТ-контура и состава обслуживаемых систем.</p> <p>Практический набор услуг включает настройку, администрирование и восстановление работоспособности поддерживаемого ПО, предоставление новых версий, консультации по документации, настройку общесистемного ПО и СУБД под требования бизнес-приложений. Сопровождение должны вести специалисты с подтвержденной экспертизой по технологическим вопросам, а при необходимости — профильные инженеры по смежным компонентам.</p> <p>SLA важно строить как управленческий инструмент. Критичные процессы и приложения должны иметь более высокий приоритет, понятные сроки реакции и восстановления, а менее критичные — экономически обоснованный уровень сервиса. Такой подход помогает одновременно защищать бизнес и контролировать бюджет.</p> <p>Функциональная поддержка и развитие отвечают за то, чтобы корпоративная система соответствовала бизнес-процессам. Подрядчик должен контролировать и документировать этапы разработки, целостно проектировать изменения, проводить нагрузочное тестирование и опираться на рекомендации производителей ПО.</p> <p>Команда поддержки должна сочетать техническую экспертизу и понимание предметной области. Консультанты выступают бизнес-аналитиками: помогают уточнять требования, оценивать влияние изменений и предлагать решения, которые улучшают работу пользователей.</p> <p>По нашему опыту, такой подход может повышать производительность пользователей до 30%, сокращать время реализации изменений до 80% и снижать затраты на обслуживание ИТ-систем и компонентов до 60%. Отдельный эффект возникает за счет того, что компании не нужно держать в резерве полный набор редких и дорогостоящих компетенций.</p> <p>Поддержка пользователей и сервисов данных обеспечивает ежедневную работу сотрудников с корпоративными системами, качеством информации, отчетностью и смежными сервисами. Важны понятное единое окно, гарантированное время реакции, контроль жизненного цикла обращений, быстрая эскалация и фокус на решении бизнес-проблемы пользователя.</p> <p>С точки зрения бюджета для ряда компаний эффективна модель фиксированной цены — особенно когда периметр работ, уровень обслуживания (SLA), метрики качества и порядок изменения объема услуг описаны заранее. В такой схеме провайдер заинтересован в снижении количества инцидентов, длительности простоев и повторяемости типовых проблем.</p> <p>Еще один критерий зрелого подрядчика — способность масштабировать и перенастраивать сервис под изменения бизнеса. Провайдер берет на себя подбор, обучение, замену и перераспределение специалистов, а клиент получает более гибкую модель управления ресурсами без необходимости постоянно держать избыточный штат внутри.</p> <p>По нашему опыту, при внедрении такой модели удовлетворенность пользователей может повыситься до 30%, время ответа на обращения — снизиться до 50%, а количество обращений — сократиться до 30%. Как и в случае с другими метриками, эффект зависит от стартового состояния процессов и качества внедрения.</p> <h3>Чек-лист выбора подрядчика</h3> <p>Перед передачей сопровождения на аутсорсинг стоит проверить не только стоимость услуг, но и управляемость будущего сервиса. Минимальный чек-лист может выглядеть так:</p> <ul> <li> Есть ли у подрядчика единая ответственность за приложения, СУБД, инфраструктуру и интеграции?</li> <li> Кто является единым окном и сервис-менеджером со стороны поставщика?</li> <li> Как в SLA описаны приоритеты, время реакции, время восстановления, эскалация и отчетность?</li> <li> Определены ли целевые показатели восстановления (RTO/RPO) для критичных систем и проверяются ли эти сценарии?</li> <li> Как устроены мониторинг, управление изменениями, разграничение доступов и база знаний?</li> <li> Какие метрики поставщик регулярно показывает бизнесу: количество инцидентов, среднее время восстановления (MTTR), повторяемость проблем, удовлетворенность пользователей, динамика затрат?</li> <li> Есть ли у команды подтвержденная экспертиза по ERP-системе и смежным технологическим компонентам?</li> </ul> <h3>Практические шаги к внешнему сопровождению</h3> <p>Переход на поддержку силами внешнего подрядчика редко бывает одномоментным. Бывают ситуации, когда ИТ-ландшафт нужно взять в сопровождение немедленно — например, во время активного инцидента, но в штатном сценарии поспешность повышает риски.</p> <p>Переход занимает несколько недель или месяцев: срок зависит от масштаба компании, количества систем, уровня документации, интеграций, доступности данных и готовности внутренней команды передать знания. Важно дать подрядчику возможность разобраться в процессах и архитектуре.</p> <p>Базовая стратегия — поэтапная передача ИТ-решений на сопровождение. Сначала провайдер изучает процессы, системы, интеграции и инфраструктурные компоненты, затем встраивает сервис в процессы клиента и готовит дорожную карту. В ней должны быть описаны целевая модель поддержки, зоны ответственности, необходимые изменения, требования к ПО и оборудованию, а также план стабилизации.</p> <p>Затем начинается этап стабилизации: команда усиливается экспертами, накапливается база знаний, уточняются регламенты, выявляются критичные проблемы и устраняются повторяющиеся причины сбоев. На этапе штатного сервиса компания получает поддержку с согласованным объемом и качеством, регулярную отчетность, оценку удовлетворенности и управление отклонениями.</p> <p>Такой подход особенно важен при восстановлении после кибератак и крупных сбоев. Действия компании только собственными силами и без заранее отработанных регламентов могут занимать от недели до месяца. В это время часть процессов выполняется вручную, растет риск ошибок и задержек. При внешнем сопровождении с проработанными регламентами, резервным копированием и проверенными сценариями восстановления потери можно существенно снизить. Например, допустимый объем потери данных может измеряться минутами, а не неделями.</p> <p>Квалифицированный подрядчик работает на долгосрочную перспективу: планирует обновления, контролирует работоспособность приложений и инфраструктуры, поддерживает средства защиты, развивает базу знаний и регулярно пересматривает SLA под задачи бизнеса. Главная «банальная истина» проста: устойчивость ERP и корпоративной инфраструктуры появляется не в момент аварии, а задолго до нее — через системное сопровождение, понятную ответственность и проверенные регламенты.</p> <p>#IMAGE_234988#</p> Рассмотрим, почему поддержка корпоративных систем больше не может ограничиваться «закрытием заявок» и как выбрать … article Максим Гришин, начальник отдела “Лаборатория сервисов” IBS https://www.itweek.ru/themes/detail.php?ID=234984 Wed, 10 Jun 2026 11:03:10 +0300 <p>Компания «Спикател» совместно с партнерами провела исследование защищенности API в российском финансовом секторе. Данные получены на основе мониторинга, опросов руководителей ИБ-подразделений и анализа инцидентов. Опрос охватывал период последних 12 месяцев — с июня 2025 по май 2026 включительно.</p> <p>По данным опроса, 98% финансовых организаций зафиксировали как минимум один инцидент, связанный с безопасностью API, за последние 12 месяцев. Это соответствует международной статистике — по данным Akamai, аналогичный показатель в мире составляет 96%. Под инцидентами безопасности мы понимаем случаи, когда злоумышленники использовали API (программный интерфейс) для атаки на инфраструктуру финансовой организации: веб-атаки, нацеленные на конечные точки API, проникновение программ-вымогателей через API эксплуатация «неинвентаризованных» API, «тихие» атаки на бизнес-логику, атаки через незащищенные тестовые контуры мобильных банков.</p> <p>«Глобальная цифра в 96% выглядит устрашающе, но российская специфика диктует почти стопроцентную гарантию инцидента. Ключевой фактор — скорость. В стремлении быстрее вывести на рынок отечественные аналоги ушедших вендоров, безопасность API на этапе разработки зачастую приносится в жертву функциональности», — прокомментировал ведущий аналитик центра мониторинга киберугроз «Спикатела» Алексей Козлов. </p> <p>На финансовый сектор пришлось 85% всех веб-атак на российские организации и 90% атак, направленных на конечные точки API. Вероятно, это связано с тем, что в РФ ускоренными темпами формируется экосистема открытых API (в рамках инициатив ЦБ РФ по Open Banking), и злоумышленники активно изучают уязвимости новых, зачастую «сырых», микросервисных архитектур.</p> <p>За последние 12 месяцев 85% опрошенных финансовых организаций столкнулись с атаками программ-вымогателей и попытками шифрования данных. Также зафиксирован рост векторов проникновения через API мобильных приложений и партнерских интеграций.</p> <p>Злоумышленники все чаще используют API как точку входа в инфраструктуру, минуя классические периметры защиты. Фиксировались случаи, когда вымогатели проникали через незащищенные тестовые контуры мобильных банков.</p> <p>При этом уровень внедрения передовых средств защиты (WAF нового поколения, API Security Gateways) в российском финтехе оценивается лишь в <nobr>35–40%.</nobr> Многие организации до сих пор полагаются на устаревшие модели безопасности периметра, не справляясь с «тихими» атаками логического уровня.</p> <p>«Спикател» прогнозирует рост числа инцидентов, связанных с эксплуатацией неинвентаризованных API, на 40% к концу 2026 года. Факторы роста: расширение числа интеграций по модели Open Banking и увеличение количества публикуемых API.</p> Компания «Спикател» совместно с партнерами провела исследование защищенности API в российском финансовом секторе … message https://www.itweek.ru/themes/detail.php?ID=234983 Wed, 10 Jun 2026 09:23:58 +0300 <p><em><nobr>2026-й</nobr> уже близок к середине, но впереди нас ждет еще много интересного — и, к счастью, не все это — чепуха про искусственный интеллект для сетей. Что точно не будет чепухой, так это продолжающиеся рост и внедрение сетевых платформ, пишет в корпоративном блоге Андре Кинднесс, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Эта идея может показаться запоздалой по сравнению с рынком безопасности (и да, меня это раздражает как сетевого аналитика), но производители решений в области безопасности — особенно в сфере SASE — уже показали, на что способны платформы. Такие вендоры, как Netskope и Zscaler, выпустили платформы, которые управляют и контролируют устройства безопасности и сетевое оборудование, ПО и сервисы через единый облачный интерфейс. И это только в области безопасности.</p> <p>Длинный список других продуктов для управления технологиями и не только уже совершил этот переход. Теперь и сетевые вендоры наконец-то начинают конкурировать и на уровне платформ. Но этот важнейший сдвиг трудно заметить на фоне маркетинговой шумихи вокруг ИИ, затмевающей этот важнейший момент.</p> <p>Надо признать, что развитие сетей идёт медленно, и переименование существующих вещей под эгидой ИИ — слишком распространённое явление на каждом рынке прямо сейчас. Если вы думаете: «Разве мы этого раньше не слышали? Разве это не просто приукрашивание действительности? Будут ли вообще команды мотивированы использовать эти платформы?», то это может так ощущаться — но на этот раз есть важное отличие.</p> <h3>Что осталось прежним</h3> <p>Клиенты по-прежнему хотят единую систему управления и мониторинга, которая позволит их сетям перейти к автономной работе. Идея платформы покажется знакомой любому, кто слышал рекламную кампанию «единой консоли» в течение последних десяти с лишним лет. Однако тогда это был в основном слоган. Немногие клиенты видели реальную ценность, потому что эти инструменты были сосредоточены почти исключительно на задачах «нулевого дня», с ограниченной общей функциональностью в рамках одного и того же ПО управления.</p> <p>Проводные инструменты управления были сложны в использовании и не обладали широкими возможностями беспроводной связи. Проводное и беспроводное управление на локальных серверах часто в сумме давали очень мало пользы. В действительности менее 10% сетевых команд приобретали инструменты управления сетью (не считая контроля доступа к сети) у того же поставщика, что и для коммутации. Беспроводные сети были исключением — выбора было немного — но даже в этом случае лишь небольшая часть организаций фактически использовала эти инструменты для управления проводной частью сети. Мониторинг и аналитика были в лучшем случае элементарными.</p> <h3>Что нового</h3> <p>Большие перемены произошли с появлением управления на основе SaaS. Aerohive (теперь часть Extreme Networks) и Meraki (теперь часть Cisco) доказали, что управление сетью может быть проще и эффективнее при предоставлении из облака. Это положило начало более широкому переходу к облачному управлению. Затем Mist снова подняла планку, показав, как богатая телеметрия в сочетании с большой вычислительной платформой может обеспечить значимые операции в Day 1 и Day 2.</p> <p>Объединив видимость LAN, WLAN и WAN, системы управления сетью начали превращаться в нечто большее: настоящие единые панели управления, теперь известные как платформы. Cisco, Extreme и Juniper осознали, что объединение данных из всей сети может вывести управление за пределы отдельных доменов (кампус, филиал, удаленный офис) на уровень всей корпоративной сети. Именно здесь ИИ начинает играть реальную роль. При наличии достаточного количества данных и контекста, платформы наконец могут обеспечить реальную операционную ценность. Как рассказал генеральный директор Extreme Networks Эд Мейеркорд, один из клиентов увидел, как время выполнения задач сократилось с 6 часов до 6 минут благодаря такой платформе.</p> <h3>Что это значит для рынка</h3> <p>Все это приводит к значительному сдвигу на рынке — и открывает возможности для поставщиков, которые предлагают действительно зрелые, унифицированные платформы. Эти новые платформы выйдут за рамки операционной инфраструктуры и предоставят многократно используемые возможности — декларативные модели, программируемые намерения и непрерывное отслеживание состояния — которые другие смогут использовать для построения и автоматизации на протяжении всего жизненного цикла, от проектирования до управления и вывода из эксплуатации. Крайне важно, чтобы платформа управлялась как продукт, а не как инструмент, с четкими результатами, ограничениями и ответственностью, потому что больше функций или вспомогательных средств ИИ не сделают платформу полноценной, если они существенно не улучшат результаты бизнеса.</p> <p>После приобретения Juniper компанией HPE, на рынке локальных сетей за пределами центров обработки данных образовалась большая ниша, которую необходимо заполнить. HPE предстоит некоторое время заниматься оптимизацией продуктовых линеек, переработкой ПО для поддержки своих амбиций в области дата-центров, основанных на GreenLake, и интеграцией двух крупных портфелей. Cisco, тем временем, все еще устраняет сложности в продуктах Meraki, Catalyst и своих WAN-решениях — и растущий спрос на решения, ориентированные на суверенитет, не облегчит эту задачу. Extreme имеет хорошие позиции для того, чтобы с помощью Platform ONE сделать в офисных зданиях и на удаленных площадках то, что Arista сделала в дата-центрах, став гигантом и маяком для этого сегмента рынка.</p> <p>Вывод прост: платформы не новы, но на этот раз они реальны. И это меняет направление развития конкуренции в сфере сетевых технологий.</p> 2026-й уже близок к середине, но впереди нас ждет еще много интересного — и, к счастью, не все … article https://www.itweek.ru/themes/detail.php?ID=234982 Tue, 09 Jun 2026 15:47:43 +0300 <p>Эксперты компании «Информзащита» выявили резкое сокращение окна между публикацией CVE и появлением рабочего эксплойта: по итогам анализа открытых баз уязвимостей, данных о публичных proof-of-concept и собственных кейсов реагирования среднее время снизилось со 125,3 дня в январе 2025 года до 0,5 дня к апрелю 2026 года. За первые пять месяцев 2026 года доля уязвимостей, по которым признаки эксплуатации или готовый PoC появлялись в первые сутки после раскрытия, достигла 38% против 12% за сопоставимый период 2025 года.</p> <p>Основная проблема заключается в том, что превратить информацию об ошибке в готовую атаку стало почти так же просто, как её прочитать. Для злоумышленников опубликованное исправление стало техническим указателем: сравнив старую и новую версии кода, можно восстановить логику ошибки и собрать рабочий пример атаки быстрее, чем организация успевает согласовать обновление. Раньше бюллетень производителя, запись в базе CVE и выпущенное исправление давали специалистам по ИБ несколько недель, иногда месяцев на инвентаризацию активов, оценку применимости и планирование обновления. Теперь этот интервал часто укладывается в одну рабочую смену. Для злоумышленников исправление стало не только способом закрыть проблему со стороны производителя, но и технической подсказкой: по сравнению изменений в коде можно восстановить логику ошибки, определить уязвимый участок, сопоставить его с типовыми приемами эксплуатации и собрать рабочий пример быстрее, чем крупная организация успеет пройти полный цикл согласования изменений.</p> <p>Дополнительное ускорение дали инструменты автоматизированного анализа кода и ассистенты на базе больших языковых моделей. Они не заменяют сильного специалиста по эксплуатации уязвимостей, но снимают значительную часть рутинной работы: помогают сравнивать версии, выделять изменения, связанные с безопасностью, подбирать входные данные, искать похожие ошибки в старых уведомлениях производителей и формировать черновики демонстрационного кода. В результате снизился порог входа для воспроизведения уже раскрытой уязвимости. По оценке экспертов, в 2026 году в 31% исследованных кейсов первые публичные примеры эксплуатации имели признаки ускоренной сборки на базе уже опубликованных исправлений, а в 18% случаев код атаки появлялся раньше, чем у крупных поставщиков средств сканирования и управления уязвимостями выходили стабильные проверки.</p> <p>На стороне бизнеса ситуацию осложняют кадровый дефицит и неоднородность инфраструктуры. Даже зрелые команды не всегда могут быстро ответить на базовый вопрос, где именно используется уязвимый компонент. В одной организации он может находиться в коммерческом продукте, контейнерном образе, внутренней разработке, устаревшем сервисе на периметре сети или в системе подрядчика. К этому добавляется разрыв между публикацией CVE и появлением качественного правила обнаружения в сканерах: часть проверок выходит с задержкой, часть покрывает только отдельные версии продукта, часть требует проверки с учетными данными, которую компании не всегда включают из-за рисков для рабочих систем. Команды привыкли закрывать уязвимости в плановом режиме — раз в неделю, иногда реже. Это работало, пока атака готовилась месяцами. Сейчас тот же процесс просто не успевает: к моменту, когда задача попадает в спринт, окно уже закрыто — но не в пользу защитников. </p> <p>Наиболее заметная концентрация риска в 2026 году наблюдается в отраслях, где сочетаются крупный внешний периметр, множество прикладных систем и жесткие ограничения на простои. По данным анализа обращений и расследований, на финансовый сектор пришлось 24% кейсов, связанных с эксплуатацией CVE в первые 72 часа после раскрытия, на промышленность и энергетику — 19%, на ИТ и телеком — 17%, на розничную торговлю и интернет-продажи — 14%, на транспорт и логистику — 10%, на государственные и окологосударственные организации — 9%, на медицину и фармацевтику — 7%. В финансах и интернет-торговле злоумышленников привлекает доступ к платежной инфраструктуре и персональным данным, в промышленности — длительные циклы обновления и зависимость от поставщиков, в телеком-сегменте — высокая плотность сетевых сервисов и большое число пограничных компонентов.</p> <p>Данные сканеров стоит дополнять ведомостью состава программного обеспечения, анализом состава приложений, мониторингом данных о киберугрозах и проверкой доступности систем с внешнего периметра сразу после публикации значимых CVE. Для критичных систем нужен заранее согласованный порядок экстренного обновления, приоритизация по фактической доступности актива из сети и сценарии временного снижения риска: отключение уязвимой функции, ограничение доступа по спискам контроля, усиление правил межсетевого экрана веб-приложений, изоляция сегмента, перевод сервиса за дополнительный контроль аутентификации. Отдельного внимания требует ретроспективный поиск признаков компрометации: при появлении эксплойта через несколько часов после раскрытия исправление уязвимости уже не гарантирует, что злоумышленники не успели закрепиться в системе до установки обновления.</p> Эксперты компании «Информзащита» выявили резкое сокращение окна между публикацией CVE и появлением рабочего эксплойта … message https://www.itweek.ru/themes/detail.php?ID=234981 Tue, 09 Jun 2026 15:47:00 +0300 <p>Промсельхозбанк вывел на российский рынок платежный сервис «Pay in Russia» (Плати в России) — иностранные туристы смогут открыть карту онлайн и пополнить ее удобным способом. Решение реализовано менее чем за 5 месяцев на базе платформы ДБО для физлиц от BSS, которая позволяет быстро доработать функционал под бизнес-идеи банка и бесшовно интегрировать различные сервисы для клиентов.</p> <p>Промсельхозбанк внедрил первый полноценный платежный сервис «Pay in Russia» (Плати в России) для иностранных туристов на базе системы дистанционного банковского обслуживания для физлиц от BSS. </p> <p>Новое решение позволяет гостям из других стран оплачивать товары и услуги по QR-коду как онлайн, так и офлайн. Онлайн-счет заводится в несколько кликов, и пополнять его клиент может прямо со своих зарубежных карт. </p> <p>Сервис реализован на базе платформы Digital2Retail — команда BSS расширила ее функциональность под задачи сервиса: обеспечила выпуск виртуальных карт для пользователей, реализовала сценарии работы с идентификацией и без нее, внедрила распознавание и поддержку паспортов различных стран, а также предусмотрела ряд других возможностей.</p> <p>Ключевое преимущество платформы BSS — гибкость и возможность развития: система позволяет быстро адаптироваться и реализовывать новые требования заказчика, дорабатывать функциональность под новые продукты и бесшовно интегрироваться с внешними сервисами через ТИР.</p> <p>Председатель Правления Промсельхозбанка Владимир Курстак прокомментировал: «Новое решение упростит расчеты и сделает уровень сервиса для туристов в российских городах еще комфортнее. Для бизнеса это дополнительный драйвер роста: сервис снимает барьеры на финальном этапе оплаты и помогает сократить упущенную выгоду, которая, по оценкам экспертов, исчислялась миллиардами рублей».</p> <p>Равшан Рахманов, директор по развитию продуктов Центра разработки продуктов для физических лиц компании BSS, рассказал: «Благодаря гибкости нашей системы ДБО банки могут как вносить точечные доработки, так и создавать новые цифровые сервисы под конкретные бизнес-задачи заказчика, соблюдая Time To Market. Наглядный пример — платежный сервис „Pay in Russia“ (Плати в России), при реализации которого были учтены уникальные бизнес-процессы и требования Банка, и который при этом реализован менее чем за пять месяцев с момента старта проекта».</p> Промсельхозбанк вывел на российский рынок платежный сервис «Pay in Russia» (Плати в России) — иностранные … message https://www.itweek.ru/themes/detail.php?ID=234980 Tue, 09 Jun 2026 09:17:57 +0300 <p><em>Согласно Gartner «1H26 CIO Report», 77% </em><em>CIO</em> <em>называют безопасность и риски главными препятствиями для масштабирования автономных технологий. Некоторые из них, тем не менее, находят способы ускорить этот процесс, сообщает портал </em><em>InformationWeek</em><em>.</em></p> <p>Автономный искусственный интеллект выходит от стадии эксперимента и становится приоритетом предприятия. Модели достаточно точны. Экономическое обоснование очевидно. Советы директоров стремятся к ускорению. Но большинство CIO сдерживают проблемы безопасности, а не технические ограничения.</p> <p>Действительно, 77% из более чем 11 тыс. CIO, опрошенных Gartner, заявили, что безопасность и риски являются главными препятствиями для масштабирования автономных технологий. Их опасения обоснованы: автономные агенты ИИ могут допускать утечки данных, совершать дорогостоящие ошибки и создавать проблемы с аудитом.</p> <p>Но все большее число CIO находят способы ускорить процесс, не жертвуя безопасностью. Ответ, по их словам, кроется в защитных ограничениях, управлении и ином типе партнерства между CIO и руководителями, отвечающими за безопасность и конфиденциальность.</p> <h3>Растущее давление со стороны автономного ИИ</h3> <p>Согласно <a href="https://www.gartner.com/en/newsroom/press-releases/2026-04-23-gartner-survey-reveals-80-percent-of-ceos-say-artificial-intelligence-will-force-operational-capability-overhauls">опросу</a> Gartner, проведенному в апреле 2026 г. среди 469 руководителей компаний, примерно восемь из десяти из них ожидают, что к 2030 г. автономный бизнес будет доминировать в их отрасли. Советы директоров и руководство, осознавая конкурентные риски, подталкивают CIO идти в ногу с этими изменениями.</p> <p>«Наши команда руководителей и совет директоров относительно хорошо разбираются в ИИ, — говорит Кит Фултон, директор по данным поставщика ПО для финансовых учреждений Jack Henry. — Они видят потенциал ИИ. И спрашивают: „Как мы можем ускорить процесс?“. Я отвечаю: „Я тоже хочу ускорить процесс. Но мы хотим быть осторожными“».</p> <p>Это напряжение между давлением бизнеса и дисциплиной в области безопасности проявляется во всех отраслях. Опрос Sembi «Software Quality Pulse Report», проведенный среди почти 3800 руководителей компаний-разработчиков ПО, показал, что 86% как минимум иногда задерживают выпуск релизов из-за проблем безопасности, а 63% называют проблемы конфиденциальности и безопасности препятствиями для внедрения ИИ.</p> <p>«Сейчас со всех сторон бизнеса оказывается реальное давление с целью ускорения внедрения ИИ, и команды безопасности [и ИТ] не могут просто сказать „нет“, — отмечает Ринки Сети, CISO компании Upwind Security и бывший руководитель служб безопасности в Twitter, Rubrik и BILL. — Разговор сместился с блокирования инноваций на их ответственное внедрение».</p> <h3>Главные проблемы с агентным ИИ</h3> <p><strong>Утечка данных.</strong> По словам многих руководителей, основная проблема — это видимость, точнее её отсутствие. «Большинство организаций до сих пор не до конца понимают, к чему имеют доступ агенты ИИ, на какие действия они способны и как они ведут себя после развертывания в производственных средах, — говорит Сети. — Утечка данных — это серьезная проблема, особенно когда агенты могут получать доступ к внутренним системам или перемещать информацию между средами без четкого контроля».</p> <p>Фултон проводит различие между кибербезопасностью и безопасностью данных: «На самом деле, самая большая проблема — это не кибербезопасность. А безопасность денег и данных. Мы должны быть уверены, что персональные данные не покидают здание, когда мы общаемся с агентами гиперскейлеров».</p> <p><strong>Ошибочность агентов.</strong> Проблема усугубляется ошибочностью агентного ИИ. «Агенты достигли точности <nobr>80-99%.</nobr> Они становятся лучше, но точны не на 100%, — говорит Фултон. — Если бы у вас была электронная таблица Excel, и 1% возвращаемых ею данных были бы вымышленными, никто бы ею не пользовался. Но агенты страдают именно этим».</p> <p><strong>Теневой ИИ.</strong> Дополнительную сложность добавляет рост теневого ИИ. «Сотрудники внедряют инструменты ИИ, потому что они повышают производительность, и большинство групп по безопасности обнаруживают их использование постфактум, а не через формальные процессы утверждения, — говорит Сети. — Однако решение не в том, чтобы запрещать всё подряд, потому что это обычно загоняет деятельность ещё глубже в подполье».</p> <h3>Безопасность в ИИ с самого начала</h3> <p>Организации, которые продвигаются быстрее всего, не добавляют безопасность после развертывания. Они строят её с самого начала.</p> <p>«Безопасность не является для нас тормозом, — говорит Чейз Кристенсен, CIO сегмента и вице-президент по корпоративным решениям компании Jabil, предоставляющей производственные услуги. — Она замедляет процесс только тогда, когда мы не закладываем ее в наши процессы. Мы же встраиваем безопасность на начальном этапе жизненного цикла разработки ПО (SDLC). Это устраняет все препятствия и позволяет нам быстро масштабироваться».</p> <p>Он также переосмыслил подход Jabil к теневым ИТ и ИИ. «Мы не говорим о теневых ИТ — мы говорим о демократизации ИТ, — поясняет он. — Корпоративные ИТ-службы могут работать медленно. Наша задача — предоставить платформы. Когда мы обеспечиваем правильные данные и правила использования, то, что выглядит как теневые ИТ, становится двигателем роста организации».</p> <p>Сети соглашается с тем, что ранняя интеграция имеет важное значение. «Организации, которые успешно это делают, с самого начала рассматривают системы ИИ как производственные нагрузки, а не как экспериментальные побочные проекты, — говорит она. — Добавление системы безопасности после развертывания редко бывает эффективной, потому что к этому моменту система ИИ уже интегрирована в рабочие процессы, API и среды данных, которые трудно распутать».</p> <h3>Правильные ограничения для ИИ: принцип собачьей площадки</h3> <p>Фултон рассматривает ограничения не как препятствия, а как факторы, ускоряющие процесс. «Я часто обращаюсь к аналогии с собачьей площадкой, — говорит он. — Я вожу туда своего щенка, потому что хочу, чтобы у нее была свобода, но я не хочу, чтобы она бегала по улице. Она видит забор и не выходит за него. Она может резвиться, и я знаю, что с ней все в порядке. Ключ к быстрому прогрессу — это наличие правильных ограничений».</p> <p>Уровень риска определяет ограничения. «У нас есть критерии для оценки уровня риска действий, которые может предпринять агент, — говорит Фултон. — В зависимости от уровня риска мы применяем разные ограничения. Перемещение денег очень сложно отменить. Ограничения в этом случае должны быть очень осторожными и строгими по сравнению с ограничениями для „второго пилота“, помогающего составить документ Word».</p> <p>Ответственность не подлежит обсуждению. «Каждый агент должен отслеживаться, проверяться и быть привязан к конкретному человеку, ответственному за его поведение, — считает Фултон. — Нельзя посадить агента в тюрьму. Каждое действие агента должно быть отслежено до человека, ответственного за него».</p> <h3>Непрерывная видимость развертывания ИИ</h3> <p>Для Сети самым большим изменением является переход от статических проверок политик к мониторингу в режиме реального времени. «Безопасность становится тормозом, когда команды полагаются на традиционные модели управления, которые не были созданы для автономных систем реального времени, — говорит она. — Организации, которые продвигаются быстрее всего, — это те, которые при развертывании ИИ с самого начала обеспечивают видимость и контекст в режиме реального времени, вместо того чтобы пытаться добавить элементы управления позже».</p> <p>Это означает переосмысление того, что такое «достаточно хорошая» безопасность. «Если вы не можете ответить на вопрос, к каким данным агент имеет доступ, какие действия он может предпринять или отклонилось ли его поведение от нормальных шаблонов, вы не готовы к масштабированию, — отмечает Сети. — Ошибка заключается в том, чтобы рассматривать развертывание ИИ как требующее разовой проверки безопасности, а не как постоянное обязательство по мониторингу».</p> <h3>Изменение взаимоотношений между CIO и CISO</h3> <p>Многие руководители указывают на динамику отношений между CIO и CISO как на критически важный фактор — или узкое место — в области автономного ИИ.</p> <p>«ИИ делает отношения между CIO и CISO гораздо более тесно переплетенными в операционном плане, — говорит Сети. — Исторически безопасность и ИТ могли работать параллельно, но автономные системы требуют гораздо более тесной координации, поскольку инфраструктура, управление данными, разработка приложений и безопасность теперь глубоко взаимосвязаны».</p> <p>Разговоры также изменились. «Речь теперь идет не столько о контрольных списках соответствия, сколько об операционной устойчивости, прозрачности и управлении бизнес-рисками со скоростью автоматизации, — отмечает Сети. — Во многих организациях CIO и CISO теперь совместно несут ответственность за безопасное внедрение ИИ, а не рассматривают безопасность как функцию утверждения на последующем этапе».</p> <p>Роль директора по конфиденциальности (CPO). По словам Фултона, традиционное партнерство CIO и CISO — это лишь часть картины. «CPO может быть вовлечен больше, чем CISO, — говорит он. — Речь идёт об уважении конфиденциальности клиентов и заказчиков — и о том, чтобы не доверять их данные гиперскейлерам».</p> <p>Организации, масштабирующие автономный ИИ, не игнорируют безопасность. Они просто перестали позволять ей быть причиной того, что все останавливается. «Не ждите идеального управления, прежде чем двигаться вперёд, потому что бизнесу надо идти вперёд, — советует Сети. — Скорость без видимости создаёт риск, тогда как видимость даёт вам уверенность в том, что вы можете ответственно двигаться быстрее».</p> Согласно Gartner «1H26 CIO Report», 77% CIO называют безопасность и риски главными препятствиями для масштабирования … article https://www.itweek.ru/themes/detail.php?ID=234978 Tue, 09 Jun 2026 09:03:59 +0300 <p><em>На рынке труда в ИТ сложилась странная ситуация: резюме много, подходящих людей — по</em><em>-</em><em>прежнему мало. Повышать зарплаты бизнес не может — компании оптимизируются в связи с охлаждением экономики. </em><em>Рассмотрим, к</em><em>ак балансировать между дефицитом сильных специалистов и ограниченным бюджетом так, чтобы ИТ-команда работала на бизнес-результат.</em></p> <p>Еще несколько лет назад ИТ-директор мог закрывать большинство кадровых задач деньгами и массовым аутсорсингом. Теперь таких бюджетов нет, а те специалисты, которые действительно двигают продукт и инфраструктуру вперед, дороги и штучны. Реальный спрос смещается в сторону узких и сложных ролей — архитекторов, техлидов, экспертов в доменах (финтех, HR-tech, логистика, e-commerce) и специалистов по современным стекам и инструментам.</p> <p>Воронка резюме расширяется, но большинство кандидатов не дотягивают по глубине экспертизы. При этом на рынке мало аутсорс-команд, которые действительно разбираются в конкретном бизнес-домене заказчика. Ожидания сильных специалистов по зарплате выросли и уперлись во внутренние ограничения компаний. В результате ИТ-директора зажаты с двух сторон: с одной — «зарплатный потолок» и жесткий бюджет, с другой — дефицит тех, кто реально тянет сложные проекты.</p> <h2>От количества к компетенциям</h2> <p>Раньше, чтобы быстрее показать результат, нанимали больше людей. Сегодня такая логика не работает: набор еще десятка мидлов без доменной экспертизы не решает задач бизнеса. Поэтому полезно ввести несколько новых принципов найма.</p> <ul> <li> <strong>Доменные знания как обязательное требование.</strong> Если продукт в HR, нужен человек, который понимает HR-процессы, если система для финтеха — специалист, который разбирается в финансовых инструментах и регуляторике. Универсальные разработчики все хуже попадают в сложные вертикали.</li> <li> <strong>Глубина компетенций важнее широты.</strong> В условиях жестких бюджетов компании ищут людей, которые могут спроектировать устойчивую архитектуру, закрыть вопросы безопасности, обеспечить сложные интеграции и взять на себя ответственность за решения, от которых зависит работа систем.</li> <li><strong>Не нанимать, если можно автоматизировать.</strong> Рутинная работа в разработке, тестировании и поддержке постепенно уходит в автоматизацию — от CI/CD-пайплайнов до самообслуживания в поддержке.</li> </ul> <h2>Сегментация команды</h2> <p>Структура ИТ-команд часто выглядит как «линейка грейдов»: джуны, мидлы, сеньоры, тимлиды — без явной бизнес-логики распределения ресурсов. Сегодня стоит перейти к более жесткой сегментации. Бюджет и усилия по удержанию распределяются по трем уровням.</p> <h3>Уровень 1: незаменимые эксперты и архитекторы</h3> <p>Это небольшой слой людей, без которых бизнес перестает работать. Архитекторы, ведущие эксперты по основным продуктам, системам и платформам, люди, которые держат в руках критичные участки — от ядра продукта до стратегических интеграций.</p> <ul> <li> Им платят заметно больше среднего по рынку.</li> <li> С ними работают точечно по вовлеченности и удержанию.</li> <li> Их риски ухода — под постоянным управлением: от преемственности до распределения знаний внутри команды.</li> </ul> <p>Потеря одного такого человека может «заморозить» проект на месяцы и обойтись компании в миллионы.</p> <h3>Уровень 2: сильные исполнители</h3> <p>Сюда попадает основной массив разработчиков, аналитиков, тестировщиков, тимлидов, которые обеспечивают стабильную работу и развитие продуктов.</p> <ul> <li> Главное для этого слоя — предсказуемость и стабильность: понятные процессы, прозрачные правила игры, адекватный менеджмент.</li> <li> Текучка должна быть управляемой: массовый отток мидлов и синьоров бьет по скорости поставки и качеству.</li> </ul> <p>Для сотрудников второго уровня компания не всегда может существенно увеличивать сумму вознаграждения, поэтому конкурентоспособность часто обеспечивается за счет условий: гибкий формат работы, понятные карьерные треки, обучение и участие в интересных проектах.</p> <h3>Уровень 3: джуниоры и аутсорс</h3> <p>Это слой, где допускается высокая текучка и максимальная автоматизация. Речь идет о начинающих ролях, а также внешних подрядчиках, которые закрывают типовые задачи — поддержка, доработки, неключевые проекты.</p> <ul> <li> Здесь важно выстроить процессы так, чтобы уход одного человека минимально влиял на бизнес.</li> <li> Любые рутинные операции должны быть максимально описаны и автоматизированы.</li> <li> Новые люди должны быстро входить в контур, а действующие — легко заменяться.</li> </ul> <p>Такой подход к сегментации позволяет ИТ-директору честно ответить на вопросы: «На кого мы тратим больше всего денег?», «Кого мы ни в коем случае не можем потерять?», Где мы можем позволить себе текучку?".</p> <h2>Роль ИТ-директора в достижении бизнес-результата</h2> <p>ИТ-директор становится одним из профильных руководителей, влияющих на бизнес-результат. Однако рассчитывать точное влияние ИТ на P&L (отчет о прибылях и убытках) — сложно, а интерпретация может быть субъективной: слишком много факторов влияют на итоговую картину (от автоматизации до прямых доходов), и легко нарисовать желаемые цифры, которые далеки от реальности. Поэтому лучше также показывать результат через надежные метрики, которые в свою очередь влияют на P&L. Это управляемость процессов, пользовательский и клиентский опыт, скорость вывода продуктов.</p> <p>Например, при разворачивании системы мультиканального общения сотрудников чистая экономия в деньгах не сойдется. Зато улучшения в управляемости и пользовательском опыте принесут бизнесу реальный эффект.</p> <p>Таким образом, для влияния на P&L ИТ-директор может:</p> <ul> <li> снижать расходы за счет автоматизации процессов и оптимизации поддержки;</li> <li> контролировать фонд оплаты труда, перераспределяя задачи между сотрудниками разного уровня, снижая зависимость от дорогих специалистов и выстраивая осознанную политику аутсорса;</li> <li> увеличивать выручку и скорость вывода продуктов за счет грамотной структуры команды, которая может быстро запускать и масштабировать решения.</li> </ul> <p>По сути, ИТ-директор сегодня отвечает не только за технологии, но и за то, как эти технологии превращаются в деньги и экономию для бизнеса.</p> <h2>Что делать ИТ-директору уже сейчас</h2> <ol> <li><strong>Провести инвентаризацию команды.</strong> Честно разделить сотрудников на три уровня — понять, кто действительно незаменим, какие позиции нужно усилить, кого перевести в другой формат работы.</li> <li><strong>Пересобрать структуру затрат.</strong> Сфокусировать бюджет на удержании ключевых экспертов и архитекторов, заложить стабильные условия для ядра специалистов второго уровня, выстроить экономную модель третьего уровня.</li> <li><strong>Усилить доменную экспертизу.</strong> Пересмотреть требования к найму: ввести обязательный фильтр по доменным знаниям, добавить кейсы на понимание конкретного бизнеса, уделять внимание не только стеку, но и пониманию предметной области.</li> <li><strong>Ускорить автоматизацию.</strong> Проанализировать, какие функции можно отдать скриптам, платформам и сервисам — и сократить зависимость от ручного труда там, где он не создает уникальной ценности.</li> <li><strong>Связать ИТ с бизнес-результатом.</strong> Показать бизнесу, как реструктуризация команды и автоматизация позволяют ускорять запуск новых продуктов, улучшать управляемость в командах и пользовательский опыт.</li> </ol> <p>#IMAGE_234979#</p> На рынке труда в ИТ сложилась странная ситуация: резюме много, подходящих людей — по-прежнему мало. Повышать … article Дмитрий Махлин, партнер и директор по развитию HRlink https://www.itweek.ru/themes/detail.php?ID=234974 Mon, 08 Jun 2026 11:06:28 +0300 <p>Сбер выпустил новую версию ИИ-ассистента GigaCode, которая работает и запускается из командной строки независимо от типа среды разработки (IDE) и операционной системы</p> <p>GigaCode CLI — это мультиагентная система, ориентированная на автономную генерацию кода. Она позволяет запускать задачи прямо из терминала, работать в привычном репозитории, автоматизировать сборку, тестирование и внесение изменений в код, а также искать уязвимости, рефакторить код, писать тесты. Основная ценность GigaCode CLI в ускорении выполнения типовых операций в защищенном контуре организации.</p> <p>Использование GigaCode CLI локально (on-premise) — это ответ на запрос крупных корпоративных клиентов. Им важно ускорять разработку с помощью искусственного интеллекта, сохраняя полный контроль над данными и инфраструктурой внутри собственного периметра. Автономность разработки критична, в частности, для банков, промышленности, телеком- и государственных организаций, где требования к информационной безопасности и локализации данных стоят на первом месте.</p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Наши внутренние тесты показали, что использование CLI в GigaCode повышает производительность инженеров на <nobr>30-70%</nobr> в зависимости от их задач. Глобально уменьшаются затраченные человеко-часы и растет качество ПО за счет лучшей проверки кода и поиска уязвимостей. Развитие GigaCode, расширение его функциональности и дальнейшая интеграция в разработку на стороне клиентов позволяет не просто автоматизировать задачи заказчиков, а кардинально сократить время вывода продуктов на рынок, обеспечить безопасность кода и совершить качественный скачок в трансформации всей ИТ-инфраструктуры».</p> <p>Помимо ключевого обновления в виде локального <nobr>CLI-агента,</nobr> в GigaCode стал доступен расширенный набор больших языковых моделей. Оплата за них осуществляется в рублях. Таким образом, клиенты смогут продолжать пользоваться наиболее современными и мощными нейросетями для разработки.</p> Сбер выпустил новую версию ИИ-ассистента GigaCode, которая работает и запускается из командной строки независимо … message https://www.itweek.ru/themes/detail.php?ID=234973 Mon, 08 Jun 2026 11:04:55 +0300 <p>За последние годы искусственный интеллект из прикладного инструмента превратился в один из ключевых факторов трансформации науки. На примере стран, наиболее активно внедряющих ИИ в научную деятельность, Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил разные модели развития и регулирования данной сферы.</p> <p>Американская модель делает ставку на расширение доступа исследователей к данным, вычислительным ресурсам и ИИ-инструментам. Эту задачу решают такие крупные инфраструктурные инициативы, как Национальный ресурс для исследований ИИ (NAIRR) и программа Genesis. Государство выступает главным образом в роли координатора и инвестора, а регулирование остается преимущественно мягким и основывается на добровольных стандартах и инструментах оценки рисков. Важную роль в развитии системы играют также принципы открытой науки, предполагающие обмен данными и моделями.</p> <p>Китайская модель отличается значительным масштабом инвестиций и высокой степенью централизации. Государство координирует развитие вычислительной инфраструктуры, научных данных и кадрового потенциала, а финансирование осуществляется через крупные госпрограммы. Например, Национальная система скоординированных инноваций интегрированных центров больших данных поддерживает работу распределенной вычислительной инфраструктуры и сети из восьми опорных вычислительных хабов, ежегодно обеспечивающих ресурсами сотни исследовательских проектов. Такой подход позволяет концентрировать ресурсы на приоритетных направлениях и ускорять их развитие.</p> <p>Европейская модель сочетает масштабные инвестиции в инфраструктуру и научную кооперацию с одной из наиболее развитых систем регулирования ИИ. Значительные средства направлены на создание единого исследовательского пространства, объединяющего данные, вычислительные мощности и научные коллективы стран ЕС. Одновременно действуют обязательные требования к аудиту высокорисковых систем ИИ и использованию персональных данных, обеспечивающие прозрачность и безопасность применения технологии.</p> <p>Британская модель обеспечивает развитие вычислительной инфраструктуры и адресную поддержку проектов и исследовательских коллективов даже при более ограниченных объемах государственных инвестиций. Доступ к вычислительным ресурсам реализуется через специализированную инфраструктуру, ключевую роль в которой играет программа AI Research Resource, предоставляющая научным коллективам мощности для обучения и использования ИИ-моделей.</p> <p>Опыт ведущих стран показывает, что конкуренция в сфере ИИ для науки разворачивается не столько на уровне отдельных разработок, сколько в плоскости создания устойчивых научно-технологических экосистем. Несмотря на различия в моделях регулирования, государства используют схожий набор инструментов поддержки: развивают вычислительную инфраструктуру и ресурсы научных данных, поддерживают исследовательские проекты и подготовку кадров, внедряют принципы ответственного использования ИИ. Для России это означает необходимость комплексного подхода, объединяющего развитие инфраструктуры, кадрового потенциала и механизмов взаимодействия науки и индустрии с формированием национальных стандартов применения ИИ.</p> За последние годы искусственный интеллект из прикладного инструмента превратился в один из ключевых факторов … message https://www.itweek.ru/themes/detail.php?ID=234972 Mon, 08 Jun 2026 11:03:31 +0300 <p>Вышла новая версия Luxms BI v12. Платформа включает ИИ-функциональность, расширение возможностей программируемой аналитики и глубокой адаптации под корпоративные задачи. Обновление затрагивает ключевые уровни системы — технологический стек, пользовательский интерфейс и внутреннюю логику работы с данными.</p> <p>Одним из ключевых обновлений Luxms BI v12 стала поддержка ИИ-сценариев. В платформе появился ИИ-аналитик — интеллектуальный ассистент, встроенный непосредственно в BI-среду.</p> <p>Пользователь может общаться с ним на естественном языке без специальных промтов. ИИ понимает структуру аналитической модели, работает с существующими показателями, фактами и размерностями и помогает выполнять повседневные задачи аналитики.</p> <p>ИИ-аналитик может:</p> <ul> <li>создавать кубы и аналитические модели данных;</li> <li>самостоятельно формировать дэшборды и отчеты по запросу пользователя;</li> <li>объяснять полученные результаты и помогать интерпретировать показатели;</li> <li>ускорять работу с данными и создание аналитических решений.</li> </ul> <p>ИИ-аналитик позволяет автоматизировать и ускорить работу дата-инженера и аналитика — от подключения источника, при наличии подключения к каталогу данных*, и подготовки модели данных до готового отчета и аналитического вывода.</p> <p>Luxms BI позволяет подключать различные <nobr>LLM-модели</nobr> непосредственно в аналитические процессы. Особое внимание уделено безопасности — поддерживается использование локальных моделей, когда данные остаются внутри корпоративного контура компании.</p> <p>При этом платформа не ограничивается готовыми функциями вроде чат-ботов или встроенных ассистентов. Сегодня это может быть ИИ-аналитик, а завтра любой другой интеллектуальный сценарий, необходимый бизнесу.</p> <p>ИИ-функциональность доступна начиная с версии 12 как дополнительное расширение платформы и требует отдельного лицензирования.</p> <p>Одним из важных обновлений в версии 12 стало развитие LPE — внутреннего языка платформы.</p> <p>LPE по-прежнему остается удобным языком формул и расчетов, постоянно развивается и пополняется новым функционалом. Но теперь LPE стал еще и мощным языком программирования, который управляет поведением системы. Он связывает данные, расчеты, визуализации, фильтры, пользовательское поведение и интерфейс единой логикой. LPE в версии 12 позволяет:</p> <ul> <li>динамически изменять структуру и отображение дэшбордов;</li> <li>управлять состояниями, фильтрами и пользовательскими сценариями;</li> <li>адаптировать интерфейс под контекст и действия пользователя;</li> <li>реализовывать сложную бизнес-логику без внешней разработки.</li> </ul> <p>LPE в 12 версии дает возможность настроить бизнес-логику, которая не закладывалась вендором, путём написания кода с использованием специально разработанных для этого функций. </p> <p>Один интерфейс может адаптироваться под различные сценарии использования, менять набор визуализаций, компоновку, фильтры и аналитику в зависимости от контекста. Например, при снижении продаж на дэшборде показывается детализация каналов продвижения, а при перерасходе бюджета — структуру затрат и эффект.</p> <p>Раньше такая задача решались бы через набор отдельных дэшбордов, а сейчас — внутри одного интерфейса. Дэшборд может динамически менять свое содержимое в зависимости от состояния — фильтров, пользовательских действий, прав или даже размера экрана. Фактически — набор различных сценариев в одном интерфейсе.</p> <p>По сути, Luxms BI формирует собственный слой программируемой логики внутри платформы. LPE выступает как специализированный предметно-ориентированный язык для управления логикой и поведением внутри платформы. Такой подход позволяет реализовывать сложные сценарии, сохраняя преимущества коробочного решения — безопасность, управляемость и совместимость при обновлениях системы. Компании получают гибкость кастомизации без типичных проблем глубокой разработки на JavaScript, где обновления со временем приводят к рискам несовместимости и усложнению поддержки решений.</p> <p>В планах развития — развитие интерфейса для настройки логики с LPE, усиления подхода к переиспользованию через Init.LPE и упрощение создания сложных сценариев.</p> <p>Но при этом LPE это также и язык формул, как и раньше. Простой пользователь может ограничиться расчетами, а продвинутый аналитик — использовать его как полноценный скриптовый язык. Это важный шаг в сторону self-service — аналитики получают больше контроля без необходимости полноценной разработки. В результате платформа становится расширяемой не только со стороны вендора, но и со стороны пользователя.</p> <p>Важной частью обновления стал переход платформы на React 19. Для Luxms BI это стратегическое обновление технологического стека, которое влияет на производительность, стабильность и дальнейшее развитие интерфейсов платформы.</p> <p>Новая версия React обеспечивает:</p> <ul> <li>более высокую отзывчивость интерфейсов;</li> <li>стабильную работу сложных дэшбордов и больших объемов данных;</li> <li>снижение нагрузки на браузер;</li> <li>улучшенную обработку состояний и ошибок;</li> <li>совместимость с современными библиотеками и инструментами разработки.</li> </ul> <p>Переход на актуальную версию React также формирует основу для ускоренного развития пользовательских интерфейсов и внедрения новых возможностей платформы в будущих релизах.</p> <p>White label и развитие корпоративных BI-платформ</p> <p>В новой версии Luxms BI появилась поддержка white label — возможность разворачивать платформу как собственное BI-решение компании.</p> <p>Компании могут использовать Luxms BI как технологическую основу собственной BI-платформы, адаптируя интерфейс, визуальный стиль и пользовательский опыт под собственный бренд и корпоративные стандарты. Такой подход особенно востребован в крупных организациях, где усиливается тренд на развитие внутренних цифровых платформ и независимых ИТ-экосистем.</p> <p>White label позволяет объединить преимущества готовой промышленной BI-платформы с гибкостью собственного решения без необходимости разрабатывать систему с нуля.</p> <p>С версии 12 документация становится версионной — теперь можно выбирать нужный вариант базы знаний в соответствии с версией системы, с которой работаете. Также в документации к версии 12.0.0 появились новые разделы:</p> <ul> <li>руководство по LPE для фронтенда;</li> <li>руководство по управлению отчетами;</li> <li>руководство прикладного администратора.</li> </ul> <p>Luxms BI v12 — это не просто очередное обновление функциональности. Новая версия усиливает платформу сразу на нескольких уровнях — архитектуры, интерфейсов, логики и возможностей кастомизации, и предлагает основу для дальнейшего развития интеллектуальной аналитики.</p> Вышла новая версия Luxms BI v12. Платформа включает ИИ-функциональность, расширение возможностей программируемой аналитики … message https://www.itweek.ru/themes/detail.php?ID=234971 Mon, 08 Jun 2026 11:01:22 +0300 <p>«Яндекс» разработал ультрамалую нейросетевую модель для голосового управления в носимых ИИ-устройствах. Размер модели удалось сократить без потери качества примерно до 200 Кб — это меньше объёма одной фотографии на смартфоне. Информацией об этом поделился Дмитрий Солодуха, руководитель направления голосовой активации в «Яндексе».</p> <p>Подход к голосовому управлению в носимых устройствах отличается от подхода, используемого в умных колонках или смартфонах. Компактные гаджеты сильнее ограничены по ёмкости аккумулятора, объёму памяти и вычислительной мощности процессора. При этом система голосовой активации должна постоянно анализировать аудиопоток и обрабатывать его локально в ожидании ключевой команды, не создавая заметной нагрузки на устройство и не сокращая время его автономной работы. Для решения этой задачи команда Яндекса создала систему обработки голоса на нескольких уровнях — от аппаратной части до самой нейросетевой модели.</p> <p>Инженеры применили двухэтапную систему обработки аудиосигнала. Сначала лёгкая модель определяет наличие речи в потоке звука и практически не нагружает устройство. Основная модель запускается только после этого и проверяет, была ли произнесена ключевая голосовая команда. Такой подход позволяет снизить постоянную вычислительную нагрузку и расход энергии.</p> <p>Отдельной задачей стала оптимизация самой нейросетевой модели, поскольку именно непрерывная работа системы голосовой активации, которая ждет команду, создаёт основную нагрузку на аккумулятор устройства. Команда сократила число параметров модели примерно в 10 раз за счёт более компактной архитектуры нейросети, которая требует меньше вычислений без существенной потери качества распознавания. Это позволяет выполнять распознавание голосовой команды локально — без постоянной передачи аудиосигнала в облако. За счёт этого снижается энергопотребление устройства и уменьшается задержка при обработке команд.</p> <p>Одним из решений проблемы стало использование чипов с NPU — специализированным нейропроцессором для ускорения вычислений нейросетей с меньшим энергопотреблением по сравнению с CPU.</p> <p>По словам Дмитрия Солодухи, такой подход может использоваться в разных устройствах с обработкой речи в реальном времени — например, в наушниках, умных часах и других компактных носимых устройствах с ИИ-функциями.</p> «Яндекс» разработал ультрамалую нейросетевую модель для голосового управления в носимых ИИ-устройствах. Размер модели … message https://www.itweek.ru/themes/detail.php?ID=234969 Mon, 08 Jun 2026 08:43:11 +0300 <p><em>Три четверти руководителей предприятий сообщают, что они внедряют агентный искусственный интеллект. Но лишь небольшое меньшинство использует его в реальных производственных условиях, за исключением «агентных» чат-ботов, а по-настоящему масштабируемые мультиагентные системы встречаются еще реже. В этом разрыв между погоней и достижением результата, и это история 2026 г. Технология ИИ — это неуправляемый поезд. А предприятие — это тяжелый груз, который оно должна тянуть, пишут в корпоративном блоге авторы нового отчета </em><em>Forrester</em> <em>«</em><em>The</em> <em>State</em> <em>Of</em> <em>Agentic</em> <em>AI</em><em>, 2026</em><em>».</em></p> <p> #IMAGE_234970#</p> <p>В основе нового исследования Forrester лежат интервью с архитекторами, создающими агентные системы. Авторы отчета также проанализировали данные опроса, чтобы подкрепить эту историю фактами. Общий вывод таков: технология уже появилась, но готовность предприятий к её внедрению пока отстает. Это никого не должно удивлять. Мы уже видели подобную историю. Более сложный вопрос заключается в том, сможет ли готовность когда-либо догнать технологию, развивающуюся так быстро.</p> <h3>Ждать агентов больше не нужно</h3> <p>Возможности ИИ уже есть, и они появились быстрее, чем кто-либо ожидал. Рынок поставщиков в режиме реального времени перестраивается вокруг агентов. Агенты теперь работают часами, днями, даже месяцами. OpenAI уже несколько месяцев использует внутренний рабочий процесс разработки ПО с минимальным вмешательством. Cursor развернула агентов, работающих в режиме длительного кодирования. Anthropic продемонстрировала агентов для многодневных исследований. Доказательства применимости технологии получены.</p> <p>Агент, работающий в режиме длительного кодирования, не ведёт себя как чат-бот. Она ведёт себя как распределённая система, а распределённые системы требуют оркестровки, идентификации и дисциплины контекста, которые большинство компаний никогда не создавали. Масштабирование терпит неудачу из-за сложности задач, а не из-за количества агентов, и большинство команд вообще не управляют этой сложностью. Объедините десяток изолированных агентов без общих реестров или маршрутизации, и координация развалится на дублирование и расхождение.</p> <h3>Погоня проста — добыча дорога</h3> <p>Интерес есть повсюду. Масштабирование — редкость. Причины этого упорно остаются неизменными, и начинаются они с денег. Неопределённость рентабельности инвестиций загоняет амбиции предприятий в режим пилотного проекта, потому что большинство компаний не могут обосновать производственные выгоды за пределами узкого повышения эффективности. Пробелы в управлении приводят к разрастанию агентной сети. Более половины предприятий сообщают об этом даже после принятия NIST AI RMF, потому что документ с политикой не может контролировать автономную систему, использующую инструменты. А путаница с платформами замораживает обязательства, пока команды спорят о том, стоит ли делать ставку на SaaS-агента, систему, построенную системным интегратором, или на собственную разработку.</p> <p>В основе всего этого лежит налог доверия. Каждое автономное действие должно быть зафиксировано и обосновано аудитором, и сейчас эта стоимость слишком высока. Даже руководители это чувствуют. Банк Нью-Йорка находится на самом переднем крае как регулируемое предприятие, и он до сих пор не в полной мере ощутил на себе потенциал агентных систем. Но у него есть то, чего нет у большинства. Его сотрудники готовы управлять высокоавтономными агентами в условиях жесткого регулирования бизнеса. Эта готовность бесценна.</p> <h3>Управление рисками — это реальное ограничение</h3> <p>Это та часть, которую недооценивают руководители. Автономные системы, которые действуют непрерывно, преодолевая границы, которые человек не может отслеживать в режиме реального времени, одновременно многообещающи и опасны. В исследовании Forrester «Security Survey 2026» 49% лиц, принимающих решения в области безопасности, назвали агентный ИИ проблемой. Эти угрозы носят новый характер, а не только масштаб. Агенты могут выдавать себя друг за друга и повышать свои привилегии, потому что идентификация нечеловеческих объектов все еще находится в запутанном состоянии. Их численность растет быстрее, чем кто-либо может за ней уследить, и когда нарушается координация, небольшая ошибка в оценке приводит к сбою.</p> <p>Безопасности нельзя добиться ежеквартальными обзорами. Управление осуществляется с помощью инструментов, работающих параллельно с агентом, при этом идентификация и политики обеспечиваются в виде кода, а не прописаны и рассчитаны на желаемый результат.</p> <h3>Как начать двигаться вперед</h3> <p>Компании, которые опережают конкурентов, — это не те, у кого больше всего агентов. Это те, кто прокладывает путь, по которому будет двигаться поезд. Три шага наиболее важны:</p> <ul> <li><strong> Инвестируйте в оркестровку, прежде чем добавлять агентов.</strong> Общие реестры и схемы передачи задач имеют решающее значение для того, чтобы агенты и традиционные системы работали как единое целое.</li> <li><strong> Перепроектируйте работу, а не только инструменты. </strong>Агенты, прикрученные к устаревшим рабочим процессам, работающим в ручном темпе, обеспечивают экономию задач, а не кардинальные изменения. Выберите несколько рабочих процессов с высокой степенью сложности и перестройте роли и утверждения вокруг автономности.</li> <li><strong> Рассматривайте каждого агента как управляемую идентичность.</strong> Предоставьте ему уникальные учетные данные, принцип наименьших привилегий, полное логирование и именованного владельца, который управляет его жизненным циклом. Никакой бесконтрольной автономности.</li> </ul> <p>Затем масштабируйте поэтапно. Начните с ограниченных задач с путями утверждения и отката. Расширяйте автономию только тогда, когда это оправдано надлежащими средствами управления.</p> <p>Поезд движется, и быстро. Теперь вопрос только в том, направляется ли он туда, куда вы хотите.</p> Три четверти руководителей предприятий сообщают, что они внедряют агентный искусственный интеллект. Но лишь небольшое … article https://www.itweek.ru/themes/detail.php?ID=234967 Mon, 08 Jun 2026 08:33:00 +0300 <p>Страхование долго развивалось как отрасль, которая подключается после наступления события: аварии, болезни, повреждения имущества, кибератаки или перерыва в деятельности компании. Логика проста: клиент покупает полис, страховщик оценивает риск, а затем компенсирует ущерб, если страховой случай произошел. Искусственный интеллект постепенно меняет эту модель. Страховая компания становится не только плательщиком по факту убытка, но и начинает быть участником системы прогнозирования, профилактики и раннего реагирования.</p> <p>Этот сдвиг уже заметен на международном рынке. <a href="https://www.mckinsey.com/industries/financial-services/our-insights/the-future-of-ai-in-the-insurance-industry">McKinsey</a> отмечает, что ИИ применяется почти во всех ключевых зонах страхового бизнеса: продажах, персонализации, андеррайтинге, урегулировании убытков, клиентском сервисе и бэк-офисе. По оценке <a href="https://www.eiopa.europa.eu/publications/traditional-ai-generative-ai-implications-insurance-sector_en">EIOPA</a>, в Европе технологии ИИ уже используют 50% страховщиков non-life-сегмента и 24% страховщиков life-сегмента. Отечественный рынок — в той же практической повестке: <a href="https://www.cbr.ru/Content/Document/File/185193/Consultation_Paper_20112025.pdf">по данным опроса Банка России 2025 года</a>, 60% страховщиков сообщили об использовании ИИ на постоянной основе. Поэтому вопрос для отрасли постепенно смещается с «нужен ли ИИ» к «где он реально меняет экономику риска, сервиса и урегулирования».</p> <h3>Андеррайтинг становится точнее</h3> <p>Одна из первых зон, где ИИ дает заметный эффект, — оценка риска. В классической модели андеррайтер работает с заявкой, историей клиента, документами, правилами и экспертными допущениями. Сегодня к этому добавляются модели, которые могут анализировать большие массивы структурированных и неструктурированных данных: документы, изображения, историю убытков, внешние факторы, поведенческие признаки.</p> <p>По данным <a href="https://www.capgemini.com/news/press-releases/insurance-leaders-optimistic-about-ais-impact-on-underwriting-quality-and-fraud-reduction-but-underwriter-confidence-lags/">Capgemini</a>, 62% руководителей страховых компаний считают, что искусственный интеллект и машинное обучение повышают качество андеррайтинга и помогают снижать мошенничество. Однако только 43% андеррайтеров регулярно доверяют автоматическим рекомендациям predictive analytics. Это важная метрика: потенциал уже очевиден, но страхование все еще остается отраслью, где решение должно быть объяснимым, проверяемым и профессионально интерпретируемым.</p> <p>При этом отмечу, что сам ИИ не отменяет роль андеррайтера, а меняет ее. Специалист меньше времени тратит на сбор и первичную обработку информации и больше — на оценку сложных случаев, исключений и нестандартных рисков. <a href="https://www.munichre.com/ca-life/en/perspectives/2024/large-language-models-in-underwriting-and-claims.html">Munich Re</a> отдельно отмечает потенциал больших языковых моделей в работе с неструктурированными данными: медицинскими заключениями, описаниями убытков, договорами, правилами страхования и внутренними регламентами.</p> <h3>Урегулирование убытков ускоряется</h3> <p>Вторая большая зона трансформации — управление урегулированием страховых случаев (claims management). Для клиента это — один из важнейших и самых щепетильных моментов: именно здесь страховая компания либо подтверждает свою ценность, либо разрушает доверие.</p> <p>ИИ помогает автоматизировать первичную обработку заявлений, распознавать документы, классифицировать обращения, проверять комплектность пакета и извлекать данные из актов, счетов, справок, фотографий и медицинских заключений. <a href="https://www.bcg.com/publications/2023/the-future-of-insurance-claims">BCG</a> пишет, что генеративный ИИ может применяться для оценки повреждений, выявления мошенничества, обработки обращений, поддержки сотрудников и получения аналитических выводов на основе данных.</p> <p><a href="https://www.cnews.ru/news/line/2024-10-17_alfastrahovanie_ureguliruet">АльфаСтрахование сообщает</a>, что ИИ помогает закрывать значительную часть обращений по ОСАГО без ручной обработки: около 60% таких кейсов компания урегулирует автоматически, а в Московском регионе этот показатель приближается к 70%.</p> <h3>Антифрод становится технологической гонкой</h3> <p>Страховое мошенничество всегда было одной из ключевых проблем отрасли, но генеративный ИИ сделал ее сложнее. С одной стороны, алгоритмы помогают страховщикам выявлять подозрительные сценарии: повторяющиеся паттерны убытков, связи между участниками, аномальные суммы, несоответствия в документах и изображениях. С другой — те же технологии дают злоумышленникам новые инструменты.</p> <p><a href="https://www.swissre.com/institute/research/sonar/sonar2025/how-deepfakes-disinformation-ai-amplify-insurance-fraud.html">Swiss Re</a> указывает, что дипфейки, сгенерированные документы и дезинформация усиливают риски страхового мошенничества и повышают нагрузку на операционные процессы страховщиков. Поэтому антифрод постепенно превращается из проверки отдельного кейса в непрерывный анализ контекста: истории обращений, поведения клиента, цифровых следов, документов, изображений и связей между событиями.</p> <h3>Страхование становится персональным</h3> <p>ИИ меняет и сам страховой продукт. Раньше клиент чаще выбирал из нескольких стандартных программ. Теперь страховщик может точнее учитывать ситуацию человека или компании — от профиля риска и истории обращения до состояния объекта и особенностей бизнеса.</p> <p><a href="https://insuranceblog.accenture.com/guide-generative-ai-insurance">Accenture</a> видит один из главных потенциалов генеративного ИИ в андеррайтинге, дистрибуции и урегулировании. Компания также отмечает, что значительная часть времени андеррайтеров уходит на административные задачи, которые можно автоматизировать или усилить с помощью ИИ. Для клиента это может означать более точный тариф, более релевантное покрытие, быстрый сервис и профилактические рекомендации.</p> <p>Именно здесь страхование начинает смещаться от модели «постфактум» к профилактической. В автостраховании это может быть анализ стиля вождения и рекомендации по снижению аварийности. В ДМС — более точная маршрутизация к специалистам и управление медицинскими программами. В корпоративном страховании — анализ структуры убытков и рекомендации по снижению операционных рисков.</p> <h3>ИИ меняет работу сотрудников</h3> <p>Отдельный пласт изменений связан с «внутренней кухней» страховых компаний. ИИ-ассистенты могут помогать операторам, агентам, андеррайтерам и специалистам по убыткам: искать информацию в базе знаний, готовить ответы, суммировать документы, подсказывать следующий шаг и проверять комплектность данных.</p> <p>Но масштабирование таких решений упирается не только в технологию. <a href="https://www.deloitte.com/us/en/insights/industry/financial-services/scaling-gen-ai-insurance.html">Deloitte</a>, опросив 200 руководителей страховых компаний в США, отмечает, что 76% уже внедрили генеративный ИИ в одной или нескольких функциях. При этом среди барьеров остаются качество данных, устаревшая ИТ-инфраструктура, управление рисками и недостаточная связка между бизнесом и технологиями.</p> <p>Подобные выводы мы фиксировали и в собственном исследовании экономики страховых процессов: 83,3% респондентов назвали сбор и интеграцию данных из информационных систем одной из основных сложностей внедрения аналитических инструментов. Это важный барьер и для ИИ-проектов: ассистенту недостаточно просто «подключиться» к рабочему месту сотрудника, ему нужны качественные данные, понятная логика процесса и корректно связанные системы.</p> <p>Почему это важно в страховании? Здесь много регламентов, исключений, документов и чувствительных клиентских ситуаций. Роль сотрудника становится более экспертной.</p> <h3>Почему страхованию нужен осторожный ИИ</h3> <p>Страхование — щепетильная отрасль. Ошибка алгоритма может повлиять на стоимость полиса, доступность продукта, решение по выплате или качество клиентского сервиса. Поэтому вместе с ИИ растут требования к управлению моделями.</p> <p>Поэтому главный вопрос для страховщика сегодня не только «где внедрить ИИ?», но и «как подготовить бизнес к этому шагу?». Без качественных данных, понятных процессов, предварительной аналитики и прозрачной логики технология может не ускорить развитие компании, а масштабировать ее старые ошибки.</p> <p>Здесь особенно важна предварительная диагностика: прежде чем автоматизировать процесс с помощью ИИ, нужно понять, как он фактически выполняется, где возникают отклонения, задержки и ручные доработки. <a href="https://infomaximum.ru/blog/process-task-mining-v-strvakhovanii?ysclid=mpf8c5r0oz440837045">В нашем исследовании 100% респондентов </a>указали, что используют аналитику бизнес-операций (Task Mining) для оценки себестоимости операций и выявления потенциала автоматизации, а 75% — для выявления операций с потенциалом роботизации и внедрения ИИ. Это показывает, что для страхового рынка предварительная аналитика становится способом выбрать участки, где ИИ действительно даст измеримый эффект.</p> <p>Страхование строится на доверии: клиент должен понимать, что его риск оценен справедливо, обращение рассмотрено корректно, а решение можно объяснить. Поэтому наиболее устойчивый эффект получат не те компании, которые быстрее всех внедрят отдельные ИИ-инструменты, а те, кто сумеет встроить их в систему управления данными, процессами и ответственностью.</p> <p>#IMAGE_234968#</p> Страхование долго развивалось как отрасль, которая подключается после наступления события: аварии, болезни, повреждения … article Александр Бочкин, генеральный директор “Инфомаксимум” https://www.itweek.ru/themes/detail.php?ID=234965 Fri, 05 Jun 2026 14:33:37 +0300 <p>Сейчас автоматизация процессов — это базовая задача для бизнеса, способ повысить конкурентоспособность и закрыть боли, связанные с неэффективностью исполнения этапов бизнес-процессов. Когда компания растет, процессов становится больше, они усложняются и теряют прозрачность: руководству сложнее понять, где возникают потери и почему, например, в одном месяце продажи оказались на 25% ниже, чем в другом.</p> <p>Но автоматизации процессов может быть недостаточно. Поэтому следующий шаг — повышение эффективности уже автоматизированных процессов, ведь даже в них остаются узкие места: где-то процесс замедляется из-за человеческого фактора, где-то по-прежнему требуется ручное участие.</p> <p>И вот здесь уже может быть полезен искусственный интеллект. Не как волшебная надстройка, которая сама исправит все проблемы, а как инструмент, который может заметно ускорить рутинные операции.</p> <h3>Три контура внедрения</h3> <p>Сегодня можно выделить три сценария внедрения ИИ для уже автоматизированных процессов.</p> <p><strong>Первый — ИИ, который уже встроен в платформу. </strong>В CRM (системах управления взаимоотношениями с клиентами) и low-code BPM (платформах для управления бизнес-процессами, которые позволяют создавать и настраивать решения без сложной разработки) вендоры зачастую из коробки дают возможность его использовать. То есть заказчик покупает систему, и внутри уже есть ИИ-функции.</p> <p>Плюс очевидный: не нужно привлекать дополнительную экспертизу для настройки, вводить еще одного вендора в ИТ-ландшафт, заключать отдельный договор, разворачивать отдельный продукт. Решение полностью лицензируется единой поставкой. Функций, скорее всего, будет ограниченное количество, но для старта этого часто достаточно.</p> <p><strong>Второй сценарий — это отдельно стоящие решения. </strong>Это те инструменты, которые идут не внутри платформы, а рядом с ней. Они, как правило, более функциональны по сравнению с встроенными и лицензируются дополнительно.</p> <p>Главная задача — «подружить» их с основной системой через интеграцию в нужных точках процесса. Это дороже, сложнее во внедрении и требует погружения в сам продукт. Но при этом и возможностей больше, потому что решение независимое, оно изначально не заточено под конкретную задачу, и его можно далее глубже настраивать под себя.</p> <p><strong>Третий — использование ИИ для настройки самих процессов. </strong>Такие инструменты уже есть в ряде российских платформ.</p> <p>Как это работает: пользователь в чате с ИИ-агентом может описать процесс, и система отрисует его в BPMN-нотации (стандарте моделирования бизнес-процессов), визуализирует схему, настроит атрибуты, карточки внутри системы, дополнительные параметры. Пользователь пишет: «добавь задачу согласования коммерческого предложения после его создания в системе», задача идет на коммерческого директора с двумя вариантами ответа — согласовать или отклонить. Сценарий можно сразу запустить на тест, с маршрутизацией и ответственными.</p> <p>По факту получается, что пользователю вместо <nobr>8-16</nobr> часов на настройку нужно потратить час-полтора на то, чтобы пообщаться с ИИ-агентом и получить уже готовый процесс, который останется только проверить и при необходимости скорректировать.</p> <h3>Сценарии, которые работают</h3> <p>У компании может быть несколько десятков поставщиков или даже тысячи. Каждый предлагает оборудование в разных конфигурациях, и под конкретный запрос менеджеру нужно собрать спецификацию: открыть прайс-листы, подобрать позиции, сопоставить параметры. Можно сделать это вручную — и потратить, например, час времени. А можно поставить задачу ИИ-агенту, и он за минуту отберет данные и сформирует готовый файл, который нужно только проверить и отправить. Тут ИИ дает самый очевидный эффект.</p> <blockquote> <p><em>При этом важно, что речь не про один-два сценария. ИИ встраивается практически в любой процесс, и количество таких решений по сути не ограничено.</em></p> </blockquote> <p>В BPM-системах можно строить модель оттока клиентов прямо на данных внутри системы. Или формировать саммари по заказу: система пробегается по лиду, сделке, позициям и выдает сводку: какая потребность, какая номенклатура, в какой бюджет нужно уложиться. Менеджер проверяет и нажимает «сохранить» — заказ создается автоматически.</p> <p>Другой пример — генерация писем. Система автоматически формирует письмо для клиента из карточки в системе, подтягивает актуальные цены, позиции, выстраивает структуру — приветствие, основную часть, CTA (call to action, призыв к действию). Получается двойной эффект: быстрее реакция и выше уровень коммуникации. Письмо можно отредактировать, отправить из системы или поставить задачу «напиши и отправь». За то же время менеджер может сделать не одно, а сразу десять писем.</p> <p>ИИ может работать не только на данных внутри системы, но и с внешними источниками. Допустим, нужно понять конкурентную среду по сделке по продаже оборудования. Раньше для этого приходилось идти в интернет и собирать информацию по разным сайтам. Сейчас внутри CRM можно задать запрос и получить сводку или сравнительный анализ по аналогичным предложениям на рынке.</p> <p>Существуют и точечные сценарии. Спросить у агента: «С кем согласовать скидку при таких условиях?» — он найдет ответ, даст ссылку. Это полезно, но эффект локальный.</p> <blockquote> <p><em>Системная ценность появляется тогда, когда ИИ встроен в процесс и работает на данных информационной системы.</em></p> </blockquote> <p>Представим ситуацию: новому менеджеру передают клиента, а он не знает контекста: о чем с ним ранее договаривались, какие были сделки. ИИ-ассистент может собрать как внешнюю информацию по клиенту, так и внутренние данные: какие сделки были, на какие суммы проходили оплаты, в чем был интерес, какие активности фиксировались, по каким каналам чаще шла коммуникация. В целом менеджер потратил бы на сбор и изучение контекста, к примеру, три часа. А с помощью ИИ-агента эту информацию можно получить за три минуты.</p> <h3>Почему этап пилота затягивается</h3> <p>Если ИИ так эффективен, почему компании не внедряют его массово? У заказчиков есть причины сомневаться.</p> <ul> <li> Неясно, насколько достоверные сведения возвращает агент. Все равно нужно перепроверять, отлаживать, смотреть, где он ошибается, где додумывает, где не так понял контекст.</li> <li> У ИИ есть склонность к «галлюцинациям» — он начинает додумывать, если теряет контекст. Значит, нужны дисциплина в работе с ним и дополнительные проверки. Это не отменяет пользы, но добавляет неопределенности.</li> <li> Непонятно, как будут меняться роли людей. Если все автоматизируется с помощью ИИ, что тогда будут делать сотрудники?</li> <li> Заказчики хотят увидеть уже доказанный эффект. Чтобы кто-то попробовал, получил результат и показал, что это действительно работает. Любая технология становится дешевле и понятнее, когда превращается в «коробочную» — кто-то уже внедрил, проверил, и дальше ее можно адаптировать под себя.</li> </ul> <p>Но при этом, чтобы развивать такие решения внутри компании, нужны компетенции. Это не та история, где можно просто взять и начать. Нужен отдельный человек, который понимает, как ставить задачу ИИ, как проверять результат и как встраивать его в существующие процессы.</p> <h3>Сначала процесс, потом ИИ</h3> <p>ИИ должен ложиться на хорошо отстроенный процесс: сначала его нужно проанализировать, осознать, оптимизировать, автоматизировать, чтобы появилась система, в которой ИИ сможет жить. И только потом уже имеет смысл добавлять ИИ.</p> <p>Почему это важно? Потому что такие решения работают на структурированных данных и на их объеме. Это хорошо видно на примере маркетплейсов. Они не случайно предлагают подборку «вам может подойти» — иногда предложения выглядят неожиданно точными, хотя человек, казалось бы, еще не покупал подобные товары. В ритейле такие модели используются давно — именно за счет накопленных данных.</p> <blockquote> <p><em>ИИ дает системный эффект только в том случае, если он накладывается на уже выстроенные процесс.</em></p> </blockquote> <p>Невозможно внедрить агента, который предлагает клиенту релевантный продукт для допродажи, если в системе нет накопленной базы знаний по сделкам. В простом примере: человек купил детское питание — сервис ему предлагает подгузники, что выглядит логично. Но в автомобильной отрасли, в продаже автозапчастей, взаимосвязи строятся уже неочевидно: их нужно «выучить» на данных.</p> <h3>ИИ не заменяет людей</h3> <p>С внедрением ИИ не идет речи о том, что люди станут не нужны. Речь про повышение продуктивности. Меньше рутины, больше задач, где действительно нужно участие человека: коммуникации с клиентами, работа с контрагентами, оптимизация процессов.</p> <p>Это хорошо видно, в том числе, по работе с low-code. Несмотря на упрощение настройки, человеческое участие никуда не девается. Все равно нужно осмыслить, что именно настраивается, и внести правки в результат работы искусственного интеллекта.</p> <blockquote> <p><em>ИИ не убирает человека из процесса, а усиливает его. Быстрее передаются в пилот решения, проверяются гипотезы, настраиваются процессы.</em></p> </blockquote> <p>С внедрением ИИ у заказчиков появляется новая роль — условно, специалист по настройке таких решений. В крупных компаниях, например в ритейле, формируются отдельные команды, которые анализируют процессы, ищут точки применения ИИ и с его помощью улучшают существующие системы. То есть автоматизация начинает восприниматься не просто как поддержка, а как инструмент постоянной оптимизации.</p> <h3>Результат против ожиданий</h3> <p>Модель работы постепенно меняется. Сейчас привычный формат — интерфейс: карточки, кнопки, поля. Дальше работа будет смещаться в сторону ассистентов — чата, где формулируется задача или задается вопрос, и сразу возвращается конкретный ответ, без дашбордов и ручной настройки фильтров.</p> <p>Ассистенты уже сейчас закрывают значительную часть задач. При текущем темпе внедрения через пару лет это станет рядовой практикой. При этом у вендоров разная зрелость встроенного ИИ, но направление у всех одно — массовость и тиражирование. Это формирует высокие ожидания от технологии.</p> <p>И здесь важно не подменять реальный эффект ожиданиями. ИИ действительно ускоряет процессы, но только там, где есть выстроенная логика, понятные регламенты и накопленные данные. В этих условиях он снимает рутину и дает измеримый результат. Если этого нет, он не решает проблему, а просто масштабирует те же самые ошибки.</p> <p>#IMAGE_234966#</p> Сейчас автоматизация процессов — это базовая задача для бизнеса, способ повысить конкурентоспособность и закрыть боли … article Светлана Ермакова, руководитель направления CRM и BPM, “Софтлайн Решения” (ГК Softline) https://www.itweek.ru/themes/detail.php?ID=234964 Fri, 05 Jun 2026 09:20:27 +0300 <p><em>Федеративная архитектура (</em><em>Federation</em> <em>Architecture</em><em>, </em><em>FA</em><em>) обеспечивает баланс преимуществ конвергенции ИТ-ОТ с мерами безопасности, одновременно снижая риски, связанные с искусственным интеллектом, и обеспечивая централизованное получение инсайтов, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Давуд Шахлаи, старший менеджер компании Belden.</em></p> <p>Разрозненные операции все чаще ограничивают эффективность, необходимую для современных рабочих нагрузок, и интеграция информационных технологических систем с операционными технологическими системами (конвергенция ИТ-ОТ) является решением этой проблемы.</p> <p>Однако полностью конвергентные архитектуры ИТ-ОТ создают профиль рисков, который многим операторам трудно обосновать. По мере ускорения внедрения ИИ этот риск становится более острым, особенно когда конвергенция создает точки соприкосновения автоматизации на границе ИТ и ОТ.</p> <p>Рабочие нагрузки, связанные с ИИ, подталкивают организации к конвергенции и увеличивают потребность в общей инфраструктуре, общих данных и централизованных инсайтах. В то же время ИИ создает междисциплинарный риск, который становится видимым только при совместном рассмотрении ИТ-безопасности, безопасности ОТ и рисков, возникающих в связи с ИИ.</p> <p>Задача состоит в том, чтобы обеспечить конвергенцию, не ставя под угрозу основы безопасности и управления в ОТ-средах.</p> <h3>Ценность конвергенции ИТ-ОТ</h3> <p>Конвергенция ИТ-ОТ иногда представляется как цель или неизбежная тенденция, но на самом деле это средство достижения цели. Она обеспечивает единый интеллект на всем инфраструктурном стеке и площадках. Частое преимущество заключается в устранении слепых зон.</p> <p>Когда сигналы об энергоснабжении, охлаждении и ИТ-системах доступны в едином представлении, операторы могут быстрее выявлять проблемы, затрагивающие разные области, например, сопоставляя неисправность системы охлаждения, влияющую на ряд серверов, с пиком задержки сети или снижением производительности ЦП.</p> <p>Помимо обеспечения видимости, конвергенция позволяет скоординированно оптимизировать процессы. При высокой плотности рабочих нагрузок, превышающей температурные пределы, ручное или изолированное управление питанием и охлаждением становится сложнее поддерживать.</p> <p>Сторонники конвергенции могут утверждать, что интегрированные системы могут способствовать более быстрой оперативной реакции и повышению эффективности, особенно когда инсайты и планирование из центрального командного центра охватывают несколько площадок. Однако сочетание конвергенции ИТ-ОТ с реалиями ОТ-среды остается сложной задачей и вызывает постоянные дискуссии.</p> <h3>Состояние дискуссий</h3> <p>Полная конвергенция не так широко распространена, как некоторые предполагают. Дискуссия ведется не о том, полезна ли централизованная видимость. Она о том, насколько корпоративные ИТ должны охватывать ОТ-системы, управляющие физическими процессами.</p> <p>Ключевая причина — структурное несоответствие между ИТ и ОТ. В то время как ИТ-инфраструктура оптимизирована для гибкости и частых изменений, ОТ-инфраструктура оптимизирована для детерминированного поведения, доступности и длительных жизненных циклов. Эти различия создают трения, когда ИТ-практики распространяются на ОТ-среды.</p> <p>Риск также асимметричен. Сбои в ИТ-инфраструктуре часто можно устранить путем восстановления и перестройки. Сбои в ОТ-инфраструктуре могут повредить физические активы и их сложнее устранить. ИТ-служба разрабатывает процесс реагирования на инциденты безопасности, предполагая, что нарушение может произойти, в то время как ОТ-служба инвестирует в предотвращение. Именно поэтому многие операторы рассматривают пути управления ОТ-инфраструктурой как серьезное архитектурное решение.</p> <p>В результате многие организации колеблются между двумя крайностями. Некоторые расширяют удаленные полномочия на объекты для повышения эффективности. Другие замораживают архитектуру, чтобы избежать расширения рисков. На практике конвергенция представляет собой спектр, и каждая организация ищет дисциплинированную золотую середину.</p> <p>Полная конвергенция продолжает обсуждаться по причинам, не связанным со злым умыслом. Развитие ИТ-инфраструктуры делает глубокую интеграцию неизбежной. Упрощение управления способствует созданию единой платформы, а рыночные стимулы поощряют интегрированные платформы. Некоторые площадки в конечном итоге имеют подключенные сети, но неизменные процессы, что может усилить проблемы безопасности и эксплуатации.</p> <p>Уже сейчас, еще до того, как этот спор утихнет, ИИ появляется как следующая переменная и повышает ставки.</p> <h3>Фактор ИИ</h3> <p>ИИ меняет модель угроз, поскольку он может работать внутри доверенных ИТ-сред с законным доступом и выдавать рекомендации, которые могут масштабироваться быстрее, чем люди могут реально контролировать.</p> <p>Это важно, потому что многие дискуссии о безопасности неявно предполагают, что ИИ остается «запертым» в дата-центрах и не может поворачивать ручки или включать/выключать рубильники в операционной инфраструктуре. Двусторонняя конвергенция ИТ-ОТ разрушает этот структурный барьер.</p> <p>ИИ стимулирует предиктивное техническое обслуживание, аналитику и оптимизацию, которые являются основными мотивами конвергенции. В то же время его профиль риска является недетерминированным и непрозрачным. ИИ может влиять на решения и автоматизированные действия через системы, которые рассматривают ИИ как доверенного участника.</p> <p>Системы ИИ статистически оптимизированы, но по своей природе несовершенны. ИИ может преследовать непредусмотренные цели, например, снижать энергопотребление на охлаждение за счет изменения температурных пределов способами, которые выглядят приемлемо на панелях управления, но снижают уровень безопасности. Эта динамика часто описывается как игра с прокси, проблема согласования или потеря контроля.</p> <p>В конвергентных архитектурах сетевые пути и механизмы автоматизации могут превращать аналитические задачи в оперативные команды. Это смещает границу безопасности с одних только сетей и устройств на модель ИИ, ее входные данные и управление тем, что происходит после выдачи рекомендации. Именно поэтому для перспективной модернизации необходим дисциплинированный подход: сохранение уровня безопасности операционных технологий при одновременном обеспечении возможности анализа и оптимизации с помощью ИИ.</p> <p>В центрах обработки данных есть одна особенность: ИИ, оптимизирующий охлаждение, может работать на той же инфраструктуре, которая зависит от этого охлаждения. Это делает ограничения и защитные механизмы первостепенной задачей проектирования.</p> <p>Первые эксперименты показывают, что ИИ может рекомендовать ограниченные действия, но только в сочетании с явными мерами безопасности и человеческим контролем.</p> <h3>Шаблон федеративной архитектуры</h3> <p>FA — это дисциплинированный способ конвергенции ИТ и ОТ без расширения поверхности управления, что операторам может быть трудно оправдать. FA не отвергает конвергенцию. Она переосмысливает ее, делая обязательным небольшой набор архитектурных обязательств и рассматривая любую более глубокую интеграцию как явное решение, требующее обоснования.</p> <p>FA построена на трех принципах:</p> <ol> <li> Автономия на периферии: каждое предприятие сохраняет способность к безопасной, детерминированной работе, даже если оно отключено от корпоративных или облачных систем.</li> <li> Однонаправленный поток данных: операционные данные поступают вверх для аналитики, а архитектурные пути записи в системы ОТ исключены по замыслу.</li> <li> Человеческий контроль: централизованные системы, включая ИИ, могут генерировать рекомендации, но квалифицированные инженеры должны санкционировать изменения до их внедрения.</li> </ol> <p>FA намеренно минимальна. Это набор архитектурных настроек по умолчанию, на основе которых можно безопасно строить другие проектные решения. Для некоторых организаций FA может стать моделью конвергенции, которую они выберут на долгосрочную перспективу. Для других это может быть промежуточным этапом, первым, более безопасным шагом через двустороннюю дверь для итеративного внедрения конвергенции.</p> <p>После внедрения FA организации могут анализировать результаты и либо откатываться назад с минимальными усилиями, либо выбирать контролируемые отклонения от однонаправленности в каждом конкретном случае, не ослабляя автономность периферии или человеческий контроль.</p> <p>Жизнеспособным примером реализации второго принципа может быть разрешение обновлений ПО в контролируемые временные окна для определенных разделов инфраструктуры.</p> <p>FA служит прагматичным вариантом по умолчанию для организаций, стремящихся к получению междоменных инсайтов, избегающих постоянного удаленного управления и готовящихся к расширению интеграции ИИ.</p> <h3>FA: что вы сохраняете и чем жертвуете</h3> <p>Что вы сохраняете с FA:</p> <ul> <li> Полная видимость всего парка техники и централизованная аналитика с использованием телеметрии, передаваемой на север.</li> <li> Обнаружение аномалий, предиктивное техническое обслуживание и обоснованное планирование и составление графиков.</li> <li> Цифровые двойники и моделирование, поддерживающие более безопасные решения об изменениях.</li> <li> Системы рекомендаций, ориентированные на данные.</li> <li> Перспективная и дисциплинированная стратегия, влияющая на модернизацию всей организации.</li> </ul> <p>FA совместима с тем, как владельцы критической инфраструктуры оценивают риски: сохранение видимости и поддержки принятия решений, а также ограничение того, что может напрямую влиять на физические системы.</p> <p>С точки зрения FA, изолированные (air-gapped) площадки могут удовлетворять двум основным принципам: автономность на периферии и человеческий контроль. Для таких площадок добавление восходящего потока данных обеспечивает аналитическую ценность по разумной цене.</p> <p>Чем вы жертвуете с FA:</p> <ul> <li> Скорость удаленного управления и непрерывная оптимизация парка техники.</li> <li> Удобство постоянного двустороннего подключения.</li> <li> Полностью автоматизированное реагирование между площадками в замкнутом цикле.</li> </ul> <p>Для организаций, которые оптимизировали операционные расходы за счет централизации, эти компромиссы снижают ключевые показатели эффективности. Для тех, кто вложил значительные средства в локальные ресурсы и персонал, влияние незначительно.</p> <p>FA в первую очередь не увеличивает затраты на технологии. Она перераспределяет затраты с централизованной эффективности на локальную ответственность. Организации, которые уже работают с полномочиями на уровне площадки, воспринимают FA как дополнительные капитальные затраты. Организации, оптимизированные для сокращения централизованных операционных затрат, воспринимают FA как структурное увеличение операционных расходов. FA предоставляет организациям возможность платить либо операционными возможностями, либо архитектурным риском.</p> <p>Некоторые организации уже могут быть глубоко вовлечены в двустороннюю конвергенцию. Они могут управлять рисками и использовать оптимизацию замкнутого цикла.</p> <p>То же самое не всегда верно для других критически важных сред, где последствия могут быть физически серьезными. Для них гарантированное отсутствие путей управления может даже стимулировать конвергенцию в стиле FA, поскольку утечка данных больше не приравнивается к нарушению систем управления.</p> <h3>Дисциплинированный подход к конвергенции</h3> <p>FA использует аналитические преимущества конвергенции ИТ-ОТ, а также ИИ, сохраняя при этом локальное управление и явное определение рисков, обеспечивая дисциплинированную основу для модернизации в критически важных средах. Отдавая приоритет автономности на периферии, однонаправленному потоку данных и человеческому контролю, FA обеспечивает структуру, соответствующую осторожному характеру критической инфраструктуры.</p> <p>Поскольку ИИ продолжает менять операционные ландшафты, внедрение дисциплинированного подхода, такого как FA, гарантирует, что организации смогут модернизироваться без ущерба для безопасности или контроля. Будь то долгосрочная стратегия или промежуточный шаг, FA позволяет предприятиям уверенно ориентироваться в сложностях конвергенции.</p> Федеративная архитектура (Federation Architecture, FA) обеспечивает баланс преимуществ конвергенции ИТ-ОТ с мерами … article https://www.itweek.ru/themes/detail.php?ID=234962 Fri, 05 Jun 2026 08:51:24 +0300 <p><em>И</em><em>зменения в законодательстве о закупках постепенно формируют новую архитектуру рынка IT-оборудования. Национальный режим, требования к локализации и новая система отчетности меняют не только правила участия в тендерах, но и саму экономику отрасли.</em><em> Рассмотрим</em><em>, почему закупки становятся инструментом промышленной политики и какие компании выиграют в новой модели рынка.</em></p> <p>Еще несколько лет назад рынок государственных закупок IT-оборудования жил в режиме постоянных регуляторных изменений. Появлялись новые ограничения, выходили разъяснения ведомств, корректировались постановления. Участникам рынка приходилось почти ежегодно адаптироваться к новым правилам.</p> <p>Регулирование национального режима становится более унифицированным, хотя подзаконная настройка и практика применения продолжают развиваться. Базовая механика закупок сохранилась, но существенно изменился комплаенс-контур допуска товаров и подтверждения происхождения. Изменилась логика формирования спроса и предложения. Национальный режим в меньшей степени воспринимается как совокупность разрозненных защитных мер, а превращается в инструмент, который задает правила развития рынка и влияет на формирование требований к локализации и происхождению радиоэлектронной продукции. В результате закупка IT-оборудования все чаще рассматривается не как разовая поставка, а как часть более долгосрочной промышленной политики. По сути, мы наблюдаем не очередную волну регулирования, а структурную перезагрузку рынка. Закупочная система все заметнее используется как инструмент реализации технологической и промышленной политики.</p> <h3>Архитектурная перестройка регулирования и новая роль закупок</h3> <p>Ключевой структурный сдвиг связан с тем, что национальный режим получил единое законодательное оформление. Изменения, внесенные законом № <nobr>318-ФЗ,</nobr> закрепили единый рамочный подход к национальному режиму в <nobr>44-ФЗ</nobr> и <nobr>223-ФЗ.</nobr> Если раньше регулирование строилось на отдельных постановлениях и разъяснениях, то теперь базовая логика закреплена на уровне федерального закона.</p> <p>В рамках этой модели применяются запрет, ограничение и преимущество в отношении отечественной продукции. Прикладные механизмы при этом формируются через подзаконные акты правительства, включая постановление № 719, которое устанавливает критерии и условия подтверждения производства российской промышленной продукции, включая требования к технологическим операциям. В совокупности эта система перестает быть набором отдельных ограничений и превращается в полноценную архитектуру регулирования доступа продукции к государственным закупкам.</p> <p>На этом фоне меняется и сама роль закупочной системы. Государство начинает управлять не формой торгов, а структурой спроса. Через такие инструменты, как постановление № 1875, требования к локализации, отраслевые реестры продукции и специальные режимы для программного обеспечения, формируется детализированная модель допуска продукции к закупкам. В результате закупка становится не просто процедурой выбора поставщика, а инструментом реализации промышленной политики, через которую государство стимулирует локализацию и развитие технологических цепочек. А когда закупки начинают выполнять эту функцию, они формируют и новый тип спроса на рынке.</p> <h3>Якорный спрос и новая модель конкуренции</h3> <p>Когда государство начинает управлять структурой спроса через закупки, на рынке формируется предсказуемый внутренний спрос. Одним из механизмов стала обязательная отчетность по закупкам российских товаров в рамках <nobr>223-ФЗ.</nobr> Данные из реестров договоров позволяют измерять долю отечественной продукции и оценивать эффективность национального режима.</p> <p>Импортозамещение в этой модели перестает быть декларацией и становится системой измеримых показателей. При применении «защитных мер» национального режима ограничена замена российского товара иностранным на стадии исполнения контракта. Это закрепляет долгосрочную логику выбора технологических решений. А значит меняются и правила конкуренции на рынке.</p> <p>Цена перестает быть единственным фактором. В ряде сегментов возрастает значение регуляторной исполнимости поставки наряду с ценой. Выигрывает не тот, кто дешевле привез оборудование, а тот, кто способен гарантировать его происхождение, локализацию, исполнение контракта и сопровождение в течение всего жизненного цикла. Механизмы вроде <nobr>15-процентного</nobr> преимущества для российской продукции в рамках <nobr>223-ФЗ</nobr> дополнительно усиливают эту логику.</p> <h3>Ужесточение требований и рост барьеров входа</h3> <p>Одновременно с изменением модели конкуренции заметно ужесточаются требования к участникам рынка. Для поставщиков IT-оборудования ключевыми становятся риски, связанные не столько с самой поставкой, сколько с подтверждением соответствия продукции регуляторным требованиям.</p> <p>Прежде всего это касается происхождения товаров и глубины локализации. Сегодня недостаточно просто заявить российское происхождение продукции — необходимо документально подтвердить цепочку операций, наличие записи в реестре и соответствие установленным требованиям. Любые разрывы в цепочке поставок, несоответствие заявленной локализации или ошибки в документах могут привести к риску отклонения заявки или проблемам на этапе исполнения контракта. Существенно возрастает и роль комплаенса, поскольку поставщик должен обеспечивать регуляторную корректность всей сделки на протяжении всего жизненного цикла контракта.</p> <p>Повышаются требования и к заказчикам. Если раньше достаточно было формально принять указанные в заявке сведения, то теперь заказчик обязан проверять их достоверность: сопоставлять реестровые записи, подтверждать происхождение продукции и контролировать соответствие закупаемого товара заявленным характеристикам.</p> <p>Показательным примером такой логики является контур гособоронзаказа. В рамках регулирования по <nobr>275-ФЗ</nobr> требования к дисциплине исполнения доведены до максимума: расчеты ведутся через отдельные счета, участники кооперации обязаны вести раздельный учет по каждому контракту, а взаимодействие всех участников цепочки находится под постоянным контролем. Эта модель хорошо показывает общий тренд рынка — рост прозрачности, финансовой дисциплины и управляемости кооперации.</p> <p>Такая система требований неизбежно повышает барьеры входа на рынок. Простая модель дистрибуции постепенно уступает место более сложной системе, где ключевое значение имеют управляемость поставок, подтверждаемая локализация и способность выстраивать устойчивые кооперационные цепочки. Именно поэтому следующей закономерностью становится консолидация рынка.</p> <h3>Консолидация рынка и смена роли игроков</h3> <p>Ужесточение требований постепенно меняет структуру самого рынка. Когда растут требования к комплаенсу, финансовой дисциплине, контролю кооперации и сопровождению контрактов, работать в этой системе становится сложнее. Необходимость подтверждать происхождение продукции, управлять цепочками поставок и обеспечивать исполнение контрактов на протяжении всего жизненного цикла требует более зрелых процессов и ресурсов.</p> <p>В этих условиях естественным образом усиливается консолидация рынка. Компании, которые не готовы работать в новой регуляторной логике, постепенно уходят с него или переходят в нишевые сегменты. Одновременно усиливаются позиции игроков, способных выстраивать устойчивые производственные и сервисные цепочки.</p> <p>Меняется и сама роль участников рынка. Модель простого дистрибьютора, который закупает оборудование и перепродает его заказчику, постепенно теряет устойчивость. На первый план выходит другой тип игрока — инфраструктурный интегратор, который не только поставляет оборудование, но и обеспечивает его соответствие требованиям национального режима, управляет кооперацией, сервисом и исполнением контракта. Эти изменения уже формируют новую устойчивую модель рынка.</p> <h3>Необратимость новой модели рынка</h3> <p>Важно понимать, что происходящие изменения носят не временный характер. Они закреплены не только на уровне отдельных постановлений, но и в самой законодательной архитектуре регулирования.</p> <p>Национальный режим зафиксирован в нормах федеральных законов, дополнен системой подзаконных актов и поддержан механизмами контроля и отчетности. Постановления с перечнями продукции, требования к подтверждению происхождения, минимальные доли закупок и другие инструменты формируют устойчивую систему регулирования.</p> <p>В результате формируется новая конфигурация рынка. Внутренний спрос становится более управляемым, локализация — измеримой, а конкурентоспособность компаний все больше определяется их способностью соответствовать промышленной политике государства и обеспечивать полный жизненный цикл решений. Именно эта логика и будет определять развитие рынка государственных закупок IT-оборудования в ближайшие годы. Именно поэтому для участников рынка возникает стратегический вопрос — как работать в этой новой системе правил.</p> <h3>Новые правила игры для участников рынка</h3> <p>В новой конфигурации рынка меняется и сам подход к регуляторике. Ее уже нельзя воспринимать исключительно как ограничение или административную нагрузку. По сути, она становится одним из ключевых факторов, определяющих стратегию развития бизнеса.</p> <p>Сегодня именно требования законодательства формируют рамку, внутри которой выстраиваются продуктовые линейки, кооперационные связи и цепочки поставок. Компании, работающие на рынке IT-оборудования, вынуждены учитывать требования к локализации, подтверждению происхождения продукции, включению в реестры и сопровождению контрактов на протяжении всего жизненного цикла. В результате регуляторная среда превращается в инструмент проектирования бизнеса: вокруг нее формируются инженерные компетенции, сервисная инфраструктура и модели долгосрочного партнерства между производителями, интеграторами и заказчиками.</p> <p>Национальный режим, требования к локализации и механизмы контроля уже закреплены на уровне законодательства и подзаконных актов. Эта модель будет постепенно развиваться и уточняться.</p> <p>Поэтому участникам рынка не стоит рассчитывать на возвращение к прежним условиям. Новая архитектура закупок уже сформирована и станет базовой рамкой для развития отрасли. Поэтому ключевой вопрос сегодня не в том, ослабнут ли требования. Ключевой вопрос — кто из игроков рынка сможет встроить свою стратегию в эту новую модель и использовать ее как точку роста.</p> <p>#IMAGE_234963#</p> Изменения в законодательстве о закупках постепенно формируют новую архитектуру рынка IT-оборудования. Национальный … article Сергей Семикин, СЕО компании “ГИГАНТ — Компьютерные системы” https://www.itweek.ru/themes/detail.php?ID=234961 Thu, 04 Jun 2026 16:10:30 +0300 <p>Компании все чаще рассматривают искусственный интеллект как функциональный слой, глубоко интегрированный в бизнес-процессы и ИТ-ландшафты. Этот сдвиг в 2026 году ведет к переходу от точечных внедрений к комплексным платформенным решениям и архитектуре, где ИИ становится неотъемлемой частью операционной деятельности. ИИ трансформируется в фундаментальный элемент корпоративной инфраструктуры. Владимир Лебедев, директор по развитию бизнеса M1Cloud, рассказал, что ИИ трансформируется в фундаментальный элемент корпоративной инфраструктуры.</p> <p>Мировой рынок ИИ достиг $371,71 млрд в 2025 году, и, по оценкам MarketsandMarkets, в 2026 году составит $601,93 млрд. В России рынок также демонстрирует интенсивную динамику. По данным Just AI и Onside, российский рынок генеративного ИИ по итогам 2025 года достиг 58 млрд рублей, что почти в 4,5 раза больше, чем в 2024 году. Прогнозируется, что к 2030 году этот показатель может достигнуть 778 млрд рублей. Такой рост свидетельствует об активном внедрении ИИ-технологий в отечественном бизнесе.</p> <p>Еще год-два назад внедрение ИИ в бизнесе часто носило характер пилотных проектов. Сегодня ИИ-модели используются для автоматизации операций, поддержки принятия решений, персонализации взаимодействия с клиентами и оптимизации производственных процессов. Однако по мере созревания технологий возникла потребность в более глубокой и системной интеграции. Это требует создания полноценной инфраструктуры, способной поддерживать жизненный цикл ИИ-систем: от обучения до развертывания, мониторинга и обеспечения безопасности.</p> <p>Переход к парадигме «ИИ как инфраструктура» означает не только техническую интеграцию, но и стратегическое изменение подхода к управлению и эксплуатации ИИ. Компании, успешно внедряющие ИИ на уровне инфраструктуры, получают значительные конкурентные преимущества, включая повышение операционной эффективности, ускорение инноваций и улучшение качества принимаемых решений.</p> <p>Однако несмотря на рост внедрения ИИ на предприятиях, существующая инфраструктура не всегда готова к обработке рабочих нагрузок. Это подчеркивает необходимость в специализированных решениях и платформах, которые могут обеспечить необходимую производительность, масштабируемость и безопасность.</p> <p>С расширением применения ИИ и его интеграцией в критически важные корпоративные системы значительно возрастают риски кибербезопасности. Традиционные средства защиты оказываются недостаточными перед лицом новых, специфических угроз, нацеленных непосредственно на ИИ-модели и данные. Злоумышленники активно разрабатывают методы атак, использующие уязвимости в алгоритмах машинного обучения.</p> <p>По данным StormWall, в 2025 году число атак с участием ИИ-ботов в России увеличилось на 63% по сравнению с 2024 годом. Эти цифры подчеркивают острую необходимость в специализированных решениях для защиты ИИ.</p> <p>В ответ на эти вызовы зрелые сервис-провайдеры предлагают заказчикам комплексные решения для специализированной защиты ИИ-моделей от современных киберугроз на базе искусственного интеллекта. По информации экспертов M1Cloud, сервисы облачной ИИ-безопасности (AI Security) имеют специализированную архитектуру, ориентированную на реальные сценарии атак на ИИ, позволяя безопасно внедрять и эксплуатировать ИИ даже при работе с конфиденциальными данными. Сервисы облачной ИИ-безопасности обеспечивают защиту от prompt injection, data poisoning, model inversion и других специфических угроз, направленных на манипулирование или извлечение информации из ИИ-моделей, а также осуществляют непрерывный мониторинг работы ИИ-моделей, выявляя аномалии и риски и другие опции.</p> <p>ИИ как инфраструктура — это новая реальность корпоративного мира. Однако эти возможности сопряжены с новыми, сложными вызовами в области кибербезопасности. Сервис-провайдеры, предлагающие специализированные решения для защиты ИИ-моделей, играют ключевую роль в обеспечении безопасного и устойчивого развития ИИ-инфраструктуры. Только при условии надежной защиты компании смогут в полной мере реализовать потенциал искусственного интеллекта, превратив его в мощный двигатель роста и инноваций.</p> Компании все чаще рассматривают искусственный интеллект как функциональный слой, глубоко интегрированный в бизнес-процессы … message https://www.itweek.ru/themes/detail.php?ID=234960 Thu, 04 Jun 2026 16:09:21 +0300 <p>Компания по управлению онлайн-активами Руцентр запустила новую версию хостинг-платформы со встроенной защитой от кибератак уровня L7. Решение является собственной разработкой Руцентра и будет интегрировано во всю продуктовую линейку виртуального хостинга. Обновление затронет более 50 тысяч активных клиентов из сегмента крупного и среднего бизнеса и порядка 150 тысяч сайтов, размещенных на хостинговой платформе компании.</p> <p>Разработка Руцентра устанавливает новые стандарты безопасности на рынке хостинга. В основе решения — инфраструктурная архитектура с технологией интеллектуальной фильтрации трафика, которая сфокусирована на самом сложном классе атак уровня L7. Технология обеспечивает расширенную защиту с автоматической блокировкой SQL-инъекций, межсайтового скриптинга (XSS), подделки запросов (CSRF) и ботнетов. </p> <p>Вся фильтрация трафика будет происходить в контуре Руцентра, а не на мощностях владельцев сайтов. Если атаки на сетевом (L3) и транспортном (L4) уровнях традиционно отражаются силами операторов связи, то прикладной уровень (L7) обрабатывается на собственном серверном и сетевом оборудовании Руцентра. Кроме того, защиту уровня L7 хостинг-провайдеры обычно предлагают в качестве дополнительной услуги, а Руцентр интегрирует во всю линейку услуг виртуального хостинга на базовом уровне.</p> <p>С новой технологией Руцентра даже в экстренной ситуации сайт будет оставаться доступным без необходимости приобретения дополнительных сервисов и привлечения внешних специалистов. Подключение защиты осуществляется на уровне балансировщиков трафика — без перерыва в работе сайтов и почты. При DDoS-атаке владельцу онлайн-ресурса не потребуется менять настройки домена или хостинга: балансировщики автоматически перенаправляют трафик на очистку. </p> <p>«Традиционная модель, когда безопасный хостинг собирается из разрозненных опций, себя исчерпала. Клиент не должен быть экспертом по DDoS, WAF и бэкапам, чтобы защитить свой онлайн-проект, при этом под атаки сегодня попадают абсолютно все. Новая версия платформы Руцентра предлагает комплексную защиту всех уровней, от сетевого до прикладного, как единый стандарт. Это именно то, что мы называем безопасным хостингом по умолчанию — провайдер берет на себя фильтрацию трафика, а клиент получает гарантию, что его сайт будет работать даже во время массированной атаки», — прокомментировал Валентин Бостанов, руководитель департамента хостинга Руцентра.</p> <p>Новая тарифная линейка будет доступна для заказа с 4 июня. А для всех действующих клиентов Руцентра автоматический переход на новую платформу безопасного хостинга состоится 18 июня. При этом стоимость услуг уже оплаченного срока не изменится, новая тарификация применится только при очередном продлении услуги.</p> <p>Руцентр входит в число крупнейших российских хостинг-провайдеров, имеет лицензии ФСТЭК на техническую защиту конфиденциальной информации и лицензию ФСБ в области шифрования. Компания предоставляет услуги защищенного хостинга ФЗ-152 и хостинга для госсистем. Запуск нового сервиса становится очередным шагом компании по усилению продуктового портфеля в области информационной безопасности.</p> Компания по управлению онлайн-активами Руцентр запустила новую версию хостинг-платформы со встроенной защитой … message https://www.itweek.ru/themes/detail.php?ID=234959 Thu, 04 Jun 2026 16:06:48 +0300 <p>Крупный бизнес больше не рассматривает замену зарубежных ERP-систем как формальную ИТ-задачу. Компании реального сектора связывают такие проекты с устойчивостью операционной модели, управляемостью данных и снижением зависимости от зарубежной ИТ-инфраструктуры. На практике это приводит к тому, что компании выбирают разные модели развития ERP-ландшафта. К такому выводу пришли аналитики Axenix в исследовании «Российский ERP-рынок: траектории развития».</p> <p>Исследование показало, что российский рынок систем управления перешел к прагматичной трансформации. Одного лишь импортозамещения больше недостаточно для старта проектов. Сегодня бизнес инвестирует в изменения для снижения рисков, оптимизации затрат и повышения управляемости данных. Компании отказываются от универсальных стратегий, выбирая гибкие сценарии с учетом своей операционной готовности.</p> <p>Одни продолжают использовать зарубежные платформы с локальной поддержкой и собственными доработками. Другие переходят на российские продукты или развивают отдельные специализированные системы под конкретные бизнес-задачи. Российские подразделения международных компаний выделяют локальный ИТ-контур из глобальной системы, переносят данные и поддержку, но не всегда рассматривают этот этап как окончательное решение. Выбор подхода зависит от отрасли, зрелости процессов, качества данных и готовности бизнеса к изменениям.</p> <p>ERP остается центром корпоративной архитектуры, но сама модель таких систем меняется. Компании все чаще разделяют учетное ядро и специализированные контуры: ERP-ядро отвечает за финансы, учет, казначейство и базовые закупки, а отдельные системы закрывают производство, логистику, документооборот, аналитику, бюджетирование и отраслевые процессы. Такой подход снижает риск единовременной миграции, позволяет обновлять ИТ-ландшафт поэтапно и ускоряет изменения в специализированных контурах.</p> <p>При выборе ERP-платформы участники исследования обращают внимание прежде всего на то, понимает ли вендор практику больших внедрений: управление релизами, тестирование, поддержка, архитектурный надзор, документация, исправление дефектов, работа с критичными инцидентами. Не менее важны для заказчиков качество документации и наличие понятной дорожной карты развития. Одновременно компании оценивают способность системы работать под нагрузкой и в едином контуре с большим оргобъемом и массивами данных. Особое внимание уделяется технологическому стеку выбираемого решения. Российское происхождение ERP не гарантирует полной независимости, если инфраструктура продолжает работать на иностранных системах виртуализации или аналитических инструментах.</p> <p>Одним из самых сложных этапов ERP-трансформации остается работа с данными, которые часто становятся главным скрытым риском внедрения. По оценке Axenix, программу управления мастер-данными стоит запускать еще до миграции. Без очистки справочников, правил контроля качества данных и интеграций новая система унаследует старые проблемы.</p> <p>Исследование также зафиксировало, что ожидания «бесшовной» замены ERP без изменения процессов постепенно исчезают. Компании признают, что переход требует пересмотра организационной модели, подходов к управлению данными и внутренних процессов. Те, кто начинают такую подготовку заранее, проходят миграцию быстрее и с меньшими потерями времени и бюджета. </p> <p>«Российский ERP-рынок перестал жить логикой срочного импортозамещения. Компании начали оценивать не только происхождение платформы, но и способность решения обеспечивать устойчивость бизнеса на горизонте <nobr>5-10 лет.</nobr> Поэтому рынок движется в сторону гибких архитектур, поэтапной миграции и более прагматичного подхода к трансформации. В ближайшие годы рынок будет развиваться не вокруг одного доминирующего продукта, а вокруг способности поставщиков подтверждать надежность решений в реальных корпоративных сценариях», — прокомментировал Евгений Смирнов, эксперт по ERP компании Axenix.</p> <p>По прогнозу Axenix, в <nobr>2027-2028</nobr> годах рынок вряд ли придет к одному новому ERP-лидеру. Вероятнее закрепление гибридной модели: российское или импортонезависимое ядро, отраслевые контуры, собственные доработки, сильный слой данных и интеграций. </p> <p>Крупные компании будут переходить на российские решения поэтапно. Полная замена ERP-монолита одним проектом останется редкой из-за риска остановки критичных процессов, сложности данных и необходимости вовлекать бизнес на длительный срок.</p> <p>Российские платформы продолжат расти, но крупный бизнес будет требовать отраслевых шаблонов, подтвержденных нагрузочных тестов, архитектурного надзора и развития партнерской экосистемы.</p> <p>Исследование «Российский ERP-рынок: траектории развития» Axenix провела весной 2026 года. Аналитики компании изучили открытые отраслевые данные и провели серию интервью с представителями крупнейших российских компаний из промышленности, энергетики, транспорта, финансового сектора и машиностроения. </p> Крупный бизнес больше не рассматривает замену зарубежных ERP-систем как формальную ИТ-задачу. Компании реального сектора … message https://www.itweek.ru/themes/detail.php?ID=234958 Thu, 04 Jun 2026 16:04:07 +0300 <p>Банк ЗЕНИТ объявил о запуске кабинета налогоплательщика Автоматизированной упрощенной системы налогообложения на базе платформы Digital2SME от компании BSS. Автоматизированная упрощенная система налогообложения (АУСН) — это специальный налоговый режим, который предоставляет малому бизнесу преимущества:</p> <ul> <li>автоматический расчет налогов самим ФНС;</li> <li>отсутствие обязательных страховых взносов;</li> <li>ставки налогообложения: 8% с полученных доходов, либо 20% с разницы между доходами и расходами.</li> </ul> <p>На АУСН может перейти бизнес с численностью работников не более 5 человек и годовым доходом не более 60 млн рублей. Подробные условия опубликованы на сайте ФНС. </p> <p>АУСН от BSS — активно внедряемое на российском рынке промышленное коробочное решение, полностью прошедшее аккредитацию Федеральной налоговой службы. На сегодняшний день сервис успешно функционирует в девяти банках, включая Банк ЗЕНИТ. Еще несколько финансовых организаций находятся на финальной стадии внедрения.</p> <p>«Благодаря слаженному взаимодействию с командой BSS мы смогли запустить решение АУСН для клиентов Банк ЗЕНИТ всего за 3 месяца. Справедливый итог проделанной работы — удобный сервис для предпринимателей и признание банковского сообщества — премия FINAWARD’26, полученная банком «За инновации в цифровом взаимодействии бизнеса и государства», — отметил Дмитрий Дьяков, руководитель блока МСБ Банка ЗЕНИТ.</p> <p>Клиенты Банка ЗЕНИТ, подключившие кабинет налогоплательщика АУСН, получают:</p> <ul> <li>автоматическую передачу данных о доходах и расходах в ФНС напрямую из ДБО;</li> <li>расчет налога налоговым органом без необходимости подачи декларации;</li> <li>удобный мониторинг начислений и оплат в личном кабинете;</li> <li>интеграцию с кассовыми системами и бухгалтерскими сервисами;</li> <li>поддержку при переходе на новый режим и консультации по налоговым вопросам.</li> </ul> <p>«Для нас большая ценность, что Банк ЗЕНИТ доверил реализацию такого стратегически важного проекта команде BSS. АУСН — это не просто новый функционал, это инструмент, который помогает малому бизнесу сократить административную нагрузку и сфокусироваться на развитии. Наше решение, уже проверенное в реальных условиях и одобренное ФНС, позволяет банкам минимизировать риски и выводить сервис на рынок в предсказуемые сроки», — подчеркнула Юлия Савинова, руководитель направления по развитию цифровых продуктов Центра цифровых решений для бизнеса компании BSS.</p> Банк ЗЕНИТ объявил о запуске кабинета налогоплательщика Автоматизированной упрощенной системы налогообложения на базе … message https://www.itweek.ru/themes/detail.php?ID=234955 Thu, 04 Jun 2026 10:07:38 +0300 <p><em>Отслеживание производительности искусственного интеллекта имеет решающее значение. Однако традиционные ИТ-инструменты не справляются с этой задачей. CIO должны расширить свое видение и кругозор, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Ни один уголок современного предприятия не остается незатронутым ИИ. Но по мере расширения сценариев использования и резкого роста внедрения появляются трещины в развертывании этой технологии. CIO все чаще сталкиваются с трудностями в отслеживании того, что делают системы ИИ, кто их использует и как они работают.</p> <p>Во многих случаях CIO обнаруживают, что у них нет возможности отслеживать или измерять критически важные факторы, такие как дрейф модели, задержка, частота галюцинаций, снижение производительности, теневой ИИ и ухудшение результатов. Неудивительно, что по мере того, как системы ИИ принимают все более важные решения и обрабатывают критически важные действия, риски возрастают.</p> <p>«CIO уверены, что знают, как ИИ развертывается в их организации, но обычно они не могут сказать, как он на самом деле работает», — отмечает Арнаб Чакраборти, директор по ответственному ИИ компании Accenture.</p> <p>Согласно ИИ-индексу HAI 2026 Стэнфордского университета (на основе данных McKinsey), доля организаций, оценивших свою реакцию на инциденты, связанные с ИИ, как «отличную», снизилась с 28% в 2024 г. до 18% в <nobr>2025-м.</nobr> При этом 88% организаций сообщили об использовании ИИ как минимум в одной бизнес-функции, но менее 10% полностью масштабировали ИИ в какой-либо отдельной области.</p> <p>Вывод? В условиях быстро меняющегося пространства ИИ наблюдаемость имеет решающее значение. Однако ИИ требует принципиально иного подхода, чем традиционные ИТ-решения. «Для понимания повседневной производительности и управления рисками крайне важно мыслить шире традиционных ИТ-показателей», — считает Чакраборти.</p> <h3>Важность видимости производительности ИИ</h3> <p>Что отличает мониторинг ИИ от традиционного ИТ-мониторинга, так это непредсказуемость. Время безотказной работы, пропускная способность, коэффициенты использования и ошибки — показатели, которые лежат в основе ИТ — не отражают факторы и риски, характерные для ИИ. Это потому, что ИИ по своей природе является вероятностным. Одни и те же входные данные может давать совершенно разные выходные данные.</p> <p>Эти проблемы могут принимать самые разные формы. CIO, как правило, знают предполагаемое назначение систем ИИ, но им не хватает понимания точности, задержки, пользовательского интерфейса, затрат и рисков. Им также приходится бороться с проблемами дрейфа моделей, поведения агентов и теневого ИИ. К сожалению, ни один поставщик не создал инструмент, обеспечивающий наблюдаемость на всех уровнях ИИ.</p> <p>Проблема кроется в самом принципе работы ИИ. Это не единая модель с единственным результатом. ИИ обычно представляет собой набор компонентов: конвейеры данных, базовые модели, системы поиска, агенты и другие компоненты — все они взаимодействуют с людьми и рабочими процессами. Агентный ИИ вносит дополнительные риски. К ним относятся «каскадные ошибки, сбои интеграции, неясная ответственность и труднопредсказуемое поведение, возникающее при взаимодействии нескольких агентов в рамках рабочих процессов», — говорит Илана Голбин Блюменфельд, партнер по ответственному ИИ в PwC US.</p> <p>Неправильно откалиброванная политика поиска может исказить результаты в десятке последующих приложений. Дрейф векторной базы данных может проявляться в виде галлюцинаций в чат-боте. По мере того, как предприятия объединяют агентов для выполнения более длительных задач, количество потенциальных проблем увеличивается быстрее, чем появляются инструменты, предназначенные для мониторинга среды. «Это не просто линейный эффект, это эффект накопления», — отмечает Чакраборти.</p> <p>Часто эти проблемы остаются незамеченными в течение недель или месяцев — пока что-то внезапно не сломается. Это происходит потому, что уровень снижения производительности незаметен — до тех пор, пока он не проявится. «Если вы не вмешаетесь достаточно рано, через несколько дней вы можете внезапно оказаться в нежелательном положении», — говорит Грейс Тринидад, директор по исследованиям в области безопасности и доверия к ИИ в IDC.</p> <p>По ее словам, существующие панели мониторинга и инструменты безопасности не могут решить эту проблему. Большинство из них полагаются на оценки риска и рейтинги уверенности, которые недостаточны и совершенно непрозрачны применительно к ИИ. Фактически, две организации могут запускать идентичные модели и получать совершенно разные представления об одном и том же факторе риска. «Нет стандартизации того, что входит в оценку риска», — говорит она.</p> <h3>Как развивается мониторинг ИИ</h3> <p>Нельзя управлять тем, чего не видишь. Microsoft обнаружила, что 73% организаций выявили несанкционированные инструменты ИИ в своих сетях, однако только 28% имеют комплексные возможности мониторинга или блокировки. Исследование McKinsey «2026 AI Trust Maturity Survey» показало, что средний показатель зрелости организаций составляет 2,3 из 4, при этом только около трети достигли уровня зрелости 3 или выше в области стратегии, управления и контроля за агентным ИИ.</p> <p>«Одна из самых больших проблем для организаций заключается в том, что они по-прежнему отслеживают ИИ как традиционное ПО. Они видят, что инфраструктура ИИ работает, но не понимают, почему она выдает плохие или ненадежные результаты», — говорит Блюменфельд. ​​Часто организации разрабатывают процессы предварительной оценки рисков и сбора информации, которые не учитывают фактическое использование системы ИИ и то, как риски внутри приложения могут меняться. «Ключевым моментом является выбор инструментов, которые могут интегрироваться в мультиоблачных, мультимодельных и агентных средах ИИ», — отмечает она.</p> <p>Фактически, наблюдаемость ИИ быстро развивается в сторону полной видимости всего стека, а также более тонкого понимания поведения ИИ. В этом мире телеметрические данные отходят на второй план по сравнению с такими вещами, как семантическое сопоставление и интерпретация намерений, непрерывный мониторинг и аудит, представления и элементы управления, соответствующие ролям, и инструменты, которые более комплексно контролируют требования безопасности и регулирования. По словам Блюменфельд, эти инструменты должны охватывать управление, мониторинг инфраструктуры и видимость на уровне моделей.</p> <p>Надежный процесс обнаружения является основополагающим, считает Тринидад. Важно каталогизировать модели, агентов, владельцев, версии, контексты развертывания и журналы — предпочтительно в реестре ИИ. Имея четкое представление о том, что должны делать системы, и понимание того, что нужно изменить, предприятие может начать внедрять мониторинг во всю систему. С помощью этой информации CIO могут выявлять отклонения данных и моделей, снижение производительности, галюцинации, теневой ИИ и риски безопасности до того, как они вызовут проблемы или нанесут ущерб репутации.</p> <p>Многоуровневый мониторинг также требует автоматизированных механизмов защиты, отмечает Чакраборти. Это означает установление правильных пороговых значений для ключевых факторов, включая частоту галюцинаций, задержку, смещение, конфиденциальность, затраты, отклонения данных и моделей, соответствие нормативным требованиям и качество выходных данных. Также требуется правильное сочетание инструментов от гиперскейлеров и сторонних поставщиков для управления и измерения задач.</p> <p>Благодаря интегрированной плоскости управления — единому архитектурному слою, который собирает и отображает все сигналы — менеджеры и руководители из разных отделов могут видеть то, что действительно важно для них. Например, директор по управлению рисками видит пороговые значения рисков и нарушения, финансовый директор отслеживает потребление и стремительный рост затрат на облачные сервисы, руководитель отдела кадров видит влияние на персонал, а инженеры держат руку на пульсе вопросов аудита и объяснимости. «Это формирует вашу ДНК, почти как нервную систему для вашего ИИ», — говорит Чакраборти.</p> <h3>Куда движется наблюдаемость ИИ</h3> <p>«CIO следует рассматривать наблюдаемость ИИ как основной принцип проектирования, а не как нечто добавляемое после развертывания», — считает Блюменфельд. ​​Она также отмечает, что важно рассматривать наблюдаемость как межфункциональную инициативу, охватывающую ИТ, бизнес, управление рисками и соблюдение нормативных требований, а также внутренние аудиторские группы. «Отрасль выходит за рамки мониторинга отдельных моделей ИИ и переходит к мониторингу целых экосистем агентов, уровней оркестровки, конвейеров данных и автономных рабочих процессов», — говорит она.</p> <p>Если организации правильно учитывают эти параметры, они могут масштабировать ИИ быстрее и безопаснее, контролировать затраты даже при росте рабочей нагрузки, создавать безупречный аудиторский след и повышать доверие клиентов. По прогнозам Gartner, инвестиции в мониторинг больших языковых моделей к 2028 г. составят 50% от общего числа внедрений генеративного ИИ, по сравнению с 15% сегодня.</p> <p>Безусловно, наблюдаемость ИИ — это не дополнительный элемент, и он не следует стандартной формуле ИТ-инфраструктуры. Это фундаментальный элемент, который необходимо встроить в структуру ИИ. «Организации, которые с самого начала правильно подойдут к этому вопросу и инвестируют в развитие соответствующих возможностей, станут лидерами в эпоху ИИ», — считает Чакраборти.</p> Отслеживание производительности искусственного интеллекта имеет решающее значение. Однако традиционные ИТ-инструменты … article https://www.itweek.ru/themes/detail.php?ID=234952 Thu, 04 Jun 2026 09:38:41 +0300 <p>Практически каждая компания, которая развивает цифровой продукт, рано или поздно сталкивается с одним и тем же вопросом: формировать собственную команду тестирования или привлекать внешнего подрядчика. Еще несколько лет назад выбор был относительно очевидным — крупный бизнес предпочитал развивать внутренние компетенции, а стартапы чаще обращались к внешним командам. Сегодня ситуация стала сложнее. Рынок испытывает дефицит квалифицированных QA-инженеров, стоимость найма растет, а скорость вывода новых продуктов становится критическим фактором конкуренции.</p> <p>Поэтому вопрос «тестирование ПО in-house или аутсорсинг» уже нельзя рассматривать только через призму затрат. На первый план выходят качество продукта, контроль процессов, безопасность данных, доступность экспертизы и способность быстро масштабировать ресурсы. Ошибка при выборе модели может привести не только к перерасходу бюджета, но и к задержкам релизов, росту количества дефектов и снижению удовлетворенности пользователей.</p> <p>Разберем сильные и слабые стороны каждого подхода и посмотрим, в каких ситуациях они работают лучше всего.</p> <h3>Что такое тестирование in-house</h3> <p>Тестирование in-house предполагает, что внутренняя команда QA является частью компании и работает вместе с разработчиками, аналитиками и владельцами продукта. Такой подход обеспечивает высокий уровень контроля над процессами и позволяет тестировщикам глубоко понимать архитектуру системы, бизнес-логику и цели продукта.</p> <p>Главное преимущество модели — постоянная коммуникация между участниками разработки. Когда тестировщики находятся внутри команды, они быстрее получают информацию об изменениях, участвуют в обсуждении требований и могут выявлять риски еще до начала разработки. Особенно эффективно это работает в долгосрочных проектах, где продукт развивается годами.</p> <p>Кроме того, внутренняя команда часто становится носителем критически важных знаний о системе. Это особенно ценно для банковских платформ, медицинских сервисов, государственных информационных систем и других продуктов с повышенными требованиями к безопасности.</p> <p>Однако полностью внутренняя QA-команда уже не всегда является признаком зрелости: иногда она превращается в дорогой и медленно масштабируемый ресурс, если не подкреплена автоматизацией и внешней экспертизой.</p> <h3>Что такое аутсорсинг тестирования</h3> <p>Аутсорсинг тестирования — это передача задач по обеспечению качества специализированной внешней компании. Вместо формирования собственного отдела бизнес получает доступ к уже готовой команде специалистов, обладающих необходимой экспертизой и набором инструментов.</p> <p>Основное преимущество такого подхода — гибкость. Если компании необходимо быстро протестировать новый продукт, провести нагрузочные испытания или организовать автоматизацию тестирования, подрядчик может подключить нужных специалистов за считанные дни или недели.</p> <p>Например, многие финтех-стартапы на ранних этапах используют внешние команды QA, поскольку создание полноценного отдела тестирования требует значительных инвестиций. При этом бизнес получает доступ к инженерам, которые уже имеют опыт работы с похожими продуктами.</p> <p>Однако существуют и риски. Внешняя команда не всегда обладает глубоким пониманием продукта, а эффективность взаимодействия во многом зависит от качества коммуникации. Кроме того, появляются вопросы контроля процессов и безопасности данных, которые необходимо учитывать при выборе подрядчика.</p> <h3>Сравнение тестирования in-house и аутсорсинга тестирования</h3> <p>Когда обсуждается тестирование ПО in-house или аутсорсинг, руководители обычно сравнивают не только стоимость, но и влияние модели на качество продукта и скорость развития бизнеса.</p> <table> <tbody> <tr> <th> Критерий</th> <th> In-house-команда</th> <th> Аутсорсинг</th> </tr> <tr> <td> Стоимость</td> <td> Высокие постоянные расходы</td> <td> Гибкие затраты по мере необходимости</td> </tr> <tr> <td> Контроль качества</td> <td> Максимальный контроль процессов</td> <td> Контроль через KPI и SLA</td> </tr> <tr> <td> Скорость запуска</td> <td> Требуется время на найм</td> <td> Быстрое подключение специалистов</td> </tr> <tr> <td> Безопасность данных</td> <td> Более высокий уровень контроля</td> <td> Требуются дополнительные меры защиты</td> </tr> <tr> <td> Масштабируемость</td> <td> Ограничена кадровым ресурсом</td> <td> Быстрое расширение команды</td> </tr> <tr> <td> Экспертиза</td> <td> Зависит от сотрудников компании</td> <td> Доступ к специалистам разных профилей</td> </tr> </tbody> </table> <p>На практике многие компании используют не один критерий, а целый набор факторов.</p> <p>Для одних критична скорость запуска проекта, для других — контроль качества или требования регуляторов к безопасности.</p> <h3>Стоимость и бюджет</h3> <p>При формировании собственного QA-отдела компания несет фиксированные расходы: заработные платы, налоги, обучение сотрудников, лицензии на инструменты и затраты на подбор персонала. В условиях дефицита кадров стоимость найма опытных специалистов может оказаться существенной статьей бюджета.</p> <p>Аутсорсинг позволяет перевести часть расходов в переменные затраты. Компания платит только за необходимые ресурсы и может масштабировать команду по мере изменения нагрузки. Именно поэтому на старте проектов внешняя модель часто оказывается экономически привлекательнее.</p> <p>Согласно исследованиям рынка ИТ-аутсорсинга, около двух третей компаний передают внешним подрядчикам хотя бы часть технологических функций. При этом тестирование программного обеспечения остается одним из самых востребованных направлений. Для многих организаций причиной становится не только экономия, но и возможность быстрее получить специалистов необходимого уровня.</p> <p>По оценкам ряда отраслевых исследований, использование внешних QA-команд позволяет сократить расходы на тестирование на <nobr>30-70%</nobr> в зависимости от модели сотрудничества и структуры проекта. Дополнительным преимуществом становится возможность оперативно наращивать ресурсы под конкретные задачи без длительного процесса найма.</p> <h3>Контроль качества и процессов</h3> <p>Одна из главных причин создания внутренних QA-команд — желание сохранить полный контроль над качеством продукта. Руководители могут напрямую влиять на процессы тестирования, стандарты работы и приоритеты команды.</p> <p>При работе с подрядчиком часть контроля неизбежно передается внешней стороне. Это не означает снижение качества, но требует четко сформулированных требований, понятных KPI и прозрачной системы отчетности. Чем подробнее описано техническое задание и ожидания бизнеса, тем эффективнее будет сотрудничество.</p> <p>Хорошим примером здесь выступает банковский сектор. По данным World Quality Report, финансовые организации направляют на QA и тестирование около трети всего бюджета разработки. При этом значительная часть критически важных систем продолжает тестироваться внутренними командами. Причина проста: ошибки в платежной инфраструктуре или системах дистанционного обслуживания могут стоить компании не только денег, но и репутации.</p> <h3>Безопасность данных и конфиденциальность</h3> <p>Для компаний, работающих с финансовой информацией, медицинскими данными или персональными сведениями пользователей, вопросы безопасности нередко становятся решающим фактором.</p> <p>Внутренняя команда позволяет минимизировать риск утечки информации и лучше контролировать доступ к критически важным данным. Поэтому банки, страховые компании и государственные структуры часто делают выбор именно в пользу модели in-house.</p> <p>Если же используется аутсорсинг, необходимы дополнительные меры защиты: соглашения о неразглашении, аудит безопасности подрядчика, сегментация доступа и контроль действий специалистов в рабочих средах.</p> <p>Важно понимать, что сегодня вопрос безопасности зависит не столько от формата сотрудничества, сколько от зрелости процессов. Многие крупные аутсорсинговые компании проходят сертификацию по международным стандартам информационной безопасности и работают с требованиями, сопоставимыми с внутренними корпоративными политиками крупных заказчиков.</p> <h3>Коммуникация и взаимодействие</h3> <p>Даже лучшие специалисты не смогут эффективно работать без качественной коммуникации. Внутренняя команда находится в едином информационном пространстве с разработчиками и аналитиками, что ускоряет принятие решений и снижает количество недопониманий.</p> <p>При аутсорсинге могут возникать сложности, связанные с часовыми поясами, различиями в корпоративной культуре и языковыми барьерами. Особенно заметно это становится на сложных проектах с быстро меняющимися требованиями.</p> <p>Однако практика показывает, что правильно организованные процессы способны нивелировать эти риски. Многие компании успешно работают с распределенными командами на протяжении многих лет без существенного влияния на качество продукта.</p> <p>Показателен пример рынка электронной коммерции. Крупные интернет-магазины нередко используют гибридную модель: внутренняя команда отвечает за ключевые пользовательские сценарии и знание продукта, а внешние специалисты подключаются перед крупными распродажами для проведения нагрузочного тестирования и масштабной регрессии. Такой подход позволяет справляться с сезонными пиками нагрузки без необходимости содержать большой штат сотрудников круглый год.</p> <h3>Как сделать правильный выбор</h3> <p>Универсального ответа на вопрос, что лучше — тестирование ПО in-house или аутсорсинг, не существует. Решение должно основываться на конкретных бизнес-задачах.</p> <p>Перед выбором стоит ответить на несколько вопросов:</p> <ul> <li> Насколько ограничен бюджет проекта?</li> <li> Требуется ли быстрое масштабирование команды?</li> <li> Есть ли повышенные требования к безопасности?</li> <li> Нужна ли специализированная экспертиза?</li> <li> Планируется ли долгосрочное развитие продукта?</li> </ul> <p>#IMAGE_234954#</p> <p>Для стартапов и SaaS-компаний выбор часто склоняется в сторону аутсорсинга. На ранних этапах развития продукта важно быстро проверять гипотезы и выводить новые функции на рынок. В этих условиях содержание большого QA-отдела может замедлить развитие бизнеса.</p> <p>Именно поэтому многие технологические компании используют комбинированную модель: несколько внутренних специалистов отвечают за стратегию качества и знание продукта, а автоматизация, тестирование производительности или аудит безопасности привлекаются извне. Такой подход позволяет получать доступ к узкопрофильной экспертизе без существенного увеличения постоянных расходов. На практике самый устойчивый подход — не выбирать между in-house и аутсорсингом, а строить QA-модель вокруг рисков продукта, скорости релизов и стоимости ошибки для бизнеса.</p> <h3>Заключение</h3> <p>Выбор между собственной командой тестирования и аутсорсингом нельзя свести к простому сравнению стоимости услуг. На решение влияют зрелость продукта, требования к безопасности, доступность кадров, скорость развития бизнеса и множество других факторов.</p> <p>Интересно, что рынок постепенно движется не к доминированию одной из моделей, а к их сочетанию. По отраслевым оценкам, до <nobr>60-70%</nobr> компаний сегодня используют смешанную модель QA, оставляя внутри управление качеством и передавая подрядчикам специализированные задачи. Компании все чаще оставляют внутри стратегические компетенции и знания о продукте, а внешних специалистов привлекают для решения специализированных задач или быстрого масштабирования ресурсов.</p> <p>Поэтому главный вопрос сегодня звучит уже не как «in-house или аутсорсинг», а как «какое сочетание этих подходов позволит бизнесу быстрее достигать своих целей без потери качества продукта». Именно такой взгляд становится определяющим для современных CTO, ИТ-директоров и руководителей цифровых продуктов.</p> <p>#IMAGE_234953#</p> Практически каждая компания, которая развивает цифровой продукт, рано или поздно сталкивается с одним и тем же … article Ирина Зверева, директор по маркетингу компании “Точка качества” https://www.itweek.ru/themes/detail.php?ID=234949 Thu, 04 Jun 2026 09:25:51 +0300 <p>Управление качеством — один из самых болезненных процессов на любом производственном предприятии. Его автоматизация уже давно перестала быть данью моде: речь идет о прямых потерях от брака, рисках рекламаций, неликвидных остатках и, в конечном счете, о доверии заказчиков. Однако на практике выбор подхода к автоматизации качества оказывается мучительным компромиссом между «быстро и дешево», «гибко, но дорого» и «стандартно, но сыро».</p> <p>#IMAGE_234951#</p> <p>В этой статье — анализ возможных стратегий построения системы контроля качества на базе современной ERP, их преимуществ, ограничений и рекомендаций по выбору. Только те моменты, с которыми производители действительно сталкиваются прямо сейчас.</p> <h2>Основные этапы построения системы качества в ERP</h2> <p>Учет качества в любой крупной учетной системе можно выстроить по-разному. Все зависит от сложности решаемых задач и финансовых возможностей компании. Можно обойтись встроенными механизмами, можно заказать доработку «под себя», а можно внедрить специализированный лабораторный модуль. Рассмотрим три основных пути — от наиболее простого к сложному.</p> <h3>1. Базовые возможности ERP (работа «из коробки»)</h3> <p>В стандартной версии практически любой серьезной ERP уже есть все необходимые инструменты для организации входного контроля. Однако отдельной «кнопки» или готового комплексного сценария именно под входной контроль, как правило, не предусмотрено — этот процесс нужно настраивать под задачи конкретного предприятия. При этом имеющегося функционала достаточно, чтобы выстроить полноценный входной контроль без дополнительных систем.</p> <p>Для организации процесса пользователям приходится комбинировать типовые объекты: создавать отдельные позиции для брака, использовать партии (серии) с признаками годности и выделять специальные склады-карантины для некачественной продукции.</p> <h3>2. Доработка системы под собственные нужды</h3> <p>Часто встроенного функционала недостаточно, компании дорабатывают систему. Это может включать:</p> <ul> <li> улучшение пользовательского интерфейса (чтобы контролерам было удобнее);</li> <li> изменение логики (переключение между статусами, блокировки, маршрутизация);</li> <li> добавление новых аналитических отчетов (для анализа показателей);</li> <li> интеграцию (связка с другими программными продуктами).</li> </ul> <p>Успех такой доработки полностью зависит от профессионализма команды: сначала анализ, затем четкое техническое задание, потом разработка, тестирование и лишь после этого — внедрение в промышленную эксплуатацию.</p> <h3>3. Специализированные решения (для сложных задач)</h3> <p>В случае необходимости автоматизировать работу собственной лаборатории (когда к качеству продукции предъявляются особые требования), на рынке существуют готовые лабораторные модули. Как правило, такие модули могут быть интегрированы с основной ERP-системой, однако это отдельный продукт, который требует дополнительных лицензий и бюджета на внедрение.</p> <p>Такие решения позволяют управлять пробами, автоматически собирать данные с измерительных приборов и формировать протоколы испытаний, а также паспорта качества.</p> <p>Кроме того, существуют отраслевые сборки (например, для молочной, фармацевтической или металлургической отраслей), в которые уже «зашиты» типовые методики проверок и обязательные отчеты по отраслевым стандартам.</p> <h2>Сравнительный анализ методов управления качеством</h2> <p>При выборе автоматизации многие оказываются в затруднении: хватит ли стандартного функционала, стоит ли заказывать доработки или лучше сразу присматриваться к профессиональным решениям?</p> <p>Ниже представлена таблица, в которой наглядно видны отличия подходов, их задачи и типичные сценарии применения.</p> <div class="block-scroll"> <table> <tbody> <tr> <th> Подход/Решение </th> <th> Описание и основные возможности </th> <th> Преимущества </th> <th> Недостатки и риски </th> <th> Кому подходит </th> </tr> <tr> <td> <p>Использование типового функционала ERP</p> </td> <td> <p>Выделение брака через:</p> <p> 1. Карточки номенклатуры с градациями «новый», «не годен», «ограниченно годен». </p> <p>2. Серии с соответствующими свойствами «не годен», «ограниченно годен» и т. д.</p> <p>3. Размещения не проверенной либо не годной номенклатуры на выделенном складе.</p> <p>4. Комбинации способов между собой.</p> </td> <td> <p>1. Минимальные затраты на внедрение.</p> <p>2. Полная поддержка и обновления от вендора.</p> </td> <td> <p>1. Настройка существующего функционала для входного контроля.</p> <p>2. Ограниченная гибкость и скудная отчетность.</p> <p>3. Риск «обхода» процедур пользователями (например, списание не проверенного сырья).</p> </td> <td> <p>Предприятия с простыми процессами контроля, где достаточно базовой фиксации брака и выполнения контрольных операций.</p> </td> </tr> <tr> <td> <p>Специализированный лабораторный модуль, интегрированный с ERP</p> </td> <td> <p>Полный цикл: от заявки на испытания и регистрации проб до формирования протоколов и передачи результатов в отчет.</p> <p>Включает управление оборудованием, реактивами, контрольные карты. </p> </td> <td> <p>1. Глубокая и бесшовная интеграция (единая среда, обмен данными).</p> <p>2. Снижение человеческого фактора, автоматический сбор данных с приборов.</p> <p>3. Готовые отчеты для регуляторов, соответствие требованиям стандартов (ISO 17025, GxP).</p> </td> <td> <p>1. Стоимость лицензий и внедрения выше, чем у типового функционала.</p> <p>2. Избыточность, если на предприятии нет развернутой лабораторной службы.</p> </td> <td> <p>Производственные предприятия с аккредитованной или сильной внутренней лабораторией, где качество напрямую зависит от результатов испытаний (пищевая, химическая, фармацевтическая промышленность).</p> </td> </tr> <tr> <td> <p>Отраслевые решения</p> </td> <td> <p>Специализированные конфигурации или модули, расширяющие ERP под нужды конкретной отрасли.</p> <p>Учитывают отраслевую специфику, нормативную базу и типовые методики контроля.</p> </td> <td> <p>1. Быстрое внедрение — многие процессы и справочники уже настроены.</p> <p>2. Учет уникальных требований отрасли (температура, соматические клетки, микробиология и т. д.).</p> </td> <td> <p>1. Ориентация на конкретную отрасль — минус для диверсифицированных производств.</p> <p>2. Зависимость от вендора решения и его политики обновлений.</p> </td> <td> <p>Предприятия четко определенной отрасли (молочной, нефтегазовой и др.), стремящиеся к быстрому получению «коробочного» решения.</p> </td> </tr> <tr> <td> <p>Комплексная система собственной разработки</p> </td> <td> <p>Модуль управления качеством, разработанный с нуля или на основе платформы, включающий: журнал лабораторных испытаний, учет несоответствий с корректирующими действиями, блокировку отгрузки брака, отчеты по качеству выпуска.</p> </td> <td> <p>1. Максимальная гибкость и полное соответствие любым требованиям.</p> <p>2. Создание уникальных конкурентных преимуществ.</p> </td> <td> <p>1. Высокая стоимость и длительные сроки разработки/ внедрения.</p> <p>2. При большом количестве требований — усложнение долгосрочной поддержки. Для снижения нагрузки при обновлениях могут использоваться расширения и/или отдельные АРМ.</p> </td> <td> <p>Крупные компании с эксклюзивными процессами и значительным бюджетом, для которых качество — ключевой стратегический фактор.</p> </td> </tr> </tbody> </table> </div> <h2>Подведем итоги: что важно учесть</h2> <p>Выбор оптимального пути автоматизации контроля качества в ERP — это стратегическое решение, которое должно базироваться на тщательном анализе текущих и будущих потребностей бизнеса.</p> <ul> <li><strong> Начните с анализа типового функционала.</strong> Прежде чем инвестировать, детально изучите стандартные возможности вашей ERP в части управления качеством. Во многих случаях грамотной настройки может оказаться достаточно.</li> <li><strong> Рассмотрите готовые решения перед заказом разработки.</strong> Если типовых функций не хватает, следующим шагом становится выбор готового решения под задачи предприятия. Здесь важно разделять разные уровни автоматизации. Специализированный лабораторный модуль подходит для учета и контроля внутри лаборатории, где выполняются измерения и испытания. Если же требуется выстроить учет и управление процессами на уровне всего предприятия, подойдет отраслевое решение, которое при необходимости может включать и лабораторный контур. Как правило, такие продукты внедряются быстрее и обходятся дешевле, чем индивидуальная разработка, а их поддержка при обновлениях более предсказуема.</li> <li><strong> Доработки — для уникальных процессов.</strong> К кастомизации стоит прибегать, когда ни стандартный, ни готовый функционал не может закрыть специфическую задачу компании. Ключевой критерий успеха здесь — выбор надежной, сертифицированной команды разработчиков, которая использует безопасные методы (например, расширения без изменения ядра) и следует профессиональному процессу внедрения.</li> <li><strong> Делайте ставку на интеграцию</strong>. Эффективная система качества — это не изолированный модуль, а часть единого информационного контура предприятия. Решения, обеспечивающие бесшовный поток данных между производством, лабораторией, складом и бухгалтерией, приносят наибольшую ценность, ликвидируя «информационные острова» и ручной ввод данных.</li> </ul> <p>#IMAGE_234950#</p> Управление качеством — один из самых болезненных процессов на любом производственном предприятии. Его … article Иван Герасимчук, бизнес-аналитик ООО “Индустрия Информатики” (бренд ГЭНДАЛЬФ) https://www.itweek.ru/themes/detail.php?ID=234948 Wed, 03 Jun 2026 16:23:31 +0300 <p>Департамент информационных технологий города Москвы представил обзор Open Source в России, подготовленный совместно с отраслевой площадкой ICT.Moscow. В нем собраны и проанализированы оценки, исследования и публикации, касающиеся отечественной индустрии за последние годы.</p> <p>Исследование рассматривает роль российского сегмента разработки открытого кода на мировой арене, описывает ключевые группы участников сообщества и особенности локального развития этого направления.</p> <p>Авторы также ретроспективно изучили программы и инициативы, создаваемые в разное время для открытого кода в стране. Отдельно приводятся мнения о прогнозах, барьерах и аспектах, стимулирующих интерес к этому направлению у его участников.</p> <p>«При формировании долгосрочной стратегии развития экосистемы „МосТех“ и входящей в нее платформы для разработчиков „Мос.Хаб“ нам очень важно иметь четкое представление о специфике внутреннего рынка, который прошел через разные этапы в последние годы, а также о реальных барьерах и мотиваторах российского сообщества Open Source. Все это позволяет опираться на подлинные данные, учитывать разные взгляды и подходы. При этом Open Source имеет все шансы стать естественной частью разработки в России», — рассказал Алексей Анисимов, заместитель руководителя Департамента информационных технологий города Москвы.</p> <p>В основе документа — наиболее заметные оценки, исследования и публикации о рынке открытого исходного кода с 2023 года. Такой подход позволяет составить панорамное представление о текущем состоянии и перспективах Open Source.</p> <p>«Несмотря на то, что при анализе мировых технологических трендов этого года не прослеживается какой-то особый интерес авторов к теме Open Source, его роль может быть сильно недооценена. Многие эксперты сходятся в том, что синергия искусственного интеллекта и открытого программного кода способна оказать существенное влияние на ИТ. В последнее время в России мы наблюдаем исследования, которые освещают Open Source скорее фрагментарно, поэтому есть необходимость посмотреть на тему с разных сторон», — пояснили представители аналитического хаба ICT.Moscow.</p> <p>Обзор Open Source в России можно изучить по <a href="https://ict.moscow/analytics/open-source-2026/">ссылке</a>.</p> Департамент информационных технологий города Москвы представил обзор Open Source в России, подготовленный совместно … message https://www.itweek.ru/themes/detail.php?ID=234946 Wed, 03 Jun 2026 13:00:01 +0300 <p>Компания BSS и Центр развития перспективных технологий (ЦРПТ) стали победителями престижной Премии в области искусственного интеллекта AI-Олимп в номинации «Решение года», категория «Голосовые помощники». Награждение состоялось 27 мая в центре событий РБК Москва в рамках форума «Время Цифры».</p> <p>Проект, реализованный в партнёрстве с системным интегратором ITFB Group, признан эталонным примером внедрения коммуникативного ИИ в условиях высокой регуляторной нагрузки и масштабных пользовательских потоков.</p> <p>«Уникальность этого проекта — не только в передовых технологиях, но и в способности интегрировать их в жесткий контур государственной системы с высочайшими требованиями к надежности и безопасности. Как системный интегратор, мы обеспечили бесшовную связку ИИ-решений BSS с действующей инфраструктурой „Честного знака“, где цена ошибки критически высока. Именно глубокое понимание отраслевой специфики и регуляторных ограничений позволило нам создать отказоустойчивый инструмент, который уже сегодня работает на стыке технологий, закона и многомиллионной пользовательской базы», — прокомментировала Наталья Романова, директор по развитию бизнеса ITFB Group.</p> <p>Система маркировки «Честный знак» — одна из ключевых инфраструктур цифровой экономики России. Ежедневно в контакт-центр системы поступает около 10 000 обращений от более чем 1 млн зарегистрированных участников, включая представителей бизнеса и 38 млн пользователей мобильного приложения Честный ЗНАК. Поддержка охватывает более 50 товарных групп, в которых уже запущены обязательные требования или идет добровольный и бесплатный эксперимент — операторы должны одновременно разбираться в технических нюансах маркировки и юридических требованиях законодательства.</p> <p>«Задача нашего контактного центра — предоставлять точные ответы в кратчайшие сроки. Помимо линии техподдержки, которая работает в режиме 24/7, в постоянном контакте с бизнесом остаются команды всех маркируемых товарных групп, включая их руководителей. Кроме того, регулярно проводим для предпринимателей обучающие вебинары, рабочие группы, публикуем справочные материалы и инструкции на нашем портале. Главная цель — понятность и простота работы с маркировкой с полным доверием системе», — отметил руководитель клиентского сервиса ЦРПТ Илья Грознов.</p> <p>Для решения этой задачи было внедрено комплексное решение на базе ИИ-платформы BSS, включающее:</p> <ul> <li>речевую аналитику для автоматического анализа 100% звонков;</li> <li>голосового робота для первичной маршрутизации и сбора данных;</li> <li>Copilot для операторов с интеграцией в CRM и базой знаний;</li> <li><nobr>LLM-модули</nobr> для семантического анализа сложных диалогов.</li> </ul> <p>Реализованный проект вывел ключевые показатели контакт-центра на новый уровень. Вероятность обнаружения «проблемных» диалогов выросла с 2,5% до 100%, доля диалогов со словами-паразитами снизилась в шесть раз, а показатель First Call Resolution превысил 80%. Производительность контролёров качества увеличилась на 20%.</p> <p>«Мы не просто автоматизировали процессы — мы создали обучающуюся экосистему, которая постоянно адаптируется под изменения в законодательстве и поведении пользователей. Уникальность проекта в том, что нам удалось объединить речевую аналитику, голосового робота и <nobr>LLM-модели</nobr> в единый контур без усложнения ИТ-инфраструктуры», — прокомментировала Оксана Станевич, представитель компании BSS.</p> <p>Ранее проект уже получил публичное признание: по итогам 2025 года команда контакт-центра «Честного знака» стала лауреатом отраслевой премии CCGuru Awards «Хрустальная Гарнитура» в номинации «Лучшая работа с обратной связью, жалобами и претензиями». Также проект выдвинут на конкурс «Проект года» Global CIO.</p> <p>Для BSS это не первая победа в области ИИ-решений: компания неоднократно становилась лауреатом Национальной банковской премии, FINAWARD, Fintech Awards и других отраслевых наград, подтверждая статус технологического лидера в сегменте коммуникативного ИИ.</p> Компания BSS и Центр развития перспективных технологий (ЦРПТ) стали победителями престижной Премии в области … message https://www.itweek.ru/themes/detail.php?ID=234944 Wed, 03 Jun 2026 09:12:05 +0300 <p>DevRel-специалист говорит на одном языке с разработчиками и клиентами, разбирается в коде и выступает лицом компании. Рассмотрим, какие навыки нужны для этой работы, и почему техподдержка — один из самых подходящих бэкграундов для профессии.</p> <h3>Кто такой DevRel и что он делает</h3> <p>Слово DevRel — это сокращение от Developer Relations и переводится как «отношения с разработчиками». Должность объединяет обязанности из областей PR, маркетинга и технологий.</p> <p>Классический DevRel-специалист занимается популяризацией компании с технологической стороны. Это значит выступать на конференциях, писать статьи, рассказывать людям с разным опытом о том, чем занимается компания и как её продукты полезны потенциальным клиентам.</p> <p>Ещё DevRel часто помогает внутренней и внешней командам разработки синхронизироваться по рабочим вопросам и находить решения. Это может выглядеть так: внешняя команда программистов работает с технологиями компании и находит ошибку в одной из частей системы. Они приходят с этой ошибкой к DevRel, а ему нужно передать проблему внутренней команде, но при этом помочь разобраться и объяснить, что именно не так. Поэтому DevRel должен тоже работать с кодом: поискать проблему, протестировать сценарии работы, попробовать отладить и посмотреть на результаты. И уже с более полной картиной прийти к внутренним программистам компании.</p> <p>Главная и основная задача — это популяризация бренда. Если люди ассоциируют компанию с определённым техническим специалистом, и это создаёт бизнесу хороший имидж, значит, DevRel работает успешно.</p> <h3>Откуда приходят в DevRel и почему нужен технический бэкграунд</h3> <p>В российских компаниях DevRel сегодня чаще всего появляется внутри компании, когда кто-то из специалистов нарабатывает достаточный набор навыков и переходит на новую должность. Реже в DevRel нанимают людей со стороны: с 2021 по 2025 годы на hh.ru количество вакансий оставалось на уровне <nobr>30-50 позиций.</nobr></p> <p>Люди приходят в эту специальность из очень разных сфер: технической поддержки, разработки, тестирования, аналитики. Важно развить достаточный уровень инженерной экспертизы и опыта. Классический DevRel не может быть без технического бэкграунда, потому что нужно понимать не только клиентов и партнёров, но и разработчиков.</p> <p>В отличие от мидлов и сеньоров в программировании, DevRel может не иметь коммерческого опыта разработки. Для опытного инженера коммерческий опыт служит доказательством, что он умеет работать с реальным продуктом и отвечать за код в рабочих условиях. Для DevRel такой опыт в разработке полезен, но не всегда обязателен, потому что его основная ценность в понимании технического контекста, коммуникации и переводе между разными участниками процесса.</p> <h3>Какие софт-скиллы нужны DevRel</h3> <p>Важно правильно доносить мысли и уметь работать в команде. Переводить мысль на разные языки — возможно, главный навык хорошего DevRel-специалиста. Он должен не просто понимать техническую часть, а уметь превратить это понимание в коммуникацию, которая помогает людям решить задачу.</p> <p>Другое важное умение — организованность. Чаще всего DevRel решает задачи не один, а в контакте с другими сотрудниками. Нужно координировать разные команды и людей: прийти к внутренней команде, договориться о приоритете, получить ответ, вернуться к внешним разработчикам и объяснить, что изменилось. Может понадобиться провести встречу, презентацию, обучение.</p> <p>Спокойствие и конфликтоустойчивость тоже важны. DevRel работает в том числе с людьми, у которых что-то не получается. А когда у людей что-то не получается, они не всегда формулируют проблему спокойно и корректно.</p> <p>Большой опыт публичных выступлений нужен не всегда, потому что обязанности DevRel в разных компаниях сильно отличаются друг от друга. Но ответственность за публичное слово всё равно нужно уметь нести.</p> <h3>Почему опыт техподдержки особенно хорошо подходит</h3> <p>Работа в технической поддержке — один из самых релевантных опытов для DevRel-позиции. Эти две профессии похожи, потому что в поддержке специалист тоже является посредником: между клиентом и своей командой разработки. Поэтому человек быстро учится понимать проблемы обеих сторон и решить их так, чтобы по возможности все были в выигрыше.</p> <p>В техподдержке развивается и другой важный навык: умение переводить с технического языка на нетехнический и обратно. В компанию может написать программист, у которого не работает интеграция между приложениями, а может и обычный пользователь, который не видит нужную кнопку. В обоих случаях нужно понять, что стоит за обращением или за проблемой, найти техническую причину, иногда вместе с командой разработки, и всё исправить.</p> <p>Коммуникацию нужно уметь поддерживать и между инженерами: у программистов нет какого-то универсального технического языка, у каждого может быть своё видение, опыт и стек технологий. Из-за этих отличий и DevRel-специалист, и сотрудник поддержки должны уметь построить диалог между разными разработчиками.</p> <p>У DevRel и техподдержки есть пересекающиеся задачи. Например, написать документацию по части сервиса для внешних команд партнёров или подрядчиков. Если DevRel-специалист до этого работал в поддержке, он уже погружён в продукт, разбирался в устройстве или даже знает, как работает код нужной части системы. Тогда задачу можно выполнить, не подключая команду разработки.</p> <h3>Что нужно развивать дополнительно</h3> <p>Это не значит, что после <nobr>2-3</nobr> лет работы в техподдержке специалист становится полностью готовым к DevRel. Один из главных навыков, который нужно поменять — мышление. Например, поддержка работает с запросами локально: задача специалистов в том, чтобы решить запрос и не думать, с чем он может быть связан. DevRel должен мыслить более глобально и мыслить стратегически: как влияет эта проблема на работу компании? Нужно ли её исправлять, улучшать или изменять другим путём? Какие риски могут быть связаны с работой над конкретной задачей?</p> <p>Полезного DevRel-специалиста отличает умение доходить до источника проблемы. Поэтому любопытство и желание досконально разобраться тоже нужно развивать. Это не совсем хард-скилл и не совсем софт-скилл. Скорее рабочая привычка: не останавливаться на статусе «работает» или «не работает», а найти первопричину.</p> <h3>Стоит ли DevRel специально идти в поддержку</h3> <p>Это вопрос, который каждый решает для себя самостоятельно, но у работы в техподдержке много плюсов для будущего DevRel.</p> <p>Главное — это опыт, который сложно получить где-то ещё. Если начинать с разработки или тестирования, скорее всего нужно будет работать с отдельными модулями и компонентами. В техподдержке нужно знать всё, пусть и не на таком же глубоком уровне. Но для работы в поддержке тоже важно иметь нужные качества: желание помогать людям, техническая база и достаточный уровень эмпатии.</p> <p>#IMAGE_234945#</p> DevRel-специалист говорит на одном языке с разработчиками и клиентами, разбирается в коде и выступает … article Владимир Верхотуров, тимлид отдела “Продуктовый DevRel” компании ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=234942 Wed, 03 Jun 2026 08:58:19 +0300 <p><em>То, как сегодня агентный искусственный интеллект используется в разработке ПО, является предвестником более широких изменений в модели разработки, пишут в корпоративном блоге партнеры McKinsey Джаред Мун и Адам Теллуолл (Лондон), Рори Уолш (Дублин) и Вито Ди Лео (Цюрих).</em></p> <p>В 9:00 утра владелец продукта заходит в систему, чтобы проверить прогресс, достигнутый ее командой за ночь. Она видит, что функция перешла от структурированных требований к протестированному коду. Отмечены граничные случаи. Она отмечает, что архитектурные зависимости проверены. Краткое резюме описывает компромиссы и нерешенные вопросы.</p> <p>Никто не работал допоздна. Работали агенты ИИ.</p> <p>К середине утра команда проверяет результаты, уточняет контрольные точки и пересматривает приоритеты бэклога. К вечеру следующие структурированные входные данные ставятся в очередь для работы агентов ИИ в течение очередного ночного цикла.</p> <p>Эта <nobr>24-часовая</nobr> модель работы больше не является теоретической. Ведущие организации уже перестраивают процесс разработки, ориентируясь на почти непрерывное выполнение. Модель разработки ПО быстро развивается, и многие компании уже видят, как она обеспечивает трех-пятикратное повышение производительности при сокращении численности команды на 60%. Организации добиваются этих результатов не просто за счет внедрения агентов ИИ, а за счет перестройки операционной модели таким образом, чтобы люди и агенты могли сотрудничать 24 часа в сутки.</p> <h3><nobr>24-часовой</nobr> спринт: проектирование для непрерывной производительности</h3> <p>Ведущие компании переходят к модели ежедневного спринта, которая сочетает в себе человеческое суждение с ночным выполнением задач агентами — значительное сокращение типичных двухнедельных циклов спринта. В течение дня люди сосредотачиваются на проверке результатов, разрешении неясностей, укреплении архитектурных ограничений и согласовании с заинтересованными сторонами. Всё чаще их роль сводится не столько к созданию артефактов, сколько к надзору и совершенствованию системы, которая их создаёт.</p> <p>Ночью агенты выполняют структурированную работу в масштабе. Их задачи включают в себя обогащение требований, проверку архитектуры, генерацию и тестирование кода, а также упаковку результатов для проверки.</p> <p>Эта модель работает только при наличии нескольких практических основ. Во-первых, у бизнеса должно быть чёткое видение того, что нужно построить (это может быть дорожная карта продукта или стандарт, на основе которого будет строиться), чтобы они могли оценивать требования, сгенерированные агентами, на предмет качества и соответствия этому видению.</p> <p>Затем базовая технологическая среда должна быть стандартной и согласованной (например, с использованием общих фреймворков и модульных архитектур), чтобы решения могли масштабироваться, а компоненты могли повторно использоваться, а не изобретаться заново каждый раз.</p> <p>В-третьих, путь от требований к коду должен следовать стандартной структуре, чтобы агенты могли надёжно интерпретировать входные данные и получать предсказуемые результаты в разных проектах.</p> <p>И в-четвёртых, одни и те же ключевые заинтересованные стороны должны оставаться вовлеченными на протяжении всего потока создания ценности, чтобы избежать несогласованности и постоянных переделок.</p> <p>Без такого уровня согласованности и ясности результаты работы агентов будут фрагментированными, и им будет трудно доверять.</p> <p>Главный вывод: непрерывная <nobr>24-часовая</nobr> доставка достижима, но только при наличии архитектурной дисциплины и стандартизированных рабочих процессов, чтобы агенты могли надежно работать в масштабе.</p> <h3>Расширьте автоматизацию, чтобы исключить передачу задач от человека к человеку</h3> <p>Традиционная автоматизация непрерывной интеграции и непрерывной доставки (CI/CD) в значительной степени сосредоточена на тестировании и развертывании. Хотя затраты на это варьируются, наш опыт показывает, что они могут составлять до 30% от общих затрат на технологии. Бóльшая часть усилий, сосредоточенных на требованиях и кодировании, остается ручной и требует интенсивной интерпретации. Именно здесь накапливаются трения, и ценность достигает плато.</p> <p>В большинстве организаций требования, стандарты, архитектурные спецификации и пользовательские истории существуют в разрозненных документах и ​​инструментах. Каждый переход вносит неоднозначность. Люди многократно переводят намерения из одного артефакта в другой.</p> <p>#IMAGE_234943#</p> <p>Агентная модель устраняет эти трения, структурируя артефакты для передачи задач от машины к машине. Функциональные описания, нефункциональные требования, ограничения, диаграммы последовательностей и репозитории кодифицируются в стандартизированных, машиночитаемых форматах. В результате конвейер может выполняться от начала до конца за несколько часов, при этом вмешательство человека происходит только на определенных этапах проверки, а не в качестве посредника.</p> <p>Главный вывод: масштабирование ИИ требует применения инженерных методов к самой системе разработки, что делает процесс повторяемым и автоматизирует передачу задач.</p> <h3>Создание инфраструктуры знаний для обеспечения автономности агентов</h3> <p>Для получения точных результатов фабрикам агентов необходимы организационный контекст и память. Ведущие компании создают графы знаний, которые функционируют как слой памяти ИИ на протяжении всего жизненного цикла разработки ПО (SDLC) для каждой области. Эти графы связывают элементы, которые агенты должны понимать, такие как отзывы клиентов, архитектурные решения, проектная документация, заявки, активность в GitHub, отчеты об инцидентах и ​​обобщенные правила соответствия нормативным требованиям. В результате получается семантически связанная система (то есть, способ для агентов понимать значение данных, чтобы лучше выполнять свои задачи).</p> <p>Такое влияние является преобразующим. На вопросы, которые раньше требовали недель интервью с многочисленными экспертами в предметной области, агент-«библиотекарь» может ответить за минуты, используя структурированную институциональную память. Каждое решение становится отслеживаемым. Если заинтересованная сторона спрашивает, почему функция была отложена, ответ может быть напрямую связан с источником, например, данными опросов клиентов или аналитикой использования. Неявные знания, накопленные в рамках сообщества, становятся явными и объяснимыми, сокращая время адаптации для новых членов команды и укрепляя управление.</p> <p>Важно отметить, что это не должно начинаться с масштабной, нисходящей разработки онтологии. Граф должен органично развиваться вокруг приоритетных областей и действующих программ, накапливая ценность с течением времени. По мере масштабирования знания становятся производственной инфраструктурой, а не статической документацией, и устойчивым источником конкурентного преимущества.</p> <p>Главный вывод: структурированные, взаимосвязанные знания — это основа автономии агентов. Рассматривайте свою архитектуру знаний как стратегическую инфраструктуру.</p> <h3>Получение выгоды: изменение размеров команд и перепроектирование портфеля</h3> <p>Агентный SDLC может существенно повысить производительность, поскольку теперь меньшие команды могут выполнять бóльшие объемы работы. Первые внедрения показывают, что большие команды из <nobr>8-12</nobr> штатных сотрудников могут уступить место меньшим группам высококвалифицированных специалистов, контролирующих выполнение задач с помощью агентов. Результатами являются сокращение сроков и снижение затрат или увеличение производительности.</p> <p>Для получения выгоды организациям следует сосредоточиться на трех приоритетах. Во-первых, это переквалификация персонала. В то время как центральной команде необходимы навыки для разработки и поддержки фабрик агентов (обеспечение стандартизации и соответствия нормативным требованиям, внедрение передовых методов и т. д.), инженерам-программистам по всей организации необходимо развивать навыки принятия решений, код-ревью и управления агентами, с которыми они работают. Роли смещаются от ручной координации и тестирования к обеспечению согласованности архитектуры, моделированию предметной области и управлению ИИ.</p> <p>Во-вторых, необходимо обеспечить участие в агентной разработке всех «внешних» звеньев — специалистов по поддержке и соблюдению нормативных требований в отделах рисков, юриспруденции, тестирования и закупок. Без этого ускоренный SDLC не приведет к ускорению прогресса. Агенты и автоматизация (например, с помощью политики как кода) могут помочь гарантировать, что эти механизмы контроля не станут узкими местами, одновременно повышая качество, согласованность, полноту и отслеживаемость. Эти механизмы контроля должны быть заложены в основу проекта, а не становиться препятствием в конце процесса.</p> <p>И третье — это перепроектирование распределения ресурсов таким образом, чтобы повышение производительности приводило к созданию новой ценности. Освобожденные ресурсы часто реинвестируются для ускорения реализации дорожных карт, модернизации платформ или запуска новых продуктов.</p> <p>Главный вывод: повышение производительности может быть преобразовано в структурные изменения портфеля. Измените размер команд и сознательно перераспределите ресурсы, чтобы получить максимальную выгоду.</p> <p>Трансформация должна начинаться там, где ее влияние наиболее велико. В большинстве технологических организаций бóльшая часть общих расходов приходится на небольшое количество крупных программ. Целенаправленное выполнение этих инициатив — будь то модернизация унаследованных систем, переделка существующих объектов или запуск новых продуктов — максимизирует видимый эффект и ускоряет обучение.</p> <p>Если агенты возьмут на себя выполнение задач в масштабе и будут создавать надежный и стабильно безопасный код, роль человека будет концентрироваться в архитектуре, оценке продукта и проектировании систем, что сделает институциональные знания и техническую согласованность решающими факторами дифференциации. Организации, которые начнут развивать эти возможности в рамках более широких усилий по перестройке своей операционной модели, не просто будут двигаться быстрее; они переосмыслят то, как ПО создает ценность.</p> То, как сегодня агентный искусственный интеллект используется в разработке ПО, является предвестником более широких … article https://www.itweek.ru/themes/detail.php?ID=234940 Tue, 02 Jun 2026 16:12:14 +0300 <p>Axiom JDK объявила о выпуске Axiom Trusted Images — линейки доверенных контейнерных образов для разработки и промышленной эксплуатации приложений в Kubernetes и cloud-native инфраструктуре. Впервые продукт был представлен 2 июня в Москве на конференции «БеКон», посвященной безопасному использованию контейнеров и контейнерных сред.</p> <p>Новый продукт помогает компаниям снизить риски безопасности в контейнерной инфраструктуре и ускорить вывод цифровых сервисов в промышленную эксплуатацию. Axiom Trusted Images предоставляют проверенный базовый слой контейнеров вместо разрозненных публичных образов с непрозрачным составом, лишними компонентами и уязвимостями, которые требуют дополнительного анализа со стороны ИБ, DevOps и разработки.</p> <p>Выпуск Axiom Trusted Images стал развитием продуктовой экосистемы Axiom JDK. Исторически компания решает задачи безопасной эксплуатации Java-приложений. Но современные корпоративные системы состоят из разных технологических компонентов: NGINX, Node.js, Go, C, C++, специализированных runtime-сред и контейнерной инфраструктуры. Каждый из этих компонентов становится частью контура промышленной эксплуатации, поэтому бизнесу нужен единый подход к безопасности базовых контейнерных образов независимо от языка разработки и типа сервиса.</p> <p>Axiom Trusted Images помогают компаниям получить несколько ключевых бизнес-преимуществ:</p> <ul> <li>снизить поверхность атаки за счёт минимального состава контейнерных образов и вариантов поставки под разные сценарии: shell, distroless, rootless;</li> <li>сократить количество CVE в базовом слое за счёт удаления лишних компонентов, постоянного мониторинга и регулярного обновления образов;</li> <li>упростить подготовку к требованиям ИБ, регуляторов и внутреннего аудита благодаря SBOM, цифровой подписи и подтверждённому происхождению образов;</li> <li>ускорить прохождение проверок безопасности перед запуском продуктов за счёт прозрачного состава, фиксированных версий и понятного процесса устранения уязвимостей;</li> <li>высвободить время разработчиков, DevOps и платформенных команд, которые вместо ручного сопровождения базовых образов могут сосредоточиться на запуске новых сервисов;</li> <li>стандартизировать контейнерный слой для разных команд и технологических стеков за счёт готовых доверенных образов для NGINX, Node.js, Go, C, C++ и других сценариев.</li> </ul> <p>«Контейнеры ускорили разработку и сделали доставку приложений в эксплуатацию более гибкой, но одновременно усложнили контроль того, что именно попадает в промышленную среду. Для бизнеса это уже не только технический вопрос, но и вопрос скорости релизов, управляемости рисков и готовности к аудиту. Axiom Trusted Images позволяют сделать базовый контейнерный слой прозрачным, минимальным и сопровождаемым, чтобы команды могли быстрее выводить новые продукты на рынок без компромиссов по безопасности», — отметил Роман Карпов, генеральный директор Axiom JDK.</p> <p>В состав линейки входят доверенные образы для разных технологических стеков, включая NGINX, Node.js, Go, C, C++. Для Java-сценариев в экосистеме Axiom JDK доступен отдельный продукт — Axiom Runtime Container Pro, предназначенный для экономичного и безопасного запуска Java-приложений в контейнерной среде.</p> <p>Основа Axiom Trusted Images — Axiom Linux, специализированный лёгкий дистрибутив для контейнеров, который поставляется в вариантах musl и glibc. Он используется как компактный базовый слой для защищённых образов под разные технологические стеки.</p> <p>Решение поддерживает платформы x86_64 и ARM64, а также развёртывание на российских Linux-дистрибутивах и Kubernetes-платформах. Axiom Trusted Images можно использовать как замену стандартных базовых образов: обычно для подключения достаточно изменить ссылку на базовый образ в Dockerfile.</p> <p>Axiom JDK регулярно проверяет представляемые образы на известные уязвимости и устраняет их в рамках SLA. Это делает работу с CVE более предсказуемой и снижает нагрузку на команды эксплуатации.</p> <p>Актуальность решения подтверждается ростом внимания к безопасности контейнеров и DevSecOps-практикам. По данным State of DevOps Russia 2025, 46,8% респондентов уже используют сканеры уязвимостей контейнерных образов, а 35,6% — анализаторы конфигураций Kubernetes. При этом внедрение ИБ-инструментов остаётся сложной задачей: 45,5% участников отмечают нехватку технической экспертизы, 42,2% — проблемы совместимости, а 26,8% признают, что результаты проверок им непонятны. Для контейнерной инфраструктуры это особенно критично: недостаточно просто запустить сканирование образов, нужно интерпретировать CVE, понимать состав базового слоя, оценивать риски, пересобирать образы и готовить доказательную базу для ИБ и аудита. Такой процесс требует значительных ресурсов и отвлекает DevOps, ИБ и разработку от вывода новых продуктов на рынок.</p> <p>Axiom Trusted Images особенно актуальны для организаций, развивающих Kubernetes-платформы, микросервисную архитектуру, внутренние платформы разработки, а также для компаний с повышенными требованиями к информационной безопасности, аудиту и промышленной эксплуатации. </p> Axiom JDK объявила о выпуске Axiom Trusted Images — линейки доверенных контейнерных образов для разработки … message https://www.itweek.ru/themes/detail.php?ID=234939 Tue, 02 Jun 2026 16:09:48 +0300 <p>Yandex B2B Tech обновила ИИ-помощника для анализа и визуализации данных — Нейроаналитика. Агент стал умнее: теперь он не просто делает выводы по готовым дашбордам, а может напрямую обращаться к сырым корпоративным данным компании и самостоятельно создавать аналитические отчеты. Это позволит бизнесу ускорить и улучшить аналитику на базе искусственного интеллекта в организации. Обновленный ИИ-агент доступен всем пользователям в BI-системе Yandex DataLens.</p> <p>Раньше Нейроаналитик работал только с готовыми отчётами: пользователь заранее строил графики, а агент помогал в них разобраться — подсказывал формулы, находил инсайты. Теперь достаточно задать вопрос в свободной форме на естественном языке — агент сам найдёт нужные данные в корпоративном источнике и создаст подробные визуализации с выводами. Так, например, можно узнать, как менялась выручка конкретного менеджера в определённом городе за последний месяц. Нейроаналитик работает с корпоративными данными внутри DataLens в рамках прав доступа, которые настроены в системе для каждого пользователя.</p> <p>По данным отраслевых исследований, специалисты по работе с данными тратят до 20 часов в неделю на доступ, объединение и подготовку данных вместо непосредственного анализа. При этом 92% аналитиков предпочли бы заниматься другими задачами вместо подготовки данных, но 65% всё равно проводят за ней минимум половину рабочего времени. Нейроаналитик забирает эту нагрузку на себя: специалисты по данным могут сосредоточиться на более сложных задачах — определять ключевые вопросы, выбирать нужные разрезы и формулировать гипотезы — а бизнес-пользователи получают ответы быстро, без необходимости знать формулы или структуру данных.</p> <p>В Yandex DataLens появился виджет с готовыми подсказками от ИИ-помощника прямо на аналитическом дашборде. Теперь пользователю не нужно каждый раз писать сложные промпты к дашбордам и обновлять их, достаточно один раз дать агенту простую инструкцию на естественном языке. При каждом открытии дашборда агент анализирует нужные данные и показывает актуальный статус. Это удобно для сотрудников, которые не занимаются аналитикой профессионально: например, оператор склада без сложных промптов понимает, есть ли проблемы с текущими заказами.</p> <p>«Самый сложный момент в аналитике — это осмысление данных, время, которое порой уходит на то, чтобы предподготовить их и оформить в нужном представлении. Мы движемся к модели, в которой пользователь сможет работать с данными через единый интерфейс напрямую и быстро: задавать вопросы к анализу, получать предподготовленные данные и способы их визуализации моментально, оставляя механистичный труд Нейроаналитику», — рассказал технический директор Yandex Cloud Иван Пузыревский.</p> <p>В будущем у Нейроаналитика появится еще больше обновлений. В новых версиях агент сможет помогать пользователям искать нужные дашборды и отвечать на вопросы по работе с Yandex DataLens на основе документации сервиса и внутренней базы знаний компании.</p> Yandex B2B Tech обновила ИИ-помощника для анализа и визуализации данных — Нейроаналитика. Агент стал умнее: теперь … message https://www.itweek.ru/themes/detail.php?ID=234937 Tue, 02 Jun 2026 11:27:10 +0300 <p>Эксперты компании «Информзащита» зафиксировали рост активности атак на корпоративные учетные записи с использованием техники распыления паролей. По данным исследований компании, в 2026 году злоумышленники ежемесячно задействуют более 12000 уникальных spray IP, каждый из которых атакует не менее 10 учетных записей. По сравнению с концом 2025 года число таких IP увеличивается в среднем на 11% месяц к месяцу, а доля неуспешных попыток входа в корпоративные сервисы держится на уровне <nobr>28-30%.</nobr> Для бизнеса это означает, что атака на идентификационные данные фактически превратились в постоянный фоновый процесс: злоумышленники не ждут отдельного повода, а регулярно проверяют облачные сервисы, почтовые системы и удаленные рабочие контуры на слабые пароли и у компаний нет периодов, когда риск можно считать низким.</p> <p>Техника распыления паролей отличается от классического перебора тем, что атакующий не сосредотачивается на одной учетной записи. Вместо тысяч попыток входа к одному пользователю он берет ограниченный набор популярных, утекших или сгенерированных паролей и последовательно проверяет их на большом массиве сотрудников. Попытки распределяются по разным IP-адресам, странам, автономным системам и временным интервалам. В журналах безопасности такая активность выглядит как множество несвязанных между собой отказов, а не как очевидная брутфорс-атака. Именно поэтому простые правила блокировки по числу ошибок с одного адреса уже не дают нужного эффекта: при использовании только таких порогов распределенные атаки закономерно проходят мимо системы мониторинга и воспринимаются как «нормальный» фон.</p> <p>Рост таких атак связан с доступностью инфраструктуры. Атакующие используют облачные серверы, прокси-сети, скомпрометированные домашние маршрутизаторы, а также одноразовые узлы, которые быстро выводятся из кампании после попадания в списки блокировки. На практике один и тот же сценарий может одновременно затрагивать десятки организаций, но в каждой из них оставлять лишь слабый след. Отдельную роль играет качество парольных словарей, так как злоумышленники часто формируют их не только из открытых утечек, но и с учетом региональной лексики, названий компаний, корпоративных шаблонов и типовых правил сложности пароля. В результате снижается объем шума, но повышается шанс успешного входа.</p> <p>В 2026 году техника распыления паролей используется как первый этап цепочки. После успешной аутентификации атакующий проверяет почтовый ящик, создает правила пересылки, пытается получить доступ к файловым хранилищам, внутренним чатам и административным панелям. В ряде случаев за первичным входом следует попытка захвата сессии и изменения параметров MFA, затем — подключение сторонних приложений через OAuth или проверка устаревших протоколов, где многофакторная аутентификация работает неполноценно . По оценке «Информзащиты», доля инцидентов, в которых после распыления паролей фиксировались признаки дальнейшего движения по облачной среде, выросла с 18% в конце 2025 года до 27% в первом полугодии 2026 года, что говорит не только о росте количества атак, но и о большей «глубине» их развития внутри облачной инфраструктуры</p> <p>По отраслевой структуре чаще всего такие атаки затрагивают финансовые организации и страховые компании: на них приходится около 24% наблюдаемых случаев. ИТ-компании и сервисные провайдеры занимают 19%, ритейл и e-commerce — 17%, промышленность и логистика — 14%, профессиональные сервисы и консалтинг — 11%, образовательные организации — 8%, здравоохранение — 7%. У каждой отрасли свой фактор риска. В финансах атакующих привлекают платежные процессы и доступ к клиентским данным, в ИТ — возможность выйти на инфраструктуру заказчиков, в ритейле — высокая доля внешних сервисов и сезонные пики нагрузки, в промышленности — сложная сеть подрядчиков и удаленного доступа, что также говорит о том, что злоумышленники чаще переходят от проверки учетной записи к полноценному движению внутри облачной инфраструктуры.</p> <p>Разбивка по векторам атак показывает, что техника распыления паролей занимает около 38% попыток первичного доступа к корпоративным аккаунтам. На credential stuffing с использованием утекших баз приходится 24%, на атаки через устаревшие протоколы — 14%, на AiTM-фишинг и повторное использование токенов — 11%, на злоупотребление OAuth-разрешениями и device code flow — 7%, на MFA fatigue — 4%, на атаки через сервисные учетные записи, API-ключи и другие non-human identities — около 2%. Эти цифры показывают, что пароль остается удобной точкой входа, но сам инцидент почти всегда развивается шире: от проверки учетной записи до закрепления в почте, облаке или бизнес-приложении, поэтому фокус мониторинга только на этапе аутентификации уже недостаточен.</p> <p>Для снижения рисков компаниям в первую очередь следует отключать устаревшие протоколы там, где они не нужны бизнесу, вводить phishing-resistant MFA для привилегированных, финансовых и административных ролей, регулярно проверять корпоративные пароли на наличие в утечках и исключать повторное использование паролей между сервисами. Отдельного контроля требуют успешные входы после серии отказов, смена MFA-параметров, создание правил пересылки в почте, выдача OAuth-разрешений, входы с новых устройств и активность из нетипичных регионов. Простых блокировок по числу ошибок уже недостаточно: техника распыления паролей как раз рассчитана на обход таких порогов. Рабочая защита строится на корреляции событий, поведенческой аналитике, контроле сессий, инвентаризации сервисных учетных записей и быстрой проверке каждого успешного входа, которому предшествовала распределенная подозрительная активность. В противном случае атака так и останется в логах в виде набора несвязанных между собой «обычных» событий.</p> Эксперты компании «Информзащита» зафиксировали рост активности атак на корпоративные учетные записи с использованием … message https://www.itweek.ru/themes/detail.php?ID=234936 Tue, 02 Jun 2026 11:24:14 +0300 <p>Компания BSS и Федеральное государственное бюджетное образовательное учреждение высшего образования «Ижевский государственный технический университет имени М.Т. Калашникова» (ИжГТУ) заключили партнерское соглашение о сотрудничестве в сфере подготовки кадров для цифровой экономики.</p> <p>Партнерство направлено на интеграцию актуальных отраслевых знаний и практического опыта в образовательный процесс, а также на создание для студентов прямого пути к стажировкам и трудоустройству в технологической компании. Документ подписан в рамках исполнения требований постановления Правительства РФ и закрепляет долгосрочное взаимодействие вуза и ИТ-бизнеса.</p> <p>Взаимодействие сторон будет строиться на взаимовыгодных основах и конкретных обязательствах, нацеленных на практический измеримый результат. Сотрудничество сфокусируется на следующих направлениях:</p> <ol> <li>преподавание экспертов BSS в ИжГТУ. Специалисты компании — практики в области искусственного интеллекта, больших языковых моделей (LLM), технологии RAG и речевой аналитики — будут проводить лекции, практические занятия и мастер-классы для студентов ИжГТУ по ИТ-дисциплинам;</li> <li>стажировки и трудоустройство в BSS. Лучшие студенты получат возможность пройти стажировку в BSS с назначением персональных наставников и последующим рассмотрением кандидатур для трудоустройства;</li> <li>разработка образовательных программ. Эксперты BSS примут участие в актуализации рабочих программ дисциплин, программ практик и учебно-методических материалов, обеспечивая их соответствие актуальным требованиям рынка труда.</li> </ol> <p>«Для BSS образование — это стратегическая инвестиция в будущее отрасли. Мы видим высокий потенциал у студентов ИжГТУ и готовы делиться с ними экспертизой, накопленной за 30 лет разработки программного обеспечения и работы с крупнейшими предприятиями. Наши технологии — это не просто код, это решения, которые уже сегодня автоматизируют контакт-центры, улучшают клиентский опыт и трансформируют бизнес-процессы. Мы хотим, чтобы выпускники вуза приходили к работодателям с пониманием реальных задач и готовыми компетенциями», — отметил Георгий Кравченко, Генеральный директор BSS.</p> <p>Партнерство BSS, обладающей уникальной экспертизой, с ИжГТУ позволит студентам получить доступ к передовым технологиям ИИ, речевым платформам и современным инструментам по созданию ИИ-агентов и мультиагентных систем. Соглашение призвано способствовать укреплению связей между академическим сообществом и технологическим бизнесом, что критически важно для подготовки кадров для цифровой экономики.</p> <p>ИжГТУ имени М.Т. Калашникова — один из ведущих технических вузов Приволжского федерального округа, реализующий программы подготовки по IT-направлениям «Информационные системы и технологии», «Прикладная информатика», «Программная инженерия». Университет активно развивает цифровую образовательную среду и сотрудничает с индустриальными партнерами для обеспечения практической ориентированности обучения.</p> <p>«Цифровизация инженерного образования — наш приоритет. Партнерство с BSS открывает для студентов уникальную возможность работать с технологиями уровня enterprise, участвовать в реальных проектах и формировать портфолио еще до выпуска. Это именно тот формат „университет 4.0“, к которому мы стремимся», — подчеркнул заведующий кафедрой «Информационные системы» Максим Горохов, ответственный за взаимодействие с индустриальным партнером в лице BSS от ИжГТУ.</p> Компания BSS и Федеральное государственное бюджетное образовательное учреждение высшего образования «Ижевский … message https://www.itweek.ru/themes/detail.php?ID=234935 Tue, 02 Jun 2026 09:18:01 +0300 <p><em>В условиях роста сетевых заторов ИТ-командам необходимо сокращать дублирование инструментов, контролировать затраты и готовиться к AIOps и агентам искусственного интеллекта, пишет на портале </em><em>InformationWeek</em> <em>Мэри Шеклет, президент консалтинговой компании Transworld Data.</em></p> <p>Затор (logjam) определяется как «непреодолимое скопление или клубок логов», подобно тому, как бревна накапливаются в реке и перекрывают ее. В сети, которая сама по себе является рекой коммуникаций, сетевые сотрудники также сталкиваются со своего рода заторами.</p> <p>Они тонут в океане избыточных логов. Избыточное сетевое журналирование перегружает процессоры, переполняет память и сбивает с толку сетевых сотрудников, которые пытаются расшифровать, какие логи являются — и должны быть — пригодными для использования.</p> <p>Между тем, ежедневные заторы данных и рабочих процессов превращаются в более серьезную проблему, поскольку сетевые сотрудники стремятся объединить инструменты, которые стандартный сетевой мониторинг, наблюдаемость, AIOps и теперь агенты ИИ навязали им для мониторинга телеметрии и других сетевых событий на все более детальном уровне.</p> <p>Эти технологии пересекаются друг с другом, и дублирование приводит к неэффективному расходованию корпоративных ИТ-ресурсов. Как ИТ-службы могут контролировать затраты? И как сетевым сотрудникам избежать дублирования усилий, когда они все еще пытаются понять, какие инструменты следует использовать и для чего?</p> <h3>Понимание типов сетевых проблем, требующих решения</h3> <p>Современные ИТ-сети охватывают центральные ИТ-подразделения, периферийные узлы, облачные локации, а также удаленные домашние и полевые офисы. Стандартные инструменты мониторинга сети, которые до сих пор используются многими подразделениями, были разработаны для монолитных сетей, таких как единая корпоративная сеть масштаба предприятия. Они не могут справиться со сложностями гибридной сетевой топологии, выходящей за пределы предприятия.</p> <p>Подразделения это понимают, как и поставщики сетевого оборудования. И те, и другие видят необходимость обновления планов развития средств управления сетью, поскольку почти никто больше не работает с монолитными корпоративными сетями.</p> <p>Перед ними стоит вопрос: какие надлежащие инструменты и методологии следует обновить — и какие существующие инструменты можно исключить?</p> <h3>Навигация по инструментам</h3> <p>Существуют четыре категории инструментов мониторинга и предотвращения сбоев в сети:</p> <ol> <li><strong> Стандартный мониторинг сети. </strong>Стандартный мониторинг сети самодостаточен, поскольку это зрелая технология, и сотрудники хорошо с ней знакомы. Он использует метрики сетевого трафика, использования ЦП и ресурсов хранения, допустимых ошибок и времени отклика, но ИТ-специалисты должны предварительно определить эти метрики. Инструменты мониторинга выдают оповещения, когда происходит превышение этих предопределенных метрик, и затем задача ИТ-специалистов — найти и устранить проблемы.</li> <li><strong> Наблюдаемость. </strong>Стандартный мониторинг сети недостаточен, поскольку он сообщает только о том, что ИТ-специалисты предварительно для него определили. Наблюдаемость идет глубже. Она сообщает не только о нарушениях метрик, но и о том, где и почему произошло нарушение. Она предоставляет эту информацию, анализируя метрики, журналы и трассировки — и соответствующее ПО может делать это автономно. Это дает ИТ-специалистам преимущество в решении проблем.</li> <li><strong> AIOps. </strong>Цель AIOps — расширить возможности наблюдаемости за счет применения ИИ и автоматизации для решения проблем. Недостаток AIOps заключается в том, что при анализе данных эта методология имеет ограниченное представление о контексте сетевого события. Она даже не может определить, являются ли анализируемые телеметрические данные достоверными. Именно здесь по-прежнему должна вмешиваться ИТ-служба, поскольку для подтверждения достоверности результатов AIOps и применения исправлений требуются специалисты по сетям.</li> <li><strong> Сетевые ИИ-агенты.</strong> Новая волна инструментов в виде сетевых ИИ-агентов пытается еще больше автоматизировать решение проблем там, где есть необходимость вмешательства сетевого персонала. ИИ-агенты автоматически обнаруживают и устраняют проблемы. Они делают это, используя машинное обучение для изучения истории производительности сети, чтобы получить бизнес-контекст того, как сеть должна функционировать.</li> </ol> <h3>Пять лучших практик управления переходом</h3> <p>Переход от стандартного мониторинга сети к наблюдаемости, затем к AIOps, а затем к сетевым ИИ-агентам — это естественное развитие ПО для управления сетями. Компании и поставщики это понимают, поэтому была определена эволюционная дорожная карта управления сетями.</p> <p>Но прежде чем они смогут приступить к реализации этой дорожной карты с использованием новых технологий, компании должны оценить, на каком этапе пути они находятся с точки зрения инструментов, персонала, бизнес-требований и затрат. Вот пять лучших практик:</p> <p><strong>1. Оцените свой текущий набор инструментов. </strong>Для многих сотрудников ИТ-подразделений, занимающихся сетевыми технологиями, разбор используемых в настоящее время инструментов — и тех, которые были забыты и лежат на полке — является колоссальной задачей. Но сейчас самое время этим заняться.</p> <p>Инструменты управления сетью должны быть учтены во всех сетях предприятия, независимо от того, находятся ли сети локально в дата-центре, на периферии предприятия или в облаке.</p> <p>Инструменты должны быть классифицированы по функциям, чтобы исключить любые дублирования. Если разные инструменты используются для одних и тех же функций в разных местах сети, эти инструменты должны быть стандартизированы в единый набор инструментов. Это упростит работу персонала, уточнив, какие инструменты следует использовать и как проводить обучение.</p> <p><strong>2. Встретьтесь с поставщиками для оценки их планов развития.</strong> Часть процесса инвентаризации и оценки инструментов — это взаимодействие с поставщиками инструментов, чтобы узнать, в каком направлении они движутся со своими планами развития.</p> <p>План развития средств управления сетью ясен: от стандартного мониторинга сети к наблюдаемости, затем к AIOps и, наконец, к сетевым ИИ-агентам.</p> <p>Если у поставщиков эта эволюция не отражена в их планах, пора искать тех, у кого она отражена.</p> <p><strong>3. Займитесь повышением квалификации персонала по AIOps. </strong>Большинство сотрудников, занимающихся корпоративными сетями, хорошо владеют стандартным мониторингом и уже работают с наблюдаемостью.</p> <p>Следующий шаг — внедрение автоматизации в наблюдаемость с помощью AIOps, что все еще находится в процессе, поскольку требует перестройки и, в некоторых случаях, переосмысления рабочих процессов сети.</p> <p>Сетевые сотрудники должны изучить новые инструменты AIOps, а также способы интеграции дополнительной AIOps-автоматизации в рабочие процессы сети и повседневные операции.</p> <p>Эти изменения должны быть задокументированы, а документация — слабое место в сетевых операциях.</p> <p>Чтобы обеспечить соответствие оперативной документации изменениям в рабочих процессах, целесообразно привлечь внешних аудиторов для проверки документации и операций, чтобы выявить и исправить любые несоответствия.</p> <p><strong>4. Очень осторожно внедряйте агентов ИИ. </strong>Концепция полностью автоматизированных сетевых операций с использованием агентов ИИ пока остается скорее теорией, чем фактом.</p> <p>Тем не менее, некоторые организации уже пробуют свои силы в этом направлении.</p> <p>Сетевые агенты ИИ используют машинное обучение для изучения прошлой производительности сети, чтобы получить бизнес-контекст для своей автоматизации. Но у них нет практических знаний и опыта, которыми обладают сотрудники сетевой службы.</p> <p>Рекомендуется первоначально внедрять сетевых ИИ-агентов в хорошо предсказуемых и контролируемых сетях с низким риском изменений или аномалий.</p> <p><strong>5. Оцените ценность унаследованных технологий. </strong>Унаследованные технологии означают не только старость, но и проверенность, надежность и долговечность.</p> <p>Существуют инструменты управления сетью, которые выдержали испытание временем и продолжают хорошо работать.</p> <p>При анализе имеющихся инструментов организациям следует внимательно изучить, что продолжает приносить пользу. Безусловно, следует совершенствовать инструменты и навыки, но не стоит выбрасывать то, что по-прежнему хорошо работает.</p> В условиях роста сетевых заторов ИТ-командам необходимо сокращать дублирование инструментов, контролировать затраты … article https://www.itweek.ru/themes/detail.php?ID=234933 Tue, 02 Jun 2026 09:04:12 +0300 <p>Представьте типичную ситуацию: компания закупает корпоративный ИИ-инструмент, проводит обучение, запускает пилот. Через три месяца — <nobr>5-10%</nobr> активных пользователей, остальная команда возвращается к привычным инструментам. Формально внедрение состоялось, но реального эффекта нет.</p> <p>По данным McKinsey   Company, большинство компаний до сих пор не получают системного результата от внедрения ИИ, несмотря на рост инвестиций. И дело здесь не в качестве самих инструментов.</p> <p>Главная причина в другом: то, что принято называть «саботажем», на самом деле является рациональной реакцией системы на плохо выстроенное внедрение.</p> <p>Сотрудники не игнорируют ИИ — они выбирают способ работы, который дает предсказуемый результат и не создает дополнительных рисков. Чтобы понять это поведение, важно посмотреть не только на людей, но и на то, как именно компания внедряет изменения.</p> <h3>Саботаж — это не проблема сотрудников</h3> <p>В большинстве компаний саботаж объясняют через психологию: страх, нежелание меняться, сопротивление новому. На практике это поверхностное объяснение.</p> <p>Сотрудник не обязан использовать инструмент только потому, что он «внедрен». Он оценивает его с точки зрения своей ежедневной работы: ускоряет ли инструмент задачи, снижает ли риски ошибок, делает ли результат более предсказуемым.</p> <p>Если ответ отрицательный, отказ от использования — рациональный выбор.</p> <p>Поэтому не стоит считать саботаж сбоем в поведении людей. Это сигнал: система внедрения ИИ не создает достаточной ценности в реальной работе.</p> <h3>Почему люди не доверяют ИИ</h3> <p>Ключевая причина сопротивления кроется не в страхе как таковом — все дело в незнании. Человек не понимает, как новый инструмент работает, где допускает ошибки, можно ли ему доверять. В такой ситуации любое использование ИИ воспринимается как риск, и первое же закономерное желание, которое возникает у сотрудника — отказаться от него вовсе.</p> <p>Это универсальный механизм: люди боятся не технологий, а неопределенности. Чем лучше человек понимает систему, тем ниже уровень сопротивления. И наоборот — отсутствие понимания почти неизбежно приводит к отказу от использования.</p> <h3>Два типа сотрудников</h3> <p>После появления ИИ команды почти всегда делятся на две группы. Первая — любопытные. Они начинают экспериментировать, тестируют сценарии, адаптируют инструмент под свои задачи и быстро усиливают свою эффективность.</p> <p>Вторая — нелюбопытные. Они не пытаются разобраться, занимают позицию «докажите, что это работает» и в итоге выпадают из процесса.</p> <p>Это не вопрос квалификации — это вопрос поведения. И именно от соотношения этих двух групп во многом зависит успех внедрения. Если нелюбопытных сотрудников оказывается больше, внедрить новую технологию очень тяжело. Речь не только об ИИ — такие члены команды, как правило, не заинтересованы в любых изменениях.</p> <h3>Главный риск — не сотрудники, а руководство</h3> <p>Отдельный специалист в команде может не использовать ИИ. Система это переживет — и, более того, однажды просто «переварит» такого человека, потому что он закономерно будет отставать от остальных.</p> <p>Если же внедрению искусственного интеллекта сопротивляется руководитель, ситуация сразу осложняется. Он задает норму, от его действий не в последнюю очередь зависит, как быстро сотрудники освоят новую технологию. Когда руководитель сам не применяет ИИ в работе и не верит в него, инициативы будут блокироваться, а внедрение фактически остановится.</p> <p>Поэтому основная трудность — не сопротивляющиеся сотрудники, а отсутствие поддержки изменений на уровне управления.</p> <h3>Как проявляются психологические барьеры</h3> <p>Психологические барьеры сотрудников, которые стоят между ними и освоением ИИ, выражаются в виде поведенческих сигналов. Если научиться их распознавать, будет легко понять, что именно тревожит члена команды.</p> <ul> <li> Страх потери экспертизы. Сотрудники опасаются, что их знания обесценятся. Это снижает готовность делиться опытом и пробовать новые инструменты.</li> <li> Недоверие к качеству результатов. Разовые ошибки или галлюцинации быстро формируют устойчивое ощущение, что инструмент требует больше времени на проверку, чем дает выгоды.</li> <li> Страх контроля. Если непонятно, что логируется и как используется, сотрудники начинают избегать корпоративных инструментов.</li> <li> Усталость от изменений. Каждый новый инструмент требует времени на освоение. Без явной ценности он воспринимается как дополнительная нагрузка.</li> </ul> <p>Важно, что эти препятствия усиливаются, если компания не задает понятных правил и сценариев работы.</p> <h3>Организационные барьеры: где ломается система</h3> <p>Возможно, сотрудники готовы активно использовать ИИ, но система не дает им делать это эффективно. Можно выделить несколько основных трудностей:</p> <ul> <li> Нет владельца со стороны бизнеса. Типичная ситуация: «ИТ внедрило, бизнес не использует». Без бизнес-владельца инструмент не привязан к реальным задачам.</li> <li> Нет четких сценариев использования. Формулировка «давайте внедрим ИИ» не работает — нужны конкретные кейсы с понятными метриками.</li> <li> Инструмент не встроен в процессы. Отдельный чат-бот почти всегда проигрывает привычным инструментам. ИИ должен работать внутри CRM, IDE или документов.</li> <li> Нет данных и контекста. Без доступа к корпоративным знаниям ИИ дает общие ответы, которые требуют ручной проверки.</li> <li> Безопасность блокирует внедрение. Если правила появляются в конце, запуск останавливается на этапе согласований.</li> <li> Нет поддержки после запуска. Разовое обучение не работает. Без постоянной помощи сотрудники возвращаются к старым инструментам.</li> <li> Неверные метрики. MAU показывает активность, но не эффективность. Важно измерять влияние на процесс: скорость, качество, нагрузку.</li> </ul> <h3>Почему «хорошая технология» не становится инструментом</h3> <p>Даже сильные решения не приживаются без системной встройки.</p> <p>Во-первых, у инструмента часто нет конкретной «работы», которую он должен выполнять. Он воспринимается как универсальный помощник, но не решает конкретную задачу.</p> <p>Во-вторых, пилот не превращается в процесс. На этапе тестирования все держится на энтузиастах, но после запуска отсутствуют роли, правила и поддержка.</p> <p>В-третьих, отсутствуют стимулы. Если KPI не меняются, сотрудники продолжают работать по-старому — это логично.</p> <p>И, наконец, нет итераций. Промпты, сценарии и базы знаний не улучшаются, и качество быстро перестает соответствовать ожиданиям.</p> <h3>Все упирается в управление изменениями</h3> <p>Ключевая проблема большинства внедрений в том, что ИИ воспринимается как инструмент, а не как изменение системы. Тогда как при трансформации по правилам change management, или управления изменениями, было бы правильно:</p> <ul> <li> сформировать рабочую группу;</li> <li> задать план внедрения;</li> <li> определить метрики;</li> <li> выделить бюджет и время;</li> <li> назначить ответственных.</li> </ul> <p>В результате команда получает новый инструмент, но не новую норму работы. А успех внедрения зависит именно от нормы — от того, донесут ли ее принципы и правила до команды, сможет ли команда приспособиться к ее условиям.</p> <h3>Как вести себя лидеру</h3> <p>Любое внедрение ИИ — это управляемое изменение, и у него должен быть лидер. Его задача заключается не в том, чтобы пассивно ждать, пока команда разберется сама и освоит новую технологию. Лидер задает направление — а значит, формулирует правила, объясняет, где и как использовать искусственный интеллект, поддерживает команду на этапе адаптации.</p> <p>Важно, что на этом этапе лидер фактически «верит за команду». Сотрудники могут относиться к идее внедрить ИИ скептически и быть не готовыми к изменениям, и задача лидера — зарядить их, направить в нужное русло. Если он сам не настроен на перемены, ничего не выйдет.</p> <h3>Нужно помнить, что сопротивление — нормальная часть процесса</h3> <p>Любая система сопротивляется изменениям, это не сбой. Очень редко бывает так, что людям предлагают попробовать что-то новое, и они сразу же радостно соглашаются.</p> <p>В случае с внедрением ИИ возможны два варианта развития событий:</p> <ul> <li> сотрудники начинают активно использовать ИИ-инструменты, адаптируются, наращивают экспертизу и усиливаются;</li> <li> сотрудники продолжают игнорировать изменения, отказываются от них — и в итоге выходят из системы, потому что становятся для нее либо слабым звеном, которое справляется со своими задачами, просто работает медленнее остальных, либо балластом, которые вообще не могут поддерживать темп команды.</li> </ul> <p>Компании, которые достигают успехов, учитывают это заранее и строят процессы с учетом неизбежного сопротивления.</p> <h3>Что в итоге</h3> <p>Саботаж искусственного интеллекта — это не проблема сотрудников и не признак их нежелания меняться. Это следствие того, что система не дает им понятного и безопасного способа, как использовать на практике новый инструмент.</p> <p>Важно помнить, что ИИ внедряется через процессы, новые нормы и грамотное управление изменениями. Здесь недостаточно обучения и лицензий хотя бы потому, что невозможно заставить сотрудников учиться, если они этого не желают.</p> <p>Без правильного внедрения команда возвращается к проверенным вариантам — тому, что работает. И будет странно требовать от них иного.</p> <p>#IMAGE_234934#</p> Представьте типичную ситуацию: компания закупает корпоративный ИИ-инструмент, проводит обучение, запускает пилот. Через три … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=234928 Mon, 01 Jun 2026 13:30:21 +0300 <p>Центр стратегических разработок опубликовал ежегодное исследование российского рынка информационной безопасности по итогам 2025 года и подготовил прогноз его развития до 2031 года. По оценке экспертов, рынок сохраняет устойчивую положительную динамику — выше среднемировых показателей и темпов роста большинства сегментов российского ИТ-сектора.</p> <p>«Рынок информационной безопасности в России демонстрирует стабильный рост. По итогам 2025 года рост составил 16,1% по сравнению с годом ранее. Это превышает глобальные тенденции и динамику большинства сегментов российского ИТ-сектора. Если текущие условия сохранятся, то к 2031 году рынок может превысить 1 трлн рублей, а среднегодовой темп роста в период с 2026 по 2031 годы составит 19,4%», — отметила заместитель генерального директора ЦСР Екатерина Кваша.</p> <p>Основу рынка формируют средства защиты информации (СЗИ) — 74% совокупного объема, или 271 млрд рублей (+18,1%). Крупнейшие категории — сетевая безопасность, защита инфраструктуры и защита конечных точек. Наибольшие темпы роста (+45,6 п.п. год к году) зафиксированы в сегменте защиты приложений (application security), что указывает на повышение значимости обеспечения безопасности прикладных контуров. Рынок услуг ИБ достиг 93,5 млрд рублей (+10,7%): острый дефицит квалифицированных специалистов продолжает стимулировать спрос на управляемые сервисы — MSS, MDR, SOC-as-a-Service.</p> <p>По объемам продаж средств защиты информации лидирует «Лаборатория Касперского» с долей 20,1% рынка (+0,5 п.п. год к году). Наиболее заметное усиление позиций показала Positive Technologies: доля компании выросла на 3,2 п.п., составив 16,8%. Среди ключевых игроков также ГК «Солар» и BI.ZONE, специализирующиеся на сервисах ИБ, и производители средств сетевой безопасности — «ИнфоТеКС», «Код Безопасности» и UserGate. Доля отечественных поставщиков на рынке СЗИ превысила 94%.</p> <p>В целом, российский рынок кибербезопасности сохраняет устойчивую положительную динамику сразу по нескольким направлениям. Первоначальная волна импортозамещения — когда организации в срочном порядке закрывали разрывы в защитном контуре — сменяется более зрелым подходом: компании переходят к системной перестройке ИБ-архитектур с акцентом на управляемость, интегрированность и доказуемую эффективность вложений. Параллельно меняется само восприятие кибербезопасности: из набора технических мер она превращается в элемент операционной устойчивости бизнеса — способность выдерживать атаки, сохранять непрерывность процессов и минимизировать финансовый ущерб.</p> <p>Дефицит кадров и регуляторное давление усиливают спрос на управляемые сервисы и платформенные решения, позволяющие быстро получить доступ к экспертизе без создания дорогостоящей внутренней инфраструктуры. Активное внедрение облачных технологий и ИИ расширяет цифровые возможности организаций, но одновременно увеличивает поверхность атаки и формирует новые классы рисков, требующих соответствующих подходов к защите.</p> Центр стратегических разработок опубликовал ежегодное исследование российского рынка информационной безопасности по итогам … message https://www.itweek.ru/themes/detail.php?ID=234926 Mon, 01 Jun 2026 00:00:00 +0300 <p>Многие компании верят: если мы внедрили CI/CD и наняли десяток DevOps-инженеров, мы стали Agile. На практике же TTM (Time-to-Market) часто не только не падает, но и растет. Почему? Потому что была совершена подмена понятий. Изначально, DevOps задумывался как способ <em>стереть границу</em> между кодом и инфраструктурой, сократить время ожидания разработчика на готовое окружение для разработки. В итоге мы построили новую <em>«админскую стену»,</em> только теперь обложенную YAML-файлами.</p> <p>В среде современного DevOps часто господствует «админский» подход. Люди месяцами спорят о выборе между Terraform, Pulumi, Helm, Kustomize или Ansible, выбирая «марку молотка», в то время как дом всё ещё не построен, а чертежи никто не видел. Забывается главная цель DevOps — сокращение TTM. Если выбор инструмента не ускоряет доставку фич, спор становится пустым: ресурсы тратятся на освоение инструментария, а не на доставку ценности. Такой подход заставляет внедрять решение просто потому, что команда его знает, а не потому, что оно оптимально (например, тащить Ansible туда, где достаточно простого Containerfile или Dockerfile). В этих спорах теряется принцип Shared Responsibility: важно не то, насколько красив манифест, а может ли разработчик самостоятельно внести в него правки, не дожидаясь администратора.</p> <p>Проблема усугубляется еще тем фактом, что многие компании создают «DevOps-подразделения», которые на самом деле являются просто отделами администрирования. Нередко это происходит так: руководство читает отчеты Gartner и видит, что «успешные компании используют Kubernetes и Terraform». В итоге покупается дорогой «молоток», нанимаются «мастера молотка», но гвоздей в компании нет. Инженерам приходится придумывать себе работу, создавая сложнейшие абстракции над простыми вещами, чтобы оправдать свое существование. Нередко автоматизируются те процессы, которые вообще не должны были существовать, или тратится время на написание сложных абстракций в каком-нибудь Helm, которые никто кроме автора не может понять. Но DevOps — это про коммуникацию, а не про то, как вы лихо умеете писать плейбуки в Ansible.</p> <p>Между тем, мы убили SysOps, заменив его эфемерным DevOps’ом. В компаниях, где нет своего кода, своей разработки, мы наблюдаем парад абсурда: люди внедряют технологии для <em>Continuous Deployment</em> туда, где деплоить нечего. Тратятся бюджеты на поддержку инфраструктуры для автоматизации самой автоматизации, стыдливо избегая честного слова «эксплуатация». Сейчас, признать, что вам нужен просто надежный SysOps — значит разрушить сложившийся миф и признать, что половина ваших модных инструментов — это просто балласт.</p> <p>Признать, что вам нужен качественный SysOps вместо карго-культового DevOps — это не шаг назад. Это шаг к эффективности. Ведь в конечном итоге бизнесу нужны работающие сервисы, а не красивые графики в ArgoCD, за которыми скрывается пустота.</p> <p>А что же не так с компаниями, в которых явно присутствует этап разработки программного обеспечения, теми компаниями, которые можно смело отнести к ISV? В компаниях-разработчиках админский DevOps нередко превращается в изощренную форму саботажа. Здесь выбор «марки молотка» напрямую бьет по прибыли: пока инженеры по эксплуатации полируют свои идеальные пайплайны, разработчики бьются лбом об ограничения инфраструктуры, которые им навязали «для их же блага». В итоге мы получаем продукт, который оброс костылями не из-за плохого кода, а из-за того, что его пытались засунуть в чуждую ему, избыточно сложную среду.</p> <p>Почему же DevOps стал инструментом администраторов, ведь CI/CD задумывался как способ дать разработчику контроль над доставкой кода (Self-Service)? Одна из причин заключается в том, что технологический порог входа стал так высок, что инструмент оказался в руках специалистов по инфраструктуре. Разработчикам становится всё сложнее поддерживать YAML-файлы на тысячи строк, они теперь должны быть наполовину системными программистами. Вместо написания бизнес-логики разработчики ПО вынуждены изучать HCL, копаться в репозиториях инфраструктуры и ждать завершения CI/CD-пайплайна, который падает из-за лишнего пробела. Кроме того, на российском рынке в крупных корпорациях (банки, госсектор) разделение на «тех, кто пишет» и «тех, кто катит» до сих пор сильнее, чем на Западе, из-за жестких требований безопасности и бюрократии. К тому же сложившийся дефицит кадров привел к тому, что проще нанять одного «звездного» DevOps-инженера, который настроит всё для десятка разработчиков, чем обучать всю команду нюансам инфраструктуры. В итоге, для разработчика программного обеспечения самообслуживание превратилось в самоистязание.</p> <p>В современных условиях DevOps-команда должна перестать быть «обслуживающим персоналом» или «хранителями ключей». Она должна стать <em>продуктовой командой</em>, чей продукт — это платформа, а ее клиент — это разработчик ПО. Целью должно стать создание условий, чтобы разработчик мог развернуть необходимый ему сервис, не вникая в YAML-описания конфигурации развертывания, без знания какая «марка молотка» использована под капотом. Необходимо выстраивание Internal Developer Platform (IDP), где разработчик нажимает кнопку «Создать среду» и получает готовое окружение за минуты, а не часы или даже дни. Необходимо перестать мерить успех количеством «закрытых тикетов» или «написанных скриптов». Метрикой успеха должно стать время, потраченное разработчиком на инфраструктуру. Если он тратит более 5% — модель DevOps убыточна. Переход к платформенной модели способен сократить цикл разработки с недель до часов. Это прямое снижения операционных расходов и реальный рывок в капитализации.</p> <p>Автоматизация ради автоматизации — это дорогое хобби, которое бизнес больше не может себе позволить. Настоящий DevOps начинается не с выбора между Terraform и Pulumi, а с вопроса: «Как это изменение поможет нам доставлять код быстрее и надежнее?». Если внедрение нового инструмента увеличивает TTM и строит новые заборы между командами — значит, вы просто сменили вывеску «Системное администрирование» на более модную, сохранив старые проблемы. Пора перестать коллекционировать «молотки» и начать, наконец, забивать гвозди. Чтобы ваша автоматизация не превратилась в «новые грабли», проведите ревизию процессов прямо сейчас:</p> <ul> <li> <strong>Упрощайте.</strong> Если задачу можно решить простым Containerfile, не тащите туда сложный Helm.</li> <li><strong>Стирайте границы</strong>. Разработчик должен иметь возможность сам управлять окружением. Используйте rootless-решения, которые позволяют запускать контейнеры без прав суперпользователя — это дает командам автономность, не создавая дыр в безопасности и лишних тикетов на админов.</li> <li><strong>Считайте метрики.</strong> Главный показатель успеха — это сокращение времени от идеи до выпуска в промышленную эксплуатацию, а не количество закрытых задач по автоматизации. DevOps — это мост, а не новая стена. Не дайте технологическому стеку стать препятствием на пути к здравому смыслу.</li> </ul> <p>#IMAGE_234927#</p> Многие компании верят: если мы внедрили CI/CD и наняли десяток DevOps-инженеров, мы стали Agile … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=234925 Mon, 01 Jun 2026 00:00:00 +0300 <p><em>Поскольку агентов ИИ на порядки больше, чем людей, устаревшие системы безопасности дают сбой. Джастин Долли, директор по работе с клиентами и безопасности компании Ory, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как защитить свою инфраструктуру с помощью системы управления идентификацией и доступом агентов (</em><em>Agent</em> <em>IAM).</em></p> <p>Переход от традиционных веб-приложений к агентным экосистемам — это не просто изменение пользовательского интерфейса; это фундаментальный сдвиг в модели угроз Интернета. Мы переходим из мира, где неправильный ввод создает неправильные данные, в мир, где неправильный ввод создает неправильные действия. В условиях, когда агенты ИИ эволюционируют от простых чат-ботов до автономных контроллеров, способных вызывать API, читать конфиденциальные файлы и отправлять электронные письма, наши устаревшие модели безопасности не выдерживают давления.</p> <p>Поскольку агентов уже на порядки больше, чем людей, если вы сегодня создаете или развертываете агентов ИИ, вы, вероятно, сталкиваетесь с замаскированной проблемой IAM. Согласно недавнему глобальному опросу Enterprise Management Associates (EMA) «Agentic AI Identities», 95% респондентов используют ИИ-агентов в производственной среде или ограниченных пилотных программах.</p> <p>Рассмотрим, как осуществить переход от человекоцентричной безопасности к эре Agent IAM.</p> <h3>1. В чем проблема: идентификационный вакуум</h3> <p>Основная проблема заключается в том, что агенты ИИ в настоящее время работают в условиях идентификационного вакуума. В большинстве производственных сред агентам предоставляется общий, унаследованный доступ. Они работают как служебные учетные записи с широкими правами доступа или, что еще хуже, наследуют полные права доступа пользователя, который их запустил.</p> <p>Это создает три критические уязвимости:</p> <ul> <li><strong> Модель угроз, основанная на действиях (</strong><strong>Action</strong><strong>-</strong><strong>Based</strong> <strong>Threat</strong> <strong>Model</strong><strong>).</strong> В отличие от традиционных приложений, агенты что-то «делают». Если большую языковую модель (LLM) обманут с помощью инъекции промпта, она не просто отобразит неправильный ответ; она выполнит вызов вредоносного инструмента. 80% респондентов <a href="https://www.osohq.com/learn/why-your-authorization-model-wont-survive-agentic-ai">сообщают</a> о случаях, когда приложения действуют за пределами предполагаемых границ.</li> <li><strong> Поверхность атаки системы RAG. </strong>Системы генерации с расширенной выборкой (RAG) уязвимы для косвенной инъекции промптов. Если агент получает документ, содержащий вредоносные инструкции, этот документ становится новым владельцем («мастером») агента, игнорируя меры защиты разработчиков.</li> <li><strong> Взрывной рост использования нечеловеческих идентификаторов (NHI).</strong> Мы наблюдаем массовый всплеск роста API, сервисов и автономных агентов, которым не хватает централизованного источника достоверной информации об идентификации. 39% респондентов опроса SailPoint «AI agents: The new attack surface» сообщают об инцидентах несанкционированного доступа агентов, и у большинства команд нет возможности отозвать доступ отдельного агента, не нарушив работу всего сервиса.</li> </ul> <h3>2. Почему это важно: растущий разрыв в устранении уязвимостей</h3> <p>Недавнее появление Claude Mythos от Anthropic <a href="https://www.ory.com/blog/anthropic-mythos-iam-identity-security-risk">повысило ставки</a>. Модель выявила тысячи уязвимостей нулевого дня в основных ОС и браузерах, включая ошибки, которые пережили более 20 лет проверки людьми.</p> <p>Это важно, потому что ИИ теперь является множителем силы для обнаружения уязвимостей. Хотя ИИ может находить ошибки со скоростью машины, люди по-прежнему устраняют их в «человеческом темпе» (совещания, бэклоги, циклы обновления).</p> <p>Если ваша инфраструктура IAM является собственной разработкой или неуправляемым Open Source, вы не сможете достаточно быстро обновлять ее, чтобы угнаться за злоумышленником, использующим ИИ. Идентификация — наиболее уязвимый уровень, поскольку это плоскость управления; если идентификация агента скомпрометирована, вся инфраструктура становится открытой для горизонтального перемещения. Исследование SailPoint показывает, что 33% респондентов сталкивались с ненадлежащим обращением агентов с данными с ограничен доступом.</p> <h3>3. Как решить проблему: план управления идентификацией и доступом для агентов</h3> <p>Для решения проблемы агентной безопасности необходимо перенести ограничительные механизмы с <nobr>LLM-промптов</nobr> на инфраструктуру. Вы не можете уговорить агента действовать безопасно; вы должны авторизовать его действовать безопасно. Усугубляет проблему агентной безопасности тот факт, что большинство участников опроса EMA считают, что их IAM-решения не готовы к новой реальности:</p> <ul> <li> 62% заявляют о неготовности к отказоустойчивости агентов;</li> <li> 49% утверждают, что не готовы к соответствию нормативным требованиям для агентов;</li> <li> 62% сообщают о неготовности к масштабируемости агентов;</li> <li> 59% заявляют о неготовности к безопасности агентов.</li> </ul> <p><strong>Относитесь к агентам как к первоклассным идентификаторам. </strong>Агенты должны рассматриваться как первоклассные нечеловеческие идентификаторы. Это означает:</p> <ul> <li><strong> Аутентификация.</strong> Агенты должны проходить аутентификацию у провайдера идентификации, используя учетные данные с ограниченной областью действия.</li> <li><strong> Токены с коротким сроком действия.</strong> Используйте OAuth2 для выдачи токенов, ограниченных областью взаимодействия. Если агент скомпрометирован, токен быстро истекает, ограничивая окно эксплуатации уязвимости.</li> <li><strong> Управление доступом на основе отношений (ReBAC).</strong> Используйте модель разрешений на основе графа, чтобы точно определить, к чему может получить доступ агент.</li> <li><strong>Согласование извлечения с авторизацией. </strong>В системах RAG разрешение на «просмотр» должно соответствовать разрешению на «извлечение». Прежде чем агент получит документ для размещения в его контекстном окне, система должна проверить: имеет ли этот конкретный Agent ID разрешение на просмотр этого Document ID? Если нет, документ никогда не будет получен, что предотвратит просмотр агентом вредоносного кода и его воздействие на него.</li> <li><strong>Инженеры как дирижеры. </strong>Измените свой инженерный подход. Перестаньте пытаться жестко запрограммировать каждое действие агента. Вместо этого действуйте как дирижер, управляя агентами с помощью политики как кода. Используйте инструменты для визуализации этих сложных цепочек разрешений, чтобы точно видеть, как отношения между агентами разрешаются в «РАЗРЕШИТЬ» или «ОТКАЗАТЬ».</li> </ul> <h3>Подводные камни и как их избежать</h3> <p>Даже при наличии продуманного плана часто возникают скрытые издержки и технические ловушки:</p> <ul> <li><strong> Ловушка унаследованного доступа:</strong> <ul> <li> Проблема: разработчики часто предоставляют агентам права администратора для упрощения разработки.</li> <li> Решение: внедрите принцип минимальных привилегий с самого начала. Если агенту нужно только читать маркетинговые документы, не предоставляйте ему доступ ко всему бакету S3.</li> </ul> </li> <li><strong> Задержка обратной связи:</strong> <ul> <li> Проблема: по мере добавления уровней безопасности задержка агента увеличивается, что заставляет пользователей обходить безопасность ради скорости.</li> <li> Решение: используйте высокопроизводительные механизмы управления разрешениями, которые могут обрабатывать сложные запросы за миллисекунды, гарантируя, что безопасность не ухудшает пользовательский опыт.</li> </ul> </li> <li><strong> Агенты-призраки:</strong> <ul> <li> Проблема: агенты создаются для задачи, задача завершается, но учетные данные остаются активными.</li> <li> Решение: внедрите автоматическое управление жизненным циклом. Используйте отзыв цепочки токенов, чтобы, если родительский агент-оркестратор помечен как проблемный, все токены дочерних агентов мгновенно аннулировались.</li> </ul> </li> <li><strong> Слепота:</strong> <ul> <li> Проблема: модели разрешений для сотен агентов становятся слишком сложными для восприятия человеком.</li> <li> Решение: используйте инструменты визуализации для аудита ваших моделей. Если вы не видите граф, вы не можете обеспечить его безопасность.</li> </ul> </li> </ul> <h3>Резюме: идентификация — это отправная точка</h3> <p>Безопасность — это процесс, а не продукт. Хотя ограничительные механизмы LLM и защита на уровне промптов важны, их легко обойти. Единственная жесткая граница, которая остается неизменной перед лицом автономного агента, — это граница авторизации.</p> <p>Относитесь к своим агентам как к идентификаторам, определяйте их окружение с помощью ReBAC и обеспечьте профессиональное управление вашим стеком IAM, чтобы идти в ногу с темпами обнаружения, обусловленными ИИ. Будущее Интернета связана с агентами; убедитесь, что ваша безопасность тоже.</p> Поскольку агентов ИИ на порядки больше, чем людей, устаревшие системы безопасности дают сбой. Джастин Долли, директор … article