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=235643 Wed, 30 Sep 2026 12:37:45 +0300 <p>На середину 2026 года число ИТ-субъектов достигло 273 тысяч — в эту категорию входят юридические лица и индивидуальные предприниматели. Ежегодно с 2020 года в России регистрировалось от 30 до 54 тысяч новых ИТ-субъектов. Количество ИТ-субъектов в России ежегодно увеличивается в среднем на 8,3%. Об этом говорится в исследовании «Точки роста: как устроен российский рынок ИТ-стартапов» ведущей российской консалтинговой компании Strategy Partners. Его результаты Сбер представил на международной технологической конференции — Московском стартап-саммите.</p> <p>При этом далеко не все новые ИТ-субъекты можно отнести к стартапам: в число новых регистраций, например, могут входить случаи юридической реструктуризации бизнеса и выделения внутренних ИТ-подразделений в отдельные юридические лица.</p> <p>Количество активных ИТ-стартапов в России оценивается в <nobr>1,5–2,5 тысячи.</nobr> В общей массе зарегистрированных ИТ-компаний и ИП их доля — около <nobr>0,5–1,5%.</nobr></p> <p>Как показало исследование, существующая инфраструктура поддержки стартапов закрывает весь жизненный цикл: от грантов на этапе идеи до подготовки к IPO. На стадии идеи и посева работают ФСИ и ФРИИ; на ранней — Сколково, технопарки и ИНТЦ, РВК; на стадии роста — Московский венчурный фонд, корпоративные венчурные фонды, МИК; на зрелой — МИК (путь к IPO), Мосбиржа, СПб Биржа и фонды поздних стадий.</p> <p>Однако высокая ключевая ставка не способствует росту венчурных инвесторов: они склонны выбирать менее рисковые депозиты и облигации. Ключевая ставка, достигавшая 21% в <nobr>2024–2025</nobr> годах и составляющая 14% на сентябрь 2026 года, делает депозиты и облигации куда привлекательнее венчурного риска. Дорогие деньги смещают спрос в сторону финансирования зрелых компаний.</p> <p>Одним из основных вызовов для развития стартапов остаётся дефицит финансирования. С 2026 года к нему добавилась повышенная налоговая нагрузка: рост НДС (исключая ПО из реестра российского ПО, которое освобождено от НДС) и отмена части льгот для ИТ-компаний.</p> <p>География рынка крайне неравномерна: совокупный балл Москвы в 18 раз выше второго города в этом рейтинге — Санкт-Петербурга. Экосистема умеет производить чемпионов, но в масштабе 273 тыс. зарегистрированных субъектов это единичные истории успеха.</p> <p>Эксперты Strategy Partners считают, что толчком для развития стартапов может стать создание региональных хабов по модели Иннополиса (стимулирование роста не только в центре, но и на периферии), стабилизация налогового режима, доступность финансирования и поддержка компаний на этапе pre-IPO. Рост за пределами центра уже виден в статистике Новосибирска, Казани и Томска (+2 позиции за год у каждого города в национальном рейтинге по версии StartupBlink). Участники рынка прямо связывают срывы сделок <nobr>2025–2026</nobr> годов с нестабильностью правил. Консенсус-прогноз предполагает снижение ключевой ставки к ~12% к концу 2027 года, что исторически совпадает с оживлением венчурной активности. Также важна поддержка на этапе pre-IPO — от программы «Путь к IPO» до специализированных фондов поздних стадий. И наконец, развитие частного посевного капитала — бизнес-ангелов и синдикатов: именно это сегодня является самым узким местом всей цепочки.</p> <p>Сергей Меламед, руководитель дивизиона «Малый и микробизнес» Сбербанка, отметил: «Исследование показало, что российский рынок ИТ-стартапов обладает значительным потенциалом, но для его реализации требуется решение системных вопросов, связанных с ценой капитала и предсказуемостью условий ведения бизнеса. Инфраструктура поддержки выстроена на всех этапах, но высокая ставка и налоговая нагрузка мешают работать в полную силу. Чтобы запустить следующий цикл роста, нужно сместить фокус на регионы, обеспечить стабильность налогового режима, доступность финансирования и поддержку на этапе pre-IPO».</p> <p>Международная конференция Московский стартап-саммит, посвящённая технологическому предпринимательству и открытым инновациям, проходит <nobr>29-30</nobr> сентября в «СберСити», в пространстве крупнейшего кампуса «Школы 21». Организаторы мероприятия — Сбер и Правительство Москвы.</p> На середину 2026 года число ИТ-субъектов достигло 273 тысяч — в эту категорию входят юридические лица … message https://www.itweek.ru/themes/detail.php?ID=235641 Wed, 30 Sep 2026 10:00:52 +0300 <p><em>Гилл Хаус, </em><em>CIO</em> <em>Chase (подразделение JPMorgan Chase & Co, отвечающее за розничный банкинг), рассказал порталу </em><em>ZDNet</em> <em>о подходе Chase к внедрению искусственного интеллекта и о том, почему так важно заложить правильный фундамент.</em></p> <p>Опыт показывает, что извлечение реальной пользы из технологий ИИ — задача непростая. Поскольку 91% специалистов <a href="https://www.itweek.ru/ai/article/detail.php?ID=235443">признают</a>, что их компании пока не достигают желаемых результатов в этой сфере, руководителям и сотрудникам предстоит проделать большую работу, чтобы превратить экспериментальные проекты в полезные для бизнеса сервисы.</p> <p><a name="OLE_LINK3">По словам Хауса, он </a>осознал, что <a name="OLE_LINK5">создание ценности в эпоху ИИ </a>— это нечто большее, чем просто решение внедрить модную модель или сервис. «Заявить о стремлении к эффективности, поставив перед собой цель, — это одно, а переосмыслить бизнес-процессы через призму использования ИИ-агентов — совсем другое», — говорит он.</p> <p>Как отмечает Хаус, крайне важно понимать, что роли и обязанности сотрудников будут меняться: ИИ уже трансформирует характер работы персонала Chase — как в ИТ-департаменте, так и в других подразделениях. «Мы видим, что наш традиционный инженер, который раньше занимался написанием кода, теперь способен на большее, — говорит он. — А менеджер по продукту, который раньше лишь формулировал задачи (писал пользовательские истории), теперь может сам писать программный код».</p> <p>По мере того как ИИ-агенты становятся частью внутренней операционной среды, рабочее пространство превращается в пространство совместной деятельности людей и ИИ.</p> <p>Хаус отмечает, что в Chase эта трансформация уже заметна — особенно в процессах разработки и в том, как меняется роль инженеров. Влияние новых технологий проявляется неожиданным образом: еще полгода назад подобное показалось бы удивительным. «На самом деле теперь я не нанимаю инженеров для того, чтобы они писали код. Понимаю, это звучит странно, ведь именно этим инженеры и должны заниматься, — признается он. — Но сегодня я нанимаю инженеров, чтобы они разбирались, какой именно код нужно написать. И в этом огромная разница. Раньше — еще полгода назад — код приходилось писать вручную. Теперь же в этом нет необходимости, ведь на помощь приходит ИИ-агент. Благодаря этому исчезает рутина, которая раньше мешала инженерам заниматься тем, что им действительно нравится».</p> <p>Итак, уделяя пристальное внимание результатам, а не просто процессу выполнения задач, как именно Хаус обеспечивает правильный подход к внедрению ИИ? Ответ на этот вопрос строится на трех ключевых принципах: создании бесшовных сервисов, выпуске безопасных продуктов и обеспечении надежных результатов.</p> <h3>1. Создание бесшовных сервисов</h3> <p>По словам Хауса, в его организации уделяют особое внимание роли ИИ в операционной модели, а все сотрудники проходят обучение эффективному использованию этих инструментов.</p> <p>Важнейшим элементом этого подхода является LLM Suite — внутренняя платформа компании, использующая агентные технологии; с ее помощью сотрудники могут задавать вопросы, анализировать документы и составлять спецификации.</p> <p>Платформа LLM Suite была запущена летом 2024 г.; она предоставляет доступ к большим языковым моделям — как передовым проприетарным решениям, так и Open Source-моделям — в защищенной среде. «Это платформа, которой может пользоваться любой сотрудник организации, — рассказывает Хаус. — Мы рассматриваем весь процесс в целом и используем технологии, чтобы устранить препятствия и раскрыть потенциал наших команд по всей компании».</p> <p>По его словам, сотрудники используют эту агентную платформу и встроенные в нее модели для создания новых продуктов и услуг: «Если у нас есть определенный сценарий взаимодействия с клиентом и мы можем использовать технологии, чтобы сделать его лучше или персонализированнее, мы это делаем».</p> <p>В качестве примера Хаус приводит использование новейших технологий для улучшения качества обслуживания клиентов, обращающихся в банк по телефону. «Мы применяем машинное обучение для распознавания намерений клиента, чтобы быстро перенаправить его к нужному специалисту, — поясняет он. — Во время разговора мы используем аналогичные технологии, чтобы понять, какие действия клиент, вероятно, хочет совершить».</p> <p>По словам Хауса, залог успеха — в глубоком встраивании агентов и алгоритмов в операционные процессы, будь то работа сотрудника с внутренним интерфейсом или использование клиентом веб-сервиса либо мобильного приложения.</p> <p>Новейшие технологии доступны сотрудникам Chase, которые ежедневно работают с этими системами, однако для клиентов банка их внутренняя «механика» должна оставаться незаметной и работать бесшовно. «Настоящая магия заключается в том, чтобы упростить жизнь клиенту — так, чтобы он даже не осознавал, что качество обслуживания улучшилось, — говорит Хаус. — Для него всё просто работает».</p> <h3>2. Выпуск безопасных продуктов</h3> <p>Хотя качественное обслуживание клиентов с применением ИИ крайне важно, применяемые для этого продукты должны быть безопасными, а защите данных необходимо уделять первостепенное внимание. По словам Хауса, поскольку Chase работает в секторе с жестким регулированием, банк предъявляет высокие требования к новым технологиям: «Мы действуем взвешенно и придерживаемся уже отработанных подходов, позволяющих двигаться быстро, но ответственно».</p> <p>Защита данных, а также соблюдение требований конфиденциальности и получение согласия пользователей — обязательные условия. «Если мы используем данные для каких-либо целей, мы обязательно информируем об этом клиентов, — отмечает Хаус. — Мы никогда не станем использовать данные небезопасным образом или в нарушение наших внутренних политик и нормативных требований, касающихся конфиденциальности и соблюдения законодательства. Эти принципы критически важны независимо от того, идет ли речь о традиционных моделях машинного обучения или об агентных технологиях».</p> <p>Вопросы безопасности касаются не только взаимодействия с клиентами. Хаус добавляет, что ИИ помогает Chase и во внутренних процессах — в частности, обеспечивая быструю и эффективную разработку ПО.</p> <p>Он отмечает, что инструменты на базе ИИ помогают использующим их специалистам выявлять ошибки, предотвращать действия злоумышленников и повышать качество обслуживания клиентов. Для других специалистов и бизнес-руководителей главным принципом безопасной разработки ПО в эпоху ИИ становится проактивность. «Я считаю невероятно важным продолжать следить за тем, чтобы помимо того что мы делаем для обеспечения хорошей работы ИИ, мы всегда были сосредоточены на нашем периметре, гарантируя, что мы обновляем наше ПО и что мы работаем над своевременным устранением уязвимостей, — говорит Хаус. — Такой проактивный подход гарантирует, что мы сможем защищать наших клиентов по мере того, как меняется окружающий мир».</p> <h3>3. Обеспечение надежных результатов</h3> <p>В агентных технологиях модели выступают в роли механизма рассуждений, прогнозирующего следующее действие с наибольшей статистической вероятностью. К сожалению, агенты, подобно людям, действуют на вероятностной основе, и, по словам Хауса, такая природа этих систем может приводить к непредвиденным последствиям. «Вы не всегда будете получать один и тот же ответ, — отмечает он. — Это имеет меньшее значение, когда вы ищете рецепт. Хотя если у вас получится майонез другого типа, это может стать некоторой проблемой. Но когда вы хотите что-то сделать со своими финансами, результат должен быть правильным».</p> <p>Хаус считает, что бизнес-лидеры должны обеспечить защитные меры, оценки и результаты, которые укрепляют доверие и создают уверенность в том, что агентные технологии могут использоваться в больших масштабах. «Во многих случаях решение заключается в том, чтобы оставить человека в центре процесса, и в Chase реализовано немало подобных сценариев», — рассказывает он.</p> <p>Возвращаясь к теме разработки ПО и к своему утверждению о том, что Chase не нанимает инженеров для написания кода, Хаус поясняет, что в эпоху агентов практически любой человек — независимо от того, является ли он ИТ-специалистом, — может создать приложение с помощью инструментов для кодирования на базе ИИ. Поэтому ему нужны квалифицированные инженеры-эксперты, которые смогут определить, когда агенты работают эффективно и правдиво, и он советует другим бизнес-лидерам обратить на это внимание.</p> <p>«Продумать и внести ясность в отношении того, что должно быть правдой в результате создания ПО — от масштаба до компонентов, которые необходимо использовать, до того, как оно должно быть спроектировано — это самые сложные задачи», — говорит он.</p> <p>Chase стремится к тому, чтобы сотрудники использовали автономные ИИ-системы, однако для безопасного и эффективного масштабирования сервисов необходима надежная базовая архитектура. «Какие у нас шаблоны? Как мы можем гарантировать, что следуя этим шаблонам наши люди создавали ПО, обеспечивающее нужный им результат, а не просто получали что-то, что выдает модель и что не продумано целостно? Нам нужны ответы на эти вопросы, — говорит Хаус. — Это та часть, которую я считаю фундаментальной и которую нам необходимо уловить. И вы можете сделать это в своей организации иными способами, чем просто использовать своих талантливых инженеров для написания кода».</p> Гилл Хаус, CIO Chase (подразделение JPMorgan Chase   Co, отвечающее за розничный банкинг), рассказал порталу ZDNet … article https://www.itweek.ru/themes/detail.php?ID=235640 Tue, 29 Sep 2026 16:44:55 +0300 <p>Компания «Аладдин» сообщила о получении сертификата ФСТЭК России № 5111 на средство многофакторной аутентификации MFA JaCarta-3. Срок действия сертификата — до 17 сентября 2031 года.</p> <p>Сертификат подтверждает, что MFA JaCarta-3 является программно-техническим средством многофакторной аутентификации и соответствует требованиям документа «Требования по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий» (ФСТЭК России, 2020):</p> <ul> <li>по 2 уровню доверия (работа с гостайной, комплектация с Aladdin SecurLogon, устройствами аутентификации на аппаратной платформе JaCarta-3, «Единым Клиентом JaCarta», без использования биометрии);</li> <li>по 4 уровню доверия (комплектации с Aladdin SecurLogon, устройствами на аппаратных платформах JaCarta-2 и JaCarta-3, «Единым Клиентом JaCarta», с использованием биометрии).</li> </ul> <p>Назначение MFA JaCarta-3:</p> <ul> <li>многофакторная аутентификация при доступе к защищённым информационным ресурсам;</li> <li>безопасное хранение ключевой информации СКЗИ и цифровых сертификатов;</li> <li>применение в информационных системах персональных данных (ИСПДн) до 1 уровня защищённости;</li> <li>применение в автоматизированных системах (АС) классов защищённости 1Д, 1Г;</li> <li>применение в государственных информационных системах (ГИС) до 1 класса защищённости.</li> </ul> <p>Ключевые возможности:</p> <ul> <li>работа в корпоративных системах с развёрнутой инфраструктурой открытых ключей (PKI). При отсутствии инфраструктуры PKI: многофакторная аутентификация в Windows с помощью компонента JaCarta SecurLogon (в составе ПО «Единый Клиент JaCarta»), в Linux — с помощью Aladdin SecurLogon;</li> <li>штатная поддержка USB-токенов и смарт-карт JaCarta в продуктах мировых вендоров.</li> </ul> <p>В состав продукта входят PKI-клиент с поддержкой средств многофакторной аутентификации в Linux Aladdin SecurLogon, средство администрирования «Единый Клиент JaCarta», различные USB-токены и смарт-карты JaCarta, в том числе — новейшие JaCarta-3 ГОСТ и JaCarta-3 РКІ/ГОСТ, выполненные в металлических корпусах с разъёмами Type-A и Type-С. Также в составе решения — персональный USB-токен с биометрической идентификацией по отпечаткам пальцев JaCarta SecurBIO и биометрический смарт-карт ридер Enterprise-класса Aladdin SecurBIO Reader. </p> Компания «Аладдин» сообщила о получении сертификата ФСТЭК России № 5111 на средство многофакторной аутентификации … message https://www.itweek.ru/themes/detail.php?ID=235639 Tue, 29 Sep 2026 16:42:21 +0300 <p>Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — Postgres Pro Enterprise Manager (PPEM) 2.10. Главным нововведением релиза стал анализатор нагрузки Healthcheck Advisor, выявляющий отклонения в работе СУБД и формирующий рекомендации по их устранению. Также в версию вошли поддержка внешних хранилищ для истории активных сеансов, кастомизация дашбордов и графическое отображение топологии кластера.</p> <p>Ключевым изменением платформы стало внедрение модуля Healthcheck Advisor. Инструмент помогает администратору перейти от ручного анализа метрик к проактивному подходу и предметному разбору инцидентов: система автоматически проверяет телеметрию по заданному расписанию или по требованию. Механизм диагностирует широкий спектр проблем, включая длительные транзакции, взаимоблокировки, задержки репликации, сбои контрольных сумм и деградацию процессов autovacuum.</p> <p>Все обнаруженные события привязываются к конкретным экземплярам и метрикам, а также распределяются по уровням критичности: Critical, High, Medium и Low. В едином обзоре администратор сразу видит узлы с наибольшим числом рисков, а при переходе к деталям получает контекст: значение метрики, правило детекции, время фиксации и шаги по локализации сбоя. При необходимости периметр проверок и список анализируемых параметров можно гибко настраивать.</p> <p>«Развитие встроенных интеллектуальных механизмов — последовательный шаг в развитии продуктов Postgres Pro. Появление Healthcheck Advisor логично расширяет линейку наших инструментов с применением ИИ, где ранее уже был представлен интеллектуальный ассистент по СУБД. Мы планомерно усиливаем аналитические возможности платформы, помогая администраторам не просто фиксировать аномалии в телеметрии, а получать готовую контекстную экспертизу для быстрого принятия решений», — прокомментировал Борис Пищик, руководитель продукта Postgres Pro Enterprise Manager в компании Postgres Professional.</p> <p>В части работы с телеметрией в PPEM 2.10 реализована поддержка внешних хранилищ для данных Active Session History (ASH). Если ранее история сеансов сохранялась исключительно во встроенной базе репозитория, то теперь ее можно перенести во внешние БД, снизив нагрузку и утилизацию дискового пространства управляющего сервера. Пользователи могут прямо из веб-интерфейса регистрировать новые хранилища, назначать целевую базу по умолчанию и централизованно управлять параметрами подключений.</p> <p>Интерфейс платформы получил развитые средства персонализации и наглядного контроля. На странице обзора экземпляра теперь можно кастомизировать дашборд: добавлять, скрывать и переставлять виджеты таблиц, счетчиков и графиков с сохранением единой компоновки между сессиями. Кроме того, состав отказоустойчивых кластеров теперь доступен в виде наглядной топологической схемы, которая дополняет классические таблицы, а также упрощает визуализацию и навигацию по кластерным архитектурам. </p> <p>Платформа также получила ряд инфраструктурных и эксплуатационных доработок:</p> <ul> <li>в регламентах обслуживания репозитория появился лимит максимального времени исполнения правил («Rule execution timeout, sec»);</li> <li>при восстановлении базы из резервной копии добавлена возможность сразу указывать параметры конфигурации, пресеты настроек и имя службы systemd;</li> <li>включены готовые пресеты графиков WAL Usage и WAL Archiving для углубленного контроля за журналами предзаписи;</li> <li>оптимизированы внутренние конвейеры для бесперебойной обработки больших массивов объектов и обновлены нормы сайзинга ресурсов;</li> <li>исправлен пул уязвимостей безопасности (CVE), а системный стек Go обновлен до версии 1.27.</li> </ul> <p>Обновление Postgres Pro Enterprise Manager 2.10 уже доступно пользователям. Инструкции по переходу и подробный перечень изменений опубликованы в документации продукта.</p> Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — … message https://www.itweek.ru/themes/detail.php?ID=235638 Tue, 29 Sep 2026 13:01:17 +0300 <p>Компания «Аладдин» объявила о запуске программы авторизованного обучения технических специалистов работе с корпоративным центром сертификации Aladdin Enterprise CA. Курсы будут проходить в Академии АйТи (акционер — ГК Softline), которая стала первым партнёром «Аладдин» в области сертифицированного обучения продуктам компании. Дата начала курсов — 2 ноября.</p> <p>Программа сертификации разработана Центром компетенций «Аладдин». Первыми в неё вошли курсы по работе с корпоративным центром сертификации Aladdin Enterprise CA (Aladdin eCA) и технологиям инфраструктуры открытых ключей (PKI) — направлению, в котором «Аладдин» обладает одной из самых глубоких экспертиз на рынке. На старте слушателям доступны два курса.</p> <p>«Основы технологий PKI» (курс eCA 101) — вводный курс продолжительностью 8 академических часов. 2 ноября слушатели разберутся в целях, принципах и алгоритмах асимметричной криптографии, изучат шифрование, хеширование и электронную подпись, познакомятся с концепцией доверия и принципами работы центров сертификации, узнают о сертификатах открытого ключа и их жизненном цикле, а также познакомятся с особенностями работы с Aladdin Enterprise CA. Отдельный блок курса посвящён практике применения сертификатов открытого ключа в корпоративной среде — в задачах двухфакторной аутентификации, электронной подписи и электронного документооборота.</p> <p>«Внедрение Aladdin Enterprise CA в корпоративной среде» (курс eCA 102) — инженерный курс продолжительностью 24 академических часа с лабораторным практикумом. С 3 по 6 ноября слушатели получат практические навыки развёртывания инфраструктуры открытых ключей. В частности, они обучатся установке корневого и подчинённого удостоверяющих центров, их интеграции с операционными системами и службами каталогов, настройке двухфакторной аутентификации и многому другому.</p> <p>Оба курса ориентированы на инженеров ИТ и ИБ, участвующих во внедрении Aladdin Enterprise CA, а также на студентов профильных вузов. Обучение проходит в очном и онлайн-форматах.</p> <p>По итогам обучения и сдачи экзаменов по первым двум курсам выпускники получат статус сертифицированного специалиста Aladdin eCA (ACS-eCA), который подтверждает базовые знания в области Aladdin eCA и позволяет эффективнее внедрять продукт в системах заказчиков. В дальнейшем линейка курсов и сертификационных статусов будет расширена: в перспективе выпускники смогут претендовать на статусы сертифицированного инженера и сертифицированного архитектора Aladdin eCA, которые подтвердят готовность специалиста проектировать сложные корпоративные решения. Наличие в штате сертифицированных специалистов по Aladdin eCA даст компаниям возможность получить более высокий партнёрский статус «Аладдин».</p> <p>«Для корпоративной ИТ-инфраструктуры PKI — основа. „Аладдин“ последовательно проводит импортозамещение этих технологий, ранее представленных на российском рынке западными компаниями. Мы развиваем компетенции ИБ-специалистов, выстраивая вместе с партнёрами учебную базу. Академия АйТи стала нашим первым партнёром в этой области, но в ближайших планах — открытие центров компетенций на базе ведущих интеграторов. Чтобы поддержать эти центры, мы передаём лидерам корпоративного ИТ-образования необходимые курсы. Это непростая задача, так как до сих пор не существовало системного решения, которое объединяло бы знания и технологии и позволяло бы комплексно развивать компетенции российских ИБ-специалистов в построении PKI на основе национальных технологий», — прокомментировал Леонид Шапиро, руководитель Центра компетенций «Аладдин». </p> <p>«Информационная безопасность динамично развивается, и компании ежедневно сталкиваются с новыми вызовами: эволюцией кибератак, необходимостью импортозамещения и ростом требований к квалификации специалистов. Академия АйТи развивает многопрофильный портфель авторизованного обучения, предлагая рынку постоянно растущую линейку образовательных программ по продуктам российских вендоров. Запуск курсов по Aladdin eCA и PKI расширяет возможности комплексной подготовки ИБ-специалистов по работе с отечественными решениями, способствуя развитию корпоративной информационной безопасности на рынке в целом», — прокомментировал куратор направления «Информационная безопасность» Академии «АйТи» Михаил Шепелев.</p> Компания «Аладдин» объявила о запуске программы авторизованного обучения технических специалистов работе … message https://www.itweek.ru/themes/detail.php?ID=235636 Tue, 29 Sep 2026 10:10:08 +0300 <p><em>Если тимлид работает с внешними зарубежными моделями, ему нужно выбирать: либо давать ИИ только обезличенные данные, либо оставлять часть рабочих сценариев за пределами автоматизации.</em></p> <p><em>С появлением ИИ внутри закрытого корпоративного контура возможностей стало заметно больше. Рассмотрим, что именно поменялось и что это даёт бизнесу.</em></p> <h3>Ограничения облачных моделей</h3> <p>Проще всего использовать ИИ-агента в облачном контуре у провайдеров, которые уже зарекомендовали себя: чаще всего это OpenAI или Anthropic. Возможности этих моделей покрывают большую часть сценариев, которые нужны руководителю — анализ рисков, распределение задач, подготовку материалов для найма.</p> <p>При работе с зарубежными провайдерами есть важное ограничение: часть сценариев упирается в данные. Их нельзя просто передать внешней модели: по закону компании нужно соблюдать требования к обработке и трансграничной передаче данных, а также собственные правила информационной безопасности.</p> <p>Из-за работы с персональными данными информацию о сотрудниках приходится обезличивать и ограничивать доступ к рабочим системам. Поэтому ИИ в таком варианте не может участвовать в процессах напрямую.</p> <h3>Преимущества закрытого контура</h3> <p>Сейчас начинает набирать популярность другой вариант — использовать ИИ внутри корпоративного контура. Агент работает с актуальными данными портала и в правах конкретного пользователя: видит доступные задачи, проекты, оргструктуру и другие сущности.</p> <p>Закрытый контур снимает часть ручной работы вокруг ИИ: агент может обращаться к корпоративным данным непосредственно в системе и использовать их в доступных ему сценариях. За счёт этого ИИ постепенно встраивается в повседневные рабочие процессы.</p> <p>Ниже разберем несколько сценариев, где эта разница особенно заметна.</p> <h3>Тестовые задания при найме</h3> <p>С облачными провайдерами тимлид сам описывал стек, уровень позиции и типовые задачи команды. Получалось так, что тестовое задание строилось в основном по пересказу и требовало ручной доработки.</p> <p>В работе внутри инфраструктуры компании агент может опираться на реальные задачи отдела. За счёт этого тестовое задание ближе к тому, с чем кандидат действительно столкнётся в работе.</p> <h3>Распределение задач между сотрудниками</h3> <p>Раньше для работы с ИИ приходилось вручную составлять профили сотрудников: описывать сильные стороны, опыт, загрузку. Тогда модели понимали, кто сколько делает и кому какую задачу лучше отдать в зависимости от умений. Но такие профили устаревают, а обновлять их можно только вручную.</p> <p>В закрытом контуре агент сам может видеть актуальную информацию по каждому человеку, и это даёт более свежую картину загрузки. Хотя окончательное решение всё равно за руководителем: усталость, мотивацию и другие человеческие факторы компьютеры пока не понимают.</p> <h3>Анализ рисков и сроков</h3> <p>При использовании сторонних технологий ИИ оценивал реалистичность плана в основном по общим знаниям и тому контексту, который передал тимлид. В итоге выводы часто оставались достаточно общими.</p> <p>Если информация остаётся в компании, ИИ-инструмент получает возможность сопоставить оценку с историей конкретной команды и увидеть: сколько времени занимали похожие задачи? Где возникали задержки? Какие узкие места есть сейчас? Всё это уточняет прогнозы модели.</p> <p>При этом числовые показатели нужно рассчитывать на стороне API или кода, а ИИ использовать для анализа результатов и формулировки выводов.</p> <h3> Рефлексия — разбор управленческих решений </h3> <p>В этом сценарии тимлид использует ИИ как собеседника, чтобы разобрать собственное решение до того, как его принять.</p> <p>Вместо того чтобы отбирать контекст таких обсуждений, агентов закрытого контура можно подключить ко всем важным каналам информации. Если говорить о бизнес-портале, то такими источниками будут чаты и звонки, встречи и задачи, сотрудники, отделы, проекты, CRM, база знаний и завершённые сеансы работы с агентом. Причём все это собирается в пределах прав конкретного сотрудника.</p> <h3>Передача результата команде</h3> <p>Некоторые процессы при использовании зарубежных моделей для тимлида были невозможны совсем. Например, работа с внешней моделью в основном остаётся личным пространством тимлида: он отдельно готовит контекст, а полученный результат для сотрудников пересказывает или переносит в другие инструменты.</p> <p>Внутри одной экосистемы результат можно сразу вернуть в рабочую среду.</p> <h3>Работа с календарём команды</h3> <p>Внешний ИИ тоже можно подключить к календарю технически, но для рабочего календаря компании это ограничено из-за отсутствия доступа сторонней модели к данным сотрудников и требований безопасности.</p> <p>Если агент работает внутри контура и в правах пользователя, он может свободно обращаться к доступным календарям непосредственно на портале. Например, найти общий свободный слот нескольких сотрудников без ручной сверки расписаний.</p> <h3>Что в итоге меняется для тимлида</h3> <p>Закрытый контур делает работу с ИИ удобнее: агент становится частью постоянных рабочих процессов и может участвовать в повседневных задачах без постоянной ручной подготовки данных вокруг каждого запроса.</p> <p>Все управленческие решения остаются за человеком. ИИ помогает собрать факты и подготовить варианты, а тимлид учитывает то, чего нет в системе: состояние людей, отношения внутри команды и реальную сложность ситуации.</p> <p>#IMAGE_235637#</p> Если тимлид работает с внешними зарубежными моделями, ему нужно выбирать: либо давать ИИ только обезличенные данные … article Владимир Верхотуров, тимлид DevRel-команды ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=235635 Tue, 29 Sep 2026 10:03:48 +0300 <p><em>Навкендар Сингх, вице-президент IDC India по направлениям клиентских устройств и IPDS, рассказывает в корпоративном блоге о том, что показала Всемирная конференция по робототехнике (WRC) 2026 г. в плане перехода физического искусственного интеллекта (Physical AI) к практическому внедрению.</em></p> <p>WRC’ 2026 прошла в Пекине в августе под девизом «Симбиоз человека и машины: интеграция производства и спроса». В мероприятии приняли участие более 300 компаний, представивших свыше 2000 продуктов, включая более 150 новинок. Впервые в программу конференции был включен специальный «День закупок»: 49 китайских государственных предприятий выступили единым инновационным консорциумом, обозначив реальный промышленный спрос по 12 сценариям применения.</p> <p>Робототехника становится все более ориентированной на конкретные задачи, а изменения со стороны спроса теперь стимулируют масштабный рост отрасли. Статистика подтверждает эту тенденцию. По данным Министерства промышленности и информатизации КНР, выручка крупных предприятий робототехнической отрасли страны за период с января по май 2026 г. превысила 90 млрд. юаней (13,4 млрд. долл.), увеличившись на 26,9% по сравнению с аналогичным периодом прошлого года. Собственные данные IDC свидетельствуют о том, что в 2025 г. мировые поставки человекоподобных роботов достигли примерно 18 тыс. единиц, показав рост почти на 800% в годовом исчислении.</p> <p>Исследования IDC также показывают, что большинство предприятий, проводящих пилотные проекты с использованием роботов, наделенных воплощенным интеллектом (embodied intelligence), пока остаются на стадии проверки концепции. Между этапами проверки технологии и ее масштабного внедрения существует ряд реальных препятствий: вопросы стабильности работы, стоимости, окупаемости инвестиций (ROI), а также организации повседневной эксплуатации и технического обслуживания. </p> <p>Впрочем, экспозиция этого года продемонстрировала более высокий уровень развития технологий. Роботы выполняли задачи целиком, а не ограничивались отдельными действиями, причем некоторые из них работали в реальных производственных, а не в лабораторных условиях. Конкуренция в сфере физического ИИ теперь разворачивается не только в области технических характеристик, но и в возможностях промышленного внедрения. Четыре ключевых тренда, выявленных на конференции, наглядно иллюстрируют эту ситуацию.</p> <h3>Тренд первый: гонка моделей уступает место обучению в реальных условиях</h3> <p>За последний год произошел значительный прогресс в области больших моделей воплощенного интеллекта, моделей, объединяющих компьютерное зрение, обработку естественного языка и управление роботами (VLA, Vision-Language-Action) и моделей реальности (world models). Это позволило роботам выйти за рамки простого восприятия и понимания окружающей среды и перейти к принятию решений и выполнению сложных комплексных задач. В нынешнем году характер конкуренции меняется: теперь важнее не то, чья модель мощнее, а то, какой поставщик сможет заставить роботов работать и обучаться в реальных сценариях. Модели служат фундаментом возможностей физического ИИ, однако именно данные из реального мира и непрерывное обучение станут определяющими факторами успеха на следующем этапе развития.</p> <p>На конференции WRC’ 2026 неизменный интерес вызывали модели реальности, системы VLA, платформы для симуляции, полигоны для обучения роботов и технологии сбора данных. Объединение виртуальной и реальной сред становится важным способом получения данных: симуляция позволяет генерировать их в больших объемах, данные из реальных сценариев обеспечивают привязку к действительности, а их сочетание снижает затраты на метод проб и ошибок. Поступление операционных данных обратно в цикл обучения запускает своего рода маховик: восприятие — обучение — выполнение — получение обратной связи — непрерывное совершенствование.</p> <p>В Китае уже запланировано создание или ведется строительство более 40 полигонов для обучения роботов, охватывающих свыше 14 провинций и муниципалитетов. Наиболее развитые из них способны генерировать миллионы записей данных в год. Одновременно с этим постоянное совершенствование манипуляторов (роботизированных рук), датчиков усилия и других аппаратных компонентов расширяет возможности роботов по сбору более информативных данных о манипуляциях. Поскольку модели, данные, симуляции и аппаратное обеспечение начинают развиваться взаимосвязанно, конкуренция между компаниями все меньше зависит от того, чья модель показывает лучшие результаты в тестах, и все больше — от способности превратить операционные данные в эффективный цикл обучения.</p> <h3>Тренд второй: от демонстрации возможностей к масштабируемому внедрению</h3> <p>По мере того как роботы выходят в реальную бизнес-среду, меняются и критерии их оценки. На конференции этого года ряд поставщиков перешли от демонстрации отдельных действий к проверке комплексных рабочих процессов, включающих депаллетизацию, сортировку, доставку, уборку и инспекцию. Теперь они демонстрируют работоспособность полноценных процессов, а не разрозненных функций. Главная грань, разделяющая игроков в сфере робототехники, сместилась от технических демонстраций к обеспечению стабильной работы и внедрению решений.</p> <p>Под функциональными возможностями теперь понимается непрерывная работа, а не выполнение разовой операции: от роботов требуются автономное восприятие, планирование задач, непрерывное выполнение действий и способность самостоятельно справляться с нештатными ситуациями. Внедрение — это более серьезное испытание. Переход от этапа проверки концепции к реальной эксплуатации означает, что заказчики повышают требования к стабильности, эффективности развертывания, стоимости обслуживания и окупаемости инвестиций, а ключевыми полигонами для такой проверки становятся автомобильная промышленность, сектор 3C-электроники (компьютеры, телекоммуникационное оборудование и бытовая электроника) и складская логистика. Вместе с этим изменились и показатели, на которые реально ориентируются покупатели: это доля успешно выполненных задач, время непрерывной работы, стоимость выполнения одной задачи и срок окупаемости, а не технические характеристики, которые вендоры демонстрируют в ходе презентаций.</p> <p>Исследование IDC показывает, что более 20% пользователей уже перешли от этапа ознакомления с рынком к пилотным проектам, а темпы перехода от проверки концепции к полномасштабному внедрению растут. Стабильность работы, скорость развертывания, текущее обслуживание и коммерческая окупаемость — именно эти факторы станут критериями, по которым будут различаться вендоры в ближайшие два-три года.</p> <h3>Тренд третий: от прорывов в отдельных сценариях к поэтапному внедрению</h3> <p>Технологии физического ИИ не смогут масштабироваться сразу на все возможные сценарии. Различия в уровне технической зрелости, сложности рабочей среды и аспекты коммерческой окупаемости определяют поэтапный путь внедрения: в сфере коммерческих услуг идет этап изучения возможностей, в промышленности — этап расширения масштабов, а в сегменте бытового и потребительского использования закладывается фундамент для будущего развития.</p> <ul> <li><strong> Сфера коммерческих услуг находится на стадии глубокого изучения возможностей.</strong> В таких областях, как общественное питание, гостиничный бизнес и розничная торговля, существует четкий спрос на автоматизацию конкретных задач, однако рабочая среда здесь сложнее, чем на производстве. Это требует от роботов более совершенных систем автономной навигации, понимания окружающего пространства и обработки нестандартных ситуаций. Внедрение воплощенного интеллекта в этом секторе ускоряется, но происходит осторожно.</li> <li><strong> Промышленное производство станет лидером по темпам масштабирования. </strong>Такие отрасли, как автопром, 3C-электроника и складская логистика, характеризуются относительно упорядоченными процессами, четкими границами задач и высокой потребностью в снижении издержек и повышении эффективности. По данным IDC, объем китайского рынка промышленных роботов с воплощенным интеллектом в 2025 г. составил около 5,74 млрд. юаней (из них 3,62 млрд. пришлось на долю традиционных промышленных роботов, а 2,12 млрд. — на долю гуманоидных роботов). Именно здесь наблюдается наилучшее сочетание технической зрелости и коммерческой ценности.</li> <li><strong> Рынок бытовых и потребительских роботов обладает долгосрочным потенциалом.</strong> Домашняя среда отличается высокой степенью неструктурированности и разнообразием задач (в том числе редких и нестандартных), что предъявляет повышенные требования к способности робота к обобщению опыта, безопасности, навыкам взаимодействия и стоимости устройства. Тем не менее, потенциальная сфера применения достаточно широка, а возможности рынка в долгосрочной перспективе — значительны.</li> </ul> <p>Процесс внедрения роботов будет продвигаться от сред с высокой степенью упорядоченности к средам с умеренной, а затем и низкой структурированностью; при этом различные форм-факторы роботов будут все точнее подбираться под конкретные сценарии использования.</p> <h3>Тренд четвертый: конкуренция на уровне отдельных устройств уступает место конкуренции системных возможностей</h3> <p>По мере перехода физического ИИ к этапу промышленного внедрения цепочка создания стоимости в робототехнике расширяется: она перестает ограничиваться лишь аппаратной платформой и теперь одновременно включает в себя вычислительные мощности, модели, данные, ключевые компоненты и прикладные решения. В конференции этого года приняли активное участие компании из всей отраслевой цепочки (как китайские, так и зарубежные), а 49 государственных предприятий выступили единым инновационным консорциумом. Конкуренция смещается от поставок отдельных технологий к сотрудничеству в рамках отраслевой цепочки и совместной разработке сценариев применения; в результате границы конкурентной борьбы между предприятиями расширяются, охватывая вопросы взаимодействия аппаратного и программного обеспечения, а также построения экосистем.</p> <ul> <li><strong> Углубляется сотрудничество в рамках производственной цепочки: </strong>ускоряется взаимодействие между платформами для роботов и производителями ключевых компонентов, таких как чипы, датчики, редукторы, сервосистемы и системы захвата (роботизированные руки).</li> <li><strong> Происходит ускоренное сближение программных моделей и аппаратного обеспечения:</strong> разработчики больших моделей, производители роботов и научно-исследовательские институты совместно работают над созданием VLA-моделей, моделей реальности и систем управления движением.</li> <li><strong> Ускоряется формирование систем поддержки отрасли.</strong> По всему Китаю уже открыты десятки инновационных центров, специализирующихся на воплощенном интеллекте; их деятельность охватывает все этапы: от разработки технологий и пилотной проверки до обучения на данных и внедрения в реальных сценариях.</li> <li><strong> Расширяется круг участников международного сотрудничества:</strong> конференция привлекла 30 зарубежных организаций, представляющих сферы научных исследований, инжиниринга, промышленности и инвестиций.</li> </ul> <p>Наилучшие шансы на переход от локальных вариантов использования к масштабному коммерческому внедрению имеют компании, обладающие наиболее развитыми способностями к формированию экосистемы, а не просто те, у кого самый совершенный отдельный продукт.</p> <h3>Прогноз IDC</h3> <p>Технологии физического ИИ переходят от стадии демонстрации возможностей к этапу подтверждения их промышленной ценности. Ключевая конкурентоспособность робототехнических компаний будет зависеть не столько от технического совершенства решений, сколько от способности превратить эти технологии в надежные, тиражируемые продукты, обладающие реальной коммерческой ценностью. Физический ИИ вступает в фазу глубокой индустриализации, и на следующем этапе конкуренции в сфере робототехники основное внимание будет уделяться реальному спросу и реальной ценности.</p> <p>Ближайшие два-три года станут важным периодом перехода роботов с воплощенным интеллектом от стадии проверки технологий к этапу масштабного внедрения. В различных сферах применения будет наблюдаться поэтапный процесс развертывания: первыми возможности использования начнут осваивать сервисные сценарии, промышленный сектор станет ключевым направлением для масштабного внедрения, а рынок бытовых и потребительских решений будет обладать долгосрочным потенциалом развития. Одновременно с этим физический ИИ сместит акцент в отраслевой конкуренции с характеристик отдельных аппаратных средств на системные возможности, формируемые за счет интеграции моделей, данных, оборудования и прикладных решений.</p> Навкендар Сингх, вице-президент IDC India по направлениям клиентских устройств и IPDS, рассказывает … article https://www.itweek.ru/themes/detail.php?ID=235633 Mon, 28 Sep 2026 16:21:26 +0300 <p>Российский рынок услуг DevOps as a Service (DaaS) по итогам 2025 года предварительно оценивается в 16,2 млрд рублей — это 17,1 % от общих затрат на ИТ-аутсорсинг, объём которого составил около 95 млрд рублей. Таковы данные исследования «Российский рынок DevOps as a Service <nobr>2025–2030»</nobr> от «Квадрант Технологий», в котором приняли участие 200 организаций малого, среднего, крупного и крупнейшего бизнеса (выручка от 25 млрд рублей).</p> <p>Ключевой вывод исследования: рынок находится в состоянии системного противоречия. Спрос на управляемый сервис сформировался, но модель закупки за ним не поспевает — компании покупают набор работ там, где им нужна управляемая эксплуатация с явной ответственностью исполнителя за результат.</p> <p>Лидерами рынка по объёму выручки остаются универсальные системные интеграторы, у которых DevOps as a Service в большинстве проектов остаётся встроенной функцией, а не самостоятельным направлением закупки — его доля в бюджете, как правило, не превышает 10 %. Среди же специализированных DevOps-компаний наибольшую долю занимает «Флант».</p> <p>При инерционном сценарии среднегодовой рост рынка (CAGR) до 2030 года составит около 5 %, а объём затрат на услуги DaaS достигнет 22 млрд рублей. В ускоренном сценарии — при переходе к платформенным моделям и росте спроса на управляемые сервисы — рост может составить <nobr>15–25 %</nobr> в год.</p> <p>Заказчики пока склоняются к классическому ИТ-аутсорсингу: около 40 % всех затрат на аутсорсинг направляется на сервисы информационной безопасности, а DevOps as a Service ещё не имеет чёткого позиционирования среди целевой аудитории.</p> <p>Рынок DevOps as a Service находится на переходном этапе: модель потребления услуг пока отстаёт от уровня зрелости самой отрасли. Сформировавшийся спрос на управляемый сервис с ответственностью за результат ещё не в полной мере отражается в практике закупок, которая во многом опирается на привлечение отдельных специалистов и разовые работы.</p> <p>Это отражает общую тенденцию: отрасль постепенно смещается от модели аутстаффинга к сервисному и инженерному подходу. На первый план выходит запрос на качественное сопровождение production-систем (24/7, SLA, работа с инцидентами), предсказуемые модели оказания услуг и встроенные практики безопасной разработки.</p> <p>Проблема номер один для всех категорий респондентов — нехватка квалифицированных DevOps-специалистов (31,5 %), за ней следуют обеспечение безопасности (29,5 %) и сопровождение CI/CD (29 %). При этом сильнее всего дефицит компетенций ощущается в части DevSecОps и соответствия регламентам РБПО (35,5 %), DataOps (29 %) и observability (28,5 %).</p> <p>Показательно, что дефицит смещён не в сторону «модных» технологий, а в сторону критичных для стабильности и безопасности компетенций. Компании научились внедрять инструменты быстрее, чем формировать команды, способные их стабильно и безопасно эксплуатировать.</p> <p>По факту DevOps в большинстве организаций — это набор отдельных практик, а не целостная инженерная модель. Наиболее распространены базовые практики: observability (32,5 %), безопасная разработка (31,5 %) и Infrastructure as Code (31 %), тогда как DataOps используют лишь 21,5 %, а MLOps — всего 4,5 % опрошенных.</p> <p>Исключительно на аутсорсинг DevOps отдаёт лишь десятая часть всех респондентов. Основной моделью становится гибридный подход, сочетающий аутсорсинг с внутренними ресурсами: его используют 56 % компаний малого и среднего бизнеса (выручка 500 млн — 3 млрд рублей) и 42 % компаний крупного бизнеса. Большинство крупнейших организаций (59 %) пока предпочитают реализовывать всё самостоятельно, ссылаясь на наличие собственных ресурсов.</p> <p>Однако наличие собственной команды не устраняет дефицит компетенций, а лишь маскирует его. Рынок уже движется к сервисной модели, но пока не готов полностью отдать DevOps внешним провайдерам — при этом справляться своими силами получается всё хуже.</p> <p>В ближайшие <nobr>1–2</nobr> года компании ожидают перехода к более централизованной DevOps-модели с едиными стандартами и платформой (28 %) и развития DevOps как внутреннего сервиса (27,5 %). DataOps, observability и SRE постепенно становятся частью базового контура, а сама эволюция DevOps в сторону внутренней платформы и сервисной модели открывает рынок DevOps as a Service.</p> <p>Отдельная особенность рынка — характер принятия решений. DevOps as a Service остаётся «инициативой снизу, но покупкой сверху»: потребность формируют инженеры, но деньги и финальное решение — на уровне руководства. Сам выбор провайдера строится скорее на доверии и репутации, чем на формальных процедурах.</p> Российский рынок услуг DevOps as a Service (DaaS) по итогам 2025 года предварительно оценивается в 16,2 млрд … message https://www.itweek.ru/themes/detail.php?ID=235632 Mon, 28 Sep 2026 16:18:51 +0300 <p>Команда iTPROTECT, специализированного интегратора в области информационной безопасности, обновила облачный сервис проверки защищённости внешнего ИТ-контура iTPROTECT Scout 2.0. Среди ключевых изменений — обновленная методика оценки рисков, разграничение прав доступа к персональным данным, проверка механизмов защиты почты от фишинга и встроенный искусственный интеллект (ИИ).</p> <p>Число киберугроз постоянно растет, но одновременно расширяется и цифровой периметр компаний. Новые онлайн-сервисы, клиентские платформы, домены и IP-адреса увеличивают число уязвимостей и точек входа, часть из них остается вне поля зрения служб информационной безопасности. Защита внешнего периметра требует непрерывного автоматизированного контроля с помощью инструментов класса EASM (External Attack Surface Management) или CPT (Continuous Penetration Testing), которые позволяют вовремя обнаружить и устранить уязвимости. </p> <p>В ответ на запрос рынка компания iTPROTECT в 2025 году вывела сервис непрерывного мониторинга и контроля защищенности внешнего ИТ-контура — iTPROTECT Scout. Сервис осуществляет 11 этапов проверки внешнего периметра: находит доступные извне активы, проверяет их на уязвимости с использованием 9 источников (включая БДУ ФСТЭК России, CISA KEV и National Vulnerability Database), считает и приоритизирует риски, а также формирует отчёты с оценкой влияния угроз на бизнес и рекомендациями по их устранению.</p> <p>За год команда разработчиков усовершенствовала инструмент, дополнив его рядом функций и новыми алгоритмами сканирования. В частности, благодаря его новой архитектуре скорость сканирования периметра по некоторым направлениям выросла более чем в <nobr>2-3 раза.</nobr> Это делает iTPROTECT Scout одним из самых производительных на рынке в этом классе решений. Также разработчики обновили личный кабинет, расширив возможности сортировки уязвимостей.</p> <p>iTPROTECT Scout 2.0 включает 58 функций. Центральным обновлением стала новая методика оценки рисков внешнего периметра. Проверка проводится по 6 направлениям: сетевая безопасность, безопасность веб-приложений, раскрытие информации (например, доступные извне файлы настроек), утечки данных, безопасность почты и DNS, управление поверхностью атаки. Для найденных уязвимостей отображается факт наличия готовых эксплойтов, это позволяет приоритизировать задачи по устранению угроз с высокими рисками.</p> <p>Также важным обновлением стала возможность многопользовательского доступа к личному кабинету с разграничением прав. Решение позволяет вести сразу несколько проектов мониторинга в филиальных сетях и открывает доступ к персональным данным из утечек только при наличии у пользователя прав. Не менее значимая модификация — проверка защищенности электронной почты (SPF, DKIM, DMARC) от фишинговых рассылок от имени компании.</p> <p>Часть функций в новой версии автоматизирована с помощью локальной модели ИИ (работает без подключения внешних источников). Например, она формирует чек-листы проверки эксплуатируемости обнаруженных уязвимостей и переводит их описание на русский язык. </p> <p>«Динамика киберугроз и изменение ИТ-ландшафта компаний создают риски все новых атак. Наш сервис позволяет выявлять устаревшее ПО, незакрытые тестовые среды и сервисы, ошибки конфигурации, фишинговые сайты, утечки учетных данных или слабые пароли. Эти проблемы требуют постоянного мониторинга. Пентеста, проводимого пару раз в год, недостаточно для непрерывной оценки защищенности организации. iTPROTECT Scout позволяет отслеживать все то, что происходит между этими проверками», — отметил Дмитрий Иняев, директор по развитию продуктов и услуг iTPROTECT.</p> <p>Сервис iTPROTECT Scout включен в Единый реестр отечественного программного обеспечения Минцифры России и его успели оценить более 80 российских организаций. </p> Команда iTPROTECT, специализированного интегратора в области информационной безопасности, обновила облачный сервис проверки … message https://www.itweek.ru/themes/detail.php?ID=235631 Mon, 28 Sep 2026 16:15:53 +0300 <p>CNews опубликовал первый рейтинг российских коробочных решений для управления знаниями, ориентированных на задачи крупного бизнеса. KMS-платформы (от англ. Knowledge Management System — системы управления корпоративными знаниями) оценивались по ключевым блокам: создание и управление контентом, поиск, ИИ-возможности, настройка оформления, поддержка.</p> <p>Главный вывод: базовый функционал — хранение, публикация, поиск, разграничение прав — уже закрыт большинством решений на рынке. Конкуренция смещается в сторону гибкости, адаптации под бизнес-процессы и задачи компании, интеграций, зрелости ИИ-сценариев и способности закрывать в едином контуре клиентский опыт (CX) и опыт сотрудников (EX).</p> <p>По большинству функциональных блоков InKnowledge (L2U, входит в группу компаний BSS) обошла конкурентов и заняла первую строчку. Платформа стала лидером по возможностям создания и управления контентом: поддерживает 22 типа готового контента «из коробки» — от статей и сценариев до BPMN-процессов и омниканальных материалов. Пользователи могут самостоятельно создавать новые типы контента и шаблоны, не обращаясь к вендору. </p> <p>InKnowledge — единственное решение в обзоре, которое предоставляет вариативность отображения результатов поиска: карточки, списки, таблицы, сниппеты. Кроме того, платформа отличается максимальной гибкостью в настройке оформления под разных пользователей и роли. В части ИИ: встроенная генерация ответов по базе знаний компании (RAG), собственная большая языковая модель (LLM) и возможность задавать отдельные инструкции для ИИ-модели по каждому сайту и разделу. </p> <p>«Как лидеры рынка, мы рады видеть развитие российских решений вместе с потребностями бизнеса — они становятся гибче, лучше адаптируются к разным корпоративным сценариям и помогают сотрудникам и клиентам в повседневных задачах. Такие платформы постепенно превращаются в надежный инструмент, который сопровождает ключевые процессы компании и делает работу со знаниями более эффективной», — прокомментировал Дмитрий Лактионов, директор продуктового направления Базы знаний компании BSS.</p> <p>В ходе исследования, эксперты обратили внимание на смену парадигмы. Во-первых, крупный бизнес всё чаще запрашивает не базу знаний для отдельного подразделения, а единую платформу, объединяющую разрозненные решения. Во-вторых, KMS закрывает сразу два направления — клиентский опыт (CX) и опыт сотрудников (EX). В-третьих, генеративный ИИ перестаёт быть только «умным поиском». Следующий шаг — ИИ-агенты, подключённые к базе знаний и способные выполнять цепочки действий с обращением к внешним системам. И наконец, усиливается тренд на контекстную подачу знаний. </p> <p>Для бизнеса это означает, что выбор современной системы управления знаниями (уровня InKnowledge) позволяет не просто «оцифровать регламенты», а получить инструмент, который снижает время на поиск информации, ускоряет адаптацию новых сотрудников и напрямую влияет на качество клиентского сервиса за счет мгновенной выдачи контекстных ответов. Инвестиции в платформы с поддержкой ИИ-агентов и оркестрации сегодня — это фундамент для снижения издержек и повышения конкурентоспособности в условиях, где скорость принятия решений играет ключевую роль.</p> CNews опубликовал первый рейтинг российских коробочных решений для управления знаниями, ориентированных на задачи крупного … message https://www.itweek.ru/themes/detail.php?ID=235628 Mon, 28 Sep 2026 11:55:30 +0300 <p><em>Ежегодно в мире регистрируются десятки тысяч новых доменов. И далеко не все — добросовестно. Кто-то использует чужой бренд для продажи контрафакта, кто-то — для перенаправления чужого трафика на себя. Бизнес теряет клиентов и репутацию. </em><em>Рассмотрим, к</em><em>ак защитить онлайн-актив, когда идти в российский суд, а когда — в международный арбитраж</em><em>,</em><em> и почему промедление грозит потерей домена</em><em>.</em></p> <p>Компания на протяжении длительного времени вкладывает ресурсы в развитие бренда, рекламу и поддержание репутации. При этом третьи лица могут зарегистрировать домен, включающий товарный знак этой компании, и использовать его для открытия собственной торговой площадки или для перехвата клиентского потока. Также возможен вариант, когда регистратор предлагает выкупить домен по завышенной цене. Отдельный риск — регистрация домена с последующим предложением правообладателю выкупить его по завышенной цене. В зависимости от обстоятельств такие действия могут квалифицироваться как недобросовестное использование доменного имени и служить основанием для судебного или внесудебного доменного спора.</p> <p>К недобросовестному использованию относятся:</p> <ul> <li> <strong>Киберсквоттинг</strong> — регистрация домена, включающего в себя чужой бренд, с целью перепродажи.</li> <li><strong>Тайпсквоттинг</strong> — регистрация домена с ошибкой в написании (например, nik.ru вместо nic.ru).</li> <li><strong>Использование чужого товарного знака в домене</strong> для привлечения трафика или продажи подделок.</li> <li><strong>Фишинг и иные мошеннические сценарии</strong> — использование похожего доменного имени для создания видимости официального ресурса правообладателя.</li> </ul> <p>При этом само по себе сходство доменного имени с брендом еще не означает нарушения. Для юриста важно оценить совокупность обстоятельств: права на обозначение, наличие у администратора самостоятельного законного интереса и признаки недобросовестной регистрации или использования домена.</p> <h2>Два показательных примера</h2> <h3>Кейс № 1: eBay подала жалобу сама на себя</h3> <p>Компания внесла свои товарные знаки в Trademark Clearinghouse, но забыла, что домены были зарегистрированы на уполномоченную компанию. Спустя время юристы eBay обнаружили «нарушение» и подали жалобу в WIPO (ВОИС, Всемирная организация интеллектуальной собственности). Арбитр, разобравшись, постановил передать домены в непосредственное управление eBay. Уполномоченная компания не возражала. История закончилась без конфликта, но с лишними затратами времени и денег.</p> <p>Вывод для юриста: доменный портфель нужно вести централизованно. В реестре должны быть указаны все домены компании, их администраторы, регистраторы, сроки продления, основания регистрации и лица, имеющие доступ к управлению. Иначе компания может потратить время и деньги на спор, которого можно было избежать внутренним аудитом.</p> <h3>Кейс № 2: ChatGPT (OpenAI) против администратора chatgpt.com</h3> <p>OpenAI долгое время использовала поддомен chat.openai.com, а заявку на товарный знак ChatGPT подала только 27 декабря 2022 года. Но 13 декабря некто зарегистрировал домен chatgpt.com. OpenAI обратилась в WIPO. Несмотря на то, что формально товарный знак был зарегистрирован позже, комиссия учла известность бренда по «общему праву» (common law rights) — к тому моменту сервис уже имел миллионы пользователей.</p> <p>Решение: домен передан OpenAI. Этот кейс показывает, что в UDRP имеет значение не только дата формальной регистрации товарного знака, но и доказательства фактического использования обозначения, его узнаваемости и риска смешения. Поэтому при подготовке жалобы важно собирать не только сведения о товарном знаке, но и подтверждения публичного использования бренда: публикации, рекламные материалы, данные об аудитории, скриншоты сайта и другие доказательства известности обозначения.</p> <h2>Два пути: российский суд и международный арбитраж</h2> <p>Восстановить свои права можно двумя способами. Они отличаются тем, в каких доменных зонах зарегистрировано имя.</p> <ul> <li><strong>Первый</strong> путь — российский суд. Это касается доменов в российских национальных зонах .ru, .рф, .su. В таких спорах ключевое значение имеют правильная формулировка требований, доказательство нарушения исключительного права и своевременное применение обеспечительных мер, чтобы спорный домен не был передан или аннулирован до окончания процесса.</li> <li><strong>Второй</strong> путь — внесудебная процедура UDRP. Когда домены в международных зонах .com, .org, .net, а также в новых доменных зонах верхнего уровня, например, .online, .shop, .tech и другие. Здесь действует Единая политика рассмотрения споров о доменных именах (UDRP), разработанная ICANN — международной некоммерческой организацией, отвечающей за координацию системы доменных имен. Это внесудебная процедура: жалоба подается в один из аккредитованных арбитражных центров: WIPO, ADR Forum, Чешский арбитражный центр, Азиатский центр ADNDRC (полный перечень доступен на сайте ICANN). Решение принимается в среднем за два месяца и обязательно для исполнения регистратором. Именно этот механизм используют крупные международные корпорации. Для правообладателя одно из преимуществ UDRP — формализованный предмет доказывания и сравнительно короткий срок рассмотрения спора.</li> </ul> <p>По <a href="https://cctld.ru/media/news/industry/39470/">статистике</a> WIPO, за 2025 год по процедуре UDRP поступило 6 282 жалобы. 90% из них касались доменов в зоне .com. В результате 79% споров завершились передачей домена истцу, 15% — урегулированы по соглашению сторон, 5% — отклонены, 1% — прекращены. Цифры наглядно демонстрируют эффективность внесудебного подхода.</p> <h2>Судебная процедура в России: пошаговый алгоритм</h2> <p>Если домен, нарушающий ваши права на товарный знак, зарегистрирован в зонах .ru, .рф или .su, нужно обращаться в российский суд. Процесс состоит из четырех этапов.</p> <h3>1. Досудебные ограничения (14 дней) для доменов .ru и .рф</h3> <p>Еще до подачи иска можно временно «заморозить» домен. Для доменов в .ru и .рф через <a href="https://cctld.ru/help/trademark/disputs/claim.php">веб-форму</a> Координационного центра .RU/.РФ правообладатель направляет регистратору заявление о нарушении. Регистратор обязан установить в реестре ограничения на 14 календарных дней. В этот период администратор домена не может передать его иному лицу, сменить регистратора или аннулировать.</p> <p>Этот механизм не решает спор по существу, но позволяет сохранить статус-кво и выиграть время для подготовки иска и ходатайства об обеспечительных мерах. Использовать его стоит сразу после обнаружения нарушения, особенно если есть риск быстрой передачи домена третьему лицу.</p> <h3>2. Подача иска и обеспечительные меры</h3> <p>Ключевой момент — правильная формулировка исковых требований. Типичная ошибка: просить просто запретить использование домена. Такого требования может оказаться недостаточно для последующей перерегистрации домена на правообладателя. Для последующей перерегистрации домена на правообладателя нужно заявить хотя бы одно из требований:</p> <ul> <li> запрет администратору использовать в доменном имени обозначение, права на которое принадлежат истцу;</li> <li> запрет администратору использовать соответствующее доменное имя;</li> <li> признание администрирования домена нарушением прав правообладателя.</li> </ul> <p>Одновременно с иском подавайте ходатайство об обеспечении иска. Суд может запретить администратору и регистратору любые действия по аннулированию регистрации домена, передаче прав администрирования домена иному лицу и передачу поддержки сведений о домене иному регистратору. Если суд по каким-то причинам откажет в обеспечении, есть запасной вариант: обратиться к регистратору с просьбой установить срочные ограничения на 90 дней (для доменов .ru и .рф) и на 60 дней (для доменов .su) на основании уже принятого к производству иска. Многие правообладатели не знают об этой возможности, а зря — домен может быть продан или переоформлен за считанные часы.</p> <p>Для корпоративного юриста это важный резервный инструмент: судебный процесс может занимать месяцы, тогда как передать домен другому администратору или изменить регистратора можно значительно быстрее.</p> <h3>3. Предмет взыскания</h3> <p>Сложность в том, что единой практики по доменным спорам в РФ нет. Суды опираются на статьи 1484 и 1252 ГК РФ, а также на принцип недопустимости недобросовестной конкуренции (статья 14.6 Закона о защите конкуренции). Ключевые обстоятельства, которые нужно доказать:</p> <ul> <li> доменное имя тождественно или сходно до степени смешения с товарным знаком;</li> <li> у администратора нет законного интереса в использовании этого домена;</li> <li> домен используется недобросовестно (например, предлагается к продаже, либо на сайте размещена реклама конкурентов).</li> </ul> <p>Доказательства стоит фиксировать сразу после обнаружения нарушения: сделать скриншоты сайта, сохранить предложения о продаже домена и переписку с администратором, зафиксировать редиректы, рекламу конкурентов, использование обозначения, продажу контрафакта или фишинговые формы. Чем раньше это сделано, тем ниже риск, что содержание сайта изменится еще до подачи иска.</p> <h3>4. Исполнение решения</h3> <p>Решение суда вступило в силу, иск удовлетворен. Теперь у вас есть 30 дней (для доменов .ru и .рф) и 60 дней (для доменов .su) на преимущественную регистрацию домена. Вы подаете регистратору заявление о реализации преимущественного права регистрации доменного имени, копию решения, ссылку на карточку дела. Регистратор обращается в Координационный центр .RU/.РФ за выдачей ключей для перерегистрации. Если пропустить этот срок, домен не переоформят. По его истечении регистратор обязан аннулировать регистрацию этого доменного имени.</p> <p>На практике часто возникают ситуации, когда правообладатели приходят через два месяца и пытаются оспорить отказ в суде — безуспешно. Второй вариант — отказаться от преимущественной регистрации и попросить аннулировать домен. Однако после аннулирования любой желающий может зарегистрировать тот же домен в ту же секунду, и вы потеряете актив навсегда либо вам предстоит еще один судебный процесс. Поэтому рекомендуем выбирать перерегистрацию на себя.</p> <h2>Внесудебная процедура UDRP: быстро и предсказуемо</h2> <p>Для международных доменов в зонах .com, .org, .net и других процедура принципиально иная. UDRP — это политика, которую администратор домена принимает автоматически при регистрации домена (условие прописано в оферте регистратора). Спор рассматривает арбитражная комиссия, а не национальный суд.</p> <p>Основания для подачи жалобы: три обязательных условия</p> <p>Для подачи жалобы в рамках процедуры доменного спора необходимо одновременное соблюдение трех условий:</p> <ul> <li> доменное имя идентично или сходно до степени смешения с товарным знаком истца;</li> <li> у администратора нет законного права или интереса в отношении домена;</li> <li> домен зарегистрирован и используется недобросовестно (киберсквоттинг, предложение о продаже, создание ложной ассоциации с брендом).</li> </ul> <p>Что по UDRP считается недобросовестным использованием? В первую очередь — киберсквоттинг: продажа, предложение о продаже товаров и услуг, предложение к продаже самого доменного имени. Также — размещение на сайте рекламы конкурентов, попытка перенаправить трафик на свой ресурс, использование домена для фишинга. При этом для заявителя недостаточно просто сослаться на наличие товарного знака. Нужно последовательно показать все три элемента UDRP, в том числе отсутствие у администратора прав или законного интереса и признаки недобросовестной регистрации и использования домена.</p> <h2>Механизм действия</h2> <p>Жалоба подается в один из аккредитованных арбитражных центров. Лидер по числу споров — <a href="https://www.wipo.int/amc/ru/domains/">WIPO</a>. Лучше использовать его: там есть русскоязычные арбитры, а форму и шаблоны можно заполнить онлайн на русском языке. Хотя окончательное решение и переписка ведутся на английском языке, но можно ходатайствовать о русском языке, если администратор и регистратор находятся в РФ. По состоянию на сентябрь пошлина WIPO по UDRP составляет $1500 для спора по <nobr>1-5</nobr> доменам при рассмотрении дела одним арбитром. Для <nobr>6-10</nobr> доменов — $2000, при коллегии из трех арбитров стоимость выше. За эту сумму можно включить в одну жалобу до пяти доменных имен, даже с разными администраторами.</p> <p>Арбитражная комиссия устанавливает администратора и накладывает ограничения на домен на весь срок рассмотрения спора. Решение выносится в среднем за два месяца. Исполнение — 10 рабочих дней. Регистратор обязан передать домен истцу или аннулировать его в зависимости от решения. Единственное, что может приостановить исполнение, — подача иска в национальный суд (пункт 4(k) UDRP). Но на практике таких случаев мало, если арбитраж признал недобросовестность, шансов выиграть в суде у администратора практически нет.</p> <h2>Рекомендации для защиты домена компании</h2> <p>Для минимизации рисков, связанных с недобросовестным использованием доменных имен, рекомендуется придерживаться следующего порядка действий.</p> <ul> <li><strong>Проведите аудит доменного портфеля. </strong>Убедитесь, что все ключевые домены (включая варианты с транслитерацией, дефисами, распространенными опечатками) зарегистрированы на саму компанию, а не на подрядчиков или сотрудников. Если самостоятельно это сделать сложно, обратитесь к регистратору. Например, в Руцентре специалисты проводят полноценный аудит доменного портфеля и в случае необходимости помогают консолидировать домены компании.</li> <li><strong>Зарегистрируйте товарный знак. </strong>Без него вы либо вовсе не сможете инициировать ни судебную процедуру, ни UDRP, либо сделать это будет ощутимо сложнее. Для международных споров важно заранее оценить, в каких юрисдикциях компании действительно требуется защита обозначения, и сформировать доказательства его фактического использования.</li> <li><strong>Внедрите мониторинг новых регистраций.</strong> Сервисы вроде Trademark Clearinghouse или просто регулярные проверки через WHOIS помогут вовремя заметить киберсквоттера. Отдельно имеет смысл отслеживать тайпо-домены, схожие обозначения и ресурсы, которые могут создавать у пользователей ложную ассоциацию с брендом.</li> <li><strong>Собирайте доказательства сразу после обнаружения нарушения.</strong> Зафиксируйте содержание сайта, дату проверки, редиректы, предложения о продаже домена, переписку и другие обстоятельства, которые впоследствии могут подтвердить недобросовестность администратора.</li> </ul> <p>При обнаружении нарушения — сразу действуйте по алгоритму:</p> <ul> <li><strong>Для зон .ru/.рф:</strong> подайте досудебное ограничение (на 14 дней) через форму Координационного центра .RU/.РФ. Одновременно готовьте иск с требованиями и ходатайство об обеспечении. В случае отказа в обеспечении — запросите у регистратора срочные ограничения на 90 дней (для доменов .ru и .рф) и на 60 дней (для доменов .su). После выигранного решения не пропустите <nobr>30-дневный</nobr> срок (для доменов .ru и .рф) и на <nobr>60-дневный</nobr> срок (для доменов .su) для обращения к регистратору за реализацией преимущественного права регистрации домена.</li> <li><strong>Для международных зон:</strong> соберите доказательства недобросовестности — скриншоты предложений о продаже, переписку, где администратор просит выкуп. Подайте жалобу в WIPO за 1 500 долларов (до 5 доменов).</li> <li><strong>Не соглашайтесь на аннулирование домена. </strong>Всегда требуйте регистрации на себя. Аннулированный домен может перерегистрировать кто угодно, и вы начнете борьбу заново.</li> </ul> <p>Доменные споры — объективная реальность для любого крупного и среднего бизнеса, имеющего онлайн-присутствие. Эта реальность требует системного подхода: от аудита портфеля до четкого понимания различий между судебной процедурой и внесудебной UDRP. Своевременное использование досудебных ограничений, правильная формулировка исковых требований и выбор правильной юрисдикции — залог того, что ваш онлайн-актив останется с вами. Не ждите, пока киберсквоттер предложит выкупить ваш же бренд. Действуйте на опережение.</p> <p>#IMAGE_235629#</p> Ежегодно в мире регистрируются десятки тысяч новых доменов. И далеко не все — добросовестно. Кто-то … article Наталья Туркина, руководитель отдела претензионной работы и судебного представительства группы “Рунити” https://www.itweek.ru/themes/detail.php?ID=235627 Mon, 28 Sep 2026 11:01:32 +0300 <p><em>Агентам искусственного интеллекта необходима специализированная инфраструктура. Селена Чеккинель, старший менеджер по маркетингу продуктов компании CoreWeave, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как оптимизировать среды выполнения для многоэтапных агентных рабочих процессов.</em></p> <p>Вы создали отличного агента, но что-то пошло не так, когда он перешёл в продакшен.</p> <p>В тестовой среде ваш агент эффективно самостоятельно просматривал запросы на слияние (PR). Он читал различия, искал в коде связанные использования, запускал набор тестов, проверял, не остался ли красный индикатор CI после предыдущего коммита, и составлял комментарий — и всё это до того, как вы сами закончили читать diff.</p> <p>Однако в продакшене те же пять шагов выполняются в связи с каждым вторым обзором PR, который агенты вашей команды выполняли в течение последнего часа. Некоторые ревью завершаются за секунды; другие задерживаются на минуты, потому что шаг набора тестов попадает на узел, который находился в процессе выполнения агентом другого пользователя.</p> <p>Агент не меняется. Меняется среда выполнения, и именно это определяет, остается ли время ревью стабильным или увеличивается.</p> <p>Агентные приложения используют иной шаблон выполнения, чем традиционные чат-приложения. Поскольку их рабочие процессы длиннее и динамичнее, инфраструктура оказывает гораздо большее влияние на задержку, надежность и стоимость, чем в случае простого чат-бота.</p> <p>Вот почему эффективность вашего агента зависит от вашей инфраструктуры.</p> <h3>Агенты — это не чат-боты с бóльшим количеством шагов</h3> <p>Разница между обслуживанием инференса чат-бота и агента ИИ заключается не просто в том, что один из них «более функционален». Они выполняют работу по-разному:</p> <ul> <li> Чат-бот обычно делает один вызов инференса на каждое сообщение пользователя. Модель получает промпт, генерирует ответ и ждет следующего ввода пользователя, прежде чем продолжить.</li> <li> Агент выполняет весь рабочий процесс, превращая одно сообщение пользователя в цепочку вызовов инференса. Он может решить провести поиск в документации, извлечь данные из базы данных, вызвать API, выполнить код, оценить результат, а затем повторить этот процесс, прежде чем выдать ответ. Каждое из этих решений может инициировать еще один вызов инференса, и каждый результат становится дополнительным контекстом для следующего шага.</li> </ul> <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> <ul> <li><strong> Пауза:</strong> агент ожидает ответа от внешнего API или базы данных, поэтому графический процессор (GPU), обслуживающий этот процесс, не выполняет задач по инференсу, а накопленный контекст может быть вытеснен из памяти GPU на время ожидания.</li> <li><strong> Всплеск:</strong> как только внешние системы возвращают результаты, инференс возобновляется одновременно для множества процессов, создавая кратковременные и резкие скачки нагрузки на GPU, причем каждый процесс заново обрабатывает весь накопленный контекст.</li> </ul> <p>Если при мониторинге загрузки GPU вы видите картину, напоминающую кардиограмму — ровную линию с резкими скачками в моменты получения результатов от инструментов, — это характерный признак. Это означает, что вы выделяете ресурсы исходя из средних показателей, тогда как нужно ориентироваться на пиковые; именно здесь чаще всего происходит незаметный, но критический рост задержки на уровне <nobr>99-го</nobr> перцентиля (p99).</p> <p>Сервисы инференса, рассчитанные на стабильные или предсказуемые потоки запросов, могут испытывать трудности с эффективным распределением ресурсов в таких условиях. Это приводит к нестабильной задержке, недоиспользованию GPU или росту эксплуатационных расходов.</p> <p>Непредсказуемая производительность или счета, не соответствующие ожиданиям, свидетельствуют о том, что ваша инфраструктура была спроектирована для иного типа нагрузки, чем тот, который вы фактически используете.</p> <h3>Как на самом деле выглядит инфраструктура для агентов</h3> <p>Агентные приложения предъявляют к инфраструктуре иные требования, чем традиционные задачи ИИ: длинные цепочки зависимостей, скачкообразный характер нагрузки и постоянное развитие. В таких условиях от инфраструктуры зависит, выдержит ли она цепочку процессов и не превысят ли расходы запланированный бюджет.</p> <p>Для работы агента необходима инфраструктура, специально созданная для обеспечения следующих возможностей:</p> <ul> <li><strong>Стабильная производительность на всей протяженности цепочки.</strong> Инфраструктура должна обеспечивать неизменную задержку при выполнении многоэтапных процессов, использующих различные инструменты.</li> <li><strong>Масштабируемость, отвечающая скачкообразным нагрузкам.</strong> Инфраструктура должна быстро масштабироваться при колебаниях спроса на инференс, не требуя резервирования мощностей в периоды простоя.</li> <li><strong>Предсказуемые затраты даже при динамических нагрузках.</strong> Счет за инфраструктуру должен отражать фактическое потребление ресурсов.</li> <li><strong>Ничто из этого не устраняет скачки нагрузки, но меняет способ их обработки системой.</strong> Достаточно мощный одновременный всплеск или рабочий процесс, накапливающий значительный объем контекста перед паузой, все равно требуют определенных затрат. Цель — не нулевые затраты или отсутствие лимитов, а их предсказуемость.</li> </ul> <p>Эффективность вашего агента напрямую зависит от качества инфраструктуры. При грамотном подходе быстродействие, надежность и экономическая эффективность агента станут залогом более продуктивной работы.</p> Агентам искусственного интеллекта необходима специализированная инфраструктура. Селена Чеккинель, старший менеджер … article https://www.itweek.ru/themes/detail.php?ID=235623 Fri, 25 Sep 2026 10:12:58 +0300 <p><em>Разница между двумя системами бесперебойного питания (ИБП) проявляется не только в счёте за электроэнергию. Она определяет, сколько мощности дойдёт до серверов, какой запас останется для роста и во что обойдётся незакрытый сценарий отказа.</em></p> <p>В закупке более дешёвый ИБП легко выигрывает таблицу сравнения. Но ЦОД покупает не просто шкаф с оборудованием. Он фактически покупает долю входной мощности, которая дойдёт до IT-нагрузки и сможет работать на бизнес.</p> <p>На объекте с IT-нагрузкой 1 МВт разница всего в один процентный пункт КПД — между 96,5 и 97,5% — означает примерно 10,6 кВт входной мощности. За год непрерывной работы это около 93 МВт·ч. Для коммерческого ЦОДа проценты из паспорта оборудования превращаются в вполне материальные киловатты и деньги.</p> <h3>Десять киловатт, которых не видно в цене закупки</h3> <p>Для примера возьмём две системы ИБП, работающие в одинаковом режиме и при сопоставимой нагрузке. IT-оборудованию нужно получить 1 МВт.</p> <ul> <li> при КПД 96,5% на входе потребуется 1000/0,965 = 1036,3 кВт;</li> <li> при КПД 97,5% — 1000/0,975 = 1025,6 кВт;</li> <li> разница — около 10,6 кВт.</li> </ul> <p>Если нагрузка остаётся постоянной весь год:</p> <p><em>10,6 кВт × 8760 часов ≈ 93 МВт·ч.</em></p> <p>Это результат только по цепочке электропитания. Дополнительный эффект от снижения тепловыделения и нагрузки на охлаждение нужно считать отдельно.</p> <p>Экономический смысл этих 10,6 кВт зависит от ограничений конкретного объекта.</p> <table> <tbody> <tr> <th> Ситуация</th> <th> Что даёт более высокий КПД</th> </tr> <tr> <td> На вводе есть запас, IT-нагрузка одинакова</td> <td> Снижение потребления электроэнергии и тепловыделения</td> </tr> <tr> <td> Мощность на вводе ограничена, есть спрос и резерв по остальной инфраструктуре</td> <td> Дополнительная мощность для IT-нагрузки</td> </tr> <tr> <td> Объект работает далеко от проектной загрузки</td> <td> Результат определяет реальная кривая КПД, а не паспортный максимум</td> </tr> </tbody> </table> <p>В первом сценарии денежный эффект можно оценить так:</p> <p><em>Экономия за год = разница потерь, кВт × часы работы × тариф.</em></p> <p>Во втором сценарии используется другая формула:</p> <p><em>Потенциальный годовой эффект = высвобождённая мощность, кВт × маржинальный доход с 1 кВт в месяц × 12.</em></p> <p>Эти эффекты нельзя автоматически складывать: это разные сценарии использования мощности. Чтобы не подменять расчёт красивой цифрой, оператор должен подставить собственные тарифы, загрузку и экономику продажи мощности.</p> <p>Например, при маржинальном доходе 16 тыс. рублей с 1 кВт в месяц потенциальный эффект от 10,6 кВт составит около 2 млн. рублей в год. Это не рыночный норматив и не обещание дохода, а иллюстрация формулы. Она работает только при наличии спроса и при условии, что охлаждение, распределение и площадь позволяют разместить дополнительную нагрузку.</p> <p>Один из вопросов, который я предлагаю задать проектной команде ещё до сравнения коммерческих предложений: сколько киловатт из оплаченной мощности в итоге действительно доберётся до серверов?</p> <h3>Максимальный КПД в каталоге может ничего не сказать о вашем объекте</h3> <p>Цифра «до 97,5%» выглядит убедительно, пока не уточнены условия измерения. Речь идёт об одном силовом модуле или обо всей системе? При какой загрузке получен результат? В штатной схеме N, при N+1 или в иной конфигурации? В онлайн-режиме или в режиме повышенной эффективности?</p> <p>Даже границы слова «система» могут отличаться. В расчёт иногда включают только ИБП, а иногда — ещё трансформаторы, распределение и собственное потребление вспомогательного оборудования. Поэтому сравнивать можно лишь значения, полученные при одинаковых границах измерения, нагрузке и режиме работы.</p> <p>Особенно осторожно следует относиться к экономичным режимам. В <a href="https://www.se.com/us/en/faqs/FAQ000244169/">классическом онлайн-режиме</a> энергия проходит через двойное преобразование, а инвертор постоянно формирует выходное напряжение. В <a href="https://www.se.com/us/en/faqs/FAQ000244169/">традиционном ECO-режиме</a> нагрузка обычно питается через статический байпас, пока параметры сети находятся в допустимом диапазоне. При отклонении система должна переключиться на инвертор.</p> <p>Поэтому вместе с КПД нужно проверять допустимый диапазон напряжения и частоты, время перехода, совместимость с нагрузкой и способность блоков питания пережить этот интервал. У разных архитектур высокоэффективного режима эти параметры отличаются; одного слова ECO в спецификации недостаточно.</p> <p>Для технического сравнения я бы запросила у поставщика четыре вещи:</p> <ol> <li> кривую КПД всей системы при 25, 50, 75 и 100% нагрузки;</li> <li> режим и конфигурацию резервирования, для которых получены значения;</li> <li> границы измерения и условия испытаний;</li> <li> параметры перехода и защиты в экономичном режиме.</li> </ol> <h3>Высокий КПД не компенсирует слабую архитектуру</h3> <p>Можно иметь резервный силовой модуль и всё равно сохранить единственную точку отказа. Вопрос не только в том, есть ли запасной модуль, а в том, насколько независимы ввод, статический байпас, управление, распределение и весь путь питания нагрузки.</p> <p>Для каждого отказа нужно проверить две вещи: сохранится ли питание критической нагрузки и как быстро система вернётся к исходному уровню резервирования.</p> <p>Параметры модуля также влияют на совокупную стоимость решения. Допустим, расчётная нагрузка составляет 480 кВт. При модулях по 60 кВт для штатной работы нужны восемь модулей, а девятый даёт схему N+1. При модулях по 50 кВт для покрытия нагрузки потребуются десять модулей: установленная мощность составит 500 кВт, но запас до номинала — только 20 кВт. Для N+1 нужен ещё один модуль.</p> <p>Это влияет на количество аппаратных единиц, размер шасси, шаг расширения, объём оплачиваемого резерва и требования к размещению. Но и здесь нет правила «чем мощнее модуль, тем лучше»: вместе с номиналом модуля растёт объём мощности, который система теряет при его отказе.</p> <h3>Один отказ способен обнулить экономию за несколько лет</h3> <p>Экономика ЦОДа не заканчивается после подсчёта дополнительных киловатт. Один серьёзный инцидент способен перекрыть эффект, который объект накапливал годами.</p> <p>По данным <a href="https://intelligence.uptimeinstitute.com/index.php/resource/annual-outage-analysis-2026">Uptime Institute</a>, 57% участников опроса 2025 года оценили стоимость своего последнего крупного сбоя более чем в 100 тыс. долл., а каждый пятый — более чем в 1 млн. долл. В том же исследовании проблемы электропитания названы ведущей причиной значимых отказов; среди основных источников указаны ИБП, автоматические переключатели и генераторы. Эти цифры нельзя напрямую переносить на российский объект, но они показывают порядок риска и объясняют, почему эффективность нельзя оценивать отдельно от устойчивости.</p> <p>Отказоустойчивость не заканчивается поставкой оборудования. Она зависит от архитектуры, мониторинга, доступности запасных частей и готовности людей действовать по заранее проверенному сценарию.</p> <h3>В 03:17 должен работать план, а не поиск контактов</h3> <p>В отчёте <a href="https://intelligence.uptimeinstitute.com/resource/annual-outage-analysis-2024">Uptime Institute за 2024 год</a> четыре из пяти респондентов, отвечавших о своём последнем серьёзном инциденте, считали, что его можно было предотвратить благодаря более качественному управлению, процессам или конфигурации.</p> <p>Даже идеально выбранный ИБП не поможет, если ночью дежурная смена впервые выясняет, кто имеет право на переключение, где находится запасной модуль и кому звонить после сигнала аварии.</p> <p>Рабочий план должен заранее отвечать как минимум на пять вопросов:</p> <ol> <li> Как система обнаружит развитие аварии до полного отказа?</li> <li> Что оператор делает немедленно, а какие действия требуют согласования?</li> <li> Кто доступен ночью и сколько времени займёт прибытие специалиста?</li> <li> Какие запасные модули и компоненты находятся на объекте или ближайшем складе?</li> <li> Как после ремонта проверить систему и восстановить исходное резервирование?</li> </ol> <p>Если ответы приходится искать уже во время аварии, простой начался задолго до первого сигнала тревоги.</p> <h3>Что проверить до закупки</h3> <p>Перед сравнением цен проектной команде стоит зафиксировать пять исходных условий.</p> <ol> <li><strong>Сколько мощности должна получить IT-нагрузка?</strong> Номинал ИБП ещё не показывает, сколько энергии дойдёт до серверов.</li> <li><strong>В каком диапазоне загрузки будет работать объект?</strong> Нужна кривая КПД, а не только максимальное значение.</li> <li> <strong>Какой отказ система должна пережить без остановки нагрузки?</strong> Резервирование модулей не устраняет общие точки отказа автоматически.</li> <li><strong>Что произойдёт при обслуживании?</strong> Следует заранее определить, сохранится ли резерв и допустим ли переход на байпас.</li> <li><strong>Как команда восстановит систему после отказа?</strong> Регламент, мониторинг, запасные части и порядок эскалации должны быть готовы до запуска.</li> </ol> <h3> Цена ИБП — только первая строка расчёта </h3> <p>Сравнивать системы бесперебойного питания только по CAPEX — всё равно что сравнивать автомобили по цене, не учитывая расход топлива, грузоподъёмность и вероятность простоя.</p> <p>Корректный вопрос звучит иначе: сколько полезной мощности останется у ЦОДа, какой отказ выдержит вся цепочка и как быстро команда восстановит резервирование?</p> <p>Именно эти ответы показывают реальную стоимость решения. Один процент КПД может оказаться незначительной строкой в спецификации — или превратиться в миллионы рублей. Разница возникает не в рекламном буклете, а в расчёте конкретного объекта.</p> <p>#IMAGE_235624#</p> Разница между двумя системами бесперебойного питания (ИБП) проявляется не только в счёте за электроэнергию. Она … article Юлия Камалдинова, руководитель проектов ГК “Темпесто” https://www.itweek.ru/themes/detail.php?ID=235622 Fri, 25 Sep 2026 09:58:00 +0300 <p><em>Анализ 623 млн. изменений кода, проведенный компанией GitClear, подтверждает реальность прироста производительности кодирования при использовании искусственного интеллекта, но также показывает, что он несопоставим с сопутствующими затратами на последующее сопровождение кода, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Стив Фентон, специалист по работе с сообществом Octopus Deploy.</em></p> <p>Значительная часть индустрии разработки ПО возлагает на ИИ-инструменты — от ранних чат-интерфейсов до современных систем, использующих рои автономных агентов — большие надежды с момента их появления. Однако в последние недели настроения изменились: например, поставщик HR-ПО Rippling добавил в свою систему панель мониторинга расходов на ИИ, позволяющую финансовым и техническим директорам контролировать затраты, а вице-председатель IBM Гэри Кон недавно заявил, что окупаемость инвестиций оказалась «далеко не такой высокой, как многие полагали». И пока в Северное полушарие приходит осенняя прохлада, для бюджетов на ИИ-инструменты, похоже, наступает зима.</p> <p>По мере того как организации будут приводить в порядок свои финансовые показатели, команды начнут ощущать давление в отношении бюджетов на использование таких инструментов, как Claude Code и Cursor. Это может обернуться либо ужесточением лимитов на использование там, где отдача неочевидна, либо нехваткой средств для поддержания текущих объемов работы.</p> <p>Организации, научившиеся измерять влияние ИИ, все чаще осознают: высокая скорость генерации кода не гарантирует улучшения ключевых показателей эффективности. Если оценивать продуктивность по количеству строк кода, числу запросов на изменения (pull requests) или даже по количеству реализованных функций, четкой связи с реальной ценностью продукта не прослеживается. Далеко не каждая строка кода или функция одинаково важны для бизнеса или клиентов; разброс в их значимости может быть колоссальным.</p> <p>Даже на уровне непосредственных результатов многие организации так и не поняли, как превратить локальные улучшения в комплексный рост эффективности всего процесса. Прирост скорости написания кода либо поглощается новыми задачами, порождаемыми самим же ИИ, либо нивелируется изменениями на последующих этапах разработки. Если вы не разобрались в особенностях потоков создания ценности до внедрения ИИ, попытки оценить окупаемость инвестиций могут стать для вас болезненным уроком.</p> <p>Если бы проблема сводилась лишь к сопоставлению затрат на ИИ-инструменты с конечной ценностью продукта, это уже было бы серьезно. Но происходит нечто гораздо более тревожное.</p> <h3>Продуктивность с точки зрения получаемых результатов</h3> <p>Давайте взглянем на данные, собранные и проанализированные GitClear для опубликованного в июне <a href="https://www.gitclear.com/the_ai_code_quality_maintainability_gap">отчета</a> «Maintainability Gap». В нем представлен анализ 623 млн. изменений, внесенных в период с 2023 по 2026 гг. По мере того как команды активно внедряют среды разработки с поддержкой ИИ и такие инструменты, как Cursor и Claude Code, база данных GitClear, отслеживающая операции с кодом, позволяет им выявлять и классифицировать дублирование кода, «горячие точки» (проблемные участки), а также признаки удачного или неудачного структурирования кода.</p> <p>Согласно отчету, активные пользователи ИИ увеличили собственную скорость работы на 25% по сравнению с предыдущими показателями — это далеко от заявлений о десятикратном росте. То же исследование показывает, что эти активные пользователи превосходят тех, кто не применяет ИИ, по объему выработки в <nobr>4-10 раз;</nobr> это может показаться противоречием, пока не вникнешь в суть того, кто именно эти люди. Команды, продемонстрировавшие более высокую продуктивность, показывали такие результаты еще до появления инструментов на базе ИИ. И не стоит забывать: нет никаких гарантий, что этот объем работы внесет реальный вклад в создание ценности для организации или ее клиентов.</p> <p>Первый этап расчета ROI — определение, оправдывают ли полученные результаты затраченные средства. Сильно удивлюсь, если для многих организаций ответ окажется утвердительным.</p> <p>Возможно, из-за того, что в дискуссиях об ИИ-инструментах упор делался преимущественно на скорость, другие факторы остались без должного внимания. Индустрия разработки ПО могла бы извлечь иную выгоду, если бы рассматривала эти инструменты не как гоночный болид, а как вилочный погрузчик: ведь скорость движения по прямой здесь не так уж впечатляет. Зато они способны выполнять тяжелую работу, сложную для нас, простых людей, — например, масштабные изменения в кодовой базе, такие как замена устаревшей, неподдерживаемой библиотеки на актуальный аналог.</p> <p>Для тех, кто успешно прошел этот первый этап, можно рассмотреть следующий фактор.</p> <h3>Продуктивность с точки зрения качества кода</h3> <p>Переход к использованию ИИ привел к кардинальным изменениям в поведении специалистов индустрии разработки ПО. На протяжении десятилетий постоянно подчеркивалась важность удобства сопровождения кода. Более половины книг по программированию на моей полке посвящены архитектуре, проектированию кода, связности компонентов и чистоте кода. Во многих из этих изданий затрагивается тема рефакторинга, подкрепленного автоматизированными тестами.</p> <p>Однако данные, полученные GitClear, свидетельствуют о совершенно иной тенденции: возврате к эпохе разработки по принципу «пиши и исправляй» («code-and-fix»). Согласно исследованию, за период с 2023 г. частота дублирования блоков кода выросла на 81% — с 40,3 до 73,0 случаев на миллион измененных строк. Множественные реализации одной и той же идеи начинают расходиться, порождая трудноуловимые ошибки, которые возникают вновь и вновь (подобно игре «Ударь крота»). Доля перемещенного кода — характерного признака рефакторинга — снизилась с 21% от общего объема измененных строк в 2022 г. до 3,8% в <nobr>2026-м;</nobr> это означает, что код становится сложнее для понимания, и с этой проблемой неизбежно столкнутся специалисты по сопровождению — независимо от того, используется ли ИИ.</p> <p>Внося подобные изменения, поначалу вы не ощущаете негативных последствий, так как находитесь на раннем этапе кривой затрат на сопровождение. Однако со временем растущие расходы станут непосильными. Увеличится доля задач по переделке кода, отнимающих время у разработки новых функций. На выявление и устранение даже незначительных проблем будет уходить слишком много времени, а многие из них просто станут частью системы, поскольку их исправление окажется экономически невыгодным. Накопление тесно связанных и запутанных фрагментов кода приведет к тому, что ПО утратит свою ценность.</p> <p>Мы пытались подтвердить заявления о десятикратном росте продуктивности благодаря ИИ-помощникам по кодированию. Данные свидетельствуют об обратном. До появления ИИ разработчики предпочитали рефакторинг копированию (copy-and-paste) кода в соотношении примерно два к одному. Теперь же они прибегают к копипасту кода примерно в пять раз чаще.</p> <h3>Технические практики — основная задача, а не второстепенное дело</h3> <p>Выступая на конференциях и встречах профессиональных сообществ с рассказами о том, как должен выглядеть качественный выпуск ПО, я упоминаю, в частности, автоматизацию тестирования и рефакторинг. В ходе последующей сессии вопросов и ответов неизбежно звучит вопрос: «Как получить разрешение руководства на внедрение этих практик?».</p> <p>Разработчиков жестко подгоняют, требуя быстрых результатов, поэтому они приучаются избегать всего, что кажется им второстепенным. Стремясь повысить производительность, они упрощают процесс написания кода, не оставляя времени на тесты или улучшение архитектуры, так как это замедлило бы выпуск новой функции. В конечном счете это приводит к значительному замедлению разработки любого функционала в долгосрочной перспективе.</p> <p>Преимущество облегченных процессов выпуска ПО заключается в опоре на технические практики, позволяющие контролировать затраты на сопровождение системы с течением времени. Идея состоит в том, что более взвешенный подход к работе сегодня позволит сохранять высокий темп внесения изменений в будущем. Если же пренебрегать этими практиками, любые изменения будут даваться все труднее и обходиться все дороже.</p> <p>Такие технические практики, как автоматизация тестирования и рефакторинг, — это не «побочные квесты», а сама суть работы. Техническая дисциплина — фундаментальное требование при выпуске коммерческого ПО, и эти практики уже давно перестали быть необязательными.</p> <p>Меня ставят в тупик просьбы подсказать способы убедить руководство разрешить применение этих практик. Я никогда не спрашивал разрешения делать то, что правильно для меня, для программного продукта, его пользователей и организации. Здесь не может быть компромиссов, поскольку отказ от технических практик вредит всем участникам процесса.</p> <p>Во многих организациях так и не удалось преодолеть отношение к этим мерам как к «побочным квестам», а внедрение ИИ лишь усугубило ситуацию. Когда команды получают инструменты на базе ИИ, от них ожидают высокой отдачи. Однако на деле они наблюдают лишь 25%-ный рост скорости внесения изменений, в то время как в отрасли бытует ошибочное мнение о десятикратном ускорении; в результате давление с требованием результатов только возрастает.</p> <p>В таких нездоровых условиях неудивительно, что те, кто считает качественные практики чем-то второстепенным, пропускают критически важные этапы работы.</p> <h3>Признаки высокой эффективности хорошо известны</h3> <p>Высокоэффективные команды осознали, что набор практик по выпуску ПО — это обязательное условие, а не опция по выбору. Они пришли к этому выводу, поскольку занимались масштабированием задолго до появления новых инструментов.</p> <p>Когда речь идет о важном ПО — продуктах, от которых зависят люди и которые должны оставаться актуальными через год, пять лет и дольше, — мы уходим от прежнего подхода «выбирай что хочешь». Теперь к профессиональной разработке и выпуску ПО предъявляются новые, более высокие требования.</p> <p>И все же есть проблеск надежды. Команды, успешно использующие ИИ, — это те же самые коллективы, которые опережали конкурентов еще до появления этой технологии. Они придерживаются строгой технической дисциплины, отслеживают показатели качества кода и уделяют первостепенное внимание мастерству создания кода, пригодного для долгосрочного сопровождения.</p> Анализ 623 млн. изменений кода, проведенный компанией GitClear, подтверждает реальность прироста производительности … article https://www.itweek.ru/themes/detail.php?ID=235620 Thu, 24 Sep 2026 15:05:11 +0300 <p>Разработчик экосистемы инфраструктурного ПО Orion soft представил zVirt Containers 2.0 — обновленную версию модуля платформы виртуализации zVirt для интеграции с Kubernetes-решением Nova Container Platform.</p> <p>По данным Strategy Partners, объем российского рынка решений для контейнеризации по итогам 2025 года достиг 5,4 млрд рублей, увеличившись на 26% год к году. Все больше корпоративных приложений используют микросервисную архитектуру, однако виртуальные машины продолжают составлять основу ИТ-инфраструктуры крупных компаний. В результате растет запрос бизнеса на управляемый способ добавить Kubernetes в инфраструктуру.</p> <p>zVirt Containers позволяет внедрить Kubernetes в существующую инфраструктуру виртуализации и связать работу администраторов zVirt и DevOps-команд в единый процесс. Интеграция контейнеров и виртуализации, сбор данных и компонентов — происходят автоматически. С модулем переход к Kubernetes реализуется за 1 час, а бизнес при этом экономит до 60 млн рублей в год на эксплуатации решения.</p> <p>В обновленном решении вендор также реализовал интеграцию с инфраструктурными компонентами Nova: Cluster Manager и Universe. Благодаря этому администраторы Kubernetes могут разворачивать, масштабировать и обновлять Kubernetes-кластеры, не привлекая специалистов по виртуализации. Шаблоны, сети и другие компоненты для создания кластеров из виртуализации zVirt можно выбирать в интерфейсе Cluster Manager. При этом серверы управления доступны для взаимодействия через zVirt. Для улучшения пользовательского опыта вендор также обновил интерфейсы — все это создает единый удобный слой управления инфраструктурой.</p> <p>zVirt Containers 2.0 — основа бесшовной интеграции основных продуктов экосистемы Orion soft. Вендор разработал и использовал в решении универсальный API, с помощью которого в дальнейшем планируется связывать продукты экосистемы: GitOps-платформу Hyperdrive, CMP-решение CloudLink, а также сторонние системы.</p> <p>«Для заказчиков, которые уже используют zVirt, Kubernetes становится логичным расширением существующей инфраструктуры. zVirt Containers 2.0 превращает zVirt из основы для виртуализации в платформу для разных типов приложений. Бизнес может сохранить существующие виртуальные машины, добавить Kubernetes для контейнерных нагрузок и при необходимости расширить свою инфраструктуру под ИИ. Для нас это важный шаг к единой экосистеме инфраструктурных продуктов Orion soft», — поделился Владимир Болвачев, лидер продукта Nova Container Platform в Orion soft.</p> Разработчик экосистемы инфраструктурного ПО Orion soft представил zVirt Containers 2.0 — обновленную версию модуля … message https://www.itweek.ru/themes/detail.php?ID=235619 Thu, 24 Sep 2026 15:03:35 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил распространение и использование технологий искусственного интеллекта в организациях, за исключением субъектов малого предпринимательства. Анализ основан на данных сплошных обследований крупных и средних организаций, проведенных Росстатом в <nobr>2025–2026 гг.</nobr></p> <p>В 2025 г. в крупных и средних организациях выросла востребованность технологий ИИ. Об этом свидетельствуют увеличение числа организаций, сообщивших об их применении, и рост затрат на внедрение таких технологий. В среднем технологии ИИ используют порядка 5,2% крупных и средних организаций, что на 0,4 п. п. больше, чем в 2024 г.</p> <p>Уровень распространения ИИ существенно зависит от размера организации. Так, в компаниях с численностью работников более 500 человек доля пользователей ИИ достигает 17%, в то время как в организациях, в которых заняты менее 100 человек (это самая многочисленная группа), — 4,3%.</p> <p>Наиболее востребованы среди ИИ-технологий решения для обработки визуальных данных и текста: к ним обращаются около двух третей организаций, применяющих ИИ, причем спрос на технологии обработки текста вырос по сравнению с 2024 г. почти вдвое. Наименее распространены технологии повышения эффективности ИИ.</p> <p>Организации применяют ИИ во всех основных бизнес-процессах: примерно каждая вторая — в маркетинге и продажах, управлении персоналом и производстве продукции, каждая четвертая — в управлении организацией.</p> <p>Чаще всего компании внедряют готовое коммерческое ПО (этот вариант выбрали 56% пользователей ИИ) или модифицированное сторонними организациями (51,8%). Собственными силами ПО разрабатывают или дорабатывают лишь <nobr>10–15%</nobr> организаций. За год существенно выросла доля компаний, использующих бесплатные ИИ-решения.</p> <p>Среди главных эффектов внедрения ИИ почти две трети (62,7%) организаций выделили повышение качества и эффективности бизнес-процессов. Свыше половины (51,1%) отметили улучшение качества и эффективности производственных процессов, 41,4% — рост доходов (в том числе за счет совершенствования продукции и услуг, более эффективного маркетинга и расширения клиентской базы), каждая четвертая (24,1%) — рост производительности труда. О снижении численности работников в результате внедрения ИИ сообщили 9,1% организаций-пользователей ИИ.</p> <p>Дальнейшему распространению технологий ИИ будет способствовать преодоление таких сдерживающих факторов, как высокие затраты (отметили 54% респондентов), недостаточность и невысокое качество массивов данных (34%), необходимость привлечения квалифицированных кадров (33%) и развитие ИКТ-инфраструктуры организации (32%). </p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил распространение и использование … message https://www.itweek.ru/themes/detail.php?ID=235618 Thu, 24 Sep 2026 15:00:37 +0300 <p>«МойОфис», российская продуктовая ИТ-компания, представила релиз 26.3 для нескольких ключевых продуктов компании. В новой версии решений «Документы Настольные», «МойОфис для дома» и «МойОфис Образование» редакторам стала доступна технология автоматического подбора и замены отсутствующих шрифтов «на лету» без искажения структуры документов на любых операционных системах. Также обновление существенно расширяет математический аппарат табличного редактора функциями прогнозирования и содержит дополнения для более комфортной работы с текстом и таблицами.</p> <p>Главным технологическим новшеством релиза стала встроенная система автоматической замены отсутствующих шрифтов «на лету» при открытии текстовых файлов, таблиц и презентаций. Редакторы «Мой Текст», «Моя Таблица» и «Моя Презентация» теперь корректно отображают документы, созданные в сторонних офисных программах, даже при отсутствии оригинальных гарнитур в операционной системе пользователя. Данное решение предотвращает искажение разметки и доступно на всех поддерживаемых платформах.</p> <p>Для дополнительного удобства пользователей реализовано сохранение масштаба документов при повторном открытии файлов в редакторах «Мой Текст» и «Моя Таблица». Также в редакторах появилась возможность поиска и замены непечатаемых символов, а для операционных систем macOS и Linux стала доступна темная тема оформления интерфейса. Дополнительно в текстовом редакторе была усовершенствована проверка орфографии, позволяя задавать конкретный язык проверки для выделенного фрагмента или всего текста целиком. В целях улучшения навигации в редакторы МойОфис добавлена функция быстрого доступа к каталогу рабочих документов, отображающая открытые файлы и пути к ним непосредственно в главном меню с возможностью быстрой очистки списка просмотра.</p> <p>В редакторе «Моя Таблица» реализована поддержка функций прогнозирования TREND (ТЕНДЕНЦИЯ) для вычисления линейных значений на базе накопленной информации, а также формул FORECAST.LINEAR (ПРЕДСКАЗ.ЛИНЕЙН) и FORECAST (ПРЕДСКАЗ) — это гарантирует совместимость с расчетными моделями из сторонних приложений. На боковую панель инструментов добавлены новые математические и тригонометрические функции, включая формулы ВРЕМЯ, ОСТАТ, ОТБР, ОКРВВЕРХ и COS. Для комфортной работы с примечаниями пользователи теперь могут управлять видимостью заметок — скрывать или показывать как отдельные комментарии, так и все заметки в документе одновременно. Также можно скрывать или отображать сетку рабочей области таблицы, а новое сочетание клавиш Ctrl+Shift со стрелками направления упрощает выделение заполненных диапазонов данных от курсора до первой или последней записи строки или столбца.</p> <p>Значительно улучшен интерфейс прикладного программирования Document API для платформ Python, C++, C# и макрокоманд LUA. Разработчики получили возможность программно переносить форматирование или чистые значения между ячейками таблиц, вставлять разрывы страниц с помощью макрокоманд, а также динамически запрашивать индекс активного листа и общее число вкладок в документе.</p> <p>В релизе 26.3 для редакторов «МойОфис для дома» и «МойОфис Образование» теперь также стали доступны новые функциональные возможности: просмотр детальной статистики документа в редакторе «Мой Текст»; темная тема для пользователей ОС macOS и Linux; работа с условным форматированием таблиц на панели редактора и операции над группой листов; поддержка работы с файловой системой в VBA; улучшенная проверка орфографии для выделенного фрагмента текста или всего документа при установке языков проверки; поддержка файлов формата HTML.</p> «МойОфис», российская продуктовая ИТ-компания, представила релиз 26.3 для нескольких ключевых продуктов компании. В новой … message https://www.itweek.ru/themes/detail.php?ID=235617 Thu, 24 Sep 2026 14:59:29 +0300 <p>В гонке кибервооружений на базе ИИ тактическое преимущество пока удерживает ИИ-защищающийся. При этом интеграция ИИ в системы защиты уже стала условием выживания. К таким выводам пришли специалисты экспертно-аналитического центра (ЭАЦ) ГК InfoWatch в исследовании «Искусственный интеллект в сетевой кибербезопасности». Отчет подготовлен по результатам изучения мировых тенденций влияния ИИ на безопасность сетевой инфраструктуры.</p> <p>Эксперты ЭАЦ ГК InfoWatch отмечают, что в настоящее время преимущество находится на стороне киберзащиты с применением ИИ. Однако использование ИИ в кибератаках сокращает разрыв за счет децентрализации и генеративных технологий. Так, уже примерно каждый шестой инцидент и успешный взлом сетей в мире (16%) осуществляется с применением ИИ-инструментов. Что касается фишинговых атак, то использование ИИ в них фиксируется почти повсеместно (86%).</p> <p>«Гонка кибервооружений на базе ИИ — это цифровая война на истощение. Пока что тактическое преимущество удерживает ИИ-защищающийся. У него есть три преимущества: полный, легитимный и непрерывный доступ к терабайтам „чистых“ внутренних данных для защиты, аппаратное превосходство благодаря ASIC и локальным ЦОД, а также технология киберобмана. Так, защитный ИИ контролирует сетевой ландшафт и может за миллисекунды перестроить топологию или подсунуть атакующему ИИ тысячи ловушек. Но атакующие быстро учатся — они используют коммерческие модели и модели на open source, взламывают их ограничения, а это делает ИИ-атаки дешевыми и массовыми. Эффективно противостоять ИИ-атаке можно только с помощью ИИ-защиты», — отметил главный аналитик ЭАЦ InfoWatch Сергей Слепцов.</p> <p>Аналитики ЭАЦ отмечают взрывной рост активности автономных ИИ-агентов, которые сканируют сети в поисках уязвимостей. Объем трафика, генерируемого вредоносными ИИ-ботами и агентами-разведчиками, за год вырос на 187%, а трафик от автономных ИИ-агентов («агентских браузеров») — почти в 80 раз. ИИ позволяет злоумышленникам находить уязвимости нулевого дня на 70% эффективнее. Кроме того, атакующий ИИ научился маскировать свой трафик под легитимный и мимикрировать под обычную активность пользователя. Это существенно затрудняет обнаружение вторжений.</p> <p>При этом ИИ-защита демонстрирует не менее впечатляющие результаты. ИИ-расширения систем обнаружения угроз (NDR/XDR) выявляют аномалии и продвинутые постоянные угрозы (APT-атаки) вдвое быстрее обычных систем — вместо нескольких дней на реакцию уходят минуты. ИИ-фильтрация на почтовых шлюзах блокирует до 94% фишинговых писем. ИИ-системы, которые анализируют поведение пользователей в ИТ-инфраструктуре, снижают риски внутренних угроз и кражи учетных данных на 45%. Благодаря ИИ-ассистентам, которые берут на себя часть рутины, нагрузка на аналитиков центров мониторинга по первичной сортировке и разбору сетевых предупреждений снижается на 60%.</p> <p> «Ключевым полем битвы в ближайшие годы станет устойчивость самих ИИ-моделей к отравлению данных и уклонение от атак. А на объектах, которые до сих пор полагаются на классические сигнатурные антивирусы, ИИ-атакующий пройдет незамеченным и победит в 100% случаев. Интеграция ИИ во все уровни мониторинга — от межсетевых экранов нового поколения (NGFW) до систем обнаружения аномалий в промышленных сетях — становится не конкурентным преимуществом, а условием выживания», — резюмировал Сергей Слепцов.</p> В гонке кибервооружений на базе ИИ тактическое преимущество пока удерживает ИИ-защищающийся. При этом … message https://www.itweek.ru/themes/detail.php?ID=235616 Thu, 24 Sep 2026 14:58:09 +0300 <p>На платформе SourceCraft появилась возможность подключать и настраивать автономных ИИ-агентов — например, для разработки и проверки безопасности кода, или создавать агентов с собственными специализациями под ключ. Разработчик поручает агенту работу прямо в обсуждении задачи в GitLab, где команда ведёт разработку. Также обратиться к агенту можно через мессенджеры, веб-интерфейс SourceCraft, редактор кода VSCode и командную строку.</p> <p>Агент работает под собственной учётной записью как самостоятельный участник команды, выполняет поручение и передаёт результат на проверку. Если ему не хватает данных или требуется согласование, он сам обращается к команде. Например, разработчик замечает ошибку в работе сервиса, создаёт задачу на её исправление и назначает ИИ-разработчика исполнителем. Агент сам готовит рабочее окружение, исправляет код, запускает тесты и отправляет изменения на проверку. Ссылка на исправление появляется в исходной задаче. Разработчик может принять результат или оставить замечания, тогда агент доработает код.</p> <p>Совместная работа разработчиков и ИИ-агентов помогает быстрее проверять продуктовые гипотезы, запускать новые сервисы и развивать существующие. По данным McKinsey, компании, которые встроили автономных ИИ-агентов в процесс разработки, более чем вдвое чаще добивались роста производительности свыше 20% по сравнению с теми, кто просто добавил ИИ-инструменты в существующие процессы. В среднем автономные агенты сокращают время на задачи разработки на 11,2%, а объём повторной работы — на 6,8%.</p> <p>«По мере развития ИИ меняется и масштаб автоматизации в разработке: от отдельных действий идёт переход к целым потокам постоянно возникающих задач. Одних только возможностей модели для этого недостаточно — нужна инфраструктура, которая позволяет бесшовно масштабировать существующие процессы разработки с помощью ИИ, а не перестраивать их заново под каждого нового агента. Именно в этом направлении мы развиваем SourceCraft», — рассказал Иван Пузыревский, технический директор Yandex Cloud.</p> <p>Яндекс, включая команду SourceCraft, уже применяет такой подход: 73% разработчиков компании регулярно используют ИИ, а более половины нового кода создаётся с помощью генеративных моделей. В рамках программы75/75/75 к концу года ИИ должны регулярно использовать не менее 75% разработчиков; он должен участвовать как минимум в 75% изменений и генерировать не менее 75% кода в каждом из них. </p> <p>В дальнейшем Yandex B2B Tech планирует объединить управление своими ИИ-ресурсами. Для этого она запустит единую подписку, которая позволит работать с SourceCraft, Алисой AI Про для бизнеса и другими ИИ-сервисами, а также использовать модели Yandex AI Studio. Это позволит компаниям централизованно распределять ИИ-ресурсы между разработчиками, агентами и работающими продуктами — и видеть полную стоимость использования ИИ, а не только затраты на разработку.</p> На платформе SourceCraft появилась возможность подключать и настраивать автономных ИИ-агентов — например, для … message https://www.itweek.ru/themes/detail.php?ID=235615 Thu, 24 Sep 2026 14:57:10 +0300 <p>Yandex B2B Tech анонсировала DataLens Platform — платформу, которая объединяет все этапы работы с данными: от загрузки и хранения до визуализации и ИИ-аналитики. DataLens Platform позволяет работать с данными компании в одном месте, быстро находить их источники и получать инсайты с помощью ИИ-агента. Сервис сокращает совокупные затраты на аналитику до 30%, а подготовку отчётов и дашбордов ускоряет в <nobr>3–5 раз.</nobr> Общедоступный релиз запланирован на начало 2027 года, сейчас можно оставить заявку на ранний доступ.</p> <p>70% аналитических команд используют от 5 до 10 инструментов для работы с данными: одни — для загрузки и хранения, другие — для обработки аналитики. ИТ-специалистам приходится вручную переносить данные между системами, настраивать интеграции и разбираться в каждом источнике информации: сопоставлять поля и идентификаторы, согласовать расхождения в данных и решать другие проблемы совместимости.</p> <p>В DataLens Platform компаниям больше не придётся собирать аналитику из десятка разрозненных инструментов и настраивать обмен данными между ними. На платформе уже объединены хранилище данных, инструменты для обработки информации и создания отчётов, а также ИИ-помощник, которому можно задавать вопросы на обычном языке. Пользователь сможет работать с данными и получать готовые показатели в единой системе — без огромного количества прослоек из межсистемных интеграций. </p> <p>«Уникальность DataLens Platform в том, что разные инструменты для работы с данными объединены в одной системе. Это сильно упрощает инфраструктуру: чем больше отдельных систем использует компания, тем больше интеграций между ними приходится поддерживать. Для пяти систем их может быть до 10, а для десяти — уже до 45. При этом хранение данных и вычислительные мощности в DataLens Platform масштабируются независимо: если растёт объём данных, можно расширить хранилище, а если нагрузка на расчёты и отчёты — добавить вычислительные мощности», — рассказал Иван Пузыревский, технический директор Yandex Cloud.</p> <p>Например, торговая сеть с помощью DataLens Platform сможет объединить данные о продажах, остатках и программе лояльности и спросить ИИ-помощника, какие популярные у постоянных покупателей товары заканчиваются в конкретных магазинах. Производственная компания — сопоставить выпуск продукции, простои оборудования и показатели качества, чтобы увидеть, на какой линии и в какой смене выросла доля брака. </p> <p>Сначала DataLens Platform будет доступна в Yandex Cloud. Позднее Yandex B2B Tech планирует выпустить версии продукта для размещения в собственной инфраструктуре компании и для гибридного сценария. </p> Yandex B2B Tech анонсировала DataLens Platform — платформу, которая объединяет все этапы работы с данными … message https://www.itweek.ru/themes/detail.php?ID=235614 Thu, 24 Sep 2026 14:55:53 +0300 <p>Yandex B2B Tech запускает новое ИБ-направление — Yandex Security. Компания сосредоточится не только на защите облачной инфраструктуры клиентов, но и будет развивать решения для гибридной, локальной и мультиоблачной безопасности. Также Yandex B2B Tech усилила свой продуктовый портфель новыми продуктами, среди них инструменты для беспарольной авторизации и поиска избыточных прав доступа в системе.</p> <p>Сервисы Yandex Security позволяют защищать инфраструктуру, размещённую у разных облачных провайдеров. Клиентам доступен мониторинг безопасности мультиоблачной архитектуры в едином интерфейсе. В нём автоматически собираются все данные о защите инфраструктуры: мониторинг доступов к системе, анализ рисков и ошибок в конфигурации и многое другое. Всё это позволяет устранить «слепые зоны» и видеть полную картину безопасности в едином интерфейсе независимо от того, в каком облаке размещены ресурсы. Интеграция с Security Deck занимает несколько минут. До конца года у компании появится несколько ведущих облачных провайдеров-партнеров. </p> <p>«Yandex Security предоставит бизнесу принципиально новый подход к информационной безопасности в эпоху ИИ. Наши технологии позволяют значительно повысить скорость внедрения ИБ-инструментов и при этом построены на экспертизе в защите больших и распределённых инфраструктур уровня Яндекса. Мы объединили наши ИБ‑решения, включая разработки с SolidLab, чтобы обеспечить защиту любых инфраструктур — от гибридных до мультиоблачных — с бесшовным внедрением и централизованной безопасностью», — прокомментировал директор по информационной безопасности Yandex Сloud Евгений Сидоров.</p> <p>Yandex Security запустит в сервисе Identity Hub беспарольную авторизацию для организаций на базе технологий WebAuthn/FIDO2. Теперь сотрудники компании смогут подтвердить вход в корпоративные системы по лицу, отпечатку пальца или с помощью аппаратного ключа. Администратор сможет гибко управлять доступом к беспарольной авторизации: от многофакторной аутентификации до полного запрета паролей. Это снижает риск компрометации учётных данных: пользователям не придётся вводить пароли, которые можно подобрать или похитить с помощью фишинга.</p> <p>В сервисе Yandex Smart Web Security появился новый тип проверки посетителей сайта от ботов — JS-Challenge. В отличие от привычной капчи, отсеивание вредоносного трафика происходит в фоновом режиме. Ключевая особенность — адаптивная защита: система динамически оценивает уровень риска каждого запроса. При стандартной активности пользователя проверка проходит незаметно, а капча показывается только при наиболее подозрительных запросах — это снижает нагрузку на посетителей и одновременно повышает эффективность фильтрации ботов.</p> <p>В составе Yandex Security Deck появился отдельный модуль Access Analyzer для контроля доступов в системе. В соответствии с принципом минимальных полномочий модуль может отслеживать использование ролей и предлагать их замену на более гранулярные, а также найти избыточные доступы и удалить неиспользуемые сервисные аккаунты.</p> Yandex B2B Tech запускает новое ИБ-направление — Yandex Security. Компания сосредоточится не только на защите … message https://www.itweek.ru/themes/detail.php?ID=235613 Thu, 24 Sep 2026 14:54:27 +0300 <p>Yandex B2B Tech представила Алису AI Про для бизнеса. Это расширенная версия корпоративного ИИ-ассистента Яндекса — она подойдёт банкам, ритейлерам, промышленным корпорациям и другим компаниям с особыми требованиями к хранению и обработке данных. Её можно развернуть на собственной инфраструктуре и гибко настроить под свои задачи — к примеру, самостоятельно выбрать модель «под капотом» или создать узкоспециализированные навыки. Новая версия уже доступна по подписке всем клиентам Yandex Cloud.</p> <p>Алиса AI Про — это универсальный ИИ-агент, способный решать сложные многосоставные задачи. Её можно использовать практически в любом отделе, от дизайна и маркетинга до бухгалтерии, HR и юридического департамента. Достаточно сформулировать поручение простым языком, и помощник выполнит его, используя те же приложения, которыми обычно пользуется сам сотрудник — например, CRM-системы или сервисы для работы с документами и бухучёта. Для решения задач Алиса AI Про сама создаёт себе команду специализированных ИИ-агентов. Пока они собирают информацию и работают с документами и корпоративными системами, ИИ-помощник координирует их работу, проверяет и объединяет результаты.</p> <p>«Сотрудники компаний каждый день используют огромное количество сервисов и приложений. С запуском Алисы AI Про у них появляется единый ИИ-интерфейс для решения большинства задач. Помощник сам поставит задачу в Трекере, отправит письмо по почте или соберёт встречу команды — достаточно предоставить ему доступ к нужным приложениям. Подобные универсальные ИИ-агенты — новый этап проникновения ИИ в бизнес», — отметил руководитель Yandex AI Studio Артур Самигуллин.</p> <p>Алиса AI Про уже предлагает более 120 навыков — готовых инструкций по решению рабочих задач — для сотрудников с разными профессиями: дизайнеров, аналитиков, юристов, финансистов, специалистов по закупкам и многих других. Можно не только использовать готовые навыки, но и создавать собственные. Умение писать код для этого не требуется.</p> <p>Для подключения к внешним приложениям и сервисам используются плагины — их уже более 20. Например, плагин Phygital+ поможет сгенерировать изображения и видео для маркетинговых материалов, а AvangardAI превратит помощника в тренажёр для специалиста по продажам. Число плагинов будет расти — их могут создавать как крупные и хорошо известные сервисы, так и стартапы. У компаний, которые работают с Алисой AI Про, также есть возможность подключить внешние или внутренние сервисы по MCP-протоколу.</p> <p>Нового ИИ-помощника уже тестируют крупные компании, например «Норникель». Его специалисты помогали сформировать сценарии использования Алисы AI Про в промышленности — от нормоконтроля документов до классификации затрат и интеллектуального поиска по внутренним нормативным документам. Эти сценарии будут востребованы и у других компаний.</p> <p>С запуском Алисы AI Про компании смогут выбирать между двумя версиями ассистента. Алиса AI для бизнеса, которую Яндекс представил в начале сентября, пригодится тем, кому нужно готовое решение. Алиса AI Про также подойдет тем, у кого есть потребность гибко настроить агента под себя.</p> Yandex B2B Tech представила Алису AI Про для бизнеса. Это расширенная версия корпоративного ИИ-ассистента Яндекса — она … message https://www.itweek.ru/themes/detail.php?ID=235612 Thu, 24 Sep 2026 14:48:42 +0300 <p><nobr>7–8</nobr> октября на крупнейшем мероприятии для профессионалов розничной торговли эксперты BSS продемонстрируют, как ИИ помогает создавать более персонализированный клиентский опыт и предотвращать проблемы покупателей.</p> <p><nobr>7–8</nobr> октября на Коннектед Ритейл Форуме около 2 000 представителей ритейла, e-commerce и FMCG-брендов обсудят, какие бизнес-модели позволяют выделиться в 2026 и за счет чего привлекать и удерживать покупателей. </p> <p>Эксперты BSS покажут, какие конкурентные преимущества можно получить при помощи ИИ на секции «ИИ (AI) студия: ИИ „под капотом“ клиентских процессов» 8 октября в 15:00. </p> <p>Заместитель генерального директора BSS Василий Жилов выступит со-модератором секции и вместе с участниками обсудит, как внедрять ИИ так, чтобы технологии работали на бизнес и клиента, а не заставляли человека подстраиваться под логику алгоритмов. </p> <p>В центре дискуссии — практические кейсы использования ИИ в ритейле: навигация и персонализированные предложения, ИИ-амбассадоры и ИИ-аналитика. Эксперты разберут, как ИИ-инструменты уже помогают повышать конверсию и удерживать покупателей, и какие возможности могут открыть дальше. </p> <p>Руководитель направления по развитию голосовых цифровых технологий BSS Валерия Учайкина расскажет, как с помощью ИИ находить скрытые сигналы в обращениях клиентов и превращать их в конкретные действия, и в конечном счете — в выручку. </p> <p>Речь пойдет о <nobr>CX-платформе,</nobr> которая собирает разрозненные данные о клиенте и связывает их с действиями на всем клиентском пути. Например, платформа фиксирует, что постоянный клиент реже совершает покупки. Недавно он несколько раз заходил на страницу привычного товара, но не оформлял заказ, при этом в чате сравнивал цену с другими магазинами. Сигналы складываются в единую картину, и система сигнализирует о риске оттока. А затем рекомендует действие — например, предложить персональную скидку или бонусы на следующую покупку.</p> <p>Актуальная информация о секции «ИИ (AI) студия: ИИ „под капотом“ клиентских процессов» — в программе.</p> <p>Эксперты BSS будут ждать гостей и на собственном стенде — здесь можно будет вживую посмотреть, как работает <nobr>CX-платформа</nobr> и ее отдельные компоненты: речевая аналитика, виртуальные помощники, ИИ-портал и другие инструменты. </p> 7–8 октября на крупнейшем мероприятии для профессионалов розничной торговли эксперты BSS продемонстрируют, как ИИ … message https://www.itweek.ru/themes/detail.php?ID=235610 Thu, 24 Sep 2026 11:21:18 +0300 <p>Open source, или компоненты с открытым исходным кодом сегодня лежат в основе значительной части корпоративного ПО и государственных ИС. По некоторым <a href="https://www.forbes.ru/tekhnologii/555582-politika-otkrytyh-dverej-kakie-ugrozy-tait-v-sebe-primenenie-opensource-koda">оценкам</a>, около 90% российских компаний используют открытый исходный код в своей ИТ-инфраструктуре. Готовые библиотеки и фреймворки позволяют не разрабатывать базовый функционал с нуля, а строить приложения их готовых строительных блоков, что позволяет существенно сокращать сроки и стоимость создания продуктов. Однако вместе с преимуществами бизнес получает новую зону риска: приложения начинают зависеть от компонентов, разработчиков, репозиториев и инструментов, которые не контролируются напрямую. Это связано с тем, что нет возможности проконтролировать весь процесс сборки от исходного кода библиотек и до конечного артефакта. Чаще всего разработчики скачивают готовые компоненты — артефакты в уже скомпилированном виде, как правило, из зарубежных источников. Чем больше таких элементов в ПО, тем выше риск атак: злоумышленники могут попытаться использовать любой из элементов цепочки и скомпрометировать его, используя уязвимости или «закладки», что позволит использовать эту ситуацию как точку входа в корпоративную инфраструктуру с целью остановки ключевых процессов, повреждения или кражи данных.</p> <h3>Что скрывается за цепочкой поставки ПО</h3> <p>Цепочка поставки ПО давно вышла за пределы исходного кода конкретной библиотеки. В нее входят публичные репозитории, пакетные менеджеры, транзитивные зависимости, SDK и плагины, CI/CD-компоненты, контейнерные образы и механизмы доставки обновлений. С каждым годом число атак на цепочки поставок растет, по <a href="https://www.kaspersky.ru/about/press-releases/cepnaya-reakciya-samoj-chastoj-kiberugrozoj-dlya-kompanij-v-2025-godu-stali-ataki-cherez-komprometaciyu-vendorov-po">данным</a> «Лаборатории Касперского», в 2025 году с такими атаками столкнулись 31% компаний в мире и 35% в России. А по <a href="https://www.anti-malware.ru/news/2025-12-29-114534/48600">данным</a> компании CodeScoring, за 2025 год количество вредоносных компонентов выросло на 1000%. Такой тренд имеет экспоненциальную динамику, по отношению к трем годам ранее, где рост составил около 700%. Атакующему не обязательно искать уязвимость непосредственно в инфраструктуре компании. Иногда достаточно скомпрометировать один из компонентов, которому она доверяет. Все чаще целью становятся разработчики, репозитории и системы сборки, ведь через них можно незаметно внедрить вредоносный код в легитимное ПО.</p> <p>Компоненты с открытым исходным кодом — это не только исходный код, который разработчик может изучить и изменить. Часто компания использует уже готовые артефакты, опубликованные в публичных репозиториях, которые, как правило, находятся на ресурсах за пределами РФ. В этом случае разработчик не контролирует весь процесс их формирования и не может самостоятельно гарантировать полное соответствие конечного артефакта исходному коду. В артефакт могли быть внесены вредоносные изменения — как на этапе разработки, так и в процессе сборки. Поэтому защищать нужно не только собственный код, но и всю цепочку поставки ПО.</p> <h3>Где возникает основной риск</h3> <p>Риски могут возникать почти на любом этапе, начиная от разработки и публикации исходного кода до сборки и доставки готового продукта. Один из очевидных сценариев: компрометация аккаунта разработчика или мейнтейнера в случаях отсутствия регистрации домена. Зарегистрировав домен на себя, злоумышленник получает доступ к репозиторию и может изменить исходный код или выпустить новую версию уже известного пакета и его артефактов. При автоматическом обновлении такой компонент способен попасть в корпоративную среду, а проверка средствами композиционного анализа покажет его как безопасный.</p> <p>Злоумышленник может взломать аккаунт разработчика или намеренно войти в сообщество и действовать изнутри. Например, в 2024 году обнаружился бэкдор в XZ Utils, который создал участник проекта. В течение двух лет он активно участвовал в развитии проекта, помогал исправлять ошибки, позже ему дали статус со-мейнтейнера с правом менять код. Получив доверие сообщества, он начал внедрять вредоносный код в набор утилит.</p> <p>Неподдерживаемая библиотека — это еще одна зона риска. Важно понимать, поддерживается ли сам проект, насколько активно развивается и есть ли команда, способная оперативно выпускать исправления. Если библиотека фактически заброшена, новая уязвимость может остаться без патча.</p> <p>Отдельный риск связан с системой сборки и CI/CD, такие средства, как Maven и Gradle, являются источниками риска. Они связывает исходный код, зависимости и готовый продукт и при этом часто имеют доступ к инфраструктуре. Если скомпрометирована система сборки или ее компоненты, злоумышленник может изменить конечный артефакт еще на этапе его формирования.</p> <p>Потенциальная угроза для продукта может скрываться и во фреймворках, которые используются в разработке. Например, Spring — это один из популярных фреймворков среди российских Java-разработчиков. По информации из <a href="https://jokerconf.com/research/state-of-java/2026/report.html">опроса </a>«State of Java» компании JUG Ru Group, Spring используется в более чем 80% проектов. И устаревшая версия фреймворка может затронуть сразу большое количество систем, поскольку теперь сообщество устраняет уязвимости только в актуальных версиях Spring. Отделу ИБ и разработчикам важно смотреть не только на наличие известных уязвимостей, но и контролировать статус поддержки версий сообществом разработчиков. Особенно это актуально сейчас, когда после выпуска обновлений бесплатная поддержка истекших версий для разработчиков прекращается и рекомендуется переход на коммерческую поддержку, которая недоступна в России.</p> <h3>ИИ тоже имеет значение</h3> <p>Генеративный ИИ уже стал неотъемлемой частью процесса разработки: он помогает писать код, подбирает необходимые библиотеки или фреймворки. При этом возникает дополнительный риск: модель может предложить внешний компонент, не учитывая, есть ли в нем известные уязвимости, насколько актуальна используемая версия и применима ли поддержка на территории России. Конечно, многое зависит от конкретной ИИ-модели и ее источников данных. Одни модели работают на основе ранее известных примеров кода, другие уже умеют обращаться к внешним ресурсам и получать более актуальную информацию. При этом сам факт рекомендации библиотеки не означает, что она прошла проверку безопасности. ИИ ориентируется прежде всего на то, работает ли предложенный код, но не проверяет зависимости.</p> <p>Для проверки можно использовать композиционный анализ. Он позволяет определить версии подключенных библиотек и проверить их на наличие известных уязвимостей через базы БДУ ФСТЭК, NIST и др. Еще один подход — настроить ИИ на использование доверенных библиотек из внутреннего репозитория, а не произвольных компонентов из публичных источников. В таком случае модель будет работать только с тем набором компонентов, который уже прошел необходимые проверки.</p> <h3>Безопасность цепочки поставок — общая ответственность поставщика и разработчика</h3> <p>Сегодня вопрос контроля ИБ-рисков особенно актуален. Проверка компонентов, актуальности версии, контроль сборки в защищенной среде и быстрого устранения уязвимостей — не всегда задача только службы ИБ. Безопасность цепочки поставок требует совместной работы нескольких команд и компаний, которые постоянно взаимодействуют с целью повышения уровня защиты ПО.</p> <p>Отдел ИБ определяет правила использования доверенных компонентов, закрепляет политики, по которым нужно использовать определенное ПО из соответствующих доверенных источников, и контролирует их соблюдение. Далее к работе подключается команда архитекторов и разработчиков, а также платформенная команда (DevOps), которая должна обеспечивать безопасные среды запуска и платформу. В ее задачи должна входить реализация ИТ-инфраструктуры на надежных и доверенных компонентах, которые будут соответствовать требованиям российского законодательства в части безопасности. Разработка, в свою очередь, несет ответственность за работу продукта. Для этого вся команда разработки должна быть погружена в продукт и разбираться в том числе и в аспектах безопасности.</p> <p>Конечный продукт должен отвечать всем требованиям, как с точки зрения ИБ, так и с точки зрения функционала.</p> <h3>Как строить защиту цепочки поставок через компоненты с открытым исходным кодом</h3> <p>Исследовательская компания Gartner в своем отчете «Leader’s Guide to Software Supply Chain Security» 2024 года предложила выстраивать защиту цепочки поставок в три этапа: Curate, Create и Operate (управление, создание, эксплуатация). Такой подход позволяет контролировать происхождение программного продукта и снижать риски на каждом этапе цепочки.</p> <p>Первый этап — выбор доверенных компонентов: библиотек, фреймворков, компиляторов, интерпретаторов и средств проверки. Важно заранее понимать происхождение компонентов и использовать те, безопасность которых можно контролировать.</p> <p>Второй этап — безопасная разработка и анализ кода. Здесь необходимо контролировать весь процесс создания ПО — от исходного кода до готового артефакта, используя инструменты анализа и практики SSDLC (Secure Software Development Life Cycle) в соответствии с требованиями ГОСТ Р <nobr>56939-2024.</nobr> Это позволяет выявлять проблемы в подключаемых компонентах.</p> <p>Третий этап — контроль эксплуатации. Даже безопасный программный продукт может оказаться под угрозой, если его развернуть на уязвимой инфраструктуре. Поэтому необходимо контролировать и среду, в которой ПО запускается.</p> <p>Такой подход позволяет встроить безопасность непосредственно в процесс разработки. Кроме того, если используемые компоненты, их версии и требования к инфраструктуре заранее определены и документированы, аудит становится проще: не нужно каждый раз заново проверять весь технологический стек.</p> <p>Чем больше внешних компонентов используется в продукте, тем сложнее контролировать их происхождение, изменение и состояние. Поэтому при оценке безопасности цепочки для противодействия атак важно рассматривать весь путь, который проходит код до промышленной эксплуатации. Часть рисков и нагрузки с команд разработки можно снять за счет работы с проверенным поставщиком, который обеспечивает контроль безопасности и целостности компонентов на всех этапах их жизненного цикла.</p> <p>При выборе поставщика ПО необходимо учитывать не только функциональность решения, но и происхождение решений. Предпочтение следует отдавать российским поставщикам ПО, которые контролируют весь исходный код компонент и обеспечивают безопасный процесс и сборки на основе ГОСТ Р <nobr>56939-2024.</nobr> Разработка ПО должна вестись в соответствии с приказом № 117 ФСТЭК России от 11.04.2025 и другими нормативно-правовыми актами, связанными с безопасной разработкой ПО.</p> <p>Функциональным заказчикам рекомендуется включать в требования к ПО пункты соблюдения правил контроля и проверки кода и использования доверенных компонентов, что можно реализовать путем создания доверенных источников компонент для подрядных организаций на уровне компаний или индустрий.</p> <p>#IMAGE_235611#</p> Open source, или компоненты с открытым исходным кодом сегодня лежат в основе значительной части корпоративного ПО … article Алексей Захаров, директор по техническому консалтингу Axiom JDK https://www.itweek.ru/themes/detail.php?ID=235608 Thu, 24 Sep 2026 11:08:19 +0300 <p>До недавних пор концепция «нулевого доверия» (Zero Trust Architecture, ZTA) считалась избыточной. Многофакторная контекстная аутентификация, короткоживущие ключи, централизованная авторизация и мониторинг аномалий — всё это означало дополнительные затраты в проектировании и повышенное потребление ресурсов в эксплуатации. И как следствие, внедрение ZTA признавалось нецелесообразным.</p> <p>Но ситуация изменилась. Новые технологии на базе искусственного интеллекта и прочих интеллектуальных инструментов в разы увеличили скорость атак и сделали их проще в реализации. Темп обнаружения и эксплуатации уязвимостей уверенно превзошёл скорость патч-менеджмента. А сами атаки стали комплексными и «обходными». Они реализуются через цепочки поставок и подрядчиков.</p> <p>Эту тенденцию подтверждают и мировые, и российские исследования. Согласно Verizon Data Breach Investigations Report 2025, доля инцидентов, связанных с третьими сторонами, выросла с 15 до 30% всего за один год. Иными словами, почти каждый третий расследованный инцидент связан с подрядчиками, поставщиками сервисов, ИТ-аутсорсингом и другими участниками цепочки поставок. Средний <a href="https://www.ibm.com/reports/data-breach">ущерб</a> от таких атак, по данным IBM Cost of Data Breach Report 2026, составляет $4,91 млн.</p> <p>Аналогичные данные приводит RED Security по России: доля инцидентов, связанных с третьими сторонами, в 2025 году также достигла 30%, а годом ранее она не превышала 10%. При этом 80% инцидентов начинаются с компрометации учётных записей, а порядок обнаружения уязвимостей с часов упал до минут.</p> <p>Гибридный и удалённый форматы работы стали нормой, и информационные системы должны быть доступны через интернет. В 2025 году гибридный режим стал самым распространённым в России. По данным исследования консалтинговой компании get experts, 51% сотрудников работают в гибридном формате, 41% — в офисе и только 8% — полностью удалённо. Четверть компаний в России за последний год изменили формат работы сотрудников в сторону гибрида.</p> <p>Это означает, что классический сетевой периметр как граница защиты фактически перестал существовать. Корпоративные ресурсы доступны извне, а значит, модель «доверяй всему, что внутри сети» больше не работает. И последним рубежом защиты становится архитектура нулевого доверия.</p> <h3>Архитектура ZTA</h3> <p>Архитектура Zero Trust строится на трёх взаимосвязанных принципах, каждый из которых закрывает определённый класс угроз.</p> <ol> <li> <strong>Аутентификация.</strong> В модели ZTA аутентификация не ограничивается вводом пароля при входе в систему. В ней используются короткоживущие ключи и учитывается весь доступный контекст: устройство, с которого выполняется запрос, сетевое и географическое местоположение, время обращения, поведенческие шаблоны пользователя. Это означает, что даже перехваченные учётные данные не дадут злоумышленнику устойчивого доступа, поскольку контекст не совпадёт.</li> <li><strong> Авторизация.</strong> Права доступа выдаются по принципу минимально необходимых и могут быть отозваны мгновенно. Пользователь или сервис получают доступ только к тем ресурсам, которые нужны для конкретной задачи, и только на время её выполнения. При изменении контекста или выявлении аномалии доступ прекращается без участия администратора.</li> <li><strong> Телеметрия.</strong> Непрерывный сбор и анализ событий безопасности позволяет выявлять аномалии в реальном времени. Триггеры аномальной активности используются не только для оповещений, но и для управления авторизацией: при срабатывании триггера система может заблокировать доступ, запросить повторную аутентификацию или перевести информационную систему в экстремально защищённый режим вплоть до полной изоляции.</li> </ol> <p>Следуя этим принципам, можно построить защиту, для преодоления которой злоумышленнику потребуется проходить расширенную аутентификацию на каждом шаге развивающейся атаки. Вечных «ключей» здесь нет, а доступ ограничен узкими разрешёнными рамками, в которые входят хронологическое окно, знакомое устройство, известное сетевое и географическое местоположение. При этом триггеры аномальной активности в реальном времени не позволят развить атаку вглубь.</p> <h3>Пути внедрения ZTA</h3> <p>Существует два принципиальных пути внедрения ZTA. Первый — «сверху вниз», через одновременную перестройку всей инфраструктуры. Трансформация инфраструктуры, долго и сложно эволюционировавшей внутри сложившихся бизнес-процессов, — дело непростое. Исходные коды и первоначальные разработчики могут быть недоступны, масштабные инфраструктурные изменения способны нарушить непрерывность бизнес-процессов, а вложения в системы, которые уже работают, не всегда экономически оправданы. По данным Gartner, до 40% проектов цифровой трансформации не достигают заявленных целей, а средняя стоимость простоя критичных бизнес-систем для крупных компаний оценивается в сотни тысяч долларов в час.</p> <p>Второй путь — «снизу вверх», от конечного устройства к ядру инфраструктуры. Этот путь делает процесс постепенным, последовательным и управляемым. Поэтому он подходит большинству организаций и включает три части.</p> <p>Первый этап — защита конечных точек доступа. На этом уровне ZTA внедряется как наложенное средство, дублирующее существующую модель безопасности на стадии внедрения и обеспечивающее бесшовный переход после её завершения. Понятие периметра возвращается на новом уровне. Не в виде замка на шлюзах, а в форме контролируемого доступа с учётом контекста. И доступ предоставляется только к разрешённым ресурсам и только при совпадении контекста.</p> <p>Второй этап — сетевая безопасность. Сегментация, маршрутизация, IEEE 802.1x представляют собой более инвазивные задачи, но их решение также относится к классу наложенных средств. ZTA здесь реализуется стандартными методами: фильтры и маршрутизаторы, RADIUS-серверы, контроль сетевых потоков. Работа выполняется силами сетевых инженеров и не требует ресурсов разработки.</p> <p>Третий этап — самая важная и самая трудоёмкая задача. На этой стадии два предыдущих шага уже пройдены, интеграционные требования к доработке систем уже сформулированы и готовы и вопрос сводится к оценке целесообразности. Если доработки слишком дороги, уже внедрённых элементов ZTA на первых двух уровнях будет достаточно для большинства сценариев. Если же требования к защищённости высоки — системы ГИС, КИИ, ПДн — и цена неприемлемого риска превышает стоимость ZTA-трансформации, необходимо идти до конца.</p> <h3>Когда пора внедрять ZTA</h3> <ol> <li> Доля инцидентов, связанных с третьими сторонами и цепочками поставок, растёт в вашей отрасли.</li> <li> Более трети сотрудников работают в гибридном или удалённом формате.</li> <li> Критичные системы доступны извне или через подрядчиков.</li> <li> Существующая модель безопасности построена на доверии к сетевому периметру.</li> <li> Организация подпадает под требования регуляторов по защите КИИ, ГИС или ПДн.</li> </ol> <h3>Как внедрять ZTA</h3> <ol> <li> Проведите аудит и выявите системы, доступные извне или через третьих лиц.</li> <li> Внедрите защиту «последней мили»: контекстную аутентификацию и контроль доступа на уровне конечных устройств.</li> <li> Выполните сетевую сегментацию и внедрите контроль сетевых потоков (IEEE 802.1x, RADIUS, микросегментация).</li> <li> Настройте телеметрию и триггеры аномальной активности с автоматическим отзывом доступа.</li> <li> Оцените целесообразность глубокой трансформации прикладных систем с учётом регуляторных требований и стоимости риска.</li> </ol> <p>Сегодня Zero Trust перестал быть опцией для организаций с повышенными требованиями к безопасности. Рост атак через цепочки поставок, массовый переход на гибридный формат работы и исчезновение классического сетевого периметра делают ZTA базовым требованием для любой инфраструктуры, где есть внешние подключения или доступ подрядчиков. Практический путь внедрения выстраивается последовательно, «снизу вверх», и ведёт от защиты конечных точек через сегментацию к оценке целесообразности глубокой трансформации. Организациям, работающим с КИИ, ГИС или ПДн, переход на модель нулевого доверия следует рассматривать как обязательный элемент стратегии защиты, который требует реализации в текущем горизонте планирования.</p> <p>#IMAGE_235609#</p> До недавних пор концепция «нулевого доверия» (Zero Trust Architecture, ZTA) считалась избыточной. Многофакторная контекстная … article Султан Салпагаров, архитектор по информационной безопасности Getmobit https://www.itweek.ru/themes/detail.php?ID=235607 Thu, 24 Sep 2026 10:53:13 +0300 <p><em>Результативность систем искусственного интеллекта зависит от того, насколько предсказуемо и безопасно данные перемещаются между центрами обработки данных, облачными средами и периферией. При проектировании систем теперь столь же важно учитывать показатели задержки, отказоустойчивость и видимость сети, как и вычислительные мощности, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Крис Альбердинг, директор по продуктам компании BCN.</em></p> <p>Дискуссии об инфраструктуре для ИИ стали весьма предсказуемыми. Почти все они сводятся к обсуждению графических процессоров (GPU), специализированных чипов, энергообеспечения и гонки по созданию все более крупных кластеров ИИ. Эти инвестиции необходимы, однако они упускают из виду не менее важный вопрос: насколько эффективно ИИ может перемещать данные туда, где требуются интеллектуальные вычисления?</p> <p>Вычислительные мощности создают интеллект. Сети обеспечивают его доставку.</p> <p>За последний год я провел множество бесед с ИТ-руководителями крупных предприятий из различных отраслей, сталкивающимися с реалиями внедрения ИИ. Сперва обсуждения почти всегда касаются моделей, вычислительных мощностей или облачной стратегии. Но уже к третьей беседе речь обычно заходит о сетевой инфраструктуре. И такой сдвиг вполне закономерен.</p> <p>Первая волна внедрения ИИ в корпоративном секторе принесла успех тем организациям, которые имели доступ к вычислительным мощностям. Следующая волна принесет успех тем, кто сможет эффективно, безопасно и предсказуемо перемещать данные в условиях все более распределенных сред. Это совершенно иная задача с точки зрения инфраструктуры.</p> <h3>Перемещение данных становится стратегической задачей</h3> <p>Традиционные корпоративные приложения генерировали довольно предсказуемый трафик. Пользователи подключались к централизованным системам, а сети проектировались для обеспечения надежного соединения между различными локациями. ИИ работает иначе.</p> <p>Один-единственный запрос к системе ИИ может потребовать извлечения данных из корпоративного хранилища и информации из векторной базы данных, обращения к большой языковой модели (LLM), работающей в другой среде, применения политик безопасности и возврата ответа пользователю — и все это за считанные секунды. Ни один из этих этапов не происходит изолированно, и все они невозможны без участия сети.</p> <p>Именно поэтому расходы на инфраструктуру для ИИ продолжают стремительно расти. По прогнозам Gartner, в 2026 г. мировые расходы на ИИ достигнут 2,59 трлн. долл., причем почти половина этой суммы придется на инфраструктуру, поскольку организации расширяют системы, необходимые для масштабного внедрения ИИ. Однако одни лишь затраты на инфраструктуру не гарантируют успеха.</p> <p>Одно из главных изменений, привносимых ИИ, заключается в том, что перемещение данных превращается из операционной задачи в стратегическую. Обучение модели — это лишь часть уравнения. Настоящая сложность заключается в обеспечении стабильной доставки интеллектуальных возможностей между дата-центрами, облачными платформами, филиалами, периферийными узлами и растущим числом приложений, зависящих от ИИ. Для этого требуется инфраструктура, ориентированная на эффективную передачу данных, а не просто на обеспечение высокой пропускной способности. Производительность сети всегда имела значение, но внедрение ИИ выводит этот вопрос на новый уровень важности.</p> <h3>Задержка передачи данных становится бизнес-показателем</h3> <p>Специалисты по инфраструктуре часто уделяют основное внимание таким параметрам, как загрузка GPU, производительность систем хранения данных или точность моделей. Однако конечные пользователи не сталкиваются с этими показателями напрямую. Они оценивают скорость отклика ИИ-помощника, мгновенность появления рекомендаций и плавность работы автоматизированных процессов. Для многих приложений на базе ИИ задержка перестает быть сугубо сетевой характеристикой и становится важным бизнес-показателем.</p> <h3>Инференс смещается на периферию</h3> <p>Именно задачи инференса во многом стимулируют эти изменения. Если обучение моделей по-прежнему сосредоточено в крупных облачных средах и гипермасштабируемых центрах обработки данных, то инференс все чаще происходит непосредственно в местах выполнения рабочих задач: в больницах, на заводах, в розничных магазинах, финансовых учреждениях, кампусах и филиалах компаний. По прогнозам IDC, в ближайшие несколько лет почти половина предприятий внедрит системы ИИ-инференса на периферии, что снизит зависимость от централизованной обработки данных, но одновременно повысит требования к распределенной инфраструктуре.</p> <h3>Проектирование с упором на предсказуемость, а не только на пропускную способность</h3> <p>За свою карьеру я участвовал в нескольких масштабных этапах трансформации инфраструктуры: от перехода к клиент-серверным архитектурам и виртуализации до внедрения облачных вычислений. Ситуация с ИИ отличается тем, что изменения затрагивают не какой-то один уровень инфраструктуры, а все уровни одновременно, включая сетевой.</p> <p>Речь идет не столько об увеличении пропускной способности сети, сколько о создании сетей, работа которых остается предсказуемой при изменении характера рабочих нагрузок, росте числа пользователей и интеграции ИИ в повседневные бизнес-процессы. Когда ИИ становится неотъемлемой частью деятельности компании, критически важными становятся такие аспекты, как видимость сети, отказоустойчивая маршрутизация, разнообразие каналов связи, комплексная безопасность и интеллектуальное управление трафиком. Новое звучание приобретает и понятие надежности.</p> <p>Когда ИИ задействован в обслуживании клиентов, обеспечении кибербезопасности, производственных процессах или принятии финансовых решений, сбой в работе сети перестает быть просто технической проблемой связи. Он может привести к остановке бизнес-процессов, все сильнее зависящих от аналитики реального времени.</p> <h3>Безопасность должна следовать за данными</h3> <p>В сфере безопасности действуют те же принципы. Системы ИИ взаимодействуют с конфиденциальными корпоративными данными, распределенными по различным средам. Для безопасного перемещения этой информации необходима слаженная работа сетевых и защитных систем, опирающаяся на такие принципы, как модель Zero Trust, сегментация, контроль доступа с учетом идентификационных данных и непрерывный мониторинг.</p> <h3>Подключение данных к интеллектуальным системам</h3> <p>Все это ничуть не умаляет важности вычислительных мощностей. GPU, ускорители и передовые процессоры по-прежнему будут определять возможности ИИ. Однако подход к формированию инфраструктуры должен стать более комплексным.</p> <p>Организации, извлекающие максимальную пользу из ИИ, не просто внедряют более крупные модели. Они создают среду, в которой данные, приложения, пользователи и интеллектуальные системы могут беспрепятственно взаимодействовать друг с другом. Это требует уделения внимания сетевой инфраструктуре на гораздо более ранних этапах проектирования, чем это делалось во многих организациях ранее.</p> <p>На протяжении десятилетий сети обеспечивали связь между людьми и приложениями. Сегодня они все чаще связывают данные с интеллектуальными системами. Я считаю, что это один из важнейших сдвигов в инфраструктуре корпоративных ИТ. Организации, которые осознают это на раннем этапе, возможно, и не создадут самые масштабные системы ИИ, но они будут лучше подготовлены к их масштабированию, адаптации к будущим изменениям и получению реальной бизнес-отдачи от инвестиций в технологии ИИ.</p> Результативность систем искусственного интеллекта зависит от того, насколько предсказуемо и безопасно данные … article https://www.itweek.ru/themes/detail.php?ID=235606 Wed, 23 Sep 2026 16:21:01 +0300 <p>Сбер объявил о запуске нового функционала SaaS-версии ИИ-ассистента разработчика GigaCode для корпоративных клиентов. Теперь бизнесу доступен GigaCode Desktop — инструмент, объединяющий множество агентов, которые упрощают выполнение типовых задач: от поиска информации и анализа документов до подготовки отчетов и презентаций. Об этом рассказал старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка Андрей Белевцев в преддверии конференции ГигаКонф для бизнеса.</p> <p>GigaCode Desktop не ограничивается только лишь работой с кодом. Инструмент может быть востребован в самых разных подразделениях компании, но в первую очередь — у аналитиков, продакт-менеджеров, руководителей проектов и сотрудников со смежными ролями. Благодаря GigaCode Desktop они могут сосредоточиться на нестандартных, креативных задачах, передав рутинные процессы искусственному интеллекту.</p> <p>Ранее GigaCode был протестирован на внутренних бизнес-процессах Сбера. Пилотный проект подтвердил высокую эффективность решения. Он помог повысить производительность команд управления продуктами и бэк-офиса. </p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Мы видим высокий интерес к продукту со стороны компаний, где велика роль внутренней разработки и множество процессов завязано на оформление документации, аналитику и маркетинг. В частности, запросы поступают от девелоперов, инжиниринговых компаний и телеком-сектора. Запуск GigaCode Desktop — наглядный пример нашего подхода к созданию технологических решений: сначала мы внедряем продукт в собственные процессы, оттачиваем его на реальных задачах и добиваемся максимальной эффективности, а уже затем предлагаем проверенный инструмент рынку. Мы убеждены, что именно такая практика позволяет нам гарантировать высокое качество и реальную бизнес-ценность для клиентов каждого продукта».</p> <p>Всем действующим клиентам функциональность GigaCode Desktop будет доступна после планового обновления ИИ-ассистента GigaCode. Новые пользователи смогут протестировать возможности как самого GigaCode, так и нового расширения Desktop в рамках бесплатного периода. Чтобы получить доступ к продукту, достаточно оставить заявку на сайте.</p> Сбер объявил о запуске нового функционала SaaS-версии ИИ-ассистента разработчика GigaCode для корпоративных клиентов. Теперь … message https://www.itweek.ru/themes/detail.php?ID=235605 Wed, 23 Sep 2026 16:19:14 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил вклад инноваций промышленных предприятий в обеспечение технологического суверенитета России. Анализ базируется на данных статистики за <nobr>2022–2025 гг. по видам</nobr> экономической деятельности.</p> <p>Одним из индикаторов технологического суверенитета является динамика объемов инновационных товаров, работ, услуг, которая отражает расширение производства продукции на основе технологических изменений. В 2025 г. объем такой продукции в промышленности составил 9,3 трлн руб. (в целом по экономике — 12,6 трлн руб.), показав не наблюдавшиеся ранее темпы прироста: +22,8% к уровню 2024 г. и +51,6% в сравнении с 2022 г. (в постоянных ценах). Положительная динамика характерна для подавляющего большинства отраслей.</p> <p>Тренд на ускорение инновационных процессов задают обрабатывающие отрасли: в производстве машин и оборудования, электрооборудования объем инновационной продукции за период <nobr>2022–2025 гг.</nobr> вырос в 3,5 раза — до 715,1 и 411,5 млрд руб. соответственно; в авиастроении — в 2,8 раза (927,6 млрд руб.), в производстве компьютеров, электронных и оптических изделий — в 2 раза (892,2 млрд руб.); железнодорожных локомотивов и подвижного состава — в 1,8 раза (129,3 млрд руб.) и др. Среди отраслей легкой промышленности заметно выделяются производители одежды, увеличившие выпуск инновационной продукции более чем втрое.</p> <p>Технологическая независимость во многом строится на продукции высокого уровня новизны. За период <nobr>2022–2025 гг.</nobr> объем вновь внедренных или подвергавшихся значительным технологическим изменениям товаров (работ, услуг) вырос на 65% (в постоянных ценах) и достиг 5,7 трлн руб. В основном это заслуга организаций высоко- и среднетехнологичных отраслей: в производстве готовых металлических изделий ее выпуск составил 1,1 трлн руб. (рост в 4,1 раза по сравнению с 2022 г.), летательных и космических аппаратов — 750,8 млрд руб. (в 3,4 раза), компьютеров, электронных и оптических изделий — 649,1 млрд руб. (в 2,2 раза), машин и оборудования — 526,2 млрд руб. (в 6,7 раза), автотранспортных средств — 393,4 млрд руб. (в 2,4 раза), электрооборудования — 361,4 млрд руб. (в 4,8 раза).</p> <p>Рост производства инновационной продукции сопровождается высокими объемами инвестиций в инновационную деятельность. Затраты на инновации в промышленном производстве достигли 2,2 трлн руб., что на 23,6% больше, чем в 2022 г. Во многом этому способствовало усиление государственной поддержки: объем средств федерального бюджета на инновационную деятельность составил 282,7 млрд руб.</p> <p>Перспективы развития инновационной деятельности складываются в пользу продуктовых инноваций, ускоряющих обновление выпускаемой продукции и создающих основу для достижения технологического суверенитета страны. Затраты на продуктовые инновации в промышленности достигли 1,4 трлн руб. (+55% к уровню 2022 г. в постоянных ценах). Максимальный рост — в производстве электрооборудования, химических веществ и продуктов, компьютеров, машин и оборудования.</p> <p>Инновационная деятельность промышленного производства демонстрирует значительный вклад в обеспечение технологического суверенитета страны. Очевидна ориентация предприятий на увеличение объемов инновационной продукции, особенно высокой степени новизны, которая обеспечивает обновление номенклатуры товаров и услуг на базе новых технологий. В период <nobr>2022–2025 г.</nobr> этот тренд установился в промышленности в целом и — особенно — в таких значимых секторах, как машиностроение, включая транспортное, радиоэлектронику, производство электрического оборудования. Высокие темпы инновационного развития демонстрирует также легкая промышленность.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил вклад инноваций промышленных предприятий … message https://www.itweek.ru/themes/detail.php?ID=235604 Wed, 23 Sep 2026 16:16:29 +0300 <p>В первом полугодии 2026 года число вакансий, где требуется умение работать с искусственным интеллектом, выросло на 37% по сравнению с тем же периодом прошлого года. Исследование «Авито Работы» и маркетплейса нейросетей chad показало, что ИИ-компетенции становятся ощутимым фактором роста доходов: оклады в таких вакансиях растут быстрее среднерыночных, а в отдельных профессиональных сферах разрыв в зарплатных предложениях достигает почти двух раз.</p> <p>Наиболее заметная финансовая разница зафиксирована в сфере маркетинга, рекламы и PR, где соискателям со знанием нейросетей работодатели готовы предложить в среднем 105 917 рублей в месяц против 60 258 рублей без этих навыков. Ощутимый аванс за владение ИИ наблюдается и в юриспруденции, где оклады для специалистов с ИИ-компетенциями достигают 80 000 рублей против 60 538 рублей без них. В сфере страхования эта надбавка составляет около 20%, формируя уровень предложений в 70 000 рублей против 58 321 рубля.</p> <p>В digital-секторе спрос на ИИ-компетенции не просто растет, а становится максимально прикладным. Быстрее всего работодатели увеличивают требования к умению работать с нейросетями для графических дизайнеров (+104%), менеджеров по работе с маркетплейсами (+84%), контент-менеджеров (+43%) и SMM-специалистов (+42%).</p> <p>Эта тенденция работодателей полностью совпадает с изменением реального пользовательского поведения. По данным маркетплейса нейросетей chad, пользователи перешли от абстрактных запросов к точечным рабочим задачам. Доля операций по созданию изображений за год выросла с 2,8% до 20,8%, а по подготовке презентаций и документов — с 8,7% до 12,7%.</p> <p>Параллельно спрос на ИИ-навыки выходит за рамки традиционного digital-сектора. Это соответствует результатам июньского опроса: о встречающихся требованиях к ИИ-навыкам сообщили 31% работников сферы услуг и сельского хозяйства, 30% представителей транспорта и логистики, 28% специалистов торговли, продаж и клиентского сервиса, а также 23% работников промышленности. </p> <p>Вместе с этим расширяется и география применения новых требований. С необходимостью уметь работать с нейросетями при трудоустройстве чаще всего сталкиваются жители Уфы (45%) и Казани (42%). В столицах и крупнейших региональных центрах показатель также держится на высоком уровне: в Москве, Краснодаре и Воронеже об этом заявляют по 38% респондентов, а в Санкт-Петербурге — 35% соискателей.</p> В первом полугодии 2026 года число вакансий, где требуется умение работать с искусственным интеллектом, выросло … message https://www.itweek.ru/themes/detail.php?ID=235603 Wed, 23 Sep 2026 16:13:46 +0300 <p>Сбер представил обновленную среду разработки GigaIDE Pro с повышенной производительностью. — теперь платформа потребляет меньше памяти и предлагает доработанные инструменты для бэкенд- и фронтенд-разработки. Об этом сообщил старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка Андрей Белевцев в преддверии конференции ГигаКонф для бизнеса.</p> <p>В новой версии GigaIDE Pro усилены сценарии работы с данными: пользователи могут эффективнее обрабатывать большие объемы информации, строить прогнозы и автоматизировать аналитику. В числе дополнительной функциональности — расширенная поддержка СУБД, инструментов стилизации, интеграция с очередями сообщений, удаленная разработка на Python и блокноты Jupyter (всего внедрено десять новых инструментов).</p> <p>В рамках обновления реализована поддержка именных лицензий, которые дополняют существующие конкурентные. Именная лицензия позволяет использовать Pro-функциональность без постоянного подключения к локальному серверу лицензирования. </p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «На высококонкурентном рынке инструментов разработки выигрывают решения, которые точно отвечают бизнес-задачам. Широкая функциональность и гибкая модель лицензирования GigaIDE помогают компаниям выбрать оптимальный формат работы и сократить затраты. Кроме того, для пользователей, работающих вне корпоративного контура, не требуется регулярное подключение к серверу. Это упрощает работу в зонах с нестабильным интернетом».</p> <p>Чтобы воспользоваться GigaIDE, достаточно зарегистрироваться в GitVerse, скачать дистрибутив GigaIDE 2026.1 и активировать подписку.</p> Сбер представил обновленную среду разработки GigaIDE Pro с повышенной производительностью. — теперь платформа … message https://www.itweek.ru/themes/detail.php?ID=235598 Wed, 23 Sep 2026 10:39:24 +0300 <p>Пятница, 18:00. Через два часа запланирован релиз, основной регресс почти завершён, но разработчики только что исправили дефект в авторизации. Само исправление проверили, однако пройти все связанные с ним сценарии команда уже не успевает.</p> <p>Блокирующих ошибок нет, перенос релиза потребует дополнительных ресурсов и затронет планы нескольких команд. На первый взгляд ситуация знакомая и вполне рабочая, однако именно в такие моменты возникает один из самых сложных вопросов релизного цикла: достаточно ли мы знаем о состоянии продукта, чтобы выпускать его в продакшен?</p> <p>Ответ пытаются найти в цифрах: регресс пройден на 90%, критических дефектов нет, большая часть сценариев завершилась успешно — формально всё выглядит достаточно уверенно. Но эти показатели мало говорят о реальном риске, пока неизвестно, что именно скрывается в оставшихся 10%.</p> <p>Рассмотрим три ситуации, которые внешне похожи: тестирование не закончено, время до релиза ограничено. Решения при этом могут оказаться совершенно разными.</p> <h3>Ситуация 1. Не успели проверить второстепенную функцию</h3> <p>Предположим, команда не завершила проверку изменений в разделе настроек, которым пользуется небольшая часть аудитории. Функция изолирована, критические бизнес-процессы от неё не зависят, а возможный дефект останется внутри ограниченного пользовательского сценария.</p> <p>В этом случае область неопределённости понятна: команда знает, что именно осталось без полной проверки, кого потенциально затронет проблема и насколько серьёзными будут последствия. При стабильной остальной части продукта такой риск вполне может быть приемлемым для релиза.</p> <p>Ситуация меняется, когда последнее исправление находится в компоненте, от которого зависит значительная часть системы.</p> <h3>Ситуация 2. Перед релизом исправили авторизацию</h3> <p>За несколько часов до запуска разработчики обнаружили проблему в авторизации и внесли исправление. Повторная проверка подтверждает, что исходный дефект устранён, изменение затрагивает общий сервис авторизации, от которого зависят веб-приложение, мобильное приложение и интеграционные сценарии.</p> <p>В релизном отчёте картина по-прежнему выглядит благополучно: основной регресс завершён, блокирующих дефектов нет, последнее исправление работает. Однако уровень неопределённости вырос, поскольку небольшое изменение оказалось в точке, через которую проходят сразу несколько частей продукта.</p> <p>Именно поэтому после поздних исправлений важно понимать область их влияния. Вопрос «Работает ли фикс?» даёт лишь часть информации. Гораздо важнее выяснить, какие компоненты используют изменённый код, какие пользовательские сценарии через него проходят и где ещё могут проявиться последствия.</p> <p>Иногда один такой вопрос даёт для решения о релизе больше, чем десятки дополнительных тест-кейсов.</p> <h3>Ситуация 3. Изменили платёжный API</h3> <p>Команда изменила платёжный API, проверила проведение оплаты и получила успешный результат. Формально критическая операция работает, однако в продукте платёж не существует сам по себе. Обычно за ним следует целая цепочка: оплата → изменение статуса заказа → передача данных в смежные системы → складские операции → возврат.</p> <p>После изменения API команда успела проверить начало этой цепочки, но пройти её полностью до релиза уже не сможет. В такой ситуации успешная оплата ещё ничего не говорит о том, корректно ли создастся заказ, получит ли склад необходимые данные, появится ли информация в CRM и сможет ли пользователь впоследствии оформить возврат.</p> <p>Особенность подобных ошибок заключается в том, что релиз может выглядеть успешным. Пользователи оплачивают покупки, сервис отвечает, мониторинг не показывает очевидного падения, а проблема тем временем возникает дальше по цепочке и обнаруживается спустя несколько часов.</p> <p>Поэтому отсутствие критических дефектов само по себе ещё не делает релиз безопасным. Найденные ошибки описывают то, что команда уже увидела; релизный риск во многом определяется тем, чего она могла не увидеть.</p> <p>В практике QA-сопровождения мы регулярно сталкиваемся с ситуациями, когда решение о выпуске приходится принимать при незавершённом регрессе или после изменений, внесённых незадолго до релиза.</p> <p> <strong>Красные флаги перед релизом: </strong></p> <ul> <li> <strong>последние изменения затрагивают авторизацию, платежи, данные или ключевые интеграции</strong>, а времени на проверку связанных сценариев уже нет;</li> <li> <strong>область влияния изменения остаётся неясной</strong>: команда понимает, что исправили, но не может уверенно сказать, какие компоненты и процессы зависят от этого участка системы;</li> <li> <strong>проблему после запуска будет сложно быстро заметить</strong> — критические операции недостаточно покрыты мониторингом, а последствия могут накапливаться постепенно;</li> <li> <strong>последствия трудно локализовать или безопасно откатить</strong>: даже после возврата предыдущей версии уже выполненные операции, изменённые данные или отправленные события потребуют отдельного восстановления.</li> </ul> <p>Каждый из этих признаков ещё не означает, что релиз нужно отменять. Но сочетание нескольких красных флагов заметно повышает цену ошибки и требует гораздо более веских оснований для решения о выпуске.</p> <h3>Что делать, если ошибка обнаружится уже после релиза</h3> <p>Даже тщательно проведённое тестирование не исключает проблем в продакшене, поэтому качество релизного решения зависит ещё и от способности команды быстро увидеть отклонение и ограничить его последствия.</p> <p>Перед запуском стоит понимать, какие сигналы покажут проблему, есть ли мониторинг критических операций, насколько быстро можно определить источник сбоя и возможен ли безопасный откат. Для некоторых систем важен и следующий вопрос: сколько операций успеет пройти до того момента, когда команда заметит ошибку.</p> <p>Если отклонение обнаруживается за несколько минут, а изменение можно быстро откатить без потери данных, команда получает больше пространства для принятия риска. Когда сбой способен часами оставаться незаметным и постепенно затрагивать пользователей, заказы или финансовые операции, требования к уверенности перед релизом становятся значительно выше.</p> <p>Два технически похожих релиза могут требовать разных решений даже при одинаковом объёме тестирования.</p> <h3>Пять вопросов перед Go/No-Go</h3> <p>Когда до запуска остаётся несколько часов, длинный отчёт с количеством тестов и дефектов уже не всегда помогает увидеть главное. Для решения о выпуске полезнее последовательно ответить на пять вопросов:</p> <ol> <li> Какие критические пользовательские и бизнес-сценарии действительно проверены?</li> <li> Какие изменения появились после последней стабильной проверки?</li> <li> Какие системы, интеграции и процессы зависят от этих изменений?</li> <li> Какими будут последствия, если ошибка находится именно в непроверенной области?</li> <li> Насколько быстро команда сможет обнаружить проблему, ограничить её влияние и при необходимости откатить релиз?</li> </ol> <p>Ценность этих вопросов в том, что они переводят разговор с количества выполненных тестов на качество понимания риска.</p> <h3>Так выпускать или переносить? Кто должен сказать последнее слово</h3> <p>В спорной ситуации от QA иногда ждут простого ответа: выпускать или переносить. Но решение о релизе выходит за рамки качества кода и результатов тестирования. У него есть техническая, продуктовая и бизнес-цена.</p> <p>Задача QA в этот момент — сделать риск видимым: показать, что проверено, где остались пробелы, какие компоненты могут быть затронуты и насколько серьёзными окажутся последствия. Дальше у владельца релиза появляется основание для решения: принять этот риск, сократить объём выпуска или перенести запуск.</p> <p>Хороший Go/No-Go заканчивается не фразой «QA разрешил релиз», а общим пониманием команды: какой риск мы принимаем и почему считаем его допустимым.</p> <p>#IMAGE_235599#</p> Пятница, 18:00. Через два часа запланирован релиз, основной регресс почти завершён, но разработчики только что исправили … article Денис Кульчавый, заместитель генерального директора компании “Точка качества” https://www.itweek.ru/themes/detail.php?ID=235597 Wed, 23 Sep 2026 10:19:03 +0300 <p><em>Мы уже много лет называем современные автомобили «компьютерами на колесах». Большинство людей согласно кивают и идут дальше. Однако это определение становится все более важным — гораздо более важным, чем многие осознают. Руководителям служб информационной безопасности необходимо обратить внимание на этот возникающий риск, пишет в корпоративном блоге Пэдди Харрингтон, старший аналитик </em><em>Forrester</em><em>.</em></p> <p>Недавние исследования выявили вредоносное ПО, созданное специально для атаки на информационно-развлекательные системы автомобилей под управлением Android. Это знаменует собой важный этап в эволюции угроз для «подключенных» автомобилей (connected vehicles). Вполне естественно, что основное внимание уделяется последствиям для автопроизводителей и потребителей, но руководителям в области корпоративной безопасности также следует принять это к сведению. Ведь суть не в том, что автомобили внезапно стали уязвимыми — мы уже давно знаем, что подключенные автомобили несут в себе риски кибербезопасности. Важно то, что злоумышленники начинают рассматривать автомобильные платформы просто как очередное вычислительное устройство, которое можно атаковать.</p> <h3>Модель угроз для подключенных автомобилей меняется</h3> <p>Исторически сложилось так, что многие атаки на подключенные автомобили были направлены на смежные системы. Исследователи демонстрировали, как уязвимости в клиентских приложениях, API и облачных сервисах позволяют злоумышленникам отправлять команды автомобилям, тогда как для других атак требовались физическая близость и специализированные инструменты для получения доступа к функциям автомобиля. Эти инциденты подчеркивали риски, связанные с подключенными автомобилями, но редко затрагивали вредоносное ПО, разработанное непосредственно для самого автомобиля.</p> <p>Последние исследования свидетельствуют о значительных переменах. Вместо того чтобы атаковать платформы управления автомобилем или подключенные сервисы, злоумышленники создали вредоносное ПО для самой информационно-развлекательной системы. Это означает, что целью становится одна из самых заметных и функционально мощных вычислительных сред автомобиля.</p> <p>Нынешняя кампания, по-видимому, сосредоточена на активности ботнетов; цели будущих атак могут быть иными, но руководителям служб безопасности следует обращать внимание на саму тенденцию, а не на конкретный образец вредоносного ПО.</p> <h3>У ваших сотрудников есть автомобили. Подключены ли к ним мобильные устройства вашей компании?</h3> <p>Многие организации по-прежнему считают, что безопасность подключенных автомобилей касается прежде всего автопроизводителей. Однако такой подход упускает из виду сотрудников, которые подключают свои мобильные устройства к автомобилям через Bluetooth, USB, мобильные приложения и облачные сервисы. Операторы автопарков, сервисные и коммунальные службы, транспортные компании и предприятия, чья деятельность зависит от использования автомобилей, все активнее внедряют технологии подключенных транспортных средств. В результате формируется экосистема, в которой автомобили, мобильные устройства, приложения и корпоративные данные тесно взаимосвязаны.</p> <p>Когда в эту экосистему добавляется очередное подключенное устройство, руководителям служб безопасности стоит задаться вопросами:</p> <ul> <li> Что произойдет, если устройство будет скомпрометировано?</li> <li> Как мы сможем обнаружить вредоносную активность?</li> <li> Может ли вредоносное ПО перемещаться между подключенными системами?</li> <li> Насколько хороша видимость этого устройства и связанных с ним рисков?</li> </ul> <p>Это типичные вопросы при обсуждении ноутбуков, смартфонов, устройств Интернета вещей (IoT) и операционных технологий (OT). Теперь такого же внимания требуют и подключенные к сети автомобили.</p> <h3>Главная проблема — не сам автомобиль</h3> <p>Непосредственная угроза, связанная с этим вредоносным ПО, заключается не столько в том, что злоумышленники могут получить полный контроль над автомобилями (хотя это, безусловно, важно для безопасности сотрудников), сколько в другом. Подключенные автомобили все чаще работают под управлением встроенных операционных систем, имеющих общие черты с технологическими платформами, которые специалистам по безопасности и так сложно защищать (например, IoT- или OT-устройствами). Кроме того, в данном случае автомобили напоминают системы сторонних организаций (подрядчиков, автопроизводителей, поставщиков): они подключены к корпоративной сети, но у аналитиков по безопасности нет средств для контроля над ними.</p> <p>Вредоносное ПО для Android — не новость. Специалисты по безопасности годами борются с угрозами, нацеленными на мобильные ОС. Появление вредоносных программ для автомобильных систем на базе Android говорит о том, что злоумышленники все чаще рассматривают автомобили как еще один элемент экосистемы подключенных технологий, а не как отдельную категорию устройств.</p> <p>Это ставит перед аналитиками по безопасности новые вопросы:</p> <ul> <li> Может ли вредоносное ПО, находящееся в системе подключенного автомобиля, попытаться взаимодействовать с мобильным устройством, сопряженным через Bluetooth или USB?</li> <li> Смогут ли организации обнаружить такую ​​активность?</li> <li> Достаточно ли развиты средства обеспечения мобильной безопасности, чтобы выявлять подозрительное поведение, исходящее от нестандартных конечных точек?</li> </ul> <p>Сегодня эти вопросы носят преимущественно теоретический характер, поскольку мы еще не сталкивались с подобными атаками, распространяющимися между системами. Однако руководителям служб безопасности не стоит сбрасывать этот сценарий со счетов: отрасль уже не раз видела, как злоумышленники, закрепившись на одной платформе, переходят на смежные системы. Кто из вас до <nobr>2025-го</nobr> мог предположить, что через веб-камеру можно обойти защиту EDR и атаковать рабочие станции программами-вымогателями?</p> <h3>Без паники! Но, пожалуйста, пересмотрите свои риски</h3> <p>Организациям не нужно кардинально пересматривать свои программы обеспечения безопасности лишь из-за появления еще одного семейства вредоносного ПО. Однако им следует принять три положения:</p> <ol> <li> Включать подключенные автомобили в процессы моделирования угроз там, где это уместно — особенно организациям, имеющим собственный автопарк или сотрудников, часто подключающих корпоративные устройства к автомобилям (в том числе тех, кто пользуется услугами аренды транспорта во время командировок).</li> <li> Обеспечить возможность выявления вредоносного ПО и подозрительной активности на корпоративных и личных (BYOD) мобильных устройствах до того, как угроза затронет корпоративные приложения, данные или облачные сервисы.</li> <li> Рассматривать подключенные автомобили как часть более широкой экосистемы бизнес-технологий, а не как изолированные активы.</li> </ol> Появление этого нового вредоносного ПО для Android свидетельствует о том, что вопросы безопасности подключенных автомобилей переходят из плоскости теоретических обсуждений в сферу практического управления Мы уже много лет называем современные автомобили «компьютерами на колесах». Большинство людей согласно кивают … article https://www.itweek.ru/themes/detail.php?ID=235595 Wed, 23 Sep 2026 10:01:57 +0300 <p>Искусственный интеллект ускоряет разработку, но вместе со скоростью растёт цена неверно поставленной задачи. Чем быстрее команда превращает требования в код, тем важнее заранее проверить бизнес-логику, ограничения и критерии результата.</p> <h2>Код действительно становится дешевле — но не весь проект</h2> <p>Мы уже видим, что ИИ снижает трудоёмкость части разработки. Разработчик тратит меньше времени на разбор существующего кода, типовые фрагменты реализации, подготовку тестов и черновой документации. Часть задач удаётся выполнять быстрее и меньшим составом.</p> <p>Когда мы говорим, что код становится дешевле, речь именно об этом: на его производство и связанные с ним рутинные операции требуется меньше человеко-часов. Но это не значит, что вместе с кодом так же заметно дешевеет весь проект.</p> <p>Архитектуру всё равно нужно продумать, интеграции — спроектировать и проверить, права доступа — определить, данные — перенести без потерь. В сложных корпоративных системах остаётся большой объём работы, который нельзя свести к генерации кода.</p> <p>У коллег по отрасли есть более заметные примеры: задачи, для которых раньше требовалась команда примерно из десяти человек и несколько месяцев работы, сейчас в отдельных случаях выполняют втроём и примерно вдвое быстрее. У нас динамика та же: ИИ снимает часть рутинной нагрузки, но не заменяет решения, от которых зависит устройство системы.</p> <h2>Узкое место смещается к постановке задачи и проектированию</h2> <p>На наших проектах это уже хорошо заметно. Код можно получить быстрее, а вот понять, какой именно код нужен быстрее получается далеко не всегда. До реализации всё равно приходится разобраться в бизнес-процессе, снять противоречия и принять решения, которые модель не может принять за заказчика.</p> <p>Допустим, компания хочет автоматизировать согласование заявки. Собрать форму и базовый сценарий сегодня несложно. Но сначала нужно определить, откуда система берёт исходные данные, кто имеет право их менять, что происходит при сбое внешней системы, какие действия нужно сохранять для аудита и где проходит граница ответственности между несколькими системами.</p> <p>ИИ может предложить вполне разумный вариант. Разработчик тоже может сделать логичное предположение. Но ни то ни другое не гарантирует, что предположение соответствует реальному процессу компании. Если такой вопрос не прояснить, неверная логика довольно быстро попадёт не только в код, но и в тесты, интеграции и документацию.</p> <h2>ИИ может быстро оформить требования, но не может сформировать их за бизнес</h2> <p>Меняются и границы ролей внутри команды. Разработчик с помощью ИИ может сам быстрее разобрать исходные материалы, подготовить прототип, черновик требований, описание API или документацию. Меньше времени уходит на рутину и на пересказ одной и той же задачи от одного специалиста другому.</p> <p>Но между оформить требования и сформировать их есть принципиальная разница. Инструменты искусственного интеллекта хорошо структурируют уже имеющуюся информацию. Они могут превратить заметки встречи в список требований, пользовательские сценарии или критерии приёмки. Они же способны заметить противоречия и предложить варианты решения. Но выбрать вариант за бизнес они не могут.</p> <p>Если два подразделения по-разному понимают один процесс, сначала нужно договориться между собой. Если одни и те же данные хранятся в нескольких системах, кто-то должен решить, какая из них считается основной. Если не определено, кто вправе отменить операцию после проведения платежа, более подробная спецификация сама по себе проблему не устранит.</p> <p>Поэтому ИИ снижает трудоёмкость оформления требований, но не снижает автоматически трудоёмкость понимания задачи. На фоне ускорившейся реализации эта разница становится особенно заметной.</p> <h2>Почему быстрый прототип иногда вводит в заблуждение</h2> <p>Заказчики тоже начинают активно использовать ИИ и самостоятельно собирать прототипы: формы, личные кабинеты, небольшие внутренние сервисы. Для проверки гипотез это полезно — рабочий сценарий можно получить быстро и без больших затрат.</p> <p>Но вместе с этим меняется и восприятие самой разработки. Если представитель компании за вечер собрал работающий прототип, у него закономерно возникает вопрос: почему подрядчику на полноценную систему нужны месяцы работы и совсем другой бюджет?</p> <p>Коллеги по рынку уже сталкиваются с такими ситуациями. Топ-менеджер крупной компании самостоятельно собирает прототип личного кабинета, а затем использует этот опыт в переговорах с подрядчиком: если первый результат появился за вечер, что именно занимает столько времени в промышленной разработке? Иногда это становится и аргументом для снижения цены.</p> <p>Проблема в том, что сравниваются разные объёмы работы. В прототипе достаточно показать основной сценарий. В промышленной системе нужно ещё решить, как хранить данные, разграничивать доступ, переживать сбои интеграций, работать под реальной нагрузкой и сопровождать решение после запуска.</p> <p>Поэтому быстрый прототип — не доказательство того, что весь проект прост. Это способ дёшево проверить гипотезу до того, как команда начнёт строить вокруг неё полноценную систему.</p> <h2>Когда ошибка в требованиях действительно становится дороже</h2> <p>Сама по себе высокая скорость разработки не делает ошибку дороже. Иногда всё происходит наоборот: прототип помогает быстро понять, что гипотеза неверна, и отказаться от неё до серьёзных затрат. Риск появляется тогда, когда непроверенное предположение принимают за подтверждённое требование и используют как основу для следующих этапов.</p> <p>Представим, что при автоматизации расчёта неверно определили одно бизнес-правило. На его основе подготовили спецификацию и написали код. Если тесты тоже строятся на той же спецификации, они могут успешно проходить: реализация делает именно то, что в них заложено. Затем та же логика попадает в интеграцию и документацию.</p> <p>При сверке с реальным бизнес-процессом может выясниться, что само исходное правило было неверным. И тогда исправлять приходится уже не одну формулировку в ТЗ, а связанные сценарии, код, тесты, интеграции, а иногда и данные.</p> <p>В этом и заключается новый риск: ИИ способен быстро масштабировать не только правильное решение, но и ошибочное исходное предположение. Цена такой ошибки зависит от того, когда её обнаружили и сколько частей системы уже построено вокруг неверной логики.</p> <h2>Что нужно выяснить до того, как ускорять реализацию</h2> <p>Не всю неопределённость нужно устранять заранее. Расположение элементов интерфейса, тексты, навигацию или отдельные UX-гипотезы часто выгоднее проверить на прототипе.</p> <p>Но есть вопросы, которые не стоит оставлять модели или разработчику на усмотрение. Перед реализацией мы бы рекомендовали проверили пять вещей.</p> <h3>1. Что должно измениться после запуска?</h3> <p>Не просто «нужен личный кабинет», а конкретный результат: например, клиент сможет самостоятельно выполнить операцию, ради которой сейчас обращается к менеджеру.</p> <h3>2. Какие бизнес-правила нельзя трактовать по-разному?</h3> <p>Особенно это касается расчётов, денег, обязательств, прав доступа, согласований и исключений из основного сценария. Команда должна понимать, где она может принять рабочее решение сама, а где любое предположение нужно согласовать.</p> <h3>3. Откуда берутся данные, и кто за них отвечает?</h3> <p>Если одна и та же информация находится в нескольких системах, нужно заранее решить, какая из них считается основной и откуда должны приходить изменения.</p> <h3>4. Где проходят границы системы и какие ограничения влияют на архитектуру?</h3> <p>Важно понимать, что делает новый компонент, а что остаётся на стороне CRM, ERP или других сервисов. Здесь же нужно зафиксировать критичные требования к нагрузке, безопасности, доступности, восстановлению и аудиту.</p> <h3>5. Как будет проверяться результат?</h3> <p>Нужны два уровня проверки. Первый — критерии приёмки: система делает именно то, о чём договорились. Второй — эффект для бизнеса: например, сократилось время операции, исчезла ручная работа или снизилось количество ошибок.</p> <p>Если ответы на эти вопросы остаются неопределёнными, ИИ не устраняет проблему. Он просто помогает быстрее зафиксировать непроверенные предположения в реализации.</p> <h2>Чем быстрее появляется код, тем важнее решения до него</h2> <p>Ускорение разработки меняет не только работу программиста, но и требования к управлению проектом. Чем меньше времени занимает производство очередной версии решения, тем важнее понимать, какие вопросы можно проверить экспериментом, а какие нельзя отдавать в реализацию без однозначного ответа.</p> <p>Для сложной корпоративной системы ценность всё меньше определяется количеством написанного кода. Гораздо важнее вовремя найти противоречие, определить источник данных, договориться о бизнес-правиле или увидеть архитектурное ограничение до того, как вокруг ошибочного решения появятся код, тесты и интеграции.</p> <p>Поэтому главный вопрос для заказчика теперь звучит не только так: как быстро команда сможет реализовать задачу? Не менее важно другое: достаточно ли хорошо мы понимаем задачу, чтобы действительно выигрывать от этой скорости?</p> <p>#IMAGE_235596#</p> Искусственный интеллект ускоряет разработку, но вместе со скоростью растёт цена неверно поставленной задачи. Чем … article Надежда Кадырлеева, исполнительный директор DIGITAL SECTOR https://www.itweek.ru/themes/detail.php?ID=235594 Tue, 22 Sep 2026 16:47:13 +0300 <p>За последние несколько лет российский ИТ-рынок прошёл через глобальные изменения. В новых условиях производители и партнёры — интеграторы, ретейлеры, сервис-провайдеры — ожидают от дистрибьюторов не только услуг по логистике и продажам. Согласно исследованию OCS, самыми востребованными сервисами становятся финансовые услуги, сервисная поддержка и технологическая экспертиза.</p> <p>Аналитики отметили, что наибольший интерес рынок проявляет к финансовым сервисам. Более 22% партнёров и 12% вендоров рассчитывают на расширение услуг в этом направлении. Это связано со спецификой ИТ-отрасли: заказчики нуждаются в сложных технологических решениях, но их разработка требует от производителей значительных вложений с длительным сроком окупаемости. Исследование OCS показало, что каждый четвёртый вендор считает финансовый вопрос главным риском в перспективе ближайших нескольких лет. Ключевая ставка остаётся высокой, а кредиты не доступны для широкого канала. Крупные дистрибьюторы, со своей стороны, предоставляют помощь в проведении расчётов и оформлении коммерческих кредитов для реализации проектов — и спрос на такую поддержку только растёт. </p> <p>Сервисное обслуживание — второе направление, которое становится приоритетным для рынка. По наблюдениям аналитиков, из дополнительной услуги техническая поддержка превратилась в решающий фактор для всех игроков. На наличие такой услуги у дистрибьюторов обращает внимание каждый четвёртый партнёр, а каждый пятый вендор заинтересован в сервисе и обучении по своим продуктам. И производители, и многие партнёры имеют собственные сервисные подразделения, однако ключевой сложностью для рынка остаётся доступность запчастей и обслуживание географически распределённых объектов. Вендоры активно выходят на региональные рынки: по данным OCS, такие планы озвучивает почти четверть российских компаний. Организовать оперативный сервис в разных регионах, поддерживать наличие ЗИП и быстро доставить их в случае необходимости — эти задачи часто берут на себя федеральные интеграторы и ИТ-дистрибьюторы.</p> <p>Потребность в мультивендорной экспертизе также растёт. Сегодня ИТ-инфраструктура заказчиков состоит из множества решений: отечественных, китайских, мировых А-брендов. Импортозамещение набирает темп, однако пока охватывает не все сегменты рынка равномерно. Например, только у 9% компаний российское сетевое оборудование составляет более половины парка. Схожая картина и в направлении серверов и СХД: только половина компаний нарастила долю отечественных решений до 25%. Масштабирование инфраструктуры, обновление и обслуживание оборудования требуют наличия инженерной сертификации по решениям различных производителей. Дистрибьюторы, объединяющие под своим крылом широкий спектр брендов, помогают интегрировать новые продукты в текущую инфраструктуру и заранее протестировать их на совместимость. 63% партнёров и 37% вендоров отметили роль дистрибьюторов в технологических партнёрствах.</p> <p>«Развитие ИТ-рынка сегодня — это симбиоз всех участников. После нескольких лет быстрого роста он достиг определённых пределов: на дальнейшем пути стоит дефицит кадров, ресурсов и технологий. Залогом успеха становится не только скорость принятия решений, но и умение выстраивать надёжные партнёрства. Мы видим, что дистрибьюторы всё чаще играют важную роль в их формировании. Это говорит об уровне доверия со стороны рынка — как к компаниям, так и к их сервисам», — прокомментировала Анна Чернякова, вице-президент OCS. </p> <p>Роль дистрибьюторов давно вышла за рамки стандартных услуг по логистике и продвижению товаров. «Базовые» сервисы всё так же важны: партнёры заинтересованы в вариативных каналах поставок, производители нуждаются в поддержке для освоения новых рынков. Однако требования и запросы рынка растут, и дистрибьюторы отвечают на них, предлагая сервисы, которые помогают игрокам справляться с актуальными вызовами.</p> <p>Интерес к таким услугам, как сервис, финансы и технологическая экспертиза, отражает текущие проблемы производителей и партнёров. Спрос на кредитную поддержку может меняться в зависимости от экономической ситуации. Но потребность в мультивендорной экспертизе и обслуживании комплексных систем в ближайшие несколько лет может стать только острее. В таких сегментах, как сетевое и вычислительное оборудование, доля иностранных решений всё ещё очень высока — и компаниям нужна поддержка для проектирования, аудита и сопровождения инфраструктур. Дистрибьюторы закрывают эти запросы с помощью гибкой экосистемы сервисов и способствуют реализации сложных проектов даже в условиях нестабильности рынка. </p> За последние несколько лет российский ИТ-рынок прошёл через глобальные изменения. В новых условиях производители … message https://www.itweek.ru/themes/detail.php?ID=235592 Tue, 22 Sep 2026 10:25:48 +0300 <p><em>Anthropic утверждает, что написание кода больше не является узким местом. И это так, однако процесс выявления ошибок, допущенных агентом искусственного интеллекта, не может быть универсальным для любых изменений, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Анирудх Раманатхан, технический директор компании Signadot.</em></p> <p>Anthropic недавно опубликовала «плейбук» (стандартизированный сценарий действий) по жизненному разработки ПО (SDLC), ориентированному на ИИ (AI-Native SDLC Playbook). Его ключевой тезис гласит: «Написание кода больше не является узким местом». Когда агенты способны реализовать задачу за считанные минуты, ограничения смещаются на этапы, сопутствующие сборке: планирование, проверку (ревью), верификацию, развертывание и управление процессами.</p> <p>Если организации выстроят работу неверно, возникнет риск появления в десять раз большего числа изменений при прежнем (или даже худшем) качестве каждого из них, причем без возможности выявить неудачные решения. Традиционный подход предполагает, что каждое изменение проверяет человек, но именно этот метод перестает работать при таких объемах.</p> <p>В плейбуке верно определены базовые принципы. Однако упущена важная деталь: процессы в организации имеют свои нюансы. На самом деле это не единый поток, через который проходят все изменения, а совокупность различных процессов, зависящих от конкретной задачи.</p> <h3>Волна инструментов разработки на основе спецификаций</h3> <p>Этот плейбук — часть более широкой волны инструментов разработки, опирающихся на спецификации (например, Amazon Kiro и GitHub Spec Kit). Все они имеют схожую структуру. В основе лежат текстовые артефакты: документ с описанием замысла трансформируется в спецификацию, план, diff (разница в коде) и результаты проверки — и всё это фиксируется в системе контроля версий. Соблюдение правил обеспечивается детерминированными механизмами (например, хуками), а не просто инструкциями в промпте. Агенты сами проверяют свою работу, прежде чем ее увидит человек. При этом окончательное решение об утверждении остается за людьми.</p> <p>Однако каждый из этих инструментов навязывает определенный процесс: фиксированную последовательность этапов и артефактов, через которые проходит любое изменение. Внедрение инструмента означает и принятие соответствующего процесса.</p> <h3>В одной организации выполняется множество процессов</h3> <p>Ни одна реальная организация не работает по единственному процессу. Выбор подходящего процесса зависит от рисков, связанных с изменением, и требуемого уровня ответственности. Исправление документации, обновление зависимостей и миграция схемы данных в платежном сервисе не должны проходить по одному и тому же пути. Для них требуются разные уровни проверки, разные ответственные за утверждение и разные формы отчетности. В регулируемых отраслях сам процесс является частью обязательств по соблюдению нормативных требований: аудиторы требуют наличия записей о том, кто утвердил каждое изменение и на основании каких данных. Состав фиксируемой информации зависит от типа изменения.</p> <p>Если инструмент навязывает единственный вариант процесса, команды находят способы обойти его при внесении изменений, которые не вписываются в заданные рамки. Это худший сценарий, поскольку реальный процесс становится невидимым. Либо же поставщик продолжает усложнять настройки, превращая инструмент в движок рабочих процессов, в котором никто не может разобраться до конца.</p> <p>Инструмент не должен навязывать процесс. Он должен предоставлять организации возможность определить собственный процесс.</p> <h3>Процессы как автоматы состояний</h3> <p>Более удачная модель — определение каждого процесса как автомата состояний (state machine). Состояния отражают факты, касающиеся изменения: например, «проверено», «проверено на соответствие зависимостям», «одобрено для внедрения в продакшен». Эти факты хранятся в различных системах, не принадлежащих какому-то одному инструменту: в репозитории, системе CI, кластере или системе отслеживания задач. Следовательно, процесс не может быть программой, последовательно выполняющей шаги. Это набор правил, реагирующих на информацию, поступающую из указанных систем. Каждое правило определяет:</p> <ol> <li> Факты, необходимые для срабатывания правила.</li> <li> Условие перехода (гейт): автоматическое срабатывание или ожидание одобрения человеком.</li> <li> Разрешение, предоставляемое при срабатывании (например, на слияние веток или развертывание).</li> </ol> <p>Определение процесса представляет собой набор таких правил, хранящихся в виде данных и проходящих ревью подобно программному коду. Организация использует множество небольших автоматов — по одному на каждый класс рисков.</p> <p>В процессе выполнения такая система работает совсем не так, как классический движок рабочих процессов. Ни один компонент не отслеживает текущий этап (например, «мы на четвертом шаге»): процесс продвигается вперед, когда в соответствующей системе появляется новый факт, на который реагируют правила. События, поступившие с опозданием, дублирующиеся или пришедшие после перезапуска системы, обрабатываются так же, как и любые другие, поскольку правила реагируют только на текущее состояние. Гейт является одним из условий правила, поэтому можно приостановить выполнение (например, во время инцидента или заморозки релизов), не меняя при этом само определение процесса.</p> <p>Условия перехода требуют принудительного соблюдения. Если гейт реализован лишь как инструкция, его выполнение зависит от того, будут ли ей следовать. Агентная обвязка может обеспечить детерминизм, необходимый для работы автомата состояний и соблюдения условий перехода, приостанавливая выполнение действий до получения подтверждения, в то время как инфраструктура обеспечивает соблюдение остальных требований.</p> <h3>Процесс адаптируется к изменениям</h3> <p>Одного фиксированного определения процесса для репозитория недостаточно: в этом случае любое изменение проходило бы по одному и тому же пути, независимо от уровня риска. Маршрут изменения должен зависеть от его сути; выбор маршрута определяется классификацией изменения, а не решением автора. Организация выстраивает классификацию на основе имеющихся данных: затронутых путей в коде, репозитория, в котором находится изменение, меток в задаче (issue) и т. д.</p> <p>Сами определения процессов также должны со временем меняться, причем безопасно. Поскольку определение процесса — это данные, его редактирование само по себе является изменением и проходит через собственный регламентированный процесс проверки. Смягчение требований к утверждению этапа выпуска (релиза) рассматривается так же, как миграция схемы данных, а не просто редактируется как файл конфигурации.</p> <p> #IMAGE_235593#</p> <p>Рассмотрим для примера три изменения в одном и том же сервисе:</p> <ul> <li> <strong>Исправление документации</strong> классифицируется на основе затронутых путей. Процесс включает два этапа: успешная сборка и слияние. Участие человека не требуется.</li> <li><strong> Обновление зависимостей</strong> не требует проверки архитектурного решения, но процесс предусматривает подтверждение совместимости: обновленный сервис проходит интеграционные тесты с реальными зависимостями. При переходе на мажорную версию добавляется этап утверждения, отсутствующий при обновлении патч-версии.</li> <li><strong> Миграция схемы данных в платежном сервисе</strong> классифицируется по затронутому компоненту, независимо от того, как заявлено само изменение. Процесс включает дополнительные этапы, отсутствующие в других случаях: проверку владельцем платежного сервиса, валидацию на данных, имитирующих реальную рабочую среду (production-shaped data), и утверждение выпуска ответственным за данную область специалистом.</li> </ul> <p>Каждый переход на любом из маршрутов фиксируется в журнале с указанием того, кто его утвердил и на основании каких данных.</p> <h3>Принципы</h3> <p>Процессы должны строиться на следующих принципах:</p> <ul> <li><strong> Автономия предоставляется для конкретных действий и возрастает со временем.</strong> Для каждого перехода настраиваются автоматическое выполнение, необходимость утверждения или режим ожидания. По мере того как агенты доказывают свою надежность в работе с определенным классом изменений, требования смягчаются; таким образом, процесс адаптируется к улучшениям в работе агентов без необходимости перепроектирования.</li> <li><strong> Внимание человека требуется только там, где необходимо принятие решения, основанное на суждении.</strong> Затраты на работу агентов снижаются, а затраты времени на контроль — нет. Человек подключается к процессу только тогда, когда решение требует экспертной оценки, и получает всю необходимую информацию для быстрого принятия решения.</li> <li><strong> Подтверждающие данные поступают извне, а не от самого агента.</strong> Отчет, сформированный самим агентом, никогда не служит основанием для продвижения изменения на следующий этап. Переходы инициируются на основе фактов, поступающих из систем, в которые агент не может вносить записи (например, результаты тестирования или данные валидации в реальных условиях эксплуатации).</li> <li><strong> Записи о процессе служат журналом аудита.</strong> Описание процесса представляет собой зафиксированный регламент, а журнал переходов фиксирует, кто и на основании каких данных утвердил каждый этап, а также какая версия регламента при этом применялась.</li> </ul> <h3>Обеспечение качества в масштабе</h3> <p>Использование плейбуков и аналогичных инструментов закладывает надежный фундамент. Однако организации также необходима возможность самостоятельно определять процессы, варьировать их в зависимости от уровня риска конкретного изменения и безопасно их совершенствовать. Цель состоит не в том, чтобы исключить человека из процесса принятия решений. Задача — задействовать человеческое суждение лишь там, где это действительно необходимо, опираясь на факты, которые агенты не могут сгенерировать самостоятельно; это позволяет поддерживать высокое качество при многократном росте пропускной способности.</p> Anthropic утверждает, что написание кода больше не является узким местом. И это так, однако процесс выявления ошибок … article https://www.itweek.ru/themes/detail.php?ID=235590 Tue, 22 Sep 2026 10:07:09 +0300 <p>Сегодня каждая вторая дорожная карта ИТ-директора содержит пункт о внедрении ИИ-инструментов для разработки. Ожидания завышены, поскольку аналитики сулят рост производительности на 40%, мгновенное сокращение времени на рутину, выход команд на новый уровень. Однако на практике мы видим иную картину, где пилотные проекты завершены, инструменты закуплены, сделаны большие инвестиции в инфраструктуру, а взрывной трансформации не произошло. Разработчики используют нейросети, но релизы не ускоряются, архитектурные решения не становятся элегантнее, а технический долг не испаряется мгновенно.</p> <p>Заявленные 40% — это миф, но с оговоркой. Да, на отдельной операции по написанию кода ИИ способен дать такое ускорение. Однако программист тратит на написание кода лишь около 30% своего времени. Поэтому общий прирост продуктивности отдельного специалиста редко превышает 10%. Компании ошибочно подменяют системную трансформацию процессов точечной автоматизацией задач, забывая про остальные 70% рабочего времени и контекст enterprise-разработки. Производительность — свойство системы, а не сумма индивидуальных эффективностей.</p> <h2>Ловушка ложных метрик</h2> <p>Первая и фундаментальная ошибка — отсутствие целеполагания и, как следствие, измерение успеха не теми показателями. Сначала нужно определить цель внедрения ИИ в разработку, и уже она должна задавать метрики. Если цель —просто адаптация технологий и соответствие модным веяниям, тогда метрика — процент кода, написанного при помощи ИИ, и количество разработчиков, которые этим пользуются. Но такие метрики ничего не говорят об экономической эффективности и, скорее всего, порождают дополнительные расходы. Если метрика — time-to-market, то при подходе, когда разработчик лишь немного использует ИИ как ассистента, общий time-to-market не улучшается, потому что оптимизация происходит на уровне тех самых 30% написания кода. Даже если ускорить их на 20%, это даст около 6% общего выигрыша — эффект на уровне погрешности. Если речь про экономику, то есть про общую стоимость владения командой разработки, то при таком подходе она, будучи правильно посчитанной, не улучшится: <nobr>5-10%</nobr> эффективности разработчика будут покрыты стоимостью платформы, инфраструктуры, токенов, обучения и дополнительной команды, которая создалась сбоку, чтобы поддерживать разработчиков.</p> <p>Если же говорить о повышении качества кода и удовлетворенности клиентов, то прямой корреляции с использованием ИИ нет. Соответственно, при такой логике — как плагин к старым процессам или примочка к имеющемуся разработчику — эффект в основном получит сам разработчик: ему станет веселее, комфортнее, он получит новую компетенцию. Компания же в целом на своем SDLC-цикле не сможет наблюдать эффект на уровне общеорганизационных показателей.</p> <p>Фокус на активности, а не на результате создает искаженную реальность. У разработчика нет плана по сгенерированному коду — у него план по функциональности. Проблема не в том, что ИИ оставляет шаблонные артефакты как таковые. При внедрении ИИ как плагина к старым процессам эффективность на уровне индивида может вырасти, а пропускная способность команды — остаться прежней или даже упасть. Происходит это потому, что ИИ внедряется как плагин к старым процессам и не является значимым поводом их пересмотреть.</p> <h2>Провал контекста</h2> <p>Вторая причина — фундаментальный разрыв между универсальностью публичных языковых моделей и уникальным контекстом enterprise-разработки. Мощный ИИ, обученный на открытых репозиториях, прекрасно справляется с типовыми задачами и созданием готовых решений с нуля. Но интеграция ИИ в уже существующий ландшафт и имеющиеся процессы, где современные новые системы сочетаются с legacy-архитектурой, спроектированной и созданной <nobr>15-20</nobr> лет назад, крайне затратна.</p> <p>С учетом разнообразия систем и инструментария единообразно внедрить ИИ во все процессы разработки на всех языках и технологиях, которые использует компания, не получится: бэкенд — это один стек, фронтенд — другой, учет и бухгалтерия — третий. Условно пятипроцентный эффект в скорости будет заметен только там, где очень много людей работает на одной и той же технологии, в одном стеке, одной системе — когда их количество измеряется тысячами. Если же на монотехнологии сидят десятки или до сотен человек, достижимый эффект незначителен, а расходы на интеграцию в разные технологические стыки и их связь между собой огромны.</p> <p>Без тотальной перестройки процессов разработки и, возможно, перегенерации целых модулей и даже систем с нуля нужного эффекта не достичь. Это снова смена процесса: мы не даем айтишнику окошко с чатом, где он генерирует себе кусочки кода, а перестраиваем процесс целиком.</p> <h2>Теневая ИИ-экономика разработчиков: симптом системной проблемы</h2> <p>Парадоксально, но на фоне неудач корпоративных программ внедрения процветает теневая ИИ-экономика. Практически все разработчики сегодня в личном порядке используют ChatGPT, Copilot или аналоги для решения рутинных рабочих задач, например объяснения чужого кода, поиска ошибок или мозгового штурма. Со стороны руководства это часто воспринимается как угроза безопасности. И справедливо. Однако борьба с этим явлением запретами стратегически ведет в тупик.</p> <p>Стихийное использование ИИ — четкий сигнал о наличии спроса, который официальные корпоративные инструменты не удовлетворяют. Они оказываются недостаточно интегрированными в рабочий контур (тот же pipeline CI/CD), не адаптированными под внутренние практики или просто неудобными. Запрещая теневые инструменты, компания не решает проблему, а загоняет ее вглубь, теряя контроль над данными и упуская возможность направить энергию команды в управляемое русло. Это классический пример тактики страуса, которую мы уже проходили с облачными сервисами десять лет назад.</p> <h2>Стратегия прорыва</h2> <p>Чтобы изменить эту сомнительную практику, необходим переход от логики внедрения ИИ к логике инжиниринга процессов с ИИ. Это требует трех последовательных действий, основанных на принципе стратегического соучастия, а не запрета.</p> <p>Важно разделять два сценария. Первый — ИИ как персональный ассистент разработчика. Это дает локальный 5-10%-ный эффект, но не меняет систему. Второй — создание автономных ИИ-фабрик, где агенты последовательно проходят весь SDLC-цикл: от анализа требований до приемки. В этом случае меняется ролевая модель команды: люди становятся оркестраторами и архитекторами. Именно второй путь ведет к взрывному росту, но требует перестройки не кода, а процессов. Ниже шаги, которые работают в обоих сценариях.</p> <h3>Шаг 1. Легализация и безопасный канал</h3> <p>Важно сперва признать реальность и создать для разработчиков безопасную, контролируемую среду для экспериментов. Технически это реализуется через корпоративный «гибридный шлюз», единую точку входа для всех ИИ-запросов. Его задача заключается в интеллектуальной маршрутизации: публичные, некритичные запросы идут в одобренные внешние модели, а работа с чувствительным кодом, архитектурой или данными перенаправляется в изолированные, внутренние sandbox-среды. Это немедленно снимает остроту рисков ИБ и, что важнее, дает руководству беспрецедентную видимость того, какие задачи команды пытаются решить с помощью ИИ, где лежат их главные боли.</p> <h3>Шаг 2. Инвестиции в контекст, а не в генерацию</h3> <p>Вместо покупки лицензий на универсальные модели ресурсы должны направляться на создание специализированных ИИ-агентов, встроенных в жизненный цикл разработки. Речь о постепенном внедрении ИИ-агентов в SDLC-процессы — точечных помощников, обученных на вашей собственной кодовой базе, документации и истории, — с последовательным рефакторингом всего процесса SDLC и приучением разработчиков и инженеров к тому, что ИИ-агенты появляются на всех этапах жизненного цикла разработки программного обеспечения.</p> <p>Альтернативным вариантом может быть дизайн SDLC с нуля и постепенный перевод на него отдельных команд и технологий, наиболее пригодных и готовых к внедрению ИИ-агентов в разработку:</p> <ul> <li> Агент для анализа и рефакторинга legacy-кода, понимающий вашу специфику.</li> <li> Интеллектуальный ревьюер, знающий внутренние стандарты и типовые уязвимости домена.</li> <li> Контекстный помощник по архитектуре, способный предлагать решения в рамках утвержденных паттернов.</li> </ul> <p>Именно такие агенты дают измеримый эффект, сокращая время на анализ, снижая количество дефектов и повышая согласованность кода. Их ключевое свойство — обучаемость на основе обратной связи команды.</p> <h3>Шаг 3. Верификация системы измерений, исходя из целеполагания компании</h3> <p>Финансирование и оценка успеха должны быть жестко привязаны не к фиксированному набору метрик, а к целеполаганию компании.</p> <p>Сначала формулируется цель, под нее определяются метрики. Кто-то говорит: «Меня устраивает time-to-market, надо, чтобы все было так же, но дешевле». Кто-то готов тратить в два раза больше, но ускорить вывод продуктов в 10 раз, потому что по бизнесу это позволит зарабатывать гораздо больше и обгонять конкурентов. У кого-то ключевой критерий — трансформация командной разработки и ее реализация, и это считается самостоятельной ценностью; тогда параметры — объем использования и т. п. Поэтому эффективность ИИ должна доказываться влиянием на эти показатели, а не на объем сгенерированного текста.</p> <h2>Производительность как инженерная дисциплина</h2> <p>Миф о 40% развеивается простым, но неудобным выводом: производительность нельзя купить как коробочный продукт. Генеративный ИИ — не волшебная таблетка, а сложный и требовательный компонент, который работает только при перестройке процессов, инвестициях во внутренние компетенции и зрелой культуре данных. Взрывного роста не будет: настоящая эффективность — результат системной инженерной работы, а не единичного внедрения.</p> <p>Будущим технологическим лидерам предстоит не «внедрить ИИ в разработку», а перепроектировать сам процесс разработки, где ИИ становится одним из ключевых инженерных приемов. И здесь критически важно не совершить стратегическую ошибку — не отказаться от джуниоров в пользу ИИ. Молодые специалисты — это инвестиция в кадровый резерв. Их роль меняется: они учатся не столько писать шаблонный код, сколько управлять агентами и контролировать их работу. Трансформация SDLC не отменяет необходимости выращивать собственную экспертизу.</p> <p>Более того, молодые специалисты без большого опыта разработки и доработки систем быстрее схватывают саму идею генерации готовых систем и функциональных блоков с нуля. У них нет груза прежних привычек или он невелик, поэтому они легче принимают мысль, что готовые решения можно генерировать. Разумеется, речь не о больших бизнес-критичных системах. Но внутренняя автоматизация, порталы, борды и другие задачи, на которые раньше не хватало ресурсов или которые оставались недоинвестированными — например, красивый портал проектного управления, — сегодня могут решаться молодыми специалистами гораздо эффективнее. Опытному программисту, привыкшему много писать код, задача генерации внутренних готовых решений часто неинтересна, а молодежь уже создает работающие системы внутренней автоматизации и внутренней эффективности. Реальных примеров много, и поэтому недооценивать джунов в задачах внедрения ИИ в разработку нельзя.</p> <p>Путь к реальному росту производительности лежит не в покупке инструментов, а в соединении инженерной дисциплины, зрелых процессов и ставки на новое поколение специалистов.</p> <p>#IMAGE_235591#</p> Сегодня каждая вторая дорожная карта ИТ-директора содержит пункт о внедрении ИИ-инструментов для разработки. Ожидания … article Сергей Путятинский, эксперт по стратегии, операционной эффективности и технологическим инновациям https://www.itweek.ru/themes/detail.php?ID=235589 Mon, 21 Sep 2026 14:05:09 +0300 <p>«Яндекс» выложил в опенсорс Alice AI Foundation LLM — претрейн-версию своей новой большой языковой модели, обученной полностью с нуля. Модель показывает высокие результаты в программировании и способности к рассуждениям, а по качеству ответов на русском языке превосходит многие мировые аналоги — особенно в задачах на знание фактов, интересных русскоязычной аудитории. Она обгоняет в том числе более крупные опенсорс-модели, не требуя при этом больших вычислительных мощностей для инференса. Разработчики могут использовать её как в исследовательских, так и в коммерческих проектах благодаря свободной лицензии Apache 2.0.</p> <p>Новая модель — это экспериментальная версия, на которой Яндекс тестирует архитектурные решения для своей будущей единой рассуждающей модели (ЕРМ). Рассуждающая модель ляжет в основу агентных возможностей Алисы AI, благодаря которым пользователи смогут поручать ей выполнение конкретных действий. </p> <p>Alice AI Foundation LLM работает на архитектуре MoE (Mixture of Experts) и включает 80 миллиардов параметров, из которых в моменте активны только 3 миллиарда — это обеспечивает исключительную скорость и экономичность её работы.</p> <p>В модель заложены способности к рассуждению и работе в агентных сценариях. За счёт этого она показывает высокую эффективность в сложных логических заданиях и в программировании. Например, на олимпиадных задачах по математике она делит лидерство с Qwen3.5-35B-A3B-Base, решая подавляющее большинство заданий. А в тестах на написание кода превосходит модель компании NVIDIA Nemotron-3-Super-120B-Base — несмотря на то, что использует в четыре раза меньше активных параметров. Качество в ризонинге и программировании — необходимый навык для эффективной работы агентов, способных выполнять действия по поручению пользователя.</p> <p>При компактном размере и меньшей требовательности к вычислительным мощностям новая модель обходит на задачах, где нужны широкие фактические знания, и более крупные открытые модели — например, DeepSeek-V4-Flash-Base с 284 млрд параметров и 13 млрд активных. Бенчмарки для оценки знания фактов показывают, что новая модель отвечает на уровне предыдущей закрытой модели Яндекса Alice AI LLM, у которой в три раза больше параметров и в семь раз больше активных. </p> <p>Для оценки знаний модели, актуальных для русскоязычных пользователей, Яндекс разработал два собственных бенчмарка — WikiWebFacts и HardMultiQA. Первый состоит из пар «короткий вопрос — короткий ответ» и проверяет знание дат, определений, событий и персоналий на основе материалов онлайн-энциклопедий и частотных агрегированных поисковых запросов. Второй, HardMultiQA, построен на основе анонимизированного потока запросов к Алисе AI и охватывает более редкие области знаний: от медицины и права до IT и искусства. В этих задачах недостаточно вспомнить один факт: модель должна выбрать несколько верных вариантов из списка, перечислить сразу несколько фактов, подходящих под условие вопроса, или найти фактическую ошибку в тексте.</p> <p>Новые бенчмарки создавались для оценки русскоязычных знаний модели, так как англоязычные бенчмарки не позволяют оценить их объективно. Оба бенчмарка компания выложила в открытый доступ вместе с моделью, чтобы разработчики и исследователи могли сами воспроизвести результаты и сравнивать между собой любые модели. Вместе с наборами задач компания публикует эталонные ответы и полный протокол оценки.</p> <p>При обучении модели разработчики Яндекса улучшили работу оптимизатора — программы, управляющей процессом обучения. Они перестроили его так, чтобы пересылка данных между видеокартами шла параллельно с вычислениями. Это позволило ускорить шаги оптимизации примерно в два раза.</p> <p>Яндекс также оптимизировал подготовку качественных обучающих данных — для их отбора требовалось оценивать документы с помощью ресурсоёмкой модели. Её запуск на всём корпусе потребовал бы более 200 тысяч часов работы видеокарт. Теперь перед такой оценкой документы проходят через каскад классификаторов. На каждом этапе более сложная и вычислительно затратная модель работает с меньшим количеством документов. Это позволило в десятки раз сократить количество вычислений и при этом сохранить около 95% полезных документов. Кроме того, инженеры значительно обогатили базу знаний модели в области права, медицины и математики. </p> <p>Новая модель предоставляется под лицензией Apache 2.0, что позволяет свободно использовать её в коммерческих и исследовательских целях. Она уже прошла основной этап обучения, от которого зависят ее эрудированность, способности и потенциал. Это позволяет использовать её как основу для создания собственных проектов. </p> «Яндекс» выложил в опенсорс Alice AI Foundation LLM — претрейн-версию своей новой большой языковой модели … message https://www.itweek.ru/themes/detail.php?ID=235588 Mon, 21 Sep 2026 14:03:41 +0300 <p>Портфель российских ИБП Сайбер Электро расширился за счет нового направления оборудования для критической инфраструктуры. Под торговым знаком CyberData бренд представляет специализированные решения для ЦОД. Первой серией новой линейки стала CyberData Prime — трехфазные модульные источники бесперебойного питания с двойным преобразованием энергии мощностью 600, 800 и 1000 кВА.</p> <p>CyberData Prime предназначена для дата-центров, где надежность электроснабжения напрямую влияет на непрерывность работы ИТ-систем и инженерной инфраструктуры. Серия рассчитана на применение на объектах с высокой концентрацией критических нагрузок и повышенными требованиями к отказоустойчивости энергоснабжения.</p> <p>Модульная архитектура позволяет масштабировать систему в соответствии с требованиями объекта и создавать резервированные конфигурации. ИБП поддерживают параллельную работу до восьми устройств и построение систем по схеме N+1, что позволяет повысить надежность электроснабжения при сохранении возможности дальнейшего наращивания мощности.</p> <p>Оборудование поддерживает совместную работу с дизель-генераторными установками, в том числе благодаря алгоритму плавного увеличения входной мощности, снижающему нагрузку на генератор при подключении ИБП. Несколько ИБП могут работать от общего аккумуляторного массива.</p> <p>Серия включает модели CDP-600-K, CDP-800-K и CDP-1000-K, ИБП строятся на модулях номинальной мощностью от 100 кВА. Среди ключевых характеристик — выходной коэффициент мощности 1,0, КПД до 96% и THDi ≤3% при 100% линейной нагрузке.</p> <p>Запуск CyberData Prime становится первым этапом формирования специализированного направления Сайбер Электро для дата-центров.</p> <p>Развитие направления оборудования для ЦОД — стратегический шаг в расширении продуктового портфеля Сайбер Электро. Новый торговый знак объединит решения, рассчитанные на объекты с повышенными требованиями к надежности, масштабируемости и качеству электроснабжения. В дальнейшем под брендом CyberData планируется представить и другие категории оборудования для инфраструктуры дата-центров.</p> <p>Выделение специализированного направления призвано в том числе упростить работу партнеров с продуктовым портфелем. CyberData позволит быстрее ориентироваться в решениях Сайбер Электро, предназначенных именно для ЦОД и других объектов критической инфраструктуры, и формировать на их основе комплексные предложения для заказчиков.</p> <p>«Появление CyberData — это следующий этап развития портфеля Сайбер Электро. Мы видим потребность рынка в специализированных решениях для дата-центров и последовательно расширяем предложение в этом сегменте. Для партнеров важно не только наличие необходимого оборудования, но и понятная структура портфеля, поэтому решения для критической инфраструктуры будут объединены под отдельным торговым знаком», — прокомментировала директор по маркетингу Татьяна Проворова.</p> Портфель российских ИБП Сайбер Электро расширился за счет нового направления оборудования для критической инфраструктуры … message https://www.itweek.ru/themes/detail.php?ID=235587 Mon, 21 Sep 2026 10:21:27 +0300 <p><em>Искусственный интеллект не переписывает правила кибербезопасности — он значительно усиливает привычные атаки. Эдер Рибейро, директор по реагированию на инциденты компании TransUnion, объясняет на портале </em><em>InformationWeek</em><em>, какие угрозы, связанные с ИИ, заслуживают внимания и какие риски по-прежнему доминируют в сфере реагирования на инциденты.</em></p> <p>С учетом того, что ИИ доминирует в заголовках новостей о кибербезопасности (и большинстве других областей), кажется, что он переписал ландшафт угроз. Дипфейки, инъекции промптов, атаки на большие языковые модели и автономные взломы с использованием ИИ говорят о том, что мы, возможно, переживаем важный переломный момент в кибербезопасности.</p> <p>Некоторые из этих угроз реальны, особенно для организаций, активно использующих агентов ИИ. Но этот нарратив часто затмевает более важную реальность: самые большие угрозы, с которыми сталкивается большинство предприятий, исходят не от злоумышленников, взламывающих защиту с помощью новых атак на основе ИИ. Судя по тому, что я вижу в области глобального реагирования на киберинциденты, успешные атаки по-прежнему основаны на знакомых, проверенных тактиках.</p> <p>Наиболее эффективными инструментами в арсенале злоумышленников остаются фишинг, кража учетных данных, выдача себя за другое лицо и социальная инженерия. Отличие заключается в том, что ИИ помогает осуществлять эти атаки быстрее, в бóльших масштабах и с таким уровнем мастерства, которого раньше было сложнее достичь.</p> <p>Понимание разницы между преувеличенными рисками ИИ и угрозами, с которыми команды безопасности сталкиваются каждый день, имеет решающее значение для практического подхода к кибербезопасности.</p> <h3>Отделение реальности от шумихи вокруг ИИ</h3> <p>Несмотря на опасения, что ИИ устранит технические барьеры для киберпреступности, успешные атаки по-прежнему требуют значительных экспертных знаний. Возьмем, например, широко обсуждаемые атаки с инъекцией промптов. Эти атаки включают в себя манипулирование системой ИИ для раскрытия информации или использование вредоносных промптов, чтобы заставить ее выполнять действия, которые она не должна выполнять. Хотя исследователи безопасности продемонстрировали успешные подобные атаки — и организации, внедряющие инструменты ИИ, должны понимать и защищаться от таких рисков — такие атаки не так просты и легки, как может показаться.</p> <p>Манипулирование корпоративными системами ИИ, которые использует большинство организаций, требует времени, доступа к целевой среде и технического уровня, которыми многие злоумышленники не обладают. Организации, применяющие зрелые передовые модели ИИ, получают выгоду от существенных встроенных средств контроля безопасности, предназначенных для ограничения злоупотреблений.</p> <p>Недавние события, такие как июльский инцидент безопасности, связанный с оценочными моделями OpenAI и Hugging Face, демонстрируют, что продвинутые атаки с использованием ИИ не являются чисто теоретическими. Однако сегодня они остаются исключением.</p> <p>Организациям следует бороться с инъекцией промптов без отвлечения внимания от уязвимостей в системе идентификации и доступа, лежащих в основе большинства успешных инцидентов.</p> <h3>Те же угрозы, но усиленные</h3> <p>Новые методы атак с использованием ИИ, такие как инъекция промптов, привлекают внимание, потому что они новые и тревожные. По сравнению с ними программы-вымогатели кажутся чем-то из прошлого. Тем не менее, несмотря на более чем 15 лет борьбы с ними, программы-вымогатели остаются одной из самых разрушительных и дорогостоящих киберугроз, с которыми сталкиваются организации.</p> <p>Малые и средние предприятия остаются частыми целями программ-вымогателей, потому что их режимы резервного копирования данных часто менее частые или менее тщательные. Хотя некоторые злоумышленники могут хвастаться использованием ИИ — часто в качестве психологической тактики — основные методы эффективных атак с использованием программ-вымогателей хорошо известны: фишинг, кража учетных данных или социальная инженерия, сбор учетных данных, латеральное перемещение и запуск вредоносного ПО.</p> <p>Программы-вымогатели могут считаться чем-то устаревшим, но их атаки по-прежнему наносят ущерб организациям.</p> <p>Аналогично, по-прежнему распространена компрометация корпоративной электронной почты. Доступные инструменты, такие как фишинговые наборы, позволяют даже начинающим злоумышленникам присылать убедительные фишинговые письма, которые направляют получателей на поддельные страницы входа, предназначенные для кражи учетных данных. Оказавшись внутри, они могут отслеживать активность, ожидая подходящего момента для перехвата управления и получения выгоды.</p> <p>ИИ доказал свою исключительную ценность как инструмент для ускорения, масштабирования и значительного повышения убедительности традиционных атак.</p> <h3>Где ИИ создает реальные широкомасштабные проблемы</h3> <p>Если и есть область, где ИИ явно меняет ландшафт угроз, то это социальная инженерия. Человеческий фактор остается одной из наиболее уязвимых аспектов системы безопасности организации.</p> <p>ИИ способен создавать практически нераспознаваемые фишинговые электронные письма и мошеннические веб-сайты. Агенты ИИ могут генерировать реалистичные поддельные документы и персонализированные сообщения с минимальными усилиями, позволяя злоумышленникам быстро адаптировать сообщения для конкретных отраслей или целей. Если злоумышленники уже взломали систему электронной почты, они будут знать, когда отправить идеально рассчитанный мошеннический запрос на оплату.</p> <p>Технология дипфейков еще больше расширила эти возможности, поскольку сообщения, которые выглядят и звучат аутентично, убедительно имитируют руководителей, сотрудников и деловых партнеров.</p> <p>Организациям следует развивать свои программы повышения осведомленности, выходя за рамки традиционных тревожных сигналов, таких как подозрительный язык или несоответствие доменов отправителей. Им необходимо следовать установленным процедурам утверждения, особенно для финансовых транзакций.</p> <h3>Угроза ИИ не ограничивается атакой</h3> <p>Еще одна возникающая проблема — это роль, которую ИИ играет после того, как злоумышленник получает легитимный доступ к сети, часто с помощью украденных учетных данных. Все чаще корпоративные агенты ИИ предоставляют злоумышленникам потенциальный путь к системам знаний, которые агрегируют информацию по всей организации.</p> <p>Злоумышленники, использующие доверенных ИИ-агентов («<strong>Living‑off‑the‑Agent», LoTA)</strong>, могут взаимодействовать с агентами корпоративной платформы ИИ в качестве авторизованного пользователя, задавая вопросы и находя конфиденциальные данные. Такие атаки особенно сложны, поскольку их действия часто неотличимы от легитимного поведения пользователя. Злоумышленник не использует уязвимость в платформе ИИ; он использует уже имеющийся доступ.</p> <h3>Риски, связанные с использованием ИИ сотрудниками</h3> <p>Наконец, особую обеспокоенность вызывает несанкционированное использование ИИ сотрудниками. В этом году 63% из 2000 респондентов <a href="https://www.blackfog.com/blackfog-research-shadow-ai-threat-grows/">опроса</a> BlackFog о теневом ИИ сообщили, что считают допустимым использование инструментов ИИ без одобрения работодателя, если нет санкционированного компанией варианта, при этом 58% используют менее безопасные бесплатные версии.</p> <p>Проблема в том, что организации не могут контролировать инструменты ИИ, о которых они не знают.</p> <p>Когда сотрудники вводят конфиденциальную внутреннюю информацию или бизнес-данные в несанкционированные платформы ИИ, они непреднамеренно создают новые точки уязвимости. Из-за широкого распространения теневой ИИ представляет собой более непосредственный и практический риск, чем любая сложная эксплойт-атака на основе ИИ.</p> <p>Четкое определение политики использования ИИ сотрудниками и поддержание видимости ИИ в масштабах всей организации должны быть частью любой стратегии управления ИИ.</p> <h3>Сосредоточьтесь на том, что действительно важно</h3> <p>ИИ трансформирует ландшафт кибербезопасности. Но для большинства организаций наибольшие риски не связаны с тем, что привлекает внимание руководителей или попадает в заголовки отраслевых новостей.</p> <p>Большинство успешных инцидентов по-прежнему начинаются с компрометации личных данных, фишинговых кампаний, слабого контроля доступа и человеческой ошибки.</p> <p>Организации по-прежнему могут повысить свою устойчивость, укрепляя безопасность идентификационных данных, внедряя надежную многофакторную аутентификацию, повышая устойчивость к фишингу и осознанно подходя к развертыванию ИИ. Будущее кибербезопасности будет связано с ИИ, но устранение рисков, которые злоумышленники используют сегодня, остается основой надежной стратегии безопасности.</p> Искусственный интеллект не переписывает правила кибербезопасности — он значительно усиливает привычные атаки. Эдер … article https://www.itweek.ru/themes/detail.php?ID=235585 Mon, 21 Sep 2026 10:09:58 +0300 <p><em>Рассмотрим пять элементов расчета, без которых ROI ИИ остается догадкой.</em></p> <p>Компания, которая покупает новый станок, считает срок его окупаемости до подписания контракта. Она знает стоимость станка, сколько единиц продукции он даст в месяц и через сколько месяцев вложение вернется. Компания, которая нанимает сотрудника, считает его стоимость в год и ожидаемый вклад в выручку заранее, до оффера. С ИИ так происходит редко. Решение принимается по демонстрации, по обещанию прироста производительности, по примеру конкурента, и уже потом, через год, кто-то пытается понять, окупилось это или нет.</p> <p>Инвестиция в ИИ отличается от инвестиции в станок по своей природе: станок не меняет поведение после установки, а модель дрейфует и требует переобучения. Но требования к расчету окупаемости у них должны быть одинаковыми. Дисциплина расчета, которую применяют к активу, определяет результат сильнее, чем сам актив. Если применить к ИИ ту же процедуру, что и к любому капитальному вложению, часть решений о внедрении просто не пройдет. Это тоже правильный результат.</p> <p>Расчет начинается с базовой операции. Нужно зафиксировать состояние процесса до внедрения: какой именно процесс меняется, в каких единицах измеряется его выпуск, сколько он стоит компании сейчас. Без этой точки отсчета любой процент прироста после внедрения превращается в цифру, которую невозможно проверить. Компания может отчитаться о росте производительности на треть, но если никто не зафиксировал производительность до старта, эта треть взята из воздуха.</p> <p>Дальше идет стоимость внедрения. Ее часто считают неверно, если путают два разных вида затрат. Капитальные затраты включают интеграцию, настройку процессов и обучение команды. Операционные затраты включают лицензии, вычислительные мощности и сопровождение. Горизонт возврата у них разный. Компании часто принимают стоимость пилота за ориентир для всего портфеля процессов, и это ошибка. Пилот на одной команде почти всегда дешевле на человека, чем тиражирование на пятьдесят команд, потому что поддержка, лицензирование и обучение растут не пропорционально числу пользователей.</p> <p>Срок эффекта редко считают верно. Именно этот показатель чаще всего подделывают ради красивого ROI: по моему опыту, инвестиционному комитету показывают цифры адаптационного периода вместо стационарного, потому что они выглядят эффектнее в презентации. У периода внедрения и стационарного периода разная экономика. В период внедрения производительность может даже просесть: команда осваивает инструмент, перестраивает привычные операции, тратит время на ошибки. Устойчивый эффект появляется позже, в стационарном периоде, когда практика уже закреплена. Именно он и имеет экономический смысл.</p> <p>У рисков простое правило: прирост засчитывается, только если качество не ухудшилось против базового уровня. Ускорение процесса ценой роста ошибок, возвратов в работу или потери контроля просто переносит издержки на более поздний срок. Отдельная опасность: пилот без развилки живет годами и не дает компании ничего, кроме привычки к пилоту. У любого пилота должен быть срок, после которого принимается одно из двух решений: масштабировать или закрыть.</p> <p>Масштабирование почти никогда не работает по прямой: предел эффективности у каждого процесса определяют именно его слабые места. Плохие данные в одной команде тормозят автоматизацию раньше, чем возможности модели. В другой команде тормозит сопротивление людей новому порядку работы, и эффект теряется на этапе внедрения раньше, чем дело доходит до модели. В третьей команде объем операций в разы меньше, чем у пилотной группы, и фиксированная часть затрат просто съедает большую долю эффекта. Если просто перенести цифры одного успешного пилота на весь портфель без поправки на эти различия, результат окажется завышен заранее.</p> <p>Приведу условный пример: пилот по автоматической сверке первичных документов в закупках дал заметное ускорение обработки заявок, но одновременно вырос процент ручных исправлений после автосверки, и по факту чистого эффекта не набралось. Не раз останавливал похожие ИИ-пилоты, которые всем нравились, но не проходили этот расчет. И наоборот, доводил до масштабирования на портфель инициативы, где результат на пилоте выглядел скромно, а расчет на стационарном периоде показывал устойчивый эффект.</p> <p>Свести все элементы вместе должен тот же орган, который утверждает любую капитальную инвестицию: инвестиционный комитет или его аналог. У него уже есть форма для станка и форма для найма команды. У капитальной инвестиции есть еще один элемент, который для ИИ обычно выпадает: план-факт контроль после сделки и ответственность за отклонение. Если через год факт разошелся с расчетом, который лег в основу решения, кто-то должен объяснить разрыв на том же комитете, где утверждали инвестицию, вместо того чтобы тихо закрыть проект новой инициативой. Без этой части весь расчет до сделки превращается в красивую формальность.</p> <p>#IMAGE_235586#</p> Рассмотрим пять элементов расчета, без которых ROI ИИ остается догадкой. Компания, которая покупает новый станок, считает … article Станислав Ежов, директор по развитию ИИ, ПАО “Группа Астра” https://www.itweek.ru/themes/detail.php?ID=235580 Fri, 18 Sep 2026 14:05:12 +0300 <p>Компания «Флант» объявила о крупнейшем обновлении продуктовой линейки: Deckhouse Kubernetes Platform, Deckhouse Virtualization Platform и Deckhouse Commander объединены в единый продукт — Deckhouse Platform. Новая платформа предназначена для построения гибридной инфраструктуры и единого управления любыми нагрузками — контейнерами, виртуальными машинами, ИИ-сервисами и данными — на любом сочетании облачных и локальных ресурсов.</p> <p>Deckhouse Kubernetes Platform (DKP) известна рынку с 2017 года, однако за это время она перестала быть платформой только для контейнеров. Вопреки ожиданиям начала <nobr>2020-х,</nobr> контейнеризация не вытеснила виртуализацию — обе технологии остались в production-ландшафтах, и управление ими из одного оркестратора превратилось из эксперимента в отраслевой стандарт. Именно это определило вектор развития: DKP выросла в продукт нового поколения, рассчитанный на гибридные ландшафты, где контейнеры, виртуальные машины, ИИ-сервисы и данные управляются из одной точки. </p> <p>Deckhouse Platform — это принципиально новый продукт, объединивший три самостоятельных решения: платформу для контейнеров, платформу для виртуализации и систему управления мультикластерной инфраструктурой. Единый control plane, общая система безопасности и наблюдаемости — формула нового продукта: «Любые нагрузки. Любая инфраструктура. Одна платформа».</p> <p>«Современные компании вынуждены постоянно выбирать: виртуальные машины или контейнеры, облако или on-prem, Open Source или готовая платформа, Infrastructure as Code или ИИ, скорость или безопасность, — и каждый такой компромисс стоит времени и денег. Нам в Deckhouse удалось объединить виртуальные машины и контейнеры, облака и on-prem, инфраструктуру как код и ИИ-агентов, а также управляемые сервисы, сети и storage, обеспечив стандартизацию, безопасность, надёжность и очень большую гибкость, а значит — дать компаниям возможность развиваться быстрее и быть первыми», — подчеркнул Давид Мэгтон, технический директор и соучредитель компании «Флант».</p> <p>Платформа предлагает семь готовых сценариев использования, которые охватывают основные задачи современных технологических ландшафтов.</p> <p>Первые три сценария закрывают базовые потребности в вычислительной инфраструктуре. Для контейнеров — кластер за считаные минуты, а не месяцы, SLA выше 99,99 % и встроенное соответствие требованиям регуляторов. Для виртуализации — простое управление ВМ-инфраструктурой и миграция с зарубежных продуктов, включая сертификацию ФСТЭК России. Для комбинированных нагрузок — контейнеры и виртуальные машины под одним control plane с единым пакетом документов ФСТЭК России на всю среду.</p> <p>Следующие сценарии расширяют платформу на работу с данными, ИИ и облачными моделями потребления. Для ИИ — GPU как ещё один ресурс в общем пуле рядом с CPU и памятью, запуск ИИ-сервиса за часы, а не кварталы, данные внутри контура компании и до 30 % экономии на оборудовании за счёт оптимизации GPU. Для данных — единый слой хранения, интеграция с внешними СХД и управляемые сервисы по запросу: PostgreSQL, ClickHouse, Airflow, брокеры сообщений, кеши. Для частного облака — ресурсы по кнопке, а не по тикету и прозрачная экономика по проектам и продуктам: квоты, потребление, стоимость.</p> <p>Наконец, Deckhouse Platform для распределённой гибридной инфраструктуры, усиленная ИИ, собирает весь ландшафт — собственный ЦОД, арендованную площадку, публичное облако, edge — в одну систему с единым control plane на все площадки для создания ресурсов, поиска аномалий и устранения ошибок.</p> <p>Все семь решений формируются из ядра Deckhouse Platform Core — минимальной неделимой основы для запуска контейнеров и виртуальных машин — и 14 совместимых расширений: по работе с данными, управлению гибридной инфраструктурой, информационной безопасностью, сетевыми возможностями и ресурсами ML/AI. Заказчик покупает только то, что нужно сейчас, и расширяет платформу по мере роста — вместо нескольких стеков и команд на ВМ и контейнеры компания получает одну ответственность вендора и единый SLA на весь контур.</p> <p>Deckhouse Platform сохраняет приверженность открытому коду — пользователям доступна бесплатная редакция Deckhouse Platform Open для самостоятельного развёртывания. Сегодня инженеры «Фланта» занимают первое место в России по объёму контрибуций в международные проекты CNCF.</p> <p>«Любая бизнес-задача живёт в условиях ограничений — времени, ресурсов, денег, масштаба. Крупное технологическое обновление в первую очередь о том, что теперь можно решать задачу иначе, выходить из этих ограничений. В Deckhouse Platform функциональность накапливается от обновления к обновлению — за прошлый год вышло больше 10 версий платформы, и компании могут использовать новые функции и сценарии, сохраняя уже сделанные инвестиции, при этом обновление будет бесшовным. Это модель непрерывного накопления ценности: без лишних затрат на пересборку среды, с управляемым и прозрачным TCO», — отметил Александр Титов, генеральный директор компании «Флант».</p> <p>Помимо Deckhouse Platform, компания развивает линейку совместимых продуктов. Deckhouse Observability обеспечивает централизованную наблюдаемость всей инфраструктуры и приложений, Deckhouse Development Portal позволяет управлять всеми этапами разработки новых сервисов и продуктов, Deckhouse Stronghold отвечает за безопасное управление жизненным циклом секретов, а Deckhouse Code — за непрерывную разработку и управление жизненным циклом ПО. Все продукты интегрированы между собой и с платформой — не нужно тестировать совместимость и тратить ресурсы на подключение сторонних решений.</p> <p>«Многие сталкивались с ситуацией, когда команда разработки создаёт цифровой продукт за пару месяцев, а клиенты получают к нему доступ лишь спустя год. Эту разницу во времени съедает инфраструктура: долгие согласования, ручная настройка кластеров и бесконечные обновления. За это время конкуренты успевают занять рынок. Deckhouse Platform возвращает это время: кластер поднимается за считаные минуты, а команды могут выпускать релизы в день написания кода. Платформа берёт на себя автоматическое масштабирование под любые пики нагрузки, обеспечивает SLA выше 99,99 % и уже „из коробки“ закрывает все ключевые требования регуляторов и информационной безопасности», — считает Карапет Манасян, директор продуктовых направлений Deckhouse, «Флант».</p> <p>Дорожная карта развития Deckhouse Platform включает развитие маркетплейса приложений с установкой в один клик, новые управляемые сервисы для хранения и обработки данных, углубление ИИ в процессы — от развёртывания инфраструктуры до создания модулей — развитие системы хранения с гибридным размещением и автоматическим распределением данных между уровнями, а также сертификацию ФСТЭК России для новых возможностей платформы.</p> <p>Сегодня под управлением платформы находится более 1300 кластеров, которые эксплуатируют свыше 260 компаний. Кластер Kubernetes поднимается в среднем за 15 минут, время вывода продукта на рынок сокращается на 23 %, а TCO за пять лет оказывается ниже на 27 % по сравнению с самостоятельно собранной платформой. На опыте реальных внедрений подтверждено, что двух инженеров достаточно для обслуживания 170+ кластеров и 1000+ виртуальных машин. Продукт имеет сертификат ФСТЭК России № 4860 от 04.10.2024 и запись в реестре российского ПО № 12338. Платформу уже эксплуатируют такие компании, как «Газпром нефть», «Лемана ПРО», ОТП Банк, «ЭР-Телеком Холдинг», «Альфа-Лизинг», Mindbox, а также Казначейство России, Банк России, ФГБУ «Росгеолфонд».</p> Компания «Флант» объявила о крупнейшем обновлении продуктовой линейки: Deckhouse Kubernetes Platform, Deckhouse … message https://www.itweek.ru/themes/detail.php?ID=235579 Fri, 18 Sep 2026 14:02:50 +0300 <p>Компания «Лаборатория Виртуализации» выпустила версию 3.0.0 платформы Inscale — российского решения для серверной виртуализации и инфраструктуры виртуальных рабочих столов (VDI). Релиз развивает платформу в трёх направлениях: централизованное управление доступом, эксплуатация распределённой инфраструктуры и качество пользовательских сессий. Продукт включён в Единый реестр российских программ Минцифры (запись № 28671).</p> <p>Главное изменение версии — новая модель распределения ресурсов на основе групп доставки (Delivery Groups). Раньше права и параметры назначались на уровне отдельных пользователей и пулов, и с ростом инфраструктуры конфигурацию становилось сложнее сопровождать и проверять. Теперь группа доставки объединяет в одной точке пользователей, доступные им рабочие столы и пулы, политики безопасности и профили подключения. При назначении пользователю рабочего стола или пула нужные параметры применяются автоматически.</p> <p>Расширена интеграция с каталогами Active Directory и LDAP: администратор может задавать дополнительные атрибуты поиска — например, табельный номер или адрес электронной почты — и назначать права доступа к VDI заранее, до появления учётной записи в системе. После синхронизации каталога назначения применяются автоматически, что сокращает ручные операции при подключении новых сотрудников. Добавлена блокировка локальных учётных записей без их удаления — для временной приостановки доступа или реагирования на инцидент.</p> <p>Для эксплуатации появилась единая панель мониторинга со сводными данными по кластерам в реальном времени. Через систему управления теперь можно удалённо перезапускать сервисы платформы, получать их журналы и автоматически собирать диагностические данные для технической поддержки. Групповые операции позволяют за одно действие изменить уровень журналирования на всех узлах кластера.</p> <p>В настройках виртуальных машин стал доступен выбор шины и типа виртуального диска, а шифрование дисков при создании образа сделано опциональным — для инфраструктур, где данные уже защищены на уровне системы хранения. Обновлён клиент подключения: пользователь видит понятные индикаторы состояния сессии при потере сети и повторном подключении. Улучшены алгоритмы сжатия протокола доставки рабочего стола, повышена надёжность работы с хранилищами по iSCSI и обработка недоступных шлюзов в профилях подключения.</p> <p>Отдельный блок релиза посвящён отказоустойчивости: устранены проблемы с неактивными участниками во внутренних кластерах баз данных, автоматическая очистка хранилища продолжает работать при недоступности одного из серверов кластера, статус виртуальной машины после принудительного выключения обновляется сразу.</p> Компания «Лаборатория Виртуализации» выпустила версию 3.0.0 платформы Inscale — российского решения для серверной … message https://www.itweek.ru/themes/detail.php?ID=235578 Fri, 18 Sep 2026 14:01:04 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) представила обновленную конфигурацию ИИ-сервера G4208P G3 для корпоративных проектов. Новая версия поддерживает до восьми GPU мощностью до 600 Вт каждый и вдвое увеличивает плотность вычислений. Сервер рассчитан на ресурсоемкие задачи обучения, дообучения и инференса современных ИИ-моделей.</p> <p>Рост производительности современных GPU повышает требования ко всей серверной платформе и условиям ее эксплуатации. В обновленном G4208P G3 усилены подсистемы питания и охлаждения, благодаря чему полная конфигурация может работать при температуре входящего воздуха до 30 °C. Для заказчиков это расширяет возможности размещения ИИ-оборудования в существующей инфраструктуре ЦОД и снижает объем дополнительных требований к подготовке площадки. </p> <p>G4208P G3 поддерживает ускорители разных классов и производителей. Конфигурацию можно подбирать с учетом модели, программного стека, профиля нагрузки и бюджета проекта. Одна платформа подходит для разных ИИ-сценариев и позволяет наращивать вычислительные ресурсы по мере роста нагрузки. </p> <p>YADRO также проводит прикладные исследования и тестирование на реальных ИИ-нагрузках, публикуя результаты измерений с описанием конфигураций, методик и условий тестирования. Заказчики могут заранее сравнивать варианты по производительности, задержкам и стоимости вычислений и быстрее переходить к проверке конфигурации на своей нагрузке. </p> <p>«Корпоративные ИИ-проекты становятся масштабнее, и вместе с ними растут требования к вычислительной инфраструктуре. При развитии G4208P G3 мы ориентировались на реальные условия эксплуатации в ЦОД, возможность выбирать конфигурацию под конкретную нагрузку и дальнейшее масштабирование инфраструктуры по мере роста задач», — отметил Михаил Михеев, директор по серверным продуктам YADRO.</p> <p>Обновленная конфигурация расширяет возможности компаний по развитию собственной ИИ-инфраструктуры — от отдельных вычислительных узлов до GPU-кластеров.</p> Технологическая компания YADRO (входит в ИКС Холдинг) представила обновленную конфигурацию ИИ-сервера G4208P G3 для … message https://www.itweek.ru/themes/detail.php?ID=235577 Fri, 18 Sep 2026 13:56:43 +0300 <p>Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, обновила Avanpost SmartPAM, продукт для управления привилегированным доступном, до версии 1.4. В новой версии добавлена библиотека из 60 сигнатур, структурированных по категориям матрицы техник атак MITRE ATT&CK для обнаружения и реакции на угрозы внутри привилегированных сессий. Библиотека доступна заказчикам по подписке и будет регулярно пополняться. До конца 2026 года подписка на библиотеку бесплатна.</p> <p>«Обновление поддерживает выбранный Avanpost вектор развития SmartPAM: от защиты доступа к непрерывному и многоуровневому анализу действий привилегированных пользователей, выявлению и своевременному реагированию на угрозы. При росте масштабов компрометации учетных данных, инсайдерских рисков, человеческих ошибок недостаточно лишь контроля входа и фиксации действий. Объектом контроля становится не только идентичность, но и каждое действие, совершаемое с ее полномочиями», — отметил Сергей Померанцев, владелец продукта Avanpost SmartPAM. </p> <p>Avanpost SmartPAM стала первой PAM-системой с библиотекой сигнатур по матрице MITRE ATT&CK. Сигнатура — это правило или совокупность правил, которые позволяют PAM-системе идентифицировать известную угрозу. Готовые сигнатуры используются движком сигнатурного анализа Avanpost SmartPAM. Он обрабатывает, нормализует и анализирует события привилегированной сессии и при необходимости формирует ответную реакцию: блокировку команды или пользователя, разрыв сессии, отправку уведомления в SIEM и тд. </p> <p>Библиотека сигнатур по матрице MITRE ATT&CK охватывает разные тактики и техники атак, включая получение учетных данных, закрепление в системе, горизонтальное перемещение, уклонение от обнаружения и другие. В частности, новые сигнатуры идентифицируют отключение служб аудита операционной системы, антивирусной защиты или межсетевого экрана , очистку системных журналов, маскирование команд. Компании могут сочетать готовые сигнатуры с собственными правилами и настраивать политики безопасности с учетом своих ИБ-приоритетов и особенностей инфраструктуры.</p> Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, обновила Avanpost … message https://www.itweek.ru/themes/detail.php?ID=235576 Fri, 18 Sep 2026 10:48:39 +0300 <p><em>Искусственный интеллект уже работает в вашем бизнесе — зачастую незаметно. Прежде чем вы сможете им управлять, вам нужно увидеть, где он работает. Видимость — на первом месте, пишет на портале </em><em>InformationWeek</em> <em>Дуг Пикл, президент Global Data Systems.</em></p> <p>Я провожу много времени в залах, полных генеральных директоров, и мне нравится задавать простой вопрос: «Работает ли ИИ внутри вашей организации?» Почти все поднимают руки.</p> <p>Затем я задаю следующий вопрос: «Где?» И в зале воцаряется тишина.</p> <p>Этот разрыв между знанием о наличии ИИ и знанием о том, где он работает, — одна из самых дорогостоящих слепых зон, которые я вижу в современном бизнесе.</p> <p>Большинство руководящих команд считают, что разговор об ИИ начинается и заканчивается инструментами, которые их сотрудники сознательно внедрили: ChatGPT, открытый во вкладке браузера, пилотный проект Copilot для одной команды. Реальная уязвимость редко проявляется именно там. Реальный риск исходит от скрытого ИИ — систем, уже встроенных в вашу инфраструктуру.</p> <p>ИИ уже интегрирован в инфраструктуру, платформы повышения производительности и совместной работы, приложения CRM, стек безопасности и бизнес-приложения, которые вы используете уже много лет. Это проявляется в обновлениях от поставщиков, внедрении новых функций и настройках по умолчанию. В большинстве компаний никто это не одобрял.</p> <h3>Скрытый ИИ начинается с одного человека</h3> <p>В большинстве компаний внедрение ИИ уже опережает политику, призванную его регулировать. Этот скрытый ИИ используется сотрудниками для обобщения документов, анализа электронных таблиц и автоматизации задач, потому что это упрощает работу. Руководство предполагает, что внедрение происходит в рамках утвержденных проектов. Это не так. Оно начинается с одного человека, задолго до того, как достигнет какой-либо панели управления или инициирует пересмотр какой-либо политики.</p> <p>Именно здесь формируется реальный риск. Технологические риски, такие как безотказность, установка обновлений и контроль доступа, хорошо известны. ИИ — это другое дело. Он может влиять на решения, генерировать контент, получать доступ к конфиденциальной информации и автоматизировать процессы быстрее, чем любой человек может это контролировать. Если вы не знаете, где работает ИИ, вы не можете контролировать то, что он производит. Если оставить это без внимания, этот пробел превращается в риск нарушения нормативных требований, риск нарушения интеллектуальной собственности, и в конечном итоге возникает вопрос: когда процесс, управляемый ИИ, вызывает проблему, кому он принадлежит? Компании, которые ответят на этот вопрос до того, как он будет задан, будут двигаться быстрее и с меньшим риском, чем те, кто разбирается в этом постфактум.</p> <h3>Ни один отдел не может полностью отвечать за управление ИИ</h3> <p>Управление ИИ не является прерогативой одной функции. Чем больше вы пытаетесь передать это одному подразделению, тем меньше это работает. Служба безопасности должна знать, где находится риск. ИТ-отдел должен знать, к каким системам теперь прикасается ИИ. Руководители отделов данных и соответствия нормативным требованиям отвечают за управление информацией. Финансовый отдел должен знать, сколько средств тратится и что из этого окупается. Решения в области технологий раньше удобно принимались внутри ИТ-отдела, но ИИ перерос эту модель. Организации, добивающиеся реального прогресса, рассматривают управление как общую ответственность руководства, а не как проблему одного руководителя.</p> <p>Хорошее управление обеспечивает три вещи: видимость того, где используется ИИ, ответственность за результаты, которые он производит, и возможность действовать на основе и того, и другого. Руководство знает, где работает ИИ. Сотрудники знают, что допустимо, им это объяснили простым языком. Конфиденциальная информация защищена уже на этапе проектирования, доступ осуществляется целенаправленно, а результаты измеряются, а не предполагаются.</p> <p>Помните: управление не направлено на замедление внедрения. При правильном подходе оно позволяет ускорить внедрение с уверенностью. Команды работают быстрее, когда ограничения понятны, а не когда они гадают, где проходит граница.</p> <h3>Начните с видимости ИИ, а не со стратегии</h3> <p>Когда я обмениваюсь мнениями с другими руководителями высшего звена, обсуждение почти всегда начинается с технологий. Речь идет о том, какие инструменты внедрять, какие платформы оценивать. В конце содержательного разговора мы обсуждаем операционные модели, права принятия решений, ответственность и управление изменениями. Вопрос смещается с «Какой ИИ нам следует внедрить?» на «Как подготовить организацию к эффективному использованию ИИ?».</p> <p>Именно здесь начинается настоящая работа, и именно к этому большинство компаний наименее готовы, потому что это требует, чтобы инфраструктура, управление и операции работали как единая система, а не как набор отдельных решений.</p> <p>Если вы генеральный директор и задаетесь вопросом, с чего начать, первый шаг — это не обсуждение бюджета или составление дорожной карты. Вам нужен ответ на один прямой вопрос: где ИИ уже работает внутри нашей организации сегодня? Не куда его планируется внедрить, не что указано в дорожной карте на следующий год. Речь идет о том, что происходит прямо сейчас, во всех системах, с которыми взаимодействуют ваши сотрудники.</p> <p>Большинство команд, которые честно задают этот вопрос, обнаруживают, что масштабы воздействия оказались больше, чем они ожидали. Скрытый ИИ накапливался годами. Прежде чем вы сможете управлять ИИ, обеспечивать его безопасность или масштабировать его целенаправленно, вам необходимо получить честное представление о том, где вы уже находитесь. ИИ — это не будущая инициатива; он уже работает внутри вашего бизнеса и внутри инструментов, на которые ваши сотрудники полагаются каждый день, независимо от того, составили вы карту его использования или нет.</p> <p>Организации, которые целенаправленно создают видимость, управление и инфраструктуру для управления ИИ, превратят его в измеримое преимущество. Те, кто этого не делает, потратят следующие несколько лет на то, чтобы на собственном горьком опыте узнать, где он все это время работал.</p> Искусственный интеллект уже работает в вашем бизнесе — зачастую незаметно. Прежде чем вы сможете … article https://www.itweek.ru/themes/detail.php?ID=235574 Fri, 18 Sep 2026 10:40:15 +0300 <p>Ошибка при работе с реальным объектом может привести к простою линии, перегрузке сети, дополнительным расходам или дорогостоящему пересмотру уже принятого решения. Цифровой двойник позволяет сначала протестировать сценарий на данных и только потом переносить его в физический мир. Однако такой подход работает только при условии, что модель получает актуальные, полные и согласованные данные. Разберёмся, что корректно называть цифровым двойником, в каких задачах технология уже даёт практический эффект и почему такие проекты чаще упираются не в математику, а в данные.</p> <h3>Что считать цифровым двойником</h3> <p>Термин «цифровой двойник» за последние годы заметно расплылся. Им называют и BIM-модель (Building Information Modeling, цифровое представление сооружения, в котором каждый элемент обладает не только геометрией, но и набором данных) здания, и экран мониторинга станка, и симулятор технологического процесса. Но в строгом смысле цифровой двойник — это динамическая цифровая модель физического объекта, системы или процесса, которая регулярно получает данные о его реальном состоянии и позволяет рассчитывать, как он поведёт себя при изменении условий. Именно эта связь с актуальным состоянием реальной системы и возможность проверять сценарии отличают двойник от статичной 3D-модели, дашборда и обычного мониторинга. Если модель обновляется вручную, это скорее цифровая модель, если автоматически получает данные от объекта, но работает в одностороннем режиме, — цифровая тень. В наиболее полном варианте цифровой двойник поддерживает постоянную связь с объектом и используется не только для наблюдения, но и для расчёта сценариев.</p> <p>Например, для простого мониторинга температуры электродвигателя достаточно датчика и панели. Но чтобы понять причину перегрева и спрогнозировать отказ, уже нужны данные о вибрации подшипников, скорости вращения ротора, нагрузке, режиме работы, внешней температуре и истории ремонтов. Для офисного или промышленного здания набор будет другим: состояние вентиляции, отопления и электроснабжения, расход энергии инженерными системами, фактическая загрузка помещений, режим эксплуатации и графики обслуживания. В медицине один снимок или анализ тоже мало что говорит без динамики показателей, терапии и анамнеза.</p> <p>Граница между обычным мониторингом и цифровым двойником проходит по их функционалу. Если система только показывает текущие показатели, это мониторинг. Если она связана с актуальным состоянием объекта и позволяет на обновляемых данных ответить на вопрос «что произойдёт, если изменить условия?», она становится инструментом моделирования и поддержки решений, то есть выполняет главную функцию цифрового двойника.</p> <h3>Где двойники уже прижились</h3> <p>Цифровые двойники быстрее всего приживаются там, где ошибка, простой или физический эксперимент стоят особенно дорого. Поэтому самые заметные российские кейсы сегодня реализованы в промышленности и ТЭК. Например, в «Газпром нефти» цифровыми двойниками <a href="https://www.interfax.ru/business/1090112">покрыто</a> около 80% цепочки создания стоимости компании — от геологоразведки до реализации нефтепродуктов.</p> <p>Но массовой эта практика пока не стала. <a href="https://ctt.spbstu.ru/news/9205">По данным</a> Росстата, в 2024 году цифровые двойники использовали только 1,36% организаций. В добыче, обрабатывающих производствах, строительстве, транспортировке и хранении, а также в профессиональной, научной и технической деятельности доля была выше — 2,46%. При этом интерес компаний шире текущего числа внедрений.</p> <p>У «Росатома» цифровые двойники <a href="https://rosatomnewsletter.com/ru/2025/11/26/the-power-of-digital-solutions/">используются</a> в проектировании и инжиниринге атомных станций, а также при разработке новых материалов, включая ядерное топливо и композиты. Здесь выгода вполне земная: часть испытаний можно провести в вычислительной среде, сократить число дорогих физических экспериментов и раньше отсеять неудачные инженерные решения.</p> <p>В городе цифровой двойник работает уже не с отдельным оборудованием, а с пространственными и инфраструктурными данными. Так цифровой двойник Москвы <a href="https://www.tadviser.ru/index.php/Статья:Владислав_Шишмарев,_ДИТ_Москвы:_Главное_—_умение_работать_с_данными_и_превращать_результат_в_конкретные_управленческие_решения">содержит</a> более 9 тыс. слоёв данных по всем сферам, которые используются при планировании инфраструктурного развития и тарифном регулировании. Для городской модели это особенно важно, так как одной геометрии зданий недостаточно, нужно регулярно сводить и обновлять данные транспорта, инженерных сетей, строительства и коммунальной инфраструктуры, а результат использовать не как красивую визуализацию, а как основание для конкретного решения.</p> <p>В медицине требования к актуальности и качеству данных ещё жёстче. Полноценный цифровой двойник пациента должен уточняться по мере изменения физического объекта — человека: с учётом новых обследований, терапии, показателей устройств мониторинга и клинической динамики. Поэтому многие нынешние решения корректнее называть «цифровыми тенями»: данные идут от пациента к модели, но обратного контура управления нет. Чем сложнее и изменчивее объект, тем труднее удерживать его цифровое описание в актуальном состоянии.</p> <p>Различия между отраслями прежде всего в цене ошибки и требуемой скорости обновления данных. Для части задач в энергетике критичны секунды и минуты, для логистики — минуты и часы, а городской инфраструктуре в части задач достаточно более редкого пересчёта. Поэтому «реальное время» не означает универсальную гонку за минимальной задержкой. Важно, чтобы данные пришли и были обработаны раньше, чем решение на их основе потеряет смысл.</p> <h3>Опаснее всего данные, которые верны по отдельности</h3> <p>Есть неприятный тип ошибки в данных, который почти не бросается в глаза. Допустим, загруженность дороги измерена пять минут назад, информация о ремонте обновлялась утром, а расписание транспорта — вчера. Все три источника могут быть корректными. Но вместе они описывают город, которого сейчас уже нет.</p> <p>На производстве, в энергетике и логистике происходит то же самое. Если показатели относятся к разным моментам времени, цифровой двойник начинает рассчитывать будущее из плохо собранного настоящего. При ручной аналитике странность ещё можно заметить. При автоматическом управлении ошибка уходит в реальный процесс почти без паузы.</p> <p>Поэтому для двойника мало знать само значение. Нужно понимать, откуда оно появилось, когда обновилось, какие преобразования прошло, были ли пропуски в данных и какой версией модели использовалось. А в идеале система управления данными должна позволять проследить весь путь назад: от итоговой рекомендации до первичного источника.</p> <p>Эту задачу решают управление метаданными и Data Lineage — прослеживаемость происхождения и преобразований данных. Если система советует изменить режим оборудования, перераспределить ресурсы или пересчитать инфраструктурный проект, важно иметь возможность объяснить, на каких данных и правилах основан этот вывод. Особенно если после рекомендации действие запускается автоматически.</p> <p>ИИ хорошо дополняет цифровые двойники: ищет аномалии в потоках сигналов, помогает строить прогнозы, быстрее перебирает сценарии. Но некорректные исходные данные он не исправляет. Скорее делает их последствия менее заметными до тех пор, пока что-то не пойдёт не так. Объекты постоянно меняются, оборудование модернизируют, технологические режимы пересматривают, у логистической сети появляются новые поставщики, в городе строятся новые развязки и кварталы. Исторические данные неизбежно начинают отставать от реальности. Поэтому идея «добавим машинное обучение и станет точнее» работает только тогда, когда сама модель объекта остаётся актуальной.</p> <p>Поэтому вопрос не в том, нужен ли двойнику ИИ. Во многих задачах он уже даёт заметный эффект. Важно то, насколько компания контролирует данные, на которых этот ИИ работает. Чем больше решений принимается автоматически, тем меньше шансов поймать ошибку вручную и тем выше её цена.</p> <h3>Начинать со «всего предприятия» — плохая идея</h3> <p>Построить цифровой двойник предприятия, города, больницы или всей логистической сети — всё это звучит амбициозно. На практике такая постановка легко превращается в бесконечную интеграционную стройку, где число систем и зависимостей растёт быстрее, чем появляется измеримый результат.</p> <p>Рабочий путь обычно намного скромнее. Сначала выбирают один вопрос, на который бизнес действительно хочет получить ответ, и уже под него собирают минимально достаточный набор данных. Далее начинается проверка, где эти данные лежат, кто за них отвечает, как часто они обновляются и можно ли дойти до первичного источника.</p> <p>Поэтому цифровой двойник вряд ли стоит воспринимать как отдельный программный продукт, который можно просто купить и внедрить. Это верхний слой над всей системой работы с данными. Математика может быть отличной, интерфейс — впечатляющим, инфраструктура — мощной, но точнее своих исходных данных двойник всё равно не станет.</p> <p>Нефтяное месторождение, энергосистема, город и пациент слишком разные, чтобы для них существовал один универсальный рецепт. Но бизнес-смысл технологии везде похож: собрать максимально близкое к реальности цифровое состояние объекта и проверить несколько вариантов действий до того, как один из них придётся оплачивать в физическом мире. Поэтому смотреть стоит не на то, насколько эффектно вращается 3D-модель и сколько к ней подключено источников. Гораздо важнее, умеет ли организация связать эти источники между собой, поддерживать данные в актуальном состоянии и объяснить, откуда взялся результат расчёта. В этом и есть практический смысл цифрового двойника для бизнеса. Не построить виртуальную копию ради самой копии, а получить место, где можно сначала проверить решение и только потом платить за его последствия.</p> <p> #IMAGE_235575#</p> Ошибка при работе с реальным объектом может привести к простою линии, перегрузке сети, дополнительным расходам или … article Максим Власюк, директор по работе с корпоративным сектором группы Arenadata https://www.itweek.ru/themes/detail.php?ID=235572 Thu, 17 Sep 2026 14:45:04 +0300 <p>Компания «АйТи Юниверс», российский аккредитованный разработчик программного обеспечения для государственных и корпоративных заказчиков, выпустила Filestone MFT 3.0, третье поколение cистемы контролируемого обмена файлами из Реестра российского ПО. Смена поколений обусловлена новой стратегией интеграций с лучшими сторонними ИТ- и ИБ-инструментами.</p> <p>Главной задачей Filestone MFT версий 3.х является обеспечение совместимости с популярными продуктами, которые формируют информационные контуры с защитой от уязвимостей и угроз разных типов, от человеческих ошибок до целенаправленных высокотехнологичных атак. </p> <p>Как и прежде, продукт предоставляет средства гибкого обмена файлами с развитыми настройками для отделов информационных технологий и информационной безопасности. Новое поколение облегчает работу всех пользователей и устраняет ряд вопросов с внедрением на объекты критической информационной инфраструктуры.</p> <p>Обновление модернизирует программный интерфейс для передачи данных о пользователях, действиях и инцидентах в стороннее ПО российского происхождения. В версии 3.0 это корпоративные антивирусы и SIEM. Реализована интеграция с Kaspersky Scan Engine (KSE), а также отправка логов в MaxPatrol SIEM от Positive Technologies. </p> <p>В дальнейших планах команды Filestone MFT интеграции с дополнительными антивирусами, SIEM и продуктами других классов, таких как DLP, песочницы, системы многофакторной аутентификации, службы каталогов. Приоритет отдан продуктам, запрос на которые поступил от клиентов.</p> <p>О конкретных интеграциях будет объявлено в сообщениях о следующих релизах и партнёрских отношениях.</p> <p>Администратор системы получил возможность полностью отключить локальную авторизацию по электронной почте. После этого вход в Filestone MFT возможен только через корпоративную службу каталогов.</p> <p>Внешние пользователи теперь могут давать согласия на обработку персональных данных, а администраторы — отзывать согласия и анонимизировать персональные данные. Для части пользователей можно ввести исключения в проверке передаваемых архивов на наличие пароля. </p> <p>Информационные панели получили возможность отображать статистические данные по отдельным сотрудникам службы информационной безопасности. А они могут опционально получать на проверку файлы, которые пользователи отправляют сами себе. </p> <p>В настройках появилась ротация логов: сроки и периодичность очистки журнала событий для соблюдения корпоративных правил и во избежание переполнения хранилища.</p> <p>Модернизация Filestone MFT затронула бэкенд для реализации возможностей API: разработку типов данных, их классификации и сбора для отправки в сторонние системы. Пользовательский интерфейс теперь отражает интеграции и новые входящие данные. </p> <p>Помимо этого команда продукта внесла оптимизации и исправила ряд ошибок, а также дополнила документацию. </p> Компания «АйТи Юниверс», российский аккредитованный разработчик программного обеспечения для государственных и корпоративных … message https://www.itweek.ru/themes/detail.php?ID=235571 Thu, 17 Sep 2026 14:43:24 +0300 <p>Компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представила vitiscale — горизонтально масштабируемую СХД, созданную для обработки больших объемов информации. vitiscale уже доступна для российских заказчиков, совместима с отечественными ОС и включена в реестр российского ПО и ПАК Минцифры. Гости мероприятия узнали больше об архитектуре нового решения, процессе создания продукта, преимуществах vitiscale в новых реалиях и сценариях применения высокопроизводительной СХД.</p> <p>«Наша система создана с нуля, не является доработкой или надстройкой open-source продуктов, — рассказал Сергей Мазниченко, генеральный директор datagarden. — Мы делаем прорывные системы хранения данных, за которые нам не стыдно. У нас получилось сформировать в компании инженерную культуру, которая позволяет создавать продукты на уровне последних мировых разработок в сфере технологий хранения данных». </p> <p>Отдельный блок мероприятия эксперты datagarden посвятили тому, как меняется роль хранилища. За последние десятилетия появилось множество задач, для решения которых требуется горизонтально масштабируемая СХД с линейным ростом производительности, не ограниченная двумя контроллерами. Линейный рост производительности при наращивании узлов СХД требует максимально полного использования всех компонентов СХД и становится необходимым условием экономической эффективности решения в целом. Так появляется новый класс систем хранения данных, работающих с задержкой менее миллисекунды при пропускной способности в сотни гигабайт в секунду.</p> <p>«СХД перестала быть просто хранилищем данных, — рассказывает Филипп Комиссаров, руководитель пресейла datagarden. — Она становится неотъемлемой частью архитектуры решения. Чем быстрее СХД, тем больше отдачи от уже купленного GPU. К тому же, в условиях подорожания ИТ-оборудования, можно приобретать меньше вычислительных мощностей, так как быстрый сторадж быстро читает сохраненные токены там, где медленный заставляет систему пересчитывать токены снова и снова, требуя более производительных GPU».</p> <p>Специалисты детально рассмотрели блочный и объектный доступ vitiscale и сценарии их применения. Блочный доступ на базе современных протоколов NVMe/RDMA, NVMe/TCP, NVME/FC, а также iSCSI и Fibre Channel рассчитан на среды с минимальными задержками. Это отраслевой стандарт для финансового сектора, крупного ритейла и критически важных государственных систем: блочный доступ обеспечивает высокую производительность транзакционных СУБД, ИИ-комплексов и средств резервного копирования.</p> <p>Объектный доступ (S3) реализует масштабируемое хранение неструктурированных данных через стандартный API и востребован в банках, телекоммуникационной, нефтегазовой отраслях и госкорпорациях — для надежной и производительной обработки аналитических данных, создания резервных копий и обеспечения эффективной работы систем искусственного интеллекта.</p> <p>На демонстрационном стенде, развернутом в рамках конференции и состоящем из шести узлов платформы vitiscale, были получены следующие результаты:</p> <ul> <li>~29 миллионов операций в секунду при случайном чтении блоков размером 4 КБ при работе по NVMe/RDMA протоколу;</li> <li>~290 000 операций в секунду при случайном чтении объектов 4КБ при работе через S3 API.</li> </ul> <p>Время отклика — менее 1 миллисекунды — означает, что система способна обрабатывать огромный поток запросов с минимальными задержками, а, значит, приложения, базы данных и сервисы будут максимально полно использовать оборудование, на котором работают, даже при пиковых нагрузках. Такие характеристики vitiscale, как высокая производительность, простота эксплуатации, линейная масштабируемость и поддержка современных протоколов доступа, гарантируют адаптивность ИТ-инфраструктуры к новым вызовам и операционную устойчивость коммерческих организаций и госпредприятий.</p> Компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представила … message https://www.itweek.ru/themes/detail.php?ID=235570 Thu, 17 Sep 2026 14:40:54 +0300 <p>MWS AI (входит в МТС Web Services) объявила об обновлении платформы для создания ИИ-агентов без программирования MWS AI Agents Platform. Агенты научились выполнять программный код, который пишут сами, в изолированной песочнице, запускаться по расписанию без команды пользователя и запоминать факты о собеседнике между сессиями. Отдельно в платформе появился конструктор интерфейсов, который даёт агенту собственный экран под конкретную задачу вместо окна чата. Вместе эти функции позволяют собирать на платформе виртуальных сотрудников, то есть связки агентов, которые ведут задачу от начала до конца без участия оператора. Песочница, запуск по расписанию и долгосрочная память уже доступны заказчикам, к конструктору интерфейсов открыт ранний доступ, в промышленную эксплуатацию он выйдет до конца 2026 года.</p> <p>Для сверки данных, расчёта показателей или подготовки отчётности агент может самостоятельно написать программу. Чтобы её выполнение не затронуло рабочие системы компании, платформа запускает такой код в песочнице — изолированной среде с собственными файлами и вычислительными ресурсами. Ограничения доступа обеспечивает программная среда: она блокирует запрещённые обращения независимо от того, какую команду сформировал агент.</p> <p>Песочница создаётся под конкретную задачу и существует только на время её выполнения. Пользователь задаёт разрешённые действия, включая запуск команд, чтение и запись файлов. На вычислительные ресурсы и продолжительность работы установлены лимиты. У агента нет доступа к внутренним системам компании, их паролям и ключам, а внешние подключения к песочнице заблокированы.</p> <p>Например, агент в финансовой организации получает выгрузку из учётной системы, пишет и запускает код для сверки данных, рассчитывает показатели и собирает отчёт. При этом он работает с переданной выгрузкой, не внося изменений в саму систему.</p> <p>Песочница разворачивается вместе с платформой внутри контура заказчика. Код исполняется на инфраструктуре компании: обрабатываемые данные и вычисления не выносятся во внешний сервис.</p> <p>Конструктор интерфейсов даёт агенту собственный экран с кнопками, формами, карточками, таблицами и графиками под конкретную задачу, причём один и тот же агент может по-разному выглядеть для клиента, сотрудника и руководителя. Например, агент авиакомпании при переносе рейса показывает на одном экране текущий билет, подходящие рейсы, стоимость обмена и кнопку подтверждения, а после выбора выполняет действия в подключённых системах. По той же логике собираются интерфейсы для продаж с карточкой клиента и историей общения, для аналитики с дашбордом и выводами, для работы с документами с текстом договора и найденными рисками, для клиентского сервиса с перепиской, данными о заказе и возвратом в одном окне.</p> <p>Агент может работать по расписанию, без команды человека. Пользователь настраивает его один раз и задаёт, когда он запускается с точностью до минуты, в каком часовом поясе и какая версия сценария при этом исполняется. Результат приходит по заданному адресу, а если несколько запусков подряд завершились неудачей, платформа сама приостановит задание и не будет копить ошибки. Запуск можно в любой момент выполнить вручную, приостановить или посмотреть историю выполнений. Таким образом агент каждое утро может собирать свежие данные, анализировать их и обновлять дашборд для руководителя, а другому агенту можно поручить фоновую обработку данных или рассылку напоминаний.</p> <p>Долгосрочная память позволяет агенту запоминать факты о пользователе и возвращаться к ним в следующих разговорах. Пользователь настраивает, какие факты агент сохраняет, и дальше он либо получает их вместе с очередным вопросом пользователя, либо сам решает, когда обратиться к памяти.</p> <p>«К базе знаний агент теперь обращается сам, когда считает нужным. Раньше место обращения к базе разработчик размечал в сценарии заранее, отдельным шагом с поиском по индексу: он решал, в какой точке разговора агент пойдёт в базу и что именно будет искать. Теперь поиск по базе знаний подключается к агенту как инструмент, наравне с остальными, и агент сам решает, когда его применить, сам формулирует запрос и разбирает результат. Базы знаний подключаются напрямую к корпоративным страницам Confluence, а большие наборы документов загружаются одним архивом вместо добавления каждого файла отдельно. Так агент внутренней поддержки отвечает сотрудникам на основе корпоративной базы знаний, опираясь на действующие инструкции и регламенты», — подчеркнул директор по продукту MWS AI Agents Platform Пётр Новиков.</p> <p>Платформа автоматически задаёт агенту набор контрольных вопросов, сравнивает ответы с ожидаемыми и показывает ошибки. Вопросы и ожидаемые ответы заранее готовит пользователь. При необходимости можно посмотреть, что происходило на каждом шаге. Раньше такие диалоги приходилось проверять вручную.</p> <p>«Мы развиваем платформу в сторону универсальных рабочих агентов, которым человек может поручить задачу целиком, задав цель и требования к результату. Такой агент самостоятельно составляет план, запускает других агентов для отдельных этапов и корректирует дальнейшую работу по результатам проверки. Например, поручает одному агенту анализ данных, другому — проверку расчётов, а затем объединяет результаты в отчёт. Для этого агентам нужна общая рабочая среда, где можно выполнять код, пользоваться инструментами и сохранять удачные способы решения для следующих запусков. Обновление платформы создаёт основу для таких систем. При этом заказчик определяет, какие действия агенты выполняют самостоятельно, как оценивается качество и в какой момент к работе подключается человек», — отметил технологический директор MWS AI Agents Platform Андрей Цивына.</p> MWS AI (входит в МТС Web Services) объявила об обновлении платформы для создания ИИ-агентов без программирования … message https://www.itweek.ru/themes/detail.php?ID=235568 Thu, 17 Sep 2026 10:27:24 +0300 <p><em>Согласно данным Gartner, сегодня многие компании сталкиваются с парадоксальной ситуацией: ИТ-бюджеты растут, но доверие к CIO падает. Бизнес перестал слушать «айтишников» не потому, что те плохо разбираются в технологиях. Основная проблема — несогласованность целей. Пока ИТ-директор концентрируется на работе серверов, собственник подсчитывает, насколько прибыльным будет техническое нововведение. Рассмотрим фатальные ошибки, которые совершают даже сильные ИТ-директора в коммуникации с бизнесом.</em></p> <h2>Девять наиболее частых ошибок ИТ-директоров</h2> <p>Перечислим наиболее частые ошибки, которые совершают ИТ-директора в процессе коммуникации с собственниками бизнеса.</p> <h3>1. Выстраивание ИТ-стратегии без настоящей интеграции с бизнесом</h3> <p>Треть ИТ-директоров не чувствуют себя компетентными в вопросах встраивания ИТ-стратегии в корпоративную. Опытные лидеры часто упускают возможность кардинально переформулировать ее вокруг бизнес-результатов. В итоге получается технически безупречная стратегия, которую собственник компании не понимает и не ценит.</p> <h3>2. Общение на технологическом языке</h3> <p>CIO часто готовят ИТ-стратегии и оформляют документацию на языке, понятном только коллегам по цеху. Но для руководителей других отделов терминология ИТ чаще всего звучит как «китайская грамота». Естественно, ни поддержки, ни сотрудничества не возникает, поскольку отсутствует взаимопонимание.</p> <h3>3. Неумение выстраивать кросс-функциональные отношения на ранних этапах</h3> <p>Опытные CIO часто забывают выстраивать отношения с руководителями других подразделений, из-за чего создают неверные стратегические предположения и не успевают за переменами в бизнесе. Без постоянного контакта собственники видят в ИТ лишь подрядчика, а не партнера.</p> <h3>4. Опора на опыт как на замену адаптированной коммуникации</h3> <p>Многие сильные ИТ-директора полагают, что их навыков сторителлинга и коммуникации достаточно для общения со стейкхолдерами. На деле у разных бизнес-лидеров (CEO, CFO, COO, руководители бизнес-подразделений) различные приоритеты и стили принятия решений, поэтому универсальная коммуникация не работает. Только 43% членов советов директоров говорят о том, что ИТ-директора предоставляют полезную информацию для контроля акционерной стоимости. Это сигнал недоверия, который упускают даже сильные лидеры.</p> <h3>5. Позиционирование ИТ-бюджетов как защиты расходов, а не стратегических нарративов</h3> <p>CIO часто подают бюджет как обычную смету расходов, но не показывают, какой доход или выгоду принесут вложения в ИТ. В результате бизнес видит в технологиях только «дыру в бюджете», а не инструмент для развития.</p> <h3>6. Позднее вовлечение в технологические решения</h3> <p>Почти две трети компаний жалеют о купленном ПО. Главная причина — ИТ-специалистов подключают слишком поздно, когда основные решения уже приняты. Это ведет к сбоям, задержкам и разочарованию. При этом даже опытные ИТ‑директора порой не успевают задать правильное направление стратегии.</p> <h3>7. Предположение, что видение без исполнения будет воспринято</h3> <p>Стратегия без исполнения — это провал. Даже опытные ИТ-директора иногда создают убедительные концепции, которые не превращаются в практические направления и измеримые метрики. Команды не имеют четкого видения результата, исполнение хромает, а доверие к руководству падает.</p> <h3>8. Пренебрежение развитием бизнес-проницательности</h3> <p>ИТ-директора часто выступают в роли хранителей данных, а не интерпретаторов бизнес-задач. Без понимания экономических драйверов, поведения клиентов, конкурентной динамики и рычагов эффективности они не могут убедительно расставлять приоритеты инвестиций или вносить значимый вклад в стратегические обсуждения. Технического мастерства больше недостаточно для участия в бизнес-диалогах.</p> <h3>9. Отсутствие социального интеллекта</h3> <p>ИТ-директора, которые не умеют считывать межличностную и организационную динамику, управлять напряженными разговорами или строить подлинные отношения с коллегами-руководителями, рискуют оказаться в изоляции. Умение интерпретировать поведение, управлять отношениями и адаптировать стиль общения крайне важно и часто упускается даже сильными, технически ориентированными лидерами.</p> <p>Чтобы собственник начал слышать CIO, ИТ-директору нужно быть не только техническим экспертом, но и бизнес-стратегом. Каждую инициативу придется формулировать на языке прибыли, рисков и клиентского опыта и вовлекать CFO и COO в обсуждение ИТ-стратегии уже на старте. Главное — научиться доносить сложные вещи простым языком и ставить технологии на службу бизнесу.</p> <p>#IMAGE_235569#</p> Согласно данным Gartner, сегодня многие компании сталкиваются с парадоксальной ситуацией: ИТ-бюджеты растут, но доверие … article Саян Доржиев, эксперт по корпоративным технологиям, ИИ и стратегической трансформации бизнеса (ex-Gartner)