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=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) https://www.itweek.ru/themes/detail.php?ID=235566 Thu, 17 Sep 2026 10:15:17 +0300 <p>Искусственный интеллект сделал код дешевым настолько, что старое правило «проще поправить, чем переделывать целиком» теперь работает не всегда. Однако возникла проблема: техническая возможность переписать продукт еще не означает, что это действительно необходимо.</p> <p>По данным июньского <a href="https://about.gitlab.com/press/releases/2026-06-23-gitlab-research-reveals-organizations-are-generating-ai-code-faster-than-they-can-control-it/">исследования</a> GitLab и The Harris Poll, 85% опрошенных считают, что ИИ уже перенес основное узкое место разработки с написания кода на его проверку и подтверждение качества. Еще 78% говорят, что разработчики стали отдавать код гораздо быстрее.</p> <p>Это хорошо описывает изменение самой экономики разработки. Обсудим, когда правда разумнее собрать продукт заново, почему старый код становится источником требований — и как не превратить переписывание в новую разновидность техдолга.</p> <h3>Код больше не самое дорогое место разработки</h3> <p>Условно можно сказать, что этап написания кода внутри жизненного цикла разработки стал обходиться «почти бесплатно». Не буквально, конечно — модели, инфраструктура и специалисты по-прежнему стоят денег. Просто количество созданного кода все слабее связано с количеством человеко-часов.</p> <p>В качестве примера возьмем задачу переноса мобильного приложения в веб. Агентная система воплощала эту идею в жизнь около 20 часов. Инженер в это время занимался другими тикетами и созвонами — но периодически возвращался к агентам и проверял работу, корректируя результат. По сути он скорее дирижировал системой, нежели писал что-то сам.</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> система перестала выдерживать нужную нагрузку;</li> <li> существующая архитектура не масштабируется;</li> <li> продукт радикально меняет назначение;</li> <li> новый функционал невозможно нормально встроить в исходную конструкцию;</li> <li> развитие старой системы обходится дороже, чем замена проблемной части.</li> </ul> <p>Любопытный пример: в базе данных кандидатов для отдела рекрутмента со временем почти перестал работать поиск — а контактов накопилось очень много. Ситуация дошла до того, что кандидата было легко найти, только если помнишь его фамилию. Нормально отфильтровать базу по стеку и другим параметрам уже не получалось. Можно было и дальше ремонтировать старое приложение, но проблема стала системной.</p> <p>Команда сохранила существующую структуру данных, а агенты проанализировали старый продукт, его зависимости и запросы пользователей. Затем поверх той же базы собрали новую реализацию. Данные и работающая бизнес-логика остались на месте — заменили только деградировавший слой приложения.</p> <p>Это важное отличие от подхода «выбросить все и начать с чистого листа». Переписывать можно не все и вся — только ту часть, которая и впрямь нуждается в обновлении.</p> <h3>С новой дрелью хочется пересверлить полдома</h3> <p>Важный нюанс в том, что дешевизна нового кода снижает психологический порог для таких решений. Представьте, что приобрели новую дрель, которая идеально лежит в руках — с новым инструментом сразу хочется пересверлить полдома. Не потому, что стены требуют ремонта — просто работать стало легко и приятно.</p> <p>С ИИ похожая история. Команда видит, что агенты могут за несколько дней сделать то, на что прежде ушли бы недели или даже месяцы — и начинает искать задачу под новые возможности.</p> <p>Однажды дошло до смешного: после изменений в компании две продуктовые команды оказались сильнее в технологических стеках друг друга. Разумно было бы поменять их местами. Вместо этого оба продукта переписали под более подходящие специалистам технологии.</p> <p>Вот только «можно быстро переписать» — не бизнес-требование. Если в старый продукт надо добавить одну функцию и сделать это можно безопасно для архитектуры, переписывание лишь увеличит область изменений. Примером может служить система, которую прежде развивали несколько разных команд. Код был далеко не идеальным, но объективной причины менять весь продукт не существовало. В итоге агент добавил нужную функцию прямо в существующую реализацию.</p> <p>Можно ли было поступить иначе? Да. Но тогда переписывание стало бы не модернизацией, а использованием новой игрушки ради самой игрушки.</p> <h3>Самая опасная часть старого продукта — то, о чем все забыли</h3> <p>У наследуемых систем есть еще одна особенность: внутри часто живет функциональность, которой нет ни в документации, ни в памяти текущей команды. Причем забывают обычно именно о том, что исправно работает.</p> <p>Например, в одном из старых внутренних сервисов обнаружили скрипт, который автоматически ставил служебную маркировку на корпоративные файлы. По смыслу он вообще не был связан с этой системой — просто оказался там исторически.</p> <p>Если бы просто собрали требования у основных пользователей, никто не рассказал бы про этот скрипт. Старую систему отключили бы, потеряв с ней рабочую функцию. А так агент обнаружил зависимость при анализе кода, и механизм перенесли в более подходящий сервис.</p> <p>Такие ситуации можно связать с восходом солнца: оно каждый день поднимается на востоке, и никто не пишет отдельное требование «солнце должно продолжать вставать». Вспомнят об этом только в тот день, когда рассвет почему-то не наступит.</p> <p>Именно поэтому переписывание с нуля порой куда опаснее, чем переписывание по фактическому поведению старой системы.</p> <h3>Старый продукт можно превратить в исполняемую спецификацию</h3> <p>До большого переписывания существующий продукт можно максимально покрыть автоматическими тестами: пользовательскими, интеграционными, сквозными. Причем сами тесты тоже помогают готовить агенты.</p> <p>Дальше старая реализация становится эталоном поведения. Команда создает новую версию и запускает на ней те же проверки. Схема получается такой: «существующий код — восстановленные требования — автоматические тесты — новая реализация — те же тесты». Если проверка падает, возникает конкретный вопрос: это новая система что-то сломала, или старая работала не так, как думала команда?</p> <p>По сути, здесь соединяются принципы SDD (разработки от спецификации) и TDD (разработки через тесты). Сначала команда восстанавливает из существующей системы спецификацию — что продукт должен делать, какие сценарии и рамки сохранять. Затем это поведение фиксируется автотестами, которые становятся проверяемыми требованиями к новой реализации.</p> <p>Получается двойная страховка: спецификация объясняет, что нужно сохранить, а тесты позволяют проверить: правда ли новое решение это сохранило.</p> <h3>Тесты могут рассказать о продукте больше, чем документация</h3> <p>Особенно интересны упавшие проверки. Они способны обнаружить скрытое поведение, исключения и исторические решения, о которых команда уже не помнит. Иногда даже выясняется, что годами система работала не так, как предполагали владельцы продукта.</p> <p>Причем не каждое отличие новой версии нужно автоматически исправлять. Если тест обнаружил неожиданное поведение старой системы, стоит сначала выяснить, действительно ли его надо воспроизводить. Возможно, команда просто впервые увидела старое ограничение или ошибку — и переписывание дает возможность осознанно от них отказаться.</p> <p>В этом смысле падающий тест становится и сигналом «мы что-то сломали», и источником нового знания о собственном продукте.</p> <p>Так переписывание превращается не просто в техническую операцию. Можно улучшить не только архитектуру и другие нефункциональные характеристики, но иногда и саму функциональность — если стало понятно, что прежнее поведение больше не имеет смысла.</p> <h3>Прежде чем все переписать: памятка</h3> <p>Искусственный интеллект сделал полное переписывание доступнее — и именно поэтому решение о нем надо принимать строже. Перед стартом полезно пройти несколько шагов:</p> <ol> <li> <strong>Ответить на вопрос: «Чтобы что?» </strong>Зафиксировать конкретную проблему: скорость, нагрузку, архитектурное ограничение, стоимость изменений или смену назначения продукта.</li> <li><strong>До начала переписывания максимально покрыть существующую систему автоматическими тестами. </strong>С помощью ИИ можно быстрее подготовить пользовательские, сквозные, интеграционные и другие проверки. Важно, чтобы они проходили на старом продукте и фиксировали его фактическое поведение.</li> <li><strong>Попросить агентов разобрать существующую систему и восстановить спецификацию</strong><strong>:</strong> компоненты, зависимости, сценарии и скрытые функции, которые могли не попасть в документы. Причина переписывания тоже должна стать частью требований к новой версии.</li> <li><strong>Разделить то, что обязательно нужно сохранить, и то, что команда намеренно хочет изменить.</strong> Новая реализация должна воспроизвести нужное поведение, но не обязана копировать старую архитектуру и ее ограничения.</li> <li><strong>Собрать новую версию и запускать на ней тот же набор тестов. </strong>Продолжать до тех пор, пока обязательные проверки не перестанут падать, а каждое оставшееся расхождение не будет объяснено.</li> <li><strong>Не исправлять отклонения автоматически. </strong>Падение теста может означать как ошибку новой версии, так и неожиданное или уже ненужное поведение старой системы.</li> <li><strong>Только после этого выключать старую реализацию. </strong>Генерация новой версии может занять часы, тогда как последствия потерянной зависимости способны проявиться через месяцы.</li> </ol> <h3>Что в итоге</h3> <p>ИИ действительно меняет старый выбор между рефакторингом и переписыванием. Там, где цена полной переработки прежде останавливала команду, технический барьер стал значительно ниже.</p> <p>Однако это не меняет стоимости неправильного решения. Новый код можно сгенерировать очень быстро — гораздо сложнее восстановить десятилетие бизнес-логики, скрытые зависимости и поведение, к которому привыкли пользователи.</p> <p>Главный эффект ИИ здесь в том, что старую систему теперь можно быстрее разобрать, превратить ее поведение в спецификацию и осознанно собрать новую — только там, где это правда имеет смысл.</p> <p> #IMAGE_235567#</p> Искусственный интеллект сделал код дешевым настолько, что старое правило «проще поправить, чем переделывать целиком» теперь … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235565 Thu, 17 Sep 2026 10:04:09 +0300 <p><em>Некоторые эксперты по сетям предполагают, что ИИ возьмет на себя бóльшую часть работы по управлению сетью с минимальным участием человека. Но сделает ли это саму сеть более интеллектуальной — или просто сделает инструменты, используемые для ее управления, более интеллектуальными — это спорный вопрос, отмечают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Сети уже давно рассматриваются как основа критически важной корпоративной ИТ-инфраструктуры, которая соединяет системы и перемещает данные. ИИ меняет подход к управлению этой инфраструктурой. Системы управления сетями теперь могут сопоставлять разрозненные сигналы, помогая ИТ-командам выявлять наиболее критические проблемы, и, в некоторых случаях, автоматически их решать.</p> <p>В какой степени ИИ в конечном итоге сможет управлять сетями — это открытый вопрос. Для CIO он заключается в том, сможет ли сеть в какой-то момент превратиться из инфраструктуры, управляемой ИТ, в инфраструктуру, которая помогает управлять самими ИТ.</p> <p>«Сеть — это не мозг; это нервная система, — говорит Паоло Канале, руководитель сектора телекоммуникаций EY в Северной и Южной Америке. — Это децентрализованный интеллект, в котором заинтересованы все сетевые операторы».</p> <p>По его словам, ИИ «оживляет сеть», имитируя работу нервной системы. При этом ИИ может анализировать данные и оповещения, поступающие из разных сегментов сети, чтобы приоритизировать проблемы и автоматизировать некоторые действия.</p> <p>Канале отмечает, что сеть также все больше объединяет интеллектуальные области, включая периферийную инфраструктуру, облачные платформы и приложения ИИ.</p> <p>Однако Роз Роузборо, старший главный аналитик исследовательской компании Omdia, утверждает, что большая часть изменений происходит в инструментах, используемых для управления сетями, а не в самой сети.</p> <p>«Возможно, это придирки, но я не уверена, что меняется сама сеть, — говорит она. — Меняются инструменты, которые поставщики услуг связи используют для управления сетью. Точно меняются OSS (системы поддержки операций). У людей, которые управляют сетью, теперь есть более интеллектуальные инструменты».</p> <p>Канале указывает на еще одно изменение: ИИ может сопоставлять информацию из разных систем мониторинга сети, которые исторически работали изолированно. «Разница в том, что теперь сеть получила возможность собирать все эти сигналы, устанавливать корреляции и определять, в чем реальная проблема. И, что более важно, как это повлияет на клиента, как это повлияет на бизнес», — поясняет он.</p> <h3>Более интеллектуальное и быстрое управление сетью</h3> <p>Способность ИИ использовать информацию из разных сетевых систем также делает управление сетью более оперативным. Сеть по-прежнему похожа на коммунальную службу, перемещающую данные из точки А в точку Б, но с ИИ она становится «более оперативной, чем раньше, потому что может обрабатывать больше информации, чем прежде», — говорит Роузборо.</p> <p>Агенты ИИ могут идентифицировать и получать доступ к данным в разрозненных системах, таких как системы биллинга и системы обслуживания, чтобы, например, найти информацию об использовании маршрутизатора.</p> <p>«Теперь инвентаризация становится чем-то вроде системы учета, и все зависит от того, может ли она выполнить то, о чем вы ее запросили. И сделать это в режиме реального времени, — говорит Роузборо. — Это позволяет делать вещи быстрее и в бóльших масштабах. Вы можете просто сказать агенту: „Вперед, сделай это“, и он сможет это осуществить».</p> <p>Некоторые из базовых технологий сетевого интеллекта не новы. Брайан Уошберн, главный аналитик Omdia, указывает на такие технологии, как Cisco NetFlow и Juniper JFlow, которые уже давно предоставляют аналитику сетевых событий. По его словам, ИИ может ускорить объединение информации из разрозненных систем управления сетью.</p> <p>Технологии сетевого интеллекта и наблюдаемости — это «части, которые, можно сказать, ведут себя как отдельные нервные системы. Теперь, благодаря волшебству ИИ, мы можем начать объединять некоторые из них, что особенно важно для предприятий, которые приобрели десяток различных систем управления сетью», — отмечает Уошберн.</p> <p>По его словам, ИИ также может упростить взаимодействие ИТ-специалистов с сетевыми системами. Например, ИТ-команды могут использовать обработку естественного языка (NLP) и агентов ИИ для запроса ценового предложения на новое оптоволоконное подключение в офисе, вместо того чтобы размещать заказ через представителя-человека.</p> <p>Роузборо отмечает, что NLP также позволяет CIO и ИТ-командам «задавать вопросы относительно сети и сопоставлять больше типов информации, чем раньше, а затем стратегически использовать эту информацию. Предприятие может получить инсайты, которые оно сможет использовать для развития своих услуг».</p> <h3>Технологии, поддерживающие более интеллектуальное управление сетью</h3> <p>Несколько технологий помогают сделать управление сетью более интеллектуальным и автоматизированным:</p> <p><strong>Цифровые двойники.</strong> Это одна из технологий, поддерживающих более интеллектуальное управление сетью. Согласно данным McKinsey, цифровые двойники сетевых сред могут использоваться в качестве испытательных полигонов и сред обучения для генеративного ИИ (GenAI), а GenAI — анализировать результаты работы цифровых двойников.</p> <p>Например, AT&T использует свою GenAI-систему GEO Modeler, которая виртуально зеркалирует сеть, помогая выявлять и сопоставлять сбои. Система может моделировать и прогнозировать покрытие сети, чтобы подготовиться к инцидентам, которые могут повлиять на доступность сети, — например, к отключению вышки сотовой связи во время бури.</p> <p><strong>Возможности самостоятельных действий (Self-X).</strong> Они выводят эту эволюцию на новый уровень, позволяя сетевым функциям работать с меньшим участием человека. Self-X включает «семейство возможностей, таких как самоконтроль, самовосстановление, самооптимизация и, в конечном итоге, самопланирование», — поясняет Канале.</p> <p>В настоящее время многие сети могут обнаруживать аномалии, определять вероятную первопричину проблемы, рекомендовать решение или предпринимать действия по устранению неполадок с помощью «заранее определенных корректирующих действий», добавляет он. Например, если базовая станция сотовой связи перегружена, сеть может автоматически перенаправить трафик или скорректировать конфигурации для поддержания уровня качества обслуживания.</p> <p>«Мы ожидаем, что со временем сети перестанут просто реагировать на проблемы. Вместо того чтобы ждать их возникновения, они будут прогнозировать всплески спроса, предвидеть сбои до того, как они произойдут, пересматривать планы пропускной способности и постоянно оптимизировать свою работу с минимальным участием человека. Конечная цель — сеть, которая учится на каждом событии, постоянно совершенствуется и управляет большей частью своей работы самостоятельно», — говорит Канале.</p> <p>Связанная с этим концепция Zero-X Experience описывает, что может означать бóльшая автономность сети для клиентов: обеспечение работы сети и предоставление услуг, требующие минимального или нулевого вмешательства с их стороны. Для клиентов сервис-провайдеров — включая CIO и ИТ-команды предприятий — внедрение ИИ может означать сети, которые функционируют без необходимости создания тикетов, эскалации или устранения неполадок, поясняет Канале.</p> <p>Он приводит пример розничного продавца, готовящегося к «черной пятнице». Традиционно ИТ-команде приходилось вручную запрашивать дополнительную пропускную способность, отслеживать производительность сети и реагировать на любые проблемы, возникающие во время распродажи.</p> <p>«Согласно концепции Zero-X сеть распознает предстоящий спрос, заблаговременно выделяет дополнительные мощности, непрерывно оптимизирует производительность во время события и возвращает ресурсы после его окончания без участия человека, — говорит Канале. — Клиент никогда не открывает тикет, не ждет подтверждения и может даже не осознавать, что оптимизация произошла».</p> <p>По его словам, ИИ также объединяет части сетевых операций, которые традиционно были изолированы, включая системы поддержки бизнеса (BSS) и OSS. «Там, где появляется ИИ, он действительно разрушает все эти барьеры и создает открытую экосистему, которая может напрямую быстро подключать BSS к OSS», — отмечает Канале.</p> <h3>Насколько далеко может зайти автономия сети?</h3> <p>По мере того, как ИИ берет на себя все больше функций управления сетью, возникает вопрос, какая часть этой работы в конечном итоге может выполняться без вмешательства человека. Канале считает, что ИИ делает сеть более интеллектуальной, в то время как сеть поддерживает эволюцию ИИ.</p> <p>«Это почти как двусторонняя трансформация, — говорит он. — С одной стороны, ИИ, безусловно, делает сети более предсказуемыми, адаптивными и все более автономными. Но в то же время ИИ предъявляет к сети новые требования. Значительно возрастают требования к задержке, передаче данных, безопасности, отказоустойчивости, стоимости и т. д.».</p> <p>При этом Канале отмечает, что хотя управление сетью станет в значительной степени автономным, оно не будет автономным в каждой ситуации. «Рутинные операционные действия, такие как мониторинг, обнаружение неисправностей, управление конфигурацией, оптимизация производительности и прогнозирование пропускной способности, являются отличными кандидатами для автономной работы, — говорит он. — Эти действия основаны на больших объемах данных и повторяющихся шаблонах принятия решений, где ИИ показывает себя исключительно хорошо».</p> <p>Роузборо поддерживает прогноз Канале о том, что сеть никогда не будет полностью автономной, поскольку это было бы «слишком рискованно». По ее словам, поставщики услуг связи стремятся к автоматизации <nobr>4-го</nobr> уровня для большинства сетевых процессов. Отраслевая телекоммуникационная организация TMForum представила таксономию уровней автономной сети — от 0 до 5, где уровень 0 означает «ручное управление и техническое обслуживание», а уровень 4 — «высокую автономность», обеспечивающую «замкнутое управление сетями, ориентированными на обслуживание и клиентский опыт, посредством ИИ-моделирования и непрерывного обучения».</p> <p>По словам Канале, ИИ будет принимать решения, которые являются «частыми, основанными на данных и оперативными по своему характеру», в том числе:</p> <ul> <li> Выявление и устранение сетевых инцидентов.</li> <li> Динамическая корректировка сетевых конфигураций.</li> <li> Оптимизация маршрутизации и потоков трафика.</li> <li> Прогнозирование сбоев оборудования.</li> <li> Предоставление услуг.</li> <li> Управление стандартными мерами безопасности.</li> <li> Прогнозирование спроса и рекомендации по изменению пропускной способности.</li> </ul> <p>К областям, которые по-прежнему будут требовать участия человека, относятся «важные архитектурные решения, стратегические инвестиции, нормативные соображения и бизнес-компромиссы, — считает он. — Полезный принцип заключается в том, что ИИ должен все чаще принимать оперативные решения, в то время как люди остаются ответственными за стратегические решения».</p> <p>Канале также отмечает, что люди будут продолжать руководить решениями по управлению сетью, касающимися доверия клиентов, соответствия нормативным требованиям и долгосрочной стратегии, выбора сетевой архитектуры, управления безопасностью и выбора поставщиков. Роузборо поясняет, что любые изменения в сети, которые могут привести к перебоям в предоставлении услуг клиенту, скорее всего, всегда будут подтверждаться или утверждаться человеком.</p> <p>По мере того как сети будут становиться все более автономными, роль CIO будет приобретать более стратегический характер, они будут уделять больше внимания клиентскому опыту и цифровым бизнес-моделям, добавляет Канале. По его словам, ИТ-командам потребуется повысить квалификацию в области управления ИИ и контроля за системами ИИ, управления качеством данных, а также сосредоточить внимание на управлении результатами для бизнеса.</p> <p>Канале сравнивает эту трансформацию с внедрением автопилота в авиации. Человек-пилот не был упразднен, но его «роль эволюционировала от непрерывного управления самолетом к контролю за все более сложными системами и вмешательству при необходимости. Сетевые технологии движутся в очень похожем направлении: все меньше людей управляют отдельными устройствами, и все больше людей оркестрируют интеллектуальные системы, которые управляют собой сами».</p> Некоторые эксперты по сетям предполагают, что ИИ возьмет на себя бóльшую часть работы по управлению сетью … article https://www.itweek.ru/themes/detail.php?ID=235560 Wed, 16 Sep 2026 19:03:06 +0300 <p>После нескольких лет аномально высокого спроса российский рынок труда в ИТ-сфере возвращается к более сбалансированному состоянию: острый кадровый дефицит уходит на второй план, а требования к кандидатам ужесточаются. Насколько навыки ИТ-специалистов соответствуют потребностям работодателей? Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает этот вопрос на примере разработчиков ПО и специалистов по ИТ-инфраструктуре.</p> <p>В 2025 г. в России насчитывалось 944,1 тыс. разработчиков ПО и 432,4 тыс. специалистов по ИТ-инфраструктуре. К первой группе (код 251 по Общероссийскому классификатору занятий) относятся специалисты, участвующие в создании и внедрении ИТ-продуктов: разработчики приложений и программ, программисты, аналитики и архитекторы данных и ПО, тестировщики. Специалисты по ИТ-инфраструктуре (код 252) — сетевые инженеры, специалисты по информационной безопасности и администраторы баз данных — обеспечивают функционирование и безопасность сетей и баз данных.</p> <p>По классификатору занятий обе группы относятся к специалистам высшего уровня квалификации, для которых диплом вуза считается стандартным требованием. На практике, особенно при кадровом дефиците, работодатели готовы рассматривать и кандидатов без высшего образования. Среди разработчиков доля выпускников вузов выше, чем среди специалистов по ИТ-инфраструктуре: 79% против 73%. Среднее профессиональное образование имеют соответственно 19% и 24% работников, общее среднее — 2% и 3%.</p> <p>Отдельно оценивалось соответствие профиля обучения содержанию текущей работы. Оно у разработчиков также выражено сильнее: разработчики ПО чаще работают по полученной специальности (91,5% против 84% специалистов по ИТ-инфраструктуре). При этом такое соответствие может определяться не только формальным совпадением диплома и профессии: достойную ИТ-подготовку могут давать также физические и технические направления.</p> <p>Подавляющее большинство ИТ-специалистов (89,5% разработчиков и 90,2% специалистов по ИТ-инфраструктуре) считают свои навыки полностью соответствующими требованиям текущей работы. Еще <nobr>7–8%</nobr> полагают, что способны решать более сложные задачи. В целом требования к разработчикам по большинству видов компетенций выше, чем к специалистам по ИТ-инфраструктуре, хотя общий профиль требований к обеим группам близок.</p> <p>Профессиональные компетенции (их респонденты оценивали применительно к своей конкретной деятельности) и навыки работы с компьютером востребованы у всех опрошенных и составляют основу требований к ИТ-специалистам. Потребность в продвинутом уровне этих навыков отмечают <nobr>48–57%</nobr> респондентов. Порядка трети для их работы достаточно среднего уровня, а для <nobr>12–15% —</nobr> и вовсе базового. Математические навыки и навыки работы с текстом востребованы у <nobr>74–88%</nobr> ИТ-специалистов (чаще нужны на среднем или базовом уровне).</p> <p>Навыки работы с ИИ необходимы 49% разработчиков и 39% специалистов по ИТ-инфраструктуре, причем их продвинутый уровень, предполагающий разработку и внедрение ИИ-решений, востребован лишь у <nobr>15–16%</nobr> работников этих групп, то есть остается нишевой компетенцией даже среди ИТ-специалистов.</p> <p>Иностранный язык используют 35% разработчиков и 26% специалистов по ИТ-инфраструктуре и, по их оценкам, достаточно его знать на среднем уровне, что может быть связано с невысокой вовлеченностью этой категории работников в международные проекты.</p> <p>Мягкие навыки ИТ-специалисты отмечают как необходимые значительно реже: по отдельным компетенциям от 57% до 79% работников сообщают об отсутствии потребности в них.</p> <p>Топ-3 наиболее востребованных мягких навыков у разработчиков составляют решение проблем (43%), работа в команде (42%) и способность к обучению (41%). У специалистов по ИТ-инфраструктуре лидируют решение проблем и работа в команде (по 38%), далее идут способность к обучению и работа с клиентами (по 33%). В целом разработчики отмечают более высокие требования к мягким навыкам, особенно когнитивным, а специалисты по инфраструктуре — к социальным, что, видимо, коррелирует с их более частым взаимодействием с внутренними заказчиками и урегулированием инцидентов.</p> <p>По всем рассматриваемым типам навыков большинство респондентов, которым они необходимы, считают свой уровень соответствующим требованиям текущей работы <nobr>(74–91%).</nobr> Это может свидетельствовать об эффективности механизмов подбора и адаптации кадров в ИТ-сфере. В отношении профессиональных навыков, математики, работы с компьютером и текстом примерно каждый пятый-шестой респондент в обеих группах оценивает свой уровень выше требуемого, что указывает на потенциал повышения производительности.</p> <p>Наиболее заметный дефицит наблюдается в навыках работы с ИИ и знании иностранных языков: недостаточный уровень отмечают соответственно <nobr>10–11%</nobr> и <nobr>8–12%</nobr> работников, которым эти навыки необходимы. Для мягких навыков характерна другая ситуация: среди тех, кому они нужны (а востребованными их считают менее половины работников), <nobr>84–91%</nobr> считают свой уровень соответствующим требованиям, а лишь <nobr>2–5%</nobr> признают его недостаточным. Возможно, работники, чьи профессиональные роли требуют мягких навыков, действительно хорошо подготовлены. Вместе с тем нельзя исключать, что ИТ-специалисты не воспринимают мягкие навыки как отдельную категорию профессиональных компетенций.</p> <p>Результаты анализа ИСИЭЗ НИУ ВШЭ показали, что большинство ИТ-специалистов (около 90%) считают свои навыки соответствующими требованиям текущей работы, что может отражать как реальный уровень подготовки, так и ограниченную сложность задач в части компаний. При этом <nobr>16–21%</nobr> работников оценивают профессиональные, компьютерные, текстовые и математические навыки выше требуемого уровня. Для дальнейшего технологического развития важны более полное использование имеющихся компетенций и устранение дефицита навыков работы с ИИ и иностранных языков.</p> После нескольких лет аномально высокого спроса российский рынок труда в ИТ-сфере возвращается к более сбалансированному … message https://www.itweek.ru/themes/detail.php?ID=235559 Wed, 16 Sep 2026 19:00:15 +0300 <p>Компания Pantum, производитель печатного оборудования, объявила о выходе новых струйных МФУ — MT300W и MT302W. Это первые устройства в портфеле компании, которые используют технологию струйной печати. Новинки поддерживают цветную печать A4 и станут универсальным решением для дома или небольшого офиса, а также станут незаменимыми помощниками во время учёбы.</p> <p>Одной из ключевых особенностей МФУ стала встроенная система непрерывной подачи чернил (СНПЧ), которая позволяет сократить расходы на печать. Удобная система заправки обеспечивает быстрое и аккуратное пополнение чернил, а прозрачные резервуары позволяют в любой момент контролировать их уровень. Чернила идут в комплекте. Для стабильной работы обе новинки оснащены системой автоматического смачивания печатающей головки. Эта технология предотвращает засыхание чернил в соплах даже при длительных паузах в печати. Интеллектуальная многоступенчатая система очистки печатающей головки помогает поддерживать высокое качество печати и снижает затраты на обслуживание.</p> <p>Скорость печати составляет до 5 стр./мин. в цветном режиме и до 8.5 стр./мин. в чёрно-белом, что соответствует средним показателям устройств мировых производителей в данной категории МФУ. Лоток подачи вмещает 100 листов. Высокое разрешение печати и сканирования гарантирует чёткие документы и детализированные изображения, а функция печати без полей позволяет получать яркие фотографии высокого качества. </p> <p>Управление осуществляется через дисплей. Новинки также поддерживают беспроводное подключение по Wi-Fi и работу с мобильными устройствами через AirPrint, Mopria и приложение Pantum. Компактный корпус позволяет разместить устройства даже в небольшом пространстве, стильный дизайн легко впишется в любой интерьер.</p> <p>«Pantum — признанный лидер в сфере лазерных принтеров и МФУ, наши решения востребованы на рынке России, миллионы пользователей доверяют Pantum. Мы вложили весь свой опыт в разработку доступных и эргономичных струйных решений для печати, которые подойдут как для дома, так и для небольшого офиса. Струйные печатающие устройства представляют важный шаг в развитии компании, выход в качественно новый для нас сегмент и, что самое главное, возможность предложить пользователям и партнерам новый продукт. В данный момент в России нет других производителей струйных МФУ, которые бы продавали свою продукцию официально, предлагая пользователям сервис, гарантию, обеспечивали непрерывное наличие. Pantum предлагает надежное и доступное устройство», — отметил Александр Кукин, генеральный директор Российского представительства Pantum.</p> <p>Струйные МФУ от Pantum станут отличным решением для ежедневной работы с документами и фотографиями. MT302W в белом цвете доступно к покупке в сети DNS, рекомендуемая розничная цена — 12 999 р. MT300W в тёмно-сером цвете поступит в продажу позднее. </p> Компания Pantum, производитель печатного оборудования, объявила о выходе новых струйных МФУ — MT300W и MT302W. Это … message https://www.itweek.ru/themes/detail.php?ID=235558 Wed, 16 Sep 2026 18:58:47 +0300 <p>Компания «Базис» объявила о выпуске новой версии своей флагманской платформы серверной виртуализации Basis Dynamix Enterprise 4.7. Релиз сосредоточен на четырех направлениях: экономии дискового пространства, автоматизации развертывания и эксплуатации платформы, контроле распределения вычислительных ресурсов и аудите событий. Всего в новую версию платформы вошло более 120 улучшений и исправлений, которые упрощают для администратора часть рутинных обязанностей и дают ему больше контроля над распределением вычислительных ресурсов.</p> <p>В предыдущей версии Basis Dynamix Enterprise тонкие диски и связанные клоны были реализованы для дисков, использующих для хранения емкость вычислительных узлов (Local SEP). В релизе 4.7 эта модель была распространена на общие хранилища Shared SEP. Теперь физическое пространство под диск не резервируется при создании, а выделяется по мере записи данных и расширяется автоматически, без остановки виртуальной машины, что позволяет администратору использовать это пространство более эффективно. Связанные клоны хранят только изменения относительно базового эталонного образа — это заметно сокращает расход емкости дисков при массовом развертывании однотипных машин из общего образа, в том числе в сценариях VDI. Размещение снапшотов больше не требует постоянного участия пользователя: пул для моментальных снимков задается в конфигурации пула хранения, и платформа применяет его автоматически.</p> <p>Чтобы выделение тонких дисков не приводило к неожиданному исчерпанию емкости, платформа контролирует фактическое заполнение пула: при исчерпании более 75% администратор получает предупреждение, при 90% и выше — платформа уведомляет администратора и блокирует создание и увеличение дисков.</p> <p>Подключение нового узла к платформе было значительно упрощено, теперь это одно действие — вызов API или заполнение формы в портале. Далее платформа сама выполняет полный цикл регистрации и установки. Инсталлятор дополняет конфигурацию недостающей секцией с системой авторизации, а маршрутизация консольного доступа к виртуальным машинам обновляется динамически при добавлении узлов и изменении их статуса. Все перечисленное значительно упрощает работу администратора Basis Dynamix Enterprise 4.7 и снимает с него часть рутинной нагрузки.</p> <p>Для работы в совмещенном режиме, когда на одном физическом узле одновременно работают виртуальные машины и программно-определяемая система хранения, в Basis Dynamix Enterprise 4.7 появилась возможность резервировать процессорные ядра и оперативную память — на уровне ЦОДа, зоны или отдельного физического узла. Это дает предсказуемое распределение мощностей, так как часть ресурсов гарантированно остается доступной для программно-определяемых СХД, а не расходуется под виртуальные машины. Изменение настроек безопасно для работающей нагрузки, и увеличение резерва не приводит к остановке или перезапуску уже работающих машин. Дополнительно платформа следит за потреблением ресурсов на узлах и предупреждает администратора при достижении 80% и 90% потребления.</p> <p>Подключение PCI-устройств к виртуальным машинам в Basis Dynamix Enterprise 4.7 перенесено в интерфейс платформы. Теперь администратор видит на странице вычислительного узла список доступных для подключения устройств — платформа автоматически формирует его и поддерживает в актуальном состоянии. Устройство можно подключить к ресурсной группе или сразу привязать к конкретной машине, а переключение драйвера выполняется из портала или через API, без ручной правки конфигурации на узле. При подключении устройства доступны два режима: безопасный, применяемый после перезагрузки узла, и горячий, применяемый без перезагрузки, но способный нарушить работоспособность узла (платформа явно обозначает этот режим как рискованный). Возврат к системному драйверу выполняется только в безопасном режиме.</p> <p>Разные поколения процессоров на узлах одной площадки традиционно ограничивают миграцию виртуальных машин. Basis Dynamix Enterprise 4.7 помогает администратору снять это ограничение: платформа определяет поколение процессора каждого узла и позволяет администратору задать профиль выравнивания для группы вычислительных узлов (зоны). Профиль balanced дает возможность совместного использования процессоров разных поколений в рамках одной зоны — это помогает миграции ВМ между узлами, поддерживающими выбранное поколение виртуальных процессоров. Профиль compatible помогает осуществлять миграцию между всеми узлами одной зоны за счет автоматического выбора для этих узлов одного поколения CPU с минимальным набором инструкций (даже если физический узел поддерживает более современные поколения). Профиль выбирается при создании виртуальной машины.</p> <p>Собственный гипервизор является важной частью экосистемы «Базиса», и в релизе Basis Dynamix Enterprise 4.7 была реализована поддержка новейшего Basis vCore 2.1. В актуальной версии гипервизора были обновлены ядро и ключевые системные библиотеки, добавлены механизмы контроля целостности файловой системы (IMA) и реализована поддержка основных сервисов, обеспечивающих комплексную защиту и контроль сред контейнеризации. Кроме того, были расширены сетевые функции и поддержка программно-определяемых систем хранения, внедрены новые возможности управления пользователями, парольной политикой, SSH-доступом, а также оптимизирована работа установщика и конфигуратора.</p> <p>Аудиторские сообщения Basis Dynamix Enterprise 4.7 теперь передаются во внешние системы сбора и хранения журналов по протоколу Syslog в стандартном для передачи событий формате RFC 5424. Благодаря этому внешние системы, например, SIEM, могут автоматически обрабатывать сообщения от платформы и выдавать администратору более структурированную и понятную информацию об инциденте. Сообщения платформы могут передаваться в том числе в решение для защиты информации в среде виртуализации Basis Virtual Security с целью создания единого журнала событий. Одновременно реализована маскировка чувствительных данных: значения ключей и паролей автоматически скрываются как в параметрах, так и в результатах API-вызовов.</p> <p>Расширены сетевые возможности платформы — от управления группами доступа SDN и применения групп безопасности на уровне сетей до новых сценариев работы с сетями PRIVATE и мониторинга DPDK-инфраструктуры узла. Диски получили режим «только чтение» и управление обработкой команд TRIM/UNMAP на уровне пула и отдельного диска, уточнен учет больших страниц памяти.</p> <p>Длительные операции (клонирование, работа со снапшотами, резервное копирование и восстановление дисков) переведены на асинхронную обработку. В портале появились массовые действия над объектами и физическими узлами, обновлен ряд страниц и разделов, обновлен графический интерфейс планировщика ресурсов DRS.</p> <p>«Когда мы говорим о развитии платформы Basis Dynamix Enterprise, речь не только о ее функциональности. Не менее важная задача — сделать работу с ней более простой и удобной. В новом релизе 4.7 мы автоматизировали ряд сложных операций, которые раньше администратор выполнял вручную, как при развертывании, так и в повседневной эксплуатации. Платформа стала эффективнее распоряжаться дисковым пространством и вычислительными ресурсами, а администратор получил больше контроля над их распределением. Чем крупнее инсталляция у нашего заказчика, тем сильнее он почувствует эффект от новых возможностей платформы», — прокомментировал Дмитрий Сорокин, технический директор компании «Базис».</p> Компания «Базис» объявила о выпуске новой версии своей флагманской платформы серверной виртуализации Basis Dynamix … message https://www.itweek.ru/themes/detail.php?ID=235557 Wed, 16 Sep 2026 18:57:03 +0300 <p>Разработчик экосистемы инфраструктурного ПО Orion soft провел исследование готовности ИТ-инфраструктуры бизнеса к растущим темпам скорости разработки. Вендор опросил 107 респондентов-представителей крупного и среднего бизнеса из отраслей: нефтегазовая и химическая промышленность, финансы, металлургия, госсектор, торговля, энергетика и машиностроение.</p> <p>ИИ-ассистенты сегодня уже помогают писать код, генерировать тесты и готовить документацию значительно быстрее. Gartner прогнозирует, что к 2028 году 90% крупных компаний-разработчиков ПО будут использовать в работе искусственный интеллект по сравнению с 14% в 2024. При этом, исследование Orion soft показывает, что вывод продуктов на рынок (Time-To-Market) не ускоряется в соответствии с ростом темпов разработки — в двух из трех случаях его тормозит инфраструктура. 65% респондентов назвали главными факторами задержки задачи, не связанные с разработкой: согласование ИБ, ручная настройка, тестирование, ожидание окружения или ресурсов.</p> <p>Почти половина всех препятствий связана с информационной безопасностью — фактор назвали 47% опрошенных. Отсутствие стандартизации, согласованных шаблонов и описанных конкретных правил действий для разработчиков приводит к увеличению Time-To-Market. Другая важная проблема — ожидание ресурсов. 78% респондентов ожидают среду для разработки более одного рабочего дня после запроса. За это время разработчики могли бы сделать бОльшую часть работы с помощью ИИ-ассистентов и быстрее реализовать проект.</p> <p>Результаты исследования демонстрируют эволюционный разрыв между разработкой и ИТ-инфраструктурой. Финансовый масштаб этого разрыва особенно заметен на фоне инвестиций в цифровизацию. По данным ИСИЭЗ НИУ ВШЭ, подготовленным на базе сплошного обследования Росстата, в 2025 году крупные и средние российские организации направили на внедрение и использование цифровых технологий почти 5,9 трлн рублей. 37% этой суммы — около 2,2 трлн рублей — пришлось на программное обеспечение: лицензии, SaaS, разработку, доработку и адаптацию. При этом 86,6% расходов компании профинансировали собственными средствами. Поэтому ожидание инфраструктуры, ручная настройка и повторные согласования ИБ снижают отдачу не от абстрактного «ИТ-бюджета», а от уже оплаченных бизнесом инструментов и компетенций.</p> <p>В ответ на эту тенденцию на международном ИТ-рынке растет популярность платформенного инжиниринга — подход, которые помогает автоматизировать и стандартизировать процессы в инфраструктуре. Gartner также прогнозирует, что к текущему году 80% крупнейших мировых разработчиков ПО создадут отдельные команды для управления платформами, которые возьмут на себя сервисную функцию поставщиков инструментов для разработки. Быстрая выдача нужных ресурсов, готовые шаблоны, согласованные с политиками безопасности ресурсы и доступы — все это в совокупности с ИИ-ассистентами позволяет получить бизнесу конкурентное преимущество с ускорением Time-To-Market.</p> <p>«Платформенный инжиниринг — это не очередная попытка внедрить еще один инструмент. Это способ вернуть управляемость там, где инфраструктура, DevOps-процессы, требования ИБ и скорость бизнеса уже стали слишком сложными для ручного управления. Наши выводы подтверждают, что все больше крупных компаний нуждаются в IDP-подходе. Его главная ценность — скорость изменений становится не результатом героизма отдельных специалистов, а свойством всей инженерной системы», — отметил Павел Лавров, лидер продукта HyperDrive в Orion soft.</p> Разработчик экосистемы инфраструктурного ПО Orion soft провел исследование готовности ИТ-инфраструктуры бизнеса … message https://www.itweek.ru/themes/detail.php?ID=235549 Wed, 16 Sep 2026 10:07:03 +0300 <p><em>Как и мы, вы, вероятно, заметили, что за последние два года большинство дискуссий об искусственном интеллекте в промышленном производстве были сосредоточены на том, что большие языковые модели (LLM) могут сделать для инженеров, планировщиков и других специалистов умственного труда, пишут в корпоративном блоге вице-президенты, главные аналитики </em><em>Forrester</em> <em>Джордж Лоури и Мишель Пелино.</em></p> <p>Поставщики демонстрировали «вторых пилотов», которые обобщают документы, отвечают на вопросы и генерируют контент. Эти возможности важны, но, возможно, именно они в конечном итоге не обеспечат наибольшего влияния на бизнес производителей.</p> <p>В предыдущих исследованиях мы изучали важность для операционной устойчивости анализа с низкой задержкой и быстрого реагирования. Но теперь у нас есть новые цифровые промышленные платформы и развертывания ИИ, сочетающие промышленную автоматизацию, агентный ИИ и архитектуры, учитывающие особенности периферии.</p> <p>Наше текущее исследование передовых технологий ИИ в производстве начинается с простой гипотезы: производители создадут больше ценности, если ИИ будет непосредственно участвовать в циклах принятия оперативных решений, чем когда он будет использоваться в основном для поиска информации и генерации контента. Сами по себе модели не создают результатов. Реальная ценность заключается в рабочих процессах, управлении и возможностях выполнения, которые они обеспечивают. Для достижения этих результатов в масштабе производителям необходимы платформы, которые связывают ИИ с выполнением операционных задач.</p> <h3>Следующее поле битвы — гемба: почему промышленный ИИ должен сместиться на периферию</h3> <p>Специалисты по бережливому производству используют термин «гемба» для описания места, где создается ценность. Для производителей это означает производственные линии или ячейки, склады, ремонтные мастерские, логистические центры и сервисные центры. Именно здесь производители диагностируют отказы оборудования, сокращают риски или исключения, связанные с качеством, безопасностью и соответствием нормативным требованиям, корректируют производственные графики, определяют приоритеты технического обслуживания, управляют перебоями в поставках и координируют действия сервисных служб. Они принимают эти решения постоянно и в условиях нехватки времени. Специалист по техническому обслуживанию, устраняющий неполадки в критически важном оборудовании, руководитель, реагирующий на проблему качества, или планировщик, управляющий сбоем в производстве, не всегда могут позволить себе задержки в облаке, зависимости от подключения или длительные циклы обработки. Для них скорость, контекст, отказоустойчивость и доверие часто важнее масштаба модели.</p> <h3>Бóльшие модели не всегда лучше: переход от периферийной аналитики к периферийному интеллекту</h3> <p>В индустрии ИИ обращают много внимания на мощные передовые модели. Однако в производственных сценариях основное внимание часто уделяется переменным, которые модели упускают из виду, — таким факторам, как предсказуемое время отклика, операционная устойчивость или экономическая эффективность. Именно поэтому производители, как правило, внедряют передовые модели ИИ в рамках более широкой архитектуры, а не рассматривают их как универсальное решение. </p> <p>#IMAGE_235550#</p> <p>Формирующийся шаблон напоминает иерархию интеллекта:</p> <ul> <li> Передовые модели обеспечивают рассуждения, планирование и координацию.</li> <li> Специализированные промышленные модели предоставляют экспертные знания в области производства.</li> <li> Более мелкие модели, работающие на периферии, обеспечивают быструю локальную поддержку принятия решений (например, в вопросах технического обслуживания и безопасности).</li> <li> Механизмы оптимизации обеспечивают соблюдение инженерных, операционных и бизнес-ограничений.</li> </ul> <p>Фабрика будущего будет полагаться на множество форм интеллекта, работающих вместе, а не на одну доминирующую модель ИИ.</p> Как и мы, вы, вероятно, заметили, что за последние два года большинство дискуссий об искусственном интеллекте … article https://www.itweek.ru/themes/detail.php?ID=235546 Wed, 16 Sep 2026 09:56:46 +0300 <p><em>Кроссплатформенная разработка привлекает прежде всего скоростью запуска и экономией на старте. Через год-два те же проекты нередко требуют серьёзной переработки архитектуры. Рассмотрим, где закладывается технический долг в проектах на Flutter и KMP, по каким признакам понять, что проект теряет выгоду от кроссплатформенности, и как оценить риски до начала разработки.</em></p> <h3>Почему технический долг появляется не сразу</h3> <p>Проекты на Flutter и KMP часто выглядят успешно на старте: единая кодовая база, быстрые итерации, предсказуемая стоимость разработки. Архитектурные проблемы проявляются, как правило, позже — когда продукт начинает развиваться за рамками первоначального замысла.</p> <p>Именно тогда становится видна реальная структура расходов. Основные затраты возникают не во время разработки MVP, а в процессе развития приложения в течение нескольких лет. Добавление новых функций требует всё больше времени, количество платформенных исключений растёт, а изменения приходится вносить сразу в несколько частей системы. Именно поэтому оценивать выбор технологии только по стоимости запуска — значит не видеть большую часть картины.</p> <h3>Где возникает технический долг во Flutter-проектах</h3> <p>В проектах на Flutter технический долг обычно появляется там, где команда недооценила будущие платформенные интеграции. Пока приложение развивается в рамках заранее продуманной архитектуры, Flutter остаётся устойчивым решением. Проблемы начинаются, когда объём платформенной логики начинает расти быстрее, чем предполагалось на старте.</p> <p>Типичный сценарий: продукт запускается с простой архитектурой, потому что на старте это выглядит достаточным. Через год появляются сложные интеграции с нативными сервисами — камерой, геолокацией, биометрией, платёжными системами. Каждая такая интеграция добавляет платформенный слой, который нужно поддерживать отдельно. В итоге команда платит и за кроссплатформенную сложность, и за нативную сложность одновременно — то есть теряет главное преимущество Flutter.</p> <p>Вторая распространённая ошибка — строить архитектуру как временную, хотя продукт планируется развивать годами. «Сейчас сделаем быстро, потом перепишем» — это решение, которое почти никогда не реализуется. На быструю архитектуру начинают опираться другие части системы, и стоимость её переработки со временем только растёт.</p> <h3>Где возникает технический долг в KMP-проектах</h3> <p>В проектах на Kotlin Multiplatform основным источником технического долга обычно становятся неверно определённые границы между общей и платформенной логикой. Чем раньше допущена такая ошибка, тем дороже обходится исправление.</p> <p>Выглядит она почти всегда одинаково: команда стремится вынести в общий код максимально возможный объём логики. На старте это выглядит разумно — высокая доля переиспользования, меньше дублирования. По мере развития продукта начинают появляться платформенные особенности и исключения, которые не укладываются в эту схему. Каждое такое исключение добавляет сложность в общий модуль, и через некоторое время поддержка кроссплатформенной архитектуры становится дороже, чем выгода от неё.</p> <p>Избежать этого помогает один простой вопрос при проектировании каждого модуля: зависит ли эта логика от особенностей конкретной платформы? Если нет — кандидат на перенос в общий код. Если да — лучше оставить на платформенном уровне. Попытка перенести то, что по своей природе платформенное, неизбежно ведёт к усложнению системы.</p> <h3>Три сигнала, что проект теряет выгоду от кроссплатформенности</h3> <p>Первый сигнал — количество платформенных исключений начинает расти быстрее, чем объём общего кода. Команда всё чаще пишет отдельные реализации для iOS и Android, а общий слой перестаёт давать прежнюю экономию. Если раньше новая функция появлялась в общем модуле один раз, теперь приходится писать версию для каждой платформы отдельно.</p> <p>Второй сигнал — появление отдельных веток поведения для разных платформ. Формально приложение остаётся кроссплатформенным, но фактически развивается как два независимых продукта с общим именем. Это самый явный признак того, что первоначальный архитектурный выбор перестал соответствовать реальной структуре продукта.</p> <p>Третий сигнал — снижение скорости разработки. Если каждая новая функция требует всё больше согласований между слоями системы и всё чаще затрагивает платформенные особенности — первоначальная выгода от общего кода начинает сокращаться. Команда тратит больше времени на координацию, чем экономит на переиспользовании.</p> <h3>Как оценить риски до начала разработки</h3> <p>Технический долг закладывается в момент выбора архитектуры. Команда, которая изначально правильно определила границы применения технологии, получает меньше долга — вне зависимости от того, Flutter это или KMP.</p> <p>До начала разработки стоит ответить на несколько вопросов. Как часто будет меняться бизнес-логика? Чем выше частота изменений, тем важнее, чтобы архитектура позволяла вносить их быстро. Насколько отличаются сценарии между платформами? Чем сильнее различия, тем меньше смысла в общем коде. Какие интеграции появятся через год-два? Сложные нативные интеграции на старте не видны, но именно они чаще всего становятся источником технического долга.</p> <p>Подводя итог, можно отметить следующее: кроссплатформенный подход меняет структуру затрат, но не отменяет архитектурную сложность. Подготовленный на старте анализ жизненного цикла продукта позволяет увидеть большую часть будущих проблем — и заложить в архитектуру решение заранее, а не разбираться с ним после релиза.</p> <p>#IMAGE_235547#</p> Кроссплатформенная разработка привлекает прежде всего скоростью запуска и экономией на старте. Через год-два те же … article Алексей Артамонов, директор Nord Clan https://www.itweek.ru/themes/detail.php?ID=235544 Wed, 16 Sep 2026 09:50:45 +0300 <p><em>За последние четыре года многие российские компании перевели часть ИТ-инфраструктуры на отечественное оборудование и программное обеспечение. Но значительный объём зарубежных решений по-прежнему остаётся в эксплуатации. Их поддержка становится сложнее и дороже: всё большее значение приобретают доступность запасных частей, логистика и инженерная экспертиза сервисных команд. Главный вопрос теперь не в том, сколько лет системе, а в том, можно ли обеспечить её дальнейшую эксплуатацию без участия производителя. Рассмотрим, где проходит эта граница и что может стать для рынка точкой невозврата.</em></p> <h3>Возраст не проблема: что действительно волнует бизнес</h3> <p>За последние годы возраст оборудования перестал быть ключевым фактором для бизнеса. Срок эксплуатации зарубежных ИТ-решений у заказчиков вырос и в среднем составляет более 5 лет. Высокотехнологичное оборудование может работать в парке организаций даже десятилетиями — такая практика постепенно становится новой нормой. Для многих компаний такие системы остаются критически важными: они глубоко интегрированы в инфраструктуру, а их замена требует значительных инвестиций и сложной миграции. При формировании бюджетов специалисты учитывают срок гарантии оборудования, историю инцидентов и совокупную стоимость технической поддержки.</p> <p>При продолжительной эксплуатации зарубежного оборудования компаниям необходимо заранее оценивать доступность запасных частей и потенциальные расходы в случае критических отказов. Современные системы мониторинга позволяют отслеживать состояние инфраструктуры, выявлять её узкие места и своевременно реагировать на признаки неисправностей. Поэтому главным ограничением становится уже не обслуживание зарубежных решений как таковое, а наличие сервисных организаций с необходимой технической экспертизой.</p> <h3>Комплексный подход: как и с кем работает бизнес</h3> <p>Отдавать критически важную инфраструктуру на обслуживание одной организации готовы далеко не все. Как правило, крупные компании распределяют задачи между собственной службой поддержки и несколькими внешними подрядчиками. В исследовании OCS 80% участников отметили, что имеют собственную службу поддержки, однако её возможностей зачастую недостаточно для решения всех сервисных задач.</p> <p>Одновременно меняются и модели взаимодействия с внешними исполнителями. Вместо фиксированной оплаты по договору компании проявляют интерес к более гибким вариантам: 34% респондентов рассматривают платежи за конкретный кейс, а 44% склоняются к смешанной модели работы. Опрос показал, что требования к сервисным партнёрам возросли и в отдельных случаях оказываются строже, чем требования к сервису ушедших мировых производителей. Компании стремятся снизить возможные риски ещё на этапе выбора подрядчика. Одним из критериев становится наличие и состав склада ЗИП: его аудит всё чаще включают в техническое задание. Далеко не все запчасти для технологически сложных решений можно оперативно доставить в Россию, а их отсутствие в критический момент приводит к простоям и убыткам.</p> <p>Не менее важен региональный охват сервисной компании. Для оперативного реагирования на инциденты по всей России подрядчику необходима территориально распределённая команда, способная обеспечить требуемые сроки обслуживания в разных регионах. Региональный охват и склады ЗИП входят в число важнейших факторов при выборе сервисной организации для 60% компаний. При этом главным критерием остаётся инженерная экспертиза. Для каждой четвёртой компании опыт и квалификация подрядчика приоритетнее цены на его услуги.</p> <h3>Компетенции: риски и перспективы</h3> <p>Квалификация сервисных специалистов — один из важнейших факторов устойчивости отрасли. Раньше ведущие мировые производители регулярно проводили для российских инженеров обучение по своим решениям, но после 2022 года такие программы существенно сократились. В результате развитие инженерных компетенций всё больше зависит от ресурсов самих участников рынка. Даже если штат укомплектован специалистами, новые сотрудники могут потребоваться для расширения сервисной сети в условиях растущего спроса. Запчасти можно закупить и оперативно разместить на складе, а подготовка специалистов с необходимой квалификацией занимает годы. Дополнительную сложность создаёт быстрое развитие технологий: на мировом рынке появляются новые поколения оборудования, тогда как доступ российских инженеров к обучению по зарубежным решениям остаётся ограниченным.</p> <p>Значительная часть задач по сохранению и развитию технической экспертизы постепенно переходит к крупным дистрибьюторам, интеграторам и сервисным компаниям. Такие игроки десятилетиями развивали технические команды и собственные базы знаний. Обладая большим опытом работы с зарубежным оборудованием, они могут передавать накопленную экспертизу партнёрам и использовать её при работе — в том числе с российскими решениями. При этом подготовка нового поколения инженеров остаётся долгосрочной задачей для всей отрасли. Без системной передачи знаний рынок со временем может столкнуться с дефицитом специалистов, способных обслуживать высокотехнологичное оборудование. Именно кадровый фактор в перспективе может стать главным ограничением для поддержки зарубежных решений.</p> <h3>Главный ресурс рынка</h3> <p>За последние годы российский рынок сервисного обслуживания адаптировался к работе без прямой поддержки части зарубежных производителей. Компании заранее планируют бюджеты на обслуживание, ответственнее выбирают подрядчиков, оценивают наличие запасных частей и используют системы мониторинга для контроля состояния инфраструктуры.</p> <p>Однако дальнейшая устойчивость рынка зависит не только от доступности оборудования и комплектующих. Ключевым ресурсом становится инженерная экспертиза и способность отрасли сохранять и передавать накопленные знания. Если рынок сможет обеспечить воспроизводство этих компетенций, обслуживание зарубежной ИТ-инфраструктуры ещё долго останется технически выполнимой задачей. Поэтому главным активом сервисных компаний сегодня становятся не только склады запасных частей и отлаженные процессы, но прежде всего специалисты и накопленная ими экспертиза.</p> <p>#IMAGE_235545#</p> За последние четыре года многие российские компании перевели часть ИТ-инфраструктуры на отечественное оборудование … article Никита Кузнецов, руководитель отдела сервиса профессиональных систем OCS https://www.itweek.ru/themes/detail.php?ID=235543 Tue, 15 Sep 2026 13:38:49 +0300 <p>Компания IT_ONE создала собственную методологию для выбора ИИ-инструментов и управления ими на всех этапах жизненного цикла разработки ПО (SDLC, Software Development Life Cycle). Решение позволяет систематизировать использование ИИ-моделей и повысить производительность команды разработки на <nobr>30-40%.</nobr></p> <p>Внедрение ИИ-инструментов в процессы разработки в большинстве компаний происходит стихийно: либо инициативу проявляют отдельные специалисты, либо решение централизованно «спускается сверху» и используется сотрудниками с разной степенью успешности. Чтобы выйти на принципиально новый уровень применения ИИ на всех этапах SDLC, специалисты IT_ONE создали комплексный фреймворк.</p> <p>Методология включает в себя пять ключевых этапов: декомпозицию SDLC на этапы (аналитика, разработка, тестирование, развертывание, стабилизация) и активности внутри этих этапов, оценку применимости ИИ для каждой задачи, описание системы навыков ИИ (скиллов), валидаций и ограничений, измерение эффективности, создание стандартизированных инструкций.</p> <p>Таким образом, фреймворк дает команде разработки полное и четкое представление о том, как применять ИИ в рамках той или иной активности и позволяет спрогнозировать результат действия модели и ее эффективность.</p> <p>«Мы проанализировали публичные методологии и гайды вендоров и не нашли готового решения такого типа — связующего слоя, который для каждой активности SDLC определяет, какой ИИ-инструмент применять, как валидировать результат, как контролировать риски и сколько это экономит трудозатрат. Поэтому мы построили такой фреймворк сами — как воспроизводимую методологию, а не закрытый внутренний регламент», — прокомментировал Кирилл Хрушков, CIO компании IT_ONE.</p> <p>Одно из главных преимуществ фреймворка — воспроизводимость. Он спроектирован как онбординг-инструмент: новый сотрудник проходит по гайду, получает предсказуемый результат и ожидаемый уровень эффективности.</p> <p>Внедрение фреймворка позволило компании IT_ONE повысить производительность команды разработки на <nobr>30-40 %.</nobr> Кроме того, методология способствует сохранению высокого качества кода при ускорении его создания и упрощению адаптации новых сотрудников.</p> <p>Применение фреймворка не зависит от конкретных вендоров ИИ-моделей и предусматривает подбор наиболее подходящих ИИ-инструментов с учетом выхода новых версий.</p> Компания IT_ONE создала собственную методологию для выбора ИИ-инструментов и управления ими на всех этапах жизненного … message https://www.itweek.ru/themes/detail.php?ID=235542 Tue, 15 Sep 2026 09:45:16 +0300 <p><em>Рекурсивное самосовершенствование (</em><em>recursive</em> <em>self</em><em>-</em><em>improvement</em><em>, </em><em>RSI</em><em>) </em><em>позиционируется как следующая важная веха в развитии искусственного интеллекта. Если оно когда-либо будет достигнуто, его влияние будет ощущаться во всей индустрии центров обработки данных и далеко за её пределами, считают опрошенные порталом </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>эксперты.</em></p> <p>RSI описывает системы ИИ, которые могут проектировать, кодировать и развертывать своих преемников с минимальным участием человека. В случае его достижения улучшения могут быстро накапливаться, поскольку более интеллектуальные модели порождают ещё более интеллектуальные поколения — потенциально ускоряясь за пределы человеческого понимания и, что вызывает беспокойство, контроля. Для операторов дата-центров RSI будет иметь последствия в плане электропитания, охлаждения, оркестрации, управления и сертификации.</p> <h3>Что такое RSI и куда оно движется</h3> <p>Хотя RSI имеет расплывчатое определение, как и общий искусственный интеллект (AGI), есть признаки того, что оно приближается к реальности. Достижение RSI зависит от быстрого прогресса в кодировании с помощью ИИ, который, по словам лабораторий, уже наблюдается. Например, компания Anthropic, занимающаяся разработкой передовых моделей ИИ, в своем <a href="https://www.anthropic.com/institute/recursive-self-improvement">отчете</a> под названием «When AI Builds Itself» утверждает, что ее модель Claude теперь сама пишет значительную часть своего кода: «По состоянию на май 2026 г. более 80% кода, который мы объединяем с кодовой базой Anthropic, был написан Claude. До запуска Claude Code в режиме предварительного тестирования в феврале 2025 г. эта цифра составляла несколько процентов». Если такая поддержка сохранится, это станет шагом к созданию систем, способных к самосовершенствованию.</p> <p>Что касается аппаратной части, то такие прорывы, как квантовые вычисления, могут катализировать кардинальные изменения в RSI или AGI. «В мире рекурсивного ИИ это, по сути, задача оптимизации. Какой ИИ является лучшим? Какая нейронная сеть для моделей ИИ станет лучшей в будущем? Квантовые вычисления могут помочь в этом, — говорит Джей Гилмарт, ведущий менеджер по продуктам компании Q-CTRL. — Существует алгоритм, называемый алгоритмом Гровера, который очень хорошо справляется с поиском в пространствах с большим количеством параметров. Он может поддерживать рекурсивные операции, чтобы помочь системе работать лучше и быстрее выбирать наилучший вариант».</p> <p>Если ИИ сможет на постоянной основе создавать улучшенные версии самого себя, последствия для физической инфраструктуры будут немедленны. Что это означает для жизненных циклов ИТ-оборудования, энергопотребления, управления рабочими нагрузками и того, как мы проектируем и эксплуатируем дата-центры?</p> <p>«Сама по себе основная концепция самосовершенствующихся систем не нова, — говорит Джон О’Брайен, старший аналитик Uptime Institute. — Сейчас ситуация отличается тем, что... достижения в моделях и инфраструктуре ИИ позволяют предположить, что мы достигли точки, когда некоторые из этих теоретических рассуждений становятся технически осуществимыми — или скоро станут таковыми».</p> <p>Практический подход к RSI отличает системы, которые действительно создают и развертывают новый код, от тех, которые постоянно самооптимизируются, не переписывая себя. Последние уже появляются в дата-центрах, часто с использованием обучения с подкреплением (RL). «Успешные приложения ИИ в центрах обработки данных сегодня часто применяют RL, хорошо зарекомендовавшую себя технику машинного обучения, которая использует штрафы и вознаграждения на основе обратной связи от окружающей среды, — говорит О’Брайен. — Это может хорошо работать в замкнутых системах, где параметры определены, например, охлаждение дата-центра, ИТ и электропитание».</p> <p>Системы, способные к самосовершенствованию на месте, уже появляются. «Стартапы Emerald AI и Phaidra совершают прорывы в ранних пилотных проектах и ​​демонстрациях, показывая потенциал динамических самосовершенствующихся систем», — добавляет О’Брайен.</p> <p>Автономные улучшения, особенно в энергопотреблении, являются целью новой волны программных платформ для управления дата-центрами, соглашается старший аналитик 451 Research Зои Рот. «Такие игроки, как Phaidra, etalytics и Vigilent, уже доказывают, что ИИ с замкнутым контуром может непрерывно оптимизировать физические параметры объекта в режиме реального времени, — говорит она. — Современные ИИ-механизмы, такие как Phaidra, выступают в качестве автономных уровней управления поверх существующих систем охлаждения (системы управления зданием, BMS) и электропитания (системы управления электропитанием, EPMS). Они не переписывают собственный код, но переобучают и обновляют нейронные сети на основе телеметрии датчиков реального времени».</p> <h3>Влияние на центры обработки данных</h3> <p>Для операторов ЦОДов самооптимизация обещает ощутимые преимущества в мониторинге и техническом обслуживании. «Сегодня для технического обслуживания на основе состояния требуется значительный исторический набор данных, прежде чем можно будет с уверенностью определить риск возникновения неисправностей, — говорит Алекс Кордовил, директор по исследованиям Dell’Oro. — Система, которая улучшает свой собственный опыт работы, может обеспечить это гораздо быстрее и эффективнее, с реальным увеличением времени безотказной работы и производительности».</p> <p>Но это поднимает сложный вопрос: как сертифицировать ПО, которое постоянно меняется? «Я не понимаю, как сертифицировать программный пакет или агент ИИ, который признан способным выполнять обязанности по управлению дата-центром и который вы должны контролировать», — говорит Кордовил. На практике это может потребовать постоянного повторного утверждения моделей или непрерывного мониторинга и контроля отката, при котором в процесс вовлечены люди, что снижает некоторые преимущества в плане эффективности.</p> <p>Самосовершенствующийся ИИ, переключающийся между обучением и инференсом, может также усугубить и без того значительные колебания энергопотребления в дата-центрах, обслуживающих ИИ-нагрузки. «Постоянное синхронное обучение совершенно не похоже на инференс: большие парки устройств синхронно колеблются между почти холостым и почти пиковым режимами, потребляя от десятков до сотен мегаватт с частотой в доли герца», — отмечает Кордовил. — Постоянным требованием при проектировании станет парк, который одновременно занимается обучением и инференсом, а не проблема кластеров для обучения«.</p> <h3>Стратегические перспективы и влияние на отрасль</h3> <p>Помимо краткосрочных проектных решений, RSI может изменить динамику отрасли. «Системы, которые могут программировать и проектировать своих преемников, будут иметь огромные последствия для тех, кто проектирует, строит и производит инфраструктуру дата-центров, — считает О’Брайен. — Захотят ли они автоматизировать половину своей рабочей силы? Как это повлияет на их бизнес?»</p> <p>Пока что концепция RSI остается на начальной стадии развития. Но если она когда-нибудь будет реализована, последствия — как положительные, так и отрицательные — выйдут далеко за рамки самих моделей, изменив весь стек ИИ и оказав влияние на общество. Один из правдоподобных сценариев предполагает, что ИИ не только будет создавать более мощных преемников, но и проектировать и даже изготавливать дата-центры, которые будут их размещать. В этом случае самооптимизирующиеся и самовоспроизводящиеся центры обработки данных для ИИ столкнутся с трудностями в регулировании, сертификации, обеспечении безопасности и общественном признании. Расширение ИИ уже сейчас кажется слишком быстрым для многих сообществ; RSI может еще больше ускорить этот процесс.</p> Рекурсивное самосовершенствование (recursive self-improvement, RSI) позиционируется как следующая важная веха в развитии … article https://www.itweek.ru/themes/detail.php?ID=235539 Tue, 15 Sep 2026 00:00:00 +0300 <p>Вступление в силу приказа ФСТЭК России № 117 весной 2026 года ознаменовало тихую революцию в требованиях к защите государственных информационных систем (ГИС), ресурсов органов государственной власти и всех субъектов, подпадающих под регулирование ФСТЭК. Ведомство изменило концепцию контроля подключения пользователя, на которой строилась безопасность в госсекторе последние двадцать лет. Привычная модель, где защищенный канал и контроль сетевого подключения считались основой доверия, теперь признана недостаточной. Сетевой адрес при этом остается одним из параметров контроля, но сам по себе не позволяет достоверно установить физическое местоположение пользователя.</p> <p>И это лишь половина проблемы. Оператор ГИС обязан не только устанавливать реальное местоположение того, кто подключается, но и лично отвечать за реализацию всех мер защиты. Переложить эту обязанность на аутсорсера, прописать в договоре с удаленным сотрудником или передать подрядчику невозможно. Ответственность неделима и остается на владельце системы. Для ИБ-директоров госструктур и операторов ГИС это означает, что привычная связка VPN и терминального сервера больше не закрывает риски регулятора и бизнеса.</p> <h3>Архитектурный тупик: почему классическая защита больше не работает</h3> <p>До сих пор защита удаленного периметра в государственных учреждениях создавалась по классической схеме: построить шифрованный VPN-туннель, запросить второй фактор (2FA) и проверить IP-адрес подсети. Если трафик идет из условного пула российских провайдеров, то система считает точку подключения доверенной.</p> <p>Приказ № 117 разрушает эту цепочку. Требование осуществлять удаленный доступ к государственным информационным системам через сети связи, расположенные на территории РФ, с использованием выделенных оператором программно-аппаратных средств и защищенных каналов передачи данных высветило главную уязвимость сетевого уровня. Это — ограниченная достоверность GeoIP-идентификации для допуска к работе.</p> <p>В современных реалиях IP-адрес может указывать физическое местонахождение пользователя лишь косвенно и с большим количеством допущений. Коммерческие и частные VPN-сервисы легко пробрасывают трафик из любой точки мира через точки присутствия внутри РФ. Промежуточные терминальные узлы и VPS/VDS позволяют развернуть прокси-сервер на российском хостинге за 15 минут, маскируя работу из зарубежных юрисдикций.</p> <p>В результате ИБ-служба ведомства видит легитимный IP-адрес провайдера, тогда как фактически сессия администратора или подрядчика может быть инициирована где-то в другой стране или незащищенной публичной Wi-Fi-сети. В сегментах с информацией ограниченного распространения, включая сведения «Для служебного пользования» (ДСП), подобная слепая зона превращается в прямую угрозу безопасности и критический регуляторный риск.</p> <p>Но этим проблема не исчерпывается. Операторы ГИС фактически встают перед архитектурной дилеммой. Первый путь — строить полноценный узел связи и доступа к ГИС, разворачивая контролируемую зону с собственной инфраструктурой геоконтроля, что неизбежно ведет к кратному росту капитальных и эксплуатационных затрат. Второй — оснастить контроллерами рабочее место каждого удаленного сотрудника, создавая распределенную систему контроля физического местоположения. Оба варианта требуют серьезных финансовых вложений, организационной перестройки процессов и пересмотра всей логики построения защищенного удаленного доступа. При этом выбрать какой-то один из них, не имея четких методических рекомендаций регулятора, — рискованно, а не выбрать вообще — невозможно.</p> <h3>От защиты канала к защите конечной точки</h3> <p>Попытки выстроить гео-контроль на стороне ведомственной сети являются борьбой с последствиями, а не причиной. Рабочий способ достоверно выполнить нормативные акты ФСТЭК России — это перенести вектор контроля непосредственно на конечное устройство доступа.</p> <p>Новая модель безопасности перераспределяет доверие. Если раньше проверялся канал, то теперь проверяется контекст среды:</p> <ol> <li> <strong>Где физически находится устройство?</strong> Использование комбинированных аппаратных и программных механизмов определения местоположения устройства позволяет получать дополнительные данные о фактической точке подключения и сопоставлять их с сетевыми параметрами соединения. Это снижает зависимость контроля местоположения от одного только IP-адреса и связанных с ним механизмов GeoIP.</li> <li> <strong>Что это за устройство?</strong> Переход к модели доверенного цифрового рабочего места исключает использование несанкционированных личных ноутбуков и рабочих станций для доступа к защищаемым ресурсам. Устройство, с которого устанавливается соединение, должно соответствовать установленным требованиям защиты и контролироваться оператором информационной системы.</li> <li> <strong>Не изменены ли настройки безопасности?</strong> Непрерывный мониторинг целостности прошивки, операционной системы и сетевого окружения осуществляется прямо во время сессии.</li> </ol> <h3>Проблема внешнего контура: почему сторонний ноутбук может быть опасен</h3> <p>Развитие крупных федеральных ИТ-проектов создало сложные экосистемы, которые объединяют интеграторов, разработчиков ПО, сервисные организации и специализированных подрядчиков. Выдача традиционного VPN-доступа к ГИС на сторонний ноутбук создает неуправляемый вектор атаки по нескольким причинам.</p> <p>Во-первых, использование портативного компьютера подрядчика для удаленного доступа требует согласно приказу ФСТЭК № 117 соблюдения установленных требований к защите конечного устройства, включая наличие антивирусной защиты. При этом после установления защищенного туннеля такое устройство получает доступ во внутренний контур государственного ведомства, что повышает требования к контролю состояния и защищенности конечной точки.</p> <p>Во-вторых, ИБ-служба госоргана не обладает административными полномочиями на устройстве подрядчика. Она не может форсировать установку обновлений операционной системы, контролировать наличие агентов EDR, блокировать стороннее ПО или запрещать использование отчуждаемых носителей.</p> <p>В-третьих, стороннее устройство может одновременно поддерживать активный туннель в государственную информационную систему и иметь открытый доступ в незащищенный интернет или локальную сеть подрядчика.</p> <p>Масштаб этой угрозы подтверждают данные центра исследования киберинцидентов <a href="https://bi.zone/news/pochti-tret-atak-s-shifrovaniem-proiskhodit-iz-za-nezashchishchennykh-podryadchikov/" target="_blank">BI.ZONE DFIR</a>. В 2025 году доля атак с компрометацией инфраструктуры или уничтожением данных через неконтролируемых подрядчиков и цепочки поставок выросла вдвое — с 15% до почти 30% от всех зафиксированных расследований. А согласно исследованию <a href="https://ptsecurity.com/research/analytics/russia-cyberthreat-landscape-2026/" target="_blank">Positive Technologies</a>, компрометация доверенных отношений между организациями и подрядчиками стала главным драйвером атак на критическую инфраструктуру и госсектор.</p> <p>Решением этой коллизии для государственных структур становится переход к другому формату доступа. На смену попыткам изолировать программное обеспечение на чужом ПК приходят аппаратно-программные комплексы на базе специализированных тонких клиентов с преднастроенной и неизменяемой средой. Это дает возможность жестко зафиксировать конфигурацию аппаратного обеспечения, заблокировать попытки манипуляции сетевым стеком и снимать телеметрию геопозиционирования, не фальсифицируемую на уровне устройства доступа. В этой схеме подрядчик получает полностью изолированную от его локальной сети рабочую среду, а оператор ГИС и регулятор — 100%-ную прозрачность действий любого внешнего пользователя.</p> <h3>Что делать операторам ГИС?</h3> <p>Приказ ФСТЭК России № 117 — это не временная формальность, а отражение долгосрочного тренда на построение архитектуры «нулевого доверия» (Zero Trust) для всех государственных структур, ведомств и организаций, подпадающих под требования регулятора. Чтобы привести системы в соответствие с новыми нормами без остановки операционных процессов, операторам ГИС рекомендуется сделать три шага:</p> <ol> <li><strong>Провести аудит схем подключения внешних пользователей</strong>. Оценить реальную долю терминальных серверов и VPN-подключений, где идентификация строится только по IP-адресу.</li> <li><strong>Пересмотреть требования к рабочим местам подрядчиков</strong>. Включить в контракты обязательные условия по использованию доверенных устройств с контролируемым геопозиционированием.</li> <li><strong>Перейти на экосистемный подход к управлению конечными точками.</strong> Внедрять специализированные российские решения (тонкие клиенты, платформы централизованного управления), способные непрерывно подтверждать доверенность устройства и его локацию без усложнения администрирования.</li> </ol> <p>Эра, когда безопасность ГИС и государственной инфраструктуры гарантировалась защищенным соединением между двумя IP-адресами, прошла. Победу в новой реальности одержат те, кто первым научится контролировать не просто факт подключения, а конкретную физическую точку, в которой инициирован доступ к системе.</p> <p>#IMAGE_235540#</p> Вступление в силу приказа ФСТЭК России № 117 весной 2026 года ознаменовало тихую революцию в требованиях … article Василий Шубин, директор по управлению продуктовым портфелем компании Getmobit https://www.itweek.ru/themes/detail.php?ID=235537 Tue, 15 Sep 2026 00:00:00 +0300 <p><em>Low-code снижает технический порог создания приложений, но не отменяет профессиональную ответственность и потребность в ее распределении. К такому выводу приходят в крупных компаниях после первых пилотных проектов на выбранной платформе. Рассмотрим, как эффективная ролевая модель устраняет риски и превращает low-code в управляемый инструмент корпоративного развития.</em></p> <h3>Почему low-code не отменяет роли</h3> <p>На начальных этапах применения платформу low-code часто воспринимают как способ дать бизнес-подразделениям больше самостоятельности. Логика понятна: если инструменты стали проще, значит больше сотрудников могут участвовать в создании приложений, быстрее разрабатывая формы, интерфейсы, системы согласования и автоматизации. С точки зрения руководства решение дать операционным командам эту возможность выглядит обоснованным, ведь они лучше понимают бизнес-процессы, ИТ-служба перегружена другими задачами, а скорость изменений в компании очень важна.</p> <p>В ограниченном контуре такой подход действительно работает, но когда low-code превращается из эксперимента в часть корпоративной ИТ-среды, возникает вопрос: кто имеет право не просто «собрать приложение», а изменить бизнес-процесс, подключить данные, настроить интеграцию и опубликовать решение для пользователей, отвечая за последствия? В крупных компаниях применение low-code не может строиться по принципу «кто умеет, тот и делает». Чем больше сотрудников получают этот инструмент изменений, тем понятнее должны быть их права, ограничения и ответственность. В таких условиях возникает потребность в ролевой модели.</p> <p>Главное заблуждение о low-code — считать, что снижение технического порога автоматически смягчает требования к управлению. На практике происходит наоборот: зрелый контур low-code требует не меньшей дисциплины, чем классический ИТ-проект. Если реализовывать изменения могут не только профессиональные разработчики, но и аналитики, продвинутые пользователи, продуктовые команды, операционные подразделения и внешние подрядчики, то компании нужно еще точнее описать правила, иначе возникают серьезные риски.</p> <p>Первый риск — <strong>изменение процесса без владельца</strong>. Приложение может выглядеть как небольшая форма или рабочий процесс, но фактически менять порядок работы подразделения, согласования, доступ к данным или ответственность участников. </p> <p>Второй риск — <strong>подключение данных без понимания последствий</strong>. Пользователь может быстро собрать интерфейс, но не всегда понимает, какие данные можно использовать, где они должны храниться, кто имеет право их видеть и как фиксируется доступ.</p> <p>Третий риск — <strong>интеграции без архитектурного контроля</strong>. Low-code часто позволяет быстро связать решение с внешними системами, но если каждая команда делает это по-своему, компания получает сложный слой зависимостей, который трудно поддерживать и безопасно обновлять. </p> <p>Четвертый риск — <strong>публикация решений без готовности к эксплуатации</strong>. То, что приложение работает в рамках тестового сценария, еще не означает, что его можно использовать в промышленном контуре. Нужны дополнительные проверки, документация, поддержка, владелец, план изменений и прозрачная схема реагирования на инциденты.</p> <h3>Какие роли нужны в контуре low-code</h3> <p>Ролевая модель для работы с low-code не должна быть слишком сложной, но в ней должны быть зафиксированы основные участники и зоны ответственности. </p> <p>Первая роль — <strong>бизнес-владелец</strong>. Он отвечает за цель решения, процесс, эффект и приоритеты. Именно этот специалист должен объяснить, какую проблему решает приложение, какая у него будет аудитория, какие метрики должны измениться и что можно считать успешным результатом запуска. Бизнес-владелец не просто «заказывает форму», а отвечает за то, что изменение действительно принесет пользу процессу и получит одобрение пользователей.</p> <p>Вторая роль — <strong>аналитик или процессный эксперт</strong>. Он составляет требования на основе бизнес-задачи: описывает сценарии, исключения, роли пользователей, данные, правила согласования, ограничения и критерии приемки. При работе с low-code эта роль особенно важна, поскольку высокая скорость сборки может создать иллюзию, что требования можно не формализовывать. Однако если процесс плохо описан, приложение станет источником хаоса.</p> <p>Третья роль — <strong>low-code-разработчик</strong>. Это может быть профессиональный разработчик, аналитик с технической подготовкой или бизнес-пользователь в ограниченном контуре. Его зона ответственности — корректная реализация логики, интерфейсов, рабочих процессов, правил и интеграций в пределах разрешенных возможностей. Права low-code-разработчика должны зависеть от уровня зрелости и типа задач. Такой специалист может собирать внутренние формы по шаблону, но не должен самостоятельно подключать чувствительные данные или менять критичные процессы.</p> <p>Четвертая роль — <strong>архитектор</strong>. Он отвечает за место решения в ИТ-ландшафте и определяет, допустима ли выбранная архитектура, как решение связано с мастер-системами, какие интеграции применяются, где хранятся данные, какие компоненты можно повторно использовать и не создает ли приложение лишний технологический долг. Архитектор не должен вручную согласовывать каждую незначительную форму, но его участие обязательно при разработке решений с интеграциями, чувствительными данными, высокой критичностью или долгим жизненным циклом.</p> <p>Пятая роль — <strong>специалист по</strong> <strong>информационной безопасности</strong>. Он отвечает за распределение доступа, защиту данных, журналирование и контроль действий, соответствие требованиям и ограничения работы с чувствительной информацией. В контуре low-code важно заранее определить, какие типы данных можно использовать без отдельного согласования, какие типы данных требуют проверки, а какие вообще нельзя переносить или обрабатывать в тех или иных сценариях.</p> <p>Шестая роль — <strong>администратор платформы</strong>. Он управляет настройками, окружениями, пользователями, правами, версиями, обновлениями, доступностью, лицензиями и техническими ограничениями самой платформы. Без этой роли low-code легко превращается в набор разрозненных рабочих пространств без централизованного контроля.</p> <p>Седьмая роль — <strong>команда сопровождения</strong>. Она отвечает за эксплуатацию после запуска, включая работу с обращениями пользователей, инцидентами, изменениями и обновлениями. Также в зону ответственности команды входят проверки влияния новых версий платформы, документация и вывод решений из эксплуатации. Эту роль часто недооценивают, но многие low-code-приложения запускаются как быстрые проекты, а потом работают в компании годами. Если их сопровождение не описано, в будущем могут возникнуть дополнительные риски.</p> <h3>Принципы распределения прав</h3> <p>Нельзя предоставлять одинаковые возможности всем участникам работы с low-code. Ключевой принцип ролевой модели: права должны соответствовать уровню риска. Одно дело — создать экран или форму, а совсем другое — подключить корпоративную систему, изменить процесс согласования или опубликовать приложение для сотен пользователей. Разумно распределить роли в проекте позволит уровневая система прав доступа. Это поможет не замедлять решение простых задач и вместе с тем не внедрять критичные изменения без проверок.</p> <p>Первый уровень — <strong>просмотр и участие в процессе</strong>. В его рамках пользователь работает в готовом приложении, выполняет задачи, заполняет формы, получает уведомления, но не меняет логику. </p> <p>Второй уровень — <strong>настройка в пределах шаблонов</strong>. На нем продвинутый пользователь или аналитик может создавать простые формы, отчеты, справочники и рабочие процессы по утвержденным правилам и без доступа к критически важным данным. </p> <p>Третий уровень — <strong>разработка решений средней сложности</strong>. Сотрудники с такими правами могут работать с более сложными сценариями, бизнес-правилами и ограниченными интеграциями, но только с проверками архитектуры и безопасности.</p> <p>Четвертый уровень — <strong>промышленная разработка</strong>. На нем специалисты могут реализовывать решения с критически важными процессами, интеграциями, чувствительными данными, высокой нагрузкой или большим числом пользователей. В этом случае нужен полноценный проектный контур, охватывающий требования, архитектуру, информационную безопасность, тестирование, сопровождение и регламент изменений. </p> <p>Пятый уровень — <strong>администрирование платформы</strong>. Он включает в себя управление окружениями, политиками доступа, версиями, обновлениями, компонентами, лицензиями и техническими настройками. Такие права также должны быть ограничены и подвержены контролю.</p> <p>Отдельно следует описать права <strong>цифровых исполнителей</strong>. Это важное дополнение, если умные системы становятся фактическими участниками корпоративных рабочих процессов: могут их запускать, искать данные, готовить документы, создавать задачи, формировать ответы или редактировать записи в системе управления отношениями с клиентами (CRM). У ИИ-агента должны быть ограниченные права доступа к данным, четкий перечень допустимых действий, журналирование процессов, владельцы сценариев, возможность отключения и запрет на критически важные операции без подтверждения человека. Принцип простой: ИИ-агенту нельзя давать больше прав, чем компания дала бы человеку на аналогичной роли.</p> <p>Cледует зафиксировать в матрице прав, кто может описывать требования, подключать источники данных, настраивать интеграции, изменять бизнес-логику, управлять доступом, сопровождать системы и выполнять другие задачи в области low-code. Для каждой операции надо определить, кто ее выполняет, согласовывает, консультирует вовлеченных сотрудников и кто несет ответственность за результат. Такая матрица помогает избежать конфликта между бизнес- и ИТ-подразделениями.</p> <h3>Как использовать ролевую модель без лишней бюрократии</h3> <p>Ролевая модель не должна превращать разработку приложения на базе low-code в классический долгосрочный ИТ-проект. Применение ролей призвано не замедлить изменения, а сделать их более безопасными. Для этого полезно использовать рискориентированный подход: чем выше цена ошибки, тем строже контроль. Простые сценарии должны реализовываться по упрощенному маршруту с шаблонами, стандартными компонентами, минимальными согласованиями и быстрым запуском. Сценарии средней сложности должны проходить проверки в сферах работы с данными, интеграций, прав и сопровождения. Критически важные сценарии следует направлять в полноценный проектный контур. Такой подход позволяет сохранить главную ценность low-code — скорость — и одновременно избежать хаоса.</p> <p>Реализацию этой модели стоит начать с трех шагов:</p> <ol> <li> Описать основные роли и уровни прав.</li> <li> Составить матрицу прав: кто что может делать в контуре low-code.</li> <li> Привязать маршруты согласования к уровням риска разных задач.</li> </ol> <p>После такой подготовки применение low-code станет более прозрачным для всех участников. Сотрудники бизнес-подразделений будут понимать, где они вправе действовать самостоятельно. В ИТ-службе появится возможность отслеживать, на каких именно направлениях нужен контроль. Отдел информационной безопасности сможет подключаться к проектам не в конце, а на оптимальных этапах. Специалисты по сопровождению заранее получат данные о приложениях, которые попадут в эксплуатацию.</p> <p>Без хорошо организованного распределения прав и ответственности low-code может стать хаотичным набором инициатив, который ускоряет не только полезные изменения, но и накопление рисков. Проработанная ролевая модель превращает эту платформу в управляемый инструмент корпоративного развития. Он сохраняет скорость, но добавляет то, без чего крупный бизнес не может масштабировать изменения: ответственность, контроль и промышленную дисциплину.</p> <p> #IMAGE_235538#</p> Low-code снижает технический порог создания приложений, но не отменяет профессиональную ответственность … article Михаил Миронов, директор отделения low-code-решений IBS https://www.itweek.ru/themes/detail.php?ID=235535 Mon, 14 Sep 2026 16:22:21 +0300 <p>В России появилось собственное корпоративное хранилище бинарных артефактов — AppSec.Registry от вендора AppSec Solutions. Это критический элемент инфраструктуры разработки, который до сих пор оставался за иностранными продуктами: именно в артефактории хранятся все зависимости, сборки и Docker-образы, без которых не собирается ни одно современное приложение. Продукт спроектирован с учётом преемственности решений — команды переходят на него без переписывания CI/CD-скриптов и без потери накопленных данных.</p> <p>До сих пор большинство российских компаний применяли для этих задач бесплатные open-source-версии Однако с 2025 года на них были введены жесткие лимиты, а лицензии на коммерческую версию компаниям из России не продаются. AppSec.Registry позволяет разработке «переехать» в российскую систему из реестра отечественного ПО и снять риски замещения зарубежных решений, без потери в функционале.</p> <p>«Российский рынок сегодня — одна из главных целей атак через open-source-зависимости. Поэтому собственный артефакторий — базовое требование для любой организации. Как минимум он даёт единый „источник истины“, куда складываются все сборки и артефакты, как максимум — закрывает периметр безопасности», — отметил Данил Балавнев, руководитель продукта AppSec.Registry компании AppSec Solutions.</p> <p>Ключевые возможности AppSec.Registry:</p> <ul> <li>22 типа репозиториев — npm, Maven, PyPI, Docker, Helm, Cargo, Go, NuGet, Conda, HuggingFace, Git LFS, P2, Swift, Terraform и другие форматы, покрывающие разработку практически на любом языке программирования, включая хранение <nobr>ML-моделей;</nobr></li> <li>три модели работы репозиториев — Hosted (собственное хранение артефактов), Proxy (кэширующий шлюз к внешним публичным реестрам с локальным кешем, ускоряющим сборки) и Group (объединение нескольких репозиториев в единую точку доступа для команд);</li> <li>корпоративный функционал уровня Pro в базовой поставке — гибкая ролевая модель доступа, контент-селекторы, маршрутизация запросов, управление квотами, аудит действий, репликация данных, отказоустойчивый кластерный режим (HA), импорт и экспорт данных для миграции и резервирования;</li> <li>безопасность цепочки поставок ПО — глубокая интеграция с AppSec.Track: артефакторий автоматически блокирует скачивание уязвимых и вредоносных пакетов, обеспечивая централизованный контроль зависимостей на уровне всей организации;</li> <li>соответствие требованиям российских регуляторов — работа на отечественных операционных системах (Astra Linux, «Базальт»), продукт входит в реестр отечественного ПО;</li> <li>готовность к интеграции в существующий ландшафт — SSO (Keycloak, Active Directory, SAML, OAuth 2.0), REST API со Swagger-документацией, совместимость с CI/CD-инструментами (GitLab, GitHub, Jenkins) и средами разработки.</li> </ul> В России появилось собственное корпоративное хранилище бинарных артефактов — AppSec.Registry от вендора AppSec … message https://www.itweek.ru/themes/detail.php?ID=235534 Mon, 14 Sep 2026 16:20:04 +0300 <p>Выполняя требования по импортозамещению критической информационной инфраструктуры, российские банки проводят миграцию систем дистанционного банковского обслуживания на отечественное ПО. Технологическим партнером в реализации таких проектов выступает компания BSS — российский разработчик с более чем <nobr>30-летней</nobr> экспертизой в банковской сфере.</p> <p>Два банка, использующие системы дистанционного банковского обслуживания компании BSS, завершили проект по переводу ДБО юрлиц на импортозамещенное (внесенное в РОПО) программное обеспечение. Перед ними стояла амбициозная задача комплексной замены не только прикладного, но и системного программного обеспечения. Миграция включала перевод базы данных с Oracle на российскую СУБД Postgres Pro, а также перенос системы ДБО на серверы под управлением операционной системы Astra Linux с использованием LiberCat и отечественной сборки Java — AxiomJDK. </p> <p>Серьезный вызов проекта заключался в переносе объемных массивов баз данных в пределах строго ограниченного технологического окна. Это потребовало разработки специализированного мигратора, а также большого объёма подготовительной работы как со стороны BSS, так и со стороны банков. Дополнительной задачей стало подтверждение способности системы на новом отечественном стеке работать с необходимой производительностью и справляться с пиковыми нагрузками без наращивания аппаратных мощностей. Для этого силами BSS перед импортозамещением было проведено нагрузочное тестирование.</p> <p>Проект реализовывался поэтапно. Вначале специалисты BSS провели тщательный и системный сбор данных о текущем решении и архитектуре банков. Далее выполнялась работа по переносу необходимых доработок в специализированную версию для каждого банка. После этого шли тестовые миграции систем ДБО, в ходе которых мигратор дорабатывался и оптимизировался. Завершающим этапом стала финальная миграция баз данных и переход на импортозамещённое ПО в промышленную эксплуатацию.</p> <p>По итогам реализации проектов банки в полной мере получили ожидаемый результат. Миграция прошла успешно, системы ДБО функционируют на новом отечественном технологическом стеке с сохранением всех необходимых функциональных возможностей и показателей производительности.</p> <p>Успешная реализация проектов демонстрирует готовность российского ПО к масштабированию. Отработанная методология миграции и инструментарий являются фундаментом выполнения проектов в других кредитно-финансовых организациях, перед которыми стоит аналогичная задача по импортозамещению в установленные президентским указом сроки.</p> <p>«Переход на отечественное программное обеспечение — это не просто выполнение нормативных требований, а стратегический шаг, обеспечивающий технологический суверенитет и информационную безопасность банковской системы. BSS, как компания с более чем <nobr>30-летней</nobr> историей разработки банковских решений, обладает всей необходимой экспертизой и зрелыми продуктами для проведения таких миграций. Мы рады, что совместная работа с банками подтвердила эффективность нашего подхода и технологического стека», — отметил Станислав Шилов, директор по развитию продуктов Центра цифровых решений для бизнеса компании BSS.</p> Выполняя требования по импортозамещению критической информационной инфраструктуры, российские банки проводят миграцию систем … message https://www.itweek.ru/themes/detail.php?ID=235533 Mon, 14 Sep 2026 16:15:08 +0300 <p>Компания «Актив» представила Рутокен ЭЦП 3.0 3250 БИО (сокращенно Рутокен БИО) — новое поколение USB-токенов для аутентификации и электронной подписи, где криптографическая защита ключей дополнена биометрической верификацией по отпечатку пальца. Устройство объединяет сразу три фактора защиты: владение (сам токен), знание (PIN-код) и свойство (отпечаток пальца).</p> <p>Ключевое преимущество новинки — устройство нельзя передать третьему лицу: каждая критическая операция требует физического присутствия владельца и его отпечатка. Чтобы подписать документ, нужно подключить токен, ввести PIN-код и приложить палец к считывателю. Принципиально важно, что биометрия запрашивается не единожды при подключении, а для каждой критической операции с использованием защищенных ключей, привязанных к биометрии. Это значит, что перехваченный PIN-код или украденный носитель не позволят выполнить операцию без владельца.</p> <p>Безопасность обеспечивается на аппаратном уровне: эталонные отпечатки регистрируются только администратором и хранятся исключительно внутри чипа в формате ГОСТ Р ИСО/МЭК <nobr class="phone">19794-2-2013,</nobr> а сравнение предъявляемого отпечатка с эталонным также происходит на борту устройства — извлечь или изменить шаблоны после регистрации невозможно.</p> <p>Требования к аутентификации могут гибко регулироваться в зависимости от критичности данных и точки входа, что соответствует принципам концепции Zero Trust. Администратор может сгенерировать на одном устройстве несколько ключевых пар с разными параметрами. Например, для входа из офиса достаточно токена и PIN-кода, а для подключения из дома по VPN дополнительно потребуется отпечаток пальца.</p> <p>Рутокен БИО сертифицирован как отдельное исполнение СКЗИ Рутокен ЭЦП 3.0 и выпускается в нескольких форм-факторах. Устройство сопровождается программным инструментарием BioSDK, который позволяет разработчикам интегрировать биометрическую аутентификацию в свои приложения.</p> <p>«Одна скомпрометированная учетная запись открывает злоумышленнику сразу несколько критических систем. Поэтому важно обладать инструментом, который исключает возможность несанкционированного доступа. Биометрические характеристики невозможно украсть, их сложно подделать, а современные методы позволяют распознавать подобные попытки. Рутокен БИО делает так, что доступ к любой системе становится личным. Использование устройства не просто усиливает аутентификацию, а меняет корпоративную безопасность, приближая ее к модели Zero Trust», — отметил Валерий Бабурин, руководитель направления по развитию продуктов Рутокен, компания «Актив».</p> Компания «Актив» представила Рутокен ЭЦП 3.0 3250 БИО (сокращенно Рутокен БИО) — новое поколение USB-токенов для … message https://www.itweek.ru/themes/detail.php?ID=235532 Mon, 14 Sep 2026 10:52:17 +0300 <p><em>В <nobr>2018-м,</nobr> когда мы еще жили на заре искусственного интеллекта, технологические лидеры и консалтинговые фирмы уже говорили о конкурентном преимуществе раннего внедрения ИИ. Восемь лет спустя посыл остается тем же. Изменилась лишь ситуация: корпоративные операционные системы с трудом успевают за стремительной эволюцией новых моделей ИИ, пишет на портале </em><em>BigDataWire</em> <em>Себастьян Арриада, </em><em>CIO</em> <em>компании Globant.</em></p> <p>Сегодня, похоже, мы оказались в тупике с точки зрения релизов основных моделей. Нам не нужны более интеллектуальные модели; скорее, нам нужно понять, какая из них лучше всего справляется с каждой задачей (и по лучшей цене). Это создает возможность для CIO начать серию стратегических обсуждений, которые помогут им оставаться впереди в условиях, когда неопределенность продолжает парализовать многие организации. Основная идея проста: продолжайте инвестировать во внедрение.</p> <p>Действительно, согласно исследованию MIT, 95% моделей ИИ, внедренных в 2025 г., не оправдали ожиданий. Однако даже неудача предпочтительнее, чем стояние на месте. Легче корректировать курс по ходу дела, чем начинать с нуля. В конце концов, прежде чем стать спортсменом, нужно сначала научиться ходить.</p> <h3>Внедрение без окупаемости инвестиций — это не трансформация</h3> <p>Один из важнейших уроков последних нескольких лет заключается в том, что покупка лицензии на ИИ не делает организацию автоматически более эффективной. Эта иллюзия полностью развеяна. Оставаться в курсе событий больше не является необязательным, это необходимость.</p> <p>Успешное внедрение зависит от экспериментов: тестирования различных моделей, процессов и структур команд путем непрерывных проб и ошибок. Технология все еще недостаточно незрелая, поэтому эксперименты остаются относительно недорогими. Однако, как только рынок достигнет зрелости, затраты, вероятно, будут выглядеть совсем иначе. К тому времени организации, которые уже изучили множество альтернатив, будут лучше подготовлены к переходу на более доступные решения, а не будут привязаны к одному поставщику моделей.</p> <p>Затраты на ИИ, которые когда-то в значительной степени игнорировались, становятся одной из определяющих проблем следующего этапа. Массовое потребление токенов больше не является синонимом инноваций; оно все чаще превращается в огромный ежемесячный счет. Многие организации сейчас расплачиваются за свою незрелость на ранних этапах.</p> <h3>Почему токенмаксинг не имеет смысла</h3> <p>Эра токенмаксинга (token maxxing, стремление использовать потребление ИИ-токенов как метрику производительности) подходит к концу. Но следующая парадигма не может заключаться в минимизации токенов ради самой минимизации. Стоимость за токен и стоимость за задачу — это не конкурирующие показатели. В мире агентных вычислений это все чаще один и тот же вопрос.</p> <p>Разные задачи требуют разного уровня интеллекта. Некоторые могут быть решены с помощью небольших, высокоэффективных моделей; другие требуют более сложных моделей, более глубокого анализа, более длительного контекста или совместной работы нескольких агентов. Таким образом, стоимость задачи в конечном итоге определяется выбранными вами моделями и количеством токенов, необходимых для ее успешного выполнения.</p> <p>Вот почему токенмаксинг не имеет смысла в обоих направлениях. Токены — это потребление, а не результат, и настоящая оптимизация заключается не в их максимизации или минимизации. Она заключается в использовании правильного интеллекта для правильной задачи. Вложение большего количества токенов в сложную задачу может быть самым разумным решением, если оно приводит к лучшему результату с меньшим количеством итераций, в то время как использование дорогостоящей модели для простой задачи — это просто пустая трата средств.</p> <p>Суть заключается в сопоставлении каждой задачи с самой дешевой моделью, которая надежно ее выполняет, и измерении результатов на уровне задачи, чтобы это можно было доказать. CIO, который сообщает о росте токенов как о показателе внедрения ИИ, сообщает о затратах так, как если бы это была ценность. Чтобы оптимизировать реальные показатели, нам нужно очень хорошо понимать ценность, создаваемую каждым токеном.</p> <h3>Как выглядит экономия затрат на практике</h3> <p>Например, за семь месяцев работы с Open Source-моделями на нашей собственной инфраструктуре наряду с коммерческими API, примерно 30% от общего объема токенов было обработано с почти нулевыми предельными издержками. Сэкономленные на API средства покрыли значительную часть инвестиций в оборудование в течение первого года — без ухудшения качества выходных данных для рабочих нагрузок, которые мы перенаправили на Open Source-модели. Последний пункт очень важен: это был не обмен затрат на качество. Речь шла о сопоставлении задач с самой дешевой моделью, которая надежно их выполняет.</p> <p>Мы наблюдали ту же динамику, когда потребление и затраты перестали двигаться синхронно. В период с января по июль 2026 г. наше общее потребление токенов выросло в 6,7 раза. Наши расходы выросли в 2,2 раза. Этот разрыв почти полностью объясняется интеллектуальной маршрутизацией, которая направляет каждый запрос к нужной модели, вместо того чтобы по умолчанию использовать самую дорогую. Это цифра, которую я бы представил любому совету директоров: внедрение росло в три раза быстрее, чем затраты, и не потому, что кто-то меньше использовал ИИ. Это практическая окупаемость инвестиций в шлюз: не только прозрачность затрат, но и их снижение.</p> <h3>Три приоритета для CIO</h3> <p>Для CIO этот новый ландшафт приводит к трем ключевым выводам:</p> <p>Во-первых, ИИ-инициативы должны быть ориентированы на рентабельность инвестиций. Какую ощутимую выгоду приносит внедрение агентного ИИ в конкретный процесс? Ответом может быть экономия времени, снижение затрат, рост доходов или некая комбинация этих трех факторов. В любом случае, каждая инвестиция в ИИ должна быть связана с измеримым бизнес-результатом. Количество токенов может объяснить потребление, но оно не определяет ценность.</p> <p>Во-вторых, внедрение агентного ИИ не означает наложение технологий поверх существующих рабочих процессов. Оно требует перепроектирования процессов с нуля для создания ИИ-нативных операционных моделей. В некоторых случаях это может даже потребовать передачи ответственности за процесс другой команде внутри организации.</p> <p>В-третьих, каждая задача заслуживает своего собственного агента. Нет необходимости развертывать самую большую и дорогую модель для каждого сценария использования в масштабах всего предприятия. Неопытность привела некоторые компании к тому, что они поступают так же, как если бы наняли кран, чтобы передвинуть стул.</p> <h3>Новая экономика работы с ИИ</h3> <p>Это также меняет экономику разработки ПО. Традиционно стоимость была тесно связана с человеческим временем: сколько людей задействовано и сколько часов занимает работа. В агентной модели вычислительные ресурсы и интеллект становятся гораздо более значимой частью этого уравнения, а это значит, что CIO необходимо использовать инструменты учета затрат на уровне задач, так же, как мы всегда измеряли проекты в людях и часах.</p> <p>Новая парадигма требует от CIO переосмысления самого процесса бюджетирования. Стоимость работы больше не может измеряться только заработной платой сотрудников; она также должна учитывать технологии, выполняющие эту работу. ИИ не бесплатен и никогда не будет бесплатным. Обеспечение того, чтобы каждая инвестиция приносила измеримую ценность, имеет важное значение не только для максимизации прибыли, но и для избежания сложных разговоров с финансовым директором.</p> <p>Если индустриальная эпоха предложила десятилетний период возможностей после изобретения машины, то сегодняшние технологические циклы значительно короче. После взрывного роста новых моделей мы, похоже, вступаем в период относительной стабилизации. Следующие три года, вероятно, будут определяться массовым внедрением, а не прорывными релизами.</p> <p>Организации, которые воспользуются этим окном возможностей, обеспечат себе существенное преимущество перед конкурентами. Внедрение агентных методов в задачи, перепроектирование процессов, диверсификация моделей, измерение производительности и контроль затрат — вот основы операционной надежности в новую эпоху. Потребление токенов покажет нам, сколько это стоит... но рентабельность инвестиций определит, окупились ли вложения.</p> В 2018-м, когда мы еще жили на заре искусственного интеллекта, технологические лидеры и консалтинговые фирмы … article https://www.itweek.ru/themes/detail.php?ID=235530 Mon, 14 Sep 2026 10:14:35 +0300 <p>Еще несколько лет назад разговор об искусственном интеллекте в финтехе почти всегда сводился к автоматизации поддержки: чат-боты, голосовые ассистенты, снижение нагрузки на колл-центры. Это был понятный, быстрый и измеримый эффект ROI — сокращение издержек и ускорение обработки запросов.</p> <p>Однако сегодня основной потенциал ИИ лежит совсем в другой плоскости. Он постепенно смещается из операционного слоя в стратегический — туда, где формируются продуктовые решения, определяющие выручку, рост и конкурентоспособность компаний. ИИ-агенты становятся полноценными управленцами и влияют на бизнес-решения.</p> <p>В статье делюсь тремя способами, как ИИ может предугадывать потребности клиента и искать неочевидные связки между сигналами, чтобы предлагать вовремя следующий шаг. Материал полезен не только банкингу, но и всем, кто строит ИИ в продуктах.</p> <h3>Подход data-driven в 2026 году</h3> <p>ИИ в сфере финансов и платежей прежде всего может менять то, как команда работает с пользовательским фидбэком и формирует гипотезы.</p> <p>Финтех традиционно оперирует огромными массивами данных: обращения в поддержку, отзывы в приложениях, поведенческие метрики, транзакционная активность. Долгое время основная задача заключалась в том, чтобы всё это классифицировать, агрегировать и анализировать.</p> <p>Да, подход data-driven активно внедряется — решения принимаются на основе данных, A/B-тестов и ретроспективного анализа. Однако данные, насколько бы они не были репрезентативными, всегда отвечают на вопрос «что происходит», но почти не затрагивают вопрос «почему и как может быть иначе».</p> <h3>Как работать с фидбеком</h3> <p>Например, ранее все виды обратной связи в основном сортировали по категориям: о чем обратная связь, насколько она негативная и т. д. Но генеративный ИИ позволяет перейти к более глубокому анализу. Он выявляет связи между на первый взгляд несвязанными сигналами.</p> <p>В том числе:</p> <ul> <li> жалобы на сложность верификации;</li> <li> пользовательский опыт запутан;</li> <li> рост оттока пользователей на этапе онбординга;</li> <li> снижение повторных действий в продукте.</li> </ul> <p>Вместе эти сигналы указывают на системную проблему — например, избыточное трение, которое подрывает доверие и снижает конверсию.</p> <p>Искусственный интеллект позволяет создать систему автоматической классификации пользовательских обращений на основе LLM. Она заменяет сотни часов ручной работы в год и позволяет выявлять продуктовые проблемы проактивно, а не реактивно. Система обрабатывает тысячи отзывов по нескольким кредитным продуктам и автоматически обнаруживает паттерны, недоступные при ручном анализе. Она собирает отзывы из разных каналов — обращений в поддержку, оценок в приложении, комментариев, а затем выделяет повторяющиеся причины недовольства, контекст проблемы и этап клиентского пути, на котором она возникает.</p> <p>Например, система может связать жалобы на сложную верификацию с падением конверсии в онбординге, ростом числа обращений в поддержку и снижением повторных действий в приложении. По отдельности эти сигналы часто выглядят как задачи разных команд, но вместе указывают на системный барьер в пользовательском опыте.</p> <h3>Как работать с гипотезами</h3> <p>Особая ценность — способность ИИ-агента обнаруживать противоречия в поведении пользователей. Клиенты могут хотеть, например, высокую степень безопасности, но на практике выбирать более простые и быстрые решения.</p> <p>Подключается способность моделей быстро генерировать и прорабатывать гипотезы. Это позволяет командам рассматривать больше сценариев развития продукта и моделировать возможные последствия изменений. Более того, можно выявить риски до их появления в реальных данных.</p> <p>В сфере финансов особенно высока цена ошибки, а угрозы постоянно эволюционируют — поэтому любое незначительное изменение влияет на миллионы пользователей.</p> <p>Если использовать модели для того, чтобы генерировать альтернативные продуктовые сценарии и моделировать их последствия, то в итоге технологии дают возможность выявить edge cases еще до запуска.</p> <p>Например, в кредитном скоринге можно создать генерацию альтернативных факторов риска, в антифрод-моделях прогнозировать новые схемы мошенничества, а в онбординге тестировать оптимизацию пути клиента.</p> <h3>Как работать с персонализацией</h3> <p>ИИ совершает сдвиг и в одной из самых привычных финтех-механик — трансформирует подход к кэшбеку. Например, с ним возможно запустить систему динамических вознаграждений, интегрированную в ключевые точки контакта с клиентом, чтобы охватить миллионы пользователей. Это трансформация подхода к кэшбэку — от фиксированного процента к персонализированной ставке, data-driven-системе стимулов, где вознаграждение определяется в реальном времени с учётом поведения пользователя, его вероятности совершить действие и контекста покупки.</p> <p>Если раньше кэшбэк представлял собой фиксированный процент возврата, одинаковый для всех пользователей и не зависящий от ситуации, то с внедрением ИИ он превращается в динамическую систему стимулов.</p> <p>Вознаграждение определяется в реальном времени с учётом поведения пользователя, его вероятности совершить действие и конкретного контекста покупки; в такой модели деньги работают как точечный инструмент влияния на поведение, превращая бонусы в элемент продуктовой стратегии.</p> <p>Например, система может учитывать историю покупок и использования кредитного продукта, реакцию пользователя на прошлые предложения, категорию и сумму текущей покупки, частоту операций и вероятность того, что клиент совершит целевое действие без дополнительного стимула. На этой основе модель выбирает наиболее уместный сценарий: поддержать первую покупку, вернуть пользователя в продукт, повысить частоту использования определённой категории или, напротив, не предлагать вознаграждение там, где оно не меняет поведение. Это помогает направлять бюджет на инкрементальные действия, а не платить бонусы пользователям, которые и так совершили бы покупку.</p> <h3>Выводы: как меняется роль ИИ-команды</h3> <p>Успешный подход data-driven требует не только технологий, но нового типа продуктового лидера — того, кто способен управлять неопределённостью, критически оценивать выводы моделей и координировать кросс-функциональные команды в условиях, когда данные ещё не сформировались. При принятии решения нужно формулировать гипотезы, критически оценивать предложения ИИ и выбирать из множества возможных решений.</p> <p>ИИ расширяет пространство вариантов, но не снимает ответственность за выбор. Более того, он создаёт новый риск — иллюзию обоснованности, когда слабая идея выглядит убедительно за счёт качественной аргументации.</p> <p>Более того, если раньше на формирование требований и подготовку данных уходило значительное время, то сейчас с развитием ИИ эти процессы ускорились в несколько раз. Опыт показывает, что продукт-менеджер с помощью ИИ инструментов все чаще может самостоятельно закрывать задачи, которые раньше требовали участия отдельных специалистов — от создания UX-моков до набросков high-level-кода.</p> <p>Это означает, что человеческая экспертиза становится не менее, а более важной — просто в другой роли.</p> <p>#IMAGE_235531#</p> Еще несколько лет назад разговор об искусственном интеллекте в финтехе почти всегда сводился к автоматизации … article Андрей Милосердов, старший продакт-менеджер Amazon https://www.itweek.ru/themes/detail.php?ID=235528 Mon, 14 Sep 2026 09:57:20 +0300 <p>Критерии выбора технологии для корпоративных систем меняются. Скорость разработки и стоимость команды остаются важными, но для сложных продуктов этого уже мало. Нужно понимать, насколько предсказуемо система будет развиваться и как она поведет себя через несколько лет эксплуатации. Часть требований к надежности сегодня имеет смысл контролировать еще до того, как готовая система попадет на тестирование. Этот контроль все глубже переносится непосредственно в технологию разработки.</p> <p>Rust в этом контексте интересен как инструмент для систем, где цена технической ошибки высока и часть рисков имеет смысл закрывать еще во время разработки. В этом заключается главное отличие подхода: часть технических требований перестаёт обеспечиваться исключительно процессами и квалификацией конкретного разработчика и становится встроенным свойством самой технологии.</p> <p>Rust — один из заметных представителей такого инженерного подхода. Его сильная сторона достаточно конкретна: язык позволяет еще на этапе компиляции исключать ряд ошибок, связанных с управлением памятью и конкурентным доступом к данным. Safe Rust также не допускает гонки данных при небезопасной параллельной работе с памятью. Для корпоративного проекта это означает, что определенный класс технических ошибок можно остановить еще до тестирования и промышленной эксплуатации.</p> <p>Масштаб именно этого класса рисков хорошо виден на крупных программных продуктах. Microsoft Security Response Center оценивал, что около 70% уязвимостей, которым центр присваивал CVE, были связаны с безопасностью памяти. В Microsoft прямо связывали интерес к Rust с возможностью исключать значительную часть таких проблем еще на уровне разработки.</p> <h3>Когда следует рассматривать Rust для проектов</h3> <ul> <li><strong>Первый критерий</strong> — долгий жизненный цикл системы. Если продукт должен работать пять или десять лет, код за это время пройдет через множество доработок. Состав команды тоже частично изменится. В такой ситуации особенно важны требования, которые сохраняются независимо от того, кто именно работает с кодом в конкретный момент.</li> <li><strong>Второй критерий</strong> — высокая цена технического сбоя, которая может измеряться миллионами. Чем сильнее система связана с критичными процессами заказчика, тем выше ценность механизмов, которые позволяют выявить некоторые дефекты еще до промышленной эксплуатации. Именно для таких систем дополнительные гарантии на уровне технологии приобретают уже бизнес-значение. Rust здесь особенно интересен, если существенная часть рисков связана с работой с памятью и ресурсами или возникает в низкоуровневых компонентах.</li> <li><strong>Третий критерий</strong> — высокая производительность. Rust компилируется в машинный код и позволяет управлять памятью без обязательного сборщика мусора. Это дает разработчику больше контроля над использованием. Поэтому Rust становится сильным кандидатом для высоконагруженных компонентов, где требования к производительности действительно влияют на выбор технологии.</li> </ul> <p>Один из этих факторов сам по себе решение не определяет. Rust становится предпочтительным вариантом, когда несколько таких требований сходятся в одной задаче.</p> <h3>Когда стоит выбирать другой стек</h3> <p>Для быстрой проверки бизнес-гипотезы или выпуска MVP обычно рациональнее использовать более массовую технологию. В таких проектах на первый план выходят скорость разработки и возможность быстро собрать команду. Преимущества Rust могут просто не успеть проявиться. Другой стек логичнее и для стандартных корпоративных задач без повышенных требований к работе с памятью или скорости выполнения. Дополнительная сложность Rust в таком проекте не дает достаточной инженерной отдачи.</p> <p>Работающую систему также не стоит переносить на Rust ради самой смены технологии. Если текущий стек закрывает требования и вокруг него сформирована команда, для перехода нужна конкретная инженерная причина. Похожая логика действует в проектах, где требуется быстро расширять команду. Более распространенный стек дает больший выбор специалистов и упрощает масштабирование разработки. Таким образом, ситуации, где свойства Rust действительно нужны проекту, отделяются от задач, которые проще решить другим инструментом.</p> <p>Rust не является более правильным выбором сам по себе. Он становится таким только тогда, когда его свойства соответствуют конкретному профилю задачи.</p> <h3>Что Rust не решает</h3> <p>Границы возможностей Rust тоже важно определить заранее. Язык не исправит слабую архитектуру и не проконтролирует бизнес-логику. В информационной безопасности он снижает вероятность ряда уязвимостей, связанных с небезопасной работой с памятью, но не решает задачи управления доступом, защиты секретов и проверки внешних зависимостей. Гарантии безопасности памяти также не исключают утечки.</p> <p>Отдельный момент — <strong>unsafe-код.</strong> Он позволяет использовать операции, безопасность которых компилятор не способен полностью проверить автоматически. Поэтому Rust снимает только часть технических рисков. Качество системы в целом по-прежнему зависит от квалификации команды и принятых инженерных правил.</p> <p>На длинном жизненном цикле проявляется еще одно преимущество: часть требований перестает обеспечиваться только регламентами, проверками кода и опытом конкретного разработчика. Часть контроля берет на себя сама технология. Правила Rust действуют для каждого следующего изменения кода независимо от того, кто его вносит. Новый специалист получает те же ограничения языка, которые действовали для предыдущей команды.</p> <h3>Экономика Rust</h3> <p>Экономика Rust является следствием этих инженерных свойств. Разработка на нем может стоить дороже по сравнению с более распространенным корпоративным стеком. Специалистов с практическим опытом Rust на рынке меньше, а более строгие правила языка требуют дополнительной инженерной работы на старте. Поэтому автоматической экономии здесь нет.</p> <p>Rust сам по себе не определяет стоимость владения системой. Он может уменьшить вероятность отдельных классов технических проблем и связанных с ними затрат. Итоговая экономика зависит от архитектуры, квалификации команды, качества тестирования и характера дальнейшего развития продукта. Поэтому более высокая стоимость разработки на Rust имеет смысл только тогда, когда дополнительные гарантии языка будут востребованы на протяжении жизненного цикла системы.</p> <h3>Встроенные гарантии как критерий выбора</h3> <p>Rust не следует считать универсальным выбором для корпоративной разработки. Для разных задач по-прежнему будут оптимальны разные технологические стеки.</p> <p>Меняется другое: надежность и будущая эксплуатация все чаще учитываются уже при выборе технологии. Часть требований переносится непосредственно в язык и инструменты разработки. Rust — один из наиболее последовательных представителей этого подхода.</p> <p>Поэтому вопрос состоит не в том, стоит ли писать на Rust больше систем. Важно, в каких проектах его встроенные гарантии действительно соответствуют цене технического риска. Там выбор языка перестает быть предпочтением разработчика и становится частью инженерного решения для бизнеса.</p> <p>#IMAGE_235529#</p> Критерии выбора технологии для корпоративных систем меняются. Скорость разработки и стоимость команды остаются важными … article Алексей Постригайло, cтарший управляющий партнер IT-интегратора “Энсайн” https://www.itweek.ru/themes/detail.php?ID=235526 Fri, 11 Sep 2026 16:16:59 +0300 <p><em>Инструменты, основанные на искусственном интеллекте, смещают теневые ИТ из сферы SaaS в сферу кода. Энди Гомбар, ведущий инженер Webflow по обнаружению и реагированию, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как можно проактивно защитить свою облачную инфраструктуру.</em></p> <p>Раньше теневые ИТ были проблемой SaaS. Кто-то из маркетинговой команды регистрировался в инструменте, подключал его к Google Workspace, и первым сигналом было разрешение OAuth, которое вы не авторизовали. Раздражающе. Обнаруживаемо. Ликвидируемо.</p> <p>Эта эпоха закончилась.</p> <p>Новые теневые ИТ не отображаются в ваших журналах OAuth. Они отображаются как работающая в вашей облачной учетной записи инфраструктура, созданная с благими намерениями инженером, который попросил агента ИИ запустить ее в тот же день. Никаких тикетов, никакого ревью, никакого участия команды безопасности. Просто кто-то с хорошей идеей и инструментом, который устранил все препятствия, замедлявшие его работу.</p> <p>Такое поведение вызвано не только существующей неэффективностью. Частично оно связано с реальной работой по обеспечению безопасности.</p> <h3>Проблема с благими намерениями</h3> <p>В классических теневых ИТ чувствовалось присутствие кого-то, сознательно обходящего утвержденную ИТ-инфраструктуру. Команда, которая не хотела ждать закупок. История безопасности, по крайней мере частично, касалась здесь обеспечения соблюдения политик.</p> <p>Теперь все иначе.</p> <p>Инженер, который разрабатывает с помощью вайб-кодинга внутренний инструмент для своей команды, не пытается ничего обойти; он пытается помочь. У него есть доступ к агенту ИИ, который может писать код, генерировать программы Pulumi и развертывать инфраструктуру быстрее, чем любой процесс проверки. И если он не потратил время на размышления о безопасности облачных вычислений, у него нет оснований полагать, что то, что он только что выпустил, представляет собой проблему.</p> <p>Вот что усложняет ситуацию: вы не можете навязать свой способ выйти из нее; вы должны быстро ее предотвратить.</p> <p>Пример того, как выглядит подобная проблема: инженер создает легковесное внутреннее приложение для автоматизации ручной работы своей команды. Он просит ИИ-агента заняться инфраструктурой. Агент выделяет ресурсы в учетной записи AWS команды, открывает необходимые порты и развертывает приложение. Оно работает, и команда в полном восторге. Никто не создает тикет, потому что нечего создавать. Шесть недель спустя ваша CSPM обнаруживает общедоступную конечную точку с избыточно разрешенной IAM-ролью. К тому времени приложение уже достаточно долго работает в продакшене, и латеральное перемещение является реалистичным сценарием, а не теоретическим.</p> <p>Намерение было благим. Результат имеет радиус поражения.</p> <h3>Почему это отличается от разрастания SaaS</h3> <p>Когда теневые ИТ означали несанкционированный SaaS, ваша поверхность обнаружения была определена. Предоставление прав OAuth, сетевой трафик, отчеты о расходах, аномалии SSO. Инструмент существовал вне вашей инфраструктуры. Он был внешним. Вы могли его обнаружить, вы могли его отключить, и ущерб обычно был ограничен.</p> <p>Внутренние инструменты, созданные агентами, находятся внутри вашей инфраструктуры. У них есть IAM-роли. Они могут иметь прямой доступ к производственным данным, внутренним API или конфиденциальным системам. Они выглядят легитимно, потому что были созданы легитимным сотрудником с использованием легитимных инструментов. Нет очевидного признака, который можно было бы обнаружить. Код не заявляет о своей неконтролируемости. Он просто работает.</p> <p>Этот сдвиг заслуживает четкого названия: мы перешли от разрастания SaaS к разрастанию кода. Сценарий обнаружения для одного не подходит для другого.</p> <h3>Базовые требования, которые действительно нужны</h3> <p>Цель здесь не в том, чтобы замедлить работу инженеров. Цель в том, чтобы сделать безопасный путь легким. Базовые требования, к которым следует стремиться, имеют два уровня, и различие между ними имеет значение.</p> <p><strong>Платформенный контроль</strong> — это то, что структурно затрудняет случайное совершение неправильных действий и что вы настраиваете один раз на уровне организации или учетной записи.</p> <p><em>IAM-ограничения по принципу наименьших привилегий.</em> Доступные для командных учетных записей AWS разрешения должны быть ограничены по умолчанию. Инженер не должен иметь возможность создавать общедоступный ресурс с широкими правами доступа, не нарушая защитный механизм. Защитный механизм не останавливает работу. Он предотвращает незаметную отправку худшей версии работы.</p> <p><em>Принудительное использование менеджера секретов.</em> Жестко закодированные учетные данные в приложениях, созданных с помощью вайб-кодинга, — это не гипотетическая ситуация. Это почти неизбежная ситуация, если вы не сделаете правильный путь очевидным. Принудительное использование менеджера секретов на уровне инфраструктуры полностью снимает с отдельного инженера право принятия решения.</p> <p><em>Цели развертывания с использованием VPN.</em> Внутренние инструменты должны по умолчанию размещаться за корпоративным VPN. Если что-то действительно должно быть общедоступным, это должно требовать явного решения, а не случайного значения по умолчанию.</p> <p><strong>Контроль процессов</strong> — это то, что должно происходить на уровне инструмента, прежде чем что-либо будет выпущено.</p> <p><em>Автоматизированная проверка базовых требований.</em> Прежде чем специалист по безопасности начнет проверку, автоматически проверьте код и конфигурацию инфраструктуры на соответствие базовым требованиям. Выявите нарушения, оцените их по степени серьезности и предоставьте инженеру конкретные рекомендации по устранению. Это тот уровень, который может обеспечить навык Claude или аналогичный инструмент. Дальнейшая проверка человеком фокусируется на результатах автоматической проверки, а не начинается с нуля.</p> <p><em>Проверка кода с учетом требований безопасности и эскалацией. </em>Каждый инструмент, разработанный внутри компании и взаимодействующий с производственной инфраструктурой, требует проверки человеком, обладающим опытом в области безопасности, прежде чем он будет выпущен. Для инструментов с низким уровнем риска это может быть коллега-инженер, понимающий масштабы проблемы, которую он проверяет. Для всего, что связано с облачной инфраструктурой, прямым доступом к данным или новыми ролями IAM, проверка эскалируется в формальную проверку безопасности. Тот же контроль, но с разбивкой по степени риска. Ключевой момент заключается в том, что проверяющий должен действительно понимать код. В случае с инструментами, разработанными с использованием вайб-кодинга, автор может не до конца понимать, что он создал. Это делает проверку более важной, а не просто формальной. Это не просто врата качества. Это своего рода «врата понимания».</p> <h3>Защитная сетка</h3> <p>Базовые требования — это профилактика. Обнаружение — это то, что выявляет то, что проскальзывает.</p> <p>Ваша CSPM — это подходящий инструмент для обнаружения неправильных конфигураций в уже существующих системах. Wiz и подобные ему инструменты выявят общедоступную конечную точку, роль с избыточными правами доступа, хранилище без надлежащего контроля доступа.</p> <p>Но CSPM обнаруживает только то, что уже развернуто. Базовые требования и процесс ревью — это то, на что вы рассчитываете в плане предотвращения. Обнаружение — это уровень выявления, а не первая линия защиты.</p> <p>Более сложная задача обнаружения — это знание о существовании чего-либо. Инструмент вайб-кодинга, работающий локально или в командной учетной записи, может не оставлять следов в вашем обычном слое видимости. Нет конвейера развертывания. Нет заявок на изменение. Нет записей в инвентаризацию активов.</p> <p>Вот где начинают иметь значение поведенческие сигналы из вашей облачной телеметрии. Создание ролей IAM вне вашей обычной активности конвейера. Появление новых общедоступных ресурсов без соответствующей записи об изменении. Вызовы API, исходящие с машин разработчиков непосредственно в производственные учетные записи, а не через стандартные инструменты. Ни один из этих сигналов сам по себе не является определяющим. В совокупности они начинают выглядеть как нечто, заслуживающее более пристального внимания.</p> <p>Большинство команд не ищут эти сигналы именно в контексте инструментов, созданных агентами. Именно этот пробел стоит закрыть.</p> <h3>Кодифицированные базовые требования</h3> <p>Документация, хранящаяся в вики, — это базис, который никто не использует, когда это необходимо. Лучший путь — сделать базовые требования доступным в инструментах, которые уже используют инженеры, на этапе разработки.</p> <p>Навык Claude или аналогичный ИИ-нативный инструмент, который проверяет описания архитектуры или сгенерированную инфраструктуру на соответствие вашему конкретному базовому уровню безопасности, полезнее, чем контрольный список в Confluence. Инженер получает конкретную, действенную обратную связь до того, как ее увидит человек-рецензент. Команда безопасности получает первый вариант, уже отфильтрованный по очевидным недостаткам. Проверка становится лучше, потому что она начинается с более полной картины.</p> <p>Ничего из этого не сработает, если инженеры не осведомлены об этом навыке или если отсутствует процесс проверки. Осведомленность сама по себе является уровнем предотвращения. Внедрение обоих аспектов во время адаптации делает безопасный путь видимым, а использование обратной связи от навыка в качестве двойного инструмента обучения тому, почему важна каждая проверка, помогает закрепить знания. Защитный барьер, который не афиширует себя, не является профилактическим.</p> <h3>Вывод</h3> <p>Внутренние инструменты, основанные на вайб-кодинге, никуда не денутся. Трение, которое раньше замедляло работу неуправляемой инфраструктуры, исчезло и не вернется. Вопрос в том, успеет ли ваш базовый уровень безопасности достичь своих целей раньше, чем CSPM.</p> <p>Платформенный контроль делает безопасный путь путем по умолчанию. Контроль процессов гарантирует, что человек, обладающий контекстом безопасности, увидит все до того, как это будет реализовано. Обнаружение дает вам уровень защиты от того, что все равно проскальзывает.</p> <p>Для всего этого не требуется выделенная команда AppSec или SOC. Необходимы четкие базовые требования, инструменты для их обеспечения и инженеры, понимающие, что именно они проверяют. Эту проблему может решить небольшая, хорошо структурированная команда безопасности. Платформенный контроль осуществляется на уровне организации или инженера по безопасности, устанавливается один раз и применяется повсюду. Контроль процессов является распределенным: коллега-инженер, имеющий опыт работы с безопасностью, занимается инструментами с низким уровнем риска, в то время как все, что касается облачной инфраструктуры, прямого доступа к данным или IAM-новшеств, передается на формальную проверку безопасности. Это распределенная ответственность с четким путем эскалации, а не одна команда, проверяющая все.</p> Инструменты, основанные на искусственном интеллекте, смещают теневые ИТ из сферы SaaS в сферу кода. Энди … article https://www.itweek.ru/themes/detail.php?ID=235525 Fri, 11 Sep 2026 12:27:06 +0300 <p>Самые высокие медианные зарплаты программистам в 3 квартале 2026 года предлагали в Москве (211,7 тыс. рублей), Московской области (180 тыс. рублей) и Санкт-Петербурге (158,8 тыс. рублей), выяснили аналитики hh.ru. При этом медианная предлагаемая зарплата у программистов по России в августе составила 152,7 тыс. рублей.</p> <p>В топ-10 регионов России с наиболее высокими предложениями от работодателей также вошли Тульская область (155 тыс. рублей), Свердловская область (139,8 тыс. рублей), Республика Татарстан (133,2 тыс. рублей), Краснодарский край (131,7 тыс. рублей), Новосибирская и Рязанская области (по 130 тыс. рублей), а также Нижегородская область (128,1 тыс. рублей).</p> <p>«Программисты остаются ключевыми специалистами для ИТ-отрасли: с начала года работодатели разместили для них более 49 тыс. вакансий. При этом растет уровень мотивации, которую готовы обеспечить компании: медианная предлагаемая зарплата увеличилась с 150 тыс. рублей в январе 2026 года до 152,7 тыс. рублей в августе. Важно отметить, что опытные специалисты востребованы не только в ИТ-секторе: их также готовы нанимать компании, которые развивают собственные цифровые продукты и инфраструктуру в разных сферах деятельности», — отметила Мария Игнатова, директор по исследованиям hh.ru.</p> <p>Больше всего вакансий для программистов приходится непосредственно на отрасль информационных технологий, системной интеграции и интернета — в 3 квартале работодатели разместили на hh.ru более 4 тыс. предложений с медианной зарплатой 165,8 тыс. рублей. На втором месте по числу вакансий — финансовый сектор (более 1 300 предложений с медианной зарплатой 176,5 тыс. рублей), на третьем месте — розничная торговля (более 600 вакансий с медианной зарплатой 150 тыс. рублей).</p> <p>В топ-5 отраслей также вошли услуги для бизнеса (более 600 вакансий и 185,3 тыс. рублей) и также сфера электроники и приборостроения (более 550 вакансий и 150 тыс. рублей предлагаемой оплаты труда).</p> <p>Топ актуальных вакансий программистов на hh.ru с наибольшей предлагаемой зарплатой:</p> <ol> <li>Senior Android разработчик — до 900 тыс. руб. в месяц;</li> <li>разработчик — от 512 тыс. до 768 тыс. руб. в месяц до вычета налогов;</li> <li>инженер-программист (SDR / ЦОС) — от 487,5 тыс. руб. в месяц до вычета налогов;</li> <li>Backend-разработчик Go — от 450 тыс. руб. в месяц до вычета налогов;</li> <li>ведущий разработчик ПО — от 350 тыс. до 650 тыс. руб. за месяц.</li> </ol> «Рынок разработки стал более избирательным: работодатели по-прежнему конкурируют за сильных middle-, senior- и lead-специалистов, но требования к кандидатам растут, особенно начиная с ролей уровня senior. На этом уровне карьеру определяет уже не только качество кода, но и способность объяснять технические решения, договариваться с командой, понимать продукт и бизнес-контекст. Поэтому для опытных разработчиков участие в профессиональном сообществе и нетворкинг становятся частью профессионального капитала: через окружение приходит обмен экспертизой, рекомендации и карьерные возможности. Мы видим этот интерес и в Сетке: на сентябрь на платформе зарегистрировано больше 40 000 разработчиков — это <nobr>4-я</nobr> по численности роль после менеджмента, продаж и маркетинга. Это показывает, что ИТ-специалисты всё чаще воспринимают профессиональные связи как инструмент роста, а не как что-то второстепенное», — отметила Юлия Ранн, CPO соцсети для нетворкинга «Сетка». Самые высокие медианные зарплаты программистам в 3 квартале 2026 года предлагали в Москве (211,7 тыс … message https://www.itweek.ru/themes/detail.php?ID=235524 Fri, 11 Sep 2026 12:20:15 +0300 <p>По данным Аналитического центра Sledi.ru, за январь—июль 2026 года по Федеральному закону № <nobr>44-ФЗ</nobr> государственные заказчики заключили 44 389 контрактов, включающих программное обеспечение и ИТ-оборудование. Общая стоимость контрактов составила 215,76 млрд рублей. По сравнению с аналогичным периодом прошлого года число контрактов выросло на 7%, а их стоимость — на 40,8%.</p> <p>Годом ранее за тот же период государственные заказчики заключили 41 474 контракта общей стоимостью 153,28 млрд рублей. Почти 70% прироста пришлось на ФНС России и ФКУ «Налог-Сервис»: за семь месяцев 2026 года они заключили контракты на 55,06 млрд рублей против 11,70 млрд рублей годом ранее.</p> <p>Для сравнения: в январе—июле 2025 года объем закупок вырос к 2024 году всего на 2,2%, а количество контрактов сократилось на 7,1%.</p> <p>За январь—июль 2026 года государственные заказчики заключили 13 762 контракта на программное обеспечение — на 11,5% больше, чем годом ранее. За тот же период 2025 года таких контрактов было 12 340. Стоимость позиций ПО с указанной в ЕИС ценой выросла с 65,34 до 85,20 млрд рублей — на 30,4%.</p> <p>Чаще всего закупали лицензии на программное обеспечение — они вошли в 6 075 контрактов. Операционные системы вошли в 5 148 контрактов, разработка ПО для прикладных задач — в 867. Еще 713 контрактов включали прочие оригиналы программного обеспечения, 505 — прикладное ПО, 440 — сетевое ПО.</p> <p>При этом самые массовые категории не формируют основной денежный объем. На 867 контрактов по разработке ПО для прикладных задач пришлось 56,35 млрд рублей — около 66% стоимости позиций ПО. Лицензии на программное обеспечение вошли более чем в 6 тыс. контрактов, но их стоимость составила 10,28 млрд рублей</p> <p>На ИТ-оборудование за январь—июль 2026 года государственные заказчики заключили 31 180 контрактов — на 5,5% больше, чем годом ранее. За тот же период 2025 года таких контрактов было 29 549. Стоимость позиций ИТ-оборудования с указанной в ЕИС ценой выросла с 60,05 до 89,39 млрд рублей — на 48,9%.</p> <p>Одним из главных факторов роста стали крупные закупки Федеральной налоговой службы и ФКУ «Налог-Сервис». За январь—июль 2025 года эти два заказчика заключили контракты на 11,70 млрд рублей, а за тот же период 2026 года — на 55,06 млрд рублей. Общий прирост стоимости контрактов составил 62,48 млрд рублей. Из них 43,36 млрд рублей пришлись на ФНС России и ФКУ «Налог-Сервис» — около 69%.</p> <p>Без учета контрактов ФНС России и ФКУ «Налог-Сервис» общая стоимость контрактов в выборке выросла со 141,58 до 160,70 млрд рублей — на 13,5%. При этом по отдельным направлениям динамика различалась: стоимость позиций ПО увеличилась с 55,83 до 67,63 млрд рублей — на 21,1%, а ИТ-оборудования, напротив, снизилась с 57,99 до 54,10 млрд рублей — на 6,7%.</p> <p>Если рассматривать закупки по регионам регистрации заказчиков в ЕИС, первое место занимает Москва — 130,08 млрд рублей. Далее следуют Московская область — 11,83 млрд рублей и Санкт-Петербург — 8,11 млрд рублей.</p> <p>Артем Баюшкин, генеральный директор Sledi.ru, отметил: «Рост закупок ПО и ИТ-оборудования может быть связан сразу с несколькими процессами. Государственные заказчики продолжают обновлять ИТ-инфраструктуру, возвращаются к отложенным проектам модернизации и развивают существующие информационные системы. Одновременно продолжается переход на отечественные программные и аппаратные решения, который требует не только замены отдельных продуктов, но и их внедрения, интеграции и доработки. Поэтому рост в денежном выражении может отражать прежде всего увеличение масштаба таких проектов, а не просто рост числа закупок».</p> По данным Аналитического центра Sledi.ru, за январь—июль 2026 года по Федеральному закону № 44-ФЗ … message https://www.itweek.ru/themes/detail.php?ID=235523 Fri, 11 Sep 2026 12:18:39 +0300 <p>«Яндекс» выложил в открытый доступ Alice AI Search Pretrain — свою собственную обученную с нуля языковую модель. Благодаря своей архитектуре она способна мгновенно давать емкие ответы и обрабатывать большой поток запросов. «Яндекс» первым выложил в открытый доступ базовую (pretrain) модель, дообученная версия которой генерирует ии-ответы в Поиске. Ее можно найти на платформе Hugging Face.</p> <p>Alice AI Search Pretrain — это компактная языковая модель, которая уже прошла первый этап обучения и имеет обширные знания о мире. Она способна обрабатывать большой объем документов и выдерживать большую нагрузку. А благодаря своей компактности не требует больших вычислительных мощностей. Разработчики и исследователи могут использовать ее в своих проектах и изучать ее архитектуру.</p> <p>Модель имеет гибридную архитектуру, которая до «Яндекса» существовала в основном только в научных исследованиях. Она объединяет две технологии: «Энкодер-декодер» (Encoder-Decoder) и MoE (Mixture of Experts). Первая позволяет давать емкий лаконичный ответ за счет того, что одна часть модели изучает и отбирает информацию, а другая генерирует ответ. Вторая технология ускоряет работу модели и экономит вычислительные мощности. Вместо того, чтобы задействовать всю нейросеть, MoE активирует только ту часть ее «мозга», которая лучше разбирается в теме. Эта модель содержит 35 млрд параметров, но при обработке одного токена (небольшого фрагмента текста) используется лишь около 600 млн — менее 2%.</p> <p>По качеству ответов Alice AI Search Pretrain превосходит компактные языковые модели на задачах по русскому языку. По данным замеров методом слепого тестирования она отвечает лучше Qwen 3.5 2B и 4B и T5 Gemma 2 4B-4B Base. При этом модель также сопоставима по качеству с Qwen 3.5 35B-A3B, которая требует значительно больше вычислительных ресурсов, чем Alice AI Search Pretrain. </p> <p>С июля в Поиске «Яндекса» работает дообученная версия этой модели — Alice AI Search, входящая в семейство генеративных моделей Alice AI. Чтобы Alice AI Search давала емкие и понятные ответы, разработчики собрали пользовательские сигналы и обучили модель на реальных примерах взаимодействия людей с поиском. Ответы модели появляются прямо под поисковой строкой и помогают быстро разобраться в теме. Каждый месяц быстрыми ответами пользуются более 49 миллионов человек. Это самый массовый генеративный продукт «Яндекса», где пользователи чаще всего сталкиваются с искусственным интеллектом.</p> «Яндекс» выложил в открытый доступ Alice AI Search Pretrain — свою собственную обученную с нуля языковую … message https://www.itweek.ru/themes/detail.php?ID=235522 Fri, 11 Sep 2026 12:14:25 +0300 <p>Компания Innostage объявила о выходе версии 1.5.1 решения Innostage TDIR Интеллектуальная автоматизация расследования инцидентов ИБ (далее по тексту — Innostage TDIR), предназначенного для интеллектуальной автоматизации деятельности центров мониторинга и реагирования на инциденты информационной безопасности (SOC).</p> <p>Innostage TDIR — российское on-premise решение класса Agentic SOC. Оно усиливает SIEM/SOAR-системы посредством автономных ИИ-агентов, которые расследуют инциденты, фильтруют ложные срабатывания и проводят историческую корреляцию, помогая аналитикам SOC преобразовать рутинную работу в автономный процесс.</p> <p>В новой версии Innostage TDIR усовершенствован механизм интеллектуальной проверки инцидентов, который сокращает количество ложных срабатываний (AntiFP) и дает рекомендации по реагированию. Поддержка нескольких алгоритмов AntiFP в рамках тестирования гипотез позволяет системе подбирать оптимальный подход к выявлению реальных угроз с учетом специфики конкретной инфраструктуры и повысить точность детектирования.</p> <p>Функциональность автоматического выполнения запросов к SIEM, предназначенных для обогащения контекста инцидента, теперь предусматривает возможность отмены таких действий на этапе анализа по инициативе пользователя. Гибкое управление запросами помогает оптимально расходовать ресурсы.</p> <p>Обновленный отчет об инцидентах информационной безопасности включает четыре ключевых столпа аналитики: вердикт False Positive / True Positive с уровнем достоверности, детальный анализ PowerShell, включая поиск обфускации и подозрительных паттернов, сопоставление с историческими инцидентами, а также обогащение из баз знаний, Threat Intelligence и правила корреляции для всесторонней оценки угроз. Это позволяет специалистам быстро отличать реальные атаки от легитимной активности. </p> <p>Также произведены доработки нескольких сервисных компонентов системы:</p> <ul> <li>скорректирован подход к передаче паролей и проверке подключения для снижения риска учетных данных;</li> <li>добавлено автозаполнение: при создании объектов из баз знаний о целях (Type = ’’Тактика«) и способах атаки (Type = «Техника») наименования и описания теперь заполняются из соответствующего справочника, что сокращает объем ручного ввода и приводит к единообразию описания угроз;</li> <li>оптимизирован процесс выполнения запросов SIEM: реализовано параллельное выполнение без блокировок других ИИ-проверок, благодаря чему система лучше справляется с нагрузкой;</li> <li>скорректирован и ускорен поиск алгоритмических правил: реализован поиск по текстовому значению без учета Markdown-разметки;</li> <li>ко всем сервисам добавлен механизм проверки работоспособности (Healthcheck), который используется в автотестах.</li> </ul> <p>«С момента выхода Innostage TDIR версии 1.0.0 прошло чуть больше месяца. За это время мы получили обратную связь от первых пользователей, что дает нам отличную возможность активно улучшать продукт. Новые доработки связаны, прежде всего, с повышением безопасности, удобства и стабильности работы системы», — прокомментировал Искандер Тиморшин, владелец продукта Innostage TDIR.</p> <p>«Ключевое преимущество Innostage TDIR состоит в том, что с его помощью компании могут легко встраивать в свои системы защиты широкий набор ИИ-агентов: они сортируют оповещения, детально разбирают инциденты, оказывают помощь и принимают первичные меры в принятии решений для устранения угроз. Это позволяет масштабировать процессы кибербезопасности, делегируя рутинные расследования и реагирование искусственному интеллекту», — добавил Никита Радионов, заместитель директора по развитию продуктов Innostage.</p> Компания Innostage объявила о выходе версии 1.5.1 решения Innostage TDIR Интеллектуальная автоматизация расследования … message https://www.itweek.ru/themes/detail.php?ID=235519 Fri, 11 Sep 2026 11:20:46 +0300 <p><em>Сто лет назад электричество начало поступать на заводы и в дома гораздо быстрее, чем кто-либо мог надёжно его распределять или контролировать. Сначала прокладывалась проводка, затем появились автоматические выключатели, правила техники безопасности и точное выставление счетов. В основном это происходило после того, как пожары, отключения электроэнергии и спорные счета вынуждали к этому. Сейчас предприятия сталкиваются с аналогичной проблемой с агентным искусственным интеллектом, и в новом исследовании IDC «</em><em>Crossing</em> <em>the</em> <em>Agent</em> <em>Economy</em><em>’</em><em>s</em> <em>Cost</em> <em>Governance</em> <em>Gap</em><em>» приводятся точные цифры, показывающие, насколько велик этот разрыв, пишет в корпоративном блоге Рик Вилларс, вице-президент группы глобальных исследований </em><em>IDC</em><em>.</em></p> <h3>Сколько агентов уже подключено к бизнесу</h3> <p>Одно только количество внедрений должно разрешить любые затянувшиеся споры о пилотных проектах и ​​производстве. Согласно четвертой волне исследования IDC «Future Enterprise Resiliency and Spending Survey (FERS Survey)», проведенного в июле 2026 г., 95% предприятий по всему миру в настоящее время используют как минимум один финансируемый компанией рабочий процесс с поддержкой агентов в производственной среде, а в среднем в организациях используется около 11 таких процессов в различных функциональных областях. Это не статистика первопроходцев. Это инсталлированная база, требующая управления и расширения, и она наиболее сконцентрирована на ИТ-операциях и разработке ПО (71% организаций), за которыми следуют обслуживание/поддержка клиентов (43%) и цепочки поставок и закупки (36%).</p> <p>Затраты, поддерживающие это растущее присутствие, — это реальные деньги, которые уже сегодня работают, а не погрешность округления, которую нужно будет моделировать позже. Предприятия, имеющие доступ к информации о своих затратах на агентов (большинство имеют такой доступ), сообщают о средних ежемесячных расходах на инференс агентов и связанные с этим услуги оркестрации в размере 117 558 долл., что значительно превышает 1 млн. долл. в год, и оценки IDC по внедрению агентов показывают, что это лишь начало гораздо более долгой истории. По прогнозам, к 2030 г. число активных агентов, используемых организациями, достигнет 2,5 млрд., что почти в 80 раз больше, чем в 2025 г. Эти агенты будут выполнять 459 трлн. действий в год против 48 млрд. сегодня. Ничто не говорит о замедлении темпов. Инновационный потенциал агентного ИИ реален, и предприятия доказали, что могут справиться с первоначальной нагрузкой. Вопрос, который сейчас рассматривает IDC, заключается в том, успевают ли счетчики и механизмы, на которые полагаются предприятия, за этой экспансией и что могут сделать технологические лидеры, чтобы избежать негативных последствий.</p> <p>#IMAGE_235520#</p> <h3>Перерасход средств — это проблема прозрачности, а не дисциплины</h3> <p>Они пока не успевают, и данные точно показывают, где находится разрыв. 67% предприятий за последние 12 месяцев превысили свой бюджет расходов на агентов более чем на 10%, в том числе 24% значительно или чрезвычайно превысили прогноз. Анализ перерасхода средств по степени тяжести показывает реальную картину: 43,1% превысили бюджет умеренно на <nobr>10-25%,</nobr> 18,5% значительно — на <nobr>26-50%,</nobr> а 5,4% — более чем на 50%. Функциональная область, возглавляющая внедрение агентов, — ИТ и разработка ПО — также чаще всего упоминается как область с наибольшим перерасходом средств, что говорит о том, что энтузиазм и бюджетная дисциплина движутся в противоположных направлениях внутри одних и тех же команд.</p> <p>#IMAGE_235521#</p> <p>Последствия не абстрактны. Примерно половина организаций, превысивших бюджет, отложили другие важные ИТ-проекты, чтобы остаться в рамках бюджета, а 43,1% проактивно сократили штат сотрудников для компенсации. Перерасход средств на агентов уже вытесняет другие инвестиции в технологии и, в значительной части случаев, рабочие места. В основе всего этого лежит настоящий парадокс: 61,8% организаций оценивают свою систему управления затратами как «определенную» или «оптимизирующую», однако только 45,4% имеют панели мониторинга, отслеживающие в реальном времени потребление токенов и затраты по рабочим процессам. Область, в которой две трети организаций считают, что их система управления достаточно зрелая, а две трети также не укладываются в бюджет, — это область, где самооценка и результаты перестали соответствовать друг другу.</p> <p>IDC разработала фреймворк для решения именно этой проблемы. Мы предлагаем краткий список решений, которые будут иметь большее значение, чем любое ожидаемое снижение цен на модели:</p> <ol> <li> Назначьте одного ответственного за расходы агентов по каждому рабочему процессу до следующего бюджетного цикла, а не после следующего перерасхода.</li> <li> Замените ежемесячный анализ счетов-фактур на отслеживание затрат в режиме реального времени. Ежемесячный снимок не позволит управлять поверхностью затрат, которая меняется ежечасно.</li> <li> Финансируйте управление затратами как инженерную дисциплину, с выделением инженерного времени, поскольку наиболее эффективные средства контроля (маршрутизация моделей, кэширование промптов, ограничения для циклов агентов) создаются, а не пишутся в служебную записку.</li> <li> Рассмотрите возможность ограничения доли расходов на инференс у отдельного поставщика, как правило, ниже 40%, и держите наготове второй вариант, поскольку цены и условия постоянно меняются от квартала к кварталу.</li> </ol> <h3>Стоимость — это лишь одна нить, а не вся ткань</h3> <p>Было бы ошибкой рассматривать стоимость агентов как отдельную финансовую проблему, и сопутствующий фреймворк IDC «Autonomy on a Leash: A Framework for Agentic AI Governance», объясняет почему. Как отмечает мой коллега Дункан Браун, «организации, которые откладывают внедрение управления до момента развертывания, не избегают затрат. Они лишь откладывают их и увеличивают свои риски, пока ждут».</p> <p>Фреймворк IDC сопоставляет 12 ИТ-областей, включая FinOps и управление затратами, с пятью основными столпами операционного управления: объяснимость и проверяемость, идентификация и контроль доступа, архитектура человеческого контроля, системное управление агентами и непрерывный мониторинг. Стоимость в основном относится к непрерывному мониторингу, но она никогда не остается там одна. Те же самые организации, которые превышают бюджет, также являются теми, где количество нечеловеческих личностей уже превышает количество человеческих, и только 44% организаций внедрили политику идентификации агентов, несмотря на то, что 92% считают это критически важным.</p> <p>Это более глубокий момент, скрытый за цифрами расходов. Перерасход и пробелы в управлении обычно являются одной и той же неудачей, рассматриваемой с разных сторон. Исследование IDC о зрелости организационного управления показывает, что предприятия с реальными моделями подотчетности, документированным надзором и возможностями наблюдаемости в реальном времени к 2029 г. смогут добиться операционной прибыли на 15% выше, чем те, кто гонится только за повышением производительности ИИ. Хорошо построенное управление не является тормозом для описанных выше инноваций. Это распределительный щит, который позволяет предприятию использовать агентный ИИ на полную мощность, не обнаруживая место короткого замыкания только после пожара.</p> <p>Все это не является аргументом в пользу замедления внедрения агентного ИИ в бизнес. Это аргумент в пользу того, чтобы технологические лидеры взяли на себя центральную роль в масштабировании системы, прежде чем это заставят их сделать финансовый, юридический отделы или публичный инцидент.</p> Сто лет назад электричество начало поступать на заводы и в дома гораздо быстрее, чем кто-либо мог надёжно его … article https://www.itweek.ru/themes/detail.php?ID=235516 Fri, 11 Sep 2026 10:25:19 +0300 <p>Крупные телеком-узлы принято считать надёжной опорой рунета — благодаря резервному питанию и географически распределённой инфраструктуре обмена трафиком. Но полуторачасовое отключение на М9 18 августа 2026 года затронуло 467 сетей, а треть из них потеряла почти всю видимость в интернете. Рассмотрим, чем оборачивается физическая концентрация инфраструктуры, когда одна площадка выходит из строя.</p> <p>Вечером 18 августа в одном из районов юго-запада Москвы на полтора часа пропало электричество. Само по себе событие не очень примечательное. Но в зону отключения попала улица Бутлерова, на которой расположен М9 — один из крупнейших телекоммуникационных узлов страны. И локальный инцидент на несколько часов аукнулся по всей стране: хостинг-провайдер Reg.ru зафиксировал сбои в своей инфраструктуре, а совокупный трафик через точку обмена MSK-IX резко просел.</p> <p>М9 давно называют «сердцем рунета». Авария 18 августа дала редкую возможность увидеть на реальных данных, насколько сильно физическая концентрация инфраструктуры на одной площадке может повлиять на сетевую связность.</p> <p>Начнём с масштаба: анализ видимости маршрутов в глобальной таблице BGP — по сути, карты того, какие сети объявляют о своей доступности и через кого, — показывает, что сбой задел 467 автономных систем и 2546 сетевых префиксов. Почти 80% этих сетей зарегистрированы в России, но эффект вышел за пределы страны. Падение прошло в две волны: первая, из 107 сетей, началась около <nobr>20:00–20:10</nobr> по Москве, вторая и основная, из 360 сетей, — в <nobr>20:15–20:23.</nobr> Восстановление в обеих группах стартовало почти синхронно, около 20:55.</p> <p>Дальше — то, что делает эту историю интересной не только для сетевых инженеров. У 165 из 467 пострадавших сетей — больше трети — видимость упала как минимум на 90% анонсируемого адресного пространства. Для них авария на М9 обернулась не помехой, а фактически полным отключением. Показательный пример — сеть НИИЯФ МГУ: один из её префиксов, до инцидента видимый из 481 точки наблюдения в мире, за несколько минут обнулился и оставался недоступным около получаса.</p> <p>А вот у крупнейшего национального оператора «Ростелеком», анонсирующего порядка 1900 префиксов, из строя вышел ровно один — около 0,05% его сети. Чем крупнее и географически распределённее оператор, тем меньше на практике он зависит от одной площадки, даже если формально на ней присутствует.</p> <p>При этом важно не смешивать М9 и MSK-IX. М9 — это физический телекоммуникационный объект, а MSK-IX представляет собой территориально распределенную систему, в которую входит 45 площадок в 10 российских городах. Поэтому глобального отключения не случилось. Это не случайность, а следствие модели: устойчивость российского сегмента интернета на сетевом уровне — одна из его сильных сторон. Показатель зависимости связности рунета от отказа одного, самого значимого оператора, сейчас составляет 4,7% — лучший результат за десять лет наблюдений, которые ведут специалисты Curator. Обеспечивают его хорошая связность и множество независимых операторов: если бы основная масса сетей зависела от одного ключевого игрока, его отказ грозил бы масштабной потерей связности. В распределённой модели компании резервируют каналы у нескольких провайдеров, а при проблеме у одного из них трафик просто перестраивается через другую автономную систему.</p> <p>Но авария на М9 показывает обратную сторону этой же устойчивости. Высокая сетевая распределённость не исключает риски на физическом уровне: даже независимые операторы и резервные каналы связи в какой-то точке могут опираться на одну и ту же физическую инфраструктуру — точки обмена трафиком, дата-центры, узлы связи, кабельные трассы. Если несколько логически независимых маршрутов физически проходят через одну площадку, её отказ способен одновременно задеть сразу несколько, казалось бы, не связанных друг с другом направлений. Именно это произошло 18 августа: для сотен операторов, чьё присутствие было сосредоточено на М9, логическая распределённость сети в момент аварии оказалась абстракцией, их доступность на деле определялась устойчивостью одного здания и его резервного электропитания.</p> <p>И это не сугубо российский феномен. Крупные точки обмена трафиком — от франкфуртского DE-CIX до амстердамского AMS-IX — обрастают тем же сетевым эффектом: чем больше операторов уже подключено, тем выгоднее подключаться следующим, и тем выше физическая концентрация критической инфраструктуры на одной площадке. Авария на М9 — частный, но показательный случай общей закономерности: распределённость в теории не гарантирует распределённости на практике, если экономика толкает десятки независимых сетей полагаться на одни и те же стены, кабели и генераторы.</p> <p>Вывод для операторов и их клиентов весьма практический: помимо осуществления резервирования на уровне маршрутизации необходимо обеспечивать резервирование на уровне физической инфраструктуры. Полтора часа без света в одном районе Москвы напомнили об этом всей стране.</p> <p>#IMAGE_235518#</p> Крупные телеком-узлы принято считать надёжной опорой рунета — благодаря резервному питанию и географически … article Дмитрий Ткачев, гендиректор Curator https://www.itweek.ru/themes/detail.php?ID=235505 Thu, 10 Sep 2026 17:48:52 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как вузы и научные организации регулируют и поддерживают применение искусственного интеллекта сотрудниками.</p> <p>Руководители организаций сферы науки в целом поддерживают применение ИИ сотрудниками для целей, связанных с исследованиями. Положительно к такой практике относятся 49% опрошенных организаций, еще 34% считают технологию полезной для одних исследовательских задач, но не подходящей для других. Нейтральной позиции придерживаются 14% респондентов, негативной — лишь 3%.</p> <p>Практические меры поддержки уже реализуют 65% организаций. В вузах они распространены заметно шире, чем в НИИ: 76% против 49%. Разрыв может быть связан с наличием у вузов собственной образовательной инфраструктуры, облегчающей развертывание обучающих форматов.</p> <p>Наиболее распространены малозатратные образовательные семинары, встречи и мастер-классы: их проводят 48% организаций. Почти четверть (23%) реализуют более системные форматы — долгосрочные программы ДПО и повышения квалификации.</p> <p>Разрабатывают собственные ИИ-модели для научных исследований 23% организаций. Однако эту деятельность следует рассматривать прежде всего как направление исследований и разработок и лишь косвенно — как меру развития сотрудников.</p> <p>Финансовая и ресурсная поддержка встречается заметно реже. Внутренние гранты на исследования с использованием ИИ выделяют 10% организаций. Междисциплинарные команды, объединяющие специалистов по ИИ и исследователей-предметников, поддерживают 6%.</p> <p>Подписки на ИИ-сервисы и доступ к внешним вычислительным мощностям оплачивают лишь единичные организации — хотя сами ученые относят именно эти меры к наиболее востребованным.</p> <p>Формализация политики заметно отстает от практики. Внутренние документы, регулирующие работу с ИИ (регламенты, положения, концепции и др.), утвердили лишь 60 участников опроса (14%); из них только 35 включили в эти документы положения об использовании ИИ непосредственно в научных исследованиях.</p> <p>Результаты опроса ИСИЭЗ НИУ ВШЭ показали, что руководители вузов и НИИ в целом одобряют использование ИИ сотрудниками в научных исследованиях, а две трети организаций уже реализуют конкретные меры поддержки. При этом практическая поддержка опережает нормативное оформление и чаще всего строится по принципу наименьших затрат. Переход к системному применению ИИ в российской науке требует не только стимулирования со стороны государства, но и развития внутренних механизмов на уровне организаций.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как вузы и научные организации … message https://www.itweek.ru/themes/detail.php?ID=235504 Thu, 10 Sep 2026 17:44:59 +0300 <p>Сбер представил GigaChat 3.5 Reasoning — новую флагманскую мультимодальную нейросеть с режимом рассуждений. Она не спешит сразу отвечать на сложный вопрос: сначала разбирает задачу на этапы, определяет план решения, при необходимости обращается к поиску и другим инструментам, ищет ошибки в своих промежуточных результатах и только после этого формирует ответ. GigaChat 3.5 Reasoning — быстрая и экономная модель: она решает задачи с меньшими ресурсами, существенно экономя токены на рассуждение в сравнении с ведущими открытыми нейросетями.</p> <p>Рассуждения особенно полезны в задачах, где недостаточно одного действия или простого поиска информации. Например, модель может найти противоречия между пунктами договора, провести финансовые расчёты или разобраться в сложной ошибке в коде. Флагманская модель уже доступна всем пользователям ГигаЧата, а разработчикам — бесплатно по лицензии MIT для интеграции в свои продукты. Модель станет доступна бизнесу по API в ближайшее время. </p> <p>Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Сегодня от ИИ ждут не просто быстрого ответа, а способности разобраться в сложной задаче. Теперь GigaChat способен самостоятельно разложить задачу на этапы, понять, каких данных не хватает, проверить промежуточные выводы и при необходимости изменить ход решения. Такой подход особенно важен для агентных сценариев, программирования, аналитики — везде, где результат зависит от целой последовательности решений. Это важный шаг к ИИ, который способен самостоятельно выстраивать путь к результату, действовать проактивно и взаимодействовать с другими сервисами. GigaChat — единственная российская модель с режимом рассуждений».</p> <p>Пользователь может сам определить, когда требуется рассуждение и включить режим отдельной кнопкой. На простой вопрос модель отвечает сразу, а для сложной задачи может использовать десятки тысяч токенов на поиск решения. Новая версия лучше справляется с написанием кода и агентными сценариями, в которых необходимо последовательно выполнить несколько действий. Например, при организации поездки модель может уточнить недостающие параметры, подобрать рейс и отель, проверить, укладывается ли маршрут в бюджет, а при обнаружении противоречия — перестроить план.</p> <p>Благодаря поддержке рассуждений качество GigaChat выросло почти по всем замерам, наиболее заметный прогресс — в агентских задачах, работе с функциями и инструментами, программировании и задачах со сложной логикой. По ключевым направлениям — следованию сложным инструкциям, планированию и написанию кода — GigaChat 3.5 Ultra Reasoning вплотную приблизился к лучшим мировым моделям. Например, в бенчмарке IFBench результат вырос с 44 до 77 баллов, на Natural Plan — с 64 до 80, на Live Code Bench v6 — с 56 до 85. Это заметный рост по сравнению с версией без режима рассуждений. </p> <p>GigaChat 3.5 Reasoning — экономная модель: на рассуждения она тратит существенно меньше токенов, чем ведущие открытые модели при сопоставимом качестве ответов. Например, на решение математических задач она тратит в среднем на 37% меньше токенов, чем DeepSeek V4 Flash Preview.</p> <p>Рассуждающая модель будет наиболее полезна в таких сферах, как:</p> <ul> <li>финансы и банкинг — прогнозирование сценариев, проверка сделок на соответствие нормативным требованиям;</li> <li>юриспруденция — поиск противоречий в договорах, проверка документов на соответствие регламенту или прецедентам;</li> <li>разработка ПО — поиск и исправление багов, выбор архитектуры с учётом скорости, цены и надёжности;</li> <li>логистика и планирование — построение маршрутов и расписаний с учётом сроков, бюджета и доступных ресурсов;</li> <li>образование — пошаговый разбор задач по математике, физике и программированию с проверкой каждого шага;</li> <li>наука и аналитика данных — анализ данных в несколько этапов: расчёты и проверка гипотез;</li> <li>поддержка клиентов — уточнение деталей у клиента и проверка данных в разных системах перед ответом.</li> </ul> <p>Нейросети без режима рассуждения на сложных задачах модель могут давать быстрый, но неполный ответ — просто не размышляя над ними. Новую модель целенаправленно обучили рассуждать, взял за основу базовую GigaChat 3.5 Ultra. Для обучения модель решала математические и кодовые задачи разными способами, раскладывая их на последовательные шаги. Автоматическая проверка определяла, какой вариант рассуждения привёл к правильному ответу, и закрепляла именно такие пути решения. Так она научилась не только выстраивать последовательность действий, но и самостоятельно решать, когда обратиться к внешнему инструменту или пересмотреть предыдущий шаг.</p> <p>GigaChat 3.5 Reasoning использует собственную архитектуру с технологией линейного внимания. Она помогает эффективнее работать с длинным контекстом: вместо того, чтобы повторного сопоставлять каждый новый запрос со всем предыдущим текстом модель запоминает его ключевое содержание и дополняет его по мере обработки информации.</p> Сбер представил GigaChat 3.5 Reasoning — новую флагманскую мультимодальную нейросеть с режимом рассуждений. Она … message https://www.itweek.ru/themes/detail.php?ID=235501 Thu, 10 Sep 2026 00:00:00 +0300 <p><em>На протяжении десятилетий критически важные приложения накапливали бизнес-правила, интеграции, обходные пути и зависимости быстрее, чем организации успевали их документировать, пишет в корпоративном блоге Бишваджит Махапатра, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Документация неполна, первоначальные разработчики ушли, а специалисты по приложениям выходят на пенсию, унося с собой свои критически важные институциональные знания. В результате возникает бизнес-проблема, замаскированная под технологическую. Команды по модернизации сталкиваются со скрытыми зависимостями, неожиданными требованиями и дорогостоящими переделками, потому что они не до конца понимают системы, которые пытаются изменить.</p> <p>Но прежде чем решать, что переписать, рефакторизовать, заменить или вывести из эксплуатации, CIO должны сначала получить ответ ответить на более фундаментальный вопрос: как на самом деле работает приложение?</p> <p>Искусственный интеллект меняет экономику ответа на этот вопрос. То, что раньше требовало месяцев ручного поиска, теперь можно ускорить с помощью анализа, поддерживаемого ИИ. Мне бы хотелось представить эту возможность как более глубокие знания, а не как более быстрое документирование, и что с более глубокими знаниями приходят более эффективные решения по модернизации.</p> <h3>ИИ раскрывает поведение, но не намерения</h3> <p>ИИ может анализировать исходный код, документацию, API, конфигурацию, операционную телеметрию, инциденты и историю изменений гораздо быстрее, чем ручные методы обнаружения. Все чаще платформы обнаружения организуют эти данные в графы знаний, которые связывают приложения, данные, сервисы, интеграции и бизнес-правила в рамках всей инфраструктуры.</p> <p>Такое взаимосвязанное представление помогает командам выявлять скрытые зависимости, оценивать риски интеграции, обнаруживать дублирующуюся логику и понимать, как приложения фактически ведут себя до начала модернизации.</p> <p>Но поведение — это не намерение. Правило, найденное в коде, может представлять собой допустимое бизнес-требование, устаревшую политику, обходной путь для устаревшей системы или дефект, который оставался незамеченным годами. Платформы обнаружения могут идентифицировать правило. Они не могут определить, отвечает ли оно будущему состоянию приложения.</p> <h3>Модернизация требует подтверждения того, что обнаружено</h3> <p>В большинстве систем недостающий контекст находится у людей, которые управляют системой. Они знают, какие правила отражают нормативные обязательства, какие поддерживают законные бизнес-исключения, а какие существуют просто потому, что их никто не удалил. Граф может идентифицировать правило. Только люди могут объяснить, почему это существует и соответствует ли это будущему состоянию приложения.</p> <p>Таким образом, модернизация требует двух форм обнаружения, но большинство программ финансируют только одну. Автоматизированная часть собирает, анализирует и отображает ресурсы приложений. Человеческая часть проверяет бизнес-цели посредством структурированных интервью с пользователями, операторами и владельцами бизнеса, а затем записывает эти решения как подтвержденные правила. Демонстрации поставщиков сосредоточены на первой половине. Успешные программы модернизации вкладывают равные средства и в первую, и во вторую.</p> <p>Это создает новое ограничение на реализацию. Поскольку ИИ сокращает циклы разработки и проверки, доступ к бизнес-экспертам становится узким местом. Команды обнаружения могут выявлять правила за считанные минуты, но проверка этих правил по-прежнему зависит от людей, которые их понимают. Организации, в которых команды модернизации дистанцированы от заинтересованных сторон бизнеса, могут обнаружить, что задержка принятия решений заменяет техническую сложность в качестве основного ограничения на реализацию.</p> <h3>Пусть ИИ реализует архитектуру, а не изобретает ее</h3> <p>Понимание текущего приложения — это половина задачи. Без архитектурного руководства ИИ будет переписывать код, сохраняя при этом тесные взаимосвязи, устаревшие шаблоны интеграции и накопленный долг. В результате получается работающий на устаревшей архитектуре современный код, который внедряется быстрее, чем когда-либо.</p> <p>Модернизация успешна, когда понимание текущего состояния сочетается с намерениями достижения целевого состояния. Доменные модели, ограниченные контексты, утвержденные шаблоны интеграции, средства контроля безопасности и архитектурные стандарты обеспечивают ограничения, необходимые ИИ для эффективной работы. ИИ может внедрять архитектурные решения в масштабе. Он не должен их принимать.</p> <p>Последовательность проста. Проверенные бизнес-правила определяют доменные модели. Доменные модели формируют архитектурные шаблоны. Архитектурные шаблоны становятся инженерными шаблонами. ИИ генерирует и рефакторит в этих рамках, а автоматизированное тестирование, проверка безопасности, проверка соответствия архитектуры и человеческий анализ подтверждают, что эта работа улучшает приложение, а не воспроизводит его.</p> <p>Организации, которые больше всего выиграют от модернизации с помощью ИИ, будут не теми, кто быстрее всего генерирует код. Это будут те, кто сохранит институциональные знания до того, как они исчезнут, подтвердит, какие бизнес-правила все еще важны, и целенаправленно спроектирует архитектуру, которую они хотят использовать в будущем. ИИ может ускорить каждое из этих действий. Он не может решить, какие части прошлого заслуживают места в будущем.</p> На протяжении десятилетий критически важные приложения накапливали бизнес-правила, интеграции, обходные пути … article https://www.itweek.ru/themes/detail.php?ID=235499 Thu, 10 Sep 2026 00:00:00 +0300 <p><em>Заказать DDoS-атаку сегодня дешевле чашки кофе. Злоумышленники тратят от 1</em><em> рубля за 1 Мбит/с — это в тысячи раз дешевле, чем 20 лет назад. Обсудим, что с этим делать.</em></p> <h3>DDoS перестал быть угрозой только для крупных компаний</h3> <p>Еще несколько лет назад DDoS-атаки ассоциировались прежде всего с банками, государственными сервисами, интернет-магазинами и крупными медиа. Сегодня ситуация изменилась. Целью атаки может стать практически любой сайт независимо от размера бизнеса или отрасли.</p> <p>По данным сервиса Statonline.ru, более 90% ресурсов Рунета размещены на виртуальном хостинге. И каждый из них потенциально может стать целью атаки. Одна из причин — изменение самого характера атак. Они стали «ковровыми»: злоумышленники бьют не по одному сайту, а по тысячам одновременно. И число таких атак в прошлом году <a href="https://companies.rbc.ru/news/FcIZ5wgrOW/kod-bezopasnosti-predupredil-o-roste-mnogovektornyih-ddos-atak/">выросло</a> на 83%.</p> <p>Одна из причин — изменение экономики киберугроз. По оценкам участников рынка, стоимость организации DDoS-атак за последние два десятилетия снизилась примерно в тысячу раз. Сегодня такие услуги продаются по модели массового сервиса: они доступны широкому кругу заказчиков и не требуют высокой технической квалификации.</p> <p>Одновременно меняется характер самих атак. Всё чаще злоумышленники распределяют трафик сразу на тысячи или десятки тысяч ресурсов. В результате выбор конкретной жертвы становится менее важным, а риск столкнуться с атакой возникает практически у любого владельца сайта.</p> <p>Для бизнеса это означает изменение подхода к информационной безопасности. Вопрос уже не в том, произойдет ли атака, а в том, насколько инфраструктура готова сохранить работоспособность сервисов в случае инцидента.</p> <h3>Почему традиционная модель защиты теряет эффективность</h3> <p>На протяжении многих лет защита от DDoS строилась по простой схеме: компания размещала сайт, а при необходимости подключала отдельный сервис фильтрации трафика.</p> <p>Такой подход был оправдан, пока атаки оставались относительно редкими и были нацелены преимущественно на крупные ресурсы. Сегодня он всё чаще сталкивается с ограничениями.</p> <ul> <li><strong>Первая проблема — цена. </strong>Профессиональные сервисы защиты от DDoS-атак могут стоить десятки и даже сотни тысяч рублей в год. Для крупных компаний такие расходы оправданы, однако для большинства сайтов на виртуальном хостинге стоимость защиты нередко оказывается выше стоимости самой инфраструктуры, которую она должна защищать.</li> <li><strong>Вторая проблема — архитектура.</strong> Внешние сервисы требуют дополнительной интеграции. Владельцам сайтов приходится менять DNS-настройки, корректировать сетевую архитектуру и передавать часть управления сторонним поставщикам услуг.</li> <li><strong>Третья проблема — сами атаки становятся сложнее.</strong> Всё чаще злоумышленники работают на уровне приложений (L7), имитируя действия обычных пользователей. Такой трафик значительно сложнее отличить от легитимного, поэтому традиционные механизмы фильтрации оказываются менее эффективными.</li> </ul> <p>Показательный пример — ботнет Kimwolf. В марте 2026 года он <a href="https://www.gazeta.ru/tech/news/2026/03/18/28080523.shtml?utm_auth=false">объединил</a> более 4 млн. зараженных устройств по всему миру и генерировал до 700 тыс. запросов в секунду. На Россию пришлось 6,7% устройств, участвовавших в атаках.</p> <h3>Безопасность становится частью инфраструктуры</h3> <p>Подобные изменения уже происходили в других сегментах цифровой инфраструктуры.</p> <p>Когда-то SSL/TLS-сертификаты были дополнительной услугой. Резервное копирование также подключалось отдельно. То же можно сказать о системах мониторинга, защите электронной почты и ряде других сервисов. Со временем рынок пришел к выводу, что некоторые функции настолько важны для устойчивой работы цифровых ресурсов, что должны быть встроены в инфраструктуру по умолчанию.</p> <p>Похожий процесс сегодня происходит и с защитой от DDoS-атак.</p> <p>Традиционная модель предполагает, что владелец сайта сначала запускает ресурс, а затем при необходимости подключает внешние средства защиты. Такой подход работал, пока атаки оставались относительно редким явлением и касались преимущественно крупных компаний. Однако в условиях, когда под угрозой может оказаться практически любой сайт, эта модель начинает терять эффективность.</p> <p>Во многом это связано с экономикой самой защиты. Внешние сервисы фильтрации требуют отдельного подключения, настройки и сопровождения. Для многих владельцев сайтов стоимость таких решений оказывается сопоставимой со стоимостью самой инфраструктуры. Кроме того, подключение внешней защиты часто связано с изменением DNS-настроек и IP-адресов. Для фильтрации HTTPS-трафика владельцу сайта нередко приходится передавать стороннему провайдеру SSL/TLS-сертификат и соответствующий закрытый ключ либо предоставлять возможность выпустить новый сертификат для домена. В результате критически важные элементы криптографической защиты оказываются за пределами инфраструктуры владельца ресурса.</p> <p>Поэтому рынок постепенно движется к другому подходу — переносу защитных механизмов непосредственно на уровень хостинговой платформы. В этом случае фильтрация вредоносного трафика становится частью инфраструктуры, а не отдельной надстройкой над ней.</p> <p>Для владельцев сайтов это означает несколько важных изменений:</p> <ul> <li> <strong>Защита начинает масштабироваться вместе с платформой. </strong>Один инфраструктурный контур может одновременно обеспечивать безопасность сотен тысяч сайтов без необходимости подключать отдельные сервисы для каждого ресурса.</li> <li><strong>Снижается сложность эксплуатации. </strong>Владельцам сайтов больше не нужно менять DNS-настройки, перестраивать сетевую архитектуру или разбираться в особенностях интеграции различных решений безопасности.</li> <li><strong>Упрощается экономика защиты.</strong> Безопасность перестает быть отдельной статьей расходов и становится частью базовой инфраструктурной услуги.</li> <li><strong>Повышается эффективность против современных атак. </strong>Поскольку защита встроена непосредственно в платформу, она может анализировать не только источник трафика, но и его поведение. Это особенно важно для противодействия атакам на уровне приложений (L7), которые имитируют действия обычных пользователей и всё чаще обходят традиционные механизмы фильтрации.</li> </ul> <p>По сути, рынок движется от модели «защита как отдельная услуга» к модели «защита как свойство инфраструктуры». Так же как сегодня никто не рассматривает резервное копирование или шифрование соединений в качестве дополнительной опции, встроенная защита от DDoS постепенно становится базовым требованием к платформам размещения сайтов.</p> <h3>Как меняются требования бизнеса к хостингу</h3> <p>Для компаний это означает пересмотр критериев выбора площадки для размещения сайтов.</p> <p>Если раньше основное внимание уделяли стоимости ресурсов, объему дискового пространства или производительности серверов, то сегодня всё большее значение приобретают устойчивость платформы и встроенные механизмы безопасности.</p> <p>Для многих компаний сайт стал не просто корпоративной витриной, а частью бизнес-процессов: каналом продаж, коммуникации с клиентами или основой предоставления цифровых услуг. Даже кратковременная недоступность напрямую влияет на выручку, клиентский опыт и репутацию.</p> <p>Поэтому бизнес всё чаще оценивает не отдельные инструменты защиты, а способность самой платформы обеспечивать непрерывность работы сервисов.</p> <p>Особенно заметен этот тренд среди небольшого бизнеса, где редко существуют собственные команды информационной безопасности и наиболее востребованы решения, в которых критически важные функции уже реализованы на уровне инфраструктуры.</p> <p>#IMAGE_235500#</p> Заказать DDoS-атаку сегодня дешевле чашки кофе. Злоумышленники тратят от 1 рубля за 1 Мбит/с — это … article Валентин Бостанов, руководитель направления хостинга “Руцентра” https://www.itweek.ru/themes/detail.php?ID=235497 Thu, 10 Sep 2026 00:00:00 +0300 <p>Еще несколько лет назад Confluence казался для многих компаний вполне рабочим и привычным решением. Даже после ухода Atlassian с российского рынка в 2022 году часть бизнеса продолжала использовать систему в закрытом контуре, откладывая вопрос замены. Но теперь этот сценарий подходит к завершению: on-prem-формат сворачивается, новые лицензии перестают продаваться, а привычная модель работы с Confluence становится все менее устойчивой.</p> <p>Для российских компаний это сигнал, что миграцию больше нельзя откладывать. Перейти в зарубежное облако большинству организаций мешают и требования законодательства, и вопросы безопасности, и общая зависимость от внешней инфраструктуры. Поэтому разговор сейчас идет не о том, «нужно ли менять Confluence», а о том, как сделать это спокойно, без потерь и с пользой для бизнеса.</p> <p>Уже в ближайшие годы возникнут ограничения по расширению лицензий и подключению новых пользователей. А следом наступит и полное завершение поддержки on-prem-формата. В этот момент система станет не просто неудобной, а потенциально опасной: без обновлений, без развития и с растущими рисками для безопасности.</p> <h3>Почему искать замену нужно уже сейчас</h3> <p>Любая миграция — это полноценный проект. Чем больше в компании материалов, подразделений и пользователей, которые работают с Confluence, тем выше сложность такого проекта. Если затянуть с переходом, высоки риски того, что придется все делать в спешке: разрабатывать конфигурацию нового решения, проверять функциональные требования, переносить данные. Это приводит к потерям, недовольству пользователей и лишним финансовым затратам.</p> <p>Сейчас у бизнеса есть редкая возможность пройти этот путь без спешки: спокойно сформулировать требования, сравнить варианты и выбрать платформу, которая не только заменит Confluence, но и даст запас для дальнейшего развития.</p> <h3>Как не попасть в ловушку при поиска альтернатив Confluence</h3> <p>Чаще всего компании пытаются найти максимально похожий инструмент, чтобы сохранить привычные сценарии работы с системой. Однако это не всегда лучшее решение. Confluence — платформа, призванная решать задачи, связанные хранением и управлением данными, но не все ее механики хороши. И если искать полную кальку системы, компания рискует сузить выбор и потратить слишком много сил на копирование старой логики там, где можно было бы построить более удобную и современную модель.</p> <p>Поэтому при выборе замены лучше смотреть не на то, насколько новая система похожа на Confluence, а на то, какие бизнес-задачи она закрывает. Важно понять, как в компании хранится информация, кто и как ею пользуется, где нужна жесткая структура, а где — гибкость, и какие сценарии уже сейчас не покрываются текущим решением.</p> <h3>Как выстроить миграцию</h3> <p>Прежде всего, не стоит воспринимать миграцию как простую замену одной системы на другую. Это хороший повод пересмотреть, как компания вообще работает со знаниями: что действительно нужно переносить, какие сценарии стоит сохранить, а от каких можно отказаться.</p> <p>Ориентироваться лучше не на попытку воспроизвести Confluence один в один, а на реальные бизнес-задачи. Важно понимать, какие процессы система поддерживает сейчас, что понадобится компании в будущем и не пришло ли время собрать разрозненные инструменты в единую платформу.</p> <p>Отдельное внимание стоит уделить выбору решения. Здесь полезно сравнивать не абстрактные функции, а то, как платформа закрывает ваши конкретные сценарии работы. Если в Confluence накоплен большой объем данных, обязательно проверьте наличие мигратора у новой платформы. Для крупного бизнеса также критичны устойчивость системы, ее масштабируемость и способность выдерживать высокую нагрузку.</p> <p>Не менее важен и процесс запуска. Если бизнес крупный, информации и сценариев работы много, начинать стоит с пилотного проекта или проводить запуск постепенно: это даст возможность увидеть слабые места, собрать обратную связь, сформировать группу экспертов по работе с решением.</p> <p>Еще один важный момент — обновление контента. Миграция почти всегда показывает, что значительная часть старых материалов уже неактуальна. Перенос — удобный момент, чтобы избавиться от лишнего, пересмотреть структуру и не тащить в новую систему цифровой балласт.</p> <p>Наконец, стоит заранее решить, что делать с текущей структурой Confluence. Если она логична и удобна, ее можно сохранить в новой системе. Если же пространство со временем превратилось в набор разрозненных блоков, миграция дает шанс собрать все в единый корпоративный портал и сделать работу с информацией более прозрачной и управляемой.</p> <p>Миграцию с Confluence стоит воспринимать не как вынужденную замену решения, а как возможность пересобрать подход к управлению знаниями. Если сделать это вдумчиво, компания получит не просто новую платформу, а более зрелую среду для хранения, поиска, обновления и использования информации.</p> <p>#IMAGE_235498#</p> Еще несколько лет назад Confluence казался для многих компаний вполне рабочим и привычным решением. Даже после ухода … article Дмитрий Лактионов, руководитель продуктового направления компании BSS https://www.itweek.ru/themes/detail.php?ID=235503 Wed, 09 Sep 2026 14:11:06 +0300 <p>Компания Security Vision представила очередное обновление платформ. Релиз расширяет возможности управления хранением и доступом к событиям, автоматизирует обслуживание базы данных, упрощает изменение типов событий и развивает сценарии работы с аналитическими виджетами и настройками Платформы.</p> <p>В Платформе появилась настройка горячего и холодного хранения событий. Для типов событий можно задать период нахождения в горячем хранилище, срок хранения в холодном и последующее удаление. Это позволяет переносить архивные события на более медленные диски и гибко управлять сроками их хранения.</p> <p>Доступ к событиям и алертам теперь учитывает организацию пользователя. События и алерты, для которых указана организация, доступны в соответствии с организационной принадлежностью пользователя. Таким образом, механизм Multitenancy распространяется на данные событий и алертов.</p> <p>Добавлены системные настройки для автоматического обслуживания БД Платформы: выполнение VACUUM, перестроение индексов и установка необходимых значений ключевых параметров производительности. Операции обслуживания можно выполнять по настроенному расписанию.</p> <p>В форме ввода свойства типа «Файл» появилась настройка, запрещающая загрузку исполняемых файлов. Для многострочного свойства типа «Строка» с автоматической шириной предусмотрено значение «Не задано», которое возвращает поле к ширине на весь блок карточки. Для форм ввода и вывода свойств также добавлена подсветка синтаксиса кода.</p> <p>Состав свойств типа события теперь можно изменять без реиндексации хранилища: добавлять новые свойства и удалять существующие. Это упрощает изменение структуры типов событий при развитии модели данных.</p> <p>Обновлён интерфейс раздела лицензирования и добавлена отдельная страница с информацией о лицензии. Если лицензия отсутствует или срок её действия завершён, соответствующая главная страница теперь отображается ещё до входа в Платформу.</p> <p>В виджетах добавлены действия, по выполнению которых открываются представления типа «Ссылка на внутренний URL». Также реализована возможность группировать объекты в кластеры по заданным условиям на базе постоянных и динамических значений: входных параметров, переменных и результатов блока.</p> Компания Security Vision представила очередное обновление платформ. Релиз расширяет возможности управления хранением … message https://www.itweek.ru/themes/detail.php?ID=235502 Wed, 09 Sep 2026 14:10:06 +0300 <p>Сфера информационных технологий в 2025 году стала самой атакуемой отраслью в стране — на нее пришлось 29% зафиксированных киберинцидентов. При этом нередко злоумышленники рассматривают ИТ-компании как точку входа в инфраструктуру конечной цели. Далее по числу атак следуют финансы и страхование (17%), ритейл и торговля (12%), здравоохранение и транспортно-логистический сектор (по 8%).</p> <p>Такие данные приведены в исследовании «От реагирования к предотвращению: инциденты 2025», подготовленном экспертами отдела реагирования и цифровой криминалистики Angara MTDR. В основе исследования лежат десятки успешных расследованных кейсов, каждый из которых привнес уникальный контекст, будь то финансовый сектор, промышленность, ретейл или отдельные государственные структуры. </p> <p>Что касается мотивации атакующих, наибольшая доля расследованных компанией инцидентов пришлась на атаки с целью шпионажа (40%), еще 25% — на хактивизм, и 15% на классическую финансовую мотивацию. В 20% случаев точно установить мотивацию атакующих не удалось. Существенную часть инцидентов также составили кампании, которые можно отнести к APT-группировкам. Их организаторы заинтересованы не только в немедленной выгоде, но и в длительном скрытном присутствии в инфраструктуре жертвы.</p> <p>Как отмечают исследователи, значительные изменения за прошлый год претерпел хактивизм. Если раньше в эту категорию, как правило, попадали группировки, ориентированные на публичный эффект и шум, то в 2025 году значительная часть подобных атак была связана с нанесением российским организациям максимального ущерба.</p> <p>Вместе с этим усложнился и сам ландшафт киберпреступности. С одной стороны, появились новые кластеры активности (группы, которые объединены общими инструментами, тактиками и целями), с другой — усложнилась точная атрибуция инцидентов. Например, то, что первоначально выглядело как случайная активность, во время расследования нередко оказывалось частью хорошо подготовленной кампании.</p> <p>Отдельно аналитики подчеркивают, что инструментарий атакующих все чаще дополнялся решениями на основе ИИ. В 2025 году в компании столкнулись не только с использованием сгенерированных сценариев и скриптов для автоматизации рутинных задач, но и со случаями применения C2-агентов, написанных или адаптированных с помощью ИИ. Порог входа для создания кастомного инструментария снижается, что усложняет сигнатурное обнаружение и ускоряет появление новых вредоносных программ.</p> <p>Медианный показатель обнаружения злоумышленников по итогам 2025 года составил 17 дней. В атаках с использованием программ-вымогателей показатель был ниже — всего 7 дней. Однако подобные атаки разворачиваются настолько быстро, что даже за этот срок компании чаще всего узнавали о взломе уже на финальной стадии. Если говорить об инцидентах в целом, то почти в половине случаев (45%) на обнаружение атаки уходило больше месяца: 15% атак обнаруживались в срок от месяца до полугода, 5% — от полугода до года, а 25% присутствовали в инфраструктуре больше года. Часть таких долгих случаев связана с низкоквалифицированными атаками ботнет-сетей, размещающих майнеры на уязвимых серверах, а другая — с деятельностью группировок, специализирующихся на шпионаже.</p> <p>«Количество и разнообразие киберугроз растет с каждым годом. Тем не менее мы видим, что в прошлом году заметно выросла доля организаций, которые быстрее реагирует на инциденты и подозрительную активность, охотнее взаимодействуют с командами реагирования и осознаннее инвестируют в защиту. Это однозначно позитивная тенденция. Но потенциал для роста в области кибербезопасности остается значительным, особенно в части проактивного обнаружения угроз и готовности к восстановлению после инцидентов», — добавил Артем Грибков, заместитель генерального директора Angara MTDR.</p> Сфера информационных технологий в 2025 году стала самой атакуемой отраслью в стране — на нее … message https://www.itweek.ru/themes/detail.php?ID=235495 Wed, 09 Sep 2026 10:26:15 +0300 <p><em>Анкит Джайн, соучредитель и генеральный директор Aviator, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, почему контекстом вашего ИИ-агента следует управлять как ПО и как цикл разработки контекста улучшает качество навыков, тестирование и масштабируемость.</em></p> <p>Навыки, конфигурации агентов, инструкции к промптам и файлы правил. Эти артефакты теперь определяют то, что создают ваши агенты по кодированию. Они определяют каждую строку сгенерированного кода, каждое архитектурное решение, каждое соглашение, которому агент следует или которое игнорирует. По сути, это ПО.</p> <p>Но никто к ним так не относится. Команды пишут навыки, добавляют их в репозиторий и никогда не проверяют, работают ли они после обновления модели. Конфигурации агентов копируются и переносятся между командами без версионирования. Файлы правил теряют синхронизацию с кодовой базой, которую они описывают. Когда что-то ломается, об этом сигнализирует разработчик, заметивший странный вывод и пожаловавшийся в Slack.</p> <p>Независимый ИТ-консультант Патрик Дюбуа предложил <a href="https://tessl.io/blog/context-development-lifecycle-better-context-for-ai-coding-agents">концепцию</a> того, чего не хватает: цикл разработки контекста (Context Development Lifecycle, CDLC). CDLC — это не управление окном контекста или размещение большего количества токенов в запросе. Речь идёт об управлении качеством элементов, которые попадают в контекстное окно. Актуален ли навык? Действительно ли модель правильно реагирует на него? Предоставляете ли вы контекст, который модель уже знает? Если контекст — это новый код, каков его жизненный цикл разработки?</p> <h3>Четыре фазы жизненного цикла разработки контекста</h3> <p>CDLC имеет четыре фазы, которые напрямую соответствуют тому, что мы уже делаем с кодом.</p> <p>#IMAGE_235496#</p> <p><strong>Генерация</strong> — это то, с чего все начинают. Написание навыков, создание конфигураций промптов, настройка правил агента. Это эквивалент написания кода, и именно на это сегодня уходит бóльшая часть времени.</p> <p><strong>Оценка</strong> — это тестирование. Проверка правильности линтинга во фронтенде или не слишком ли длинный синтаксис. На более сложном этапе вы запускаете сценарии: загружаете навык, задаёте конкретный вопрос, проверяете, выдаёт ли агент ожидаемый результат. Вы тестируете разные модели и версии. Вы проверяете, не пишете ли вы контекст, который модель уже знает, что приводит к нерациональному использованию токенов. Вы проверяете, активируется ли навык по правильным ключевым словам.</p> <p>Это цикл разработки через тестирование (TDD) для контекста. Пишите навык, пишите сценарий, проверяете результат, итерируете.</p> <p><strong>Дистрибуция</strong> — это доставка. На самом простом уровне это добавление навыка в репозиторий. На более зрелом уровне команды публикуют навыки в установленный реестр с версионированием, возможностью обнаружения и контролем доступа. Вставка навыка в канал Slack — это не дистрибуция, так же как отправка файла .jar по электронной почте — это не управление зависимостями.</p> <p><strong>Наблюдаемость</strong> — это мониторинг производственной среды. Используется ли навык? Выдает ли он правильные результаты? Сколько итераций проходит агент, прежде чем вмешается разработчик? Где разработчики переопределяют агента или исправляют его вывод? Это наблюдаемость для вашего контекста.</p> <h3>Не пропускайте тестирование</h3> <p>Кривая зрелости здесь идентична тому, что происходило с практиками разработки ПО за последние два десятилетия. Организации создают и распространяют. Они полностью пропускают оценку. Они отправляют навыки в производственную среду, то есть разработчикам, которые их используют, и ждут, что произойдет.</p> <p>Это напрямую сравнимо с тем, как команды игнорируют разработку через тестирование, несмотря на указания делать это. Они не знают, что такое боль, поэтому сразу передают в производство.</p> <p>Боль возникает, когда навык работает в одной версии модели, но ломается в следующей, или когда он срабатывает на неправильный вопрос и дает разработчику заведомо неверные инструкции. Когда соглашение, которое навязывал навык, было правильным полгода назад, но кодовая база с тех пор изменилась. Это те же самые режимы сбоев, которые мы видим в непротестированном коде. Регрессии, ложные срабатывания, устаревшие предположения.</p> <p>В каждой кодовой базе есть шаблоны, в которых ИИ постоянно ошибается. Слепота к соглашениям, галлюцинаторные API, код карго-культа, избыточное проектирование. Мы называем это инвариантами, или реестром ошибок ИИ. И реестр навыков, и реестр ошибок ИИ иллюстрируют один и тот же основополагающий принцип на обоих концах жизненного цикла разработки: каталогизируйте свои инженерные стандарты и передавайте их агентам.</p> <p>До генерации кода это означает навыки. На этапе проверки кода это каталог шаблонов, в которых ИИ постоянно ошибается на вашей кодовой базе. Реестр ошибок служит основой для автоматизированных проверок, выявляющих все, что осталось незамеченным. Вы не можете масштабировать качество кода, требуя от людей более тщательной проверки. Вы масштабируете его, инвестируя в механизмы контроля, которые кодифицируют ваши стандарты на обоих концах.</p> <h3>От 1x до 50x</h3> <p>Разработчик, оптимизирующий собственный цикл работы агента, получает лучшие индивидуальные результаты, но это улучшение остается с ним. Когда он исправляет ошибку в навыке, никто другой от этого не выигрывает. Когда он обнаруживает ошибку, никто другой извлекает из этого урок. ROI здесь однократный (1x).</p> <p>Дюбуа схематизирует вопрос масштабирования, используя две метрики, которые лежат в основе традиционных показателей DORA.</p> <p>Первая — это <strong>участие человека</strong>: как часто разработчику приходится вмешиваться в рабочий процесс конкретного агента? Каждое вмешательство — это сигнал о том, что контекст отсутствует или неверен. Сокращение участия человека — это прямой показатель того, насколько автономен цикл кодирования вашего агента, и он часто коррелирует со стоимостью, поскольку больше циклов означает больше затрат на агентов.</p> <p>Вторая — это <strong>эффект повторного использования</strong>: сколько разработчиков получают выгоду от улучшения одного навыка? Если один разработчик исправляет навык, и только он получает от этого выгоду, это 1x. Если это исправление попадает в общий реестр, и его получают 50 разработчиков, это 50x.</p> <p>Эти две метрики вместе заставляют организацию стремиться к общей инфраструктуре. Вы не можете сократить участие человека в масштабе без общего, хорошо протестированного контекста. Вы не можете получить эффект повторного использования без дистрибуции и версионирования.</p> <h3>Ваша команда платформы уже знает, как это делать</h3> <p>Организационная структура для этого уже существует. Платформенные команды потратили десятилетие на создание инфраструктуры, позволяющей командам разработчиков надежно выпускать код: системы контроля версий, конвейеры CI/CD, реестры артефактов, сканирование безопасности, управление зависимостями и контроль доступа. Этот подход практически напрямую применим и к разработке контекста.</p> <p>То, что команда платформы делает для репозиториев кода, она делает и для навыков. Предоставляет реестр. Настраивает контроль доступа и разрешения для групп. Создает инфраструктуру для оценки. Запускает сканирование безопасности и сообщает о результатах. Создает дашборды, показывающие, какие навыки работают хорошо, а какие ухудшаются. Отслеживает ответственность, чтобы, когда навык ломается после обновления модели, был ответственный за его исправление.</p> <p>Чего команда платформы не делает, так это не пишет навыки и не исправляет их, когда они ломаются. Команда, которая владеет предметной областью, владеет и навыком. Команда платформы предоставляет уровень управления и инструменты, здесь то же самое разделение ответственности, которое работает и для кода.</p> <p>Проблема «осиротевших навыков» уже начинает проявляться. Разработчик пишет навык, делится им, переходит в другую команду, и теперь никто его не поддерживает. Обновление модели приводит к сбою, и команда платформы по умолчанию наследует эту проблему. Это снова история с осиротевшими репозиториями GitHub. Решение то же самое: политики владения, требования к поддержке, пути вывода из эксплуатации.</p> <p>Советы Дюбуа звучат лаконично: «Не создавайте инструмент. Создайте инструмент, который создает инструмент. Команда платформы создает инструмент для тех, кто создает инструмент, который создает инструмент».</p> <h3>Замыкание цикла с помощью наблюдаемости</h3> <p>Наименее развитый этап в большинстве организаций — это наблюдаемость, хотя он и самый важный. Без него нет системы обучения. Вы вручную генерируете и распространяете контекст, надеясь, что это сработает, и исправляете ошибки, когда кто-то подает жалобу.</p> <p>Наблюдаемость агентов все еще находится на ранней стадии. Стандарты только формируются. Agent MD уже широко используется. Стандарты навыков и плагинов относительно новые. Инструментарий еще не зрелый, но схема ясна: инструментируйте своих агентов, централизуйте сигналы и анализируйте их в разных командах.</p> <p>По нашему мнению, петли обратной связи в производственной среде — это недостающий элемент в разработке с использованием ИИ. Когда что-то ломается в производственной среде, отследите это до изменения, определите категорию ошибки и передайте ее обратно как на уровень промптов, так и на уровень проверки. Этап наблюдаемости в CDLC расширяет эту идею от качества кода до качества контекста. Сигналы, собранные из журналов агентов, исправлений разработчиков и подсчета шагов, напрямую используются для создания более качественных навыков, написания более целенаправленных оценок и дистрибуции улучшенных версий.</p> <h3>Самосовершенствующаяся агентная разработка</h3> <p>Полностью замкнутый цикл выглядит как система, в которой журналы агентов используются для анализа, выявляющего пробелы. Эти пробелы генерируют новые навыки или обновления существующих. Обновленные навыки проходят оценку перед выпуском. Они распространяются через реестр с контролем версий. И цикл повторяется.</p> <p>Дюбуа реалистично оценивает конечный результат. Видение «темной фабрики», где агенты создают код без участия человека, он называет «благородным направлением, но рискованной игрой». Команды, которые приближаются к этому (те, кто может с уверенностью сказать, что они больше не читают код), — это те, кто вложили значительные средства в контекст, тестирование и инфраструктуру наблюдаемости, которые делают их агентов достаточно надежными, чтобы требовать меньшего количество человеческих вмешательств в цикле.</p> Анкит Джайн, соучредитель и генеральный директор Aviator, рассказывает на портале The New Stack о том, почему … article https://www.itweek.ru/themes/detail.php?ID=235493 Wed, 09 Sep 2026 10:11:05 +0300 <p><em>Логистика с ее сложными процессами и огромными массивами данных — одна из тех отраслей, где искусственный интеллект способен изменить саму архитектуру бизнеса. Однако произойдет это не благодаря появлению очередной языковой модели. Рассмотрим, из каких уровней складывается ИИ-инфраструктура и какие ограничения сегодня существуют на каждом из них.</em></p> <h3>ИИ как инфраструктура</h3> <p>Сегодня искусственный интеллект воспринимается бизнесом скорее как отдельный продукт, и разговор о нем обычно сводится к сравнению моделей. Но на самом деле смотреть стоит гораздо шире. Бизнес начинает получать ощутимый эффект только тогда, когда одновременно развиваются три компонента:</p> <ul> <li> наличие самих моделей искусственного интеллекта;</li> <li> компетенции людей;</li> <li> наличие качественных данных.</li> </ul> <p>Но и это лишь фундамент. Если представить эту систему в виде пирамиды, то в ее основании находятся именно эти три компонента. Следующий уровень — ИИ-агенты и коннекторы, которые позволяют им взаимодействовать между собой и с внешними системами. И на вершине этой пирамиды находится бизнес-эффект — возможность быстрее, точнее и с меньшими затратами решать реальные задачи.</p> <p>Именно поэтому бизнесу сегодня стоит сосредоточиться не столько на вопросе, какая модель окажется сильнее, сколько на том, насколько быстро удастся построить всю пирамиду — инфраструктуру вокруг ИИ.</p> <h3>Проблемы российских моделей</h3> <p>С точки зрения моделей ситуация в России остается сложной. Наиболее качественные и развитые мировые решения, такие как Claude от Anthropic и ChatGPT, находятся фактически вне легального контура использования для российского бизнеса. Бизнес не может официально приобрести модель, оплачивать ее использование, учитывать эти расходы в финансовом контуре и выстраивать полноценную корпоративную инфраструктуру вокруг нее.</p> <p>Российские модели пока уступают мировым по возможностям. Пока развитие отечественных решений сосредоточено преимущественно на пользовательских чат-ботах. Например, GigaChat получил инструменты для создания ИИ-агентов совсем недавно, тогда как у OpenAI и Anthropic они появились значительно раньше. За это время вокруг зарубежных моделей успела сформироваться зрелая экосистема инструментов, интеграций и практических сценариев внедрения, тогда как российские решения только проходят этот этап.</p> <h3>Даже идеальная нейросеть бесполезна без данных</h3> <p>Однако основная проблема с внедрением ИИ в России сегодня не в моделях и не в людях, которые пока только начинают накапливать практический опыт работы с нейросетями. Самый ценный ресурс — понятные, структурированные данные: это основа для принятия решений и одновременно материал, на котором обучаются сами модели.</p> <p>Например, кажется, что подготовить коммерческое предложение перевозчику — типичная задача для человека. На самом деле это практически идеальный кейс для ИИ. Но чтобы агент мог рассчитать тариф, ему нужна информация:</p> <ul> <li> собственная база тарифов и алгоритмы, которые описывают, как формируется стоимость перевозки;</li> <li> исторические данные: количество рейсов с конкретным перевозчиком и клиентом, качество работы, платежную дисциплину, возникавшие проблемы и претензии — возможно, эти риски необходимо закладывать в тариф заранее;</li> <li> система также должна учитывать будущие тренды: изменение стоимости топлива, инфляцию, динамику заработных плат водителей;</li> <li> еще один важный элемент — рыночные данные. Целевая маржинальность на рынке может составлять 5, 15 или 30% — и выбор зависит от текущего баланса спроса и предложения по конкретному направлению. Для этого нужны дополнительные коэффициенты и отраслевые базы данных.</li> </ul> <p>Фактически сейчас человек выполняет всю эту работу самостоятельно: он держит множество факторов в голове, опирается на опыт и часто интуитивно формирует предложение. Это как раз задача, где искусственный интеллект может быть особенно эффективен, но без качественных данных он будет решать ее ограниченно.</p> <p>И здесь у российской логистики есть серьезная проблема. Рынок автологистики в России сильно деконсолидирован, и даже крупнейший игрок занимает всего около <nobr>2-3%</nobr> рынка. У нас фактически нет сформированных единых больших баз данных, которые позволяли бы бизнесу строить алгоритмы с использованием ИИ.</p> <h3>Кто станет владельцем инфраструктуры данных</h3> <p>Если данные — главное топливо для искусственного интеллекта, то кто будет владеть этим ресурсом?</p> <p>Мы видим, что государство уже формирует базовую цифровую инфраструктуру, вводя обязательный электронный документооборот. В перспективе такая система способна аккумулировать информацию о значительной части перевозок на рынке. Это может стать серьезной основой для дальнейшего применения искусственного интеллекта в логистике, однако остается открытым вопрос: насколько эти данные будут доступны бизнесу для практического использования.</p> <p>Если регуляторные требования помогают сформировать единое информационное пространство и накапливать данные, то бизнес способен наполнить его практической ценностью, создавая сервисы на основе этих данных. Хороший пример — компания ATI, которая собирает данные по ставкам на перевозки в России. Сейчас это один из основных источников информации по тарифам на рынке. Модель построена на добровольной основе: компания платит участникам за предоставление данных, консолидирует их и затем предоставляет бизнесу в удобном формате.</p> <p>Потенциал у такого подхода действительно большой. Если в России развитие пойдет ближе к китайской модели, где участников рынка стимулируют работать через цифровые платформы, а сами платформы создают полезные сервисы для бизнеса, эффект, вероятно, будет очень высоким. В такой модели компании заинтересованы в использовании платформ не только из-за требований регуляторов, а потому что понимают, какую конкретную пользу получают от обмена этой информацией.</p> <h3>Настоящая революция начнется в эпоху ИИ-агентов</h3> <p>Итак, для построения полноценной ИИ-инфраструктуры требуются три элемента: сами модели, люди с компетенциями и качественные данные. Хотя на каждом из этих уровней пока есть свои ограничения, фундамент для будущей ИИ-инфраструктуры уже постепенно формируется. По мере его развития будут появляться новые классы решений.</p> <p>Именно следующий этап — появление большого количества специализированных агентов, которые смогут работать поверх этой инфраструктуры, взаимодействовать между собой и самостоятельно выполнять бизнес-задачи — может стать настоящим прорывом с точки зрения повышения эффективности бизнеса.</p> <p>В перспективе можно представить ситуацию, когда в логистической компании из 20 сотрудников, условно, 17 цифровых агентов будут закрывать рутинные процессы, а люди будут заниматься более сложными задачами, требующими экспертизы и стратегических решений.</p> <p>При этом сами агенты будут развиваться в двух основных направлениях.</p> <p>Первое — внутренние агенты. Это системы, которые помогают решать задачи внутри компании: формировать дополнительные соглашения, создавать должностные инструкции, готовить коммерческие предложения. Подобные решения уже начинают появляться во многих отраслях, и первые результаты подтверждают их эффективность. Так, согласно свежему <a href="https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-future-of-b2b-sales-how-growth-champions-rewire-their-playbooks-with-ai">исследованию</a> McKinsey «The Future of B2B Sales», 59% компаний-лидеров роста сообщили, что благодаря ИИ повысилась эффективность работы их отделов продаж, а внедрение ИИ-агентов хотя бы в один из ключевых процессов способно высвободить дополнительно около 10% времени продавцов.</p> <p>Однако прорыв, вероятнее всего, будет связан со вторым типом — агентами, которые смогут взаимодействовать не только с внутренними системами компании, но и с внешним рынком. Например, внешний агент сможет искать подходящий транспорт не только из парка компании, а среди всех доступных участников рынка. Или готовить коммерческое предложение, анализируя тендеры и взаимодействуя с внешними торговыми площадками.</p> <p>Однако потребуется еще один важный элемент — коннекторы. Сегодня люди взаимодействуют через привычные каналы: мессенджеры, электронную почту, видеосвязь. Но человеку достаточно получить сообщение, а дальше он сам найдет нужные данные, вспомнит контекст, проверит информацию, оценит риски и примет решение. Для ИИ-агента такой подход неэффективен. Ему недостаточно просто передать сообщение — вместе с ним необходимо предоставить структурированные данные, бизнес-контекст, правила принятия решений и возможность выполнить нужное действие в другой системе.</p> <p>Именно поэтому в будущем будут развиваться специальные коннекторы — цифровые каналы взаимодействия ИИ-агентов. Коннектор можно сравнить с мессенджером для ИИ-агентов, однако его роль выходит далеко за рамки обмена сообщениями. Это среда, которая обеспечивает агенту доступ к данным, контексту и инструментам, необходимым для принятия решений и выполнения действий. В логистике это может быть поиск перевозчика, расчет тарифа, проверка контрагента или оформление документов; в других отраслях — свои специализированные сценарии.</p> <h3>Победят не те, у кого лучше нейросеть</h3> <p>Сегодня рынок по-прежнему сосредоточен на сравнении языковых моделей: какая лучше и сильнее. Однако конкурентное преимущество будут создавать не сами модели, а вся инфраструктура вокруг них.</p> <p>В логистике это приобретает особое значение. Сегодня, чтобы найти подходящий транспорт, специалист иногда обзванивает десятки перевозчиков, выясняя, у кого есть свободная машина на нужном направлении. Теоретически эту задачу мог бы выполнять ИИ-агент — быстрее, дешевле и точнее. Но для этого ему нужен доступ к данным обо всем рынке, а не только к информации одной компании. Пока такой системы нет, даже самые совершенные модели не способны раскрыть свой потенциал.</p> <p>В конечном счете главным фактором развития станет уже не сама языковая модель, а инфраструктура вокруг нее. Когда появятся качественные данные, механизмы их обмена, специализированные коннекторы и экосистема ИИ-агентов, искусственный интеллект сможет решать задачи не отдельных компаний, а всей отрасли. Именно этот этап и станет настоящим переломным моментом — будь то для логистика или любая другая сфера.</p> <p> #IMAGE_235494#</p> Логистика с ее сложными процессами и огромными массивами данных — одна из тех отраслей, где … article Михаил Чушков, генеральный директор онлайн-сервиса Pooling https://www.itweek.ru/themes/detail.php?ID=235491 Wed, 09 Sep 2026 10:02:54 +0300 <p><em>Создать работающий прототип искусственного интеллекта сегодня значительно проще, чем довести его до промышленного внедрения. Современные модели позволяют быстро показать убедительный результат, однако именно после успешного пилота начинается самая сложная часть работы. На основе опыта разработки AI-решений для медицины и юриспруденции </em><em>я</em><em> разбер</em><em>у</em><em>, почему многие проекты так и не становятся полноценными продуктами и какие ошибки чаще всего приводят к этому.</em></p> <p>По данным McKinsey «Global Survey 2025», 88% респондентов сообщили, что в их организации регулярно используют AI хотя бы в одной бизнес-функции. При этом почти две трети организаций ещё не начали масштабировать AI на уровне всей компании. Лишь 39% респондентов сообщили о влиянии AI на EBIT на уровне всей организации.</p> <p>Этот разрыв показателен. Ограничением всё реже становится техническая реализация AI-модели. Основные проблемы начинаются после того, как модель впервые выдала правильный ответ.</p> <p>Похожая картина видна и в российских данных. В исследовании ИСИЭЗ НИУ ВШЭ «Применение искусственного интеллекта в российских компаниях» отмечается, что среди организаций, использующих ИИ, значимыми барьерами остаются не только затраты, но и инфраструктура, нехватка квалифицированных кадров, дефицит данных, сложность интеграции ИИ в бизнес-процессы, законодательные ограничения и качество данных.</p> <p>Пилот должен доказать не только техническую возможность, но и три более важные вещи: организация готова платить за продукт, пользователи хотят его применять и решение можно встроить в реальный процесс без потери всей ожидаемой экономии. Если хотя бы одно из этих условий не выполнено, даже сильный ИИ рискует остаться демонстрацией.</p> <p>Главная причина неудачи большинства AI-проектов — не слабая модель, а разрыв между демонстрацией технологии и ее использованием в реальном рабочем процессе.</p> <h3>Демо оптимизирует ответ, бизнес — весь процесс</h3> <p>На демонстрации AI-продукт обычно получает подготовленные данные и за несколько секунд может сформировать хорошее впечатление. На этом фоне легко решить, что основная часть задачи уже выполнена. Но ответ модели — только один этап рабочего процесса. После него результат необходимо проверить, исправить, согласовать, сохранить в корпоративной системе и использовать для принятия решения. До обращения к модели данные также нужно найти, подготовить и передать в подходящем формате.</p> <p>Поэтому локальное ускорение одной операции не гарантирует ускорения процесса целиком.</p> <p>AI ускоряет отдельную операцию. Бизнес оценивает, насколько быстрее завершился весь процесс. Именно здесь чаще всего возникает разрыв между успешным пилотом и реальным внедрением.</p> <p>Похожий эффект виден в разработке ПО. Исследование NBER по более чем 100 тыс. GitHub-разработчиков показало, что для автономных AI-инструментов рост coding activity составил около 180%, но рост фактически выпущенных релизов — только около 30%. Авторы объясняют разрыв последующими человеческими и производственными ограничениями: проверкой, интеграцией и выпуском.</p> <p>С похожей ситуацией я сталкивался при разработке AI-решений для медицины и юриспруденции. Даже когда модель демонстрировала высокое качество на тестовых сценариях, этого было недостаточно для внедрения. Основная работа начиналась после получения ответа модели: нужно было встроить систему в существующие процессы, сократить объем ручной проверки и сделать так, чтобы использование AI действительно экономило время специалиста, а не создавало новые этапы работы.</p> <p>Для отраслевого AI действует тот же принцип. Система может подготовить документ за минуту, но специалисту потребуется значительно больше времени, чтобы проверить факты, источники и применимость результата. Она может предложить решение, которое затем придётся вручную переносить в другую информационную систему. Она может ускорить работу одного сотрудника и одновременно создать дополнительную очередь у следующего участника процесса. Поэтому заказчика интересует не скорость первого ответа, его интересует время до завершенного и проверенного результата.</p> <p>Перед началом разработки полезно ответить на несколько вопросов: какое действие пользователя должно измениться, какой этап процесса исчезнет или сократится, сколько времени займет проверка, что произойдёт после получения ответа и не возникнет ли новое узкое место дальше по цепочке.</p> <h3>Позднее вовлечение пользователей создает мертворожденные продукты</h3> <p>Одна из самых распространённых ошибок — подключать будущих пользователей только на этапе пилота. Эта ошибка встречается и в начинающих стартапах, и во внутренних командах крупных компаний. Разработчики несколько месяцев создают решение, исходя из собственного представления о работе врача, юриста, бухгалтера, инженера, оператора или менеджера.</p> <p>На демонстрации всё выглядит убедительно. Данные подготовлены, сценарий заранее выбран, сложные случаи исключены или специально подобраны такие, с которыми решение справляется. Но когда продукт впервые попадает к специалисту, возникают базовые вопросы.</p> <p>Как вообще пользоваться решением? Как оно будет интегрировано в привычные рабочие инструменты? На чем основан ответ системы? Откуда должны поступать данные? Что делать с ответом? Почему новый сценарий лучше привычного? Кто отвечает, если результат окажется неверным? Будет ли у специалиста время проверять вывод модели?</p> <p>Если эти вопросы появляются в конце разработки, команда проверяет продуктовую гипотезу слишком поздно. Так возникает демонстрационный долг: набор неподтвержденных предположений о поведении пользователя, данных, интеграциях и ответственности. Чем дольше команда строит продукт, не проверяя эти предположения, тем дороже становится их пересмотр.</p> <p>Обратная связь специалиста нужна не после создания MVP, а до выбора основного сценария. Недостаточно провести интервью и попросить пользователя перечислить проблемы. Полезнее наблюдать за реальной работой: какие системы он открывает, где копирует данные, что перепроверяет, кому передает результат и в каких случаях действует в обход официального процесса, где сейчас узкое горлышко.</p> <p>В профессиональных областях пользователь не просто оценивает удобство интерфейса. Он помогает определить саму логику продукта: какие данные обязательны, какие исключения критичны, когда автоматизация допустима, где нужен контроль человека и какие ошибки нельзя пропустить.</p> <p>Поэтому участие пользователя не должно превращаться в бесконечный сбор пожеланий. Команда должна проверять конкретные гипотезы: возникает ли проблема достаточно часто, меняет ли прототип поведение специалиста, возвращается ли он к продукту без напоминаний, готов ли использовать его на реальных данных и становится ли процесс быстрее или качественнее после проверки результата.</p> <p>Если ответы отрицательные, продукт нужно менять, а не дополнять новыми функциями. На старте важнее не пытаться создать идеального ИИ-юриста, врача или бухгалтера, а качественно закрыть одну актуальную задачу и только после успешного MVP расширять функциональность. Иначе команда рискует создать продукт-Франкенштейн: он претендует на решение всего сразу, но по факту не закрывает достаточно хорошо ни один сценарий.</p> <p>На раннем этапе гораздо ценнее решить одну повторяющуюся задачу лучше существующих инструментов, чем пытаться автоматизировать весь процесс сразу. Именно так появляются продукты, которыми специалисты начинают пользоваться каждый день.</p> <h3>Пользователь, эксперт и покупатель — не один человек</h3> <p>Для вертикального AI-продукта недостаточно найти отраслевого эксперта.</p> <p>На практике я быстро убедился, что понимание профессиональной задачи — только часть работы. Даже если специалисты высоко оценивают решение, это еще не означает, что оно будет внедрено. Для появления продукта в организации должны совпасть интересы сразу нескольких участников процесса.</p> <p>Эксперт помогает понять процесс, профессиональные требования и цену ошибок. Но он не обязательно распоряжается бюджетом и может не влиять на закупку.</p> <p>В сложных B2B-продажах вокруг продукта обычно возникает несколько ролей: специалист, который будет им пользоваться; эксперт, помогающий его проектировать; внутренний сторонник, продвигающий решение; владелец бюджета; лицо, подписывающее договор; ИТ и информационная безопасность; юридическая служба и закупки.</p> <p>Команда может сделать отличный продукт для пользователя, но не иметь доступа к покупателю. В этом случае продажи не начнутся. Обратная ситуация тоже возможна: руководитель видит экономический смысл и готов приобрести решение, хотя часть специалистов относится к нему скептически. Такой сценарий может привести к первому контракту, но не гарантирует регулярного применения.</p> <p>Первая продажа и устойчивое внедрение — разные задачи. Лицо, принимающее решение, определяет вероятность контракта. Пользователь определяет вероятность регулярного использования, измеримого результата и продления. Продать AI-продукт и добиться его ежедневного использования — две разные задачи. Первый контракт подтверждает интерес рынка. Регулярная работа пользователей подтверждает ценность продукта.</p> <p>Поэтому до создания полноценного MVP команде полезно составить карту участников: кто испытывает проблему, кто будет пользоваться системой, кто получает экономический эффект, кто выделяет бюджет, кто может заблокировать внедрение и через какой контакт можно выйти на организацию.</p> <p>В узких B2B- и B2G-сегментах человек, умеющий открывать двери к нужным лицам, иногда решает половину коммерческой задачи. Хороший продукт без канала выхода на покупателя может годами оставаться экспериментом.</p> <h3>Считать нужно стоимость проверенного результата</h3> <p>Экономику AI часто оценивают через стоимость модели и время генерации. Для профессиональных продуктов этого недостаточно. Полная стоимость операции включает получение и подготовку данных, работу модели, проверку человеком, исправление результата, перенос в рабочую систему и ожидаемую стоимость возможных ошибок. Для бизнеса важна не стоимость работы модели, а стоимость получения проверенного результата. Именно этот показатель определяет экономический эффект внедрения.</p> <p>Особенно важна стоимость проверки. Если специалисту нужно заново прочитать все источники, чтобы убедиться в правильности подготовленного анализа, продукт может почти не экономить время. Если пользователь после автоматической обработки данных вынужден заново собирать структуру результата, автоматизация создает дополнительную работу.</p> <p>Средняя точность модели здесь тоже мало говорит об экономике. Десятипроцентная доля ошибок может быть приемлемой, если ошибки легко заметить и дёшево исправить. Она может быть недопустимой, если результат выглядит убедительно, ошибка обнаруживается поздно и влияет на последующие решения.</p> <p>В профессиональных процессах особенно опасны ошибки, которые не выглядят как ошибки. Пользователь видит аккуратно оформленный текст, таблицу или рекомендацию и тратит меньше внимания на проверку. В результате риск смещается с этапа генерации на этап принятия решения.</p> <p>Поэтому полезнее измерять не только точность модели, но и продуктовые показатели: время до проверенного результата, долю ответов, потребовавших исправления, частоту критических пропусков, долю результатов, принятых пользователем, долю случаев, переданных человеку, и стоимость одного полностью завершенного случая.</p> <p>Отдельно важно раскладывать процесс на этапы. Недостаточно сказать, что AI-автоматизация улучшила работу специалиста. Нужно понимать, сколько ресурсов уходит на подготовку данных, поиск релевантной информации, проверку источников, формирование итогового ответа, перенос результата в рабочую систему и последующую коммуникацию.</p> <p>Но сами метрики мало что дают, если процесс рассматривается как единая неделимая задача. Его нужно раскладывать на отдельные операции: подготовку документов, поиск релевантной информации, перепроверку источников, формирование итогового ответа, перенос данных в рабочую систему и последующую коммуникацию.</p> <p>Такая декомпозиция позволяет понять, какой именно участок ИИ действительно улучшает, а где эффект теряется. Иногда оказывается, что на первом этапе не нужно автоматизировать всю цепочку. Более сильной продуктовой гипотезой может быть узкое решение, которое качественно закрывает один дорогой этап, например, поиск и структурирование релевантной информации для специалиста, оставляя финальный вывод или коммуникацию человеку.</p> <p>Поэтому главный вопрос для разработчиков должен звучать не «насколько хорошо модель отвечает?», а «насколько качественно и надежно система закрывает выбранный участок реальной задачи и делает ли это выгоднее текущего процесса?»</p> <h3>Пилот должен проверять организацию, а не только технологию</h3> <p>У пилота почти всегда более благоприятные условия, чем у будущего продукта. В нём участвуют мотивированные пользователи, команда разработчиков быстро помогает при сбоях, данные можно подготовить вручную, нестандартные случаи временно исключаются, интеграции заменяются переносом информации между системами. Такой пилот может подтвердить техническую гипотезу, но ничего не сказать о готовности к эксплуатации.</p> <p>За последние несколько лет я пришел к выводу, что пилот проверяет не столько технологию, сколько готовность организации изменить собственные процессы. Если компания не готова встроить новое решение в ежедневную работу, даже успешная демонстрация не приведет к масштабному внедрению.</p> <p>Промышленное внедрение требует ответов на другие вопросы: кто отвечает за результат, как система получает реальные данные, как управляются права доступа, кто устраняет сбои, как обучаются новые сотрудники, из какого бюджета оплачивается эксплуатация, что происходит после обновления модели и по каким критериям решение масштабируется или закрывается. Именно эти вопросы часто оказываются важнее качества демонстрации.</p> <p>Российский аналитический доклад «Индекс готовности приоритетных отраслей экономики Российской Федерации к внедрению искусственного интеллекта» рассматривает готовность к ИИ не только через наличие технологий, но и через нецифровые факторы: государственную политику, регулирование, стратегическое планирование, корпоративное управление, кадры и компетенции, исследования и разработки. Отдельно учитываются цифровые основы: инфраструктура, данные, доверие и безопасность.</p> <p>На практике это означает, что зрелость AI-проекта определяется всей системой вокруг модели: процессами, ответственностью, инфраструктурой и готовностью сотрудников использовать новый инструмент.</p> <p>Отдельная проблема — интеграции. Во многих отраслях рабочий процесс уже распределен между несколькими системами. Если AI-инструмент требует от пользователя копировать данные между окнами, вручную переносить результат и отдельно проверять источники, часть экономии исчезает. Кроме того, у разных клиентов могут быть разные вендоры внутрикорпоративных систем. В таком случае именно вопрос интеграции может стать главным узким горлышком всего проекта.</p> <h3>Важно вовремя признать неверную гипотезу</h3> <p>После нескольких кварталов разработки команде становится сложно отказаться от продукта. Уже потрачен бюджет, руководству обещан результат, подготовлены презентации, участники проекта связали с ним свою профессиональную репутацию.</p> <p>С этой ситуацией сталкиваются и стартапы, и крупные компании. Чем больше времени и ресурсов вложено в проект, тем сложнее объективно оценить, действительно ли он решает проблему пользователя или команда продолжает развивать его по инерции.</p> <p>Если видно, что продукт не находит ожидаемого рыночного спроса, вместо признания ошибки иногда начинается поиск любого подразделения или внешнего клиента, которому можно предложить уже созданное решение. Команда перестает искать продукт под проблему и начинает искать проблему под продукт. Продажа в таком случае становится способом оправдать предыдущую работу, но необходимо различать проблемы выхода на рынок и отсутствие самой потребности. Самая дорогая ошибка в AI — не отказаться от неверной гипотезы вовремя.</p> <p>Если специалисты регулярно используют решение, самостоятельно возвращаются к нему и готовы мириться с несовершенствами, но компания не может выйти на владельца бюджета, вероятно, проблема находится в продажах.</p> <p>Если пользователь открывает продукт только по просьбе команды, не меняет привычный процесс и не замечает его улучшения, проблема, скорее всего, находится в продуктовой гипотезе.</p> <p>Если покупатель заинтересован, но стоимость интеграции превышает ожидаемый эффект, нужно менять архитектуру или целевой сегмент.</p> <p>Чтобы не принимать решения под влиянием уже понесенных затрат, проект полезно разделить на последовательные проверки.</p> <p>Первая проверка — проблема. Подтверждена ли она реальным поведением, а не только интервью?</p> <p>Вторая — пользователь. Становится ли его работа лучше после проверки результата? Продолжает ли он пользоваться продуктом без напоминания?</p> <p>Третья — покупатель. Существует ли владелец бюджета и понятный мотив для покупки?</p> <p>Четвертая — экономика. Сокращается ли полная стоимость процесса? Повышается ли итоговая ценность результата?</p> <p>Пятая — эксплуатация. Способна ли организация поддерживать решение без постоянного участия команды разработки? Как и на каких условиях будет осуществляться дальнейшее взаимодействие покупателя и разработчика?</p> <p>После каждого этапа должно оставаться три равноправных варианта: продолжить развитие продукта, изменить направление или остановить проект. Отказ от первоначальной гипотезы — это не поражение, а результат качественной проверки идеи.</p> <p>На практике успех AI-проекта определяется не тем, насколько быстро команда обучила модель, а тем, насколько рано она получила честные ответы на ключевые вопросы: существует ли проблема, готовы ли специалисты менять свои рабочие процессы, увидит ли бизнес экономический эффект и сможет ли организация поддерживать решение после внедрения.</p> <p>Именно поэтому главный показатель зрелости AI-команды сегодня — не количество разработанных моделей, а способность вовремя отказаться от неверных предположений и сосредоточиться на задачах, которые действительно создают ценность для пользователей и бизнеса.</p> <p>Путь от AI-пилота до востребованного продукта начинается не с обучения модели, а с понимания задачи, которую действительно необходимо решить.</p> <p>#IMAGE_235492#</p> Создать работающий прототип искусственного интеллекта сегодня значительно проще, чем довести его до промышленного внедрения … article Владимир Воробьев, генеральный директор АО “Экспертные платформы” https://www.itweek.ru/themes/detail.php?ID=235489 Tue, 08 Sep 2026 17:29:26 +0300 <p>Cloud Advisor представил первый в России отчёт о состоянии облачной безопасности: у 88% компаний — критические уязвимости на периметре, в каждой четвёртой инфраструктуре — вредоносное ПО.</p> <p>Российский бизнес стремительно осваивает публичные облака: всё больше компаний переносят туда свои сервисы и данные. Однако рост популярности облачных технологий закономерно привлекает и внимание злоумышленников. </p> <p>Чтобы оценить реальный уровень защищённости российских облачных инфраструктур, компания Cloud Advisor — #1 CNAPP в России — разработчик единой платформы облачной безопасности, проанализировала обезличенные данные десятков организаций: суммарно более 40 000 виртуальных машин в облаках Cloud.ru и Yandex Cloud. Результаты вошли в отчёт «Состояние облачной безопасности в России 2026».</p> <p>Главный вывод исследования: проблемы облачной безопасности носят системный характер и встречаются независимо от облачного провайдера, отрасли и размера компании.</p> <p>«Отчёт показывает тревожную картину — защищённость облачных инфраструктур в России остаётся низкой: практически нет организаций, у которых не были обнаружены критические проблемы. Причины сложившейся ситуации: нехватка знаний и экспертизы в облачной безопасности, а также попытки защитить облако привычными инструментами из on-premises сред. Такие решения не учитывают специфику облачных технологий и не способны обеспечить комплексную защиту. На глобальном уровне для защиты облаков стандартом де-факто стали специализированные решения класса CNAPP, которые обеспечивают полный контроль над облачной инфраструктурой. Отчёт — ориентир, по которому каждая компания может оценить возможные слабые места в своей инфраструктуре и начать действовать», — прокомментировал Михаил Захряпин, генеральный директор Cloud Advisor. </p> <p>Критические уязвимости на периметре — у 88% организаций. На публично доступных виртуальных машинах у 88% компаний есть уязвимости с CVSS-оценкой выше 9,0. Одна из причин — традиционные агентские и сетевые сканеры не успевают за темпом изменений в облаке и неизбежно создают «слепые зоны».</p> <p>В каждой четвёртой организации атака уже состоялась. У 24% организаций в инфраструктуре обнаружено вредоносное ПО. Это не потенциальный риск, а свидетельство состоявшегося проникновения: злоумышленники уже могли получить доступ к данным или использовать ресурсы компании для DDoS-атак и рассылки спама.</p> <p>Секреты на публично доступных ресурсах в открытом виде — у 39% организаций. На публично доступных виртуальных машинах у 39% компаний хранятся в открытом виде ключи, токены и пароли. Скомпрометировав такой ресурс, атакующий получает возможность бокового перемещения (lateral movement) по остальной инфраструктуре.</p> <p>Половина пользовательских учётных записей без MFA. 48% пользовательских учётных записей не защищены многофакторной аутентификацией, а у каждой второй организации есть привилегированная учётная запись без второго фактора. При этом 24% учётных записей не использовались более 90 дней — их удаление сократит эту часть поверхности атаки на четверть.</p> <p>Большинство ресурсов работает вхолостую. 55% виртуальных машин загружены менее чем на 10%. Оптимизация неиспользуемых и недостаточно загруженных ресурсов позволяет снизить затраты на облако до 30%.</p> <p>Полная версия отчёта содержит расширенную статистику и практические рекомендации по устранению угроз в публичном облаке. Компании могут использовать его как чек-лист для выявления рисков в собственной инфраструктуре, бенчмарк для сравнения своего уровня защищённости с другими пользователями облаков, набор аргументов для обоснования бюджета на информационную безопасность, а также — дорожную карту по защите облачной инфраструктуры на ближайший год.</p> Cloud Advisor представил первый в России отчёт о состоянии облачной безопасности: у 88% компаний — … message https://www.itweek.ru/themes/detail.php?ID=235488 Tue, 08 Sep 2026 17:27:23 +0300 <p>Физический ИИ берет числом, при этом глобальная индустрия ищет пути эволюции LLM. Это следует из результатов опроса, проведенного ICT.Moscow в рамках исследования перспективных технологических тем.</p> <p>ICT.Moscow опросил более 200 российских специалистов в сфере искусственного интеллекта, чтобы определить, какие не массовые тренды, по данным глобальных прогнозов и анализа популярных тем в отечественных медиа, имеют потенциал к последующему развитию в ближайшее время в России. Респондентам было предложено выбрать несколько перспективных, по их мнению, вариантов из предложенных.</p> <p>Для интерпретации результатов авторами также была составлена визуализация с хронологией возникновения того или иного термина и отнесения его к целевой концепции ИИ, а также прошлому или текущему стеку этой технологии.</p> <p>Среди трендов, исследуемых в опросе, почти половина относится к направлению физического ИИ (Physical AI). В этой группе наиболее приоритетными (43%) стали VLA-модели (Vision-Language-Action Models). Их применяют в робототехнике для объединения компьютерного зрения, обработки естественного языка и управления физическими устройствами. Почти каждый третий проголосовавший (31%) ожидает дальнейшего развития моделей мира (World Models). Еще 23% получили более общие крупные модели действия (Large Action Models), создаваемые для того, чтобы реагировать действиями на получаемую внешнюю информацию. Этот термин применяется как в области робототехники, так и для обозначения ИИ-агентов, не имеющих физической оболочки. Среди ответов, относимых к физическому ИИ (но не ограничивающихся им), пока меньше всего ожиданий (18%) у респондентов связано с крупными поведенческими моделями (Large Behavior Models, LBM), которые нужны для понимания действий человека в физическом мире или виртуальной среде и обучения на их основе, с тем чтобы их моделировать или воспроизводить.</p> <p>Базовые модели (Foundation Models) хоть и находятся уже в списке не самых распространенных в аналитике и новостях понятий, тем не менее собрали 23% оценок у опрошенных. Сам термин во многом уже воспринимают как синоним LLM, и его смысловое наполнение пересматривается по мере развития этого класса моделей.</p> <p>Однако тот факт, что развивавшиеся с 2015 года диффузионные модели (Diffusion Models) переживают новую волну интереса, а также появление моделей взаимодействия (Interaction Models) как нового вида UX в контексте нативных мультимодальных нейросетей, цель которых — сделать более естественным общение человека с моделью, скорее всего, говорят о том, что в индустрии ищут новый виток развития LLM, в том числе в части взаимодействия их с человеком, или даже альтернативы им. В данном опросе за них отдали 23% и 17% голосов соответственно.</p> <p>Отдельное место среди вариантов ответов занимают целевые представления об ИИ, которые многими воспринимаются как финальные точки развития технологии и продолжают сохранять этот статус уже не одно десятилетие. Речь идет об общем (или сильном) искусственном интеллекте (Artificial General Intelligence, AGI) и искусственном сверх- или суперинтеллекте (Artificial Superintelligence, ASI). Тем не менее даже такие пока что гипотетические и отдаленные концепции получили поддержку как имеющие потенциал для развития. За общий ИИ проголосовали 22% участников, а за более отдаленный сверхинтеллект — 12%.</p> Физический ИИ берет числом, при этом глобальная индустрия ищет пути эволюции LLM. Это следует из результатов опроса … message https://www.itweek.ru/themes/detail.php?ID=235486 Tue, 08 Sep 2026 17:24:24 +0300 <p>Компания «Индид», российский разработчик решений в области защиты айдентити, представила новую версию Indeed Privileged Access Manager (Indeed PAM) 3.5 — системы для управления доступом привилегированных пользователей. Среди ключевых обновлений — автоматический контроль действий во время удаленных сессий, поддержка Kerberos для Linux-инсталляций и дополнительные сценарии работы через Web Terminal.</p> <p>Одним из главных обновлений Indeed PAM 3.5 стала возможность создавать правила контроля действий пользователей во время RDP-сессий. Администратор определяет события, которые необходимо отслеживать, например запуск определенного приложения или смену окна браузера, и задает реакцию системы: запись события в журнал, завершение сессии или блокировку пользователя.</p> <p>Так служба информационной безопасности может автоматически реагировать на нежелательные действия непосредственно во время подключения, не дожидаясь завершения сессии и последующего разбора событий. Это сокращает время между обнаружением действия и ответной мерой и снижает необходимость постоянно контролировать каждое подключение вручную.</p> <p>Правила можно вводить постепенно. На первом этапе Indeed PAM может только фиксировать заданные события, чтобы специалисты собрали статистику и оценили реальные сценарии работы пользователей. После этого для отдельных действий можно настроить более строгую реакцию. Такой сценарий позволяет последовательно распространять единые требования контроля на инфраструктуру с большим количеством привилегированных подключений.</p> <p>Другим важным улучшением стала поддержка аутентификации через Kerberos на серверах Indeed PAM под управлением Linux. Она доступна пользователям, учетные записи которых хранятся в Active Directory. Если пользователь входит в Indeed PAM с доменного компьютера, браузер выполняет сквозную аутентификацию — повторно вводить логин и пароль не нужно. При этом добавлять сервер управления в домен не требуется. Ранее такой сценарий поддерживался только при развертывании Indeed PAM на Windows.</p> <p>Новый функционал также расширяет возможности работы с учетными записями администраторов, включенных в группу Active Directory Protected Users. Участники этой группы не могут аутентифицироваться по протоколу NTLM и обязаны использовать Kerberos с шифрованием AES. Теперь такие пользователи получают доступ к Indeed PAM на Linux-инсталляциях, что позволяет соблюдать усиленные требования к защите учетных данных и одновременно продолжать перевод инфраструктуры на отечественные операционные системы.</p> <p>В Indeed PAM 3.5 разработчик уделил отдельное внимание возможностям Web Terminal — инструмента для удаленных подключений через браузер. Теперь через него можно устанавливать не только RDP- и SSH-сессии, но и подключаться к серверам Remote Desktop Services (RDS).</p> <p>Пользователь может открыть удаленный рабочий стол или опубликованное RemoteApp-приложение непосредственно в браузере — без скачивания RDP-файлов, установки локального клиента и повторной аутентификации.</p> <p>Благодаря этому компании могут предоставлять сотрудникам и подрядчикам доступ к рабочим средам и бизнес-приложениям, в том числе с неуправляемых устройств. Все подключения проходят через Indeed PAM, поэтому служба информационной безопасности может контролировать и записывать привилегированные сессии.</p> <p>Кроме этого, В Web Terminal также появилась передача файлов между устройством пользователя и целевым ресурсом. Для этого достаточно перенести файл в окно активной сессии. Это возможность управляется политиками Indeed PAM, поэтому организация может разрешить ее только для согласованных сценариев.</p> <p>«По мере роста числа привилегированных подключений компаниям становится все сложнее их контролировать. Поэтому одна из ключевых задач развития Indeed PAM — автоматизировать контроль там, где раньше требовалось постоянное участие специалиста. В новой версии 3.5 мы усилили именно этот сценарий: Indeed PAM может автоматически реагировать на заданные действия пользователей. Это особенно актуально для крупных инфраструктур, где число контролируемых ресурсов постоянно растет. Одновременно мы расширяем поддержку Linux-сред и браузерных сценариев удаленной работы, чтобы заказчики могли применять единые требования к защите привилегированного доступа в разных инфраструктурах», — отметил Михаил Елычев, руководитель продукта Indeed PAM в компании «Индид».</p> Компания «Индид», российский разработчик решений в области защиты айдентити, представила новую версию Indeed Privileged … message https://www.itweek.ru/themes/detail.php?ID=235484 Tue, 08 Sep 2026 10:56:59 +0300 <p><em>Данные могут быть правильными. Определение может быть правильным. Но ответ искусственного интеллекта все равно может быть неверным. ИИ-аналитикам необходим контекст принятия решения до того, как поступит вопрос, пишет на портале </em><em>InformationWeek</em> <em>Пол Вахтлер, старший вице-президент Exiger по ИИ, данным и стратегии.</em></p> <p>Если вы работаете с данными, вы, вероятно, сталкивались с примерно с таким вопросом от вашего руководства: «Можем ли мы запустить LLM на наших данных и заставить ее проанализировать все за нас?».</p> <p>Это нормальный вопрос. Руководители хотят получать ответы быстрее, не отправляя каждый вопрос через BI-очередь. Они видят, что могут делать LLM с текстом, и предполагают, что тот же принцип должен применяться и к бизнес-данным.</p> <p>Проблема в том, что корпоративные данные не объясняют сами себя.</p> <p>Я наблюдал это во время тестирования ИИ-аналитика на реальных бизнес-вопросах. Меня интересовало, какие клиенты представляют наибольший риск в текущем квартале или какие возможности с наибольшей вероятностью будут закрыты в следующие 30 дней. Система уверенно называла клиентов или возможности. Некоторые ответы были неверными; некоторые — вымышленными; а другие имели мало отношения к вопросу.</p> <p>Система выдавала ответы, не понимая масштаба запроса или того, что бизнес подразумевает под «аккаунт подвержен риску» и «аккаунт вероятно будет закрыт». Она также не знала, означают ли «показатели текущего квартала» данные на сегодня или ожидаемые результаты к концу квартала.</p> <p>ИИ-аналитик не может понять бизнес лишь благодаря потому, что у него есть доступ к хранилищу данных. Он может написать SQL-запрос и вернуть число, которое выглядит правдоподобным. Риск заключается в том, что ему приходится где-то брать бизнес-логику, лежащую в основе ответа. Если компания не определила эту логику, модель сама заполнит пробел.</p> <p>Большинство компаний никогда не документировали всю эту бизнес-логику, потому что ею владели опытные аналитики. Сильная BI-команда знала, каким показателям выручки доверяют руководители. Они понимали, что дашборд хорош для определения направления, но не подходит для оперативного анализа. Они знали, что результат требует контекста, чтобы на нем можно было строить какие-либо действия.</p> <p>Во многих компаниях аналитик был семантическим слоем.</p> <p>Такая схема могла работать, когда одни и те же аналитики оставались в тесном контакте с бизнесом. Проблема возникает, когда от системы ожидается, что она будет отвечать самостоятельно. Теперь от LLM требуют использовать логику, которую организация ей никогда не давала.</p> <p>Проблему сложнее обнаружить, когда ответ не кажется явно ошибочным. Он может звучать разумно, но при этом быть неверным, что негативно сказывается на бизнесе.</p> <p>Помочь может проработанный семантический слой. Он предоставляет системе утвержденные определения и логику, связывающую их с данными. Но эти определения все равно должны применяться к соответствующей ситуации. Модель может использовать правильное определение дохода, но при этом выбрать неправильный временной период. Она может точно рассчитать показатели эффективности, но при этом неправильно понять, что пытается выяснить руководитель.</p> <p>Данные могут быть правильными. Определение может быть правильным. Ответ все равно может быть неверным.</p> <h3>За пределами семантического слоя</h3> <p>Семантический слой может определить, какой аккаунт следует считать подверженным риску или что делает вероятным его закрытие. Контекстный слой сообщает системе, применимы ли эти определения к задаваемому вопросу. Аккаунт может соответствовать формальным критериям риска, но эта оценка может не соответствовать временному периоду, которым пытается управлять руководитель. Определение верное; его применение неверное.</p> <p>Этот контекст также меняется со временем. Определение, утвержденное в начале квартала, может перестать соответствовать прогнозу после его изменения или корректировки руководством принимаемого решения. Система должна знать, какой контекст актуален, а какие предположения устарели. В противном случае она может правильно применить устаревшее предположение и выдать неверный ответ.</p> <p>Аналитики обычно учитывают все эти аспекты в рамках своей работы. Они знают, когда определение технически верно, но все же неверно для рассматриваемого решения. ИИ-аналитик должен понимать эти аспекты до того, как поступит вопрос. Если человеку приходится каждый раз переформулировать его, система теряет значительную часть той скорости, на которую была рассчитана.</p> <p>Агенту также необходимы операционные правила обработки неполного или противоречивого контекста. Эти правила определяют, когда агент может продолжить работу, а когда неопределенность достаточно велика, чтобы вмешался человек. Они также предотвращают незаметное превращение временных сигналов в постоянную бизнес-логику.</p> <h3>Владельцы бизнеса не исчезают</h3> <p>Владельцы бизнеса не могут проверять каждый ответ, не становясь узким местом. Им необходимо проверять результаты тестирования и оценки ответов на множества вопросов и понимать, когда контекст, лежащий в основе этих ответов, изменился.</p> <p>Бизнес поддерживает этот контекст, связывая каждое определение с решением и периодом, для которого оно было разработано. При изменении любого из этих параметров затронутый контекст помечается для проверки бизнесом.</p> <p>Этот анализ также должен охватывать сам процесс оценки. Если результат изменился, система может повысить свою оценку, улучшив выполнение неправильной задачи. Хотя система может собирать новую информацию и предлагать изменения, существенные изменения в контексте по-прежнему требуют одобрения бизнеса.</p> <p>Эта ответственность лежит на владельце бизнеса. Инженеры могут правильно построить систему, и система может работать точно так, как задумано, даже если лежащие в её основе предположения неверны.</p> <p>Раньше большую часть этой ответственности несли аналитики, опираясь на свой опыт. С ИИ-аналитиком ситуация меняется: бизнес должен брать на себя ответственность за логику, лежащую в основе ответа, и решать, когда эту логику необходимо изменить.</p> Данные могут быть правильными. Определение может быть правильным. Но ответ искусственного интеллекта все равно может быть … article https://www.itweek.ru/themes/detail.php?ID=235480 Tue, 08 Sep 2026 10:38:02 +0300 <p><em>Внедрение «умных» электронных ценников увеличило продажи и высвободило 24 тыс. рабочих часов в год.</em></p> <p>«Лемана ПРО» начала масштабирование технологии «умных» электронных ценников на всю сеть: в течение двух лет они появятся во всех гипермаркетах. Рассмотрим, почему на внедрение технологии ушел почти год подготовки, зачем потребовалось менять бумажные ценники на электронные, как устроена архитектура решения, какими функциями обладают новые ценники и какие результаты уже показал пилотный запуск.</p> <h3>Почему потребовалось менять бумажные ценники</h3> <p>Идея перейти на электронные ценники обсуждалась в компании, еще когда эта технология только начинала набирать популярность. Но долгое время высокая стоимость самой технологии в России делала внедрение невыгодным. Ситуация изменилась, когда электронные ценники стали более доступными, а дефицит кадров на рынке труда и рост стоимости рабочего времени сделали такие вложения экономически оправданными.</p> <p>«Лемана ПРО» стала первым российским ритейлером в сегменте товаров для строительства, ремонта и обустройства, внедрившим «умные» электронные ценники в процессы логистики. Электронный ценник становится частью цифровой инфраструктуры магазина, которая делает покупки более удобными, предсказуемыми и прозрачными. Если раньше офлайн-магазины конкурировали в цене друг с другом, то сегодня они конкурируют с маркетплейсами, где покупатель привык видеть актуальную цену, отзывы, характеристики товара и получать всю информацию буквально за несколько минут. Поэтому сегодня задача ритейлера — обеспечить единый уровень удобства и клиентского опыта в любом канале, в том числе непосредственно у полки в магазине.</p> <p>Мало кто задумывается, сколько времени уходит на замену бумажных ценников. Каждое утро сотрудники печатают, сортируют и вручную меняют сотни карточек с ценами — на это уходит ежедневно по <nobr>2-3 часа,</nobr> которые можно направить на обслуживание покупателей. Это одна из самых трудоемких операций в розничной торговле, которая практически незаметна клиенту, но напрямую влияет на его покупательский опыт.</p> <h3>Год подготовки: выбор технологии и партнеров</h3> <p>Прежде чем принять решение о внедрении, мы провели масштабный анализ рынка производителей и интеграторов. Российский рынок электронных ценников сегодня только формируется, а мировой рынок производителей и компаний-интеграторов сравнительно узкий.</p> <p>Почти год команда R&D и автоматизации «Лемана ПРО» работала над выбором технологии, совершала визиты в Китай к производителям и на профильные выставки, чтобы сформировать требования к продукту. Параллельно мы консультировались с российскими ритейлерами, у которых уже был опыт внедрения подобных решений: у одних технология прижилась и продолжает развиваться, у других опыт оказался неудачным. Изучение обеих сторон помогло сформировать собственный путь внедрения и заранее обойти уже известные подводные камни.</p> <p>Итоговая модель работы — трехстороннее партнерство: китайский производитель оборудования и программного обеспечения, российский интегратор, который адаптирует решение под ИТ-ландшафт конкретного заказчика и обеспечивает обучение и поддержку, и сама компания. На старте проекта мы регулярно проводили совместные встречи, а на этапе внедрения в магазинах присутствовали разработчики китайского партнера, которые могли оперативно вносить корректировки в работу системы.</p> <p>При этом мы сознательно отказались от идеи писать программное обеспечение с нуля: кастомизации подвергаются только те элементы, которые создают конкурентное преимущество для компании, а не уже отлаженные вендором процессы. Один из таких принципиальных выборов — архитектура решения: мы выбрали облачную модель хранения и обмена данными, тогда как часть игроков рынка предпочитает локальные серверы в каждом магазине, ориентируясь на собственную ИТ-стратегию.</p> <h3>Как устроена техническая архитектура</h3> <p>В доставке цены от корпоративных систем до полки участвуют пять ключевых контуров: продукты ценообразования, слой агрегации и кеширования, планировщик обновлений, облачный сервер управления ESL (Electronic Shelf Labels, электронные ценники) и радиосеть магазина.</p> <p>Цены на товары устанавливаются в соответствии со стратегией компании «Низкие цены каждый день». Мы регулярно анализируем открытые данные о стоимости товаров на рынке и в соответствии с этим снижаем цены в магазинах, чтобы гарантировать покупателям наиболее выгодные условия. Роль Price Hub выполняет собственный репозиторий цен (Price Repository) — целевая мастер-система хранения, проверки и применения розничных цен. Это единый источник данных для десятков внутренних систем: касс, электронных ценников, онлайн-каналов и систем бизнес-аналитики. Репозиторий хранит полную историю изменений и несколько миллионов активных цен, поддерживает более 600 запросов на чтение и более 350 операций записи в секунду; 95% запросов на чтение обрабатываются не дольше 200 миллисекунд, а доступность обработки поступающих запросов составляет 99,9%.</p> <p>Сервис агрегации данных объединяет все параметры товара: цену за штуку или единицу измерения товара, уникальный код, дату применения, доступный остаток, клиентский рейтинг, баллы лояльности и другие атрибуты. Профиль сохраняется в специализированном кеше, чтобы минимизировать задержку при подготовке пакетов обновлений для ценников.</p> <p>«Умный» планировщик формирует график обновлений с учетом даты вступления цены в силу, состава данных, часового пояса магазина и смен сотрудников. Он распределяет пиковую нагрузку на инфраструктуру, помогает экономить заряд батарей и инициирует применение цены точно к назначенному времени.</p> <p>ПО вендора для управления электронными ценниками развернуто в защищенном приватном облаке «Лемана ПРО». Оно управляет связками «товар — ценник», картой радиопокрытия, жизненным циклом устройств и рендерингом: накладывает данные на дизайн-шаблон и формирует растровое изображение под разрешение E-ink-дисплея нужного формата. По защищенному сетевому протоколу изображения поступают на точки доступа под потолком торгового зала, а затем по энергоэффективному радиопротоколу — на конкретные ценники.</p> <p>Облачная модель позволила отказаться от дополнительных серверов в гипермаркетах. Обновления ПО централизованно распространяются по всей сети через единый конвейер данных, а микросервисы, базы данных, очереди сообщений и API контролируются в едином контуре мониторинга. Ресурсы можно гибко наращивать по мере подключения магазинов и при массовой плановой передаче обновлений на ценники, а резервирование обеспечивается на уровне облачного кластера.</p> <h3>Что умеют новые ценники</h3> <p>Электронные ценники в «Лемана ПРО» работают в двух режимах: в режиме «день» для покупателя и продавца-консультанта и «ночь» для сотрудника пополнения и сборки. Режимы переключаются автоматически по расписанию, индивидуальному для каждого магазина, в момент его открытия и закрытия.</p> <p>#IMAGE_235483#</p> <p>В режиме «день» на ценнике отображается не только цена, но и информация о размере кешбэка за покупку данного товара, оценка товара на основе отзывов покупателей на сайте, место товара на полке, наименование, объем/размер товара и его артикул. В режиме «ночь» отображается информация о необходимости пополнения товара на полке и ее вместимости, а также увеличивается размер шрифта для необходимых атрибутов — например, артикула товара, чтобы сотруднику магазина было проще и быстрее его найти. На сегодняшний день мы — единственный ритейлер на российском рынке, который работает в мультиформатном режиме с электронными ценниками, совмещая оба сценария использования.</p> <p>Отдельная функция электронных ценников — это «мигание»: она уже интегрирована в мобильное приложение сотрудника и используется в процессах пополнения и сборки заказов. Например, среди визуально похожих друг на друга товаров сотрудник может нажать в приложении кнопку — и нужный ценник начнет мигать, показывая, где лежит необходимый артикул. Эта функция экономит время, которое раньше уходило на поиск нужной позиции среди множества похожих товаров.</p> <p>Мы не рассматриваем электронные ценники просто как замену бумаги на цифровое решение. Это скорее инфраструктурный базис, который можно интегрировать в разные процессы магазина — от ценообразования до логистики — и получать кумулятивный эффект. В планах — тестирование новых форматов, включая более крупные цифровые дисплеи (13 дюймов), которые смогут показывать дополнительный контент для покупателя.</p> <h3>Что доработали внутри компании</h3> <p>Платформа вендора стала базовым транспортным и инфраструктурным решением, однако прикладной слой и пользовательские сценарии команда разработала самостоятельно. Привязку и отвязку ценников встроили в корпоративное мобильное приложение сотрудника: операция выполняется в один шаг — сканированием штрихкода камерой смартфона. В приложении также появились пакетная привязка, принудительное обновление экрана и проверка соответствия цены данным репозитория цен.</p> <p>Для семи размеров ESL создана библиотека шаблонов в дневном и ночном режимах. Помимо ценовых атрибутов, в них передаются баллы лояльности, признак «лучшая цена» и навигационные элементы. Для плотной выкладки разработаны шаблоны с номером места и стрелками, а для кухонь, ванных комнат и других проектных зон — крупноформатный ценник А4 с составом экспозиции, перечнем артикулов и суммарной стоимостью решения. Отдельный программный сервис управляет светодиодами ценников для световой навигации при сборке заказов и пополнении полок.</p> <p>Одним из главных технических вызовов пилота стала пропускная способность радиоканала при массовом переключении режимов «день» и «ночь». В каждом гипермаркете работает около 60 тыс. ценников, поэтому одновременная смена экранов в коротком временном окне создавала большие очереди обновлений. Команда совместно с интегратором и вендором оптимизировала процесс на нескольких уровнях, включая доработку прошивки устройств.</p> <h3>Как контролируется работа ценников</h3> <p>Мониторинг построен на логах и телеметрии сервера управления ESL. Система непрерывно получает данные о состоянии точек доступа, сессиях связи, уровне радиосигнала и остаточном заряде батарей. Автоматические правила алертинга (оповещения) контролируют как сетевую инфраструктуру, так и состояние отдельных устройств: фиксируют потерю связи с точкой доступа, пропуск ценником регламентных интервалов выхода на связь и разряд элемента питания.</p> <p>На основании событий формируются задачи на обслуживание, плановую замену батарей или самого ценника. Если сеть временно недоступна, E-ink-экран продолжает автономно показывать последнее отрисованное изображение — пустого экрана в торговом зале не возникает. Такой контроль позволяет быстро устранять аппаратные и сетевые сбои.</p> <h3>Первые результаты пилота</h3> <p>Изначально пилот планировался только в одном московском магазине. Но для того, чтобы результаты были показательны как коммерчески, так и технологически, требовалась контрольная группа — так в проект добавили магазин в Твери. Дополнительным фактором стала близость обеих точек к проектной команде — это позволяло оперативно сопровождать пилот и вносить коррективы на старте проекта.</p> <p>Главный эффект проекта не в экономии средств, а в высвобождении времени сотрудников на более важные задачи. Это время они перераспределяют на работу с покупателями и, соответственно, на повышение продаж. По нашей оценке, в масштабе сети речь идет примерно о 2 тыс. человеко-часов в месяц.</p> <p>В среднем за время пилота товарооборот в пилотных магазинах вырос на 1,3% — вдвое больше планового показателя. А суммарное высвобождение рабочего времени превысило план почти в 2 раза и составило 16 тыс. часов (+7%) против плановых 9 тыс. часов (+2%).</p> <p>Рост товарооборота связан с тремя факторами:</p> <ul> <li> автоматической синхронизацией цены во всех каналах: после применения новой цены в системе она передается на электронный ценник без ручной переклейки;</li> <li> эффектом «полной полки» — высвобожденное утреннее время до открытия торгового зала сотрудники теперь направляют на пополнение и выкладку товара, а не на замену ценников;</li> <li> сокращением расхождений цены на кассе.</li> </ul> <p>Также мы измерили уровень удовлетворенности покупателей по параметрам доступности и доброжелательности сотрудников: за первые два месяца пилота показатель вырос на 0,22 п. п. (по <nobr>5-балльной</nobr> шкале).</p> <p>Экономия на печати и расходных материалах в среднем составила около 200 тыс. рублей в месяц на один магазин. В масштабах всей сети это ощутимая экономия — более 270 млн. в год, хотя изначально она не являлась целью проекта.</p> <p>Важен и экологический эффект от внедрения «умных» ценников. Отказ от печати бумажных ценников позволяет сэкономить порядка 60 кг бумаги в месяц на один магазин, или порядка 720 кг в год. В масштабах всей сети это около 80 тонн в год.</p> <h3>Что дальше</h3> <p>До конца 2026 года на электронные ценники перейдут более 50 магазинов, в том числе в Москве, Санкт-Петербурге, Краснодаре, Новосибирске, Казани, Самаре, Екатеринбурге, Ростове-на-Дону, Нижнем Новгороде, Красноярске и Иркутске. За 2 года планируется оснастить электронными ценниками всю сеть. В каждом магазине в среднем будет установлено около 60 тыс. электронных ценников семи форматов, адаптированных под различные типы товаров и особенности выкладки.</p> <p>Производство оборудования для масштабирования проекта было запущено в марте 2026 года. Первым кластером, где технология была запущена во всех магазинах, стал Новосибирск. На электронные ценники перешли четыре гипермаркета в городе, в которых заменили около 200 тыс. бумажных ценников. Одновременно еще более 50 магазинов готовятся к монтажу. Структурированная кабельная система (СКС) уже смонтирована более чем в 35 магазинах. При этом для каждого магазина после завершения монтажных работ заложен двухнедельный период тестовой стабилизации.</p> <p>Сейчас мы готовимся к следующей волне запуска со стартом реализации в 2027 году. Параллельно рассматриваем тестирование новых форматов и доработку функциональности как для сотрудников, так и для покупателей. Важно уточнить, что с точки зрения покупателя переход на электронные ценники остается бесшовным. Наши внутренние исследования показали, что клиенты не замечают замену бумажного ценника на электронный. Новые возможности — вроде мгновенно отображающейся информации о повышенном кешбэке или актуальных отзывах — воспринимаются как естественное дополнение к привычному клиентскому опыту.</p> <p>В течение пилота мы не только замеряли эффекты, но и готовили необходимые процессы для масштабирования. Над проектом работала вовлеченная профессиональная команда энтузиастов. Отдельно хочу отметить важность совместной работы команды и надежность партнеров, которые должны стать единым организмом для реализации таких трансформаций.</p> <p>#IMAGE_235481#</p> Внедрение «умных» электронных ценников увеличило продажи и высвободило 24 тыс. рабочих часов в год. «Лемана ПРО» … article Дмитрий Коченко, директор продукта компании “Лемана ПРО” https://www.itweek.ru/themes/detail.php?ID=235476 Mon, 07 Sep 2026 14:43:57 +0300 <p>Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — Postgres Pro Enterprise Manager (PPEM) 2.9. В релиз вошли усовершенствования центра оперативного контроля, улучшенные инструменты диагностики производительности, а также усиленные механизмы защиты взаимодействия между компонентами системы.</p> <p>Одним из ключевых нововведений стало расширение центра оперативного контроля. Теперь администраторы могут просматривать в нём не только отдельные экземпляры СУБД, но и отказоустойчивые кластеры. Это упрощает мониторинг распределённых инфраструктур: состояние кластера отображается как состояние единого объекта, а переход к анализу отдельных узлов занимает меньше времени.</p> <p>Существенные улучшения получил инструмент диагностики производительности Active Session Engine (ASE). Помимо общей стабилизации и доработок, в PPEM 2.9 появилась возможность управлять параметрами профилирования и выгружать данные снимков в необработанном виде для последующего анализа во внешних системах. Реализован просмотр исходных подготовленных операторов, позволяющий получить более полную картину при разборе запросов. Также добавлен бесшовный переход из истории сеансов в SQL-статистику, что упрощает диагностику проблем. Кроме того, улучшены интерфейс раздела, фильтры и визуализация графиков.</p> <p>В сфере безопасности ключевым изменением стала реализация взаимной TLS-аутентификации (mTLS). В дополнение к аутентификации по API-ключам менеджер и агенты теперь могут взаимно подтверждать подлинность друг друга с помощью сертификатов при установлении HTTPS-соединения. Это усиливает защиту взаимодействия между компонентами и снижает риск подключения недоверенной стороны, что особенно важно для инфраструктур с повышенными требованиями к безопасности.</p> <p>Платформа также получила ряд других улучшений:</p> <ul> <li>в части управления задачами и резервными копиями добавлена возможность переназначать задачи и перепривязывать хранилища для удаляемых экземпляров;</li> <li>для BiHA-кластеров реализовано управление минимальным числом исправных узлов при создании и изменении топологии;</li> <li>в обслуживании репозитория появилась возможность вручную очищать таблицы репозитория, чтобы предотвратить остановку сервера из-за нехватки дискового пространства;</li> <li>в конфигурацию добавлен параметр для задания пользовательского шаблона имени экземпляра при использовании режима автоматического обнаружения;</li> <li>исправлен ряд уязвимостей общего характера (CVE), а язык Go обновлён до версии 1.26.6.</li> </ul> <p>Postgres Pro Enterprise Manager входит в состав всех редакций СУБД Postgres Pro и предоставляет единый веб-интерфейс для мониторинга, администрирования и диагностики баз данных.</p> <p>Компания также анонсировала выход модуля Healthcheck Advisor в одном из ближайших релизов PPEM. Он будет автоматически анализировать состояние экземпляров СУБД на основе собранной телеметрии, выявлять отклонения по ключевым показателям работы баз данных, определять уровень их критичности и формировать рекомендации по дальнейшим действиям.</p> <p>Для каждого обнаруженного отклонения будут доступны сведения о метрике, объекте анализа, нормативном и фактическом значениях, времени срабатывания и рекомендуемых мерах по устранению проблемы. Результаты будут представлены в разделе «Проблемы и рекомендации»: в нём будет размещена сводная информация по управляемым экземплярам, распределение обнаружений по уровням критичности и перечень экземпляров с наибольшим числом выявленных проблем.</p> <p>PPEM Healthcheck Advisor войдёт в базовую поставку платформы и не потребует отдельной установки или лицензирования. Подробная информация об изменениях и инструкции по обновлению до PPEM 2.9 доступны в документации Postgres Pro Enterprise Manager.</p> Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — … message https://www.itweek.ru/themes/detail.php?ID=235475 Mon, 07 Sep 2026 14:41:01 +0300 <p>Число алертов на вредоносную активность в корпоративных сервисах коммуникации за последние 12 месяцев выросло более чем в два раза, выяснили эксперты компании «Информзащита». При этом большинство таких срабатываний относились к фишинговым операциям в чатах. Корпоративные мессенджеры и другие платформы для совместной работы все чаще используются злоумышленниками для атак на учетные записи, доставки вредоносных файлов и развития атаки после первоначального проникновения.</p> <p>Особенности корпоративных коммуникационных сред создают дополнительные возможности для таких атак. В отличие от электронной почты, такие сервисы поддерживают федеративный доступ между организациями, гостевой доступ, общие рабочие пространства и интеграции со сторонними системами. Для бизнеса это упрощает взаимодействие, но одновременно расширяет число доверенных каналов, через которые злоумышленник может обратиться к пользователю.</p> <p>Сообщение, поступившее из корпоративного или знакомого пользователю рабочего пространства, может восприниматься как часть обычного рабочего процесса. Если злоумышленнику удается получить доступ к учетной записи сотрудника, он наследует ее права, связи и историю переписки. Фишинговая ссылка или просьба передать файл в таком случае уже не обязательно выглядит как внешняя атака. Она приходит от сотрудника или аккаунта, который имеет легитимный доступ к нужной среде.</p> <p>Именно поэтому основной объем выявленной активности связан с чат-фишингом. Злоумышленники используют внешние коммуникации и скомпрометированные учетные записи, чтобы инициировать диалог, выдать себя за сотрудника службы поддержки или другого знакомого человека и затем подтолкнуть жертву к определенному действию. Это может быть переход на страницу сбора учетных данных, подтверждение запроса многофакторной аутентификации, установка программного обеспечения удаленного доступа или передача корпоративной информации. В атаках используются прямые сообщения, упоминания в каналах и легитимные уведомления платформ.</p> <p>После получения действующей корпоративной учетной записи атакующий может использовать ее для доступа к облачным сервисам и другим ресурсам с правами скомпрометированного пользователя. При этом традиционные средства контроля часто сосредоточены на событиях аутентификации и электронной почте и могут не иметь достаточной видимости того, что происходит внутри уже установленной и аутентифицированной сессии.</p> <p>Показатель роста алертов более чем в два раза при этом нельзя сводить только к увеличению количества фишинговых сообщений. Меняется сама роль коммуникационных платформ в цепочке атаки. Зафиксированы случаи, когда доверенные сервисы применялись для дальнейшего развития атаки. В декабре 2025 года при расследовании инцидента на производственном предприятии в Польше злоумышленник использовал скомпрометированные сетевые устройства, чтобы получить пароль привилегированной учетной записи, изменить параметры безопасности и отключить двухфакторную аутентификацию. Результаты операций передавались через штатную возможность отправки уведомлений. Легитимная интеграция с сервисом коммуникации стала частью механизма сохранения доступа и вывода данных.</p> <p>Такие сценарии особенно актуальны для организаций, которые активно используют внешние рабочие пространства и интеграции с партнерами. Чем больше у компании гостевых учетных записей, федеративных соединений и сторонних подключений, тем шире пространство для злоупотребления доверенными отношениями. При этом сам факт успешной аутентификации пользователя уже не дает достаточного основания считать последующие действия безопасными. Скомпрометированная учетная запись продолжает выглядеть легитимно, пока система не сопоставит ее действия с контекстом поведения.</p> <p>Для защиты от подобных сценариев контроль коммуникационных платформ следует расширять за пределы обычной проверки входа в систему. Администраторам необходимо регулярно пересматривать федеративный доступ между организациями, гостевой доступ и сторонние интеграции, удаляя ненужные разрешения. Мониторинг должен охватывать события обмена файлами, подключения внешних пользователей и приложений, изменения прав и необычную активность учетных записей, а также неожиданные исходящие обращения к сервисам коммуникации через встроенные интеграции. Проверку ссылок и вложений в сообщениях необходимо настраивать отдельно с учетом возможностей платформы. Дополнительно следует применять устойчивые к фишингу методы аутентификации, например на основе FIDO2, если используемые системы их поддерживают. Использование средств удаленного доступа необходимо ограничивать согласованными инструментами и установленными процедурами технической поддержки.</p> <p>На уровне пользователей особое значение имеет проверка чувствительных запросов через независимый канал. Пароли и одноразовые коды нельзя передавать другим людям, в том числе сотрудникам поддержки. Запрос MFA следует подтверждать только для входа или операции, которые пользователь инициировал самостоятельно. Запросы на установку ПО удаленного доступа, передачу рабочих данных или изменение прав необходимо проверять через заранее известный номер телефона, внутреннюю систему заявок или другой установленный процесс. Сотрудникам также должен быть понятен порядок сообщения о подозрительных обращениях в службу информационной безопасности. Данные мониторинга коммуникационных платформ, сетевых устройств и конечных точек целесообразно сводить в единую систему анализа, чтобы связать подозрительное сообщение с последующими действиями учетной записи и устройства. Порядок реагирования должен предусматривать оперативный отзыв скомпрометированных сессий.</p> <p>Рост числа алертов более чем в два раза показывает, что корпоративные мессенджеры становятся самостоятельной частью поверхности атаки. Для службы информационной безопасности это уже не только каналы рабочих коммуникаций, но и источник событий, по которым можно выявлять компрометацию учетных записей и дальнейшее развитие атаки. При этом 99% алертов, связанных с корпоративными сервисами коммуникации, приходятся на чат-фишинг. Поэтому в защите таких сред приоритетом остается выявление подозрительных сообщений и контроль действий, которые следуют за ними.</p> Число алертов на вредоносную активность в корпоративных сервисах коммуникации за последние 12 месяцев выросло … message https://www.itweek.ru/themes/detail.php?ID=235472 Mon, 07 Sep 2026 10:15:31 +0300 <p><em>Код — это только половина продукта. Вторая половина — ваша способность доказать заказчику, что он безопасен сегодня и останется таким завтра.</em></p> <p>Весной 2026 года вступили в силу обновленные требования ФСТЭК России к защите государственных информационных систем. Регулятор смещает акцент с разового подтверждения безопасности на ее непрерывное обеспечение в течение всего жизненного цикла системы. На первый взгляд это выглядит как очередная регуляторная нагрузка на госсектор. Но на самом деле новые правила бьют по самому больному месту любого коммерческого вендора — его маржинальности.</p> <p>ФСТЭК официально закрепил то, о чем рынок шептался годами: стоимость вашего продукта теперь равна стоимости времени вашей реакции на инцидент. Если поиск уязвимости в сотнях зависимостей занимает дни, ваш продукт для крупного заказчика стоит ноль, каким бы качественным ни был собственный код. Мы привыкли считать, что главная ценность ИТ-компании — талантливые разработчики. Но сегодня этого уже недостаточно. Качественный код остается обязательным условием, однако он перестал быть конкурентным преимуществом. Им становятся инженерные процессы.</p> <h3>Безопасность как производственный процесс</h3> <p>Современное программное обеспечение перестало быть статичным продуктом. Оно постоянно обновляется, интегрируется с внешними сервисами и использует десятки сторонних компонентов. По оценкам Sonatype, до 90% современного софта составляют компоненты с открытым исходным кодом (Open Source). Программный продукт превратился в сложную цепочку поставок, где защищенность зависит не только от собственного кода разработчика, но и от десятков внешних библиотек. Именно поэтому мы больше не можем один раз проверить систему и считать вопрос безопасности закрытым. Доверие определяется зрелостью процессов разработки, сопровождения и обновления.</p> <h3>Что меняется в критериях выбора</h3> <p>Еще несколько лет назад ключевыми преимуществами были функциональность, скорость написания кода и стоимость проекта. Сегодня крупный заказчик оценивает не только то, что умеет продукт, но и то, как компания гарантирует его развитие. Для него вопрос «как создается продукт» становится не менее важным, чем «что он умеет». Зрелость инженерных процессов превращается в решающий фактор доверия: заказчику нужна уверенность в безопасном развитии решения на годы вперед, а не просто зафиксированный набор функций на момент поставки.</p> <h3>Open Source как экзамен для процессов</h3> <p>Открытый код остается фундаментом разработки, однако он же стал главным источником рисков в цепочке поставок ПО. Когда появляется новость об уязвимости нулевого дня, счет идет на часы. Заказчик хочет сразу понять, затронута ли его система, каков риск и когда будет готово исправление. Ответить на эти вопросы за пару часов можно только при выстроенных процессах управления зависимостями (наличии актуального реестра компонентов — SBOM) и регламенте экстренного выпуска патчей. Наличие такого конвейера превращает информационную безопасность из статьи расходов в реальное рыночное преимущество.</p> <h3>Конкуренция инженерной зрелости</h3> <p>Автоматизация проверок, управление зависимостями и скорость выпуска обновлений перестают быть сугубо внутренними инженерными задачами. Они становятся частью рыночной ценности продукта. Инвестиции в выстраивание этих процессов нельзя рассматривать только как выполнение требований регулятора — это вложения в устойчивость бизнеса и капитализацию компании.</p> <p>Мне кажется символичным, что именно требования информационной безопасности подталкивают отрасль к тому, чтобы качество ПО оценивалось не только по функциональности, но и по предсказуемости его развития. Российский рынок переходит от конкуренции продуктов к конкуренции инженерной зрелости. И выигрывать будут компании, которые смогут гарантировать надежное, безопасное и прозрачное сопровождение своего решения на протяжении всего его жизненного цикла.</p> <p> #IMAGE_235473#</p> Код — это только половина продукта. Вторая половина — ваша способность доказать заказчику, что он безопасен … article Ирина Мягкова, заместитель генерального директора по развитию АО НПП РЕЛЭКС https://www.itweek.ru/themes/detail.php?ID=235471 Mon, 07 Sep 2026 10:09:57 +0300 <p><em>Гонка в сфере корпоративного искусственного интеллекта начинает демонстрировать некоторое разделение. Хотя внедрение ИИ продолжает распространяться по организациям, новое исследование McKinsey показывает, что крупные предприятия и небольшая группа высокоэффективных компаний движутся значительно быстрее всех остальных. Результатом может стать начало формирования двухскоростного рынка корпоративного ИИ, сообщает портал </em><em>BigDataWire</em><em>.</em></p> <p>Отчет McKinsey «State of AI in 2026» основан на опросе 1719 участников из 97 стран. Исследование выявило резкие различия во внедрении агентов ИИ.</p> <p>40% респондентов из организаций с годовым доходом более 1 млрд. долл. заявили, что сейчас масштабируют агентов ИИ. Это больше, чем 27% в прошлом году. В небольших организациях этот показатель составляет всего 22% и не увеличился по сравнению с прошлым годом.</p> <p>Аналогичное разделение наблюдается и в отношении агентов для кодирования. В целом около 20% организаций масштабируют эту технологию, по сравнению с 31% крупных предприятий. Но более интересным изменением может стать то, как компании используют эти инструменты.</p> <h3>ИИ начинает менять дилемму «разрабатывать или покупать»</h3> <p>Почти треть респондентов (32%) заявили, что их организация отказалась от покупки хотя бы одного программного продукта или функции, поскольку могла бы разработать функциональность внутри компании, используя инструменты агентного кодирования.</p> <p>Это значительное событие для рынка корпоративных технологий, построенного вокруг компаний, покупающих специализированное ПО для решения специализированных задач.</p> <p>ИИ-агенты кодирования потенциально меняют ситуацию, снижая затраты и время, необходимые для разработки ПО внутри компании. Это не означает, что предприятия внезапно заменят Salesforce, SAP или другие основные платформы ПО, созданным агентами ИИ. Разработка функции внутри компании и замена крупного корпоративного приложения — это совершенно разные вещи.</p> <p>Но результаты исследования McKinsey показывают, что ИИ начинает влиять на решения о покупке технологий, а не просто становится еще одной статьей технологического бюджета. И организации, получающие наибольшую выгоду от ИИ, похоже, движутся в этом направлении.</p> <p>McKinsey классифицирует только 6% респондентов как высокоэффективных пользователей ИИ. Это означает, что они относят не менее 5% прибыли до вычета процентов и налогов (EBIT) к ИИ и описывают его влияние как значительное. Эта доля не увеличилась по сравнению с прошлым годом. Зато стало яснее, насколько по-разному компании подходят к ИИ.</p> <p>Успешные компании внедряют более широкий спектр технологий ИИ и чаще используют ИИ для роста и инноваций, а не для повышения эффективности. Они также в 3,3 раза чаще, чем другие организации, заявляют о намерении коренным образом трансформировать свой бизнес с помощью ИИ в течение следующих трех лет.</p> <h3>Все остальные по-прежнему ищут окупаемости инвестиций</h3> <p>Обнаруженный разрыв имеет значение, потому что финансовое влияние корпоративного ИИ в целом остается на удивление неизменным.</p> <p>Только 37% респондентов заявили, что ИИ внес положительный вклад в EBIT их организации, их доля практически не изменилась по сравнению с <nobr>2025-м.</nobr> Это резко контрастирует с тем, что сообщают сами работники. Четверо из пяти (80%) заявили, что ИИ повысил их индивидуальную производительность, а 50% сказали, что он помогает им принимать более обоснованные решения.</p> <p>Таким образом, у корпоративного ИИ есть необычная проблема. Компании, похоже, накопили множество доказательств того, что технология может повысить производительность отдельных сотрудников, но им гораздо сложнее превратить эти достижения в измеримые улучшения финансовых показателей компании в целом.</p> <p>Экономические факторы также становится все труднее игнорировать. Каждый пятый респондент заявил, что операционные расходы, связанные с ИИ, включая затраты на токены, ограничивают использование ИИ. Тем не менее, большинство организаций по-прежнему ожидают увеличения своих инвестиций в ИИ в течение следующего года. Это означает, что требование демонстрации отдачи, вероятно, будет расти по мере того, как внедрение будет становиться все более масштабным и дорогостоящим.</p> <h3>Одного масштаба может быть недостаточно</h3> <p>У крупнейших компаний есть очевидное преимущество. У них больше денег, которые они могут потратить на модели, инфраструктуру, обработку данных и организационные изменения, необходимые для внедрения ИИ в сложные рабочие процессы. Но результаты исследования McKinsey показывают, что одних только затрат и масштаба недостаточно.</p> <p>Даже по мере расширения внедрения ИИ доля компаний, генерирующих значительную финансовую ценность, остается на уровне 6%. Организации, начинающие выделяться, похоже, делают нечто более фундаментальное: перестраивают способы выполнения работы с использованием ИИ, а не просто добавляют инструменты ИИ к существующим процессам.</p> <p>Это различие станет еще более важным, когда агенты выйдут за рамки просто ответов на вопросы и начнут писать ПО, получать доступ к корпоративным данным и действовать в рамках бизнес-процессов. Поэтому следующий этап развития корпоративного ИИ может быть связан не столько с тем, <em>кто</em> внедряет ИИ, сколько с тем, <em>что</em> происходит после этого. В гонку вступают почти все. Но отрываться начинает гораздо меньшая группа.</p> Гонка в сфере корпоративного искусственного интеллекта начинает демонстрировать некоторое разделение. Хотя внедрение ИИ … article https://www.itweek.ru/themes/detail.php?ID=235469 Fri, 04 Sep 2026 13:57:21 +0300 <p>Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований, технологического развития и трансформации экономики. Этот переход отчетливо прослеживается в стратегических документах Китая и Республики Корея на <nobr>2026–2030 гг.</nobr> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как эти страны адаптируют научно-технологическую политику к новой роли ИИ.</p> <p>Справочно: анализ охватывает Шестой базовый план развития науки и технологий Республики Корея (июнь 2026), Основные положения <nobr>15-го</nobr> пятилетнего плана социально-экономического развития КНР (март 2026) и Мнения Госсовета КНР об углубленной реализации инициативы «ИИ+» (август 2025).</p> <p>В обеих странах ИИ-трансформация выходит далеко за пределы научного сектора. В Китае акцент переносится с «гонки моделей» на массовую диффузию ИИ и создание новых сценариев его применения. В Южной Корее ИИ-трансформация наряду с научной системой охватывает промышленность и региональные кластеры.</p> <p>ИИ-трансформация науки опирается на национальную вычислительную инфраструктуру. Китай развивает интегрированную сеть суперкомпьютеров, центров интеллектуальных вычислений и облачных платформ; Республика Корея планирует сформировать к 2030 г. государственно-частный пул из 260 тыс. GPU.</p> <p>Китайский план ориентирован на полный цикл — от исследований до ускоренной коммерциализации. Один из новых фронтиров — физический ИИ: развитие сред для обучения роботизированных систем и разработка гуманоидных роботов. Параллельно создаются институты отраслей будущего, центры проверки концепций, механизмы разделения инвестиционных рисков и регуляторные песочницы.</p> <p>В Республике Корея ИИ встраивают непосредственно в исследовательский процесс: план предусматривает развитие ИИ-соисследователей (AI Co-Scientist), автономных лабораторий и междисциплинарных проектов с применением ИИ. Масштабная технологическая трансформация сопровождается институциональной реформой науки, включающей переход к более долгосрочному и предсказуемому финансированию исследований, а также снижение административной нагрузки.</p> <p>В совокупности опыт двух стран показывает, что комплексная ИИ-трансформация науки требует не отдельной программы поддержки ИИ, а согласованного изменения всей исследовательской среды. Наибольший интерес представляет сочетание вычислительной инфраструктуры и широкого доступа к ее ресурсам, внедрения ИИ непосредственно в исследовательский процесс, долгосрочных механизмов финансирования науки и инструментов, ускоряющих переход от исследований к практическому применению.</p> Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований … message