itWeek https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif itWeek https://www.itweek.ru M1Cloud: какие специалисты востребованы на облачном рынке в 2026 году https://www.itweek.ru/themes/detail.php?ID=235037 Thu, 18 Jun 2026 18:00:55 +0300 <p>Российский облачный рынок продолжает расти. По оценке M1Cloud, по итогам 2025 года его объем оценивался примерно в 400 млрд рублей, а в 2026 году рынок может сохранить темпы роста не ниже 30%. На этом фоне рынок труда в ИТ перестраивается: в марте 2026 года количество активных вакансий в профобласти «Информационные технологии» на hh.ru снизилось на 37% год к году, тогда как число активных резюме выросло на 29%. Массовый найм стал осторожнее, но спрос на специалистов, которые помогают бизнесу переносить критичные системы в облака, внедрять ИИ, управлять затратами и защищать инфраструктуру, сохраняется.</p> <p>Дмитрий Соловьёв, технический директор M1Cloud, рассказал, что в 2026 году рынку нужны не просто администраторы виртуальных машин: заказчики ждут от провайдера экспертизу на стыке инфраструктуры, ИИ, безопасности и экономики облака, а также объяснил, почему облачные команды будут конкурировать за специалистов, которые умеют превращать сложные технологические платформы в управляемый, безопасный и экономически понятный сервис для бизнеса.</p> <p>Спрос на кадры, связанные с ИИ, растет быстрее среднего по рынку. По данным hh.ru, в 2025 году количество вакансий для <nobr>ML-инженеров</nobr> выросло со 135 до 396, для AI-инженеров — со 164 до 290. Для облачного рынка это означает рост запросов на GPUaaS: бизнесу нужны ресурсы для обучения моделей, но покупка и эксплуатация GPU-оборудования на собственной площадке часто экономически нецелесообразна. Поэтому провайдерам нужны инженеры, которые проектируют и администрируют GPU-кластеры, настраивают сетевую инфраструктуру и системы хранения под высокую нагрузку, управляют контейнерными средами, MLOps-инструментами и интеграцией ИИ-сервисов в инфраструктуру заказчиков.</p> <p>Рост облачных бюджетов требует управления стоимостью, а не только контроля счета. В неуправляемых средах часть расходов возникает из-за простаивающих ресурсов, избыточно выбранных конфигураций, дублирования сервисов и отсутствия правил потребления. FinOps объединяет финансы, ИТ и бизнес-команды: специалисты анализируют потребление, распределяют затраты по проектам, помогают выбирать модели потребления и резервирования ресурсов, выстраивают бюджетирование и прогнозирование. По данным State of FinOps 2026, практика вышла за пределы публичного облака: 90% FinOps-команд управляют или планируют управлять SaaS-расходами, 57% — частными облаками, а 98% уже работают с затратами на ИИ.</p> <p>В условиях дефицита кадров компании переносят инфраструктуру в облака, но скорость разработки зависит не только от аренды ресурсов. Командам нужны внутренние платформы разработчика (Internal Developer Platforms), которые позволяют быстро и безопасно разворачивать приложения, базы данных, окружения тестирования и мониторинг без постоянного участия инфраструктурных инженеров. Platform Engineering развивается как практическое продолжение DevOps: эти специалисты создают self-service инструменты, стандартизируют шаблоны инфраструктуры, автоматизируют CI/CD, интегрируют Kubernetes, IaC и инструменты наблюдаемости (observability). В результате бизнес быстрее выводит продукты на рынок, а эксплуатационные команды меньше времени тратят на типовые запросы.</p> <p>Миграция критичных систем и ИИ-нагрузок в облака меняет профиль рисков. Наряду с классическими задачами — сегментацией сети, управлением доступами, шифрованием, резервным копированием и соответствием требованиям регуляторов — растет значение защиты контейнерных сред, API, пайплайнов данных и моделей машинного обучения. По прогнозу Sk Capital и «Кода Безопасности», сегмент облачной кибербезопасности в России может вырасти с 7 млрд рублей в 2024 году до 32 млрд рублей к 2028 году. Поэтому будут востребованы специалисты, которые понимают и ИБ, и устройство облачной инфраструктуры: умеют выстраивать zero trust, защищать CI/CD и Kubernetes, контролировать доступ к данным для обучения моделей, снижать риски утечек через API и работать с угрозами для <nobr>ML-систем,</nobr> включая adversarial-атаки.</p> <p>Чем сложнее облачная инфраструктура, тем труднее управлять ею вручную. Виртуальные машины, контейнеры, микросервисы, сетевые компоненты и хранилища генерируют большой поток метрик, логов и событий. AIOps (Artificial Intelligence for IT Operations) применяет машинное обучение для мониторинга, корреляции событий, обнаружения аномалий, прогноза инцидентов и автоматического масштабирования ресурсов. Такие специалисты помогают сократить время реакции на инциденты, снижать количество ложных срабатываний и находить причины проблем до того, как они затронут пользователей. В ближайшие <nobr>2–3</nobr> года спрос на AIOps-компетенции в России будет расти вслед за усложнением облачных сред, распространением Kubernetes, мультиоблачных архитектур и ИИ-нагрузок.</p> Российский облачный рынок продолжает расти. По оценке M1Cloud, по итогам 2025 года его объем оценивался примерно … message Цифровой след России: как публикации отражают трансформацию бизнеса https://www.itweek.ru/themes/detail.php?ID=235035 Thu, 18 Jun 2026 17:59:53 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал ключевые тренды публикационной активности ученых в области цифровой трансформации. Результаты анализа свидетельствуют о том, что цифровизация стала одним из ключевых факторов конкурентоспособности компаний и приоритетом для науки.</p> <p>Эмпирической базой исследования послужил массив публикаций в изданиях, индексируемых в базе данных Scopus, за <nobr>2010–2025 гг.</nobr> (182,4 тыс. по миру в целом, 4,5 тыс. в России). В указанный массив попали публикации во всех предметных областях, в заголовке и/или аннотации и/ или ключевых словах которых встречается хотя бы один из терминов, связанных с цифровой трансформацией бизнеса. Анализ публикационной активности — одна из задач Мониторинга цифровой трансформации бизнеса, проводимого ИСИЭЗ НИУ ВШЭ с 2023 г.</p> <p>Цифровая трансформация бизнеса и общества за десятилетие превратилась из нишевой темы в одно из наиболее быстрорастущих направлений российской исследовательской повестки. Интерес к этой области усилился на фоне пандемии: в 2021 г. вклад страны в мировой массив публикаций по данной тематике достигал 4,5%, а число профильных научных работ выросло более чем в 50 раз по сравнению с началом <nobr>2010-х</nobr> годов. Ввиду внешних факторов в 2024 г. доля страны упала до 1,9%. Тем не менее Россия занимает <nobr>12-е</nobr> место по числу исследований цифровой трансформации бизнеса (согласно расчетам на массиве публикаций в Scopus за <nobr>2022–2024 гг.).</nobr> Потенциал для повышения глобальной видимости исследований создает научная кооперация: доля публикаций с зарубежными соавторами за пять лет <nobr>(2019–2024 гг.)</nobr> выросла почти вдвое.</p> <p>Мировая повестка исследований в области цифровой трансформации остается устойчивой, однако меняются технологии, определяющие ее развитие. Анализ частоты упоминания ключевых слов в научных публикациях за последние <nobr>8–10</nobr> лет показывает, что при сохранении интереса к цифровизации в широком смысле, вопросам принятия решений и развитию Индустрии 4.0, все более заметную роль играют искусственный интеллект, машинное обучение, Интернет вещей, робототехника, умное производство и концепция Индустрии 5.0.</p> <p>Российская исследовательская повестка в области цифровой трансформации встроена в глобальные тренды и одновременно ориентирована на национальные приоритеты. Так, четыре из пяти ключевых тем (киберфизические системы в Индустрии 4.0, модели цифровой трансформации, цифровые двойники в киберфизических системах, цифровые компетенции в образовании) освещаются и в зарубежных исследованиях, и в России. Мониторинг ИСИЭЗ НИУ ВШЭ показывает, что все больше российских компаний включаются в цифровую трансформацию, внедряя продвинутые ИТ-решения. Научная повестка следует тому же тренду — от описания отдельных технологий к анализу полной перестройки бизнес-процессов и моделей.</p> <p>Исследования цифровой трансформации становятся все более междисциплинарными, объединяя управление, технологии и экономику. Повестку исследований задают отрасли-лидеры цифровизации: большинство российских работ посвящено опыту финансового сектора, ИКТ и телекоммуникаций, где цифровая трансформация развивается наиболее активно; тогда как малый бизнес и традиционные отрасли значительно реже попадают в фокус внимания.</p> <p>Научные приоритеты и бизнес-запросы идут в России параллельными курсами, без ощутимой синергии. Расширяется круг университетов и исследовательских центров, специализирующихся на исследованиях цифровой трансформации. При этом если в мире ведущую роль в исследованиях по этой теме играют инженерно-технические вузы, то в России — преимущественно многопрофильные, прежде всего социально-экономические, университеты. В результате исследования больше сфокусированы на бизнес-эффектах применения технологий, а не на их разработке.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал ключевые тренды публикационной … message Решение СберТеха позволит бизнесу использовать искусственный интеллект для работы с большими данными https://www.itweek.ru/themes/detail.php?ID=235034 Thu, 18 Jun 2026 13:53:45 +0300 <p>Российский разработчик ПО СберТех развивает функциональность своей СУБД Platform V Pangolin DB, внедряя возможности по использованию искусственного интеллекта (AI). Продукт получил расширение PGVector, позволяющее хранить и обрабатывать данные в векторном представлении, что является необходимым условием для работы генеративных моделей AI. Благодаря этому российские компании смогут на базе СУБД запускать семантический поиск, рекомендательные сервисы и собственных AI-агентов.</p> <p>Максим Тятюшев, генеральный директор СберТеха, отметил: «Мы видим растущий спрос бизнеса на инструменты, которые позволяют эффективно работать с данными, в том числе за счет возможностей AI. Теперь клиенты, использующие нашу СУБД, могут строить сервисы на базе искусственного интеллекта без привлечения дополнительных программных продуктов. Новая функциональность поможет компаниям ускорить внедрение AI-решений, повысить точность персонализированных рекомендаций, улучшить качество ответов интеллектуальных ассистентов и технической поддержки».</p> <p>Расширение PGVector позволяет реализовать векторный поиск по большим объемам неструктурированной информации: текстам, изображениям, аудио и видео. Благодаря этому большие языковые модели могут находить релевантную информацию в базах данных и формировать ответы на запросы пользователей. СберТех не просто интегрировал эту технологию в свою СУБД, но и адаптировал работу расширения к корпоративным требованиям надежности, производительности и безопасности.</p> <p>Platform V Pangolin DB — реляционная система управления базами данных (СУБД), полностью совместимая с PostgreSQL. Продукт содержит ряд важных доработок, которые позволяют использовать его в масштабах корпораций, и уже доказал свою эффективность эксплуатации в ряде крупнейших компаний России. Десятки тысяч инсталляций Platform V Pangolin DB успешно работают в составе сервисов и приложений различного уровня масштаба и критичности.</p> Российский разработчик ПО СберТех развивает функциональность своей СУБД Platform V Pangolin DB, внедряя … message Minervasoft назвала пять ошибок в работе с корпоративными знаниями при внедрении ИИ-ассистентов https://www.itweek.ru/themes/detail.php?ID=235033 Thu, 18 Jun 2026 11:32:20 +0300 <p>Более 80% компаний среди крупного и среднего бизнеса допускают критичные ошибки в работе с корпоративными знаниями. Это приводит к увеличению нагрузки на сотрудников и становится стоп-фактором при внедрении ИИ-ассистентов, следует из результатов проведенных Minervasoft аудитов.</p> <p>В ряде случаев бизнес формально подходит к внедрению систем управления знаниями: решает исключительно технические задачи и не уделяет достаточно внимания культуре и процессам работы со знаниями. В результате компания получает статичный инструмент без возможности масштабирования, а сотрудники продолжают работать по памяти или обращаться к коллегам. </p> <p>Еще один барьер при внедрении ИИ-ассистентов — низкое качество контента внутри базы знаний. Сотрудники работают с объемными документами, непонятными статьями и устаревшими инструкциями. Это приводит к увеличению числа ошибок, удлиняет время поиска информации и снижает доверие к платформе.</p> <p>Третья ошибка — функционал платформы не соответствует реальным задачам бизнеса. Например, нет гибкого разграничения доступа или возможности использовать базу как единый источник для разных каналов обслуживания. Это не позволяет системно работать со знаниями и поддерживать единые стандарты в разных подразделениях и регионах.</p> <p>Четвертая — отсутствие реальных KPI и прозрачной аналитики. Без отчетности компания не видит, как база знаний влияет на скорость поиска информации, количество ошибок и качество обслуживания. В итоге знания размещаются формально, а система со временем перестает развиваться.</p> <p>Пятая ошибка — переоценка внутренних ресурсов. В некоторых компаниях работу с базой знаний поручают сотрудникам, которые успешно проявили себя в других областях, но не имеют опыта подготовки и структурирования статей. Однако такие назначения не всегда приводят к ожидаемому результату: работа с корпоративными знаниями требует отдельных навыков и компетенций.</p> <p>«Наличие платформы само по себе не решает задачу управления знаниями. Отдачу получают компании, которые относятся к базе знаний как к операционной инфраструктуре — с собственными процессами, ответственными и метриками, — подчеркнул директор проектов Minerva Result в Minervasoft Денис Кучеров. — Технологии здесь лишь часть успеха. Чтобы пользу приносили и сотрудники, и ИИ-ассистенты, знания должны быть актуальными, понятными и применимыми. Это возможно только при наличии процессов и культуры менеджмента знаний».</p> Более 80% компаний среди крупного и среднего бизнеса допускают критичные ошибки в работе с корпоративными … message Postgres Professional усилила Postgres Pro Standard 18.4.1 встроеннойотказоустойчивостью BiHA https://www.itweek.ru/themes/detail.php?ID=235032 Thu, 18 Jun 2026 11:31:17 +0300 <p>Postgres Professional представила Postgres Pro Standard 18.4.1 — новую версию коммерческой СУБД на базе PostgreSQL 18.4. Релиз сочетает возможности открытой СУБД PostgreSQL и технологии Postgres Professional, разработанные для корпоративной эксплуатации.</p> <p>В отличие от «ванильного» PostgreSQL, Postgres Pro Standard включает дополнительные инструменты для отказоустойчивости, резервного копирования, аудита, мониторинга и администрирования. В версии 18.4.1 одним из ключевых нововведений стала поддержка встроенного решения высокой доступности BiHA (Built-in High Availability), которое позволяет создавать отказоустойчивые кластеры без использования сторонних компонентов и инструментов управления.</p> <p>«Мы продолжаем развивать Postgres Pro Standard как промышленную СУБД для корпоративных систем, делая упор на надёжность и простоту эксплуатации. В новом релизе наши клиенты получат встроенную отказоустойчивость, дополнительные инструменты контроля и диагностики. Всё это позволяет обеспечивать бесперебойную работу бизнеса, а также снижать затраты на запуск и сопровождение ИТ-систем», — подчеркнул директор департамента разработки продуктов Postgres Professional Василий Чепцов.</p> <p>BiHA обеспечивает автоматическое аварийное переключение, восстановление узлов и защиту от сбоев на базе встроенных механизмов физической репликации. Пользователям доступны автоматический выбор нового лидера, каскадная репликация, поддержка узла-рефери для предотвращения split-brain (раскола кластера), а также возможности географически распределенных и катастрофоустойчивых кластеров.</p> <p>В состав Postgres Pro Standard 18.4.1 вошли новые утилиты и расширения для администрирования и контроля данных. Среди них — модуль pg_hint_plan, позволяющий гибко корректировать планы выполнения SQL-запросов с помощью специальных указаний (хинтов), который ранее был доступен только пользователям Postgres Pro Enterprise. А также pgpro_validate — для проверки целостности экземпляра СУБД, pgbouncer_exporter для экспорта метрик в Prometheus. Кроме того, в релизе оптимизированы отдельные механизмы планировщика запросов и работы с памятью, что позволяет повысить производительность высоконагруженных систем.</p> <p>Дополнительные улучшения коснулись средств аудита, резервного копирования и адаптивной оптимизации запросов. В сертифицированной редакции усилены механизмы защиты конфигурации, а инструменты диагностики получили новые возможности для анализа инцидентов и журналирования.</p> <p>С выходом версии 18.4.1 пользователи Postgres Pro Standard получают дополнительные инструменты для построения отказоустойчивых систем без усложнения архитектуры и зависимости от сторонних компонентов. Подробная информация о возможностях решения и инструкции по переходу представлены в документации Postgres Professional.</p> Postgres Professional представила Postgres Pro Standard 18.4.1 — новую версию коммерческой СУБД на базе PostgreSQL … message IDC: как агентный ИИ меняет модель рентабельности инвестиций https://www.itweek.ru/themes/detail.php?ID=235030 Thu, 18 Jun 2026 09:39:58 +0300 <p><em>Большинство организаций неправильно измеряют бизнес-ценность, создаваемую агентным искусственным интеллектом. Новая концепция IDC объясняет, почему ценность нелинейна, затраты динамичны, а постоянная оценка рентабельности инвестиций не подлежит обсуждению, пишет в корпоративном блоге Андреа Сивьеро, старший директор </em><em>IDC</em> <em>по исследованиям стратегии бизнеса, основанной на ИИ.</em></p> <p>Существует хорошо отработанная методика расчета рентабельности инвестиций в ИТ. Определите базовый уровень, смоделируйте повышение эффективности, спрогнозируйте экономию затрат и представьте цифры финансовому директору. Для большинства технологических инвестиций этот подход работает.</p> <p>Агентный ИИ разрушает его.</p> <p>В отличие от традиционных программных решений, агентный ИИ (системы, которые автономно выполняют многоэтапные задачи, принимают решения в реальном времени и взаимодействуют с внешними инструментами и другими агентами) не предоставляет фиксированный, предсказуемый результат в обмен на фиксированный, предсказуемый ввод. Агенты учатся. Они адаптируются. Они принимают решения автономно в рамках многоэтапных процессов, взаимодействуют с другими системами и другими агентами, а также создают ценность или риск, которые накапливаются таким образом, что традиционные модели ROI не способны их учитывать.</p> <p><em>По данным исследования IDC, 42% организаций по всему миру уже сообщают, что оценка ROI их цифровых и ИИ-инвестиций затруднена или даже невозможна.</em></p> <p>Основные препятствия: ограниченная прозрачность долгосрочного воздействия, неопределенные или противоречивые базовые показатели и отсутствие специализированного отдела или рабочей группы по оценке ценности ИИ. Агентный ИИ не решает эти проблемы. Он их усиливает.</p> <p>Решение заключается не в прекращении измерений, а в изменении методов измерения.</p> <h3>Почему агентный ИИ требует новой системы оценки ценности</h3> <p>Основная проблема заключается в том, что ценность агентного ИИ нелинейна. Один агент, взаимодействующий с клиентом, конвейером данных и бэк-офисным процессом, не обеспечивает четкий процент производительности. Он генерирует результаты, определяемые качеством внедрения, границами автономности, петлями обратной связи, а также качеством данных и процессов, в рамках которых он работает.</p> <p>Затраты представляют собой столь же сложную картину. Расходы на агентный ИИ охватывают лицензирование LLM и SLM, вызовы API, потребление токенов и облачную инфраструктуру, но основными факторами, определяющими затраты, часто являются оркестровка и управление. В рамках концепции IDC стоимость агентного ИИ определяется как фундаментально поведенческая, зависящая от того, как агенты получают промпты, как часто они используют внешние инструменты и насколько тщательно за ними следят. Предположение о линейном масштабировании затрат — одна из самых дорогостоящих ошибок, которые может совершить ИТ-руководитель.</p> <p>Риск добавляет третье измерение. В агентных системах сбои распространяются. Неправильно настроенная граница принятия решений в одном агенте может каскадно распространяться на этапы, инструменты и последующие процессы таким образом, что статические модели риска этого не учитывают.</p> <h3>Шестикомпонентная структура для максимизации бизнес-ценности</h3> <p>Для решения этой проблемы IDC разработала схему максимизации бизнес-ценности агентного ИИ — структурированный подход, построенный на шести компонентах, через которых сквозной нитью проходит управление.</p> <p>#IMAGE_235031#</p> <ul> <li><strong>Стратегия. </strong>Агентный ИИ внедряет автономное принятие решений, поэтому стратегия должна определять, где автономия допустима, а где она ограничена. Результатом является не расплывчатое стремление к «лучшей производительности». Это многоплановая дорожная карта с ответственными за метрики, общая для всей организации и явно привязанная к приоритизации инвестиций. Организации, которые рассматривают агентов как инструменты, а не как автономных субъектов, обрекают себя на сбои в управлении, а не на повышение производительности.</li> <li><strong>Приоритизация сценариев использования.</strong> Не каждая проблема является проблемой, решаемой агентами. Внедрение агентного ИИ в узкие, изолированные задачи, с которыми прекрасно справляется детерминированная автоматизация, приводит к нерациональному расходованию инвестиций и добавляет ненужную сложность. Схема IDC вводит измерения приоритизации, специфичные для агентных контекстов: многоэтапные требования к рассуждениям, динамические потребности в принятии решений, сложность оркестровки и степень, в которой сама автономия создает ценность. Результатом является ранжированный, скорректированный по осуществимости портфель сценариев использования, а не список технически интересных экспериментов.</li> <li><strong>Картирование ценности.</strong> Картирование ценности позволяет привязать инвестиции в агентный ИИ к четким бизнес-результатам и предотвратить бесцельные эксперименты, которые раздувают бюджеты на ИИ без достижения измеримых результатов. Критически важно, что ценность агентного ИИ не статична. Она накапливается по мере того, как агенты учатся, адаптируются и расширяют сферу применения. Картирование ценности должно учитывать кривую обучения, а не только немедленный прирост эффективности, и должно включать нефинансовые факторы, такие как устойчивость и доверие клиентов, наряду с традиционными финансовыми показателями.</li> <li><strong>Расширенная модель затрат.</strong> Схема IDC предусматривает динамическую модель общей стоимости владения, которая отличает капитальные затраты от постоянных, специфических для ИИ операционных затрат и предоставляет FinOps-, юридическим и финансовым командам необходимую информацию для управления сложной экономикой агентного ИИ, основанной на использовании.</li> <li><strong>Корректировка рисков.</strong> Рентабельность инвестиций в агентный ИИ не должна представляться в виде единичной оценки. Она должна основываться на сценариях, быть привязана к траектории внедрения, качеству выходных данных и временным предположениям, и все это должно быть назначено конкретным ответственным лицам с документально подтвержденным уровнем доверия. Риск следует рассматривать как динамический, обновляемый по мере замены оценок реальными данными и моделируемый с учетом взаимозависимостей, которые делают сбои в агентных системах системными, а не изолированными.</li> <li><strong>Непрерывная оптимизация ценности.</strong> Анализ жизненного цикла развертывания агентных систем, проведенный IDC, показывает, что без активной настройки производительность агентов снижается по мере изменения контекста и накопления граничных случаев. Для поддержания устойчивой ценности необходимо рассматривать агентный ИИ как постоянную задачу управления жизненным циклом, а не как проект, который нужно завершить и передать в операционный отдел. Для этого необходим специализированный Центр передового опыта с четким графиком управления, определенными стандартами и организационным мандатом на обеспечение непрерывной оптимизации.</li> </ul> <h3>От концепции к действию</h3> <p>Схема IDC по максимизации бизнес-ценности агентного ИИ разработана для достижения шести конкретных результатов: дорожной карты автономности на несколько временных горизонтов, ранжированного портфеля сценариев использования, калькулятора бизнес-ценности, динамической модели совокупной стоимости владения, оценщика рисков на основе сценариев и модели управления жизненным циклом агента. Это не амбициозные результаты. Это минимальный набор инструментов, необходимых организации для управления агентным ИИ как бизнес-инвестицией, а не как технологическим экспериментом.</p> <p>Анализ IDC показывает, что организации, которые создадут эту инфраструктуру сейчас, получат больше пользы от существующих развертываний агентного ИИ и будут структурно лучше подготовлены к масштабированию по мере появления следующей волны возможностей.</p> Большинство организаций неправильно измеряют бизнес-ценность, создаваемую агентным искусственным интеллектом. Новая концепция … article Почему у продавцов на маркетплейсах нет готовых ИТ-решений — и что с этим делать https://www.itweek.ru/themes/detail.php?ID=235028 Thu, 18 Jun 2026 09:28:30 +0300 <p><em>С развитием бизнеса на маркетплейсах практически каждый продавец приходит к необходимости усиливать ИТ-часть и быстро понимает: универсального решения «из коробки» не существует. Но главный вызов заключается не в автоматизации отдельных процессов, а в сохранении управляемости и контроля над бизнесом. О</em><em>бсудим</em><em>, как выстраивать ИТ-инфраструктуру селлера на разных стадиях развития</em><em>.</em></p> <h3>Чужая система координат</h3> <p>Иногда кажется, что рынок сервисов для продавцов на маркетплейсах растет быстрее самих маркетплейсов. Аналитические платформы, конструкторы, системы учета и автоматизации обещают предпринимателям управляемость «из коробки»: подключил сервис — и бизнес прозрачен.</p> <p>На старте готовые сервисы действительно работают. Они позволяют быстро выйти в продажи без собственной ИТ-команды и закрывают базовые задачи — учет заказов, аналитику, склад, рекламу.</p> <p>Но вместе с удобством предприниматель получает зависимость. Инфраструктура оказывается арендованной: логика расчетов, доступ к данным и правила интеграций определяются не бизнесом, а поставщиком сервиса. Пока объемы небольшие, это почти незаметно. Но с ростом начинают проявляться ограничения:</p> <ul> <li> невозможно гибко считать юнит-экономику;</li> <li> данные из разных источников не сходятся;</li> <li> любое отклонение от стандартного сценария требует доработок или обходных решений;</li> <li> стоимость сервисов и интеграций растет быстрее оборота.</li> </ul> <p>В какой-то момент инструмент, который помог запуститься, начинает ограничивать развитие.</p> <h3>Главная проблема — не отсутствие, а избыток</h3> <p>На практике минимальный технологический набор для профессионального селлера включает несколько ключевых компонентов:</p> <ul> <li> система управления складом (WMS), обеспечивающая точный учет и контроль остатков;</li> <li> система управления заказами (OMS), которая позволяет отслеживать статус каждой покупки и планировать отгрузки;</li> <li> интеграции через API между всеми системами для синхронизации данных;</li> <li> ERP для ведения бухгалтерского и финансового учета;</li> <li> CRM для работы с клиентами, маркетинга и обработки обращений.</li> </ul> <p>При этом, по <a href="https://www.itforless.com/resources/blog/the-real-cost-of-unused-saas-tools">оценкам</a> индустриальных исследований, <nobr>20-30%</nobr> расходов на SaaS-инструменты приходится на дублирующие, неиспользуемые или слабо используемые сервисы. Отдельная статья расходов — интеграции между системами. Это не разовые вложения: любая интеграция требует постоянной поддержки, доработок и адаптации к изменениям API. По мере роста бизнеса число таких связей увеличивается, и стоимость ИТ-инфраструктуры начинает расти не линейно, а за счет накопления и усложнения взаимодействий между системами.</p> <p>Каждый инструмент решает свою локальную задачу и при этом создает отдельный поток данных. В какой-то момент компания понимает, что проблема не в функциональности отдельных сервисов, а в отсутствии единой картины бизнеса.</p> <p>Продажи, расходы, трафик и финансы существуют раздельно. Решения принимаются на основе фрагментов информации, а не целостной экономики.</p> <p>По <a href="https://www.forbes.com/councils/forbescommunicationscouncil/2025/10/22/the-real-cost-of-bad-data-how-it-silently-undermines-pricing-and-growth/">оценкам</a> Gartner, плохое качество данных обходится компаниям в среднем в $12,9 млн. ежегодно. Для селлеров это означает искажение юнит-экономики: по <a href="https://foyzo.com/marketplace-insights/marketplace-fees-2026/">оценкам</a> отрасли, при реальной марже <nobr>10-25%</nobr> даже ошибка в расчетах на уровне <nobr>5-10%</nobr> может полностью обнулить прибыль.</p> <p>Поэтому главным ИТ-проектом растущего селлера становится не внедрение новой системы, а интеграция всех существующих. Компании начинают строить собственное «ядро» — центральную базу данных, куда стекается вся операционная информация. Именно способность связать данные между собой превращается в ключевой фактор управляемости.</p> <h3>Автоматизация как источник новых рисков</h3> <p>Дополнительное ограничение — вопрос доступа и безопасности. Для того, чтобы сторонний сервис начал считать экономику бизнеса, ему необходимо предоставить доступ к личному кабинету маркетплейса — чаще всего через API или другие интеграции. Насколько это безопасно? Даже если это известная платформа, никто не может гарантировать, как именно будут использоваться данные и какие сценарии возможны в случае инцидента.</p> <p>Представьте наихудший вариант: сервис допустил ошибку или злоупотребил доступом, и бизнес пострадал. Судебные разбирательства здесь мало помогают — основной ущерб уже нанесен. Особенно это актуально для России, где механизмы компенсаций и ответственности сервисов находятся пока на стадии формирования.</p> <p>Быстрое внедрение автоматизации и ИИ опережает развитие систем контроля, формируя так называемый накопленный долг по безопасности. По <a href="https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai">данным</a> IBM, 97% организаций, столкнувшихся с инцидентами, связанными с ИИ, не имели должного контроля доступа, а 60% компаний не имеют формализованных политик управления ИИ.</p> <p>Облачные решения усиливают это противоречие. Они создают ощущение надежности, однако зависимость от одного провайдера означает, что технический инцидент может парализовать бизнес мгновенно. Пример: год назад перебои в международной интернет-инфраструктуре, связанные с событиями в Иране, затронули часть зарубежных облачных сервисов, которыми пользовался ряд компаний. Это показало, что в ряде случаев даже двух серверов в разных локациях недостаточно — иногда необходим третий балансировщик, чтобы ежедневно зеркалировать данные и иметь возможность мгновенно восстановить систему из резервной копии.</p> <p>Аналогичные ситуации уже происходили с крупными провайдерами: уход Microsoft из России стал шоком для компаний, полностью завязанных на облачные решения — сотрудники потеряли доступ к корпоративной почте, контактам и мессенджерам, на которые полагались для ежедневной работы.</p> <p>Поэтому зрелые игроки постепенно переходят к компромиссной модели: внешние сервисы используются как интерфейсы, но ключевые данные хранятся внутри компании — с резервными копиями, распределенным хранением и контролем доступа.</p> <h3>Почему с ростом бизнес неизбежно приходит к собственной разработке</h3> <p>С увеличением масштаба многие предприниматели проходят одинаковый путь: со временем складывается ситуация, когда поддержка набора внешних сервисов становится дороже и сложнее, чем создание собственной системы.</p> <p>Прежде чем начать разработку собственной WMS-системы, тестируются готовые решения. Все они имеют определенную логику, но не закрывают потребности на 100%. С планируемыми темпами роста становится очевидно, что любое из имеющихся решений требовало бы бесконечных доработок, каждая из которых стоила бы дорого и не гарантировала нужного результата. Поэтому компании идут по пути создания собственного решения, которое дает полную свободу действий и позволяет выстроить систему под реальные бизнес-процессы.</p> <p>Есть несколько типичных сигналов:</p> <ul> <li> данные из разных систем регулярно расходятся;</li> <li> отчеты собираются вручную или в Excel;</li> <li> невозможно посчитать маржинальность по SKU в реальном времени;</li> <li> рост оборота не приводит к росту прибыли;</li> <li> добавление нового канала или товара резко усложняет процессы.</li> </ul> <p>Это не всегда означает, что компании необходимо создавать всю ИТ-систему с нуля. Чаще это постепенное формирование собственного data-слоя и логики обработки данных поверх существующих инструментов.</p> <p>Кастомная разработка появляется не из технологических амбиций, а из управленческой необходимости. Бизнесу нужен контроль над логикой расчетов, данными и процессами. Маркетплейс-торговля постепенно превращается из торговой деятельности в инженерную — где конкурентным преимуществом становится не товар, а архитектура управления.</p> <h3>Эволюция ИТ-архитектуры селлера</h3> <p>На практике можно выделить три этапа технологической зрелости:</p> <ol> <li><strong> Старт</strong><strong>. </strong>Готовые сервисы «из коробки», минимальные интеграции, быстрый выход в продажи.</li> <li><strong> Рост</strong><strong>. </strong>Комбинация нескольких систем, появление бизнес-аналитики, первые попытки свести данные.</li> <li><strong> Зрелость</strong><strong>. </strong>Собственное ядро данных, централизованная логика расчетов, контроль над архитектурой.</li> </ol> <p>Проблема возникает, когда бизнес остается на первом или втором этапе при растущих оборотах.</p> <h3>Маркетплейс как инструмент, а не бизнес-модель</h3> <p>Главное изменение мышления происходит позже — когда предприниматель перестает воспринимать маркетплейс как сам бизнес. Площадка — это канал продаж и источник трафика, но устойчивость появляется только там, где существует собственная экономика: бренд, операционная эффективность, логистика или производственное преимущество.</p> <p>Рост оборота без системы учета часто приводит не к прибыли, а к управленческому кризису. Масштабирование требует понимания маржинальности, долговой нагрузки и реальных финансовых потоков — а значит, собственной инфраструктуры данных.</p> <p>Именно поэтому технологическая архитектура сегодня стала базовой частью торговли. Продавец больше не просто закупает и продает товар — он управляет системой интеграций, финансовых моделей и данных.</p> <p>Поэтому в новой реальности выигрывает не тот, кто быстрее выходит на маркетплейс, а тот, кто раньше начинает строить собственную управляемую инфраструктуру.</p> <p>#IMAGE_235029#</p> С развитием бизнеса на маркетплейсах практически каждый продавец приходит к необходимости усиливать ИТ-часть … article Никита Терехов, CEO и управляющий партнер международного онлайн-ретейлера Dubai Express «Яндекс» выложил в опенсорс технологию, которая помогает экономить до 20% серверных мощностей https://www.itweek.ru/themes/detail.php?ID=235027 Wed, 17 Jun 2026 13:09:02 +0300 <p>«Яндекс» выложил в опенсорс YaFF (Yet Another Flat Format) — новый формат передачи и чтения данных для высоконагруженных сервисов. Технология позволяет работать с данными, не расходуя ресурсы на их распаковку. Это даёт возможность экономить до 20% вычислительных мощностей.</p> <p>Современные сервисы и приложения получают данные по сети или с диска в компактном виде. Чаще всего крупные ИТ-компании используют для «упаковки» и передачи данных формат Protobuf. Он удобный и надёжный, но имеет существенный недостаток: полученные данные нужно каждый раз распаковывать. Это ресурсоёмкая операция, на которую уходит до 10% всех мощностей сервиса. Альтернативный формат — FlatBuffers — позволяет читать данные без распаковки, но для перехода на него нужно практически полностью переписать код. Технология «Яндекса» решает эти проблемы. </p> <p>YaFF (Yet Another Flat Format) можно использовать поверх стандартного формата Protobuf, чтобы считывать данные напрямую — без распаковки. Это позволяет применять YaFF в уже существующих проектах и экономить вычислительные ресурсы, не переписывая код сервиса. Новый формат подойдет банкам и маркетплейсам, телеком-операторам и разработчикам облачных сервисов — всем, для кого критичны скорость обработки данных и эффективность использования «железа». </p> <p>Технология уже внедрена в рекламной системе «Яндекса». В условиях обработки сотен тысяч запросов в секунду это позволило снизить нагрузку на процессоры на <nobr>10–20%.</nobr> Высвобожденные ресурсы компания направляет на обработку большего числа пользовательских запросов без расширения серверного парка.</p> <p>Документация и код Yet Another Flat Format опубликованы на платформе GitHub.</p> «Яндекс» выложил в опенсорс YaFF (Yet Another Flat Format) — новый формат передачи и чтения данных для … message Apple Hills Digital: российский рынок ПО ИИ вырос до 25 млрд рублей и входит в фазу зрелости https://www.itweek.ru/themes/detail.php?ID=235026 Wed, 17 Jun 2026 13:07:50 +0300 <p>Независимая аналитическая компания Apple Hills Digital опубликовала отчет по исследованию «Рынок программного обеспечения искусственного интеллекта (AI/ML/GenAI) в РФ», в котором определила объем, структуру и динамику российского рынка ПО ИИ с <nobr>2022–2025 год,</nobr> а также дала прогноз и обозначила ключевые драйверы его развития до 2030 года.</p> <p>Главный вывод: рынок ПО искусственного интеллекта в России выходит из стадии точечных экспериментов и переходит к более зрелому этапу, где заказчики этой технологии ждут конкретной пользы для бизнеса.</p> <p>Ключевые тренды: </p> <ul> <li>ИИ в России все быстрее превращается из экспериментального направления в полноценный рынок корпоративного ПО. Объем российского рынка ПО ИИ составил 25 млрд рублей. За последние три года рынок почти удвоился, а к 2030 году может приблизиться к 95 млрд рублей;</li> <li>самым заметным драйвером становятся технологии GenAI. Сегодня основную часть рынка формируют прикладные решения — сервисы разговорной речи (10 млрд рублей и 53% сегмента) и компьютерное зрение (5,8 млрд рублей и 31% сегмента). Их рост поддерживался за счет интеграции с технологиями GenAI. В 2025 году применение GenAI было основным драйвером для рынка программного обеспечения ИИ. Компании стали активнее использовать GenAI в автоматизации бизнес-процессов, переходя от базовых, рутинных к более сложным, комплексным рабочим процессам — за три года это направление выросло с 0,1 млрд до 2,0 млрд рублей, а CAGR составил 156,7%;</li> <li>изменение логики спроса — важный сигнал для рынка. Если раньше многие компании приходили в тему ИИ из опасения отстать от тренда, то сейчас они все чаще оценивают, где технология действительно дает эффект: помогает сокращать издержки, ускорять процессы и повышать производительность;</li> <li>доли поставки платформ ИИ в публичном облаке и локальных развертываниях сопоставимы, но преобладает локальная поставка. Сейчас в России по-прежнему преобладает локальное развертывание ИИ-решений, однако несколько быстрее растут облачные модели. В 2025 году на локальное развертывание пришлось 62,3% рынка, или 15,6 млрд рублей. Однако решения в публичном облаке растут быстрее и к 2030 году будут прибавлять в среднем 34% в год, что связано со скоростью обновления моделей, доступностью вычислительных ресурсов и снижением барьеров для запуска новых сценариев ИИ. </li> </ul> <p>Эта тенденция перекликается с исследованием Apple Hills Digital по облачным трендам: российские компании активнее наращивают ИТ-бюджеты, выводят ИИ в промышленную эксплуатацию и все чаще рассматривают облако как среду для быстрого запуска и масштабирования новых технологий.</p> <p>«Российский рынок искусственного интеллекта заметно повзрослел. Если еще недавно многие компании приходили в эту тему из опасения отстать от тренда, то сейчас фокус меняется — бизнес хочет понимать, где именно ИИ дает измеримый эффект, оптимизирует издержки, ускоряет процессы или создает новые предпосылки для роста. Эта тенденция сохранится и до 2030 года будет обеспечивать устойчивый ежегодный рост с CAGR 30,5%», — отметила Елена Семеновская, аналитик Apple Hills Digital. </p> Независимая аналитическая компания Apple Hills Digital опубликовала отчет по исследованию «Рынок программного обеспечения … message GitVerse обеспечивает стабильный доступ к пакетным хранилищам популярных языков программирования https://www.itweek.ru/themes/detail.php?ID=235024 Wed, 17 Jun 2026 10:47:50 +0300 <p>Команда российской ИИ-платформы для работы с кодом GitVerse развернула зеркала библиотек для наиболее популярных языков программирования. Проект охватывает ключевые направления разработки — от веба и бэкенда до DevOps и контейнеризации. Он позволяет пользователям GitVerse защититься от сбоев при работе с внешними зарубежными сервисами.</p> <p>На GitVerse теперь доступны зеркала для хранилища библиотек Python Package Index (PyPI), официального сервиса для работы с модулями Go (proxy.golang.org) и реестра пакетов для языка программирования Rust (Crates.io). Ранее на платформе были созданы зеркала для Maven Central (репозитория пактов для языка Java), NPM (менеджера пакетов для JavaScript), а также Docker Hub (хранилище образов контейнеров). </p> <p>Таким образом, GitVerse сегодня предоставляет локализованные в российской инфраструктуре практически все самые популярные реестры пакетов для разработки. Это важно для компаний, которым необходима стабильность процессов и технологический суверенитет.</p> <p>Зеркала можно использовать как основной или резервный источник зависимостей, чтобы гарантировать непрерывность локальной разработки в тех случаях, когда исходный репозиторий пакетов недоступен. Благодаря размещению в российской инфраструктуре снижаются сетевые задержки и ускоряется загрузка пакетов по сравнению с зарубежными хранилищами. </p> <p>GitVerse — продукт ИТ-компании СберТех, российская ИИ-центричная платформа, которая позволяет командам совместно работать с кодом, надёжно его хранить, автоматически сканировать на уязвимости, отслеживать изменения и собирать аналитику. Функциональность платформы усилена ИИ-инструментами: ассистентом GigaCode с агентным режимом, гибридной средой GigaIDE (локально и в облаке) и мультиагентной системой разработки GigaStudio. Платформе доверяют свыше 200 тыс. пользователей — на GitVerse размещено более 140 000 проектов и хранится 13,8 ТБ данных (примерно 130 млрд строк кода).</p> Команда российской ИИ-платформы для работы с кодом GitVerse развернула зеркала библиотек для наиболее популярных языков … message «Информзащита»: 86% организаций не готовы автоматически остановить скомпрометированного ИИ-агента https://www.itweek.ru/themes/detail.php?ID=235023 Wed, 17 Jun 2026 10:46:11 +0300 <p>Специалисты компании «Информзащита» выявили рост рисков, на фоне активного подключения ИИ-агентов к корпоративным почтам, внутренним базам, документообороту, клиентским обращениям и финансовым операциям; при этом механизмы контроля за их действиями остаются недостаточно зрелыми. В 2026 году только 14% компаний имеют внутренние инструменты, позволяющие выявить такую манипуляцию и заблокировать опасный сценарий без ожидания ручной реакции. По собранным данным, доля проектов, где ИИ-агенты получают доступ к внешним письмам, сайтам, документам и пользовательским обращениям, за год выросла с 18% до 34%, а число запросов на оценку безопасности подобных сценариев увеличилось на 41%.</p> <p>Агенты часто используются в решении потоковых задач, разбирают входящие сообщения, извлекают сведения из договоров и таблиц, готовят ответы, создают заявки, переносят данные между системами, и в ряде компаний действует как полноценный участник процесса с доступом к корпоративному контуру. Он получает информацию извне, сопоставляет ее с внутренними данными и при определенных настройках запускает следующее действие. </p> <p>Сценарий атаки часто начинается типично через почту, через которую приходит запрос от контрагента, в форму поддержки загружается обращение клиента, в документе появляется комментарий, на сайте размещается текст, который агент должен использовать как источник. Внутри такого контента злоумышленник прячет инструкцию: изменить ход обработки, раскрыть сведения, переслать данные, проигнорировать ограничение, сформировать ответ с нужной формулировкой. Сотрудник видит обычный деловой материал, агент может принять скрытую команду за часть рабочего контекста и выполнить ее как штатную операцию. Расследование в таких случаях осложняется тем, что действие не выглядит как классический взлом: оно проходит через разрешенный сценарий автоматизации.</p> <p>Многие проекты стартуют в бизнес-подразделениях с конкретной практической целью сократить время обработки писем, ускорить первую линию поддержки или разобрать поток документов. Команды безопасности подключаются уже после пилота, когда у агента есть доступ к почтовому ящику, файловому хранилищу, системе заявок или клиентской базе. Права при этом часто выдаются с запасом, потому что широкий доступ повышает качество результата. В защите такая логика создает лишние привилегии, размывает границы ответственности и усложняет восстановление цепочки событий.</p> <p>По векторам атак наиболее заметна электронная почта и вложения: на них приходится около 32% выявленных рискованных сценариев. Это письма от клиентов, поставщиков, подрядчиков, соискателей и партнеров, где скрытая инструкция маскируется под нормальную деловую переписку. Сайты и внешние базы знаний формируют 24% случаев: агент обращается к ним для подготовки ответа, сверки сведений или поиска справочной информации. Документы контрагентов дают около 18% сценариев, включая таблицы, презентации, договоры, технические описания, комментарии, скрытые элементы форматирования и метаданные. На чаты, системы заявок и клиентские формы приходится 15%. Еще 11% связаны с цепочками из нескольких систем, где команда появляется в одном канале, затем действие выполняется в другом: письмо приводит к созданию заявки, заявка меняет данные в карточке клиента, после этого система отправляет подтверждение внешнему адресату.</p> <p>Особенно опасен разрыв между скоростью агента и скоростью проверки. Ручной контроль работает, когда речь идет о единичном черновике или операции, где у сотрудника есть время внимательно изучить результат. В потоковых процессах такая проверка быстро превращается в задержку, которую начинают обходить ради скорости. По данным специалистов, 25% организаций полагаются на ручную проверку высокорисковых результатов, 14% умеют выявлять манипуляцию, но не могут автоматически остановить агента, 34% знают о риске, но не имеют средств обнаружения и сдерживания. Еще 14% компаний пока не включили такой сценарий в модель угроз. При реальном инциденте агент успевает отправить данные наружу, согласовать заявку, подготовить изменение реквизитов или сформировать ответ с вредоносной ссылкой раньше, чем событие попадет к ответственному специалисту.</p> <p>Сильнее всего проблема проявляется в отраслях, где внешние запросы быстро переходят во внутренние действия. В финансовом секторе сосредоточено около 31% выявленных сценариев повышенного риска: агенты помогают разбирать платежные запросы, клиентские обращения, документы по операциям и внутренние заявки. На розничную торговлю и электронную коммерцию приходится 19%; зона риска связана с поддержкой покупателей, возвратами, бонусными программами, личными кабинетами и изменением контактных данных. Промышленность и логистика дают около 14% сценариев из-за документооборота с поставщиками, заявок на отгрузку, маршрутной информации и производственных инструкций. В ИТ-компаниях и у разработчиков программного обеспечения доля составляет 13%, поскольку агенты получают доступ к задачам, технической документации, хранилищам кода и описаниям внутренних процессов. Телекоммуникации занимают 9%, здравоохранение — 8%, государственные и профессиональные услуги — 6%.</p> <p>Агент с доступом к почте, файловому хранилищу и системе заявок — это по факту непривилегированный администратор без аудита. Его права необходимо пересматривать так же строго, как права администратора, финансового сотрудника или оператора клиентской поддержки. Особого внимания требуют цепочки из нескольких агентов и систем: один инструмент анализирует письмо, второй извлекает данные, третий создает запись, четвертый отправляет ответ. Чем длиннее такая связка, тем сложнее понять, где появилась вредоносная команда и какой элемент выполнил опасное действие. Без подробных журналов, привязки операций к конкретному агенту и контроля переходов между системами расследование быстро теряет точность.</p> <p>Снижать риск можно через управляемую архитектуру использования ИИ-агентов. У каждого агента должен быть владелец, описанная цель, ограниченный набор источников данных и перечень действий, разрешенных без дополнительного подтверждения. Внешний контент нужно проверять до передачи агенту: письма, документы, страницы и вложения должны проходить фильтрацию на скрытые команды, попытки изменить роль агента и инструкции, выходящие за рамки исходной задачи. Для операций с высоким риском требуется отдельный уровень подтверждения. Изменение платежных реквизитов, отправка персональных данных, массовая рассылка, действия с правами пользователей и доступ к финансовым системам должны выполняться только после проверки ответственным сотрудником или через заранее настроенный механизм доверенного согласования. Практическую основу защиты составляют журналирование, контроль поведения, ограничение внешней передачи данных и автоматическое сдерживание. При отклонении от нормального сценария агент должен остановиться сам и передать событие в разбор. </p> Специалисты компании «Информзащита» выявили рост рисков, на фоне активного подключения ИИ-агентов к корпоративным … message Deckhouse Stronghold 1.18: усиленная безопасность ключей, расширенные возможности аудита и новые enterprise-сценарии эксплуатации https://www.itweek.ru/themes/detail.php?ID=235022 Wed, 17 Jun 2026 10:44:59 +0300 <p>Команда Deckhouse, направление компании «Флант», выпустила версию 1.18 Deckhouse Stronghold — российского решения для безопасного управления жизненным циклом секретов. Новый релиз сфокусирован на интеграции с внешними системами управления ключами, расширении возможностей аудита и внедрении удобных сценариев эксплуатации для корпоративных инфраструктур.</p> <p>Главное нововведение версии — поддержка управляемых ключей (Managed Keys). Теперь Deckhouse Stronghold может работать с внешними KMS, не размещая приватные ключи внутри своего хранилища. Это снижает риски компрометации и упрощает соответствие строгим требованиям безопасности и комплаенса. </p> <p>Для бесшовной интеграции в корпоративные IAM-среды добавлены аутентификация через внешний SAML 2.0 Identity Provider и поддержка Web SSO. Вход в систему стал удобнее и безопаснее благодаря поддержке WebAuthn (FIDO2/Passkeys), которая полностью убирает зависимость от паролей.</p> <p>Повседневная административная работа выведена на новый уровень. Теперь параметры репликации KV-mount, мониторинг audit-логов и просмотр сервисных журналов доступны прямо из веб-интерфейса — без необходимости использовать <nobr>CLI-утилиты.</nobr> Журналы аудита получили гибкую фильтрацию и возможность исключения чувствительных полей из записей, что повышает удобство анализа событий, упрощает расследование возможных инцидентов и помогает соблюдать политики обработки данных.</p> <p>Stronghold 1.18 поддерживает загрузку внешних плагинов в контейнерном исполнении. Ранее при использовании в составе Deckhouse Kubernetes Platform хранилище работало только в поставке «как есть» — механизма загрузки плагинов в кластере не было, это было доступно лишь в standalone-исполнении. Теперь инженеры могут подключать собственные решения, совместимые с HashiCorp Vault, и адаптировать продукт под специфику инфраструктуры без изменения кода.</p> <p>«Новый релиз развивает функциональные возможности Deckhouse Stronghold как полноценного enterprise-хранилища секретов для крупных корпоративных инфраструктур. В версии 1.18 мы сделали акцент как на новых функциях безопасности, так и на удобстве повседневной работы с продуктом: добавили поддержку внешних KMS, расширили возможности аудита и перенесли ряд административных операций в веб-интерфейс, чтобы сделать управление секретами в Deckhouse Stronghold проще и эффективнее», — отметил Владимир Девятайкин, менеджер продукта Deckhouse Stronghold.</p> Команда Deckhouse, направление компании «Флант», выпустила версию 1.18 Deckhouse Stronghold — российского решения для … message «СёрчИнформ»: 34% опрошенных ИБ-специалистов используют ИИ в работе https://www.itweek.ru/themes/detail.php?ID=235021 Wed, 17 Jun 2026 10:44:16 +0300 <p>Компания «СёрчИнформ» представила результаты опроса по теме искусственного интеллекта в области ИБ, проведенного среди 170 российских специалистов по информационной безопасности. Вопросы касались практики использования нейросетей для решения ИБ-задач, а также рисков утечек конфиденциальной информации через ИИ.</p> <p>Российский бизнес активно внедряет искусственный интеллект в операционные процессы для повышения эффективности, и сфера информационной безопасности не стала исключением. В 2024 году, по данным опроса «СёрчИнформ», 77% ИБ-специалистов считали возможным внедрение технологий искусственного интеллекта в свою работу, 23% опрошенных ответили, что в работе ИБ-специалистов нет места ИИ.</p> <p>В 2026 году 34% опрошенных специалистов по информационной безопасности уже активно используют ИИ в работе. 39% — планируют внедрение ИИ в будущем, это свидетельствует о растущем интересе и потенциале для расширения использования ИИ в области ИБ. Однако более четверти опрошенных (27%) все еще не планируют использовать ИИ для решения ИБ-задач.</p> <p>«Использование ИИ в информационной безопасности активно растет. Примерно треть специалистов уже используют ИИ для решений задач, еще 39% планируют внедрять в будущем. Причины такого сдвига, на мой взгляд, комплексные — снижение стоимости ИИ, появление локальных решений, улучшение моделей: они стали быстрее, умнее и требуют меньше ресурсов. ИБ-специалисты видят реальную пользу, а для тех, кто ранее отказывался от использования ИИ из-за риска утечки данных, появилась возможность использовать локальные системы», — прокомментировал начальник отдела безопасности «СёрчИнформ» Алексей Дрозд.</p> <p>Более половины опрошенных специалистов (53%) оценивают эффективность использования ИИ для решения ИБ-задач как среднюю, и 36% — как высокую. В то же время 11% специалистов видят различные ограничения возможностей ИИ и оценивают эффективность использования нейросетей в работе ИБ-специалиста как низкую.</p> <p>При этом никто из опрошенных ИБ-специалистов не готов полностью полагаться на результаты работы ИИ. 76% доверяют ИИ, но с осторожностью, 19% — скептически относятся к результатам работы искусственного интеллекта. 5% ИБ-специалистов пока не готовы доверять ИИ.</p> <p>Также аналитики «СёрчИнформ» выяснили, в каком формате опрошенные специалисты используют ИИ. Большинство (56%) предпочитают использовать ИИ, встроенный в софт. Однако нередко (49%) ИБ-специалисты используют бесплатные ИИ-модели в открытом доступе. 44% — пользуются собственной локальной ИИ-моделью.</p> <p>ИБ-специалисты активно внедряют ИИ для помощи с аналитическими и классификационными задачами, однако для более критичных задач, таких как реагирование на инциденты и обнаружение угроз, использование ИИ пока ограничено.</p> <p>Наиболее популярные сценарии использования ИИ для решения ИБ-задач — генерация ответов (например, ИИ-помощник для анализа документов и т.д.) — 49%, анализ логов и событий безопасности — 47%, помощь в классификации и анализе контента (аудио, изображения, большие объемы текста, перевод) — 42%.</p> <p>Четверть опрошенных доверяют нейросетям анализ инцидентов информационной безопасности. Еще реже опрошенные передают ИИ обнаружение вредоносных программ (12%), детектирование фишинга (10%), реагирование на инциденты и предотвращение атак (6%).</p> <p>«Многие полагают, что в ИИ-системах существует одна универсальная „кнопка“, которая решит все задачи. На деле же, за этим стоят разные специализированные инструменты, каждый из которых эффективно работает в своей области ИБ. Например, нейросети хорошо справляются с классификацией изображений, в то время как большие языковые модели чаще используют для генерации и анализа текста. Важно понимать, что для разных задач нужны разные решения. Анализ логов, обнаружение фишинга, автоматизация реагирования на инциденты — все это требует различных инструментов и подходов. Поэтому комплексное внедрение ИИ в ИБ-задачи зачастую включает в себя интеграцию нескольких технологий», — рассказал начальник отдела безопасности «СёрчИнформ» Алексей Дрозд.</p> <p>Среди главных преимуществ использования ИИ в информационной безопасности опрошенные специалисты видят: автоматизацию рутинных задач (86%), улучшение аналитических возможностей (73%) и повышение скорости обнаружения угроз (69%).</p> <p>Лишь 11% российских ИБ-специалистов используют технологии ИИ, встроенные в защитные решения. Почти половина (49%) планируют протестировать ИИ в защитных решениях в ближайшее время. 39% специалистов не используют, 1% опрошенных не планируют использовать.</p> <p>«Интересно отметить крайнюю разрозненность ответов, функции ИИ, встроенные в ИБ-средства, сейчас используют 11% и лишь 1% опрошенных не планируют использовать возможности нейросетей. Эти цифры демонстрируют, насколько сильно изменилось восприятие ИИ-инструментов в отрасли безопасности. Если в <nobr>2017-2018</nobr> годах об использовании ИИ в ИБ не могло быть и речи, то сейчас ИИ воспринимается как технология обязательная, но все еще новая — ведь большая часть респондентов только планирует ее применение. Однако все еще основную роль играет показатель доверия к ИИ среди ИБ-специалистов: абсолютное большинство относится к результатам анализа ИИ со здоровым скептицизмом, а показатель безоговорочного доверия к ИИ среди опрошенных специалистов и вовсе равен нулю», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Кроме преимуществ ИИ, опрошенные ИБ-специалисты отмечают и ограничения, с которыми сталкиваются при использовании ИИ. Среди них: высокие требования к вычислительным ресурсам (62%), сложности интеграции с существующими системами (46%) и недостаточная прозрачность решений ИИ (42%).</p> <p>В 2025 году, по данным опроса «Битрикс24» и «Русской школы управления», каждый пятый сотрудник российских компаний передавал конфиденциальные данные ИИ. Компрометация конфиденциальной информации из-за отправки корпоративных или персональных данных в нейросети — один из рисков, который теперь необходимо контролировать ИБ-специалистам.</p> <p>В 2024 году, по данным «СёрчИнформ», почти в половине российских компаний ИБ-специалисты видели риски, связанные с утечками конфиденциальной информации через чат-боты, и ограничивали персоналу доступ к ИИ-сервисам. По данным опроса в 2026 году, большинство ИБ-специалистов (53%) оценивают риск утечки конфиденциальных данных при использовании ИИ сотрудниками как высокий, 29% опрошенных как средний.</p> <p>При этом лишь 8% опрошенных ИБ-специалистов запрещают сотрудникам использовать ИИ для работы, 36% — не контролируют использование ИИ. 30% ИБ-специалистов разрешают сотрудникам использовать нейросети из «белых списков», а 26% разрешают использовать ИИ только по определенным сценариям.</p> <p>Среди мер контроля, которые используют ИБ-специалисты: мониторинг активности сотрудников при работе с ИИ (44%), инструкции и регламенты по использованию нейросетей (29%), обучающие программы и тренинги по безопасному использованию ИИ (23%) и блокировка отправки определенного содержимого в файле или обращении (18%).</p> <p>«Свободно распространяемые ИИ-сервисы создают значительные риски для конфиденциальности данных российских компаний. Защита от этих угроз в первую очередь лежит на разработчиках средств защиты информации, таких как файрволы искусственного интеллекта (AI Firewall) и системы защиты от утечек информации (DLP). Системы защиты от утечек, которые не учитывают популярные ИИ-сервисы, такие как чат-боты с генеративным искусственным интеллектом (ChatGPT, Copilot и DeepSeek), рискуют стать неконкурентоспособными на рынке. Мы как разработчик предвидим подобные риски, поэтому уже добавили в свое решение функцию детектирования и блокировки многих популярных ИИ-сервисов, а сейчас готовим комплексное обновление этого функционала», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Также по данным опроса «СёрчИнформ», 42% ИБ-специалистов сталкивались с тем, что сотрудники передавали в ИИ-сервис конфиденциальные или чувствительные данные. 28% респондентов ответили, что им не хватает инструментов для контроля утечек через нейросети.</p> <p>Среди мер, которые предпринимают ИБ-специалисты для предотвращения передачи конфиденциальных данных ИИ-системам: обучение сотрудников (54%), мониторинг и аудит использования ИИ (45%) и ограничение доступа к конфиденциальным данным (43%).</p> <p>Также ИБ-специалисты выделили основные сложности, с которыми они сталкиваются, при контроле использования ИИ. Среди них: отсутствие четкой стратегии и стандартов для мониторинга и регулирования использования ИИ, простота доступа к нейросетям с различных устройств и невозможность отслеживать все сценарии использования ИИ сотрудниками, человеческий фактор (риск ошибок или злоупотреблений со стороны сотрудников), нехватка знаний и навыков, которая затрудняет разработку эффективных мер контроля и реагирования на угрозы и др.</p> Компания «СёрчИнформ» представила результаты опроса по теме искусственного интеллекта в области ИБ, проведенного … message Экспертиза Frank RG и BSS: клиенты требуют от банков качественного сервиса и понимания контекста в управлении CX https://www.itweek.ru/themes/detail.php?ID=235020 Wed, 17 Jun 2026 10:34:03 +0300 <p>При поддержке BSS состоялась встреча Frank Award 2026 «Банковские контакт-центры», на которой было представлено самое комплексное в России актуальное исследование клиентского опыта в отрасли. По его результатам были награждены лучшие банковские практики. Эксперт BSS принял участие в церемонии награждения и экспертной дискуссии.</p> <p>BSS выступила партнером отраслевой встречи Frank Award 2026 «Банковские контакт-центры», организованной аналитической компанией Frank RG. Мероприятие объединило представителей крупнейших банков РФ, включая Сбер, Т-Банк, Альфа-Банк, ПСБ, ВТБ, Уралсиб, ОТП Банк.</p> <p>На встрече Frank RG представила исследование клиентского опыта в банковских контакт-центрах. Ключевые результаты:</p> <ul> <li>уже 64% пользователей предпочитают чат в мобильном приложении — фокус смещается все больше на текстовые каналы. На втором месте — колл-центр (42%), на третьем — чат в интернет-банке (23%). Также клиенты общаются через чат на сайте (6%), форму обратной связи (5%), Email (4%), мессенджеры (3%) и соц. сети (3%);</li> <li>контакт-центры становятся важной точкой поддержки клиентов в стрессовых ситуациях — растет количество обращений, связанных с мошенничеством и блокировками счетов;</li> <li>доля максимальных оценок роботам достигла 75%, однако пользователи по-прежнему отмечают недостаточное понимание запросов и отсутствие гибкости в диалоге;</li> <li>главный фактор качественного обслуживания для клиентов — минимальное количество усилий при решении вопроса: быстрый ответ и короткий диалог без переключений, решение проблемы с первого обращения. </li> </ul> <p>По результатам исследования состоялась церемония награждения лучших банковских практик. Заместитель генерального директора BSS Василий Жилов вручил награду банку ПСБ, признанному победителем в номинации за лучшую работу чат-бота. </p> <p>Исследование также стало отправной точкой для экспертной дискуссии о будущем банковских контакт-центров, в которой приняли участие представители ведущих финансовых организаций страны. Среди спикеров выступил эксперт BSS Василий Жилов.</p> <p>По словам Василия, сегодня банки располагают огромным объемом данных о взаимодействии с клиентами — телефонные разговоры, переписки в чатах, история обращений в приложении — однако эти данные существуют разрозненно и не позволяют получить целостную картину клиентского опыта.</p> <p>«Если создать единый операционный слой управления данными, можно гораздо точнее понимать причины оттока клиентов или снижения конверсии и принимать решения на основе полной картины клиентского пути», — отметил Василий Жилов. </p> <p>Эксперт также подчеркнул, что важно соблюдать баланс между автоматизацией и удовлетворенностью клиентов: можно существенно сократить издержки на входящей линии за счет автоматизации, но если клиент останется недоволен взаимодействием, бизнес потеряет больше. </p> <p>При этом ключевая причина недоверия к роботам сегодня связана не с ограничениями технологий, а с качеством их внедрения и настройки. Современные системы понимают смысл обращений, качественно синтезируют речь, используют интеллектуальный поиск информации и многое другое: </p> <p>«Технологии уже приносят результат: получают все более высокие оценки при обработке обращений, анализируют качество всех коммуникаций контакт-центра, заводят и решают тикеты в Service desk, помогают операторам проходить онбординг в 3 раза быстрее. А в ближайшие годы мы увидим по-настоящему human-centric решения, которые к тому же будут проявлять эмпатию», — прокомментировал Василий Жилов. </p> <p>Эксперт BSS также коснулся оценки эффективности контакт-центров и отметил, что важно смотреть не только на традиционные операционные показатели, такие как AHT или FCR, но и на бизнес-метрики: скорость получения клиентом ценности (Time to Value), пожизненную ценность клиента (LTV) и стоимость привлечения (Customer Acquisition Cost). Достижению этих показателей сегодня часто мешает «лоскутная автоматизация».</p> <p>«Банки тратят до 40% бюджетов на интеграцию различных цифровых решений между собой. Поэтому сегодня особенно важен комплексный подход, который охватывает сразу пять ключевых направлений: сервисные функции, продажи, предотвращение оттока, маркетинговые коммуникации и развитие сотрудников. Объединение этих процессов в единой среде с общими данными и <nobr>ML-логикой</nobr> позволит выйти на новый уровень клиентского сервиса», — отметил Василий Жилов.</p> При поддержке BSS состоялась встреча Frank Award 2026 «Банковские контакт-центры», на которой было представлено самое … message Dialog Composer 3.0 от BSS: переход от скриптовых ботов к самостоятельным ИИ-агентам https://www.itweek.ru/themes/detail.php?ID=235019 Wed, 17 Jun 2026 10:27:51 +0300 <p>Компания BSS дает мощный толчок развитию диалоговых интерфейсов с новой версией Dialog Composer 3.0. Ключевой особенностью релиза стала нативная поддержка архитектуры ИИ-агентов на базе больших языковых моделей (LLM). Обновленный no-code инструмент позволяет компаниям быстро внедрять автономных ИИ-ассистентов, существенно снижая нагрузку на контактные центры и операционные службы.</p> <p>Один из ведущих российских разработчиков речевых технологий и искусственного интеллекта, компания BSS, представила масштабное обновление своей no-code платформы для разработки диалоговых сценариев — Dialog Composer (DC) версии 3.0. Релиз помогает перейти от классической автоматизации на жестких скриптах к созданию сложных автономных ИИ-агентов, способных самостоятельно принимать решения и интегрироваться в бизнес-процессы заказчика.</p> <p>Ключевой особенностью DC 3.0 стала возможность реализации полноценных ИИ-агентов. В отличие от традиционных сценарных ботов, где прописаны каждый шаг и реакция, новые агенты на базе больших языковых моделей (LLM), промптов и набора инструментов сами определяют, какие уточняющие вопросы задать клиенту, запоминают контекст диалога и автономно выбирают необходимый инструмент для решения задачи.</p> <p>Для разработчиков платформа предлагает современный визуальный интерфейс, отладку каждого элемента, систему версионности для безопасного отката изменений, а также гибкую настройку параметров LLM (температура, лимиты токенов и вызовов). Архитектура агентов теперь поддерживает создание пользовательских инструментов на Python, интеграцию через OpenAPI и подключение MCP-инструментов, что обеспечивает бесшовную стыковку с любыми корпоративными системами.</p> <p>Понимая, что не все бизнес-процессы готовы к полной передаче диалога нейросетям, и учитывая интересы заказчиков, предпочитающих проверенные и детерминированные сценарные решения, в DC 3.0 был существенно доработан базовый функционал:</p> <ul> <li>появилась возможность копировать созданные элементы (ноды) в другие ветки сценария, что ускоряет разработку;</li> <li>удаление целой ветки сценария теперь выполняется в несколько кликов, избавляя от необходимости удалять элементы поштучно;</li> <li>грамматика для транскрибации голосового ответа теперь задается один раз на уровне всего бота, а не в каждой отдельной ноде, что экономит часы рутинной работы;</li> <li>добавлена кнопка для копирования всей отладочной информации одним кликом, заменяющая неудобные скриншоты или ручной перенос данных.</li> </ul> <p>Отдельный блок улучшений коснулся ботов с архитектурой RAG (Retrieval-Augmented Generation). Изменения внедрены напрямую на основе обратной связи от клиентов. Система логирования стала прозрачнее: теперь можно анализировать время обработки запросов и строить статистику по наиболее востребованным документам. Кроме того, ИИ-ассистент теперь может предоставлять клиенту не только сформированный ответ, но и прямую ссылку на источник. Визуальная часть режима тестирования RAG также была переработана: отладочная информация структурирована по блокам и доступна для быстрого копирования.</p> <p>Кроме того, в DC 3.0 реализован механизм отслеживания количества одновременных текстовых и голосовых сессий прямо в интерфейсе платформы. Если ранее для анализа пиковых нагрузок и контроля лицензий инженерам приходилось вручную выгружать логи и запускать скрипты, то теперь эта аналитика доступна в режиме реального времени, что существенно повышает операционную эффективность команд внедрения и эксплуатации.</p> <p>«Выпуск Dialog Composer 3.0 — это знаковый переход от обычной автоматизации диалогов к запуску по-настоящему интеллектуальных цифровых сотрудников. Мы предлагаем среду простого создания ИИ-агентов, которые способны самостоятельно принимать решения, использовать внешние инструменты и опираться на историю взаимодействий. При этом мы сохранили и усилили классические no-code инструменты для тех клиентов, кому важна абсолютная предсказуемость сценарных ботов. Это тот самый баланс инноваций и надежности, который требует современный рынок», — отметил Александр Крушинский, директор департамента голосовых цифровых технологий компании BSS.</p> <p>Обновление Dialog Composer 3.0 подтверждает статус компании BSS, как одного из безусловных лидеров отечественного рынка в области разработки и внедрения речевых технологий, искусственного интеллекта, ИИ-агентов и мультиагентных систем. Предлагая бизнесу <nobr>CX-платформу</nobr> нового уровня, BSS не только задает технологические тренды, но и обеспечивает компаниям реальные инструменты для повышения качества клиентского опыта, снижения операционных затрат и ускорения цифровой трансформации.</p> Компания BSS дает мощный толчок развитию диалоговых интерфейсов с новой версией Dialog Composer 3.0. Ключевой … message Закон Конвея: ваша операционная модель важнее, чем модель ИИ https://www.itweek.ru/themes/detail.php?ID=235018 Wed, 17 Jun 2026 09:38:32 +0300 <p><em>Если мы хотим, чтобы агентный искусственный интеллект создавал совокупную ценность, мы должны сначала перепроектировать операционную модель, которая его окружает, пишет в корпоративном блоге Сэм Хиггинс, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Я люблю аксиомы, что-то легко запоминающееся, быстро произносимое и достаточно убедительное, чтобы остаться в памяти. Своим старшим сыновьям я часто говорил: «Если сомневаешься, не делай». Моему младшему сыну, у которого аутизм, я говорю: «Оставайся рядом; будь в безопасности». Это короткие фразы с большим смыслом, которые помогают в момент, когда времени мало, а ставки высоки.</p> <p>Вероятно, именно поэтому такие идеи, как закон Мура, закон Амары и закон Паркинсона, продолжают находить отклик у технологических лидеров. Они помогают нам придерживаться простых идей, когда мы осмысливаем внедрение, ценность и реализацию технологий в масштабе. Они помогают нам оставаться на верном пути и поддерживать наших сотрудников, когда нарастает ажиотаж в СМИ, презентации консультантов становятся все толще, а эксперты LinkedIn заполняют наши ленты уверенностью. И это подводит меня к закону Конвея.</p> <h3>Выбор платформы — не отправная точка</h3> <p>Я несколько раз в неделю провожу семинар для клиентов под названием «Преодоление препятствий на пути внедрения ИИ в масштабах организации». Недавно один из клиентов сказал: «Закон Конвея срабатывает каждый раз. Мы хотим внедрить системы, прежде чем заняться бизнесом... и каждый раз получаем тот же результат: системы оказываются такими же несовершенными, как и наши организации». Другими словами: начните с операционной модели и организационной структуры, а затем ориентируйте платформы на соответствующие области.</p> <p>Одна из главных ошибок в области ИИ сейчас — это убеждение, что ответ кроется в основном в выборе правильной платформы, модели или стека поставщика. Это не так. Если операционная модель неясна, фрагментирована или создана для более ранней эпохи работы, система ИИ унаследует эти недостатки и воспроизведет их со скоростью машины. Вот почему закон Конвея снова кажется таким актуальным: системы не выходят за рамки организаций — они их зеркалируют. А в эпоху агентного ИИ они усиливают худшие из их особенностей: разобщенность, политику и многое другое.</p> <h3>Начните с вашей организации и ваших людей</h3> <p>Этот момент лежит в основе наших исследований когнитивной операционной модели, интеллектуального предприятия и архитектуры, ориентированной на навыки. И основная предпосылка этих исследований — парадокс производительности ИИ: преимущества рассеиваются внутри операционных моделей, разработанных для работы, выполняемой исключительно людьми и основанной на задачах. Прикручивание агентов к вчерашним ролям, рабочим процессам и правам принятия решений — это эффективное с точки зрения маркетинга внедрение технологий компаниями, которым необходимо максимизировать оценку IPO, чтобы получить капитал, необходимый для подпитки денежной печи ИИ.</p> <p>Вот почему переход от генеративного ИИ к агентному ИИ так важен. Генеративный ИИ был разминкой: агентный ИИ меняет правила игры, потому что мы переходим от промптов к планам. Эти системы теперь извлекают информацию, принимают решения, запускают процессы, уведомляют и действуют. Это смещает акцент с качества результатов на управление, подотчетность, координацию и легитимность — особенно в государственном управлении, где объяснимость, справедливость и общественное доверие являются незыблемыми.</p> <h3>Почему важно изменение операционной модели</h3> <p>Если ваша операционная модель разрознена, фрагментирована, перегружена передачей задач и построена на исключительно человеческом понимании работы, ваша система ИИ будет отражать эту сложность. Агенты будут выбираться, развертываться и управляться в соответствии с теми же линиями разлома. Результат? Дублирование возможностей, фрагментированный контекст, непоследовательный контроль и точечные решения, маскирующиеся под трансформацию.</p> <p>Закон Конвея объясняет, почему сдвиг операционной модели так важен. По своей сути, агентный ИИ — это проблема архитектуры работы и шок для операционной модели. Если агенты все чаще становятся исполнителями рутинной когнитивной работы по умолчанию, то организация должна быть перестроена с учетом этой реальности. Роли, рабочие процессы, пути эскалации, управленческие предположения и модели подотчетности — все меняется. В противном случае, технология просто автоматизирует археологию современных предприятий.</p> <h3>Почему важны навыки и контекст</h3> <p>Именно поэтому мы побуждаем людей отходить от мышления, основанного на конкретных сценариях использования, и рассматривать навык как атомарную единицу дизайна. Сценарий использования описывает проблему, которую необходимо решить. Навык описывает ограниченные когнитивные возможности, которые можно повторно использовать, которыми можно управлять и комбинировать в разных ролях и рабочих процессах. Организация портфелей агентных систем вокруг изолированных сценариев использования приводит к хрупким, разрозненным развертываниям, которые сопротивляются масштабированию. Организация вокруг навыков создает условия для компоновки, управления и устойчивых изменений операционной модели: динамичных, гибких и адаптивных.</p> <p>Другая половина этого — контекст. Одних только возможностей недостаточно. Реальная компетентность зависит от окружающего семантического слоя политики, лексики, памяти, следов принятия решений, неявных знаний и организационной логики. Без согласованного способа выявления и управления контекстом агентные системы будут зеркалировать недостающие знания предприятия, фрагментированную интерпретацию политики, слабую подотчетность и растущие затраты.</p> <h3>Почему закон Конвея имеет значение</h3> <p>Если бы мне пришлось превратить закон Конвея в практический контрольный список для руководителей в эпоху агентного ИИ, он бы звучал так:</p> <ul> <li><strong> Начать с операционной модели.</strong> Пусть платформа следует за работой, проблемными областями и результатами, которых организация должна достичь.</li> <li><strong> Создавать многократно используемые организационные возможности.</strong> Разрабатывайте навыки, роли, рабочие процессы и структуры управления, которые накапливаются в различных сценариях использования.</li> <li><strong> Рассматривать контекст как организационный интеллект.</strong> Сделайте политику, знания, память и логику принятия решений машиночитаемыми, управляемыми и доступными в точке работы.</li> <li><strong> Разрабатывать агентов, ориентируясь на организацию, которой вы хотите стать.</strong> Агенты усиливают систему, в которой они работают, включая ее сильные стороны, недостатки и модель подотчетности.</li> </ul> <p>Для меня в этом заключается современная ценность закона Конвея. В головокружительном вихре перемен, в котором мы находимся, если мы хотим, чтобы агентный ИИ создавал совокупную ценность, мы должны сначала перепроектировать операционную модель, которая его окружает. Вот почему наши текущие исследования так сосредоточены на структуре, контексте и перепроектировании самой работы. В противном случае мы не построим будущее работы — мы автоматизируем прошлое. Так что запомните: «Операционные модели обеспечивают результаты».</p> Если мы хотим, чтобы агентный искусственный интеллект создавал совокупную ценность, мы должны сначала перепроектировать … article Кто следит за вашими ИИ-агентами? https://www.itweek.ru/themes/detail.php?ID=235017 Wed, 17 Jun 2026 09:21:35 +0300 <p><em>Мультиагентные системы искусственного интеллекта уже вовсю работают в производственной среде, но кто за ними следит? Моше Бар, генеральный директор Codenotary, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>об операционных пробелах в отслеживании автономных агентов.</em></p> <p>За последние несколько месяцев произошли незаметные изменения. Фреймворки, такие как CrewAI, AutoGen и LangGraph, больше не просто появляются в демонстрациях — они работают в производственной среде.</p> <p>Команды объединяют планировщиков, использующих инструменты агентов, средства поиска и внешние API, а затем передают им реальную работу. Реагирование на инциденты, внутренние «вторые пилоты», конвейеры автоматизации — все это начинает выглядеть не как эксперименты, а как инфраструктура.</p> <p>И как только эти системы запускаются, проблемы становятся очевидными очень быстро. Не обычная проблема «LLM галлюцинируют». А что-то более операционное.</p> <p>Сейчас мы очень хорошо умеем создавать агентов, но не очень хорошо умеем ими управлять. Фреймворки упрощают компоновку, но они не дают реального контроля, когда все работает в масштабе.</p> <p>И этот пробел сразу же проявляется в производственной среде. Неприятная реальность заключается в том, что многие команды, развертывающие сегодня мультиагентные системы, работают с ними с меньшей прозрачностью, чем это было 10 лет назад при использовании микросервисов. Они доверяют результатам, не до конца понимая путь, который их породил.</p> <p>Это работает для демонстрации. Но это не работает, когда эти системы начинают взаимодействовать с реальными данными, реальными пользователями и реальными деньгами.</p> <p>На самом деле ломается сама система. Запрос, который должен занимать один или два шага, превращается в десятки вызовов модели. Агенты взаимодействуют друг с другом, повторяя попытки, перефразируя, зацикливаясь ровно настолько, чтобы оставаться работоспособными, но недостаточно эффективными. Задержка увеличивается. За этим следуют затраты. Ничего не падает, поэтому и оповещения не срабатывают. Вы просто замечаете, что что-то идет не так...</p> <p>Или, что еще хуже, кажется все работает, но ответ немного неверен. Один агент выдает ошибку по таймауту, другой компенсирует ее, третий заполняет пробелы частичным контекстом. К тому времени, как вы увидите результат, ошибка уже где-то глубоко запрятана в цепочке решений, которые трудно восстановить.</p> <p>А затем есть данные. Нет ни одной очевидной утечки, но происходит их постепенное распространение. Один агент читает конфиденциальную информацию, другой её резюмирует, третий включает её в запрос к внешней модели. Ни в какой момент ничего не выглядит явно опасным, однако система в целом выходит за рамки, за которые не должна выходить.</p> <p>Общая нить здесь в том, что никто на самом деле не видит, что происходит.</p> <p>Большинство команд пытаются использовать уже имеющиеся инструменты. Журналы, трассировки, возможно захват запросов. Это помогает в крайних случаях, но не отвечает на основной вопрос: как система на самом деле пришла к такому результату?</p> <p>Агентные системы — это не просто распределенные системы с большим количеством вызовов API. Они ведут себя скорее как развивающиеся графы выполнения, где решения принимаются динамически, а пути меняются в зависимости от промежуточных результатов. Наблюдение за отдельными вызовами похоже на просмотр одного кадра стека и попытку вывести всю программу целиком.</p> <p>Чего не хватает, так это видимости на уровне, где эти системы фактически работают.</p> <p>Необходимо видеть, как запрос разворачивается между агентами, насколько глубока цепочка рассуждений, где она разветвляется и где зацикливается сама на себе. Необходимо понимать не только то, что токены были израсходованы, но и почему их количество продолжало расти на разных этапах. Необходимо отслеживать движение данных — не только их исходное состояние, но и то, как они трансформировались и куда в конечном итоге попали.</p> <p>Без этого отладка сводится к симптомам. Медленная реакция здесь, завышенный счет там, случайный неправильный ответ. Основное поведение остается неясным.</p> <p>Особенно интересно то, что эти системы со временем формируют закономерности. Хотя они и не детерминированы, они и не случайны. Определенные потоки становятся распространенными, определенная глубина рассуждений — типичной. Эта базовая линия невероятно полезна, потому что реальный сигнал поступает, когда система отклоняется от нее. Когда агент внезапно выбирает путь, по которому он никогда раньше не ходил, или начинает получать доступ к данным, к которым обычно не обращался, или расширяет цепочку рассуждений далеко за пределы ее обычной формы.</p> <p>Вот где должен находиться мониторинг — не в статических правилах, а в достаточно глубоком понимании нормального поведения системы, чтобы распознавать отклонения.</p> <p>Вопрос не в том, нужен ли агентам мониторинг. Вопрос в том, готовы ли мы относиться к ним как к системам, которыми они уже стали.</p> <p>Сейчас большинство из нас не готовы, и это нужно исправить.</p> Мультиагентные системы искусственного интеллекта уже вовсю работают в производственной среде, но кто за ними … article Linux Foundation: наметился тренд сокращения начинающих специалистов в сфере технологий https://www.itweek.ru/themes/detail.php?ID=235015 Tue, 16 Jun 2026 09:40:46 +0300 <p><em>Новый <a href="https://www.linuxfoundation.org/hubfs/Research%20Reports/State-of-Tech-Talent-Europe-2026-REV-1.pdf">отчет</a> </em><em>Linux</em> <em>Foundation</em><em> «</em><em>2026 </em><em>State</em> <em>of</em> <em>Tech</em> <em>Talent</em> <em>Europe</em> <em>Report</em> <em>показывает», что искусственный интеллект способствует 27%-ному росту найма в сфере технологий в Европе, даже несмотря на сокращение числа вакансий для начинающих специалистов как растущей глобальной тенденции, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>Влияние ИИ на мировую рабочую силу ощущается во всех отраслях, но, пожалуй, нигде это не проявляется так остро, как в разработке ПО и в технологическом секторе в целом.</p> <p>Такие компании, как OpenAI и Google, уже переосмысливают представление о руководящих технических должностях: FDE (<strong>Forward Deployed Engineer</strong><strong>s</strong><strong>, </strong>инженеры по передовому внедрению) — технические специалисты широкого профиля, которые выступают посредниками между моделью ИИ и заказчиком, преобразуя сложные возможности в работающие решения, — становятся одними из самых востребованных в отрасли.</p> <p>В других областях возникают проблемы с проверкой кода, сгенерированного ИИ, что меняет повседневную работу инженерных команд. А вакансии для начинающих программистов — традиционный путь в карьеру в сфере ПО — выглядят все более нестабильными.</p> <p>Новый отчет Linux Foundation проливает некоторый свет на то, что часто обсуждается без фактических данных, и картина выглядит гораздо сложнее, чем принято считать.</p> <h3>Сокращение числа начинающих специалистов</h3> <p>Linux Foundation опросил почти 400 менеджеров по найму и обучению на европейском и других крупных рынках и обнаружил, что ИИ приводит к чистому увеличению найма технических специалистов на 27% в Европе. Но эта цифра скрывает нечто важное: в европейских организациях наблюдается тенденция к сокращению числа начинающих специалистов на 3%, хотя в остальном мире эта категория выросла на 14%.</p> <p>В отчете не дается однозначного объяснения того, почему Европа может отставать от остального мира в вопросах найма молодых специалистов, но отмечается, что Старый Свет отстает по ряду более широких показателей готовности к внедрению ИИ, включая меньшее развертывание основной инфраструктуры ИИ, более острую нехватку персонала в сфере кибербезопасности и более медленное внедрение технологического стека, лежащего в основе производственного ИИ.</p> <p>Тьерри Каррез, генеральный директор Linux Foundation Europe, связывает вопрос о талантах с более широким стремлением к технологической независимости Европы — движением, охватывающим все, от облачной инфраструктуры и разработки ИИ до суверенитета данных и стремления к снижению зависимости от крупных технологических компаний.</p> <p>«Цифровой суверенитет невозможен без местных технических специалистов, — говорит он. — ИИ меняет все. Модели продолжают расти в своих возможностях, и их влияние на рынок технических специалистов необходимо должным образом оценить».</p> <p>Хотя распространилось мнение, что ИИ уничтожает технологические должности начального уровня, Сеад Ахметович, генеральный директор и соучредитель глобальной платформы для найма разработчиков и проведения мероприятий WeAreDevelopers, утверждает, что реальность гораздо сложнее. По его словам, что паника по поводу сокращения найма начинающих специалистов не отражает реальной ситуации: «Должности начального уровня не исчезают, но исчезает работа, которая их определяла. ИИ теперь выполняет многие задачи, на которых обучались начинающие разработчики, поэтому старое определение роли джуниора устаревает. Новое определение выглядит совершенно иначе и требует другого набора навыков с первого дня».</p> <p>Авторы отчета сами признают это, отмечая, что если тенденция к сокращению сохранится, это, вероятно, будет отражать поглощение ИИ задач, которые традиционно служили отправной точкой для начала карьеры.</p> <p>«Организации могут сокращать набор джуниоров, одновременно увеличивая спрос на должности мидлов и сеньоров, требующие умения принимать решения, контекстного мышления и контроля над системами ИИ», — говорится в отчете, что поднимает вопросы о том, как необходимо переосмыслить саму роль джуниора, прежде чем можно будет перестроить кадровый резерв.</p> <p>Проще говоря, возможно, европейской индустрии просто нужно время, чтобы наверстать упущенное — компании медленнее переосмысливают эти роли, чем ИИ их замещает.</p> <h3>Вверх по стеку </h3> <p>Давление на навыки не ограничивается младшим сегментом рынка. В отчете Linux Foundation говорится, что почти две трети европейских организаций заявляют о значительных пробелах в компетенциях в области безопасности ИИ и управления ИИ-рисками. Эта сфера вызвала наибольшее беспокойство в ходе опроса, опередив пробелы в технических ИИ-навыках. Также растет спрос на кросс-доменных специалистов, и такое сочетание находится в дефиците на любом уровне — тенденция, которую, по словам Ахметовича, он видит непосредственно в процессе найма.</p> <p>«Настоящая проблема — это дефицит квалифицированных кадров, и он затрагивает все уровни, — говорит он. — В сфере технологий всех продвигают вверх по стеку. Компаниям нужны люди, которые сочетают в себе навыки разработки ПО, владение ИИ, осведомленность в вопросах безопасности, продуктовое мышление и понимание бизнеса, а такое сочетание редко встречается на любом уровне».</p> <p>Этот профиль — технически подкованный специалист широкого профиля, разбирающийся в разработке, ИИ и бизнес-контексте — уже становится одной из самых востребованных ролей в сфере технологий, и наиболее ярким примером является FDE: роль, находящаяся на стыке глубоких технических знаний и навыков работы с клиентами.</p> <p>Финтех-гигант Ramp внедряет эту модель на уровне новой услуги: компания направляет собственных инженеров непосредственно в финансовые команды клиентов для создания и развертывания агентов ИИ — ставка на то, что разрыв между возможностями ИИ и реальным внедрением может быть преодолен только с помощью человеческой экспертизы на местах. Ори Дэниел, возглавляющий новый сервис Ramp, говорит, что импульсом послужило одно ключевое наблюдение: «Узким местом оказалась не сама модель, а кропотливая предварительная работа, которая должна быть проделана, чтобы сделать данные и бизнес-контекст понятными для агентов».</p> <h3>Проблема конвейера</h3> <p>Однако всё это не решает вопрос о специалистах начального уровня. В отчёте установлено, что организации в 3,7 раза чаще инвестируют в обучение существующих сотрудников, чем в найм новых, и что когда они всё же нанимают новых сотрудников, тем требуется более чем вдвое больше времени, чтобы стать полностью продуктивными. В краткосрочной перспективе становится всё сложнее оправдать экономическую целесообразность привлечения джуниоров, даже несмотря на то, что долгосрочная потребность в таком кадровом резерве остаётся неизменной.</p> <p>Аргумент Ахметовича заключается в том, что формулировка вопроса как бинарного — нанимать джуниоров или нет — совершенно неверна. «Остается верным утверждение, что невозможно вырастить сеньора, не наняв сначала джуниора, — говорит он. — Разумный ответ заключается не в сокращении кадрового резерва молодых специалистов, а в его перепроектировании. Необходимо быстрее повышать квалификацию сотрудников и создавать более четкий путь от специалистов начального уровня к реальным инженерным обязанностям».</p> <h3>Как на самом деле выглядит новая роль джуниора</h3> <p>Данные Linux Foundation указывают на то, что среди европейских организаций инвестиции в техническое обучение занимают более высокое место, чем компенсация как инструмент удержания персонала, это отметили 93% респондентов. Аппетит к разработке есть. Чего не хватает, так это четкого представления о том, как на самом деле выглядит новая роль джуниора, и понимания срочной необходимости создания программ обучения, соответствующих направлению развития отрасли, прежде чем разрыв между существующими должностями и людьми, способными их занять, станет сложнее преодолеть.</p> <p>Стоит отметить, что к этим выводам следует относиться с некоторой осторожностью. Опрос в значительной степени опирается на организации, уже активно занимающиеся внедрением Open Source и ИИ — эта группа, вероятно, сообщает о более позитивных результатах, чем рынок в целом. Отчет отражает то, как относительно вовлеченные в ИИ компании ожидают развития процесса найма, а не то, как, вероятно, будет развиваться европейский рынок труда в сфере технологий в целом.</p> Новый отчет Linux Foundation «2026 State of Tech Talent Europe Report показывает», что искусственный интеллект способствует … article Forrester: разработка ПО эволюционирует от помощников по кодированию к оркестрированным агентам SDLC https://www.itweek.ru/themes/detail.php?ID=235013 Tue, 16 Jun 2026 09:11:29 +0300 <p><em>В 2026 г. разработка ПО вышла на новый рубеж. Генеративный искусственный интеллект больше не просто помогает разработчикам быстрее писать код; он меняет подход к планированию, созданию, тестированию и поставке ПО, пишет в корпоративном блоге Диего Ло Джудиче, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Недавний отчет Forrester «The State Of Agentic Software Development, 2026», показывает, что боты TuringBots теперь становятся агентами, а не просто ИИ-помощниками, встроенными в отдельные инструменты. Новой нормой является разработка ПО с использованием автономных агентов, которые сотрудничают на протяжении всего жизненного цикла разработки программного обеспечения (SDLC), стремясь к более сквозной автоматизации.</p> <p>Этот сдвиг важен, потому что изолированного повышения индивидуальной производительности уже недостаточно. Технологические лидеры находятся под давлением: от них требуют добиваться более быстрых и безопасных результатов, не увеличивая штат сотрудников и не повышая риски. Агентные подходы становятся единственным надежным способом достичь и того, и другого.</p> <h3>От TuringBots к агентному SDLC</h3> <p>Эволюцию лучше всего представить как три фазы (см. рисунок ниже).</p> <p> #IMAGE_235014#</p> <p>В течение 2023 и 2024 гг. TuringBots в основном были сфокусированы на кодировании и модульном тестировании. В <nobr>2025-м</nobr> эти возможности расширились на смежные задачи, такие как документирование, помощь в проектировании и генерация тестов. Сейчас, в 2026 г., мы видим настоящий переломный момент: агенты теперь работают на всех этапах: анализ и планирование, проектирование, разработка, тестирование и доставка — и все чаще координируются между собой.</p> <p>Вместо того чтобы просить один инструмент генерировать код, команды теперь могут делегировать задачи («создать данную функцию»), в то время как агенты декомпозируют работу, генерируют артефакты, запускают тесты и готовят релизы. Люди остаются ответственными, тогда как ИИ выполняет большую часть работы.</p> <h3>Без сквозного внедрения ИИ повышение производительности будет разочаровывающим</h3> <p>Многие компании разочарованы первыми результатами, потому что они применяют ИИ слишком узко. Кодирование может улучшиться на <nobr>30-40%,</nobr> но если планирование, тестирование и выпуск остаются ручными, общая производительность команды часто увеличивается менее чем на 10%. Узкие места просто перемещаются. Агентная разработка ПО меняет математику. Когда ИИ применяется последовательно на протяжении всего SDLC, преимущества накапливаются, а не компенсируют друг друга. Именно поэтому ведущие разработчики переходят от точечных инструментов к агентным платформам, которые координируют работу множества специализированных агентов, вместо того чтобы сосредотачиваться только на генерации кода.</p> <h3>Роли разработчиков ПО не исчезнут, но они будут эволюционировать</h3> <p>Агентная разработка не устранит разработчиков, тестировщиков или архитекторов, но она изменит представление о том, что значит «хорошо» для каждой из этих ролей.</p> <ul> <li><strong> Менеджеры/владельцы продуктов</strong> «вайбят» прототипы и функции для остальной командой для внедрения в продукт. Они также генерируют спецификации, что позволяет осуществлять разработку, основанную на спецификациях.</li> <li><strong> Разработчики</strong> меньше пишут код и тратят больше времени на проверку, руководство и координацию работы агентов по кодированию. По мере совершенствования ИИ и роста доверия к нему они будут писать и проверять минимальное количество кода, если вообще будут это делать.</li> <li><strong> Тестировщики</strong> переходят от написания скриптов тестов к установлению целей по качеству и контролю за агентами тестирования, включая тестирование самих систем ИИ.</li> <li><strong> Архитекторы и старшие инженеры</strong> уделяют больше внимания проектированию системы, ограничениям и контекстной инженерии — обеспечивая работу агентов в рамках заданных границ.</li> </ul> <p>Во всех ролях критически важным навыком является не только техническая глубина, но и способность четко определять намерения, контекст и ограничения для ИИ-коллег.</p> <h3>Тестирование и управление станут более, а не менее важными</h3> <p>По мере роста автономности доверие становится ограничивающим фактором. Агентные системы могут выдавать галлюцинации, вносить незаметные дефекты или распространять ошибки быстрее, чем это когда-либо могли бы сделать люди. Именно поэтому тестирование становится более, а не менее важным в агентном SDLC.</p> <p>Ведущие организации инвестируют и переходят от TuringBots к агентной разработке ПО и теперь относятся к артефактам, созданным ИИ, с той же или даже большей строгостью, что и к коду, написанному человеком. В то же время управление должно масштабироваться по мере роста внедрения. Прежде чем расширять автономность агентов в производственных системах, необходимо обеспечить защитные механизмы, возможность аудита и четкую ответственность человека.</p> <h3>Что должны делать технологические лидеры сейчас</h3> <p>Для CIO, CTO и вице-президентов по инжинирингу <nobr>2026-й —</nobr> это год перехода от экспериментов к целенаправленному внедрению. Вот четыре ключевых шага, которые вы должны предпринять уже сейчас:</p> <ol> <li><strong> Проведите пилотные проекты на нескольких этапах SDLC,</strong> смещая применение ИИ на более ранние и более поздние этапы, а не только используя его в процессе кодирования, чтобы выявить реальные узкие места и преимущества.</li> <li><strong> Развивайте операционные модели и роли, </strong>четко определяя, как взаимодействуют люди и агенты.</li> <li><strong> Инвестируйте в тестирование и управление ИИ на ранних этапах,</strong> включая тестирование приложений с ИИ и самих агентов.</li> <li><strong> Сосредоточьтесь на платформах агентной разработки, а не на инструментах,</strong> отдавая предпочтение платформам, которые координируют и обеспечивают оркестровку агентов от начала до конца.</li> </ol> <p>Агентная разработка ПО больше не является концепцией будущего. Она становится доминирующей моделью для высокоэффективных команд разработчиков. Лидерами, которые добьются успеха в 2026 г., станут те, кто будет рассматривать агентов не как умных помощников, а как первоклассных участников в перестроенном, сжатом SDLC — с человеком, твердо контролирующим ситуацию.</p> В 2026 г. разработка ПО вышла на новый рубеж. Генеративный искусственный интеллект больше не просто … article «СёрчИнформ Файловый Аудитор» взял под контроль облачные хранилища в Google Workspace 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 Платформа Tantor 6.4: поддержка СУБД Tantor Polar, новые возможности ИИ-ассистента, аудита и мониторинга 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 ИСИЭЗ НИУ ВШЭ: топ-10 технологий в металлургии 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 К 2031 году российский сегмент рынка средств защиты конечных точек может вырасти до 78,3 млрд руб. 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 PlatformCraft запустила холодное объектное хранилище для архивных и редко используемых файлов 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” IDC: как обеспечить надлежащее руководство внедрением агентного ИИ 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 От Disaster Recovery к Multi-AZ: новая архитектура непрерывности бизнеса 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 Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” Иллюзия автоматизации: почему 90% ИИ-проектов не доходят до результата 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 Исследование: 65% российских компаний увеличили IT-бюджеты в 2026 году — главным направлением инвестиций стал искусственный интеллект 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 Npm-атаки стали чаще приводить к компрометации CI/CD и облачных секретов 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 Astra Server Core: доверенная ИТ-инфраструктура “из коробки” 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 Валерий Васильев Как поддержка ERP и инфраструктуры снижает реальные потери бизнеса 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 «Спикател» представила результаты исследования защищенности API в российском финансовом секторе за 2025–2026 годы 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 Forrester: сетевые вендоры наконец-то начинают создавать платформы, а не просто дашборды 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 Время появления эксплойтов после публикации CVE сократилось до 12 часов 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 ПСХБ совместно с BSS запустил первый полноценный сервис онлайн-оплаты для иностранных туристов в РФ 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 Безопасность замедляет внедрение автономного ИИ — как реагируют CIO 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 Сбер представил быструю и защищенную версию ИИ-ассистента разработчика — GigaCode CLI 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 Luxms BI v12: платформа с ИИ для нового поколения корпоративной аналитики 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 Forrester: компании гонятся за ИИ, но лишь немногие достигают результата 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 Как изменения законодательства меняют рынок IT-оборудования 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 Сергей Семикин, СЕО компании “ГИГАНТ — Компьютерные системы” M1Cloud: ИИ как инфраструктура — трансформация корпоративных систем и платформенных решений 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