https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif https://www.itweek.ru https://www.itweek.ru/themes/detail.php?ID=235207 Fri, 17 Jul 2026 15:43:56 +0300 <p>Для обучения ИИ-моделей требуется высокопроизводительные GPU-серверы, но как только модель обучена и переходит в режим эксплуатации (inference), на первый план выходит скорость отклика, то есть одним из решающих факторов становится физическое расстояние между пользователем и дата-центром, в котором развернута облачная платформа. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что разница принципиальна: при обучении оптимизируется стоимость за час GPU-времени, при инференсе — стоимость каждой миллисекунды задержки исчисляется в потерянных клиентах.</p> <p>Уже более 10 лет назад компания Amazon выяснила, что каждые 100 мс задержки приводят к снижению продаж на 1%. Сейчас для ИИ-сервисов ставки еще выше: если рекомендательная модель отвечает с задержкой, пользователь уже принял решение без нее. Современные ИИ-приложения работают в реальном времени. Чат-бот должен начать генерировать ответ за доли секунды. Рекомендательная система в e-commerce должна подобрать товары до того, как покупатель прокрутит страницу. Система антифрод в банке должна принять решение о блокировке транзакции за <nobr>50–200</nobr> миллисекунд — пока карта еще «в терминале». Каждая из этих задач решается в реальном времени и критически зависит от задержки сети. Латентность перестает быть инженерной абстракцией и становится прямым фактором выручки и потерь.</p> <p>Эксплуатация ИИ-сервиса — это непрерывный поток запросов от реальных пользователей, каждый из которых ожидает мгновенного ответа. В этом случае география ЦОД, где развернуто облако, определяет качество ИИ-сервиса. Для чат-бота, который должен начать стриминг ответа за <nobr>100–150 мс,</nobr> например, потеря на сетевую задержку даже 50 мс с учетом маршрутизации и обработки — это треть бюджета латентности, потраченная впустую.</p> <p>Для российского рынка это особенно актуально. Более 76% действующих в России дата-центров расположены в Москве и Московской области (по данным TAdviser). Это создает естественное преимущество для провайдеров с площадками в Москве — большинство пользователей и бизнес-систем находятся в радиусе минимальной сетевой задержки. Но одновременно это означает, что компании из регионов — Урала, Сибири, Дальнего Востока — получают ИИ-сервисы с неизбежной дополнительной латентностью.</p> <p>Глобальный рынок ИИ оценивается в $106 млрд по итогам 2025 года и, по прогнозу Polaris Market Research, будет расти со среднегодовым темпом 19,4% до 2034 года. При этом Gartner прогнозирует, что к 2029 году 50% всех облачных вычислительных ресурсов будут направлены на ИИ-нагрузки — против менее 10% сегодня. Это означает, что постоянная круглосуточная работа моделей в продакшене — становится основным потребителем облачной инфраструктуры, где латентность критична.</p> <p>Зрелый подход к развертыванию ИИ-сервисов предполагает распределенную архитектуру инференса ИИ-моделей. Тяжелое обучение моделей может происходить в центральном кластере с максимальной концентрацией GPU. Но инференс-серверы — точки, где модель обрабатывает запросы пользователей — должны располагаться максимально близко к потребителю, то есть размещение ИИ-сервиса в ближайшем к пользователю дата-центре.</p> <p>Для рынка сервис-провайдинга это означает, что с 2026 года будет ощутимо увеличиваться спрос на региональные облачные кластеры, то есть растет необходимость инвестировать не только в наращивание GPU-мощностей, но и в географическое присутствие в нескольких точках с гарантированной низкой латентностью и с возможностью разместить инференс-ноды отдельно от основного кластера.</p> <p>В мире, где ИИ становится интерфейсом взаимодействия бизнеса с клиентом, миллисекунды — это не техническая деталь. Это деньги, лояльность и конкурентное преимущество.</p> Для обучения ИИ-моделей требуется высокопроизводительные GPU-серверы, но как только модель обучена и переходит … message https://www.itweek.ru/themes/detail.php?ID=235206 Fri, 17 Jul 2026 15:42:54 +0300 <p>Как превратить разовые проверки безопасности в непрерывный процесс, который действительно защищает бизнес, а не просто формально закрывает требования регуляторов? Эксперт Security Vision Виктор Гончаров представил системный подход к управлению конфигурациями (Security Hardening), продемонстрировав его эффективность на примере работы с крупными отраслевыми компаниями. В условиях массового перехода к гибридным облачным архитектурам и микросервисам именно некорректные настройки становятся главным вектором атак. Предложенный подход показывает, как автоматизация помогает связать абстрактные требования комплаенса с реальными техническими параметрами ИТ-инфраструктуры, устраняя разрыв между бумажной отчетностью и фактическим состоянием защищенности.</p> <p>Практика кибербезопасности демонстрирует, что к инцидентам чаще приводят не сложные целевые атаки, а базовые ошибки конфигурирования. К ним относятся использование стандартных или слабых паролей, наличие избыточных привилегий у пользователей, открытые в сеть неиспользуемые порты и отсутствие сетевой сегментации.</p> <p>Главная проблема современных динамичных инфраструктур — так называемый «дрейф» конфигураций. После любых обновлений ПО или изменений в бизнес-процессах настройки имеют свойство самопроизвольно меняться, открывая уязвимости и эксплойты. Именно поэтому управление конфигурациями трансформируется из разовой задачи по настройке в непрерывный циклический процесс.</p> <p>«Харденинг, или безопасное конфигурирование, — это процесс циклический, — отмечает Виктор. В 2026 году он должен охватывать пять ключевых уровней: организационный, сетевой, виртуализации, уровень ОС и уровень ПО. Ключевая цель этого процесса — минимизация привилегий без нарушения функциональности конечных систем и комфорта пользователей».</p> <p>Для многих организаций соответствие требованиям ФСТЭК России или международным стандартам CIS Benchmark часто остается формальностью. Основная сложность при проведении аудитов заключается в разрыве между стратегическими проверками и фактическим состоянием ИТ-среды и установленными патчами.</p> <p>Чтобы связать пункты нормативных документов с конкретными параметрами конфигурационных файлов и реестров, необходим системный харденинг. Решение этой задачи лежит в плоскости использования инструментов, которые автоматически маппят требования стандартов на технические проверки. Такой подход позволяет перевести комплаенс из формата регулярного сбора справок в полноценную часть системы управления кибербезопасностью.</p> <p>Для автоматизации рутинных операций и выстраивания эффективного процесса на практике применяются специализированные платформы. В частности, решения Security Vision (модули Asset Management и Security Profile Compliance) позволяют замкнуть этот цикл, обеспечивая прозрачность и полный контроль над инфраструктурой.</p> <p>Глубокая инвентаризация (Asset Management). Процесс начинается не с простого сканирования сети, а с формирования ресурсно-сервисной модели. Система идентифицирует хосты, сервисы и ПО, рассчитывает роли активов и группирует их по степени критичности для бизнес-процессов. Это позволяет грамотно приоритизировать задачи: в первую очередь защищаются те системы, остановка которых может парализовать работу всей компании.</p> <p>Формирование и применение профилей (Security Profile Compliance). Вместо трудоемкого ручного аудита безопасности используются готовые эталоны: в базовом релизе платформы доступно более 70 профилей проверок, сформированных на основе собственной экспертизы вендора (наработанной в секторах телекома, финансов, промышленности и ритейла), рекомендаций ФСТЭК России и глобальных стандартов. Платформа содержит несколько тысяч готовых проверок «из коробки», которые можно гибко настраивать, тестировать перед публикацией и адаптировать под специфику конкретного бизнеса.</p> <p>Непрерывный мониторинг и автоматизация. Платформа использует встроенные возможности операционных систем (SSH, WMI, Remote PowerShell) для централизованного управления параметрами защиты и автоматического снижения поверхности атак. При выявлении отклонения от эталона система автоматически формирует задачи на исправление с соблюдением установленных SLA. Интерактивные дашборды и графы связей предоставляют руководителям ИБ рабочий инструмент для анализа любых срезов данных, заменяя собой статичную и часто бесполезную отчетность.</p> <p>Важнейшим преимуществом такого подхода является интеграция данных об инвентаризации и отклонениях в единую витрину. Информация передается в SIEM-системы и решения класса VM (Vulnerability Management), что позволяет использовать контекст об уровне защищенности конкретного актива для более точной корреляции событий безопасности и эффективного управления рисками. Таким образом, оперативные данные о конфигурациях напрямую влияют на качество реагирования на инциденты.</p> <p>Как резюмировал Виктор Гончаров, автоматизация управления конфигурациями дает максимальный эффект, высвобождая ресурсы специалистов для решения сложных архитектурных задач вместо рутины. Связь практических метрик защиты с нормативными требованиями позволяет компаниям обеспечить жесткое соответствие стандартам регуляторов и укрепить защиту инфраструктуры, не блокируя при этом операционную деятельность и дальнейшее развитие.</p> Как превратить разовые проверки безопасности в непрерывный процесс, который действительно защищает бизнес … message https://www.itweek.ru/themes/detail.php?ID=235205 Fri, 17 Jul 2026 15:41:19 +0300 <p>Компании «Аладдин» и «САФИБ» подтвердили совместимость USB-токенов и смарт-карт JaCarta с системой удаленного мониторинга и управления «АССИСТЕНТ». По итогам испытаний получен сертификат, подтверждающий корректную работу решений в составе единой ИТ-инфраструктуры.</p> <p>В ходе испытаний подтверждена корректная работа средств строгой аутентификации JaCarta LT, JaCarta PKI, JaCarta-3 PKI, JaCarta-2 ГОСТ, JaCarta-3 ГОСТ, JaCarta-2 РКІ/ГОСТ, JaCarta-3 РКІ/ГОСТ и JaCarta-2 SE с системой удаленного мониторинга и управления «АССИСТЕНТ». Сертификат подтверждает готовность решений к совместному применению и обеспечивает заказчикам возможность построения защищенной среды удаленного администрирования с использованием отечественных технологий.</p> <p>Проверка проводилась в различных программно-аппаратных конфигурациях, включая операционные системы семейства Microsoft Windows, Astra Linux, РЕД ОС, Альт, РОСА, ОСнова, Debian, Ubuntu, CentOS, а также macOS (11.6 — 15). Испытания подтвердили стабильную и корректную работу решений во всех заявленных программно-аппаратных конфигурациях.</p> <p>В линейку продуктов JaCarta входят сертифицированные средства строгой аутентификации, электронной подписи для безопасного хранения ключей, работы с цифровыми сертификатами и интеграции с корпоративными системами управления доступом и единым входом (SSO). Смарт-карты, электронные ключи и USB-токены JaCarta сертифицированы ФСТЭК России и ФСБ России, включены в реестры Минпромторга РФ и Минцифры РФ и совместимы с российскими и зарубежными ОС.</p> <p>Система удаленного мониторинга и управления «АССИСТЕНТ» предназначена для организации безопасного удаленного доступа, управления и администрирования компьютерной техники и серверного оборудования внутри изолированной защищенной локальной сети или через сеть Интернет. «АССИСТЕНТ» включен в реестр отечественного программного обеспечения, сертифицирован ФСТЭК России и успешно применяется в государственных структурах, промышленных предприятиях, финансовом секторе и образовательных учреждениях для построения импортонезависимых систем удаленного управления ИТ-инфраструктурой.</p> <p>«Вопросы безопасного удаленного администрирования приобретают особую актуальность для организаций любого масштаба. Подтверждение совместимости JaCarta с системой „АССИСТЕНТ“ расширяет возможности наших заказчиков по построению доверенной ИТ-инфраструктуры, в которой надежная аутентификация сочетается с удобными инструментами управления и поддержки», — прокомментировал Сергей Ступин, руководитель продуктов семейства JaCarta, «Аладдин». </p> <p>«Для наших заказчиков важно, чтобы система „АССИСТЕНТ“ легко интегрировалась с отечественными средствами информационной безопасности. Подтвержденная совместимость с продуктами JaCarta означает, что теперь они могут строить защищенный контур управления, используя сертифицированные средства строгой аутентификации в связке с нашей системой. Это готовое доверенное решение, которое позволяет соблюдать регуляторные требования и при этом сохранять гибкость и удобство удаленной работы с любыми ОС», — прокомментировал Виталий Панкратов, заместитель генерального директора ООО «САФИБ». </p> Компании «Аладдин» и «САФИБ» подтвердили совместимость USB-токенов и смарт-карт JaCarta с системой удаленного … message https://www.itweek.ru/themes/detail.php?ID=235204 Fri, 17 Jul 2026 15:39:43 +0300 <p>MWS Cloud, входящая в МТС Web Services (MWS), почти в два раза расширила число больших языковых моделей, доступных в сервисе MWS GPT Model Hub, доведя их количество до 17. Главными пополнениями платформы стали GLM 5.2, опенсорс LLM от компании Z.AI, которая была признана лучшей LLM в агентских задачах. MWS Cloud первой в России предоставила клиентам инференс GLM 5.2 в собственном облаке. Кроме того, в сервисе появились первые модели распознавания речи (ASR) и синтеза речи (TTS), а также реранкеры для повышения качества поиска и RAG-пайплайнов. Сервис доступен в рамках платформы MWS Cloud Platform.</p> <p>Среди новых LLM — GLM 5.2, Kimi K2.6, Qwen3.6, Gemma 4, GPT OSS и другие. Каталог из 17 моделей даёт разработчикам возможность подбирать модель под конкретную задачу с учётом требований к качеству, скорости и стоимости. Все модели доступны через единый OpenAI-совместимый API, что упрощает интеграцию и переключение между ними.</p> <p>Сервис рассчитан на внедрение AI-ассистентов в продукты, построение интеллектуального поиска, обработку текстовых данных, автоматизацию поддержки, создание AI-инструментов для разработчиков и внутренних сервисов для сотрудников. Все вычисления происходят в облаке MWS Cloud Platform, не покидая пределов страны.</p> <p>GLM 5.2 — опенсорс-модель от Z.AI, ориентированная на сценарии, где важны качество рассуждений, глубокий анализ текстов и обработка многошаговых запросов. Модель расширяет возможности MWS GPT Model Hub для команд, которые встраивают AI-функции в продукты, внутренние сервисы, инструменты поддержки и backend-приложения.</p> <p>MWS Cloud первой в России развернула GLM 5.2 на собственной инфраструктуре — модель хостится на серверах компании, все вычисления происходят на GPU внутри MWS Cloud. Для бизнеса это значит, что запросы обрабатываются в России и не передаются провайдеру модели или посредникам — а значит, данные не покидают юрисдикцию РФ и не зависят от условий доступа со стороны иностранного вендора.</p> <p>Также в каталоге появилась Kimi K2.6 от Moonshot AI. Модель подходит для обработки сложных пользовательских запросов, анализа документов, генерации развёрнутых ответов и построения AI-ассистентов. Вместе с GLM 5.2 она формирует линейку для наиболее требовательных AI-задач.</p> <p>Помимо LLM, в MWS GPT Model Hub в режиме превью добавлены модели распознавания речи (ASR) и синтеза речи (TTS), такие как Whisper Large v3, Qwen3 ASR 1.7B, Qwen3 TTS Custom Voice. Они открывают новый класс сценариев: транскрибацию аудио, создание голосовых ассистентов, озвучивание текстов. В сервисе также стали доступны реранкеры — инструменты для более точного ранжирования найденных фрагментов и выбора релевантного контекста при ответе модели. Они повышают качество RAG-пайплайнов и работы с базами знаний.</p> <p>«В современной архитектуре агентских решений логично оркестрировать много моделей, каждая из которых лучше всего подходит для своего класса задач. Множество моделей, позволяющих работать с разными модальностями и объединённых с инструментами автоматизации и хранения данных в нашем облачном MWS Model Hub, — именно то, что нужно бизнесу для оптимального решения прикладных задач», — прокомментировал генеральный директор МТС Web Services Павел Воронин.</p> MWS Cloud, входящая в МТС Web Services (MWS), почти в два раза расширила число больших языковых моделей, доступных … message https://www.itweek.ru/themes/detail.php?ID=235203 Fri, 17 Jul 2026 15:38:48 +0300 <p>Аналитика инцидентов «Информзащиты» за <nobr>2025-2026</nobr> годы показала, что случаи утечек, где фигурирует несанкционированное использование ИИ, фиксируются все чаще и уже выделяются в отдельный класс событий. В июле 2026 году уже 20% организаций, столкнувшихся с утечками, связали произошедшее хотя бы частично с применением ИИ-инструментов вне утвержденных процессов и контроля служб информационной безопасности. По внутренней выборке расследований за 2025 год доля таких инцидентов составляла около 12%, что позволяет напрямую сравнить динамику год к году. Рост на 8 п. п. за год указывает, что сценарии с ИИ переходят из редких в типовые. Такие инциденты обходятся дороже (в среднем +670 тыс. долларов), поскольку утечка происходит без триггера классических защитных механизмов и обнаруживается позже. Специалисты связывают эту динамику с тем, что сотрудники и отдельные подразделения подключают генеративные сервисы, расширения и программные интерфейсы быстрее, чем компании успевают включить их в контур управления ИБ.</p> <p>По данным опроса клиентов и аудитов инфраструктуры, лишь около 30% компаний имеют инвентаризацию используемых ИИ-сервисов. Остальные видят лишь официально внедренные решения или контролируют отдельные облачные платформы. При этом сотрудник может установить браузерное расширение, передать текст во внешний чат-бот, подключить API к внутреннему скрипту или использовать ИИ-ассистента для обработки рабочего документа без участия ИТ- и ИБ-подразделений. Для SIEM и прокси — это неотличимо от обычных запросов к SaaS: домен легитимен, TLS корректен, сигнатур нет, но данные уже ушли наружу.</p> <p>В 2026 году одним из наиболее заметных векторов остаются веб-интерфейсы публичных ИИ-сервисов. На них приходится около 42% выявленных инцидентов, связанных с теневым ИИ. Сотрудники загружают договоры, фрагменты исходного кода, внутреннюю переписку, клиентские обращения и техническую документацию для перевода, анализа или подготовки ответа. Еще 24% случаев связаны с браузерными расширениями и ИИ-помощниками, которые получают доступ к содержимому открытых вкладок, истории сессий и другим данным браузера. Такие расширения на 60% чаще содержат известные уязвимости по сравнению с обычными дополнениями, в три раза чаще запрашивают доступ к сессионным cookie и в шесть раз чаще меняют набор разрешений после установки. Около 19% инцидентов приходится на самостоятельно подключенные API и библиотеки для работы с ИИ, а 15% связаны с ИИ-инструментами разработки, включая ассистентов для написания и анализа кода.</p> <p>Отдельную проблему создают учетные данные ИИ-сервисов. Почти у 29,5% организаций, использующих ИИ, обнаруживается хотя бы один секрет или API-ключ, размещенный в небезопасном месте. Среди пользователей отдельных поставщиков показатель достигает 40%. Ключи сохраняются в конфигурационных файлах, переменных окружения рабочих станций, тестовых скриптах и репозиториях. В ряде случаев они остаются в истории Git даже после удаления из актуальной версии проекта. Получив такой ключ, атакующий может не только генерировать запросы за счет компании, но и вытягивать данные из подключенных RAG-хранилищ или интеграций с внутренними БД. Эксперты отмечают, что теневой ИИ усложняет расследование, так как служба ИБ может не знать о существовании самого сервиса, его владельце и перечне переданных в него данных.</p> <p>Наиболее высокая доля подобных инцидентов в 2026 году фиксируется в ИТ и разработке программного обеспечения — около 31% утечек с участием теневого ИИ приходится на этот сегмент. Высокий показатель связан с распространением ИИ-ассистентов разработки и самостоятельным подключением SDK и API. В финансовом секторе доля составляет порядка 22%, где основной риск связан с передачей фрагментов клиентской и аналитической информации во внешние сервисы. На промышленность приходится около 18% случаев: сотрудники используют ИИ для обработки технической документации, инструкций и проектных материалов. В ритейле и электронной коммерции показатель достигает 16% из-за активной работы с клиентскими обращениями и маркетинговыми данными. В профессиональных услугах, включая консалтинг и юридическое сопровождение, доля составляет около 13%. Здесь ключевым фактором становится загрузка во внешние ИИ-системы документов клиентов и материалов рабочих проектов.</p> <p>Во многих организациях сами правила не учитывают фактическую модель использования ИИ. Полный запрет публичных сервисов обычно приводит к переносу активности в менее контролируемые каналы: личные устройства, браузерные расширения или сторонние учетные записи. Другой распространенный сценарий — это формальное согласование одного корпоративного инструмента без учета того, что подразделения продолжают использовать десятки альтернативных решений. Дополнительный фактор — фрагментация: один пользователь одновременно работает с <nobr>4-7 ИИ-сервисами,</nobr> каждый со своей моделью доступа и логирования. Для ИБ-подразделения это означает необходимость контролировать несколько моделей аутентификации, схем передачи данных и наборов разрешений.</p> <p>Практически это начинается с инвентаризации: выгрузки доменов, анализа прокси-логов и поиска API-ключей в Git и рабочих станциях. Контроль следует строить вокруг данных и действий пользователей, а не только перечня разрешенных брендов. Организациям требуется классифицировать сведения, которые запрещено передавать во внешние ИИ-системы, настроить выявление несанкционированных ключей и секретов, проверять историю репозиториев и ограничивать установку расширений с избыточными разрешениями. Для корпоративных ИИ-сервисов необходимо применять централизованную аутентификацию, журналирование и разграничение доступа. Эксперты «Информзащиты» также рекомендуют включать теневое использование ИИ в сценарии мониторинга и реагирования на инциденты. Без учета этого канала компания может расследовать утечку как обычную передачу данных в облако и пропустить причину, которая уже затрагивает каждую пятую организацию, столкнувшуюся с компрометацией информации.</p> Аналитика инцидентов «Информзащиты» за 2025-2026 годы показала, что случаи утечек, где фигурирует несанкционированное … message https://www.itweek.ru/themes/detail.php?ID=235202 Fri, 17 Jul 2026 15:36:12 +0300 <p>Компания BSS анонсировала выход версии 3.8 инструментария NLU-Suite. Ключевым нововведением стал функционал оценок GAI, позволяющий использовать большие языковые модели (LLM) в роли аудитора для автоматизированного тестирования ответов RAG-систем (Retrieval-Augmented Generation). Это один из самых востребованных сегодня подходов к построению корпоративных ИИ-приложений.</p> <p>NLU-Suite представляет собой инструментарий для обучения моделей распознавания через визуальный интерфейс. Система позволяет с высокой точностью выявлять намерения клиента в диалоге и извлекать ключевые атрибуты (слоты) из речи: числа, локации, даты и прочие специфические сущности. С массовым внедрением генеративного ИИ перед бизнесом встала новая проблема: контроль фактологической точности и безопасности ответов. В новой версии решение выходит за рамки традиционного NLU, предоставляя комплексные средства для оценки качества работы генеративных моделей.</p> <p>Обновленный модуль «Метрики» и раздел «Оценка» поддерживают гибкую настройку контрольных точек. Дата-инженеры и аналитики могут использовать три типа метрик:</p> <ul> <li>рубрики — с фиксированными критериями, весовыми коэффициентами и настраиваемыми шкалами (от непрерывных значений до текстовых меток);</li> <li>категории — для классификации ответа по заданным параметрам качества;</li> <li>попарное сравнение — для A/B-тестирования ответов на базе одного набора данных, но сгенерированных разными LLM.</li> </ul> <p>В релиз уже включены предустановленные отраслевые метрики для RAG-систем. Среди них: Answer_Correctness (сравнение с эталоном), Answer_Correctness_noRef (оценка качества без опоры на эталон), Context_Relevancy (оценка того, насколько точно ИИ подобрал релевантные чанки из базы знаний) и Faithfulness (проверка на отсутствие «галлюцинаций» и противоречий предоставленным документам).</p> <p>«Главный вызов для бизнеса сегодня — это не просто внедрение генеративного ИИ, а обеспечение его предсказуемости и фактологической точности, особенно в клиентском сервисе. В версии 3.8 мы реализовали функционал, который позволяет автоматизировать один из самых трудоёмких этапов разработки RAG-систем — валидацию качества ответов. Использование LLM в роли аудитора даёт возможность оценивать ответы по множеству критериев одновременно, включая фактологическую точность и релевантность контекста, без необходимости ручного анализа каждого кейса. Это существенно ускоряет вывод голосовых помощников и чат-ботов в промышленную эксплуатацию», — прокомментировал Александр Крушинский, директор департамента голосовых цифровых технологий компании BSS.</p> Компания BSS анонсировала выход версии 3.8 инструментария NLU-Suite. Ключевым нововведением стал функционал оценок GAI … message https://www.itweek.ru/themes/detail.php?ID=235197 Fri, 17 Jul 2026 09:48:37 +0300 <p><em>Модели с открытыми весами, такие как GLM 5.2, отстают от передового ИИ на месяцы, а не на годы, и стоят намного меньше. Опрошенные порталом </em><em>The</em> <em>New</em> <em>Stack</em> <em>эксперты обсуждают такие аспекты, как привязка к поставщику, безопасность и реальные результаты для разработчиков.</em></p> <p>В сфере моделей ИИ назревает тихая революция.</p> <p>С одной стороны, доминирование проприетарных закрытых моделей укрепилось благодаря глобальному общественному интересу, который распространился на правительства и регулирующие органы от США до Европы и Китая.</p> <p>Однако, несмотря на это доминирование, Open Source-сообщество, которое редко уклоняется от борьбы, утверждает, что проприетарная модель — это всего лишь корпоративная оболочка вокруг модели, которая включает в себя память, средства наблюдаемости, интеллектуальную маршрутизацию и коннекторы. И называет закрытые модели дорогой оберточной бумагой, поскольку открытые модели примерно в 10 раз дешевле в расчете на токен.</p> <h3>Фактор запугивания со стороны крупных игроков</h3> <p>По словам Бориса Ренски, основателя и генерального директора стартапа Apelogic, занимающегося интеграцией ИИ-агентов, передовые лаборатории «усердно работают над тем, чтобы посеять страх» по поводу уникально «умных», опасных моделей и скорого появления общего ИИ (AGI).</p> <p>«Этот фактор страха призван отвлечь внимание от результатов тестов, показывающих, что открытые модели отстают всего на четыре месяца и при этом обходятся значительно дешевле, — говорит он. — Это означает, что в большинстве случаев компании платят OpenAI или Anthropic не за интеллект, а за „стандартные корпоративные функции“, связанные с моделью, такие как интеграция IDP, коннекторы MCP и наблюдаемость».</p> <p>#IMAGE_235198#</p> <p>Обеспокоенность Ренски во многом обусловлена ​​его двадцатилетним опытом создания компаний, занимающихся Open Source-инфраструктурой, когда он наблюдал, как «Open Source всегда догоняет и часто превосходит» вертикально интегрированные, проприетарные стеки по возможностям и распространенности. Это повторяющаяся закономерность, которая, по его словам, проявляется в сравнении Windows и Linux, Oracle и MySQL, Docker Enterprise и Kubernetes и т. д.</p> <h3>Неужели снова лицензионная привязка?</h3> <p>«Через несколько лет предприятия будут рассматривать свои многолетние контракты с передовыми лабораториями на большие языковые модели так же, как сегодня рассматривают свои лицензии Oracle, но будет уже слишком поздно. Это потому, что сама структура их бизнеса будет настолько глубоко переплетена с поставщиками проприетарных LLM, что миграция станет невозможной», — поясняет Ренски.</p> <p>Джонатан Брайс, исполнительный директор Cloud Native Computing Foundation (CNCF), согласен с этим мнением и заявляет, что платить в десять раз больше за четырехмесячное преимущество в развитии возможностей «не является корпоративной стратегией ИИ».</p> <p>«Это явно неразумный подход или стратегия, — говорит он. — В действительности это очень дорогостоящая форма привязки. Передовые технологии постоянно развиваются, поэтому разработчикам следует использовать открытую инфраструктуру, которая позволяет им менять модели и оборудование, не перестраивая приложение каждый раз, когда меняется рейтинг лидеров».</p> <p>Прямолинейное мнение Ренски и согласие Брайса по этому вопросу совпадают со смелыми заявлениями компании Featherless, занимающейся разработкой бессерверных платформ для инференса. Организация утверждает, что может «резко сократить затраты на передовые разработки в области ИИ» за счет нативной оптимизации китайской ИИ-модели Z.ai GLM 5.2 с открытыми весами.</p> <h3>Во что обходятся 100 миллиардов токенов в месяц?</h3> <p>Featherless утверждает, что ее нативная оптимизация модели GLM 5.2 на частной облачной инфраструктуре AMD существенно снижает затраты на ИИ-инференс передового уровня — примерно на 94%. По данным компании, для команды разработчиков, работающей при максимальной загрузке и использующей около 100 млрд. токенов в месяц, годовая стоимость GPT-5.5 составляет 1 557 600 долл.; при использовании Claude Opus 4.8 идентичная ежемесячная нагрузка обходится в 1 506 000 долл. в год.</p> <p>Если 100 млрд. токенов кажутся огромной цифрой, то, согласно отчетам этого года, ссылающимся на исследование Deloitte, одна медицинская компания потратила 1 трлн. токенов за шесть месяцев.</p> <p>В отличие от проприетарных моделей с подобными оценками затрат, вариант с частным облаком Featherless учитывает переменные факторы и предполагает фиксированную годовую плату в размере 90 000 долл., что позволяет экономить более 1,46 млн. долларов в год при полной загрузке команды разработчиков.</p> <h3>Особенности реализации</h3> <p>Неужели мы действительно дойдем до того, что крупные организации ощутят жизнеспособность моделей с открытым исходным кодом и открытым весом, и в конечном счете разработчик (и пользователь) даже не будет задумываться о том, на каком оборудовании выполняется их инференс?</p> <p>По словам Исаака Джемала, руководителя отдела Featherless по связям с разработчиками, модели с открытыми весами часто считались неполноценными или неспособными к реальной работе, но теперь «GLM 5.2 перевернула это представление с ног на голову».</p> <p>Насколько легко было запустить GLM 5.2 нативно на оборудовании AMD вместо Nvidia, и на какие подводные камни следует обратить внимание разработчикам? «Это было непросто; спрос на GLM 5.2 оказался даже выше, чем мы прогнозировали, что стало для нас неожиданностью, поэтому эффективное распределение ресурсов GPU на начальном этапе представляло собой сложную задачу, — рассказывает Джемал. — Наша команда инженеров непосредственно работает с Tensorwave, чтобы обеспечить успешное развертывание этой большой модели».</p> <p>Существуют операционные ограничения и подводные камни, на которые следует обратить внимание. Джемал советует разработчикам следить за условиями, скрытыми в политиках обеспечения конфиденциальности.</p> <p>«Крупные лаборатории часто говорят что-то вроде: „Мы не будем регистрировать ваши запросы, кроме случаев, когда это необходимо“, и всё, что их собственные системы сочтут „небезопасным“, всё равно сохраняется, иногда годами, полностью по их собственному усмотрению. Их критерии часто расплывчаты и очень широки. Мы считаем такой подход неправильным, поскольку очень серьёзно относимся к вопросам конфиденциальности», — говорит Джемал.</p> <h3>Что думают разработчики из реального мира?</h3> <p>Очевидно, что решающим фактором здесь является мнение об открытых альтернативах разработчиков и специалистов в области науки о данных.</p> <p>Кацпер Михалик, инженер-программист польской компании Screen Studio, на практике сравнил модель с открытыми весами (фактически, GLM 5.2) с закрытыми моделями, такими как Opus 4.8, занимаясь исследованием технологического стека для инжиниринга данных, алгоритмических задач и генерации компонентов.</p> <p>«В исследовательских задачах GLM 5.2 показала результаты, аналогичные или даже лучшие, чем Opus 4.8, — говорит он. — Она имеет широкий охват, активно расширяется на смежные темы и даже создает полезные визуальные графики. Я сравнил GPT, Claude и GLM на задаче, предлагаемой на собеседовании по программированию. GPT хорошо объяснила этапы мышления, но не предоставила код; ответ Claude была кратким и понятным, но без особых подробностей; GLM же заняла промежуточную позицию, то есть изложила чёткие моменты, дала подробное пошаговое объяснение и предложила работающее решение на Python».</p> <p>По мнению Михалика, при наличии четкого запроса результаты GLM превосходны. Модель также разработала компонент формы React с использованием Zod и TypeScript, который работает корректно, имеет правильную типизацию, корректно обрабатывает поля и отображает четкие ошибки валидации. По умолчанию для стилизации используется Tailwind, что сейчас является стандартной практикой.</p> <p>«Конечно, GLM не безупречна, — уточняет Михалик. — Когда я попросил ее создать 3D-сцену с помощью React и TypeGPU в одном файле, она не смогла корректно отобразить результат — я ожидал чего-то ближе к версии v0 или Lovable для полной генерации проекта. Кроме того, ближе к вечеру я столкнулся с предупреждениями об ограничении использования».</p> <h3>Безопасность и другие аспекты</h3> <p>Учитывая, что многие из ИИ-моделей с открытым исходным кодом разрабатываются в Китае, нельзя обойти вниманием вопрос безопасности.</p> <p>Фил Уиттакер, инженер-разработчик опенсорсной CMS-системы Umbraco согласен с тем, что модели ИИ с открытыми весами (не с открытым исходным кодом) отстают от передовых моделей на четыре-пять месяцев, но это не вся история.</p> <p>«Я не вполне согласен с тем, что эти модели в 10 раз дешевле, поскольку все зависит от масштаба и цели, — говорит он. — И да, большинство моделей с открытыми весами — китайские. Прямое подключение к конечным точкам ИИ поставщика имеет последствия для безопасности и конфиденциальности. Использование стороннего поставщика, такого как Ollama, лучше, но затраты основаны на токенах, а различия в токенизаторах между моделями могут означать снижение стоимости всего на 50%».</p> <p>Наконец, как уточняет Уиттакер, самостоятельный хостинг — это вариант, но он требует первоначальных капитальных затрат (серверы) и постоянного обслуживания. Он отмечает, что бенчмарки и опыт показывают, что GLM 5.2 «приближается к уровню интеллекта» Opus 4.8 от Anthropic. Однако следует учитывать, что, поскольку эта модель не такая быстрая, она лучше подходит для длительных и независимых задач, чем для инструментов агентного кодирования, где скорость инференса имеет значение.</p> <p>«Результаты также зависят от качества среды, которая управляет моделью, — добавляет Уиттакер. — По мере того, как модели становятся все более стандартизированными, а потребности обычных пользователей могут удовлетворяться моделями более низкого уровня, среда и ее конфигурация будут приобретать все большее значение».</p> Модели с открытыми весами, такие как GLM 5.2, отстают от передового ИИ на месяцы … article https://www.itweek.ru/themes/detail.php?ID=235195 Fri, 17 Jul 2026 09:31:39 +0300 <p>Интерес к использованию ИИ в разработке продолжает расти. Компании внедряют кодовых ассистентов, автоматизируют тестирование, используют генеративные модели для работы с документацией и внутренними знаниями. На уровне отдельных задач эффект часто становится заметен практически сразу: сотрудники тратят меньше времени на рутинные операции, быстрее находят информацию и получают готовые заготовки решений.</p> <p>Однако между локальным ускорением отдельных действий и ускорением бизнеса существует большая разница.</p> <p>На практике многие организации сталкиваются с похожей ситуацией. Инструменты используются все активнее, но сроки вывода продуктов на рынок почти не меняются. Разработчики генерируют больше кода, однако производительность команд растет значительно медленнее ожидаемого. Согласно <a href="https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value?utm">исследованию</a> McKinsey «The State of AI: How Organizations Are Rewiring to Capture Value», именно переработка рабочих процессов оказывает наибольшее влияние на способность компаний получать измеримый бизнес-эффект от генеративного ИИ</p> <p>Это закономерно. ИИ способен ускорять отдельные операции, но бизнес получает эффект только тогда, когда ускорение начинает распространяться на весь цикл создания продукта.</p> <p>Рассмотрим, почему многие компании не получают ожидаемой отдачи от внедрения ИИ и какие изменения необходимы, чтобы технология действительно начала работать на результат.</p> <h3>Главная ошибка — считать, что проблема находится в написании кода</h3> <p>Когда компании обсуждают внедрение ИИ в разработку, основной фокус обычно направлен на скорость создания кода. Именно здесь генеративные инструменты демонстрируют наиболее заметные результаты, поэтому возникает естественное ожидание: если код будет писаться быстрее, бизнес автоматически начнет получать продукты быстрее.</p> <p>Но в реальных проектах написание кода далеко не всегда является главным ограничением.</p> <p>Задержки чаще возникают в других точках процесса:</p> <ul> <li> согласовании требований;</li> <li> поиске информации;</li> <li> архитектурных решениях;</li> <li> тестировании;</li> <li> ревью изменений;</li> <li> устранении дефектов;</li> <li> межкомандных коммуникациях.</li> </ul> <p>Поэтому увеличение скорости генерации кода само по себе не гарантирует ускорения поставки продукта.</p> <p>Более того, иногда происходит обратный эффект. Чем быстрее создаются изменения, тем больше нагрузки появляется на этапах проверки и контроля качества. В результате локальная производительность растет, а пропускная способность системы в целом остается прежней.</p> <p>Это один из ключевых парадоксов внедрения ИИ. Автоматизация устраняет ограничения на одном участке процесса, но одновременно делает более заметными ограничения на других участках.</p> <p>Поэтому перед внедрением полезно ответить не на вопрос «какой инструмент выбрать», а на вопрос «что именно сегодня ограничивает скорость разработки».</p> <h3>Самые успешные сценарии внедрения редко выглядят самыми амбициозными</h3> <p>Многие организации начинают знакомство с ИИ через наиболее заметные сценарии: автоматическую генерацию кода или создание полноценных программных компонентов.</p> <p>На презентациях такие примеры выглядят впечатляюще. Однако в реальной эксплуатации именно они часто оказываются наиболее сложными для масштабирования.</p> <p>Причина проста: чем ближе система находится к бизнес-критичным изменениям, тем выше стоимость ошибки.</p> <p>Каждый автоматически созданный фрагмент кода требует проверки. Каждое архитектурное решение нуждается в дополнительной валидации. Каждая ошибка может привести к затратам, которые значительно превышают выигрыш от ускорения разработки.</p> <p>Поэтому наиболее успешные внедрения часто начинаются с менее заметных, но более управляемых процессов:</p> <ul> <li> подготовки документации;</li> <li> поиска информации во внутренних базах знаний;</li> <li> анализа требований;</li> <li> генерации тестовых сценариев;</li> <li> поддержки процессов ревью.</li> </ul> <p>Общий признак таких задач заключается в том, что результат легко проверить, а риски остаются контролируемыми.</p> <p>Практика внедрений показывает, что наиболее быстрый и предсказуемый эффект обычно возникает не в сценариях полной автоматизации разработки, а в задачах, связанных с повторяющимися инженерными операциями. Именно такие процессы проще контролировать, измерять и масштабировать внутри организации.</p> <p>Именно поэтому первые этапы внедрения ИИ должны быть ориентированы не на максимальный уровень автоматизации, а на быстрое получение контролируемого результата.</p> <h3>ИИ усиливает качество процессов, а не заменяет их</h3> <p>Существует распространенное представление, что внедрение ИИ способно компенсировать недостатки существующей организации разработки.</p> <p>На практике происходит противоположное.</p> <p>Если процессы описаны недостаточно подробно, ответственность распределена неявно, а инженерные знания существуют преимущественно в головах сотрудников, генеративные инструменты начинают воспроизводить эту же неопределенность.</p> <p>Особенно заметно это становится в крупных проектах.</p> <p>Для эффективной работы модели необходим контекст:</p> <ul> <li> архитектурная документация;</li> <li> история изменений;</li> <li> бизнес-правила;</li> <li> инженерные стандарты;</li> <li> требования информационной безопасности;</li> <li> внутренние регламенты разработки.</li> </ul> <p>Если эти знания противоречат друг другу или быстро устаревают, качество рекомендаций начинает снижаться независимо от возможностей самой модели.</p> <p>В результате ИИ становится своеобразным индикатором зрелости инженерной системы.</p> <p>Компании с прозрачными процессами обычно быстрее получают практический эффект. Организации, где накопилось большое количество организационных и технических проблем, напротив, сталкиваются с тем, что технология лишь делает эти проблемы более заметными.</p> <p>Поэтому внедрение ИИ редко ограничивается подключением нового инструмента. Чаще оно приводит к необходимости пересматривать подходы к управлению знаниями, документации, качеству данных и внутренним инженерным стандартам.</p> <h3>Метрики использования почти ничего не говорят о бизнес-эффекте</h3> <p>Еще одна причина разочарования связана с неправильной оценкой результата.</p> <p>Многие компании отслеживают:</p> <ul> <li> количество пользователей;</li> <li> число запросов к модели;</li> <li> объем автоматически созданного кода;</li> <li> частоту использования инструмента.</li> </ul> <p>Эти показатели помогают понять уровень распространения технологии внутри организации.</p> <p>Но они не позволяют ответить на главный вопрос: стала ли разработка эффективнее.</p> <p>Для бизнеса значительно важнее другие показатели:</p> <ul> <li> сократилось ли время прохождения задачи через полный цикл разработки;</li> <li> уменьшилось ли количество дефектов после релиза;</li> <li> ускорился ли выпуск изменений;</li> <li> снизилась ли стоимость сопровождения;</li> <li> уменьшилась ли нагрузка на ключевых специалистов.</li> </ul> <p>Показательно, что наиболее зрелые организации постепенно переходят от оценки активности к оценке результата. Причина проста: сам факт использования ИИ не создает ценности. Ценность возникает только тогда, когда меняется экономика процесса.</p> <p>Если команда стала отправлять модели больше запросов, но релизный цикл остался прежним, бизнес практически не почувствует разницы.</p> <h3>Основная сложность начинается после успешного пилота</h3> <p>На этапе пилотного проекта ИИ обычно демонстрирует хорошие результаты.</p> <p>Команда работает с ограниченным набором сценариев, использует подготовленные данные и концентрируется на достижении конкретной цели. В таких условиях технология часто показывает высокую эффективность. Но именно после завершения пилота начинается самый сложный этап.</p> <p>Необходимо встроить решение в существующую инженерную среду, обеспечить соблюдение требований безопасности, организовать поддержку пользователей, определить зоны ответственности и адаптировать процессы контроля качества. Именно здесь многие проекты начинают терять темп.</p> <p>Проблема заключается в том, что пилот проверяет работоспособность технологии, а промышленная эксплуатация проверяет готовность организации к изменениям.</p> <p>Поэтому переход от эксперимента к масштабированию остается одним из самых сложных этапов внедрения ИИ. Основные трудности обычно связаны не с моделями, а с необходимостью менять привычные процессы и подходы к управлению разработкой.</p> <h3>Что в итоге</h3> <p>Сегодня вопрос уже не в том, способен ли ИИ ускорять работу разработчиков. Практика показывает, что способен.</p> <p>Гораздо важнее другое: способен ли бизнес превратить локальное ускорение отдельных задач в ускорение всей системы создания продукта. Здесь проходит граница между экспериментом и реальным результатом.</p> <p>Компании получают наибольшую отдачу от ИИ не потому, что выбирают самые современные инструменты. Устойчивый эффект появляется тогда, когда технология становится частью инженерной системы, а процессы, метрики и правила работы адаптируются под новые возможности.</p> <p>Поэтому успешное внедрение ИИ начинается не с выбора модели.</p> <p>Оно начинается с понимания того, какие ограничения действительно мешают бизнесу двигаться быстрее и каким образом организация готова их устранять.</p> <p> #IMAGE_235196#</p> Интерес к использованию ИИ в разработке продолжает расти. Компании внедряют кодовых ассистентов, автоматизируют … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235193 Thu, 16 Jul 2026 16:56:18 +0300 <p>Провайдер облачной сетевой инфраструктуры и решений в области кибербезопасности и доставки контента CURATOR, специализирующийся на обеспечении доступности интернет-ресурсов, нейтрализации DDoS-атак и защите веб-приложений, подытожил данные своей инфраструктуры защиты за первое полугодие 2026 года и зафиксировал постепенное вхождение DDoS-атак терабитного класса в обычную практику злоумышленников.</p> <p>По данным CURATOR, в течение второго квартала 2026 года структура кибератак претерпела заметные изменения: финтех сохранил лидерство среди целей, однако его доля сократилась, тогда как сегмент медиа резко усилил своё присутствие в статистике. Во втором квартале 2026 года финтех-сегмент по-прежнему остаётся главной целью злоумышленников, однако его доля сократилась с 44,2% до 31,9%. При этом медиасегмент — «Медиа, ТВ, радио и блогеры» — стремительно вырос и занял первое место в микросегментации с 12,7% всех инцидентов. Тройку лидеров по макросегментам замыкают «ИТ и Телеком» (16,8%) и «Медиа» (14,0%), вместе с финтехом формирующие около двух третей всех зафиксированных атак. В топ-5 микросегментов по числу атак вошли также «Платёжные системы» (10,0%), «Банки» (9,5%), «Онлайн-букмекеры» (9,0%) и «Торговые площадки» (7,9%).</p> <p>На этом фоне атаки мощностью свыше 1 Тбит/с превратились в рутину: за один квартал их зафиксировано вдвое больше, чем за весь прошлый год. За апрель—июнь 2026 года CURATOR нейтрализовал 12 подобных инцидентов — вдвое больше, чем за весь 2025 год. Наиболее мощные атаки пришлись на сегмент онлайн-ставок: пиковый битрейт двух крупнейших достиг 1,64 и 1,58 Тбит/с при скорости передачи пакетов 553 и 638 Мпак/с (миллионов пакетов в секунду) соответственно. Наиболее продолжительная атака квартала — в сегменте онлайн-ритейла — длилась почти 80 часов.</p> <p>Растёт техническая сложность атак: так, доля мультивекторных DDoS-инцидентов увеличилась с 8,0% в 2025 году до 11,7% во втором квартале 2026 года. Изменилась и структура векторов: доля UDP flood выросла с 22,9% до 29,3%, TCP flood удвоилась — с 4,2% до 8,9%, SYN flood — с 2,8% до 5,6%. Одновременно зафиксирован нетипичный всплеск ICMP flood: его доля достигла 4,3% против 0,1% годом ранее.</p> <p>Во втором квартале впервые за два года зафиксировано резкое снижение размера крупнейшего наблюдаемого ботнета — с 13,5 млн устройств в первом квартале до 2,09 млн. По оценке специалистов CURATOR, это связано с международной операцией правоохранительных органов США, Канады и Германии, в ходе которой была выведена из строя инфраструктура ботнетов Aisuru и Kimwolf. Вместе с тем компания не ожидает долгосрочного изменения ситуации: фундаментальные предпосылки для формирования масштабных ботнетов — рост числа уязвимых устройств и доступность инструментов автоматизации на базе ИИ — никуда не исчезли.</p> <p>Операция правоохранителей отразилась и на географии источников атак. На первое место среди источников L7 DDoS вышли США (15,9%), следом — Вьетнам (9,5%) и Россия (7,2%). Бразилия, лидировавшая несколько кварталов подряд, резко снизила долю (6,2%) и опустилась на четвёртое место. В целом распределение источников атак по-прежнему становится более равномерным: совокупная доля стран за пределами топ-20 продолжает расти. Это ещё раз подтверждает снижение практической ценности простых географических блокировок как инструмента защиты.</p> <p>«Наши данные показывают: ландшафт угроз меняется быстрее, чем было принято считать. Атаки класса 1 Тбит/с больше не являются экстраординарными событиями — они за последний год стали частью нашей реальности. При этом смена приоритетов у злоумышленников происходит стремительно: медиасегмент, ещё недавно находившийся на периферии статистики, за один квартал вышел в лидеры по числу инцидентов. Для бизнеса это означает одно: защита не может строиться на отраслевых допущениях — угроза актуальна для любого публичного ресурса», — отметил Дмитрий Ткачёв, генеральный директор CURATOR.</p> Провайдер облачной сетевой инфраструктуры и решений в области кибербезопасности и доставки контента CURATOR … message https://www.itweek.ru/themes/detail.php?ID=235192 Thu, 16 Jul 2026 16:54:13 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) объявляет о старте продаж сервера H225 G4 — первого устройства в портфеле компании на базе процессоров AMD EPYC 9004 (Genoa) и 9005 (Turin). Это стратегическое расширение линейки серверных платформ YADRO предлагает заказчикам альтернативную x86-архитектуру с максимальной вычислительной плотностью и энергоэффективностью.</p> <p>H225 G4 — универсальный сервер для сценариев масштабирования scale-out и scale-up нагрузок. Высокая плотность вычислений и большой объем быстрой памяти делают его оптимальным выбором для высокоплотных сред виртуализации, озер данных, HPC-кластеров и OLAP-систем. На практике это позволяет бизнесу оптимизировать ИТ-инфраструктуру и снизить совокупную стоимость владения (TCO) при консолидации нагрузок за счет сокращения затрат на стойко-место и энергопотребления ЦОД.</p> <p>Компактная двухпроцессорная платформа в форм-факторе 2U на базе процессоров AMD EPYC 9004 и 9005 объединяет до 384 физических вычислительных ядер с частотой до 5 ГГц, позволяя разместить больше вычислительных ресурсов в ограниченном пространстве стойки и кратно повысить плотность виртуальных сред. <nobr>12-канальная</nobr> архитектура с поддержкой до 24 модулей DDR5-6400 и общим объемом до 6 ТБ обеспечивает необходимую пропускную способность для ресурсоемких задач обработки данных и облачных сервисов.</p> <p>При этом платформа сохраняет гибкость конфигурации за счет поддержки от 4 до 11 высокоскоростных слотов PCIe 5.0 и возможности подключения от 8 до 30 дисковых накопителей. Это позволяет подобрать конфигурацию точно под сценарий заказчика, избегая переплат за неиспользуемые компоненты.</p> <p>«Корпоративная ИТ-инфраструктура развивается в условиях роста вычислительных нагрузок и требований к эффективности ЦОД. YADRO H225 G4 расширяет возможности наших клиентов по выбору серверной архитектуры для задач виртуализации, обработки данных и облачных сервисов. Мы видим устойчивый спрос на решения с высокой плотностью ядер и делаем ставку на платформы, которые позволяют консолидировать ресурсы, масштабировать вычислительные мощности и точнее управлять затратами на размещение и эксплуатацию оборудования», — отметил Александр Бакулин, коммерческий директор YADRO. </p> <p>Сервер YADRO H225 G4 уже включен в Единый реестр российской радиоэлектронной продукции Минпромторга, что позволяет использовать его в проектах субъектов КИИ, государственных заказчиков и организаций регулируемых отраслей.</p> Технологическая компания YADRO (входит в ИКС Холдинг) объявляет о старте продаж сервера H225 G4 — первого … message https://www.itweek.ru/themes/detail.php?ID=235191 Thu, 16 Jul 2026 16:52:38 +0300 <p>Компания «СёрчИнформ» представила результаты опроса по теме «Практика защиты коммерческой тайны». В опросе приняли участие 70 российских компаний. Вопросы касались особенностей защиты информации, относящейся к коммерческой тайне, а также инцидентов, которые допускают сотрудники при работе с такими данными.</p> <p>По данным «СёрчИнформ», больше половины опрошенных (53%) компаний сталкивались с попытками неправомерного доступа или разглашением КТ со стороны сотрудников компании, 21% фиксировали инциденты с коммерческой тайной по вине контрагентов и подрядчиков.</p> <p>При этом, лишь 5% компаний доводили инциденты с коммерческой тайной до суда. Большинство компаний назначали нарушителям выговор (40%) или увольняли их (30%). Однако почти четверть компаний (23%) не предпринимали никаких мер, если фиксировали инциденты с коммерческой тайной.</p> <p>У 42% компаний возникали трудовые или гражданские споры с сотрудниками или контрагентами о неправомерном доступе, разглашении, использовании коммерческой тайны.</p> <p>«Результаты опроса показали, что большинство опрошенных решают вопросы нарушения режима коммерческой тайны внутри организаций. В первую очередь это связано с практикой трудовых споров: суды не всегда встают на сторону компаний. С другой стороны, объем прямых убытков от утечки коммерческой тайны сложно оценить. Однако, есть позиции судов в случаях, когда вина сотрудника в инциденте и наличие режима КТ были доказаны. Компаниям удавалось привлечь нарушителей к ответственности и возместить ущерб.</p> <p>Компаниям с техническими средствами защиты намного проще доказать, что был нарушен режим коммерческой тайны. Показатели систем помогают обосновать факт разглашения конфиденциальной информации и определить причастных», — отметил Дмитрий Вощуков, специалист по связям с государственными органами «СёрчИнформ».</p> <p>По данным опроса, в большинстве (65%) компаний утверждены положение о коммерческой тайне и перечень сведений, составляющих КТ. В 18% компаний утвержден только один из документов.</p> <p>В большинстве компаний ИБ-специалисты так или иначе участвуют в защите коммерческой тайны. В 35% опрошенных компаний ИБ-отдел отвечает за защиту коммерческой тайны, в 44% компаний ИБ-отдел оказывает содействие подразделению, ответственному за защиту коммерческой тайны.</p> <p>Лишь 35% компаний маркируют бумажные и электронные документы, а также носители информации, 18% маркируют только электронные документы и носители информации. 18% опрошенных признались, что не занимаются маркировкой информации, составляющей коммерческую тайну.</p> <p>«В условиях, когда основная часть переписки и документооборота перешла в электронный формат, основным риском в части защиты коммерческой тайны становится передача именно цифровых данных. Почти половина компаний не применяет маркировку коммерческой тайны к файлам и носителям цифровой информации и, при утечках, эти организации не смогут уверенно рассчитывать на защиту своих прав в судах», — отметил Дмитрий Вощуков, специалист по связям с государственными органами «СёрчИнформ».</p> <p>Наиболее распространенными способами разграничения доступа к коммерческой тайне среди опрошенных компаний являются: ограничение физического доступа к документам и материальным носителям с КТ (56%), использование встроенных средств операционной системы для управления доступом (47%) и издание локальных документов, регламентирующих права доступа (44%). Лишь 23% компаний используют специализированные средства (системы аудита и защиты файловых хранилищ, иные СЗИ от НСД) для управления доступом к сведениям, составляющим коммерческую тайну. </p> <p>Также аналитики «СёрчИнформ» выяснили, как российские компании защищают коммерческую тайну от утечки. 47% опрошенных используют средства защиты от утечек информации (DLP), 30% используют криптографические средства и 32% используют другие средства защиты информации. 16% ответили, что не используют технические средства для защиты коммерческой тайны.</p> Компания «СёрчИнформ» представила результаты опроса по теме «Практика защиты коммерческой тайны». В опросе приняли … message https://www.itweek.ru/themes/detail.php?ID=235190 Thu, 16 Jul 2026 16:49:55 +0300 <p>Эксперты компании «Информзащита» выявили, что около 58% организаций не могут уверенно установить, какие уязвимости с наибольшей вероятностью будут использованы в реальных атаках — на практике это означает, что список из тысяч CVE не превращается в список из <nobr>5-10</nobr> реально опасных точек входа. Лишь 34% компаний автоматически проверяют, можно ли применить известные эксплойты к их конкретным активам — например, сопоставляют результаты сканирования с доступностью сервиса из интернета и наличием защитных контролей.</p> <p>В среднем организации используют 14 источников данных о киберугрозах, включая сведения об уязвимостях, активности злоумышленников и новых техниках атак. Без привязки к инфраструктуре эти источники превращаются в шум: аналитик видит десятки новых CVE в день, но не понимает, относятся ли они к его внешнему периметру или к изолированному тестовому стенду. По оценке экспертов, в 2026 году ИБ-команды тратят в среднем 42% рабочего времени на анализ рисков, которые впоследствии оказываются низкоприоритетными или неэксплуатируемыми в конкретной среде.</p> <p>Вход в инфраструктуру всё чаще происходит не через один доминирующий вектор, а через комбинацию уязвимостей, учетных данных и социальной инженерии, что ломает привычные модели приоритизации. На эксплуатацию уязвимостей приходится около 31% успешных сценариев получения доступа, на фишинг — 16%, на использование скомпрометированных учетных данных — 13%, еще около 6% связаны с претекстингом и другими методами социальной инженерии. В инфраструктуре крупной организации одновременно могут присутствовать тысячи известных уязвимостей, десятки и даже сотни из которых имеют высокий уровень критичности. При этом злоумышленнику достаточно одной проблемы в VPN-шлюзе, веб-приложении, системе удаленного доступа или другом доступном извне компоненте. Наличие рабочего эксплойта и понятной цепочки дальнейшего перемещения по инфраструктуре часто делает такую уязвимость значительно опаснее технически более критичной проблемы во внутреннем сегменте.</p> <p>Эксперты связывают рост проблемы с тем, что во многих организациях приоритизация по-прежнему строится преимущественно вокруг формальной оценки критичности. Высокий балл уязвимости автоматически поднимает ее в очереди на устранение, хотя реальная вероятность эксплуатации зависит от расположения актива, его доступности из интернета, конфигурации продукта, наличия публичного эксплойта, интереса атакующих и действующих компенсирующих мер.</p> <p>Чем больше парк систем и интеграций, тем выше шанс, что критичная уязвимость потеряется среди нерелевантных находок — особенно в компаниях с десятками внешних сервисов и устаревшими сегментами. В розничной торговле эксплуатация уязвимостей может быть связана примерно с 42% случаев первоначального проникновения, в государственном секторе — с 40%, в промышленности — с 38%, в здравоохранении — с 20%. В ритейле риск повышают многочисленные веб-сервисы, распределенная инфраструктура и большое количество внешних интеграций. Государственные организации часто эксплуатируют разнородные информационные системы с разными жизненными циклами. Для промышленных предприятий установка обновления может требовать отдельного технологического окна и предварительной проверки совместимости. В здравоохранении дополнительные ограничения связаны с необходимостью поддерживать непрерывную работу специализированных систем. В каждой из этих отраслей формальная очередность устранения уязвимостей может расходиться с тем, какие активы в конкретный момент представляют интерес для злоумышленников.</p> <p>Приоритизацию стоит начинать с вопроса о том, можно ли через эту уязвимость прямо сейчас зайти в сеть и что атакующий сможет сделать дальше. Инвентаризация активов должна учитывать сетевую доступность, бизнес-критичность и место системы в потенциальной цепочке перемещения злоумышленника. Сведения об активно используемых уязвимостях необходимо автоматически сопоставлять с результатами сканирования и данными об инфраструктуре, а наиболее опасные находки проверять на реальную эксплуатируемость в контролируемой среде. Отдельные сроки устранения целесообразно устанавливать для уязвимостей в доступных из интернета компонентах и проблем, по которым уже зафиксирована активность атакующих. Интеграция систем управления уязвимостями с данными об угрозах, CMDB, SIEM и средствами контроля конечных точек позволит сократить объем ручного анализа и быстрее выделять действительно опасные сценарии. Ключевым показателем зрелости процесса при этом становится не количество закрытых уязвимостей, а скорость устранения тех проблем, которые злоумышленники способны использовать для проникновения и развития атаки.</p> Эксперты компании «Информзащита» выявили, что около 58% организаций не могут уверенно установить, какие уязвимости … message https://www.itweek.ru/themes/detail.php?ID=235189 Thu, 16 Jul 2026 16:46:45 +0300 <p>Сделать так, чтобы обращение клиента тут же заканчивалось решением — в новом выпуске программы «Интеллектуальный сервис» коммерческий директор «Инвитро» Валерий Вагнер рассказал о стратегической цели развития клиентского сервиса и технологиях, которые помогают ее достичь.</p> <p>Как внедрить ИИ в клиентское обслуживание в медицине, где аудитория достаточно консервативна? Как обеспечить персонализацию и для B2C, и для B2B сегментов? Как управлять огромным массивом данных во благо бизнеса и клиентов? И почему даже бухгалтерия — уже часть CX?</p> <p>В новом сезоне программы «Интеллектуальный сервис» на ПРОБИЗНЕС ТВ заместитель генерального директора BSS Василий Жилов продолжает исследовать, как крупнейшие российские компании выстраивают клиентский сервис и какую роль в этом играют ИИ и речевые технологии. Гость нового выпуска — коммерческий директор «Инвитро» Валерий Вагнер. </p> <p>По словам эксперта, стратегическая цель компании — сделать так, чтобы обращение клиента тут же заканчивалось решением, насколько это возможно. Именно такой подход позволяет повышать лояльность и LTV. </p> <p>ИИ и другие технологии помогают приблизиться к этому результату: они автоматизируют бэк-офисные функции, сохраняют контекст взаимодействия клиента с компанией независимо от канала обращения и позволяют лучше понимать его потребности, даже когда клиент их не до конца может сформулировать. </p> <p>Например, «Инвитро» активно применяет речевую аналитику для оценки качества взаимодействия с клиентами и планирует дальнейшую интеллектуализацию процесса с помощью ИИ-агентов. Это особенно важно для компании, работающей с самым большим объемом данных в своей отрасли: ИИ помогает выявлять паттерны, которые иным образом невозможно обнаружить в таком крупном и сложно устроенном массиве. </p> <p>Какие еще технологии развивает «Инвитро», какие результаты они дают и как компания дополнила стандартные метрики собственной системой оценки эффективности — смотрите в полном выпуске на Rutube и VK Видео. </p> Сделать так, чтобы обращение клиента тут же заканчивалось решением — в новом выпуске программы «Интеллектуальный … message https://www.itweek.ru/themes/detail.php?ID=235188 Thu, 16 Jul 2026 16:43:02 +0300 <p>Компании «Актив», SafeTech Lab и «Индид» представили на российском рынке комплексную Платформу управления доступом, или сокращенно ПУД. Решение предназначено для построения единой инфраструктуры корпоративного доступа в организациях с высокими требованиями к информационной безопасности.</p> <p>Платформа разработана с учетом роста целевых кибератак, усложнения гибридных ИТ-ландшафтов и усиления регуляторных требований, в частности, Приказа ФСТЭК № 117. Решение позволяет перейти от парольной модели к строгой аутентификации, в основе которой лежат аппаратные средства — USB-токены и смарт-карты.</p> <p>В состав платформы входят аппаратные аутентификаторы, корпоративный центр сертификации, средства управления жизненным циклом ключевых носителей и система централизованного управления доступом. Интеграция компонентов обеспечивает единый подход к аутентификации на всех уровнях — от рабочих станций до корпоративных сервисов.</p> <p>Ядром платформы выступает корпоративный центр сертификации SafeTech CA, который служит источником криптографического доверия и обеспечивает надежную проверку подлинности пользователей и всех компонентов инфраструктуры. </p> <p>ПУД обеспечивает доступ к ключевым системам организации (VPN, VDI, ERP, CRM, инфраструктурным сервисам), совместимо с отечественными и зарубежными операционными системами и может использоваться в гибридных средах без изменений в существующей инфраструктуре.</p> <p>Платформа повышает уровень защищенности и обеспечивает снижение рисков компрометации учетных данных за счет отказа от паролей и внедрения строгой аутентификации.</p> <p>Решение позволяет централизовать управление доступом ко всем информационным системам и обеспечить прозрачный контроль действий пользователей.</p> <p>Использование единой платформы упрощает соответствие требованиям отечественных регуляторов (Приказ ФСТЭК России № 117) и международных стандартов в области информационной безопасности: NIST SP 800 207 (ZTA), NIST CSF, CIS Controls.</p> <p>Автоматизация процессов управления аутентификаторами и сертификатами снижает нагрузку на ИТ-подразделения и уменьшает количество инцидентов, связанных с учетными данными, улучшая пользовательский опыт и нивелируя парольную нагрузку.</p> <p>Ключевые технические преимущества:</p> <ul> <li>поддержка аппаратных токенов и смарт-карт с X.509-сертификатами, SSH-ключами и стандартом FIDO2. Единая система управления доступом с поддержкой Single Sign-On и централизованных политик аутентификации;</li> <li>полноценный Autoenrollment (автоматический выпуск и обновление) технологических сертификатов в Windows, Linux и гетерогенных средах. Полная совместимость с отечественными операционными системами и доменными службами при поддержке Windows-инфраструктур;</li> <li>автоматизация жизненного цикла ключевых носителей: выпуск, перевыпуск, отзыв и блокировка. Поддержка широкого спектра сценариев — от пользовательского доступа до администрирования инфраструктуры, включая SSH, sudo и контейнерные среды.</li> </ul> <p>Андрей Тархов, директор по специальным проектам компании «Актив», отметил: «Вывод на рынок комплексной платформы управления доступом позволяет организациям выстроить единый и управляемый контур аутентификации в условиях роста угроз, усложнения инфраструктуры и повышения регуляторных требований. Проект является наглядным примером реальной и эффективной коллаборации лидеров отечественного рынка ИБ в ответ на насущную потребность российских организаций».</p> <p>Александр Санин, генеральный директор SafeTech Lab, прокомментировал: «ПУД объединяет современные технологии аутентификации и управления доступом в рамках единой платформы и помогает организациям перейти к более надежным сценариям защиты. Наш продукт SafeTech CA является основой для построения инфраструктуры корпоративного доверия. Он обеспечивает выпуск и управление цифровыми сертификатами пользователей, устройств и сервисов, которые позволяют гарантировать их подлинность и безопасное взаимодействие».</p> <p>Андрей Лаптев, директор по продуктовому развитию в Индид, рассказал: «Для Индид участие в создании платформы — это продолжение нашего подхода к защите айдентити как к комплексной задаче. Сегодня организациям уже недостаточно внедрять отдельные средства аутентификации или управления доступом: в условиях гибридной инфраструктуры, роста атак на учетные данные и усиления регуляторных требований компаниям нужен единое управляемое решение, которое связывает пользователей, устройства, сертификаты и корпоративные сервисы. В рамках платформы технологии Индид помогают централизовать управление доступом, применять единые политики аутентификации и обеспечить защищенное подключение к важным системам. Совместно с „Актив“ и SafeTech Lab мы предлагаем рынку решение, которое позволяет перейти от разрозненных инструментов к единой инфраструктуре доверенного доступа».</p> Компании «Актив», SafeTech Lab и «Индид» представили на российском рынке комплексную Платформу управления доступом, или … message https://www.itweek.ru/themes/detail.php?ID=235187 Thu, 16 Jul 2026 09:40:28 +0300 <p><em>Проекты в области искусственного интеллекта часто замирают после этапа демонстрации. Эндрю Селлерс, руководитель группу технологической стратегии компании Confluent, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, почему инфраструктура данных реального времени имеет решающее значение для масштабирования моделей ИИ до производства.</em></p> <p>Большинство инженерных команд, с которыми я общаюсь, могут выпустить демонстрацию ИИ. Прототип работает, заинтересованные стороны впечатлены, и все согласны с тем, что у сценария использования есть потенциал. Затем проект заходит в тупик.</p> <p>Причины могут быть разными, но новые исследования показывают, что часто проблема заключается в трудностях сбора и анализа данных в реальном времени из множества источников. И это усугубляется растущим дефицитом квалифицированных кадров.</p> <p>Согласно отчету Confluent «2026 Data Streaming Report», агентный ИИ работает в производстве только у 32% организаций. В то же время две трети респондентов назвали инфраструктуру данных и качество данных препятствиями на пути к успеху агентного ИИ. Модели работают в контролируемых условиях, но производство — это совсем другая история.</p> <h3>Почему разрыв между демонстрацией и внедрением в производство так велик?</h3> <p>Демонстрации, как правило, работают, потому что всё вокруг них контролируется. Данные статичны и тщательно отбираются, чтобы точно соответствовать тому, что будет требоваться от модели.</p> <p>В производственных средах такие возможности не всегда недоступны. Там системам ИИ приходится запрашивать данные, хранящиеся в десятках источников, включая базы данных, потоки событий, журналы приложений и сторонние каналы. Большая часть этих данных плохо управляется, и лишь небольшая их часть предназначена для обработки агентом ИИ в режиме реального времени. Модели, которые выглядели впечатляюще в пилотных проектах, дают ненадежные результаты, потому что работают с устаревшими, неполными или неконтекстуализированными данными.</p> <p>Инстинктивно хочется настроить модель, но проблема, скорее всего, заключается в данных, которые её питают.</p> <p>В опросе 72% ИТ-руководителей назвали недостаточную инфраструктуру для обработки данных в режиме реального времени препятствием для масштабирования ИИ, по сравнению с 61% годом ранее. Этот рост говорит о том, что проблема никуда не исчезает, и это становится все более очевидным по мере того, как команды переводят проекты в производство.</p> <p>Системам ИИ нужны достоверные, контекстуализированные и актуальные данные, а эти свойства трудно гарантировать, когда данные хранятся в изолированных хранилищах, не предназначенных для непрерывного использования. Пакетные конвейеры почти всегда вносят задержки, не имеют формальных контрактов на данные и скрывают происхождение данных. В итоге система ИИ работает с непоследовательным, частичным снимком бизнеса, а не с тем, что происходит на самом деле сейчас.</p> <h3>Проблема с навыками усложняет ситуацию</h3> <p>В отчете выявлена ​​еще одна проблема: 71% ИТ-руководителей назвали нехватку соответствующей экспертизы и навыков препятствием для внедрения ИИ.</p> <p>Работа по разработке приложений сместилась от кодирования бизнес-логики к созданию информационной среды, где автоматизированные системы могут учиться и обобщать. Создание надежных приложений ИИ требует от разработчиков более высокого уровня знаний в области инженерии данных. Им необходимо понимать распределенные системы, потоковую архитектуру, контроль качества данных и как создавать конвейеры, которые работают в реальных условиях. Им необходимо разбираться в происхождении данных, эволюции схем и в том, что происходит при изменении исходных источников. При этом шаблоны контроля качества, работающие для детерминированного ПО — где одни и те же входные данные дают одинаковые выходные — не применимы к вероятностным системам.</p> <p>Большинство разработчиков раньше не сталкивались с подобным мышлением. Дисциплина обеспечения доставки правильных данных в правильную систему в нужное время, управляемым и многократно используемым способом, перестала быть узкоспециализированной задачей и стала обязательным требованием для всех, кто разрабатывает производственный ИИ.</p> <p>Это влияет на то, как организации должны подходить к преодолению разрыва между демонстрацией и производством. Инвестиции в навыки инженерии данных должны соответствовать инвестициям в сам ИИ.</p> <h3>Что на самом деле требуется для готового к производству ИИ</h3> <p>Организации, которые успешно выходят за рамки пилотного проекта, с самого начала рассматривают инфраструктуру данных как первостепенную задачу. Это означает создание конвейеров обработки данных в реальном времени, а не пакетной обработки. Это означает применение определений схем, метаданных о принадлежности и проверок качества в точке производства данных, а не в озере данных. Это означает структурирование данных в виде многократно используемых продуктов, на основе которых могут строиться различные команды и приложения, так что инженерная работа, поддерживающая одно приложение ИИ, может ускорить разработку следующего, вместо того чтобы начинать с нуля.</p> <p>Согласно отчету, 88% ИТ-руководителей заявили, что платформы потоковой передачи данных помогают решать проблемы инфраструктуры и качества данных для агентного ИИ. Это связано с тем, что они устраняют конкретные причины, по которым проекты ИИ заходят в тупик — доставка данных в реальном времени, управление исходными данными и обеспечение достаточной достоверности данных для использования во время инференса.</p> <h3>Этот сдвиг уже происходит</h3> <p>В исследовании впервые было установлено, что инвестиции в потоковую передачу данных превзошли инвестиции в ИИ и машинное обучение: 88% против 82%. Организации, которые пытались внедрить ИИ в производство, все чаще признают, что модель — не самая сложная часть.</p> <p>Поэтому, если вы застряли на этапе пилотного проекта, не поддавайтесь желанию продолжать оптимизировать модель. Лучше задаться вопросами, являются ли данные, поступающие в модель, актуальными, точными и хорошо управляемыми и были ли ваши конвейеры действительно созданы для производственного ИИ или только для демонстрации, которая должна была сработать только один раз.</p> Проекты в области искусственного интеллекта часто замирают после этапа демонстрации. Эндрю Селлерс, руководитель группу … article https://www.itweek.ru/themes/detail.php?ID=235185 Thu, 16 Jul 2026 09:30:07 +0300 <p><em>Между менеджером проекта и девопс-инженером — огромная пропасть в техническом понимании Kubernetes. Но управлять проектом по внедрению приложений без минимального понимания системы невозможно. </em><em>Обсудим</em><em>, что должен знать менеджер проектов о Kubernetes, чтобы вовремя заметить проблему и говорить с командой на одном языке.</em></p> <h3>Дирижёр, а не музыкант</h3> <p>Kubernetes часто называют системой оркестрации контейнеров, и это сравнение хорошо объясняет суть. Представьте дирижёра, который следит, чтобы все музыканты играли по нотам, и оперативно перезапускает любого из них, если тот сбивается. Из таких контейнеров-музыкантов собирается масштабируемое и отказоустойчивое приложение.</p> <p>Менеджеру проекта обычно не нужно самому что-то настраивать внутри Kubernetes, для этого есть команда. Но без базового понимания того, как устроена эта система, он рискует управлять процессом на ощупь: не понимать, что стоит за словами команды, и не замечать, что что-то идёт не так, пока не станет поздно.</p> <h3>Минимум, который нужно понимать</h3> <p>Есть четыре вещи, в которых менеджеру проекта стоит разбираться, даже если он никогда не будет настраивать кластер руками. Первое — общая архитектура: что такое поды, сервисы, Ingress и Gateway API, который постепенно развивается как более гибкая альтернатива Ingress, и как всё перечисленное связано друг с другом. Второе — какие метрики говорят о здоровье системы. Третье — как быстро самому проверить, всё ли работает исправно. Четвёртое — как задать команде правильные вопросы, если что-то сломалось.</p> <p>За метриками обычно следит комбинация инструментов: Prometheus или Zabbix собирает данные из кластера, а Grafana показывает их в виде наглядных дашбордов. Из этих двух решений для сбора метрик чаще рекомендуют Prometheus. Это минимум, тогда как в более зрелых инфраструктурах для хранения метрик и логов часто используют VictoriaMetrics и Loki, а для сбора и передачи телеметрии — OpenTelemetry.</p> <h3>Что показывает загрузку ресурсов</h3> <p>Первая группа метрик показывает, насколько сервисы загружают процессор, память, сеть и диск, и где из-за этого могут возникнуть проблемы. Загрузка процессора становится тревожным сигналом, когда длительное время держится у отметки 80% от запрошенного объёма (requests) — именно от него автоскейлер считает загрузку в процентах, и это повод задуматься о масштабировании. Упор в жёсткий лимит (limit) масштабирование не запускает, а притормаживает под — это называется throttling. Потребление памяти важно наблюдать в динамике: постоянный необъяснимый рост или выход за установленные пределы обычно приводит к сбоям.</p> <p>Входящий и исходящий сетевой трафик тоже стоит держать в поле зрения: резкие всплески могут говорить о перегрузке, аномальной активности или ошибках приложения. То же касается диска: заполненное хранилище или медленные операции записи и чтения напрямую тормозят работу сервисов.</p> <h3>Как понять, что поды чувствуют себя хорошо</h3> <p>Вторая группа метрик отвечает за стабильность и предсказуемость запуска приложений. Первое, на что стоит смотреть — сколько подов находится в статусе Ready, то есть все ли экземпляры сервиса фактически работают. Частые перезапуски контейнеров — это почти всегда признак сбоев в коде или нехватки ресурсов, и игнорировать такую метрику не стоит.</p> <p>Отдельное внимание заслуживают поды в статусе Pending — те, что не получили ресурсы для запуска. Чаще всего причина банальна: на нодах кластера не хватает процессора или памяти, реже — не примонтировалось хранилище или не сошлись правила размещения. Ошибки CrashLoopBackOff и события OOM сигнализируют о более серьёзной проблеме: контейнеры либо не могут стартовать, либо вылетают из-за превышения лимитов.</p> <h3>Скорость и ошибки — то, что видит пользователь</h3> <p>Третья группа метрик показывает, насколько быстро и стабильно сервис отвечает конечному пользователю. Задержка ответа, измеряемая в перцентилях p95 и p99 — один из самых ранних индикаторов деградации системы: рост задержек обычно заметен задолго до полного отказа.</p> <p>Ещё один прямой сигнал даёт процент запросов с ошибками 5xx. Если их доля устойчиво превышает <nobr>1-2%</nobr> от общего числа запросов, это уже повод для команды начать расследование. Дополняют картину пропускная способность сервиса в запросах за секунду и его доступность — можно ли вообще достучаться до сервиса извне. Здесь важно не путать понятия: readiness- и liveness-пробы — это внутренний механизм кластера (первая убирает неготовый под из балансировки, вторая перезапускает зависший), а реальную внешнюю доступность обычно измеряют отдельным синтетическим мониторингом.</p> <h3>Для тех, кто хочет копнуть глубже</h3> <p>Есть и более тонкие метрики для менеджеров, которые уже освоились с базовым набором. CPU Throttling показывает, что Kubernetes искусственно ограничивает использование процессора контейнером. Это частая причина «непонятных тормозов» при формально невысокой загрузке. Повторно стоит обратить внимание на события OOM, когда система вынуждена убивать поды из-за превышения лимита памяти.</p> <p>Резкий рост количества потоков внутри приложения может говорить об утечках, которые пока не проявились в виде явного сбоя. Поды в статусе Pending в этом более глубоком разрезе стоит читать как сигнал, что кластеру в целом не хватает ресурсов — то есть проблема не в одном сервисе, а в общих лимитах инфраструктуры.</p> <h3>С чего начать, если всё это звучит пугающе</h3> <p>Если список метрик выглядит избыточным, начинать не нужно со всего сразу. Достаточно взять несколько показателей, которые проверяются каждый день, и постепенно расширять список по мере того, как появляется уверенность.</p> <p>Разумный стартовый набор такой:</p> <ol> <li> все нужные экземпляры приложения находятся в состоянии Ready;</li> <li> рестарты контейнеров не повторяются без понятной причины;</li> <li> загрузка CPU и памяти держится ниже 80% от значения requests;</li> <li> задержка p95 не выходит за 500 миллисекунд;</li> <li> доля ошибок 5xx остаётся ниже 1% от общего числа запросов.</li> </ol> <p>Но эти пороги стоит воспринимать как ориентир, а не догму: 500 мс для платёжного сервиса — катастрофа, для тяжёлого отчётного — норма, так что нужно сверяться с SLA своего проекта.</p> <p>Этого набора достаточно, чтобы менеджер проекта мог сам, без помощи команды, открыть дашборд и за минуту понять, в порядке ли система или пора задавать вопросы.</p> <h3>Зачем это всё менеджеру проекта</h3> <p>Менеджеру проекта не обязательно знать все технические детали Kubernetes на уровне инженера. Но понимание высокоуровневой архитектуры и ключевых метрик меняет качество управления проектом: появляется возможность принимать взвешенные решения, разговаривать с DevOps-командой на одном языке и быстро реагировать на проблемы в продакшене, а не узнавать о них постфактум из чужого отчёта.</p> <p>На практике этот разрыв чаще всего превращается в потерянное время при инцидентах. Инженер видит одно, менеджер понимает другое: команда работает с показателями, а менеджер не может ни оценить их критичность, ни объяснить ситуацию заказчику. Базовое понимание метрик закрывает именно этот разрыв, без необходимости самому погружаться в настройку кластера. Выигрывают обе стороны: инженеру спокойнее работать с менеджером, который отличает критичный сигнал от рутины, а проект получает руководителя, способного трезво оценить ситуацию.</p> <p>Для компаний, работающих с контейнеризированными приложениями в банковской сфере, ритейле, телекоме, промышленности и госсекторе, понимание принципов работы Kubernetes особенно важно. В таких проектах цена простоя высока, поэтому менеджеру проекта важно быстро понимать, когда система работает штатно, а когда пора подключать инженеров и разбираться в причинах.</p> <p>#IMAGE_235186#</p> Между менеджером проекта и девопс-инженером — огромная пропасть в техническом понимании Kubernetes … article Иван Грушевский, менеджер проектов mt cloud https://www.itweek.ru/themes/detail.php?ID=235184 Wed, 15 Jul 2026 14:31:08 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал тенденции развития сектора ИКТ и его сегментов (ИТ-отрасли, телекоммуникаций, производства ИКТ-оборудования, оптовой торговли ИКТ-товарами) в I квартале 2026 г.</p> <p>В I кв. 2026 г. сектор ИКТ сохранил лидерство среди крупных отраслей по темпам годового прироста объема реализованных товаров, работ, услуг. Продолжился рост численности работников и объема инвестиций. Решающий вклад в положительную динамику сектора внесла ИТ-отрасль.</p> <p>Объем реализованных товаров, работ, услуг сектора ИКТ в I кв. 2026 г. вырос по сравнению с аналогичным периодом 2025 г. на 22,5%. Максимальный годовой прирост отмечался в марте (+37% к марту 2025 г.). Сектор нарастил долю по этому показателю в экономике в целом с 4,7% в I кв. 2025 г. до 5,8%.</p> <p>Объем реализации в ИТ-отрасли увеличился более чем на треть (+37,6% к I кв. 2025 г.), что вдвое выше прошлогодней динамики (+16,5% к I кв. 2024 г.). Среди крупных сегментов рост сохранился также в телекоммуникациях (+12,8% к I кв. 2025 г.).</p> <p>Среднесписочная численность работников сектора ИКТ в I кв. 2026 г. достигла максимума — 1,7 млн человек (+2% к IV кв. 2025 г. и +6,4% к I кв. 2025 г.). Основной вклад в прирост по-прежнему вносит ИТ-отрасль, несмотря на некоторое снижение числа вакансий в этом сегменте.</p> <p>Объем инвестиций в основной капитал в секторе ИКТ превысил уровень I кв. 2025 г. на 6,8% (в текущих ценах), что является значимым результатом на фоне отрицательной динамики по экономике в целом (-5,7%). Рост в секторе в целом достигнут благодаря ускорению динамики вложений в ИТ-отрасли.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал тенденции развития сектора ИКТ … message https://www.itweek.ru/themes/detail.php?ID=235183 Wed, 15 Jul 2026 13:16:39 +0300 <p>MWS AI (МТС Web Services) выпустила Cotype Pro 3 и Cotype Light 3 — языковые модели третьего поколения, способные работать одновременно с текстом и изображениями. Размер моделей — 27 и 9 млрд параметров соответственно. Модели предназначены для построения промышленных ИИ-агентов — программ, способных самостоятельно выполнять многошаговые задачи без участия человека.</p> <p>Для оценки агентских возможностей MWS AI разработала собственный набор из 178 бизнес-сценариев. Каждая задача ставит модель в одну из пяти реальных рабочих ролей и проверяет, как агент пользуется доступными инструментами, соблюдает бизнес-правила и доводит задачу до результата. Это роли оператора поддержки (вопросы по услугам, подпискам и списаниям абонента), консультанта по тарифам (подбор и смена тарифного плана под реальное потребление), кадрового специалиста (расчёт отпускных и больничных, работа с документами), аналитика по компаниям (составление досье на юрлицо по ИНН — финансы, руководители, связи с другими организациями) и инспектора налоговых рисков (расследование схем переноса бизнеса между компаниями и решение о назначении проверки). Тест измеряет два показателя: долю сценариев, в которых модель полностью выполнила задачу, и показатель воспроизводимости — насколько стабильно модель решает одну и ту же задачу при многократном обращении. Cotype Pro 3 показала 92,2% и 79,1%, Cotype Light 3 — 88,6% и 73,9%. Предыдущая версия Cotype Pro 2.6.1 — 80,5% и 62,5%.</p> <p>«Мы смотрели на то, как корпоративный рынок внедряет агентный ИИ — и там есть один устойчивый паттерн: модель отлично работает на демо, а в продакшне начинает вести себя непредсказуемо. Мы думаем, что одна из главных причин — это именно нестабильность поведения модели: она решила задачу один раз, но никто не знает, решит ли она её завтра при тех же условиях. Когда мы начали делать собственный бенчмарк для агентных сценариев, мы специально заложили в него метрику воспроизводимости. Это не про то, какой максимальный результат может показать модель. Это про то, как она ведёт себя при многократном обращении. Вопрос, получит ли компания тот же правильный ответ при тысячном обращении, что и при первом, — это вопрос о том, можно ли строить на модели реальные процессы», — подчеркнул генеральный директор MWS AI Денис Филиппов.</p> <p>«Отдельное внимание при разработке Cotype Pro 3 было уделено качеству русскоязычной генерации. MWS AI разработала собственную метрику, которая проверяет, насколько стабильно модель остаётся в русском языке и не производит языковых деградаций — случайных переходов на другой язык, бессмысленных повторов или искажений текста. Тест проводился на корпусе из почти 304 тысяч слов. Модель сгенерировала 99,79% русского текста без языкового дрейфа», — добавил директор по экспериментальным продуктам MWS AI Сергей Пономаренко.</p> <p>В независимом бенчмарке MERA модель на 27 млрд параметров заняла третье место, уступив только моделям в несколько раз большего размера. На открытом бенчмарке MWS AI Vision Bench, который оценивает работу с русскоязычными корпоративными документами и содержит более 800 изображений и 2 500 заданий, модель показала точность 74%, превысив результаты зарубежных моделей. Проверялись пять навыков: считывание текста с изображения, воспроизведение структуры документа, определение местоположения элементов на странице, извлечение данных и ответы на вопросы по содержимому. Поддерживаются русский, английский и китайский языки.</p> <p>Обе модели можно развернуть в закрытом контуре на серверах заказчика, в том числе под управлением российской ОС Astra Linux, и дообучить на корпоративных данных. Модели доступны как отдельно, так и в составе MWS AI Agents Platform. Контекстное окно обеих моделей составляет 262 тысячи токенов. Этого достаточно, чтобы модель одновременно удерживала в памяти документ или архив объёмом около 600 страниц текста на русском языке — например, весь пакет договоров по крупной сделке или годовой корпоративный отчёт с приложениями. Модели могут работать на видеокарте A100, что делает внедрение ИИ-агентов на базе Cotype Pro 3 и Cotype Light 3 доступным для широкого круга компаний. Квантование и технология одновременного предсказания нескольких токенов (MTP) позволяют запускать модели на менее производительном оборудовании и обеспечивают более высокую скорость генерации, чем у решений сопоставимого класса, без потерь в качестве.</p> <p>MWS AI обучает Cotype Pro 3 и Cotype Light 3 и другие модели на облачных мощностях MWS Cloud. В ходе тестирования MWS AI также подтвердила полную технологическую совместимость моделей семейства Cotype со всеми компонентами отечественных программно-аппаратного комплексов.</p> MWS AI (МТС Web Services) выпустила Cotype Pro 3 и Cotype Light 3 — языковые модели третьего поколения … message https://www.itweek.ru/themes/detail.php?ID=235182 Wed, 15 Jul 2026 13:15:51 +0300 <p>Искусственный интеллект перестаёт быть точечным экспериментом и становится основой перестройки операционной модели банков — с перераспределением ролей между сотрудниками, системами автоматизации и ИИ-агентами. К такому выводу пришли аналитики компании Axenix в исследовании «Банки будущего: тренды и развитие в мире», посвящённом ключевым направлениям трансформации мирового банковского сектора.</p> <p>Главный драйвер сдвига — растущий спрос на скорость и персонализацию сервисов, который всё труднее закрывать процессами с преобладанием ручных операций. Поэтому банки постепенно переходят от «умных инструментов», которые лишь подсказывают сотруднику, к «умным исполнителям» — агентным системам, способным самостоятельно планировать и выполнять сложные задачи в разных банковских сценариях. Пока такие решения остаются редкостью в промышленной эксплуатации: их сдерживают требования регуляторов, модельные риски и вопросы качества данных. Поэтому большинство банков движутся к автономности поэтапно — от «умной надстройки» над существующим процессом к агентным приложениям под отдельные функции и далее к полному перепроектированию процесса, где человек выполняет роль контролёра, а не исполнителя рутинных операций.</p> <p>Особенно быстро ИИ проникает в комплаенс, мониторинг и киберзащиту. В процедурах KYC (проверка клиента) и AML (противодействие отмыванию доходов) банки применяют поведенческую аналитику и выявление аномалий, чтобы точнее находить подозрительные операции. В рыночном надзоре ИИ помогает предотвращать нарушения внутри самого банка — через непрерывный мониторинг сделок, выявление признаков инсайдерской торговли и анализ коммуникаций сотрудников. Одновременно перестраивается киберзащита: рост числа дипфейков и мошенничества с использованием генеративного ИИ заставляет банки усиливать удалённую идентификацию клиентов — внедрять проверку «живости» (liveness detection) и поведенческую биометрию.</p> <p>Параллельно банки массово внедряют ИИ-помощников для разработчиков, риск-менеджеров, сотрудников поддержки и аналитиков. Такие инструменты берут на себя рутину: поиск информации, подготовку и перепроверку типовых документов, — а сотрудники сосредотачиваются на коммуникации с клиентом и принятии решений.</p> <p>Тренд на активное внедрение ИИ прослеживается и в российском банковском секторе. По данным Банка России, которые приводятся в исследовании, на конец 2025 года технологии искусственного интеллекта применяла уже каждая пятая финансовая организация в стране, ещё около трети планируют внедрить их в ближайшие три года. Большинство используют ИИ прежде всего для снижения операционных затрат и оптимизации управления рисками.</p> <p>Развитие ИИ в российских банках идёт на фоне импортозамещения и перехода к цифровому суверенитету: как субъекты критической информационной инфраструктуры, банки выстраивают ИИ-решения преимущественно на отечественном технологическом стеке.</p> <p>«Российские банки уверенно проходят путь от отдельных пилотов к системному использованию ИИ — сегодня это уже рабочий инструмент, встроенный в конкретные процессы и приносящий измеримый экономический эффект. При этом фокус пока смещён в сторону внутренней эффективности: сокращения издержек, ускорения обработки обращений, более точного управления рисками. Ключевыми ограничителями остаются качество и доступность данных, а также уровень доверия к технологии — как со стороны регулятора, так и со стороны клиентов», — прокомментировала Анастасия Иволина-Райская, директор практики «Рынки капитала» Axenix.</p> <p>Перестройка операционной модели под ИИ — первый из шести макротрендов, которые эксперты Axenix выделили в исследовании мирового банковского сектора. Помимо него, в отчёте рассматриваются трансформация банков в персональных финансовых помощников клиентов, клиентский опыт как драйвер роста выручки, борьба за статус основного финансового партнёра клиента, переход к открытым моделям данных и партнёрствам, а также трансформация платёжной инфраструктуры в сторону цифровых и программируемых моделей.</p> Искусственный интеллект перестаёт быть точечным экспериментом и становится основой перестройки операционной модели … message https://www.itweek.ru/themes/detail.php?ID=235181 Wed, 15 Jul 2026 13:14:53 +0300 <p>Компания Security Vision представила очередное обновление платформы. Релиз включает доработки, направленные на упрощение управления доступом, повышение прозрачности настроек и удобство повседневной работы пользователей. В частности, добавлена поддержка аутентификации по OIDC, расширены возможности анализа конфигурации типов объектов, а также оптимизирована работа с отчётами и чатами.</p> <p>В платформе реализована поддержка протокола аутентификации OpenID Connect (OIDC). Новая возможность расширяет доступные варианты подключения Security Vision к используемым в организации системам аутентификации.</p> <p>В настройках типов объектов появилась вкладка «Применения», на которой отображаются все места использования выбранного типа объекта в платформе.</p> <p>Новая вкладка помогает оценить существующие зависимости перед изменением типа объекта и снижает риск непреднамеренного влияния на связанные настройки.</p> <p>В разделе истории запуска отчётов переработана компоновка элементов управления «Посмотреть входные параметры» и «Выгрузить отчёт».</p> <p>Изменение упрощает доступ к параметрам запуска и результатам ранее сформированных отчётов.</p> <p>В блоке «Чат» карточек объектов добавлен регистронезависимый поиск сотрудников при их упоминании.</p> <p>Теперь поиск не зависит от регистра введённых символов, что делает выбор сотрудника для добавления в обсуждение удобнее.</p> <p>Для работы коннектора PowerShell теперь требуется интерпретатор PowerShell версии 7.4.16. Новое требование необходимо учитывать при обновлении платформы и подготовке инфраструктуры.</p> Компания Security Vision представила очередное обновление платформы. Релиз включает доработки, направленные на упрощение … message https://www.itweek.ru/themes/detail.php?ID=235180 Wed, 15 Jul 2026 09:19:28 +0300 <p><em>Автоматизация на основе искусственного интеллекта успешна, когда ИТ-руководители понимают поведение процессов, исключения, передачу управления и риски принятия решений перед развертыванием агентов или автоматизацией рабочих процессов, пишет на портале </em><em>InformationWeek</em> <em>Анджали Гарг, старший руководитель отдела оперативной аналитики, стратегии и автоматизации процессов компании Walmart.</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> <h3>Не каждый ручной шаг должен быть автоматизирован</h3> <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> Автоматизация на основе искусственного интеллекта успешна, когда ИТ-руководители понимают поведение процессов, исключения … article https://www.itweek.ru/themes/detail.php?ID=235178 Wed, 15 Jul 2026 09:06:45 +0300 <p><em>Системы интеллектуального видеонаблюдения уже давно стали полноценным элементом цифровой инфраструктуры организации и, как и любое сетевое устройство, могут стать целью киберзлоумышленников. Чтобы они не стали потенциальной точкой уязвимости, производители оборудования уделяют вопросам кибербезопасности не меньше внимания, чем качеству изображения или развитию интеллектуальной видеоаналитики.</em> <em>Рассмотрим</em><em>, что </em><em>они </em><em>делают для защиты от кибератак.</em></p> <p>Спектр таких угроз постоянно расширяется. В компании «Информзащита» подсчитали, что за первый квартал 2026 года количество срабатываний по атакам на IoT-устройства <a href="https://ru-bezh.ru/kompanii-i-ryinki/news/26/04/28/ataki-na-iot-ustroystva-v-i-kvartale-2026-goda-prevysili-589-mln">увеличилось</a> примерно на 11% и достигло 589,4 млн. Камеры видеонаблюдения являются одним из наиболее распространенных и уязвимых сегментов IoT, и эти данные напрямую отражают динамику угроз для систем видеонаблюдения. Более ранний отчет Bitdefender и Netgear за январь-октябрь 2025 года показывает, что в прошлом году обнаружено 13,6 млрд. атак и заблокировано 4,6 млрд. попыток эксплуатации уязвимостей в потребительских IoT-устройствах. При этом IP-камеры вместе с устройствами для стриминга и Smart TV <a href="https://www.bitdefender.com/en-us/blog/hotforsecurity/bitdefender-and-netgear-2025-iot-security-landscape-report-shows-alarming-rise-in-smart-home-threats">содержали более половины</a> всех известных уязвимостей.</p> <p>Среди наиболее распространенных угроз — включение камер в ботнеты (например, ботнет Eleven11bot в феврале-сентябре 2025 года <a href="https://securityaffairs.com/174941/malware/new-eleven11bot-botnet-infected-86k-iot-devices.html">заразил</a> более 86 000 IoT-устройств, главным образом камеры видеонаблюдения и сетевые видеорегистраторы), несанкционированный доступ к видеопотокам, использование устройств в качестве точки входа во внутреннюю сеть компании, а также попытки обхода или обмана алгоритмов видеоаналитики.</p> <p>Использование оборудования, в котором вопросы кибербезопасности не были в полной мере учтены на этапе проектирования, приводит к значительным рискам для компаний. Показательна ситуация, произошедшая в 2025 году. Исследователи компании Claroty <a href="https://www.incibe.es/incibe-cert/alerta-temprana/avisos-sci/multiples-vulnerabilidades-en-productos-de-axis-communications">обнаружили</a> ряд критических уязвимостей в программных продуктах Axis Communications, используемых для управления системами видеонаблюдения. Наиболее серьезная из них — CVE-2025-30023 получила 9 из 10 баллов по стандарту CVSS. Уязвимость была связана с механизмом обработки данных между клиентом и сервером и позволяла аутентифицированному пользователю выполнить произвольный код, получив возможность отдавать команды системе видеонаблюдения. Угроза была масштабной и <a href="https://thehackernews.com/2025/08/6500-servers-expose-axis-remoting.html">открывала доступ</a> к более 6500 серверов, доступных через проприетарный протокол удаленного взаимодействия. В случае успешной атаки злоумышленник мог получить контроль над сервером управления видеонаблюдением и доступ к связанным компонентам инфраструктуры безопасности.</p> <p>Другой пример связан с уязвимостью CVE-2025-7503, обнаруженной для ряда OEM IP-камер производства Shenzhen Liandian Communication Technology LTD. Согласно данным, <a href="https://vuldb.com/?id.3007503">опубликованным</a> в базе VulDB, устройства компании содержали активированный сервис Telnet с предустановленными учетными данными. И при наличии сетевого доступа злоумышленник мог получить административный доступ к устройству.</p> <p>В ответ на растущие угрозы ведущие производители переходят от реактивного подхода к концепции Secure by Design, т. е. к закладыванию механизмов защиты на этапе разработки продукта. Одним из ключевых элементов такой архитектуры является аппаратный корень доверия (Hardware Root of Trust). Его задача — мониторинг ПО в каждом компоненте аппаратного обеспечения на предмет взлома, перезаписи или любой другой компрометации. Иными словами — программа-контролер. Подобные платформы <a href="https://www.axis.com/solutions/edge-vault">уже интегрированы</a> в устройства ряда ведущих производителей. Они обеспечивают безопасную загрузку устройства (Secure Boot), защищенное хранение криптографических ключей и контроль целостности программного обеспечения. Благодаря этому устройство можно запустить только с доверенным программным кодом, подписанным производителем.</p> <p>Другой важный механизм для обеспечения безопасности — защищенное обновление прошивки. Перед установкой нового ПО устройство <a href="https://www.axis.com/solutions/edge-vault">проверяет </a>цифровую подпись обновления, предотвращая загрузку модифицированных или вредоносных версий. В дополнение существует <a href="https://developer.axis.com/video-streaming-and-recording/signed-video">технология</a> подтверждения подлинности видеозаписей Signed Video. Эта функция позволяет проверить, что видеоматериалы не подвергались изменениям после записи. Для этого используются криптографические механизмы, основанные на внутренних защищенных ключах устройства. Такой подход особенно востребован в ситуациях, когда видеозаписи используются в качестве доказательной базы при расследованиях или судебных разбирательствах.</p> <p>Для реализации аппаратной защиты производители используют <a href="https://www.nxp.com/products/SE052F">защищенные элементы</a> семейства EdgeLock компании NXP, включая EdgeLock SE052F. Микросхемы предназначены для безопасного хранения криптографических ключей и выполнения чувствительных операций внутри изолированной аппаратной среды, что существенно усложняет попытки использования или организации уязвимостей в устройствах даже при физическом доступе.</p> <p>Для российских заказчиков все большее значение приобретает соответствие требованиям отечественных регуляторов. Особое внимание вопросам защиты информации уделяется на объектах критической информационной инфраструктуры, транспортной безопасности, в государственном секторе и промышленности. Так например российские производители начинают <a href="https://www.cnews.ru/news/line/2025-05-05_atronik_nachala_rabotu">сертифицировать</a> интеллектуальные IP-видеокамеры в соответствии с требованиями российского законодательства в области защиты информации. Кроме того, в России действует <a href="http://fsb.ru/fsb/science/single.htm!id=10438106@fsbResearchart.html">система сертификации</a> технических средств обеспечения транспортной безопасности, включая решения в области интеллектуального видеонаблюдения.</p> <p>Отдельным направлением угроз становятся атаки на системы видеоаналитики, использующие искусственный интеллект. Исследователи киберугроз регулярно демонстрируют методы, позволяющие вводить алгоритмы компьютерного зрения в заблуждение с помощью специально подготовленных изображений или физических объектов. В ответ производители совершенствуют модели машинного обучения, внедряют дополнительные механизмы проверки результатов и используют комбинированный анализ данных из нескольких источников. Практика последних лет показывает, что уязвимости могут обнаруживаться даже у крупнейших мировых производителей. Поэтому сегодня ключевым показателем является не отсутствие ошибок, а способность компании быстро выявлять угрозы, выпускать обновления безопасности и обеспечивать прозрачный процесс управления уязвимостями.</p> <p>Для заказчиков это означает необходимость оценивать не только характеристики камер и возможности видеоаналитики, но и наличие аппаратного корня доверия, механизмов безопасной загрузки и обновления, криптографической защиты и независимых подтверждений безопасности. Именно эти факторы все чаще становятся определяющими, поскольку помогают выбрать надежную современную систему видеонаблюдения.</p> <p>#IMAGE_235179#</p> Системы интеллектуального видеонаблюдения уже давно стали полноценным элементом цифровой инфраструктуры организации и, как … article Илья Малышев, руководитель направления развития продуктов видеонаблюдения RVi Group https://www.itweek.ru/themes/detail.php?ID=235169 Tue, 14 Jul 2026 14:09:05 +0300 <p>Согласно исследованию Nexign, большинство российских компаний применяют для работы с данными интеграционные инструменты, самый востребованный класс решений — ETL-системы.</p> <p>Объем данных в мире продолжает стремительно расти: ежедневно генерируется порядка 400 млн терабайт информации. По оценкам экспертов, в 2025 году объем созданных данных достиг 181 зеттабайта, а в текущем может превысить 200 зеттабайт. В условиях такого увеличения количества данных и масштабной цифровизации компаниям становится все сложнее обеспечивать стабильный обмен и обработку данных без применения систем ETL/ESB.</p> <p>Согласно результатам исследования Nexign, 71% опрошенных организаций уже используют интеграционные инструменты. Среди них не только корпорации (20%) и крупный бизнес (17%), но и компании среднего и малого сегмента (34%). При этом чуть более половины респондентов применяют отдельные инструменты, такие как ESB-шины, ETL-решения или брокеры сообщений, тогда как комплексные интеграционные платформы используют 17% компаний.</p> <p>В среднем компании используют в своей работе более одного инструмента. Наиболее распространенными являются ETL-системы — они установлены у 62% респондентов. ESB применяют 44% компаний, ELT — 26%.</p> <p>Исследование показывает, что использование коммерческих продуктов не является единственной альтернативой. Практикуется гибкий подход к выбору решений: 35% компаний подбирают инструмент индивидуально под каждую задачу. Четверть организаций используют решения с открытым исходным кодом, 22% — продукты вендоров, 18% — собственные разработки. При этом использование решений с открытым исходным кодом и самописных решений нередко связано с дополнительными затратами на поддержку и развитие. По оценкам экспертов, до 30% компаний, внедряющих самописные ETL/ELT-системы, не достигают запланированных SLA по производительности из-за сложности интеграции устаревших (legacy) систем.</p> <p>Главный критерий выбора инструментов для работы с данными — наличие надежных коннекторов к базам данных разных типов и производителей (51%). Также для респондентов важны возможность работы под высокой нагрузкой и с большими объемами данных (45%) и поддержка интеграции с российским программным обеспечением (44%).</p> <p>Встроенные элементы искусственного интеллекта интересуют пока в меньшей степени — их значимость отметили около 13% компаний вне зависимости от масштаба бизнеса. На фоне активного импортозамещения снизилась актуальность коннекторов к зарубежному ПО — этот критерий важен лишь для 11% респондентов.</p> <p>Самым распространенным сценарием использования интеграционных инструментов остается передача данных между разнородными системами внутри компании, такими как ERP, CRM, биллинг и DWH — его указали 63% участников исследования. 44% компаний применяют такие инструменты для синхронизации справочников и мастер-данных между разными приложениями, 43% — для построения сквозных бизнес-процессов на базе нескольких ИТ-систем, 42% — для оперативной загрузки, трансформации и агрегации больших массивов данных для аналитики и бизнес-аналитики.</p> <p>В числе ключевых эффектов от внедрения компании чаще всего называют сокращение рутинных операций, повышение доступности и качества данных, повышение надежности обмена данными (все примерно по 50%).</p> <p>31% респондентов отметили снижение совокупной стоимости владения (ТСО). Большинство из них указывают на значительное сокращение объема рутинных операций при решении интеграционных задач, а также на снижение вовлечения программистов за счет разработки с минимальным использованием кода (low-code) и предоставления интуитивно понятных инструментов для решения типовых задач (self-service).</p> <p>Кроме того, четверть опрошенных указали на ускорение вывода новых продуктов на рынок (time-to-market). Из них 55% оценили его до 25%, 14% — до 50%, а еще 14% — до 80%. В первую очередь этот эффект актуален для отраслей с большим объемом транзакций и клиентов.</p> <p>«Результаты опроса свидетельствуют о росте зрелости российского бизнеса в области управления данными. В связи с увеличением объемов данных в компаниях, а также количества систем и связей между ними растет востребованность интеграционных инструментов. На первый план выходят такие критерии, как производительность, универсальность и совместимость с российским ПО. Важно, что компании уже ощущают конкретные эффекты от использования этих инструментов — от снижения количества рутинных операций до ускорения вывода продуктов на рынок», — прокомментировал результаты исследования Максим Нартов, директор по развитию бизнеса Nexign.</p> Согласно исследованию Nexign, большинство российских компаний применяют для работы с данными интеграционные инструменты … message https://www.itweek.ru/themes/detail.php?ID=235168 Tue, 14 Jul 2026 14:08:00 +0300 <p>В новой версии low-code платформы GreenData появилась расширенная канбан-доска с многоуровневой структурой, гибкой настройкой карточек, WIP-лимитами, персональной фильтрацией и возможностью встраивания доски в карточки объектов.</p> <p>Новая канбан-доска в low-code платформе GreenData теперь позволяет работать не только с классической моделью «задача — статус», но и с более сложными процессами. Пользователи могут распределять карточки по этапам, дорожкам и группам одновременно. Например, в одном представлении можно увидеть задачи по статусам выполнения, командам и проектам. Так, пользователи могут быстрее оценивать общую картину процесса, видеть загрузку направлений и находить участки, где задачи начинают накапливаться.</p> <p>При этом канбан-доска работает с данными любого типа объекта платформы: задачами, обращениями, заявками, документами и другими сущностями. Она не хранит данные отдельно, а отображает уже существующие объекты системы. Если пользователь перемещает карточку из одного этапа в другой, в системе меняется соответствующий атрибут объекта, например статус задачи. Эти изменения сразу становятся доступны в реестрах, дашбордах и других представлениях, построенных над теми же данными.</p> <p>Кроме того, в новой версии были расширены возможности настройки карточек канбана. Для них можно использовать HTML-шаблоны и адаптировать внешний вид под конкретный бизнес-сценарий, что позволяет выводить на карточку только ту информацию, которая нужна пользователю для принятия решения, и не перегружать доску лишними данными.</p> <p>Еще одно изменение касается контроля загрузки команд. В канбан-доске появились WIP-лимиты — ограничения на количество задач, которые могут одновременно находиться в определенном состоянии, например, «в работе». Их можно задавать для этапов, дорожек и групп, а также рассчитывать динамически с помощью алгоритма. Например, лимит может зависеть от количества сотрудников в команде, режима работы или текущих условий процесса. Если количество задач превышает заданную границу, система визуально подсвечивает перегрузку, помогая быстрее замечать узкие места и управлять нагрузкой до того, как она начнет влиять на процессы.</p> <p>Также появилась двухуровневая модель фильтрации и сортировки на канбан-доске. Общие правила задаются администратором и применяются для всех пользователей, например, чтобы исключить из отображения задачи закрытых проектов. При этом каждый пользователь может настроить собственную выборку по атрибутам, этапам, дорожкам или группам. Такие параметры сохраняются в URL, поэтому ссылкой на нужный срез можно поделиться с коллегой.</p> <p>Отдельно была реализована возможность встраивать канбан-доску в карточку объекта через виджет. В карточке проекта можно отобразить доску с задачами проекта, в карточке клиента — обращения, а в карточке релиза — связанные доработки. Контекстный объект автоматически используется как параметр фильтрации, поэтому пользователю не нужно переходить в отдельный раздел и вручную настраивать выборку.</p> <p>«Когда в работе одновременно находятся десятки или сотни задач, важно не только фиксировать их статусы, но и вовремя видеть, где процесс начинает замедляться. Перегруз команды, скопление задач на отдельном этапе или приближение дедлайнов должны быть заметны до того, как это станет проблемой. Канбан-доска в GreenData помогает увидеть эти сигналы в рабочем контексте — карточки связаны с объектами платформы, изменения сразу отражаются в реестрах и отчетах, а руководители и команды работают с одной актуальной картиной процесса», — отметила Ксения Золотарева, директор по продукту GreenData.</p> В новой версии low-code платформы GreenData появилась расширенная канбан-доска с многоуровневой структурой, гибкой … message https://www.itweek.ru/themes/detail.php?ID=235167 Tue, 14 Jul 2026 09:15:03 +0300 <p><em>В течение двадцати лет компании создавали дашборды для принятия более взвешенных решений и тратили столько же времени на то, чтобы заставить людей их открывать. Теперь, когда информация может передаваться туда, где уже выполняется работа, эра дашбордов подходит к концу, и на ее место приходит нечто более полезное, пишет в корпоративном блоге Ник Меркурио, директор IDC по доходам.</em></p> <p>Большую часть своей карьеры я посвятил тому, чтобы помогать организациям внедрять в свою деятельность аналитику данных о клиентах и ​​сотрудниках. И стал свидетелем того, как вокруг дашбордов возникала целая индустрия.</p> <p>Компании инвестировали миллиарды в сбор отзывов клиентов, анализ настроений сотрудников, операционные показатели и бизнес-аналитику. Целые категории ПО были построены вокруг того, чтобы помочь организациям визуализировать эту информацию и принимать решения.</p> <p>Модель работала чрезвычайно хорошо.</p> <p>Такие компании, как Qualtrics, Medallia, Tableau, Salesforce и многие другие, помогли определить целое поколение корпоративного ПО. Но со временем выявилась неприятная закономерность. Проблема заключалась не в сборе данных, а в том, чтобы заставить людей их использовать.</p> <p>Организации годами пытались побудить руководителей, менеджеров и рядовых сотрудников регулярно заходить в дашборды, просматривать отчеты, выявлять проблемы и принимать меры.</p> <p>Принятие этого стало самостоятельной бизнес-проблемой. Аналитика предоставлялась, но привычки ее использовать не было.</p> <h3>Скрытая стоимость дашбордов</h3> <p>Проблема с дашбордами проста: они требуют от пользователей прерывать свой рабочий процесс.</p> <p>Каждый дашборд предполагает, что пользователь:</p> <ol> <li> прекратит делать то, что он делает;</li> <li> откроет отдельное приложение;</li> <li> найдет необходимую информацию;</li> <li> интерпретирует ее;</li> <li> решит, что делать дальше.</li> </ol> <p>Этот процесс создает трение, а трение — враг внедрения.</p> <p>Сегодня большинство профессионалов проводят большую часть своего времени в нескольких средах:</p> <ul> <li> электронная почта;</li> <li> Teams;</li> <li> Slack;</li> <li> CRM-платформы;</li> <li> ChatGPT;</li> <li> Claude;</li> <li> приложения для повышения производительности.</li> </ul> <p>Они стали операционными системами для современной работы. Каждое дополнительное приложение конкурирует за внимание с этими средами, и большинство проигрывает.</p> <h3>Искусственный интеллект меняет ситуацию</h3> <p>Большие языковые модели создали новый интерфейс для работы, позволив пользователям взаимодействовать с аналитикой на естественном языке, а не через отчеты, дашборды и порталы. Впервые аналитику больше не нужно размещать в отдельном месте. Вместо этого она может напрямую доставляться пользователю.</p> <p>Руководитель может задать вопрос в ChatGPT. Продавец, готовящийся к встрече с клиентом, может мгновенно узнать о рыночных тенденциях, конкурентных угрозах и получить аналитические инсайты непосредственно в Salesforce. Руководитель продукта может получать рыночные инсайты через Teams. Стратег может запрашивать сложные исследования через ИИ-помощника.</p> <p>При этом пользователь никогда не покидает свой рабочий процесс, потому что аналитика приходит к нему сама. Это больше, чем просто улучшение пользовательского опыта: речь идет о внедрении принципиально иной операционной модели.</p> <p>Цель состоит не просто в улучшении аналитики. Речь идет об уменьшении трения между аналитикой и действием.</p> <h3>Почему собственные данные важны как никогда</h3> <p>Многие организации считают, что конкурентным преимуществом является сам ИИ. Я придерживаюсь иной точки зрения: по мере того, как модели оказываются все более доступными, отличительной чертой становится аналитика.</p> <p>Организации, обладающие уникальными, собственными, заслуживающими доверия данными, получат значительное преимущество, поскольку смогут сочетать ИИ с инсайтами, которые невозможно найти в общедоступном Интернете. Именно это делает нынешний момент таким многообещающим.</p> <p>Данные об объеме рынка, конкурентных раскладах и производительности поставщиков, тенденции внедрения технологий, отраслевые прогнозы и стратегические исследования — это те наборы данных, которые организации используют для принятия решений на миллиарды долларов. Исторически они получали доступ к этой информации через отчеты, порталы и взаимодействие с аналитиками. Сегодня ИИ позволяет нам переосмыслить способы использования этой информации.</p> <h3>От аналитических систем к системам принятия решений</h3> <p>Следующая эволюция — это нечто большее, чем просто дашборды и отчеты. И даже больше, чем ИИ-помощники.</p> <p>Реальная возможность заключается в создании технологического уровня аналитики, который объединяет:</p> <ul> <li> анализ рынка;</li> <li> анализ данных о клиентах;</li> <li> оперативный анализ;</li> <li> финансовый анализ;</li> <li> собственные корпоративные данные.</li> </ul> <p>Когда эти сигналы объединяются, организации получают более полное представление о своих рынках, клиентах, конкурентах и эффективности бизнеса. С этого момента речь уже идет о новой системе принятия решений. Речь идет о внедрение надежной технологической аналитики непосредственно в рабочие процессы, где принимаются решения.</p> <p>Организации, которые добьются успеха в следующем десятилетии, не обязательно будут обладать наибольшим количеством данных, но у них будет наименьшее трение между аналитикой и действием.</p> <p>Дашборды устарели, потому что аналитике больше не нужен пункт назначения. Она может напрямую предоставляться в момент принятия решения.</p> В течение двадцати лет компании создавали дашборды для принятия более взвешенных решений и тратили столько же … article https://www.itweek.ru/themes/detail.php?ID=235165 Tue, 14 Jul 2026 08:59:56 +0300 <p><em>Бизнес требует прорывов, а технические команды уходят в глухую оборону, избегая любых рисков. Почему так происходит? Ответ кроется не в нехватке талантов, а в глубоких системных сбоях на стыке управления, финансов и корпоративной культуры. Рассмотрим, почему безынициативные ИТ-отделы годами создают одни и те же функции.</em></p> <h3>Иллюзия контроля и налог на микроменеджмент</h3> <p>Все начинается на уровне стратегии. Классическая ошибка топ-менеджмента — нанять дорогих специалистов и директивно спустить им готовые решения. В итоге высокооплачиваемые эксперты превращаются в «кодеров по вызову». Интеллектуальный капитал стремительно выгорает, ведь линейный менеджмент никогда не возьмет на себя ответственность за стратегию, в формировании которой ему не позволили участвовать.</p> <p>Избыточные круги согласований и раздутые матрицы RACI создают лишь видимость управления рисками. На деле они порождают коллективную безответственность: если релиз срывается, каждый участник процесса надежно защищен «согласованной бумагой». Убытки же несет исключительно бизнес.</p> <p>Ситуация усугубляется еще и тем, что сотрудники мыслят предельно прагматично: если инновационное архитектурное решение экономит компании миллионы, команда в лучшем случае получит премию в размере оклада. Но если эксперимент приведет к сбою — последует публичная порка или увольнение. Инициатива становится финансово невыгодной.</p> <p>Особенно ярко это проявляется в компаниях, переживших серьезные сбои или кассовые разрывы. И если этот режим гиперкомпенсации вовремя не отключить, фокус бизнеса навсегда смещается с развития на банальное выживание, где команда тратит 80% времени на перестраховку и лишь 20% — на сам продукт.</p> <h3>Финансовая и юнит-экономика</h3> <p>Вторая причина кроется в юнит-экономике. Внедрение передовых технологий, будь то оркестрация мультиагентных ИИ-систем в Vertical SaaS, часто дает непредсказуемую финансовую модель. Страх технического руководства перед экспоненциальным ростом затрат на API и сжиганием бюджета приводит к тому, что перспективные проекты годами пылятся в статусе «архитектура пока не готова» (так называемая «ловушка OpEx»).</p> <p>Бизнес, со своей стороны, требует гарантий ROI до старта проекта. Но в технологиях невозможно гарантировать возврат инвестиций на этапе гипотезы. Заставляя просчитывать точные цифры для MVP, CEO вынуждает команду приносить лишь скучные, небольшие улучшения, на корню отсекая прорывные продукты.</p> <p>Технические команды изолированы от бизнес-контекста. Инженеры оптимизируют инфраструктуру ради инфраструктуры, не понимая, как их решения влияют на CAC (стоимость привлечения), LTV или операционную маржу. Без связи кода с деньгами продуктовый Ownership не возникает.</p> <h3>Инфраструктурные заложники</h3> <p>Бизнес годами требует новых фич, игнорируя рефакторинг фундамента, пока не образуется хрупкий legacy-монолит. Команда избегает ответственности за ключевые сервисы, понимая: любое вмешательство может обрушить ядро бизнеса.</p> <p>Из этого вытекает критическая зависимость от исполнителей. Экспертиза по критическим узлам концентрируется в руках пары разработчиков, диктующих условия. Остальные просто обходят эти зоны стороной.</p> <p>Сюда же добавляется ловушка вендор-лока. Продукт намертво врастает в облачного провайдера. Даже понимая необходимость переезда для оптимизации костов, топ-менеджмент годами оплачивает невыгодные тарифы из-за страха потерять данные. Никто не хочет войти в историю как руководитель, при котором компания «легла» на неделю.</p> <p>А в секторах с высокой ценой ошибки (MedTech, FinTech) к этому добавляется комплаенс-ступор. Юристы и служба безопасности, опасаясь регуляторных штрафов за работу с данными или ИИ, превращаются в непроходимое «бутылочное горлышко», полностью парализуя гибкость разработки.</p> <h3>Процессные искажения</h3> <p>Как итог, ИТ-отдел деградирует до синдрома «фабрики фич». Инженеры механически перерабатывают тикеты в код, отвечая лишь за соблюдение дедлайна конкретной задачи. Ответственность за рыночный успех продукта размывается до нуля.</p> <p>Внедрение модных фреймворков не спасает, оборачиваясь карго-культом Agile. Компании тратят миллионы на коучей, но сохраняют директивную культуру. Синхронизации превращаются в ритуальные статус-репорты, реальные полномочия командам не отдаются, что рождает в коллективе лишь массовый цинизм.</p> <p>Вишенкой на торте становится культура «тушения пожаров». Системы поощрений часто выстроены так, что инженер, героически поднявший упавший сервер в ночь на воскресенье, получает премию и славу. При этом рутинная, системная работа по предотвращению таких инцидентов остается незамеченной. Команде становится репутационно невыгодно строить надежные системы — гораздо ярче выглядит эффектное спасение бизнеса от кризиса, который можно было не допускать.</p> <p>Боясь взять на себя осознанный технический долг, архитекторы закладывают решения для проверки простейшей гипотезы. Выжигаются бюджеты и время на запас прочности, который продукту пока объективно не нужен.</p> <p>Чтобы вернуть командам смелость брать на себя риски, бизнесу необходимо отказаться от иллюзии тотального контроля. Настоящая ответственность не прописывается в должностных инструкциях — она рождается там, где есть право на ошибку, прозрачная связь кода с деньгами и общая заинтересованность в конечном продукте. И пока корпорации не перестроят эту математику, их дорогие ИТ-отделы так и останутся блестящими исполнителями, избегающими любых смелых решений.</p> <p> #IMAGE_235166#</p> Бизнес требует прорывов, а технические команды уходят в глухую оборону, избегая любых рисков. Почему так происходит … article Борис Лопатухин, генеральный директор и сооснователь компании ЛЕГАЛТЭК https://www.itweek.ru/themes/detail.php?ID=235162 Mon, 13 Jul 2026 16:13:15 +0300 <p>Компания по кибербезопасности «АБП2Б» выпустила бета-версию 3.0.0 клиента для удаленного администрирования МС22. Главным изменением стал полный переход на новую архитектуру: приложение полностью переписали на языке Rust, отказавшись от прежней реализации на NodeJS.</p> <p>Переработка архитектуры позволила существенно сократить потребление системных ресурсов. Если в версии 2.x приложение в режиме ожидания занимало около 250 МБ оперативной памяти, то в версии 3.0 этот показатель снизился примерно до 50 МБ. По данным разработчиков, нагрузка при работе с 50 одновременными сессиями теперь сопоставима с работой около 10 сессий в предыдущей версии.</p> <p>МС22 предназначен для подключения к серверам, сетевому оборудованию и базам данных. Клиент работает под Windows, macOS и Linux и поддерживает SSH, Mosh, SFTP, Telnet, RDP и VNC (RFB).</p> <p>«Когда мы выпускали первую версию МС22 в 2023 году, основной задачей было предложить рынку отечественную альтернативу зарубежным решениям. По мере развития продукта мы поняли, что хотим не просто догнать существующие аналоги, а сделать клиент быстрее, стабильнее и функциональнее. На этом этапе стало очевидно, что прежняя архитектура начинает ограничивать дальнейшее развитие продукта. Поэтому мы приняли решение полностью переписать приложение, выбрав в качестве нового технологического стека Rust. Это позволило значительно снизить потребление ресурсов, устранить ряд технических ограничений предыдущей версии и создать архитектурную основу для дальнейшего развития МС22», — отметил технический директор компании «АБП2Б» Валерий Холоденко.</p> <p>Помимо повышения производительности, разработчики переработали реализацию протоколов RDP и VNC. В новой версии расширена совместимость с современными и устаревшими версиями Windows Server, а также появилась поддержка подключения через шлюзы RD Gateway.</p> <p>Изменения затронули и другие возможности приложения. В терминале появилась функция приостановки вывода данных и возможность открывать сессии в отдельных окнах. При передаче файлов по SFTP теперь отображается подробная информация о ходе копирования, включая скорость передачи, оставшееся время и прогресс выполнения операций.</p> <p>Для работы с базами данных в МС22 добавили SQL-редактор с контекстными подсказками, расширили возможности администрирования и доработали инструменты просмотра структуры данных.</p> <p>Одновременно с выходом версии 3.0 компания представила бесплатную редакцию МС22. Она позволяет хранить до пяти подключений и работать с двумя одновременными сессиями. Для протоколов RDP и VNC действует ограничение продолжительности подключения — до 30 минут. По оценке разработчиков, этого достаточно для обучения, домашнего использования и небольших организаций.</p> <p>Еще одним нововведением стала интеграция с платформой инвентаризации ИТ-инфраструктуры «ОдинХаб». После настройки пользователь может запускать подключение к оборудованию непосредственно из интерфейса платформы без ручного ввода параметров. Для интеграции с внешними системами также реализована поддержка глубоких ссылок формата mc22://.</p> <p>Версия 3.0.0 пока доступна в статусе бета. Разработчики отмечают, что продолжают тестирование отдельных сценариев работы и планируют оперативно выпускать обновления по мере получения обратной связи от пользователей.</p> Компания по кибербезопасности «АБП2Б» выпустила бета-версию 3.0.0 клиента для удаленного администрирования МС22. Главным … message https://www.itweek.ru/themes/detail.php?ID=235161 Mon, 13 Jul 2026 16:11:27 +0300 <p>Разработчик решений для кибербезопасности CICADA8 представил обновления для платформ External Threat Management (ETM) и Vulnerability Management (VM). Флагманские решения теперь поддерживают агент-серверную архитектуру и позволяют настроить ИИ-агентов для приоритизации уязвимостей. Кроме того, на платформе VM CICADA8 также будет доступен механизм ретроспективного анализа состояния хостов.</p> <p>Одно из ключевых нововведений для платформ CICADA8 ETM и VM — запуск агентов для конечных устройств. Они позволяют инвентаризировать хосты без учетных записей, сканировать порты удаленных сегментов сети и выстраивать цепочки туннелей к платформе, сохраняя весь объем функциональности в режимах «черного» и «белого ящиков». При этом они не используют много мощности: их размер 15 МБ с потреблением около 200 МБ оперативной памяти и <nobr>5–7%</nobr> одного ядра CPU.</p> <p>Второе обновление — облачные и on-premise ИИ-агенты, которые автоматически верифицируют и приоритезируют найденные уязвимости с учетом бизнес-контекста компании и особенностей ее инфраструктуры. С их помощью время на разбор и валидацию найденных уязвимостей значительно сокращается, а рутинная нагрузка на команду снижается. ИИ-агенты поддерживают как подключение к собственной <nobr>LLM-модели</nobr> заказчика, так и могут быть запущены в облаке CICADA8.</p> <p>Наконец, на платформе VM CICADA8 доступна функциональность для ретроспективного анализа и выявления аномалий в инфраструктуре. Решение фиксирует, как менялись Linux- и Windows-хосты с течением времени — какие службы, процессы и учетные записи добавлялись или удалялись. Команда по информационной безопасности сможет сравнивать состояния устройств в разные периоды, что упростит контроль за происходящим в инфраструктуре и сократит время на выявление аномалий и расследование инцидентов.</p> <p>«Изменения в продуктах направлены на то, чтобы сделать платформы CICADA8 не просто инструментом для сканирования, а полноценным интеллектуальным помощником, который берет на себя рутину и адаптирует возможности специалистов по безопасности под актуальные киберугрозы. Агенты в этой схеме обеспечивают покрытие удаленных и сегментированных участков сети, ИИ фильтрует шум сканирования и выделяет действительно критичные уязвимости. Поддержка историчности инвентаризации позволяет отследить изменения на хостах без сторонних систем. В дальнейшем функциональность ИИ-агентов расширится до генерации активных проверок „на лету“. В ближайших релизах CICADA8 ETM и VM также планируется запустить поддержку кластеров контейнеризации k3s и Kubernetes», — прокомментировал Кирилл Селезнев, руководитель продуктов ETM и VM CICADA8. </p> <p>Платформы CICADA8 ETM и VM работают в связке и обеспечивают комплексный контроль киберландшафта. CICADA8 ETM непрерывно мониторит внешний ИТ-периметр, выявляет уязвимости, ошибки конфигурации и потенциальные утечки данных, анализируя инфраструктуру так, как её видят злоумышленники. Дополнительно платформа защищает репутацию бренда — отслеживает фишинговые кампании, негативные упоминания в СМИ и факты продажи доступов на теневых форумах. </p> <p>Решение CICADA8 VM отвечает за внутренний контур: инвентаризирует активы, обнаруживает уязвимости, предлагает компенсирующие меры и контролирует их устранение, включая возможность проведения внешнего пентеста для проверки эффективности СЗИ. Платформа позволяет гибко выстраивать процесс управления уязвимостями и контролировать время их жизни по внутренним SLA в компании.</p> Разработчик решений для кибербезопасности CICADA8 представил обновления для платформ External Threat Management (ETM … message https://www.itweek.ru/themes/detail.php?ID=235159 Mon, 13 Jul 2026 16:10:33 +0300 <p>Российский разработчик ПО СберТех выпустил крупное обновление своего решения для многомерного анализа больших данных Platform V Analytics. Доработки существенно расширили его функциональность для крупного и среднего бизнеса. Теперь инструмент проще масштабируется, эффективнее работает с массивами информации, а также позволяет быстрее находить аномалии в данных и моделировать различные бизнес-сценарии.</p> <p>Одно из ключевых изменений связано с хранением информации. В обновленной версии продукта кубы данных и метаданные обрабатываются в облачных хранилищах формата S3 (Simple Storage Service), который является мировым стандартом надежных систем хранения. В S3 файлы хранятся как самостоятельные объекты, и каждый из них имеет несколько экземпляров. Это делает инфраструктуру более гибкой и устойчивой к изменениям, упрощает масштабирование за счет отделения хранения от вычислений и ускоряет перенос данных из тестовой в продуктивную среду без сложных миграций.</p> <p>Максим Тятюшев, генеральный директор СберТеха, отметил: «Обновленная версия Platform V Analytics позволит бизнесу заметно повысить гибкость и масштабируемость систем онлайн-аналитики. Мы расширили продукт современными инструментами для ежедневного анализа и планирования, которые помогают компаниям точнее оценивать различные сценарии развития, выявлять риски и точки роста, быстрее принимать решения и сохранять конкурентоспособность. Инструмент не только повышает надежность инфраструктуры благодаря распределенному хранению данных, но и способствует снижению затрат на этот процесс за счет использования реляционных СУБД. Все это делает Platform V Analytics эффективным решением для высоконагруженных аналитических систем и работы с огромными массивами информации».</p> <p>Platform V Analytics поддерживает полноценный многомерный анализ данных (OLAP) — технологию, которая позволяет быстро просматривать показатели с разных сторон, углубляться в детали и формировать общую картину для принятия обоснованных решений. Благодаря обновлению продукт теперь выполняет запросы напрямую в реляционной системе управления базами данных (СУБД) без предварительной агрегации информации. Решение работает с аналитическими СУБД, ядром которых являются высокопроизводительные колоночные базы данных ClickHouse. Это позволяет ИТ-директорам, руководителям аналитических направлений, а также бизнес-пользователям из отделов финансов, продаж и логистики быстро и гибко генерировать актуальные отчеты на основе больших массивов информации.</p> <p>С обновлением в продукте появился механизм условного форматирования отчетов, позволяющий автоматически применять правила подсветки и визуального выделения значений. Он ускоряет выявление отклонений и аномалий в данных, повышает наглядность и упрощает интерпретацию. Также в Platform V Analytics добавленa функция анализа «что если» для моделирования различных сценариев и влияния изменений на ключевые показатели без редактирования исходных данных.</p> Российский разработчик ПО СберТех выпустил крупное обновление своего решения для многомерного анализа больших данных … message https://www.itweek.ru/themes/detail.php?ID=235158 Mon, 13 Jul 2026 16:09:15 +0300 <p>Эксперты компании «Информзащита» выявили рост числа киберинцидентов, связанных с использованием legacy Windows в промышленных OT-средах. В первом полугодии 2026 года с такими инцидентами столкнулся 43% промышленных организаций, тогда как за аналогичный период 2025 года показатель составлял 35%. Рост на 8 процентных пунктов показывает, что устаревшие или ограниченно поддерживаемые Windows-системы остаются одной из наиболее проблемных зон промышленной инфраструктуре: они продолжают обслуживать технологические процессы, но все хуже соответствуют текущему уровню киберугроз.</p> <p>В промышленной среде legacy Windows часто сохраняется из-за зависимости от станков, контроллеров, HMI, SCADA, инженерных рабочих станций и специализированных приложений. Совместимость со старым оборудованием остается главным барьером для замены устаревших ОС, этот фактор отметили 54% организаций. Еще 38% указывают на высокую стоимость обновления, 35% — на риски простоя при модернизации, 21% — на недостаточную поддержку новых платформ со стороны поставщиков. Для OT-среды обновление операционной системы редко выглядит как штатная ИТ-процедура. Часто оно требует тестирования всей технологической цепочки, проверки драйверов, согласования с производством и поставщиками оборудования.</p> <p>Legacy Windows-системы создают риск именно потому, что одновременно нужны производству и плохо вписываются в актуальную модель угроз. На таких системах сложнее поддерживать регулярное обновление, не всегда корректно работают современные средства защиты, а вмешательство в конфигурацию может повлиять на устойчивость производственного процесса. В результате предприятие оказывается между двумя рисками: оставить устаревшую систему без достаточной защиты или внедрить защитные механизмы, которые могут конфликтовать с OT-приложениями. На это указывают и сами компании: 43% опасаются влияния средств безопасности на производительность, 39% — конфликтов с промышленными приложениями. Доля организаций, которым не хватает компетенций для настройки политик безопасности в OT, выросла с 13% в первом полугодии 2025 года до 18% в первом полугодии 2026 года.</p> <p>«В OT-контуре такая Windows-машина часто управляет конкретным участком производства и связана с оборудованием, драйверами, технологическими картами и подрядной поддержкой. Поэтому компании откладывают замену не из-за недооценки риска, а из-за страха нарушить процесс. Для злоумышленника это удобная ситуация, так как система продолжает работать в контуре, но ее защита ограничена, обновления нерегулярны, а доступ к ней может идти через инженерные станции, подрядчиков или слабо сегментированные участки сети», — отметил Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащита».</p> <p>По векторам атак картина типична для промышленной инфраструктуры. На первом месте находятся вредоносное ПО и вирусные заражения, их назвали ключевой угрозой 56% компаний. Несанкционированный доступ отметили 38% организаций, ransomware-атаки — 37%, отсутствие патчей и обновлений — 33%, инсайдерские угрозы — 22%. Для OT это особенно чувствительная комбинация. Вредоносное ПО может попасть в контур через инженерный ноутбук, подрядный доступ, съемный носитель или плохо изолированный корпоративный сегмент. Ransomware не обязательно должен атаковать контроллеры напрямую: достаточно вывести из строя операторские станции, серверы визуализации, архивы рецептур или инженерные рабочие места, чтобы предприятие столкнулось с остановкой участка, переходом на ручные процедуры или потерей управляемости процесса.</p> <p>Наиболее уязвимыми оказались отрасли с высокой долей непрерывного производства и большим числом специализированных систем. В пищевой промышленности с инцидентами, связанными с legacy Windows, столкнулись 70% организаций. Такой же показатель зафиксирован в полупроводниковом секторе — 70%. В энергетике доля пострадавших компаний составила 61%, в коммунальной инфраструктуре — 35%. Пищевая отрасль и полупроводниковое производство завязаны на технологические линии, где оборудование может эксплуатироваться десятилетиями, а модернизация требует длительных окон и сложного согласования. В энергетике риск усиливается распределенной архитектурой, подрядным обслуживанием и высокой ценой простоя. Коммунальный сектор показывает более низкий показатель, но для объектов водоснабжения, теплоснабжения и другой базовой инфраструктуры даже 35% остаются значимым уровнем риска.</p> <p>Эксперты «Информзащиты» связывают рост инцидентов с сочетанием нескольких факторов: длительным жизненным циклом промышленного оборудования, недостаточной сегментацией OT и ИТ-контуров, сохранением удаленного доступа для подрядчиков, слабым контролем съемных носителей и неполной инвентаризацией активов. Во многих организациях устаревшие рабочие станции остаются подключенными к сегментам, где уже действуют актуальные угрозы, но сами системы не рассчитаны на такой уровень воздействия. Проблему усиливает отсутствие единой картины по legacy-активам: часть машин известна только производственным службам, часть не попадает в стандартные ИТ-реестры, часть работает в изолированных участках и вспоминается только при инциденте или аварийном обслуживании.</p> <p>Снижать риски нужно с инвентаризации legacy Windows в OT-контуре и оценки их роли в технологическом процессе. Компания должна понимать, какие версии ОС используются, какие узлы критичны для производства, с какими системами они взаимодействуют и кто имеет к ним доступ. После этого необходимо отделить промышленные сегменты от корпоративной сети, ограничить прямые административные подключения, пересмотреть права подрядчиков, внедрить контроль удаленных сессий и журналирование действий. Для систем, которые нельзя обновить, нужны компенсирующие меры: виртуальный патчинг, контроль запуска приложений, мониторинг сетевого трафика, защита от съемных носителей, резервное копирование конфигураций HMI, SCADA и инженерных станций. Отдельно требуется проверить сценарии восстановления после ransomware: резервные копии должны быть изолированы, доступны для быстрого восстановления и защищены от удаления. Такой подход позволяет удерживать legacy Windows в производственном контуре без превращения устаревших систем в постоянный канал проникновения в OT-среду.</p> Эксперты компании «Информзащита» выявили рост числа киберинцидентов, связанных с использованием legacy Windows … message https://www.itweek.ru/themes/detail.php?ID=235157 Mon, 13 Jul 2026 16:06:51 +0300 <p>13 августа 2026 года в Москве состоится ежегодная бизнес-регата IT SAILING DAY 2026 — закрытое мероприятие для руководителей крупного бизнеса, ИТ- и ИБ-директоров, объединяющее деловую конференцию, экспертные дискуссии, профессиональный нетворкинг и командную регату на яхтах.</p> <p>Организатором мероприятия выступает DCLogic — системный интегратор с многолетним опытом реализации комплексных ИТ-проектов и разработки собственных технологических решений. В этом году мероприятие пройдет при поддержке российских ИТ-компаний OCS, NERPA, AXOFT, GigaCowork, БАЗИС и GMONIT.</p> <p>Участие в IT SAILING DAY 2026 бесплатное и осуществляется по предварительной регистрации. Количество мест ограничено.</p> <p>Почему стоит принять участие?</p> <ul> <li>разбираем реальные кейсы, обсуждаем инсайты и тренды ИТ-отрасли;</li> <li>приглашаем к участию ведущих экспертов и лидеров мнений ИТ-отрасли;</li> <li>привлекаем только крупный бизнес и компании с похожим профилем и задачами;</li> <li>формируем прочные дружеские отношения;</li> <li>вырабатываем совместный план действий для достижения общих интересов. </li> </ul> <p>IT SAILING DAY — это ежегодная встреча представителей крупного бизнеса, ведущих российских разработчиков и производителей ИТ-решений и отраслевых экспертов. Мероприятие объединяет профессионалов, которые определяют развитие корпоративных информационных технологий, обсуждают актуальные вызовы и риски рынка, искусственный интеллект и обмениваются практическим опытом реализации масштабных ИТ-проектов.</p> <p>В программе — выступления ведущих экспертов отрасли, панельная дискуссия, посвященная вопросам повышения эффективности бизнеса, профессиональный нетворкинг и командная парусная регата.</p> <p>Центральная тема деловой программы — панельная дискуссия «Оптимизация vs рост: как enterprise-компаниям сокращать расходы без потери эффективности».</p> <p>Модератором дискуссии выступит Сергей Козырь, CEO Digital Advisers, эксперт в области информационных технологий с <nobr>18-летним</nobr> опытом работы на высших руководящих позициях в российских и международных компаниях — лидерах индустрии розничной торговли.</p> <p>Можно ли одновременно снижать затраты и ускорять развитие бизнеса? Сегодня ответ на этот вопрос все чаще связан не с сокращением ресурсов, а с интеллектуальной трансформацией процессов, внедрением искусственного интеллекта и эффективным использованием современных цифровых технологий.</p> <p>В ходе панельной дискуссии ведущие эксперты ИТ-рынка обсудят, как использовать ИИ и современные цифровые инструменты для повышения производительности, оптимизации операционных расходов и масштабирования бизнеса без ущерба для качества и устойчивости процессов.</p> <p>Участники рассмотрят практические кейсы реализации проектов в крупных компаниях, обменяются опытом применения технологий искусственного интеллекта и обсудят новые подходы к повышению эффективности корпоративной ИТ-инфраструктуры.</p> <p>Ключевые вопросы дискуссии:</p> <ul> <li>Как использовать ИИ для повышения эффективности бизнеса уже сегодня?</li> <li>Какие процессы дают наибольший эффект при автоматизации?</li> <li>Где проходит граница между разумной оптимизацией затрат и риском замедления развития компании?</li> <li>Какие цифровые инструменты помогают одновременно сокращать расходы и создавать основу для дальнейшего роста?</li> </ul> <p>Партнерами IT SAILING DAY 2026 выступают ведущие российские разработчики и поставщики ИТ-решений:</p> <ul> <li>OCS — один из крупнейших ИТ-дистрибьюторов с портфелем сервисов и 20 офисами по всей России;</li> <li>NERPA — российский бренд ИТ-продукции, объединяющий собственное производство высокотехнологичного ИТ-оборудования и целый комплекс производственных услуг;</li> <li>AXOFT — центр экспертизы и дистрибуции цифровых технологий, представленный в 8 странах мира — работает на ИТ-рынке с 2004 года;</li> <li>GigaCowork — платформа для создания и управления ИИ-агентами для всей компании. Внедряется без разработки и перестройки внутренних ИТ-систем, соответствует 152 ФЗ;</li> <li>БАЗИС — крупнейший российский разработчик ПО управления динамической ИТ-инфраструктурой, виртуальных рабочих мест и оказания облачных услуг;</li> <li>GMONIT — российская платформа наблюдаемости (Observability), которая помогает обеспечивать стабильную работу цифровых сервисов.</li> </ul> <p>Совместно с партнерами мы подготовили насыщенную программу, посвященную современным технологиям, импортонезависимым решениям и практическому опыту цифровой трансформации предприятий.</p> <p>После завершения деловой программы участников ждет командная регата на современных парусных яхтах под руководством профессиональных шкиперов. Это отличная возможность проявить командный дух, получить новые впечатления и продолжить общение с коллегами в неформальной атмосфере. Гости, которые не планируют выходить на воду, смогут провести время в комфортной зоне отдыха, наслаждаясь живописными видами, неформальным общением и деловым нетворкингом.</p> <p>На протяжении всего мероприятия участников ожидают:</p> <ul> <li>первоклассный сервис;</li> <li>полноценное питание и напитки;</li> <li>профессиональное сопровождение регаты;</li> <li>комфортные условия для общения, обмена опытом и новых деловых знакомств.</li> </ul> <p>Бизнес-регата пройдет на территории «Берёзы Парк. Строгино» — современной площадке на берегу Строгинского затона, сочетающей атмосферу отдыха на природе и удобную транспортную доступность. Адрес: Москва, Строгинское шоссе, владение 1А.</p> <p>IT SAILING DAY 2026 ориентирован на представителей крупного бизнеса:</p> <ul> <li>собственников компаний;</li> <li>генеральных директоров;</li> <li>ИТ-директоров;</li> <li>директоров по информационной безопасности;</li> <li>руководителей цифровой трансформации;</li> <li>руководителей ИТ-подразделений промышленных предприятий и корпоративного сектора.</li> </ul> <p>Участие в IT SAILING DAY 2026 осуществляется по предварительной регистрации.</p> <p>Для подачи заявки перейдите по <a href="https://invite.dclogic.ru/itsailingday2026?utm_source=itweek_news&utm_medium=site&utm_campaign=post_006">ссылке</a> и заполните регистрационную форму. Каждая заявка проходит модерацию организаторами.</p> <p>Участие бесплатное. Количество мест ограничено.</p> <p>IT SAILING DAY 2026 — это возможность за один день получить актуальную отраслевую экспертизу, познакомиться с опытом ведущих российских ИТ-компаний, обсудить практические вопросы цифровой трансформации с коллегами и экспертами рынка, а также провести время в уникальной атмосфере командного единства. Если вы отвечаете за развитие ИТ в компании и ищете новые идеи для повышения эффективности бизнеса, это мероприятие станет отличной площадкой для профессионального общения и обмена опытом.</p> 13 августа 2026 года в Москве состоится ежегодная бизнес-регата IT SAILING DAY 2026 — закрытое мероприятие … message https://www.itweek.ru/themes/detail.php?ID=235153 Mon, 13 Jul 2026 09:53:01 +0300 <p><em>Разработчики создают приложения искусственного интеллекта с головокружительной скоростью, но у большинства организаций нет инфраструктуры или операционных возможностей для их внедрения в производство. По мнению Филипа Меррика, соучредителя, директора по продуктам и председателя pgEdge, в значительной степени в неудачах ИИ-проектов виновата инфраструктура данных, сообщает портал The New Stack.</em></p> <p>Скептики любят критиковать технологию ИИ за неспособность приносить значимые бизнес-результаты, часто ссылаясь на исследования, подобные <a href="https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf">исследованию</a> MIT NANDA, которое показало 95%-ный уровень неудач корпоративных решений в области ИИ, или на <a href="https://www.idc.com/resource-center/blog/most-ai-investments-dont-deliver-value-heres-what-emea-leaders-are-missing/">исследование</a> IDC, в котором говорится, что «только 9% организаций [в Европе, на Ближнем Востоке и в Африке] смогли добиться измеримых бизнес-результатов от большинства своих проектов, связанных с ИИ, за последние два года».</p> <p>Многие ИИ-скептики не учитывают экспериментальный характер прототипов ИИ; не все эти проекты предназначены для дальнейшего развития после этапа тестирования. Тем не менее, 5% успеха — это позор.</p> <p>В чем загвоздка?</p> <p>Две вещи. Во-первых, большинство организаций создают прототипы ИИ «на песке»; то есть, инфраструктура данных, на которой они создают ранние приложения, не может поддерживать последующий переход к производству. В то же время операционным командам, ответственным за управление этими приложениями в производстве, часто не хватает человеческих ресурсов, чтобы справиться с растущим объемом работы инженеров.</p> <h3>Четыре причины, почему инфраструктура прототипирования ≠ производственная инфраструктура</h3> <p>На вопрос о том, почему так много прототипов ИИ не доходят до производства, Филип Меррик отвечает, что в значительной степени виновата инфраструктура данных. В частности, он объясняет, что среды прототипирования не соответствуют требованиям крупных предприятий к производству, называя четыре основных причины их недостатков.</p> <p>Во-первых, средам прототипирования не хватает гибкости развертывания, необходимой организациям для перехода от прототипа к производству.</p> <p>Меррик признает, что управляемые поставщиками облачные платформы могут показаться очевидным выбором для прототипирования, поскольку они позволяют командам быстро начать работу. Тем не менее, он предупреждает, что им не хватает технических возможностей для поддержки приложений ИИ в производстве, особенно в областях безопасности, соответствия нормативным требованиям и управления. В частности, для организаций в сфере здравоохранения, финансов или других регулируемых отраслей, управляемые облачные платформы часто не обладают тем строгим уровнем контролем, который присутствует в самоуправляемых облачных или локальных средах.</p> <p>Таким образом, гибкость и безопасность идут рука об руку, утверждает Меррик: «Вы должны иметь возможность выбирать, каким образом в конечном итоге прототип ИИ будет внедрен в производство».</p> <p>Он отмечает, что когда приходит время перехода к производству, управляемые облачные платформы могут создавать проблемы суверенитета данных как на уровне предприятия, так и на региональном уровне. По его словам, среды, которые большинство команд используют для создания прототипов, недостаточно прозрачны: «Если это платформа, управляемая поставщиком, и никто не знает, в каком облаке и в каком регионе она находится, то вы теряете контроль над данными».</p> <p>Наконец, Меррик обращает внимание на надежность, объясняя, что прототипы ИИ не могут быть внедрены в производство без гарантии высокой доступности. Например, когда приходит время обновить базу данных или заменить оборудование, можно ли это сделать без простоя?</p> <p>«В мире облачных решений, управляемых поставщиками, ответ на этот вопрос почти всегда отрицательный», — говорит Меррик, акцентируя внимание на том, что для перехода приложений ИИ от прототипа к производству требуется инфраструктура корпоративного уровня.</p> <h3>Так почему же разработчики создают прототипы там, где они не могут внедрить их в производство?</h3> <p>Если именно выбор инфраструктуры данных мешает разработчикам перевести прототипы ИИ в производство, то почему они постоянно начинают с неправильного подхода?</p> <p>Как объясняет Меррик, многих привлекает простота использования управляемых облачных платформ: «Эти среды для прототипирования, безусловно, значительно упрощают начало работы». Но, похоже, упрощение прототипирования не окупается в долгосрочной перспективе, поскольку в конечном итоге ответственность за подготовку этих прототипов к производству ложится на кого-то другого.</p> <p>Тем не менее, Меррик не винит разработчиков за поиск лёгкого пути. Скорее, он говорит о разрыве между площадкой для прототипирования и полем битвы за производство, который мешает разработчикам понять, что потребуется для внедрения прототипов в производство в будущем.</p> <p>По его словам, много лет назад решения о выборе инструментов принимались преимущественно сверху вниз, без участия разработчиков: «Затем, где-то <nobr>15-20</nobr> лет назад, разработчики совершенно справедливо вернули себе право выбора собственных инструментов».</p> <p>Проблема сейчас, утверждает Меррик, заключается в том, что разработчики принимают решения о выборе инструментов исключительно для прототипирования, не предвидя потребностей производства. Внутреннее разделение означает, что разработчики часто отвечают только за создание прототипов, прежде чем передать эстафету совершенно отдельной операционной команде: «В итоге, в некоторых организациях отсутствует сквозная цепочка понимания производственных требований начиная с момента принятия разработчиком первоначального решения».</p> <p>Для Меррика именно этот разрыв является причиной сбоев ИИ-проектов, поскольку командам приходится пытаться перенести прототипы ИИ с доступных, но неадекватных управляемых облачных платформ на корпоративную инфраструктуру данных, отвечающую требованиям гибкости развертывания, безопасности, суверенитета данных и высокой доступности.</p> <p>«Но если вы сделаете правильный выбор инфраструктуры данных, этого несоответствия не будет, — говорит он, — потому что у вас будет сквозная связь от прототипа до производства».</p> <p>Меррик считает Postgres инфраструктурой данных, которая лучше всего помогает разработчикам преодолеть этот разрыв, называя её «швейцарским армейским ножом среди баз данных» из-за её расширяемости, полностью открытого исходного кода и способности решать разнообразные задачи управления данными, от неструктурированных данных до векторных представлений и геопространственных данных.</p> <p>Место и способ запуска Postgres также имеют значение, отмечает он, снова обращая внимание на ограничения многих управляемых поставщиками облачных сред, которым часто не хватает механизмов управления для удовлетворения требований к данным и/или гибкости развертывания для перехода к соответствующим требованиям локальных или собственных облачных сред.</p> <h3>Но выбор правильной инфраструктуры данных решает только половину проблемы</h3> <p>Меррик говорит, что есть еще одна часть уравнения, которую большинство организаций упускают из виду: люди, а точнее, администраторы баз данных (DBA) и их растущая рабочая нагрузка.</p> <p>Согласно <a href="https://survey.stackoverflow.co/2025">опросу</a> Stack Overflow «2025 Developer Survey», инструменты ИИ используют 84% респондентов, по сравнению с 76% годом ранее. Между тем, Supabase <a href="https://techcrunch.com/2026/06/05/supabase-doubles-valuation-to-10b-in-8-months/?utm_source=chatgpt.com">утверждает</a>, что более 60% баз данных на ее платформе были запущены «с помощью какого-либо инструмента ИИ». Как отмечает Меррик, этот взрывной рост производительности имеет свою загвоздку: администраторов баз данных недостаточно, чтобы справиться с этим.</p> <p>«Произошел колоссальный, гигантский скачок в производительности разработчиков, — объясняет он. — Но вам нужен какой-то способ управления этим на стороне производства; эти базы данных не могут оставаться без мониторинга». По его словам, команды эксплуатации и администрирования уже испытывали трудности с отслеживанием существующих баз данных Postgres до того, как внедрение агентной инженерии усугубило ситуацию: «Кто будет ими управлять?». Он говорит, что настало время для того, чтобы агентные операции догнали агентный инжиниринг.</p> <h3>ИИ-агенты DBA могут наделить людей «сверхспособностями»</h3> <p>Может показаться, что Меррик предлагает организациям использовать полностью автономных агентов DBA для управления базами данных, но он говорит, что отрасль еще не готова: «Мир не готов к полностью автономным базам данных, управляемым ИИ-агентами DBA. Однако существует огромная нехватка ресурсов и проблема производительности, а DBA могут управлять лишь ограниченным количеством баз данных», — объясняет он. Между тем, новые «приложения ИИ требуют гораздо большего количества баз данных в производстве».</p> <p>Итак, как организации могут увеличить свои операционные возможности?</p> <p>Меррик говорит, что администраторам баз данных следует обратить внимание на новых ИИ-агентов DBA не для того, чтобы они взяли на себя управление, а для того, чтобы они наделили их «сверхспособностями» для мониторинга и управления бóльшим количеством баз данных с меньшим количеством ручной работы.</p> <p>Таким образом, ИИ-агенты DBA должны повысить эффективность работы операционных команд, которые, по мнению Меррика, остро нуждаются в экспертных знаниях в области администрирования баз данных. В подтверждение его слов некоторые отраслевые прогнозы говорят о том, что 41% современных специалистов по базам данных намерены покинуть отрасль в течение следующего десятилетия, половина из них уйдет на пенсию, а остальные будут искать другую работу.</p> <p>Меррик утверждает, что без агентов ИИ работа DBA останется утомительной, трудоемкой и отнимающей много времени. Как он объясняет, база данных может работать отлично, но когда возникает проблема, она может затронуть множество приложений; тогда DBA приходится просматривать данные мониторинга, чтобы выявить и диагностировать проблему, по сути, ища иголку в стоге сена.</p> <p>«Агент, — говорит Меррик, — может реагировать на эти оповещения гораздо быстрее и продуктивнее, чем человек».</p> <h3>Инфраструктура и люди: для повышения успешности прототипов ИИ нужны обе стороны</h3> <p>Почти в любом контексте ИИ поднимает вопросы о качестве, а не о количестве, и корпоративные ИИ-проекты не являются исключением. Агентная инженерия означает, что разработчики теперь могут создавать больше, но все эти прототипы не попадают прямиком в производство. Ограничения как в инфраструктуре, так и в операционной рабочей силе создают препятствия, из-за которых многие прототипы ИИ терпят неудачу.</p> <p>По мнению Меррика облегчение перехода от прототипа к производству требует не только отличных инструментов ИИ, но и готовой к производству инфраструктуры данных в сочетании с агентными операциями, способными идти в ногу с бумом агентного инжиниринга.</p> Разработчики создают приложения искусственного интеллекта с головокружительной скоростью, но у большинства … article https://www.itweek.ru/themes/detail.php?ID=235151 Mon, 13 Jul 2026 09:34:23 +0300 <p><em>Курс на импортозамещение в России был задан еще в 2014 году, но тогда он практически не повлиял на ИТ-рынок. Реальные изменения произошли уже после <nobr>2022-го,</nobr> когда иностранные вендоры стали массово уходить с рынка и ограничивать доступ к своим продуктам. Это затронуло все направления в индустрии, включая балансировщики трафика. В этой статье </em><em>мы обсудим </em><em>промежуточные итоги перестройки российского рынка балансировщиков трафика.</em></p> <h3>Немного истории: с чего начиналась перестройка рынка</h3> <p>В <nobr>2022-2024</nobr> годах балансировщики трафика на российском рынке практически не импортозамещались. Крупные компании заменяли ранее используемые решения на китайские и пытались создавать кастомные для удовлетворения собственных запросов. Однако именно готовых и зрелых решений, как от F5 и Citrix, не было. Основное внимание уделялось другим системам: АБС, СУБД, ДБО и антифрод-системам. Такая ситуация была обусловлена тремя ключевыми факторами:</p> <ul> <li><strong>Заимствованные запросы рынка</strong>. Корпоративные клиенты требовали продукт формата «все, как в F5, но российское». Они не понимали специфику российского рынка, собственные запросы и текущие возможности вендоров. Бизнес просто копировал спецификации западных продуктов.</li> <li> <strong>Сложность разработки ПО</strong>. Балансировщики трафика должны соответствовать множеству требований: высокая отказоустойчивость, эффективные алгоритмы распределения, учет динамических факторов, безопасность, возможность интеграции с другим инфраструктурным ПО и т. д. Западные вендоры развивали свои продукты десятилетиями и путем проб и ошибок создавали качественные решения.</li> <li> <strong>Отсутствие экспертизы</strong>. Российские компании долгие годы полагались на готовые импортные решения, поэтому в стране практически не осталось специалистов, способных создавать и развивать балансировщики трафика с нуля.</li> </ul> <p>Кроме того, важно учитывать, что балансировщики используются преимущественно крупным бизнесом — банками, телеком-компаниями и т. д. В кризисном 2022 году эти организации в первую очередь замещали критически важное ПО: офисные пакеты, операционные системы и сервисы для управления базами данных. Спрос на российские продукты из этих сфер вырос на 300% по сравнению с 2021 годом. И только после закрытия базовых потребностей сформировался запрос на инфраструктурное ПО.</p> <h3>Как происходило изменение рынка балансировщиков трафика</h3> <p>В <nobr>2024-2025</nobr> годах рынок балансировщиков трафика стал более зрелым. Компании начали разбираться в том, что им нужно, а не просто копировать спецификации западных продуктов. Кроме того, в России сформировался устойчивый спрос на такое инфраструктурное ПО. Это обусловлено увеличением нагрузки на системы (в том числе из-за ИИ) и появлением новых типов угроз для кибербезопасности, которые стали проблемой в <nobr>2023-2024 годах.</nobr></p> <p>В ходе исследования рынка и опроса клиентов мы выявили изменение требований к балансировщикам. У бизнеса появился спрос на централизованное управление, удобный API, возможность быстрого восстановления и отката конфигураций, быстрое горизонтальное и вертикальное масштабирование и гибкие системы лицензирования. Для бизнеса важнее стала окупаемость самих решений и удобство в эксплуатации, не требующие узкопрофильных специалистов.</p> <p>Компании нуждаются в гибких решениях, которые не ограничивают их в развитии. Клиенты хотят внедрять искусственный интеллект, увеличивать количество пользователей и подключать новые компоненты без радикальной перестройки всей сетевой инфраструктуры. </p> <h3>Как тренды меняют требования к балансировщикам трафика</h3> <p>Анализ клиентских запросов показывает, что за последние два года профиль требований к балансировщикам трафика существенно изменился. Современный продукт должен отвечать как минимум четырем критериям.</p> <ul> <li><strong>Гибкость.</strong> ПО обязано поддерживать несколько профилей нагрузки и позволять оперативно добавлять новые сценарии работы или модифицировать существующие без перепроектирования всей системы.</li> <li><strong>Высокая скорость изменений</strong>. Этот показатель зачастую перевешивает «чистую» производительность в RPS и предельное количество конкурентных пользователей. Бизнес готов жертвовать пиковыми мощностями в пользу возможности быстро адаптировать балансировку под меняющиеся условия.</li> <li><strong>Простота в эксплуатации</strong>. Бизнес начал отдавать предпочтение удобным и понятным продуктам, которые инженер способен освоить за считанные недели или даже дни, а не за годы. Спрос же на функциональные, но сложные «комбайны» не растет.</li> </ul> <h3>Отказ от ПАК</h3> <p>На российском рынке растет интерес к виртуальным и программным решениям, заменяющим традиционные программно-аппаратные комплексы. В условиях сложившегося кризиса бизнес ищет способы сократить CapEx, оптимизировать расходы на обслуживание нового ПО и получить возможность гибко масштабировать инфраструктуру. При этом ПАК все еще остаются актуальными из-за больших запасов старого оборудования на складах, которое бизнес пока не готов списывать. Его можно использовать в качестве запасных мощностей для масштабирования балансировки. Однако для критичных сервисов старое «железо» не подходит из-за своих ограничений, которых нет у современных решений.</p> <h3>Заключение</h3> <p>Российский рынок балансировщиков трафика за <nobr>2022-2025</nobr> годы прошёл путь от пассивного копирования западных спецификаций до формирования зрелого спроса на гибкие, программные решения. Бизнес перестал требовать «аналогов F5» и сосредоточился на простоте эксплуатации, централизованном управлении и окупаемости. Уход ПАК-подхода и рост интереса к виртуальным продуктам подтверждают смену парадигмы. Перестройка рынка продолжается, но ее главный итог уже ясен: будущее за адаптивными, программно-ориентированными решениями, а не за «железными» монолитами прошлого.</p> <p>#IMAGE_235152#</p> Курс на импортозамещение в России был задан еще в 2014 году, но тогда он практически … article Алексей Лобачёв, основатель компании “5А” https://www.itweek.ru/themes/detail.php?ID=235149 Fri, 10 Jul 2026 16:28:02 +0300 <p>В 2026 году все чаще решающим фактором при выборе облачного провайдера становится не только вычислительные мощности, SLA и ценовые модели, но места хранения данных. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что бизнес при выборе облака все чаще опирается на принципы Data Gravity (гравитации данных): чем больше данных накоплено в определенной точке, тем сильнее она притягивает к себе приложения, сервисы и аналитику, и тем дороже обходится перемещение этих данных в другое место.</p> <p>По данным IDC Global DataSphere, глобальный объем создаваемых данных достиг около 181 зеттабайта в 2025 году и утроится к 2029 году. Корпоративные данные растут еще быстрее: согласно исследованию Digital Realty Data Gravity Index 2.0, объем генерируемых предприятиями данных достиг 1,2 млн эксабайт в 2025 году, причем они будут сосредоточены в крупных городах с развитой ЦОД-инфраструктурой. Для российского рынка это означает, что московский и петербургский кластеры ЦОД концентрируют подавляющую часть корпоративных данных страны, и эта концентрация будет только усиливаться.</p> <p>Когда компания накапливает десятки и сотни терабайт в одном облаке — CRM-данные, логи транзакций, обучающие датасеты для ИИ-моделей, архивы документов — перенос этого массива в другое облако становится не только технической задачей, но и экономической. Физическая передача петабайта данных по каналу 10 Гбит/с занимает около 9 суток непрерывной работы — без учета верификации, перенастройки приложений и возможного простоя бизнес-процессов.</p> <p>По данным Gartner, расходы на вывод данных из облака (egress fees) составляют от 10% до 15% совокупного облачного бюджета компании. Это объективная реальность цифровой экономики. Ответственные провайдеры выстраивать архитектуру, при которой заказчик получает максимум ценности именно там, где лежат его данные.</p> <p>Зрелый подход к управлению Data Gravity предполагает не складирование всех данных в единое хранилище, а осознанное распределение по специализированным кластерам. Горячие данные — транзакции, аналитика в реальном времени, инференс ИИ-моделей — требуют низкой латентности и размещаются на высокопроизводительных кластерах вблизи вычислительных мощностей. Теплые данные — исторические выборки, датасеты для периодического дообучения моделей — хранятся на более экономичных кластерах с балансом между скоростью доступа и стоимостью. Холодные данные — архивы, бэкапы, регуляторные копии — размещаются в хранилищах с минимальной стоимостью за гигабайт.</p> <p>Такая архитектура решает сразу несколько задач. Во-первых, она оптимизирует затраты: нет смысла хранить архив за 5 лет на том же оборудовании, что и, например, данные для real-time fraud detection (обнаружения мошенничества в реальном времени). Во-вторых, она минимизирует внутренний трафик: приложения работают рядом с теми данными, которые им нужны, без необходимости перекачивать массивы между площадками. В-третьих, она упрощает комплаенс: персональные данные можно физически изолировать в отдельном сегменте с усиленным контролем доступа, не затрагивая остальную инфраструктуру.</p> <p>Особенно остро эффект Data Gravity проявляется в проектах с искусственным интеллектом. Обучение и дообучение моделей требует доступа к огромным массивам данных — и перемещать эти массивы к модели экономически бессмысленно. Логика меняется: не данные перемещаются к вычислениям, а вычисления разворачиваются там, где лежат данные. Провайдер разворачивает GPU-кластеры в непосредственной близости от хранилищ данных, обеспечивая высокоскоростную внутреннюю связность.</p> <p>Компания, которая хранит у провайдера свои корпоративные данные, получает естественное преимущество при запуске ИИ-проектов: данные уже на месте, латентность минимальна, egress-расходы отсутствуют. Это создает эффект платформенной экосистемы, где каждый новый сервис — будь то <nobr>ML-пайплайн,</nobr> аналитическая витрина или система мониторинга — органично встраивается в существующую инфраструктуру.</p> <p>Data Gravity меняет саму природу отношений между заказчиком и провайдером. Если раньше облако воспринималось как утилита — арендовал, использовал, при необходимости сменил — то сегодня провайдер, хранящий критические данные бизнеса, становится стратегическим партнером. Соответственно, провайдер должен обеспечивать сохранность и доступность данных, а также возможность наращивать вокруг них новые сервисы без миграции.</p> <p>Для российского рынка эффект Data Gravity будет усиливаться с каждым годом. Компании, которые сегодня осознанно выбирают провайдера по архитектуре хранения, внутренней связности, возможности масштабирования без перемещения — получат долгосрочное преимущество. Потому что в мире, где данных становится экспоненциально больше, выигрывает тот, кто умеет извлекать из них ценность на месте.</p> В 2026 году все чаще решающим фактором при выборе облачного провайдера становится не только вычислительные мощности … message https://www.itweek.ru/themes/detail.php?ID=235147 Fri, 10 Jul 2026 10:10:16 +0300 <p><em>Агенты искусственного интеллекта терпят неудачу, когда упускают из виду «невидимые данные». Нитин Сингхал, вице-президент по инжинирингу данных и монетизации компании GitLab, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, почему необходимо фиксировать институциональную логику, лежащую в основе решений, прежде чем она исчезнет.</em></p> <p>При создании платформ данных для крупных организаций решения часто принимаются на основании того, что видим, игнорируя слепые зоны, или то, что мы называем «невидимыми данными», которые могут быть опаснее, чем плохие данные. Эти невидимые данные включают исключения, согласования, контекст, недокументированные институциональные знания, межсистемные синтезы и решения, которые помогают вести бизнес, но редко попадают в какую-либо систему.</p> <p>Я наблюдал этот шаблон во всех отраслях, в которых работал. Моя команда в одной крупной компании социальных сетей провела аудит метаданных, который показал, что большинство производственных наборов данных были «осиротевшими», не имеющими принадлежности или избыточными. Ни у кого не было достоверного подсчета работающих API. Традиционные инструменты каталогизации предоставляли устаревшие метаданные по мере их поступления. Чтобы решить эту проблему, мы с нуля создали коннекторы на основе графов, сшили воедино цепочки активов и вернули сотни миллионов долларов экономии.</p> <p>Но даже после того, как мы решили проблему видимости структурированных данных, мы продолжили сталкиваться с той же проблемой: логику, лежащую в основе данных, нельзя было найти нигде в системе.</p> <p>В течение десятилетий потеря этой логики была приемлемой ценой. Команды могли восстановить ее благодаря опыту и адаптации сотрудников. Однако решения становились непоследовательными, и эта непоследовательность оставалась невидимой. Теперь ИИ-агенты выявляют эти несоответствия.</p> <h3>Стена, в которую утыкается каждый агент</h3> <p>Рассмотрим, что происходит, когда ИИ-агент, обрабатывающий продление договора с клиентом, должен решить, одобрить ли 20%-ную скидку, даже если политика ограничивает скидку при продлении 10%. Хорошо оснащенный агент может получить данные о доходах клиента из CRM, проверить открытые заявки в службу поддержки, просмотреть недавние инциденты и оценить соответствующий документ политики. Это видимый слой.</p> <p>При этом система не может получить доступ к логике, которая хранится в головах людей, достаточно долго занимающихся этой работой, чтобы аккумулировать её, историю исключений из правила дисконтирования и незадокументированные изменения в принятии решений после реорганизации.</p> <p>Без этой логики агент принимает неверное решение, передает дело человеку, который восстанавливает ту же логику с нуля, или жестко применяет приписанную политику в ситуациях, которые организация всегда разрешала взвешенно. Все три варианта являются неудачами, и они усугубляются в больших масштабах.</p> <h3>Почему действующие игроки рынка не могут закрыть этот пробел</h3> <p>Описанная проблема носит архитектурный характер, а не является продуктовым пробелом, который любой поставщик может закрыть с помощью пункта дорожной карты.</p> <p>Операционные системы учета — CRM, ERP и HRIS — сохраняют текущее состояние. Когда исключение утверждается, контекст, который его обосновывал, исчезает. Вы можете видеть, что скидка изменилась, но вы не можете воспроизвести состояние мира в момент, когда кто-то совершил звонок, запросил скидку или использовал ее в качестве прецедента для будущих обоснований.</p> <p>Платформы данных сталкиваются с другой проблемой. Они получают данные через конвейеры извлечения, преобразования и загрузки (ETL) после того, как решения уже были приняты. К тому моменту, когда запись попадает в хранилище, контекст рассуждений уже исчезает. Эти платформы могут показать вам историю, но не причинно-следственную связь.</p> <p>Каждый крупный поставщик ПО теперь создает агентные возможности, эти агенты хорошо работают в рамках своих собственных системных границ, но они наследуют ограничения родительской системы. Агент CRM не видит инфраструктурный инцидент в системе мониторинга. Агент платформы поддержки не видит сигнал об оттоке клиентов, скрытый во внутренней цепочке. Межсистемный синтез, который опытные люди выполняют инстинктивно, остается невидимым для любого агента, ограниченного периметром одного поставщика.</p> <h3>Отсутствующее измерение</h3> <p>Большинство корпоративных систем управления знаниями отслеживают, какие сущности существуют, как они связаны друг с другом и как их состояния меняются со временем.</p> <p>Четвертое измерение практически повсеместно отсутствует: события принятия решений или структурированные записи моментов, когда организационная логика превратила контекст в действие. Большинство команд не записывают, какие факторы привели к принятию решения, какая версия политики применялась или какие условия устанавливал утверждающий.</p> <p>Эти рассуждения растворяются в чатах Slack, во время звонков и в ходе вводных бесед с сотрудниками, которые в конечном итоге увольняются. До появления агентов это была управляемая потеря. Опытный сотрудник мог восстановить рассуждения по памяти и на основе связей.</p> <p>В среде, управляемой агентами, этот пробел становится критически важным. Агентам необходимо понимать не только то, что прописано в политике, но и то, как организация исторически решала эти вопросы на практике. Только живая, доступная для запросов запись обоснований организационных решений, зафиксированных в момент их принятия, делает это возможным.</p> <p>Аргументы в пользу создания этого уровня становятся все сильнее с каждым решением, принимаемым организацией. Каждая зафиксированная траектория решения становится доступным для поиска прецедентом. Каждое исключение калибрует будущую маршрутизацию исключений. Организационные знания, которые ранее уходили вместе с увольняющимися сотрудниками, становятся долгосрочным ресурсом, который сохраняется после реструктуризаций и поглощений.</p> <h3>Что со всем этим делать?</h3> <p>Архитектурное ограничение не требует ожидания решения от поставщика. Следующие пять практик помогут постепенно создать недостающий уровень, не заменяя существующую инфраструктуру.</p> <ul> <li><strong>Проведите аудит вашей поверхности обработки исключений.</strong> Составьте карту решений, принимаемых вашей организацией, которые не полностью объясняются в письменной политике: исключения в ценообразовании, отмена утверждений, исключения из требований комплаенса. Именно в этих областях агенты будут терпеть неудачу в первую очередь. Расставьте приоритеты для фиксации, а не пытайтесь зафиксировать все сразу.</li> <li><strong>Инструментируйте путь выполнения, а не только результат.</strong> Большинство журналов фиксируют то, что произошло. Для фиксации решений также необходимо записывать причины, включая то, какие входные данные были учтены, какая версия политики была применена, кто одобрил и какие условия были установлены. Перед развертыванием агентов в последовательных рабочих процессах добавьте в них структурированную выдачу событий.</li> <li><strong>Оценивайте поставщиков с точки зрения межсистемного мышления.</strong> При оценке платформ агентов задавайте конкретный вопрос о том, как они обрабатывают решения, требующие контекста из нескольких систем. Если ответ полностью зависит от предварительно созданных интеграций или единой модели данных, структурный пробел проявится как сбой в производстве.</li> <li><strong>Начните с высокочастотных потоков высокой важности.</strong> Продление контрактов с клиентами, проверка исключений безопасности, эскалация инцидентов и одобрение поставщиков — это хорошие отправные точки. Они происходят достаточно часто, чтобы быстро создать значимый корпус прецедентов, и ошибки агентов здесь приводят к реальным затратам.</li> <li><strong>Разрабатывайте систему так, чтобы она обеспечивала воспроизводимость, а не только извлечение данных.</strong> Полезная запись о принятом решении — это структурированный артефакт, который команды могут запрашивать, сравнивать с предыдущими решениями и использовать для проверки того, соответствует ли предлагаемое действие актуальному поведению организации.</li> </ul> <h3>Заключение</h3> <p>Агенты рассуждают на основе того, что явно доступно во время выполнения, в масштабе и со скоростью, недоступными ни одному механизму передачи знаний, используемому человеком.</p> <p>Предприятия, которые извлекут долгосрочную ценность из агентов ИИ, будут не теми, у кого самые сложные модели. Они будут теми, кто проделал работу по обеспечению возможности запрашивать свои организационные решения, фиксируя не только то, что говорят их данные, но и то, как их организация действовала на их основе с течением времени.</p> <p>Организационный айсберг реален, и агенты уже здесь. Каждое решение, принятое вашей организацией без фиксации его логики, — это институциональные знания, которые вы никогда не сможете вернуть.</p> Агенты искусственного интеллекта терпят неудачу, когда упускают из виду «невидимые данные». Нитин Сингхал, вице-президент … article https://www.itweek.ru/themes/detail.php?ID=235146 Fri, 10 Jul 2026 09:53:36 +0300 <p><em>Внедрение физического искусственного интеллекта ускоряется, но для достижения успеха требуется ранняя интеграция, передовое проектирование и стратегическое развертывание, чтобы выйти за рамки пилотных проектов, пишет на портале </em><em>InformationWeek</em> <em>Вибха Рустаги, вице-президент Cognizant по IoT и инженернии.</em></p> <p>Физический ИИ больше не является футуристической концепцией. Эта новая технология, существующая в различных формах — автономные роботы и дроны, беспилотные транспортные средства, промышленная автоматизация, — проникает в мир вокруг нас.</p> <p>По мере ускорения ее внедрения организации быстро переходят к использованию ее коммерческих и операционных возможностей. Согласно январскому <a href="https://www.ib.barclays/our-insights/series/impact-series/ai-gets-physical-innovation-meets-opportunity.html">отчету</a> Barclays, интерес к внедрению машин и систем с поддержкой ИИ вырастет до такой степени, что, по прогнозам, к 2035 г. гуманоидный сектор рынка робототехники достигнет 200 млрд. долл.</p> <p>Но готовы ли организации внедрить эту технологию в свою деятельность? Для переноса ИИ из облака в физическую среду руководителям проектов необходимо сначала решить сложные технические задачи.</p> <p>Физический ИИ включает в себя машины и системы, которые могут воспринимать, понимать, рассуждать и действовать автономно в реальном мире. Организации должны доказать, что их решения безопасны, надежны, совместимы и масштабируемы, с четкой ответственностью за риски в реальных условиях. Если они не смогут этого сделать, проекты не пройдут стадию проверки концепции.</p> <p>В то же время руководители должны управлять текущими операционными расходами. Когда они контролируются, а инвестиции ориентированы на четкую ценность, организации имеют больше шансов выйти за рамки пилотных проектов, обеспечивая повышение эффективности, энергопотребления и времени безотказной работы.</p> <h3>Внедряйте физический ИИ как можно раньше</h3> <p>Руководители могут повысить вероятность успеха, внедрив интеллект с самого начала. Раннее встраивание ИИ в системы создает прочную основу для масштабируемого развертывания и более быстрого получения эффекта.</p> <p>Поздняя интеграция приводит к фрагментации оборудования, встроенного сфота, ПО и облака. Наблюдение за данными оказывается затруднено, системам ИИ сложно получать точную информацию, что приводит к неоптимальной производительности.</p> <p>Когда физический ИИ не учитывается на ранних этапах проектирования и разработки, накапливается технический долг. Это может препятствовать способности организации к инновациям. По оценкам Gartner, организации, активно управляющие этим «ИИ-долгом», в течение следующих трех лет будут взрослеть в пять раз быстрее.</p> <p>Хотя ИИ можно внедрять в существующие операции для получения значительных преимуществ, ранняя интеграция обеспечивает более гладкое масштабирование и более эффективные долгосрочные операции, особенно если она поддерживается моделированием и цифровыми двойниками для проверки решений перед развертыванием.</p> <h3>Освойте периферийную инженерию</h3> <p>Встраивание физического ИИ в продукты и операции требует тщательного проектирования. В отличие от облачных сред, эти развертывания должны учитывать ограниченные вычислительные мощности, память и энергопитание. Поэтому обеспечение инференса в реальном времени на периферии требует аккуратного компромисса между такими элементами, как размер модели, частота ее обновления, выбор оборудования и архитектура.</p> <p>Эти ограничения можно устранить с помощью комбинации подходов. Локальные рабочие нагрузки можно расширить с помощью энергоэффективных графических процессоров и специализированных ИИ-ускорителей, а методы оптимизации моделей, такие как сжатие и квантование, снижают вычислительные требования без ущерба для производительности.</p> <p>В ограниченных средах распределенные периферийные архитектуры могут перекладывать определенные задачи на близлежащие устройства. Если учитывать особенности периферии в решениях с самого начала, организации могут использовать аналитику ближе к месту принятия решений, уменьшая чрезмерную зависимость от облака. Это также обеспечивает обновление моделей, мониторинг производительности и скоординированную оркестровку всех парков устройств для поддержания реальной производительности в любом масштабе.</p> <h3>Сначала смоделируйте</h3> <p>В отличие от облачных развертываний, физический ИИ часто требует крупных капиталовложений. Соответственно, вначале необходимо предоставить подтверждение концепции. Руководители должны продемонстрировать, какое влияние эти проекты окажут на операционную деятельность и потенциальную рентабельность инвестиций. Без этих доказательств старшее руководство не сможет решительно двигаться вперед.</p> <p>Помимо возможности ранней проверки проекта, моделирование в виртуальных средах повышает уверенность в успехе крупномасштабного развертывания. Такие платформы, как Omniverse от Nvidia, позволяют организациям создавать цифровых двойников и оценивать операционный эффект, прежде чем совершать капитальные затраты.</p> <p>С их помощью руководители могут тестировать различные сценарии, оценивать альтернативные решения, чтобы увидеть, как они повлияют на стратегии автоматизации, использование энергии и взаимодействие между сотрудниками. Они могут делать это, не прерывая живые операции. Это упрощает демонстрацию рентабельности инвестиций и получение поддержки руководства.</p> <h3>Управляйте стратегиями развертывания</h3> <p>Моделирование помогает руководителям выявить способы достижения быстрых результатов и продемонстрировать успех на раннем этапе, что позволяет разработать стратегию поэтапного развертывания.</p> <p>Поэтапный подход дает командам возможность собирать доказательства безопасности, надежности, соответствия нормативным требованиям и способности обеспечивать высокую окупаемость инвестиций. Это позволяет продвигать внедрение и помогает руководителям избежать потенциальной ловушки «пилотного чистилища». Наряду с поэтапным внедрением, развертывание должно поддерживаться программой управления изменениями, чтобы подготовить организацию к операционному воздействию физического ИИ.</p> <h3>Управляйте организационными изменениями</h3> <p>Поскольку физический ИИ требует навыков проектирования периферийных решений, которые обычно не нужны в проектах облачного ИИ, может потребоваться расширение штата сотрудников и изменение организационных структур. Необходимо будет пересмотреть обязанности сотрудников, процессы и управление.</p> <p>Также необходимо учитывать влияние этой новой технологии на все заинтересованные стороны. Для обеспечения широкого принятия необходимо четкое информирование о причинах внедрения технологии и о том, как она повлияет на роли людей. Могут потребоваться обучение и постоянная поддержка.</p> <p>Проникновение физического ИИ в наши рабочие места, дома и общественную инфраструктуру будет иметь трансформационные последствия. Его возможности значительны, но организации должны быть готовы как к самой технологии, так и к изменениям, которые она приносит. Им потребуются решения, адаптированные к их конкретным потребностям, и стратегии внедрения, чтобы ускорить развертывание во всех их операциях.</p> Внедрение физического искусственного интеллекта ускоряется, но для достижения успеха требуется ранняя интеграция, передовое … article https://www.itweek.ru/themes/detail.php?ID=235145 Thu, 09 Jul 2026 14:33:12 +0300 <p>Innostage представила новую версию Innostage PAM 1.7.0 — решения для управления привилегированным доступом в корпоративных инфраструктурах. В новой версии доработаны сценарии, от которых зависит повседневная эксплуатация PAM в крупных корпоративных инфраструктурах: подключение к ресурсам в сетях с пересекающейся адресацией, прозрачность аутентификации и управляемость при хранении событий.</p> <p>Одно из ключевых обновлений касается работы с RDP-подключениями. В версии 1.7.0 появился портал выбора ресурсов для клиентских подключений, реализована поддержка VRF (Virtual Routing and Forwarding) и Kerberos для RDP Web и RDP Client. Также добавлен пароль временного токена и реализован его запрос при подключении. Эти изменения помогают адаптировать Innostage PAM к инфраструктурам со сложной сетевой архитектурой и сделать подключение к целевым ресурсам более удобным и безопасным для пользователей.</p> <p>Отдельный блок изменений связан с контролем аутентификации. В Innostage PAM появилась фиксация неуспешных попыток входа по сертификатам X.509. Также расширен контроль смарт-карт и токенов при подключении. Это повышает прозрачность входа по сертификатам, токенам и смарт-картам, что позволяет внедрить подходы беспарольной аутентификации. </p> <p>В версии 1.7.0 администратор может выбирать алгоритмы генерации SSH-ключей при ротации ключей, создании привилегированных учетных записей (ПУЗ) и при создании ключей для входа в Innostage PAM. Это усиливает безопасность процессов аутентификации с помощью SSH-ключей.</p> <p>Помимо этого, в новой версии улучшен функционал по защите данных доступа к внутренней БД, реализована маскировка паролей в фиксируемых командах для Web Proxy и исправлены ошибки при работе с Elasticsearch. Эти изменения повышают управляемость при эксплуатации PAM-системы и хранении событий.</p> <p>Отдельно Innostage начала работу над модулем поведенческой аналитики привилегированных пользователей. Модуль будет автоматически выявлять нетипичные действия без ручного анализа логов, формировать профиль поведения на основе статистических и математических методов, обнаруживать отклонения, деструктивные действия и признаки компрометации учетных записей. Данный модуль помогает ускорить выявление инцидентов безопасности и проведение расследований.</p> <p>«В проектах по внедрению и сопровождению PAM-систем сложность часто возникает не в настройке самого контроля, а в его ежедневном использовании: подключениях через разные сегменты сети, работе с токенами и смарт-картами, анализе большого объема событий. Если эти процессы неудобны, PAM быстро становится формальным контуром. В версии 1.7.0 мы доработали именно такие участки, чтобы контроль привилегированного доступа работал в реальной инфраструктуре заказчика, а не только на схеме внедрения», — отметил Игорь Еньков, владелец продукта Innostage PAM. </p> Innostage представила новую версию Innostage PAM 1.7.0 — решения для управления привилегированным доступом … message https://www.itweek.ru/themes/detail.php?ID=235144 Thu, 09 Jul 2026 14:29:24 +0300 <p>Обновление в последней версии СЭД Directum Lite для среднего и малого бизнеса поможет быстрее и без разработчиков автоматизировать внутренние обращения и пользовательские сервисы.</p> <p>С помощью инструмента «Диалоги» в Directum Lite можно создавать документы, запускать задачи, добавлять записи в справочники в ускоренном режиме. Пользователю больше не нужно разбираться, как правильно формировать запросы, по какому процессу идти и куда отправлять задачи. «Диалоги» упрощают получение данных. Сотрудники вводят информацию в одном окне с минимальным количеством кликов и ошибок. Благодаря этому бизнес может быстрее внедрять изменения и сократить затраты на разработку.</p> <p>Раньше администратору в no-code-редакторе, чтобы добавить новые поля и собрать формализованную информацию, требовалась помощь разработчиков для создания специальной формы. С помощью инструмента «Диалоги» администратор может настроить ПО так, чтобы у пользователя появилось всплывающее окно. В нем система сама запросит информацию и подтверждение действия.</p> <p>Чтобы при запуске нового инструмента пользователю было понятно, что от него требуется, у администратора есть возможность настроить инструкцию. В нее можно добавить подсказки по заполнению полей и ссылки на внутренние регламенты.</p> <p>Обновления доступны в облачной и локальной версиях системы Directum Lite.</p> Обновление в последней версии СЭД Directum Lite для среднего и малого бизнеса поможет быстрее и без разработчиков … message https://www.itweek.ru/themes/detail.php?ID=235143 Thu, 09 Jul 2026 11:00:31 +0300 <p><em>Инженеры и эксперты говорят, что проверка кода (</em><em>code</em> <em>review</em><em>) редко выявляет ошибки — её настоящая задача состоит в том, чтобы помечать код, который трудно поддерживать в дальнейшем, сообщает портал The New Stack.</em></p> <p>Рецензирование программного кода — это систематическая процедура обеспечения качества, в которой участвуют коллеги разработчика. Она предполагает тщательную проверку кода, когда разработчик отправляет запрос на изменение или слияние.</p> <p>Плохие процедуры проверки кода часто критикуют за неизбежные задержки и возможность создания узких мест из-за незначительных мелочей, зато, по идее, хорошая проверка кода выявляет ошибки на ранних стадиях, способствует развитию наставнических отношений и рассматривается как демократичный способ распределения ответственности. Хорошо, если бы все так и было.</p> <p>По словам старшего инженера-программиста Марка Доминуса, хотя многие компании, очевидно, проводят проверку кода, они не «четко формулируют, каким должен быть результат проверки», и это проблема. «Представьте, что вы начинающий инженер, и вам впервые поручают провести проверку кода. Каков должен быть результат вашей работы? Во многих местах, где я работал, этому вопросу не хватало четкости», — отмечает он.</p> <p>В своем посте на Mastodon на эту тему Доминус <a href="https://mathstodon.xyz/@mjd/115096720350507897">пишет</a>, что «любой, кто полагается на проверку кода для поиска ошибок, живет в мире иллюзий», главным образом потому, что в целом невозможно найти ошибки, просто изучая код. Он подчеркивает, что основная цель проверки кода — найти код, который будет сложно поддерживать в будущем.</p> <h3>Верный путь к плохим результатам проверки кода</h3> <p>Доминус отмечает, что в сценариях, когда от инженера-программиста ожидают неспешный просмотр изменений и указания на то, что ему не нравится, это приводит к плохим результатам, то есть побуждает людей пытаться навязывать свои собственные предпочтения относительно того, как все должно быть сделано, и тогда обычно возникают споры.</p> <p>«Иногда начальник дает младшему инженеру малоинформативное задание, например: „Попробуй найти какие-нибудь ошибки“, и это ставит джуниора в неприятное положение, — поясняет Доминус. — Может быть, он и найдет ошибку, отлично! Но что, если нет? Найти ошибки, просто изучив набор изменений, крайне сложно и требует определенной доли удачи».</p> <p>Он предлагает другой подход, при котором проектные тимлиды дают примерно такие указания: «Изучайте код два часа, записывайте все, что вам непонятно, и если вы не дочитали до конца, отметьте, где остановились».</p> <h3>Путь к получению реальной ценности</h3> <p>«Если рецензенту не хватит времени просмотреть всё, это уже ценный результат: изменения слишком велики или сложны, чтобы их можно было понять за два часа. Возможно, набор изменений следует разбить на два или более вариантов поменьше, которые следует рассматривать отдельно. Тогда независимо от того, насколько неопытен, некомпетентен или страдает от похмелья рецензент, он сможет выполнить поставленную задачу, и то, что он сделает, будет иметь реальную инженерную ценность», — объясняет Доминус.</p> <p>В данном случае реальная инженерная ценность — это отрицательный результат. Команда выявила код, который другой член команды не может понять, или набор изменений слишком громоздкий для текущего процесса проверки кода... или и то, и другое.</p> <h3>Проверка кода — это скорее театральное представление</h3> <p>Согласный в целом с этими утверждениями, Михаил Голиков, инженер по обеспечению качества в компании, занимающейся высоконагруженными платформами электронной коммерции, говорит, что «проверка кода — это своего рода театр», если команда полагается на неё для выявления ошибок.</p> <p>«Человек, бегло просматривающий diff, не может увидеть состояние гонки или скидку, которая становится отрицательной под нагрузкой. Проверка предназначена для выявления кода, который вы будете ненавидеть поддерживать позже; тесты — для кода, который не работает сейчас, — подчеркивает он. — Рецензент читает чистый diff, видит осмысленные имена и аккуратные функции и нажимает „одобрить“. Но ничто из этого не говорит вам о том, что ключевая часть приложения неисправна и предоставляет пользователю неработоспособный сервис».</p> <p>Голиков, который также является мейнтейнером Open Source-инструментов тестирования Python, объясняет, что ошибки, вызывающие сбои, находятся не в коде, который могут прочитать разработчики. Они возникают в состояниях, в которых код находится во время выполнения.</p> <h3>Не испытывайте чувство удовлетворения, не получив каких-либо доказательств</h3> <p>«Когда команда рассматривает проверку как фильтр ошибок, она выпускает проект с чувством удовлетворения и без каких-либо доказательств, а затем обнаруживает ошибки в продакшене, — отмечает Голиков. — Проверка кода предназначена для того, чтобы задавать вопросы типа: „Буду ли я ненавидеть поддерживать это через шесть месяцев?“ и „Действительно ли это работает?“, когда тест проводится на реальных входных данных, а не для того, чтобы человек бегло просматривал запрос на слияние под конец рабочего дня».</p> <p>Среди разработчиков и поставщиков практически нет споров о том, что процессы проверки кода нуждаются в изменениях, особенно в эпоху ИИ с растущим распространением агентных инструментов кодирования.</p> <p>Джуда Тауб, управляющий партнер Hetz Ventures, согласен с этим мнением и отмечает, что на протяжении многих лет инженерные команды рассматривали проверку кода как последнюю линию защиты от ошибок, но это никогда не было ее сильной стороной.</p> <p>«Проверка кода выявляет стиль, архитектуру, читаемость и удобство сопровождения, — говорит он. — Тесты выявляют ошибки. В производственной среде обнаруживается все остальное. Лучшие инженерные организации не полагаются на то, что другой разработчик обнаружит едва заметный крайний случай, скрытый в сотнях строк кода — они создают системы, которые автоматически проверяют корректность задолго до того, как запрос на слияние попадет к другому человеку. Проверка кода призвана обеспечить бесшовную работу над кодом следующего инженера».</p> <h3>Будущее проверки кода</h3> <p>Поскольку в игру вступает код, сгенерированный ИИ, Тауб считает, что неизбежно новой нормой станет ситуация, когда люди будут меньше напрямую проверять код и все больше — код, проверенный ИИ.</p> <p>«Роль инженера продолжает смещаться от самого кодирования к проверке архитектуры, намерений и бизнес-логики. В будущем даже это может быть автоматизировано», — предсказывает он.</p> <p>Здесь, безусловно, видна важная тенденции, позволяющая сказать, что командам разработчиков определенно нужно выйти из девяностых, если они сейчас там находятся.</p> <p>Совокупные революции нативных облачных технологий, платформенной инженерии и переходящего в агентное кодирование вайб-кодинга (можно добавить большие данные, DevOps и стандартизацию в сторону корпоративного Open Source, если хотите) изменили способ работы разработчиков ПО. Поэтому, очевидно, должны произойти и соответствующие изменения в способах проверки кода.</p> Инженеры и эксперты говорят, что проверка кода (code review) редко выявляет ошибки — её настоящая задача состоит … article https://www.itweek.ru/themes/detail.php?ID=235142 Thu, 09 Jul 2026 10:13:44 +0300 <p><em>В условиях развития агентного искусственного интеллекта плохое управление (</em><em>governance</em><em>) данными рискует усилить предвзятость и ошибочные решения. Управление должно стать основой для надежного ИИ реального времени, пишет на портале </em><em>InformationWeek</em> <em>Эрин Хамм, директор по данным в DataBee, принадлежащей компании Comcast.</em></p> <p>В течение многих лет управление рассматривалось как налог, который вы платите, чтобы избежать проблем — это было что-то, что вы делали реактивно, минимально и в основном для удовлетворения требований аудиторов. Это уже была неэффективная модель, но теперь агентный ИИ сделал ее неприемлемой.</p> <p>Развитие ИИ, особенно агентного, коренным образом изменило ожидания в отношении управления данными. Речь идет уже не только о соблюдении нормативных требований и ответственном управлении, но и об обеспечении надежных результатов ИИ.</p> <p>Теперь, когда ИИ получил широкое распространение, предприятия выходят за рамки экспериментов и начинают внедрять агентный ИИ и автономную бизнес-аналитику (BI) в операционные рабочие процессы и отчетность. Эти технологии выступают в качестве интеллектуальных «вторых пилотов» для автоматизации повторяющихся задач, проактивного выявления закономерностей и даже инициирования действий на основе предопределенных параметров управления и рисков.</p> <p>Однако успех зависит от готовности данных. Агентный ИИ процветает благодаря контекстно-насыщенным, высококачественным данным. Современным организациям необходимо уделять гораздо больше внимания данным, используемым для построения моделей ИИ, чтобы гарантировать их точность и происхождение. Без надежной архитектуры данных и управления ими эти системы рискуют усилить предвзятость или принятие бизнес-решения на основе неполной информации.</p> <h3>Расширение сферы управления</h3> <p>По мере распространения ИИ в организациях становится ясно, что необходим более строгий подход к управлению. Эта новая волна внедрения ИИ высвечивает необходимость расширения сферы деятельности команд управления, включая:</p> <ul> <li><strong> Контроль за предвзятостью и справедливостью. </strong>Наборы данных, используемые для ИИ, должны быть репрезентативными и свободными от системной предвзятости, однако большинство организаций не знают, что содержится в их обучающих наборах. Это не провал науки о данных, а скорее ситуация, когда управление должно вмешаться и помочь им получить необходимые знания.</li> <li><strong> Происхождение данных и прозрачность.</strong> Если команды не могут отследить происхождение данных, они не могут защитить результаты ИИ. Надлежащая политика обеспечит четкую видимость происхождения данных и их преобразования до того, как они достигнут систем ИИ.</li> <li><strong> Динамическое управление рисками.</strong> ИИ вносит новые риски, такие как дрейф моделей и галлюцинации, которые требуют тесного сотрудничества команд управления с командами безопасности и управления рисками. Это уже не только ИТ-проблемы; это проблемы управления рисками — и командам управления необходимо место за этим столом.</li> </ul> <p>За последние пару лет работа по управлению эволюционировала от преимущественно ориентированной на соответствие нормативным требованиям к стратегическому компоненту цифровой трансформации. Эффективные команды управления теперь тесно сотрудничают с командами безопасности, ИИ/машинного обучения и облачных операций для управления рисками и обеспечения инноваций во всей организации. Аналогичным образом, вместо реактивных аудитов после завершения цикла, управление может быть интегрировано в процессы жизненного цикла данных, уменьшая трение и повышая гибкость.</p> <h3>Проблема неоперационализированного управления</h3> <p>Наиболее распространенный вид неудачи — это не сопротивление внедрению ИИ, а управление посредством служебной записки. Когда речь идет об ИИ и его эффективном использовании, организации выигрывают от подхода, ориентированного на управление, с четко определенными ролями и обязанностями, а также ясной структурой использования ИИ в повседневной работе. Организациям может быть проще просто сказать «нет» ИИ, но это было бы ошибкой. Вместо этого им следует продумать все аспекты и разработать руководящие принципы, позволяющие людям использовать инструменты ИИ для повышения производительности.</p> <p>Организации со зрелыми, интегрированными практиками управления должны увидеть значительные улучшения. Они лучше подготовлены к ответственному использованию ИИ, снижению регуляторных рисков и поддержанию доверия клиентов при одновременном ускорении получения инсайтов.</p> <h3>Управление с включением ИИ в цикл</h3> <p>Эффективность и безопасность в управлении данными все чаще обеспечиваются интеграцией и автоматизацией. Организации, которые правильно подходят к этому вопросу, внедряют следующее:</p> <ul> <li><strong> Унифицированная видимость данных.</strong> Команды не могут управлять тем, чего не видят. Переходите к платформам, которые объединяют данные из нескольких источников в единое, нормализованное представление. Это уменьшает разрозненность и упрощает последовательное применение политик управления.</li> <li><strong> Политика как код. </strong>Применение правил в режиме реального времени всегда превосходит ретроспективные проверки. Внедряйте правила управления непосредственно в конвейеры обработки данных, обеспечивая реагирование в режиме реального времени, а не проверки постфактум.</li> <li><strong> Управление с приоритетом безопасности. </strong>С учетом стремительного роста объемов данных в гибридных и мультиоблачных средах происходит конвергенция управления с кибербезопасностью. Команды должны уделять приоритетное внимание безопасному обмену данными и мониторингу аномалий в рамках рабочих процессов управления.</li> <li><strong> Управление с помощью ИИ.</strong> ИИ следует использовать для классификации данных, выявления пробелов в соответствии нормативным требованиям и выработки рекомендаций по их устранению, освобождая человеческие команды для принятия более важных решений. Цель состоит не в замене команд управления на ИИ, а в том, чтобы прекратить заваливать их ручной работой.</li> </ul> <p>Управление имеет возможность стать фактором, способствующим развитию бизнеса, а не узким местом. Когда управление автоматизировано и интегрировано с безопасностью, организации могут быстрее внедрять инновации, сохраняя при этом доверие и соответствие нормативным требованиям.</p> <h3>ИИ в управлении станет конкурентным преимуществом</h3> <p>Организации, которые сейчас опережают конкурентов, — это не те, у кого самый сложный ИИ. Это те, чьи данные действительно готовы к его использованию: нормализованы, отслеживаемы, управляются в режиме реального времени и связаны во всех рабочих процессах безопасности. Эта готовность возникла не случайно, а благодаря архитектурным решениям, принятым задолго до того, как были определены сценарии использования ИИ.</p> <p>Устаревшие системы, которые не могут поддерживать обмен данными в режиме реального времени или автоматизацию управления, не только замедляют работу, но и создают накопленный риск, который усугубляется с каждой последующей ИИ-инициативой. Поэтому предприятиям следует уделять больше внимания нативным облачным архитектурам, тканям данных и экосистемам на основе API, поскольку это необходимые условия для масштабируемого ИИ.</p> <p>Готовое к ИИ управление не является необязательным, оно является основополагающим. Отстающие проигрывают не потому, что выбрали неправильную модель, а потому, что построили ее на основе данных, которым не могут доверять.</p> В условиях развития агентного искусственного интеллекта плохое управление (governance) данными рискует усилить предвзятость … article https://www.itweek.ru/themes/detail.php?ID=235139 Wed, 08 Jul 2026 15:28:27 +0300 <p>Российский разработчик СУБД Postgres Professional представил Postgres ProGate 1.3.0 — обновление продукта для миграции и репликации данных. В новой версии появилась поддержка распределённой реляционной СУБД Postgres Pro Shardman, отказоустойчивый режим работы prosync для непрерывной репликации и расширенные возможности безопасности.</p> <p>Postgres ProGate предназначена для проектов миграции, разового переноса данных и непрерывной репликацей между СУБД. Продукт помогает автоматизировать ключевые этапы работы с данными: первичную загрузку, синхронизацию изменений в режиме, близком к реальному времени, и проверку корректности переноса. Версия 1.3.0 расширяет сценарии использования ProGate для крупных распределённых систем, где важны не только скорость миграции, но и надёжность репликации, управляемость, отказоустойчивость и контроль качества данных.</p> <p>«В крупных проектах всё чаще требуется не просто перенести данные в новую СУБД, а обеспечить их непрерывную синхронизацию и встроить целевую систему в масштабируемую, отказоустойчивую архитектуру. В ProGate 1.3.0 мы добавили поддержку Postgres Pro Shardman как целевой системы, усилили отказоустойчивость prosync и расширили инструменты безопасности. Это помогает делать проекты миграции и репликации более предсказуемыми и надёжными для заказчиков с большими объёмами данных и критичными нагрузками», — отметил Евгений Кривов, руководитель продукта Postgres ProGatel.</p> <p>Ключевым нововведением ProGate 1.3.0 стала поддержка Postgres Pro Shardman в качестве приёмника данных. Теперь Shardman можно использовать как целевую СУБД как при разовом переносе данных с помощью procopy, так и при непрерывной репликации через prosync.</p> <p>В релизе появилась маршрутизация строк по шардам: данные из таблицы-источника можно распределять между сегментами Shardman-кластера по заданным условиям. Это позволяет управлять распределением данных уже на этапе миграции и готовить целевую систему к работе с большими объёмами и растущей нагрузкой.</p> <p>В prosync, утилите для <nobr>CDC-репликации,</nobr> появился режим высокой доступности. Несколько экземпляров prosync с одинаковой конфигурацией могут работать как кластер: один узел выполняет роль лидера, остальные находятся в резерве и готовы продолжить репликацию при отказе основного узла.</p> <p>Такой подход снижает риски остановки синхронизации данных во время длительных миграционных проектов и повышает надёжность непрерывной репликации в промышленных средах.</p> <p>Список поддерживаемых СУБД-источников расширен за счёт Oracle 11g. Теперь procopy и prosync поддерживают Oracle 11g, 12c, 18c и 19c.</p> <p>Также в новой версии улучшена работа с Oracle Real Application Clusters и сценариями обратной миграции PostgreSQL → Oracle. Это делает ProGate более гибким инструментом для сложных инфраструктур, где миграция может включать несколько типов источников и направлений переноса данных.</p> <p>В ProGate 1.3.0 усилены механизмы безопасности: увеличены требования к длине пароля, ограничено число попыток входа, добавлена обязательная валидация email, расширен журнал аудита, а после смены пароля администратором пользователь должен обновить пароль при следующем входе.</p> <p>Улучшения также затронули procheck — утилиту для проверки корректности переноса данных. В ней появились аутентификация, события безопасности, автоматическое определение кодировок источника и приёмника, а также исправления для более стабильной работы с пользовательскими типами, XML, геометрическими данными и объектами Oracle.</p> <p>Все утилиты ProGate теперь поддерживают подстановку переменных окружения в конфигурационных файлах. Это упрощает использование платформы в контейнерных и автоматизированных средах, где чувствительные параметры — например пароли и адреса хостов — не должны храниться напрямую в конфигурации.</p> Российский разработчик СУБД Postgres Professional представил Postgres ProGate 1.3.0 — обновление продукта для миграции … message https://www.itweek.ru/themes/detail.php?ID=235138 Wed, 08 Jul 2026 15:25:34 +0300 <p>Линейка продуктов на базе платформы «АКСИОМА» дополнена новым решением — «АКСИОМА ИскИн». «АКСИОМА» уже зарекомендовавшей себя на российском рынке как эффективный инструмент управления активами/ТОиР. Интеллектуальная система призвана стать удобным инструментом для анализа производственной информации, работы с корпоративными знаниями и поддержки принятия решений на промышленных предприятиях и объектах энергетики.</p> <p>Объём данных, с которыми ежедневно работают промышленные предприятия, растёт экспоненциально: эксплуатационная документация, регламенты, отчёты технических служб, журналы ремонтов, нормативные справочники. В этом потоке теряется главное — способность быстро находить нужную информацию и видеть связи между разрозненными фактами. Именно эту задачу решает «АКСИОМА ИскИн».</p> <p>Система объединяет разрозненные источники корпоративных данных в единое информационное пространство. Инженер, технолог или руководитель может задать вопрос на естественном языке — и получить не просто ссылку на документ, а структурированный ответ, основанный на данных из технической документации, инструкций и внутренних баз знаний. При этом каждый ответ сопровождается ссылками на исходные источники, что реализует принцип объяснимого искусственного интеллекта.</p> <p>Технологической основой решения служит корпоративный граф знаний. Он связывает оборудование, технологические процессы, документы, нормативные требования и производственные данные, позволяя выявлять неочевидные взаимосвязи между объектами и событиями. Это превращает разрозненные архивы в работающий интеллектуальный актив.</p> <p>«АКСИОМА ИскИн» предназначена для работы в цифровой среде самого предприятия — данные остаются в закрытом контуре организации. Это важно для объектов критической информационной инфраструктуры и предприятий, работающих в условиях строгих требований к технологическому суверенитету. Благодаря такой интеграции с существующими корпоративными системами решение не требует кардинальной перестройки ИТ-инфраструктуры, что обеспечивает быстрый старт и минимальные риски.</p> <p>Среди ключевых результатов внедрения — сокращение времени поиска информации, ускорение подготовки ответов на технические вопросы, повышение доступности корпоративных знаний и создание единой среды для работы специалистов. Наибольший эффект «АКСИОМА ИскИн» принесёт в энергетике, нефтегазовой отрасли, металлургии, химической промышленности, машиностроении и транспортной инфраструктуре. </p> Линейка продуктов на базе платформы «АКСИОМА» дополнена новым решением — «АКСИОМА ИскИн». «АКСИОМА» уже … message https://www.itweek.ru/themes/detail.php?ID=235137 Wed, 08 Jul 2026 15:24:08 +0300 <p>Эксперты компании «Информзащита» выявили рост спроса на гибридную модель проверки AI-систем: в 2026 году только 9% организаций готовы полностью доверить пентесты AI-автоматизации. Годом ранее такой подход поддерживали 29% респондентов. За двенадцать месяцев доля сторонников полного автономного тестирования сократилась на 20 процентных пунктов, тогда как число компаний, предпочитающих использовать автоматические средства для некритичных активов, а критичные системы проверять вручную, выросло на 22 процентных пункта — до 47%.</p> <p>Автоматические средства быстро находят известные ошибки конфигурации, проблемы с внешней поверхностью атаки, повторяемые недостатки в API и нарушения базовых политик безопасности. Однако AI-приложение редко ограничивается типовой веб-логикой. Поведение LLM зависит от системных инструкций, контекста диалога, версии модели, подключенных источников данных, прав пользователя, списка доступных агенту инструментов и ограничений, заданных в оркестраторе. Уязвимость может проявиться только при определенной последовательности действий, которую невозможно получить одиночным тестовым запросом. </p> <p>Разбивка по векторам уже зафиксированных AI-инцидентов подтверждает, что риск не ограничивается ошибками одной модели. В 44% случаев причиной становился shadow AI — использование сотрудниками несанкционированных внешних инструментов с передачей чувствительных данных. По 41% пришлось на отравление данных и моделей, а также на небезопасную обработку ответов LLM. Уязвимости в цепочке поставок были названы в 35% инцидентов, prompt injection — в 34%, ошибки LLM и слабости векторных баз и эмбеддингов — в 32% каждый. Далее следуют чрезмерные полномочия агентов и утечки системных промптов — по 24%, дезинформация — 20%, неограниченное потребление ресурсов — 15%. Автоматизированные средства полезны для регулярного контроля многих из этих направлений, но не способны самостоятельно подтвердить безопасность сложной связки между моделью, данными и бизнес-процессом.</p> <p>В исследовании 78% команд сообщили, что сталкивались с пропуском критичных уязвимостей автоматизированными средствами. Для AI-сервисов это особенно чувствительно: ошибка может находиться не в самом запросе к модели, а в том, как она интерпретирует данные из RAG-базы, вызывает внешние API, получает доступ к внутреннему контуру или действует от имени сотрудника. Механическая проверка не всегда способна увидеть связь между отдельными элементами такой архитектуры и оценить последствия их сочетания. </p> <p>«Снижение доверия к полной автоматизации не означает отказа от AI-инструментов в пентесте. Компании увидели пределы их применимости: сканер способен быстро проверить большую поверхность атаки, но не всегда распознает многошаговую цепочку, где результат зависит от контекста диалога, прав агента, подключенных данных и логики бизнес-процесса. Для критичных AI-систем автоматизация должна сокращать время на рутинные проверки, а итоговую оценку риска должны давать специалисты, способные воспроизвести действия атакующего», — объяснил Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащита». </p> <p>Наиболее показательный пример — prompt injection. В изолированной среде модель может корректно отклонять вредоносные инструкции, но изменить поведение после обработки специально подготовленного документа, сообщения из внешней системы или фрагмента истории диалога. Аналогично проявляются риски избыточной агентности: модель получает доступ к почте, CRM, файловому хранилищу или корпоративному API, а ошибка в разграничении прав позволяет выполнить действие, которое не должно быть доступно в данном контексте. Для проверки таких сценариев нужно моделировать действия атакующего, тестировать обход защитных ограничений, анализировать бизнес-логику и оценивать фактический объем полномочий AI-агента.</p> <p>Эти сценарии хорошо ложатся на классы рисков OWASP Top 10 for LLM Applications: prompt injection, data/model poisoning, improper output handling, supply-chain weaknesses, excessive agency, system prompt leakage, vector and embedding weaknesses и unbounded consumption. Автоматизация может обнаружить часть таких проблем, но не подтверждает безопасность всей цепочки от источника данных до бизнес-действия, которое модель выполняет после обработки запроса.</p> <p>Разбивка инцидентов по векторам атак подтверждает, что проблема не сводится к одному классу уязвимостей. В 44% случаев причиной становился shadow AI — использование сотрудниками несанкционированных внешних AI-сервисов и передача им чувствительных данных. По 41% инцидентов пришлось на отравление данных и моделей, а также на некорректную обработку ответов LLM. Уязвимости цепочки поставок фигурировали в 35% случаев, prompt injection — в 34%, ошибки LLM и слабости векторных баз и эмбеддингов — в 32%. Избыточные полномочия агентов и утечки системных промптов отмечались в 24% инцидентов, дезинформация — в 20%, неограниченное потребление ресурсов — в 15%. Автоматизация может обнаружить часть этих проблем, но не способна самостоятельно подтвердить безопасность всей цепочки от источника данных до бизнес-действия, которое модель выполняет после обработки запроса.</p> <p>Отраслевой разрез исследования не ранжирует сферы по уровню доверия к полной автоматизации и не дает статистики инцидентов для каждой вертикали. Однако состав выборки показывает, где вопрос особенно актуален: разработка ПО представлена 27% респондентов, здравоохранение — 21%, финансовые и страховые организации — 14%, информационные сервисы — 10%, другие отрасли — 27%. В разработке ПО AI-инструменты часто подключают к репозиториям, средам разработки и CI/CD-конвейерам, поэтому ошибка в правах агента может затронуть исходный код или цепочку поставки. В здравоохранении основной риск связан с обработкой медицинских данных и интеграциями с профильными системами. Для финансового сектора критичны операции с платежной информацией, персональными данными и сервисами, которые участвуют в принятии решений по клиентам. Информационные сервисы чаще работают с внешними запросами, большими массивами контента и поисковыми системами, что повышает значимость контроля источников данных и RAG-контуров. Указанные проценты отражают структуру выборки, а не уровень уязвимости отраслей. </p> <p>Сложность проверки усугубляется тем, что найденные проблемы не всегда быстро устраняются. В 2026 году AI- и <nobr>LLM-приложения</nobr> показали самую низкую долю закрытых высокорисковых уязвимостей среди всех типов пентестов — 38,4%. Годом ранее показатель составлял 21,1%, однако даже после роста он остается существенно ниже, чем у веб-приложений с 73,7% и API с 77,3%. При этом 77% организаций уже регулярно проводят оценки безопасности и пентесты AI-продуктов, а 59% используют red teaming или adversarial testing с фокусом на LLM. Проверок становится больше, но возможности команд по устранению сложных находок растут медленнее. </p> <p>Эксперты «Информзащиты» рекомендуют использовать автоматизацию для задач, где она дает стабильный и проверяемый результат: непрерывного мониторинга внешней поверхности, контроля конфигураций, инвентаризации сервисов, поиска повторяемых ошибок и повторных проверок после устранения уязвимостей. AI-системы, работающие с внутренними данными, персональной информацией, платежными операциями или действиями от имени сотрудника, должны проходить ручной пентест и red teaming до ввода в эксплуатацию, а затем — после изменения модели, системного промпта, RAG-базы, набора интеграций или прав доступа. Полная инвентаризация AI-сервисов, контроль shadow AI, отдельные сценарии для prompt injection и утечек через RAG, прозрачные SLA для ИБ, разработки и владельцев продукта помогут сделать результаты тестирования частью реального управления рисками, а не формальным отчетом.</p> Эксперты компании «Информзащита» выявили рост спроса на гибридную модель проверки AI-систем: в 2026 году только 9% … message https://www.itweek.ru/themes/detail.php?ID=235135 Wed, 08 Jul 2026 09:42:12 +0300 <p><em>Работа будущего, вероятно, потребует тщательного сочетания человеческих навыков и агентов искусственного интеллекта. Опрошенные порталом </em><em>ZDNet</em> <em>эксперты рассказывают, как успешно работать со своими коллегами-агентами.</em></p> <p>Беспокойство о том, насколько профессионально выполняет свою работу человек рядом с вами, больше не является вашей единственной заботой. Команда тех, кто хочет достигать срочных целей и добиваться отличных результатов, скорее всего, будет включать в себя широкий спектр коллег-людей и агентов ИИ.</p> <p>Мы вступаем в эпоху автономного бизнеса, где новые сочетания технологий и данных означают, что некоторые роли, которые мы сегодня считаем само собой разумеющимися — от базовых операционных задач до принятия решений — выполняются агентами, которые автономно обнаруживают, обсуждают и совершают действия.</p> <p>Gartner предполагает, что компании увеличат свои инвестиции в агентов, при этом расходы на ПО для ИИ-агентов, <a href="https://www.gartner.com/en/newsroom/press-releases/2026-05-05-gartner-says-autonomous-business-and-artificial-intelligence-layoffs-may-create-budget-room-but-do-not-deliver-returns">по прогнозам</a>, в 2027 г. достигнут <nobr>206,5-376,3 млрд.</nobr> долл. по сравнению с 86,4 млрд. долл. в <nobr>2025-м.</nobr></p> <p>Некоторые компании уже успешно используют агентов в своей операционной деятельности. Отвечая на вопросы ZDNet, представители трех из них выделили три ключевых фактора успеха: сравнительный анализ агентов, открытость к новым идеям и сосредоточение на правильных областях.</p> <h3>Сравнительный анализ инструментов</h3> <p>Мадлен Уонт, вице-президент по данным в спортивной платформе Fanatics, признала, что достижение отличных результатов с помощью и агентов, и людей — непростая задача, поэтому ее организация отслеживает и анализирует достижения сообщества специалистов по работе с данными.</p> <p>Она рассказала, что Fanatics активно и одной из первых внедряет ИИ для работы с данными, тестируя инструменты, сравнивая функции, проводя предварительные просмотры и развивая партнерские отношения в области дизайна: «Мы сравниваем, как вы используете эти инструменты, для каких задач вы их используете, сколько времени, по вашему мнению, они вам экономят, и что вы делаете с этим временем — ответы на все эти вопросы помогают в самостоятельной оценке ценности».</p> <p>По словам Уонт, которая руководит инженерией данных, наукой о данных и машинным обучением в подразделении ставок и игр, результаты тестов показывают, что использование ИИ-агентов экономит время людей.</p> <p>«Каждый бизнес-аналитик скажет вам что-то вроде: „Я бы хотел заниматься более стратегической работой, но я погряз в рутинной отчетности“. Мы видим, что именно рутинные задачи по составлению отчетов лучше всего поддаются автоматизации с помощью ИИ, и в результате сотрудники экономят время и затем используют его для более человеческой и стратегической работы, что является своего рода наилучшим результатом, на который можно надеяться», — сказала она.</p> <p>Уонт отметила, что успешное применение агентного ИИ заключается в получении более совершенных инструментов для работы, чтобы можно было самим не выполнять необходимые части работы и сосредоточиться на более интересных областях, в которых вы преуспеваете.</p> <p>Однако, хотя некоторые инструменты могут работать уже сейчас, она признала, что агентный ИИ — это незавершенный проект, и стремление ее компании к внедрению и тестированию таких инструментов в первую очередь означает, что специалисты могут регулярно знакомиться с новыми сервисами.</p> <p>По словам Уонт, философский подход ее организации к агентам означает, что внедрение предполагает процесс обмена информацией между менеджерами и специалистами по мере открытия новых способов работы с использованием ИИ.</p> <p>«Нужно быть готовым к тому, что это не традиционный многолетний проект по трансформации корпоративных технологий», — сказала она, посоветовав другим специалистам быть открытыми к исследованиям и переменам.</p> <p>«Мы не внедряем хорошо проверенные, заезженные технологии, которые, будучи внедренными, никогда не будут отменены. Сейчас ИИ находится на экспериментальной стадии, поэтому внедряйте его как можно раньше и пробуйте разные варианты, но также относитесь к этому осторожно, потому что нужно оставаться гибкими», — посоветовала Уонт.</p> <h3>Открытость для новых идей</h3> <p>Мэтт Луиззи, вице-президент по аналитике компании Whoop, специализирующейся на носимых технологиях, еще до внедрения агентного ИИ стремился помочь своей команде более эффективно использовать свое время.</p> <p>«Я пытался понять, на что тратит время моя команда, и люди говорили, что от 50 до 60% времени уходит на ответы на случайные вопросы из разных отделов компании, — сказал он. — Каковы были продажи вчера? Чем они отличаются по регионам? Почему у нас увеличилось количество веб-сессий? Это задачи, от которых люди хотят избавиться. Это задачи, от которых люди были бы рады избавиться. Именно в этом сейчас преуспевают агенты».</p> <p>По словам Луиззи, его компания заметила, что внедрение агентов позволяет сотрудникам-людям уделять больше времени стратегической работе, приносящей дополнительную ценность: «Мы уже видим реальное влияние этой технологии на доходы, поскольку люди могут заблаговременно определять проблемы, выявлять их первопричины, устранять неполадки и принимать меры гораздо быстрее, еще до того, как ситуация выйдет из-под контроля».</p> <p>Он считает, что развитие агентного ИИ будет продолжать набирать обороты, особенно для задач, которые легко автоматизировать. «Мы будем и дальше наблюдать прогресс, открывающий новые возможности там, где люди тратят свое время, но нам нужно продолжать расширять границы», — сказал он.</p> <p>В связи с этим Луиззи предположил, что ни один сотрудник, вероятно, не обладает ключом к успеху агентного ИИ. Отличные идеи могут возникать где угодно, и все специалисты должны быть готовы внести свой вклад. «Некоторые организации будут развиваться снизу вверх, где сотрудники младшего уровня будут осваивать новые технологии, рисковать и высвобождать время, — сказал он. — Некоторые из этих инициатив будут исходить сверху вниз, от руководителей, которые посещают конференции и узнают, что делают другие организации. Они смогут распространять эти знания по всей организации, выявляя и сопоставляя, как они помогают решать проблемы, с которыми сталкивается их команды».</p> <h3>Поиск новых проблем для решения</h3> <p>Шрирам Ситараман, CIO софтверной компании Synopsys, управляет довольно большими объемами инженерных и корпоративных данных. По его словам, в обеих областях агенты демонстрируют способность помочь повысить возможности человека.</p> <p>«Если вы посмотрите на объем доступных данных, то концепция наилучшего следующего действия, которое вы можете предпринять, раньше предполагала обсуждение группой людей, исходя их текущих приоритетов, — сказал он. — Теперь, благодаря ИИ, вы можете действительно принимать решения, основанные на данных и приносящие прибыль».</p> <p>Ситараман рассказал, что его компания осознала потенциал агентов ИИ для выполнения задач младших сотрудников, таких как выполнение быстрых запросов, создание графиков и получение инсайтов.</p> <p>Он также привел пример процесса принятия решения о том, какие новые функции следует разработать для приложения: сотрудники могут работать бок о бок со своими коллегами-агентами для отбора идей и выявления коммерчески жизнеспособных предложений. «Вам не нужна целая команда людей, ведущих обсуждение. Достаточно небольшой группы, анализирующие большой объем данных, — сказал он. — Многие усилия по согласованию источников данных для принятия решений сейчас сосредоточены на том, как людям получить преимущество от использования ИИ. Эти усилия направлены на сокращение больших объемов данных до достаточных для выполнения конкретных шагов».</p> <p>По опыту Ситарамана, агентный ИИ экономит время сотрудников. Например, беря на себя задачи сортировки и отбора данных первого уровня, персонал может перейти к более сложной, создающей ценность работе.</p> <p>«Это иерархическая система. Модели будут передавать задачи ИИ, и по мере совершенствования моделей сложность задач, с которыми может справиться ИИ, будет возрастать, — сказал он. — Так что через полгода ИИ будет решать иные задачи — не те же, что сейчас, а другого типа, и эта эволюция будет происходить постоянно».</p> Работа будущего, вероятно, потребует тщательного сочетания человеческих навыков и агентов искусственного интеллекта … article https://www.itweek.ru/themes/detail.php?ID=235133 Wed, 08 Jul 2026 09:26:44 +0300 <p><em>Когда HR приходит к ИТ-директору с запросом на автоматизацию найма, за этим, как правило, стоит не техническая задача, а управленческая. Рассмотрим, где такие проекты проваливаются, сколько реально стоят и как организовано внедрение, которое приносит измеримый результат.</em></p> <h3>Главное, что нужно проверить до старта</h3> <p>Большинство проектов по автоматизации найма не дают ожидаемого эффекта по одной причине: процесс, который пытаются автоматизировать, не описан. Нет чёткой последовательности шагов, непонятно, кто за что отвечает, информация между участниками передаётся устно и теряется по дороге.</p> <p>Здесь важно понимать: автоматизация не исправляет процесс — она его закрепляет. Если внутри беспорядок, система просто зафиксирует этот беспорядок в цифровом виде, и он никуда не денется. Именно поэтому до выбора любого инструмента стоит честно ответить на простой вопрос: может ли HR-блок описать процесс найма пошагово, назвать ответственного на каждом этапе и объяснить, как принимается решение по кандидату? Если ответ неуверенный — сначала нужно выстроить сам процесс, и только потом искать под него инструмент автоматизации.</p> <h3>Роль HR: от исполнителя к владельцу продукта</h3> <p>HR-система сегодня — это не отдельное приложение, которое работает само по себе. Она встраивается в существующую инфраструктуру компании: интегрируется с кадровыми системами, корпоративным порталом, внутренними коммуникациями и почтой. Вместе с этой интеграцией сразу возникает вопрос, который раньше HR-проектов не касался: где и как хранятся данные. По требованиям <nobr>152-ФЗ</nobr> данные кандидатов должны размещаться либо на локальных серверах в контуре компании, либо в сертифицированных облачных решениях. Штрафы за утечку персональных данных за последние годы выросли существенно, и игнорировать этот вопрос на этапе выбора платформы уже не получится.</p> <p>Всё это изменило не только технические требования к проекту, но и состав команды, которая принимает решение о внедрении. Раньше HR-директор выбирал систему самостоятельно — в лучшем случае согласовывал бюджет с финансами. Сейчас в проект входят юристы, безопасники, системные администраторы и аналитики. Сам HR-руководитель в этой команде занимает принципиально иную позицию. Всё чаще он выступает в роли product owner: формулирует требования, управляет внедрением как проектом и отвечает за результат перед бизнесом. Это принципиально другой уровень ответственности и другой уровень компетенций, который от него теперь требуется.</p> <h3>Где реально экономятся деньги</h3> <p>Многие компании ожидают, что после внедрения системы автоматизации стоимость подбора снизится. Через год обнаруживают, что цифра в бюджете осталась прежней — просто деньги переложились из одной строки в другую. Раньше уходили на джоб-борды, теперь уходят на лицензии, поддержку, интеграцию и обучение.</p> <p>Реальная экономия достигается иначе — через скорость закрытия вакансий. Чем быстрее закрыта позиция, тем меньше часов рекрутер тратит на каждого кандидата и тем раньше новый сотрудник начинает приносить компании результат. На линейных позициях это особенно ощутимо: каждая незакрытая ставка напрямую влияет на операционные показатели, и потери от простоя легко посчитать в деньгах.</p> <p>Проверить, происходит ли эта экономия на самом деле, можно одним вопросом: изменилось ли количество рекрутеров, которые нужны компании для обработки того же объёма вакансий? Если число осталось прежним, автоматизации не произошло. Система сделала работу рекрутеров чуть удобнее, но реальной эффективности компания не получила.</p> <p>Именно поэтому метрики успеха нужно определять до старта, а не после. Для ИТ-директора важно ещё на этапе подготовки проекта определить метрики успеха: сколько компании стоит закрытие вакансии, сколько времени занимает найм, какой объём ручной работы выполняют рекрутеры, сколько систем участвует в процессе и во сколько обходится их поддержка. Без этих исходных данных оценить результат внедрения после запуска сложно.</p> <h3>Децентрализованная структура: как не утонуть в зоопарке систем</h3> <p>Компании с филиальной структурой сталкиваются с типичной картиной: у каждого подразделения своя система, свои данные, свои процессы найма. Один филиал работает в одной CRM, другой ведёт всё в Excel, третий вообще не знает, что у соседей что-то автоматизировано. Такое встречается уже в компаниях от 800 человек — это не история про корпорации-гиганты.</p> <p>Попытка решить эту проблему одним махом — привести всё к единому стандарту одновременно — почти всегда заканчивается провалом. Подразделениям навязывают чужие процессы, и в ответ получают саботаж. Гораздо эффективнее начать с одного-двух департаментов, отладить там процесс, получить измеримый результат — и дать этим людям самим рассказать об опыте коллегам. Каждое следующее внедрение идёт быстрее: уже есть внутренние сторонники с живыми цифрами, и сопротивления значительно меньше.</p> <p>При этом успех масштабирования во многом определяется архитектурой самой платформы. Важно выбирать систему, которая изначально рассчитана на такую гибкость: позволяет настраивать разные процессы для разных подразделений, не заставляя всех работать по единому шаблону. Но гибкость процессов не должна означать раздробленность данных. Для ИТ-директора принципиально, чтобы при различии процессов данные оставались централизованными. В противном случае компания получает не единую систему подбора, а ещё один набор несвязанных между собой баз данных и интеграций.</p> <h3>Внутренняя база кандидатов — недооценённый ресурс</h3> <p>У большинства крупных компаний накоплены базы кандидатов, которые не используются повторно. Люди подавали заявки год, два, три назад — их данные хранятся в системе, но в подборе не участвуют. Это одновременно юридический риск — избыточные персональные данные сверх минимума, установленного законом, — и упущенная возможность сократить затраты на привлечение новых кандидатов.</p> <p>Между тем работа с внутренней базой даёт вполне конкретный эффект. В ритейле, например, при открытии новой точки географическая близость кандидата к месту работы — один из ключевых факторов успешного найма. Если данные о местоположении собраны, можно точечно реактивировать тех, кто живёт рядом, вместо того чтобы тратить бюджет на широкий таргет на внешних площадках.</p> <p>В вахтовом найме работает другая логика, но результат тот же. Люди, которые уже работали в компании, возвращаются значительно охотнее новых кандидатов — просто потому что знают, чего ожидать. На практике работа с такой базой добавляет около 15% к воронке найма без дополнительных затрат на привлечение.</p> <p>Для ИТ-директора это в первую очередь вопрос к архитектуре системы: умеет ли платформа работать с накопленными данными, строить по ним выборки и запускать автоматические сценарии повторного вовлечения кандидатов. Если нет — данные так и будут копиться мёртвым грузом, создавая юридические риски, но не принося никакой пользы.</p> <h3>Где сейчас граница между ИИ и человеком в найме</h3> <p>Во многих компаниях ИИ уже не просто помогает отбирать резюме — он ведёт первичный контакт с кандидатом: переписку, первые вопросы, проверку базовых критериев. Следующий уровень — уже не переписка, а полноценный анализ поведения кандидата в реальном времени. Системы анализируют видеоинтервью: отслеживают реакции кандидата, тембр голоса, эмоциональные маркеры и на основе этого формируют рекомендацию. Такие решения уже есть на рынке и активно внедряются.</p> <p>При всём этом финальное решение о найме остаётся за человеком — и, судя по всему, останется там ещё долго. Задача ИИ в этой цепочке — собрать полную картину по кандидату, структурировать данные и подсветить ключевые факты. Задача рекрутера и нанимающего менеджера — принять взвешенное решение на их основе. Рутинная фильтрация уходит на сторону системы, а за рекрутером остаётся то, что алгоритм пока не умеет: оценивать человека в контексте команды и культуры компании.</p> <p>Для ИТ-директора это означает, что запрос на интеграцию ИИ-инструментов в HR-контур — уже не вопрос будущего. Компании, которые сегодня внедряют автоматизацию найма, завтра придут с запросом на диалоговых агентов, видеоанализ и предиктивную аналитику по кандидатам. Инфраструктура должна быть к этому готова.</p> <p>А значит, проекты автоматизации подбора давно вышли за рамки HR-функции. Они становятся частью общей цифровой архитектуры компании, а их эффективность зависит не только от возможностей системы, но и от того, насколько органично она встроена в существующие процессы, данные и корпоративные сервисы.</p> <p>#IMAGE_235134#</p> Когда HR приходит к ИТ-директору с запросом на автоматизацию найма, за этим, как правило, стоит … article Татьяна Бабич, владелец продукта KitBot компании Nord Clan https://www.itweek.ru/themes/detail.php?ID=235131 Tue, 07 Jul 2026 14:04:07 +0300 <p>Несмотря на стремительный рост популярности ИИ-ассистентов, многие продолжают использовать их неэффективно. По результатам опроса Faves Communications и LibraChat , 7 из 10 россиян признались, что не используют возможности ИИ в своей работе в полной мере. Завышенные ожидания, поверхностная оценка возможностей и неправильная постановка задач приводят к тому, что полученные результаты не соответствуют запросам. Марианна Базаркулова, эксперт по практическому применению ИИ в бизнесе платформы искусственного интеллекта LibraChat, назвала три самые распространенные ошибки, которые мешают получать от ИИ максимальную пользу.</p> <h3> 1. Ожидать, что искусственный интеллект полностью сделает за тебя всю работу</h3> <p>Самое распространенное заблуждение — воспринимать ИИ как полноценную замену сотрудника. На самом деле ИИ — это инструмент, который помогает выполнять задачи быстрее, но не способен самостоятельно принимать стратегические решения. ИИ не владеет тем пониманием бизнеса, продукта и целевой аудитории, которое есть у опытного специалиста. Если человек сам не способен разобраться в задаче, то и ИИ вряд ли справится с ней на высоком уровне.</p> <p>Аналогично и с бизнес-процессами. Если в компании отсутствуют маркетинговая стратегия, аналитика, регламенты или четкое описание процессов, искусственный интеллект не создаст их «из воздуха». Он способен усиливать уже существующую систему, но не заменять ее.</p> <h3>2. Оценивать ИИ по одной небольшой задаче</h3> <p>Многие делают выводы о возможностях искусственного интеллекта, ограничиваясь одним простым запросом вроде «напиши пост» или «подготовь рассказ», но такой подход редко позволяет увидеть реальную ценность технологии. </p> <p>Максимальный эффект от ИИ раскрывается при работе с большими объемами информации и выполнении повторяющихся операций, например, при анализе сотен публикаций, обработке массивов данных, мониторинге информационного поля, генерации множества вариантов контента, классификации обращений клиентов или поиске закономерностей для аналитических сводок. Именно на масштабных задачах ИИ существенно экономит время, снижает операционные издержки и повышает производительность команды.</p> <h3>3. Использовать ИИ без качественного промптинга и контроля результатов</h3> <p>Качество результата работы ИИ напрямую зависит от четкости поставленной задачи: даже самая передовая модель не сможет предложить эффективное решение, если запрос лишен конкретных деталей. Практика показывает, что пользователи нередко допускают типичные ошибки — дают слишком общие формулировки, не раскрывают контекст (особенности компании, продукта и целевой аудитории) и не обозначают критерии качества. </p> <p>Чтобы добиться максимального эффекта, можно выстроить систему проверки и уточнения результатов: после первичной генерации материала стоит дать ИИ дополнительные указания — исключить шаблонные фразы, усилить аргументацию, подкрепить тезисы конкретными данными либо скорректировать тональность текста. Многоэтапный подход в работе с ИИ существенно повышает ценность итогового продукта. </p> <p>При этом важно осознавать границы возможностей технологии: задачи, где критически важны профессиональное чутье и человеческий опыт, не подлежат полной автоматизации. К ним относятся, в частности, разработка стратегических решений, управление репутационными рисками, создание креативных концепций, ведение переговоров и принятие управленческих решений — здесь ключевую роль продолжает играть сам человек.</p> Несмотря на стремительный рост популярности ИИ-ассистентов, многие продолжают использовать их неэффективно … message https://www.itweek.ru/themes/detail.php?ID=235130 Tue, 07 Jul 2026 10:26:22 +0300 <p>ИТ-компания IT_ONE представила систему мониторинга процессов разработки Gradient — инструмент для комплексного управления ИТ-командами и принятия решений на основе достоверных данных. Система не только аккумулирует и визуализирует метрики эффективности из различных инструментов команды разработки, но также анализирует их, подсвечивает узкие места и дает рекомендации по оптимизации процесса, исправлению ошибок и снижению операционных рисков.</p> <p>Система Gradient автоматически собирает исходные данные из Jira, Git, BitBucket, CI/CD и любых других систем, применяемых продуктовыми командами (репозиториев, тест-трекеров, аналитических инструментов), обрабатывает их, вычисляет показатели производительности и строит интерактивные дашборды. </p> <p>Для мониторинга в Gradient специалисты IT_ONE отобрали те метрики, которые позволяют наиболее точно и объективно оценить скорость, предсказуемость и эффективность процесса разработки, а также качество кода. Среди них, например, lead time (время от создания до завершения задачи), velocity (среднее количество дней, затраченное на итерацию), coding time (время от первого коммита до создания pull request), review count (количество проведенных ревью) и другие — всего более 15 показателей. Метрики и способы их расчета могут быть адаптированы под уникальные процессы команд и управленцев. У пользователей системы есть возможность добавлять любые новые метрики, отсутствующие в библиотеке Gradient.</p> <p>За визуализацию этих показателей отвечают гибко настраиваемые дашборды команд разработки, руководителей ИТ-департаментов и топ-менеджмента. С помощью этих отчетов ответственные специалисты видят единую, понятную картину всех процессов, получают объективные данные о нагрузке в разрезе команд, проектов и отдельных сотрудников, динамике разработки и качестве изменений, скорости решения отдельных рабочих задач, появлении узких мест в процессах, отклонений и аномалий. При этом им не нужно искать, выгружать и обрабатывать какие-либо данные вручную.</p> <p>Ключевое преимущество системы Gradient — в способности грамотно интерпретировать полученные данные, формировать на их основе предупреждения. За счет этого она становится главным помощником руководителей разного уровня. Также важно отметить, что для внедрения системы не нужно трансформировать процесс работы команды. Решение гибко встраивается в текущие реалии и при первом же сканировании выдает базовый аудит собираемых данных, необходимых для доверенного сбора метрик.</p> <p>«Команды разработки в своей деятельности используют разные инструменты. Чтобы сформировать и проанализировать необходимые метрики эффективности, им, как правило, приходится собирать данные из этих систем в некое хранилище, над которым строится визуализация с помощью BI и любых других систем. Однако аналитические возможности BI и аналогов сильно ограничены, там нет контроля качества данных, обратной связи и других полезных функций. Поэтому главная ценность Gradient в том, что ему можно доверять. Наша система агрегирует данные, анализирует их и оценивает, насколько они пригодны, и полны для формирования метрик и аналитики по работе команд производства», — объяснил Дмитрий Немов, директор по развитию продуктов холдинга IT_ONE.</p> <p>По прогнозам IT_ONE, система Gradient позволит на <nobr>10-20%</nobr> повысить продуктивность команд за счет постоянного мониторинга и своевременного выявления узких мест, на <nobr>5-15%</nobr> снизить расходы на управление за счет автоматизации сбора метрик, аналитики и сокращения ручной отчетности, на 15% оптимизировать использование ресурсов благодаря аналитике загрузки и более точному распределению задач. </p> <p>Отдельно стоит отметить, что Gradient повышает прозрачность процессов, помогает выявлять риски и отклонения задолго до срыва сроков. Благодаря системе алертов и прогнозирования команда сможет отреагировать на инцидент задолго до того, как проблема станет критической. </p> <p>Функционально и архитектурно система отвечает всем требованиям информационной безопасности. Gradient предоставляет каждому сотруднику доступ только к тем данным, которые он использует в своей работе — таким образом сильно снижается вероятность утечки конфиденциальной информации. Также система может быть развернута on-premise, в том числе в закрытом контуре заказчика. </p> <p>«Система Gradient трансформирует сырые цифры, собираемые в различных системах, в целостную картину процесса разработки, которая позволяет экспертам принимать осознанные управленческие решения на основе понятных и достоверных данных, поставленных в нужный контекст. Благодаря ей они могут всегда оценить, что происходит в команде разработки в данный момент, почему так происходит, какие рациональные меры предпринять для улучшения процесса», — прокомментировал Андрей Комраков, ведущий руководитель программы разработок IT_ONE.</p> <p>В IT_ONE фиксируют высокий спрос на систему Gradient: на данный момент запущено несколько пилотных проектов ее внедрения у заказчиков разных сфер деятельности, в том числе в финсекторе и ритейле. Особенно актуален этот продукт для средних и крупных компаний с большими подразделениями разработки ПО, занятыми в сложных длительных проектах.</p> ИТ-компания IT_ONE представила систему мониторинга процессов разработки Gradient — инструмент для комплексного управления … message https://www.itweek.ru/themes/detail.php?ID=235129 Tue, 07 Jul 2026 09:48:41 +0300 <p><em>Искусственный интеллект открывает новую эру аварийного восстановления, и предприятиям необходимо понять, как обновить свои стратегии для поддержания устойчивости, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>До нынешней волны внедрения ИИ аварийное восстановление фокусировалось на резервном копировании и восстановлении корпоративных приложений, баз данных и всех компонентов традиционной ИТ-инфраструктуры.</p> <p>Это остается актуальным и сегодня, но предприятиям теперь также необходимо подумать о моделях ИИ, промптах и агентах. Можно ли восстановить эти ресурсы, и как предприятия могут убедиться в их надежности после восстановления?</p> <p>«Вообще говоря, планы аварийного восстановления большинства организаций в этой области отстают от внедрения ИИ на годы», — говорит Грег Сарич, CIO компании Quest Software.</p> <p>Если CIO и CISO хотят помочь своим предприятиям наверстать упущенное, они должны понять, как обновить свои планы аварийного восстановления и протестировать их на реальных инцидентах.</p> <h3>Катастрофа в эпоху ИИ</h3> <p>Когда предприятие сталкивается с инцидентом безопасности или сбоем в современной среде, насыщенной ИИ, команде по восстановлению после катастроф приходится учитывать множество факторов, в том числе:</p> <ul> <li> Были ли скомпрометированы данные, используемые для обучения систем ИИ?</li> <li> Были ли они украдены?</li> <li> Были ли отравлены модели ИИ?</li> <li> Были ли скомпрометированы промпты?</li> </ul> <p>Обеспечение необходимой прозрачности для ответа на эти вопросы является сложной задачей, учитывая, насколько сильно ИИ затрагивает технологические стеки предприятия.</p> <p>«Если вы используете Claude, он может затрагивать вашу систему Salesforce и SharePoint, вашу систему Outlook и другие данные, которые у вас могут быть, скажем, в Snowflake, или что-то еще, где у вас есть критически важные для бизнеса данные, — поясняет Сарич, иллюстрируя, как ИИ создает сеть взаимосвязанных зависимостей. — Речь идет не только о защите этих систем, но и обо всех этих небольших пересечениях, которые он затрагивает на пути к возможности извлечения данных и последующего создания результата».</p> <p>В условиях, когда ИИ все больше интегрируется в бизнес-процессы, предприятия рискуют столкнуться с остановкой работы, особенно если их команды больше не могут вернуться к ручным методам. «Если ИИ-помощник или чат-бот выйдет из строя, мы потеряем доступ к институциональным знаниям, на которые полагаются наши сотрудники», — говорит Мехди Худайги, главный специалист Deloitte по кибербезопасности ИИ.</p> <p>Риск сохраняется и после восстановления работы ИИ-ресурсов после инцидента. Предприятия должны проверять целостность этих ресурсов, но обнаружение компрометации базовых данных, промптов или моделей может быть затруднительным. «ИИ может продолжать работать. И неподготовленному глазу может казаться, что он выдает уверенные ответы, но эти ответы могут быть неверными, неполными или сфальсифицированными», — отмечает Худайги.</p> <p>Предприятие может, например, восстановить работу чат-бота, но катастрофа продолжится, если люди будут действовать на основе скомпрометированной информации, которую он предоставляет.</p> <p>Радиус поражения может быть значительно больше при наличии агентов ИИ. «В зависимости от сложности агента, он уже не ограничивается одной системой, способной выполнять свои задачи. Потенциально он может охватывать несколько систем», — добавляет Худайги.</p> <p>Ущерб может сохраняться еще долго после того, как группы аварийного восстановления очистят скомпрометированные агенты ИИ, работающие на нескольких системах.</p> <p>«Если наши сотрудники, наши организации теряют доверие к самим инструментам, возникает большой разрыв в дальнейшем внедрении», — отмечает Сарич.</p> <h3>Разработка плана аварийного восстановления ИИ</h3> <p>Для CIO и CISO, рассматривающих, как должны развиваться их планы аварийного восстановления в ответ на ИИ, есть несколько основных шагов, которые помогут им начать:</p> <ul> <li><strong>Каталогизируйте свои ИИ-активы.</strong> С распространением ИИ в различных бизнес-подразделениях — и появлением теневого ИИ, добавляющего еще один уровень сложности — бывает трудно полностью понять, какие инструменты используются в каком месте.<br/> <br/> «Начните с инвентаризации активов ИИ. Если у вас ее нет, вам нужно быстро ее создать, — говорит Сарич. — Вы не сможете восстановить то, что не каталогизировали». </li> <li><strong>Определите критичность каждого актива для бизнеса. </strong>«Все, что в работе бизнеса связано с ИИ или имеет ИИ в своей основе, должно быть приоритетом номер один или считаться высоким уровнем опасности», — говорит Крис Миллингтон, руководитель направления решений Hitachi Vantara в области данных и киберустойчивости.<br/> <br/> По словам Сарича, инструменты, ориентированные на клиентов, и те, которые влияют на выручку, имеют более высокий приоритет. </li> <li><strong>Составьте карту зависимостей.</strong> Если ИИ глубоко интегрирован в рабочие процессы предприятий, крайне важно понимать его зависимости. «Какие данные он использует? На какую модель он опирается? Какой поставщик или поставщики участвуют? К каким системам он может получить доступ? И самое главное, какие учетные данные он использует?», — приводит перечень главных вопросов Худайги.</li> <li><strong>Оцените права доступа. </strong>Для эффективного восстановления руководителям служб ИТ и безопасности необходимо знать права доступа агентов и инструментов ИИ и иметь возможность отзывать учетные данные и завершать определенные задачи. После выполнения этих действий данные ИИ-ресурсы необходимо оценить, прежде чем их можно будет восстановить и снова предоставить им права доступа.<br/> <br/> «Проверка того, что агент работает в рамках так называемых утвержденных границ, прежде чем он снова будет задействован, имеет решающее значение с точки зрения аварийного восстановления», — говорит Худайги. </li> <li><strong>Определите целевые показатели восстановления.</strong> Организации должны определить целевое время восстановления и целевую точку восстановления, отмечает Худайги. Какой объем данных и времени простоя, связанных с ИИ-ресурсами, предприятие может позволить себе потерять? Каковы последние известные доверенные версии моделей, промптов и данных?<br/> <br/> Планы аварийного восстановления также должны определять необходимые этапы тестирования и проверки перед восстановлением и повторным подключением инфраструктуры ИИ к сети.<br/> <br/> «В системах ИИ задействовано значительно больше этапов из-за присущей им сложности, просто из-за их вероятностной природы», — поясняет Худайги. </li> <li><strong>Тестирование и проверка.</strong> План аварийного восстановления мало кому пригодится, если он пылится на полке до тех пор, пока не случится катастрофа. Тестирование имеет ключевое значение, но ежегодные или ежеквартальные тесты недостаточны, учитывая темпы развития ИИ. Новые инструменты, новые зависимости и новые риски — неотъемлемая часть эпохи ИИ.<br/> <br/> При проведении тестирования предприятиям необходимо учитывать все потенциальные пробелы в своих планах аварийного восстановления и устранять их.<br/> <br/> «Спросите себя, что произойдет, если база знаний будет повреждена или если мы потеряем доступ к одной из больших языковых моделей, когда API будут недоступны по какой-либо причине? Что произойдет, если агент будет вести себя неожиданно или если у нас реализуются случаи потенциального компрометирования, когда мы не сможем доверять журналам? Ответы на эти вопросы помогут довольно быстро выявить пробелы», — говорит Худайги. </li> </ul> <h3>Когда случается катастрофа</h3> <p>Несмотря на то, что ИИ меняет операционную деятельность, старая поговорка в области кибербезопасности «Это вопрос не „если“, а „когда“» остается актуальной. Если внедрение ИИ будет продолжать опережать надлежащее управление, инциденты, которые возникают и затрагивают агентов и инструменты, будут неизбежно происходить.</p> <p>Согласно недавнему исследованию Proofpoint «<em>2026 AI and Human Risk Landscape</em>», 42% из 1400 опрошенных специалистов по безопасности сталкивались с инцидентами, связанными с ИИ, как подозрительными, так и подтвержденными. Кроме того, 52% респондентов заявили, что не полностью уверены в способности средств защиты их организаций обнаружить скомпрометированный ИИ.</p> <p>Предприятия уже сталкиваются с инцидентами, влияющими на их ИИ-ресурсы, и Сарич предполагает, что рано или поздно произойдет крупное событие, которое выведет восстановление после ИИ-сбоев на первый план. «Я уверен, что в недалеком будущем мы станем свидетелями чего-то масштабного», — говорит он.</p> <p>Независимо от того, будет ли это крупное публичное событие или нет, предприятиям придется обратиться к своим планам аварийного восстановления, проработать их, а затем провести анализ причин сбоя, чтобы сделать этот план более надежным для следующего инцидента. По словам Миллингтона, корпоративным командам предприятий придется искать ответы на такие ключевые вопросы, как: «На каком этапе мы восстановились, и было ли это приемлемо, или это можно оптимизировать еще больше?».</p> <h3>Недостающий показатель устойчивости ИИ</h3> <p>В условиях, когда стратегии аварийного восстановления совершенствуются в ответ на сложность корпоративного ИИ, остается без ответа важный вопрос: могут ли предприятия количественно оценить потери, связанные со сбоем, нарушением безопасности или другим инцидентом, затрагивающим их ИИ-ресурсы?</p> <p>Худайги утверждает, что в отрасли еще не достигнуто согласие относительно того, как количественно оценивать киберриски ИИ, не говоря уже о потерях, связанных с ИИ. В то же время, по его словам, у отрасли в целом есть возможность и необходимость взглянуть на то, каковы поддающиеся количественной оценке потери или риски воздействия этих систем.</p> <p>По мере того, как предприятия будут получать более четкое понимание операционных и финансовых последствий инцидентов, связанных с ИИ, аспекты стоимости аварийного восстановления и устойчивости, наконец, могут начать догонять внедрение ИИ.</p> Искусственный интеллект открывает новую эру аварийного восстановления, и предприятиям необходимо понять, как обновить свои … article https://www.itweek.ru/themes/detail.php?ID=235127 Tue, 07 Jul 2026 09:26:03 +0300 <p><em>Злоумышленники все чаще атакуют не рядовых сотрудников, а администраторов, имеющих широкие полномочия. Используются письма с поддельными уведомлениями от службы поддержки, запросами на смену пароля, фальшивыми обновлениями ПО. При этом традиционные тренировки уже не защищают ИТ-персонал от таких атак на 100%. </em><em>Рассмотрим</em><em>, как строить комплексную защиту от мошенников для ИТ-отделов.</em></p> <h3>Почему злоумышленники переключились на ИТ-отделы</h3> <p>По данным исследования Positive Technologies, в половине успешных кибератак в 2025 году <a href="https://ptsecurity.com/research/analytics/trendy-atak-v-2026-godu/#id33">применялись</a> методы социальной инженерии. В среднем 35% сотрудников <a href="https://www.it-world.ru/news-company/ilfpeqjrgj4ssg400kgkkgo8sowogoc.html">переходят </a>по фишинговым ссылкам, 21% — вводят свои учетные данные, и всего 2% сообщают о своих подозрениях в службу ИБ.</p> <p>При этом еще несколько лет назад фишинговые рассылки были в основном нацелены на специалистов, далеких от ИТ — бухгалтерию, секретарей или рядовых менеджеров. С одной стороны, их было проще ввести в заблуждение. С другой — полезный эффект от атак не всегда был высоким, ведь у рядовых сотрудников обычно сильно ограничены права доступа.</p> <p>Поэтому в последние годы злоумышленники активнее переключились на ИТ-отделы. Обмануть технических специалистов сложнее, но в случае успеха мошенников последствия для компании куда серьезнее. Один скомпрометированный сотрудник с правами администратора домена или доступом к критическим сервисам может дать ключ ко всей инфраструктуре компании.</p> <h3>Кто в группе риска внутри ИТ-отдела </h3> <p>Чтобы обмануть рядового сотрудника не из ИТ-департамента, может хватить обычной массовой рассылки со стандартными сценариями. Например, их просят срочно перейти по ссылке, иначе их рабочий аккаунт удалят или заблокируют.</p> <p>При таком массовом фишинге ИТ-специалисты сталкиваются с теми же базовыми триггерами. Обычно это стандартные уведомления о проблемах с аккаунтами или доступностью сервисов: требуют срочно сменить пароль либо предупреждают о том, что почтовое или локальное хранилище переполнено.</p> <p>Однако, как правило, такие методы малоэффективны для работы с ИТ-сотрудниками — они уже готовы к стандартным сценариям мошенников. Поэтому основной упор злоумышленников теперь смещается на таргетированные атаки, тщательно адаптированные под профиль конкретного сотрудника, его поведение и контекст работы. При этом не все администраторы привлекательны для атак с точки зрения хакера. Среди самых уязвимых категорий сотрудников можно выделить:</p> <ul> <li> Администраторов домена и идентичности — у них полный контроль над всеми сотрудниками и системами.</li> <li> Администраторов облачных сервисов (M365, AWS, Google Workspace).</li> <li> Системных администраторов, отвечающих за резервные копии и мониторинг. Через них можно легально отключить защиту или восстановить доступ к зашифрованным данным.</li> </ul> <p>Зная внутреннюю структуру компании, хакеры могут переписать текст письма под конкретные обязанности человека — это логичный шаг при подготовке атаки. Но на практике выяснить, за какую именно систему отвечает конкретный сотрудник, удается крайне редко. Такая информация стоит дорого, поэтому мошенники почти не подбирают индивидуальные триггеры под каждый тип администратора.</p> <h3>Как выглядит реальный сценарий атаки на системного администратора</h3> <p>Сегодня типичная атака состоит из нескольких этапов::</p> <ol> <li><strong> Разведка.</strong> Хакеры собирают цифровые следы ИТ-специалистов в компании, чтобы понять их зоны ответственности и права доступа. Они ищут утечки токенов и ключей в репозиториях кода, вычисляют имена тестовых серверов и аккаунты сервисов. Возможны сценарии, когда специалисты сами оставляют зацепки: на конференциях случайно рассказывают об особенностях своей инфраструктуры, а на форумах и в каналах в мессенджерах делятся защищаемыми активами инфраструктуры.</li> <li><strong> Подготовка инфраструктуры.</strong> Для писем хакеры регистрируют домены, запускают почтовые узлы и верстают фишинговые страницы. Иногда используют ресурсы крупных провайдеров — открытые серверы рассылок и IPFS-хранилища. Средства защиты информации более лояльно обрабатывают подобные сервисы, поэтому чаще рискуют пропустить фишинговый контент.</li> <li> <strong>Атака.</strong> Используя собранные данные, злоумышленники отправляют подготовленные письма и вредоносные файлы.</li> <li><strong> Закрепление и развитие.</strong> Скомпрометировав права, хакеры прописывают новые правила доступа, оставляют бэкдоры. Если захваченный аккаунт быстро заблокируют, у них все равно останется лазейка для входа.</li> <li> <strong>Результат.</strong> Дальше все зависит от целей хакеров. Они могут украсть данные, потребовать выкуп, сохранить доступы для следующих атак.</li> </ol> <p>Как это выглядит на практике, показывают результаты недавних киберучений в одной из компаний. Организаторы отправили тестовую фишинг-рассылку и так собрали у невнимательных сотрудников логины, пароли и коды второго фактора от почт. Они зашли в аккаунты и разослали в службу поддержки архивы с вредоносным кодом и припиской: «Посмотри, пожалуйста, почему архив не распаковывается».</p> <p>Сотрудники хелпдеска пытались открыть файл, но видели ошибку и пересылали его коллегам с той же просьбой. Так как у техподдержки есть права отключать антивирус, специалисты пытались это сделать, чтобы все-таки запустить содержимое. В итоге из-за одной ошибки под угрозой оказалась практически вся инфраструктура компании. И хорошо, что это были всего лишь киберучения! В случае реальной кибератаки такие действия привели бы к необратимым последствиям.</p> <p>Другой показательный случай произошел также во время киберучений, когда проверяли реакцию сисадминов на популярную у пентестеров тактику «низко висящих фруктов». На парковке офиса раскидали флешки с вредоносным ПО. Один из администраторов подобрал устройство и, понимая опасность, не стал включать ее на рабочем месте. Он принес флешку домой и подключил к домашнему ПК. Но админ не учел, что на его личном компьютере запущен VPN для удаленной работы. В результате пентестеры без труда проникли во внутренний периметр организации.</p> <h3>Как защитить ИТ-отдел</h3> <p>Одним из ключевых элементов эффективной защиты компании традиционно считается обучение персонала практикам кибербезопасности. По <a href="https://www.knowbe4.com/press/knowbe4-report-reveals-security-training-reduces-global-phishing-click-rates-by-86">данным KnowBe4</a>, треть (33%) сотрудников также взаимодействуют с имитацией фишинга перед тем, как пройти обучение. После внедрения обучения процент сотрудников, которые могут стать жертвами социальной инженерии или фишинговых атак, за год снижается сразу на 86%. Важно разбирать именно практические кейсы и ошибки — для этого можно использовать специальные онлайн-полигоны, на которых имитируются реальные атаки на инфраструктуру.</p> <p>При этом само по себе обучение не может полностью исключить человеческий фактор. Часть людей все равно перейдет по ссылке или скачает вредоносный файл — в спешке или по невнимательности. Для доставки вредоносного ПО мошенники используют различные коммуникационные каналы: электронную почту, сайты, мессенджеры и социальные сети. Поэтому первый шаг для снижения вероятности утечек — минимизировать саму возможность успешной доставки вредоносного ПО (ВПО). Для этого можно: </p> <ul> <li> использовать почтовые шлюзы и песочницы, проверяющие вложения и ссылки в электронных письмах в режиме реального времени;</li> <li> внедрить NGFW и прокси-сервисы с функцией категоризации сайтов и фильтрацией трафика;</li> <li> контролировать каналы обмена файлами внутри организации, включая мессенджеры, где возможна доставка ВПО с использованием социальной инженерии;</li> <li> регулярно тестировать параметры шлюзов и фильтров с помощью специализированных решений, имитирующих реальные сценарии доставки ВПО.</li> </ul> <p>Также нужно отметить, что число атак с распространением ВПО через легитимные сервисы продолжает расти. Поэтому разработчикам нужно внимательно относиться к используемым репозиториям и менеджерам пакетов в своих проектах и внедрять инструменты безопасной разработки и контроля цепочки поставок.</p> <p>Кроме того, важно следить за всеми возможными точками входа в инфраструктуру, включая давно неиспользуемые. Забытые сервисы, неучтенные устройства, теневые системы и устаревшие компоненты — все это становится потенциальными источниками уязвимости, которые нужно своевременно обновлять или отключать.</p> <p> #IMAGE_235128#</p> Злоумышленники все чаще атакуют не рядовых сотрудников, а администраторов, имеющих широкие полномочия. Используются … article Федор Гришаев, ведущий специалист группы исследования фишинговых угроз департамента киберразведки Positive Technologies https://www.itweek.ru/themes/detail.php?ID=235126 Mon, 06 Jul 2026 16:13:48 +0300 <p>Аналитики проекта STAQ, предназначенного для цифровизации бизнеса в России, определили ключевые рабочие процессы, которые отечественные компании предпочитают выполнять с использованием платформенных решений в 2026 году. Также эксперты проанализировали данные российских компаний из нескольких ведущих отраслей и выделили процессы, которые чаще всего становятся точкой входа в платформенную автоматизацию и дают наиболее измеримый эффект в каждой конкретной индустрии. Для анализа были использованы данные клиентов STAQ.</p> <p>Вне зависимости от отрасли есть задачи, которые сегодня массово переводятся на платформенные решения. Эти задачи объединяет высокая частота повторений, большое количество участников, четкие сроки и необходимость фиксировать каждый шаг. Управление сервисными заявками является одним из самых важных запросов. Платформа превращает поток обращений в структурированный процесс: единая точка входа, автоматическая маршрутизация по типу и приоритету, контроль SLA, эскалация при нарушении сроков. Еще одна задача — техническое обслуживание и ремонт (ТОиР). Платформенные решения переводят ТОиР из аварийного режима в плановое автоматическое формирование нарядов по расписанию или показателям с датчиков, назначение исполнителей, контроль выполнения, история по каждой единице оборудования. </p> <p>Кроме того, в списке подобных задач есть управление выездным персоналом. Платформа решает задачу на уровне логики процесса: учет геолокации, квалификации и загрузки специалистов, автоматическое назначение заявки ближайшему доступному исполнителю, мобильное приложение для фиксации работ на месте, автоматическое закрытие наряда после подтверждения. Важная задача — управление инцилентами и эскалациями. Любая операционная деятельность создает нештатные ситуации. Важно, как быстро о них узнают нужные люди и что будет дальше. Платформа задает этот маршрут заранее: по типу и критичности инцидента автоматически назначается ответственный, запускается таймер, при нарушении срока — эскалация на следующий уровень. Это превращает реакцию на инциденты из хаотичной в предсказуемую.</p> <p>Главный запрос в ритейле — централизация сервисных процессов при сохранении гибкости на уровне отдельного объекта. Это означает единую платформу, где сотрудники любой точки подают заявки на ремонт, расходные материалы, технических специалистов, единый контроль SLA по всей сети, автоматические уведомления и эскалации, если объект не получит ответ в срок. Второй по востребованности процесс — обслуживание торгового оборудования. Кассы, холодильники, торговые автоматы, вентиляционные системы — в крупной сети это тысячи единиц со своим регламентом обслуживания. Платформа обеспечивает автоматические наряды, историю по каждому устройству, контроль сроков, интеграцию с IoT-датчиками для предиктивного обслуживания. Третий сценарий, набирающий популярность — управление внешними подрядчиками. Платформа позволяет включить подрядчиков в единый контур: они получают заявки в той же системе, фиксируют выполнение, проходят оценку качества. </p> <p>В производстве также есть ключевые задачи, которые чаще всего решаются с помощью платформенных решений. Наиболее запрашиваемый блок — управление производственными заданиями и сменными отчетами. Платформа уровня MES позволяет переводить плановые задания в цифровые наряды для каждой смены и участка, фиксировать фактическое выполнение в реальном времени, автоматически сравнивать план и факт, видеть причины отклонений без разбора бумажных журналов постфактум. Второй процесс — мониторинг оборудования и контроль технологических режимов. Интеграция с IoT-датчиками позволяет платформе получать данные о состоянии оборудования в режиме реального времени. На основе данных формируются предиктивные задания на обслуживание. Третий процесс — управление качеством и несоответствиями. Выявленный брак, несоответствие стандарту запускают цепочку действий. Платформа превращает этот процесс из бумажного в цифровой. </p> <p>Ключевой запрос в логистике — управление парком техники и планирование работ. Единая платформа аккумулирует данные о техническом состоянии каждой единицы, истории обслуживания, пробеге и наработке моточасов. На основе этих данных формируются планы ТОиР и заявки на внеплановый ремонт. Второй востребованный процесс — диспетчеризация и контроль выполнения рейсов. Платформа позволяет фиксировать маршрут, время отправления и прибытия, отклонения от плана, статус груза на каждом этапе. Это не только операционный контроль — это данные для последующей аналитики. Третий процесс, который заметно активизировался в последний год, — управление подрядными перевозками. Когда часть маршрутов отдана на аутсорс, важно включить подрядчиков в единый цифровой контур., где есть постановка задания, подтверждение принятия, фиксация выполнения, оценка. </p> <p>В 2026 году платформенный подход продолжает набирать популярность в России, и это вполне объяснимо. Платформенный подход позволяет объединить системы в единую архитектуру управления, обеспечивая прозрачность, экономию и гибкость. Кроме того, он помогает компаниям запустить процессы по цифровой трансформации бизнеса. Переход от десятков сервисов к единой платформе — это важная стратегическая трансформация. Для компаний это означает больше, чем просто удобство. В данном случае речь про новый уровень управляемости, прозрачности и контроля.</p> Аналитики проекта STAQ, предназначенного для цифровизации бизнеса в России, определили ключевые рабочие процессы, которые … message