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=235118 Fri, 03 Jul 2026 14:10:25 +0300 <p>МТС Линк, платформа для бизнес-коммуникаций, обучения и совместной работы, запустила маркетплейс ИИ-агентов для решения рабочих задач. Согласно опросу МТС Линк, 67% россиян хотели бы делегировать ИИ-агентам рутинные действия.</p> <p>Маркетплейс встроен в единое коммуникационное приложение МТС Линк. Одним из сервисов, доступных в его рамках, стал «Ваш помощник» — агент, представленный разработчиком около года назад. Сегодня он выполняет функцию цифровой памяти сотрудника: ему можно задать любой вопрос по содержанию встреч и чатов, к которым у пользователя есть доступ. Кроме того, в первой версии маркетплейса будут доступны ассистенты, настроенные под определенные роли и функции. В частности, среди них есть редактор для HR (составляет и улучшает описание вакансий), эксперт по продажам (пишет скрипты продаж и прорабатывает возражения клиентов), маркетолог (оптимизирует тексты для SEO, готовит карточки продуктов для маркетплейсов) и SMM-менеджер (составляет контент-планы, пишет посты и разрабатывает стратегию продвижения в соцсетях). </p> <p>Список доступных на маркетплейсе агентов будет постоянно расширяться. В ближайших планах — запуск ИИ-секретаря, который сможет находить и бронировать свободное время в календарях коллег и назначать им онлайн-встречи.</p> <p>Клиенты МТС Линк уже сегодня могут интегрировать собственных агентов в корпоративный мессенджер. В будущих обновлениях они смогут самостоятельно добавлять их на маркетплейс МТС Линк — это позволит сотрудникам быстро находить нужных им агентов. Также компании получат возможность через маркетплейс предлагать своих агентов другим организациям, в том числе платно.</p> <p>«Каждый день команды сталкиваются с однотипными задачами, и всё чаще сотрудники начинают использовать публичные ИИ-модели для их решения. Это увеличивает риск утечки конфиденциальной информации. ИИ-помощники и агенты, доступные в рамках платформы корпоративных коммуникаций, снижают эти риски. А формат взаимодействия в единой среде напоминает взаимодействие с коллегами: вы можете легко найти их по имени или аватарке и написать в корпоративном мессенджере», — отметил директор по продукту МТС Линк Сергей Тарасенко.</p> <p>По данным опроса МТС Линк, 13% россиян, знакомых с ИИ, утверждают, что в их компаниях уже применяют ИИ-агентов. Самый распространенный вид агента — ИИ—секретарь, который следит за календарем, заметками, планами, протоколирует мероприятия, рассылает итоги встреч участникам и ставит задачи в календарь (он есть у 57% из тех, кто применяет агентов. На втором месте — помощник в составлении отчетов, который готовит текстовое представление данных и презентации.</p> <p>В настоящее время треть россиян, применяющих ИИ, всё ещё считает, что ИИ-агенты им не нужны. Остальные респонденты уже готовы передать им широкий спектр задач. Помимо ИИ-секретаря и составителя отчетов, каждого из которых хотели бы иметь 30% респондентов, были отмечены ассистент по ответам на электронную почту (22%) и агент-офис-менеджер, который заказывает канцелярские и офисные принадлежности (15%). Также опрошенные хотели бы делегировать ИИ подбор персонала и бронирование билетов (по 12%).</p> <p>В исследовании МТС Линк приняли участие 1010 респондентов из России, из которых 78% хотя бы иногда применяют ИИ. Опросы проведены во втором квартале 2026 года.</p> МТС Линк, платформа для бизнес-коммуникаций, обучения и совместной работы, запустила маркетплейс ИИ-агентов для решения … message https://www.itweek.ru/themes/detail.php?ID=235117 Fri, 03 Jul 2026 12:42:32 +0300 <p>Эксперты компании «Информзащита» выявили, что в 2026 году 32% уязвимостей, обнаруженных при пентестах AI- и <nobr>LLM-приложений,</nobr> относятся к высокорисковым. По всем классам активов тот же показатель составляет около 12%, поэтому риск-профиль AI-приложений в 2,7 раза выше среднего. За второй год наблюдений эта пропорция не изменилась, что исключает версию о временном эффекте раннего внедрения технологии. Одновременно медианный срок устранения серьезных находок увеличился с 19 дней в 2025 году до 36 дней в <nobr>2026-м.</nobr></p> <p>У AI-систем одновременно работают два слоя риска: базовое веб- или API-приложение сохраняет привычные проблемы с аутентификацией, авторизацией, инъекциями, доступом к секретам и обработкой пользовательского ввода; поверх них появляются сценарии, связанные с поведением модели и ее интеграциями. Prompt injection, небезопасная обработка ответа LLM, утечка системного промпта, отравление данных, ошибки в RAG-контурах, нарушения в векторных хранилищах и отказ в обслуживании на уровне модели формируют широкое поле для атак. Разработчики часто подключают модель к корпоративным данным, API, CRM, базе знаний или инструментам автоматизации, чтобы получить полезный прикладной результат. Вместе с доступом модель получает возможность влиять на процессы, а ошибка в разграничении прав или в логике вызовов превращает ответ чат-бота в точку входа во внутренние системы.</p> <p>Проверить такую архитектуру стандартным сканером непросто, поскольку многие уязвимости проявляются только в цепочке событий. Для успешного prompt injection может понадобиться несколько сообщений, специально подготовленный документ в базе знаний, определенная роль пользователя и доступ агента к внешнему сервису. Избыточная агентность зависит от сочетания системного промпта, доступных инструментов, прав учетной записи и правил оркестратора. Участники исследования подтверждают границы автоматизации: 78% команд обнаруживали, что автоматические средства пропускали критичные уязвимости. На этом фоне готовность полностью доверить пентесты автономным инструментам за год сократилась с 29% до 9%, а 47% организаций выбрали гибридную модель, в которой автоматические проверки применяются к некритичным активам, а критичные системы проверяют специалисты.</p> <p>Разбивка инцидентов по векторам атак показывает, что у AI-продуктов нет единственной доминирующей точки отказа. Среди организаций, столкнувшихся с инцидентами, в 44% случаев причиной стал shadow AI: сотрудники использовали несанкционированные внешние сервисы, и чувствительные данные оказались за пределами контролируемого контура. По 41% пришлось на отравление данных и моделей и на небезопасную обработку ответов LLM. Уязвимости цепочки поставок указали в 35% случаев, prompt injection — в 34%, ошибки LLM и слабости векторных баз и эмбеддингов — по 32%. Далее следуют избыточная агентность и утечка системных промптов — по 24%, дезинформация — 20%, неограниченное потребление вычислительных ресурсов — 15%. Такая картина требует проверять не только модель, но и источники данных, плагины, цепочки поставки, права доступа, журналы действий и правила, по которым агент вызывает инструменты.</p> <p>Отраслевой разрез отчета не ранжирует сектора по числу высокорисковых уязвимостей, поэтому называть одну сферу наиболее подверженной было бы некорректно. В выборке 2026 года, включившей 455 ИБ-специалистов из компаний с численностью от 500 сотрудников, разработка ПО представлена 27% респондентов, здравоохранение — 21%, финансовый и страховой сектор — 14%, информационные сервисы — 10%, прочие отрасли — 27%. Для разработки ПО приоритетны риски генерации кода и доступа модели к репозиториям, конвейерам CI/CD и средам разработки. В здравоохранении цена ошибки связана с медицинскими данными и интеграциями с профильными информационными системами; в финансовом секторе — с платежной информацией, решениями, затрагивающими клиентов, и операциями с повышенными требованиями к контролю доступа. Информационные сервисы чаще используют AI для обработки массивов пользовательских запросов и корпоративного контента, поэтому нуждаются в контроле источников данных и фильтрации выдачи.</p> <p> Сложность состоит не только в поиске уязвимости, но и в ее устранении. В 2026 году организации закрывали 38,4% высокорисковых находок в AI/LLM-приложениях против 21,1% годом ранее, однако это все равно самый низкий показатель среди типов тестирования. Для desktop-приложений уровень устранения составил 40,2%, для веб-приложений — 73,7%, для API — 77,3%. Исправление AI-уязвимостей требует совместной работы ИБ, разработки, архитекторов, владельцев данных и иногда поставщика базовой модели. Управленческий контур нередко не успевает за этой связностью: 57% руководителей считают, что компания стабильно соблюдает SLA на устранение уязвимостей, тогда как среди практиков с этим согласны только 15%. При разрыве в 42 процентных пункта бизнес может недооценивать объем незакрытого риска и откладывать необходимые изменения в процессах.</p> <p>Снизить эту экспозицию можно через отдельную программу безопасности AI, встроенную в жизненный цикл продукта. Эксперты «Информзащиты» рекомендуют начать с инвентаризации моделей, агентов, подключенных инструментов, внешних сервисов и источников данных, а затем установить обязательные контрольные точки перед вводом каждого AI-решения в эксплуатацию. Для моделей, работающих с внутренними данными или способных выполнять действия от имени пользователя, необходимы ручной пентест и red teaming с проверкой многошаговых атак, prompt injection, разграничения прав, сценариев утечки через RAG и последствий небезопасного вызова инструментов. Автоматизация сохраняет ценность для регулярных проверок, инвентаризации и поиска повторяемых ошибок, но не заменяет экспертную оценку бизнес-логики и архитектуры. Общие для ИБ, разработки и руководства SLA, понятный порядок эскалации, контроль shadow AI и приоритизация устранения по реальному влиянию на данные и процессы позволяют сократить период, в течение которого высокая уязвимость остается доступной для эксплуатации.</p> Эксперты компании «Информзащита» выявили, что в 2026 году 32% уязвимостей, обнаруженных при пентестах AI- … message https://www.itweek.ru/themes/detail.php?ID=235114 Fri, 03 Jul 2026 12:17:05 +0300 <p>Компания BSS представила новую версию Чат-платформы, в которой поддерживается глобальный тренд на гиперперсонализацию и автоматизацию рутинных процессов. Ключевым вектором обновления стала глубокая интеграция генеративного ИИ для помощи операторам, а также расширение экосистемы корпоративных каналов связи.</p> <p>Российский разработчик BSS, известный своими решениями в области речевых технологий и ИИ, анонсировал выход версии 2.5 омниканальной чат-платформы. Обновление превращает стандартный АРМ оператора в гибридный интеллектуальный интерфейс, где классические каналы связи дополняются продвинутыми ИИ-инструментами, функцией совместного просмотра экрана и гибкими сценариями персонализации.</p> <p>Новая версия платформы BSS делает акцент на предиктивной поддержке оператора и бесшовной интеграции. Ключевым улучшением стала встроенная генерация подсказок на основе RAG (Retrieval-Augmented Generation) — система автоматически подтягивает релевантные фрагменты базы знаний прямо в окно диалога, реализуя полный цикл работы с RAG без необходимости переключения между системами. Для повышения скорости ответа добавлены настраиваемые шаблоны сообщений и пользовательские команды, адаптируемые под специфику веб-виджета и мессенджеров. Что касается последних, то добавлена поддержка корпоративных мессенджеров VK Teams и Slack.</p> <p>С технической стороны релиз 2.5 закрывает запросы бизнеса на гибкость: появилась возможность интеграции мобильных приложений через REST API без обязательного использования WebSocket, реализован b2b-адаптер для работы через сторонний бэкенд, а также расширены сценарии авторизации клиентов, обращающихся к веб-виджету — от JS callback с настраиваемыми полями до bearer token-инициализации виджета. Внимание разработчиков также привлекли функции управления жизненным циклом данных: теперь администраторы могут настраивать периоды очистки и архивации диалогов и отчетов прямо через веб-интерфейс чат-платформы.</p> <p>Для операторов добавлены важные тактические инструменты: отдельные кнопки для запроса номера телефона и геолокации абонента, режим приватного обмена сообщениями между сотрудниками, отложенные сообщения и точное отображение времени ожидания в очереди. Возможность повторного открытия сессии с закреплением за тем же оператором и кобраузинг (совместный просмотр экрана) в веб-виджете существенно повышают NPS и снижают число повторных обращений.</p> <p>«Новая версия чат-платформы отражает наш подход к построению интеллектуальной <nobr>CX-платформы</nobr> нового уровня. Мы интегрируем ИИ не как „замену человека“, а как усиление его компетенций — через RAG-подсказки, сценарные автозаполнения и адаптивный интерфейс. Это позволяет нашим заказчикам кратно сокращать время решения инцидентов и использовать единое окно для управления всеми клиентскими коммуникациями, будь то мессенджер, веб-сайт или мобильное приложение», — прокомментировал Александр Крушинский, директор департамента голосовых цифровых технологий BSS.</p> <p>Чат-платформа BSS — это единый интерфейс взаимодействия с клиентом, который повышает эффективность работы сотрудников, улучшает качество обслуживания и оптимизирует рабочие процессы. Решение органично встраивается в существующий ИТ-ландшафт, настраивается без программирования и закрывает потребности как крупных b2b-корпораций, так и сервисных операторов. Экспертиза BSS как лидера отечественного рынка речевых технологий, ИИ-агентов и мультиагентных систем позволяет говорить о новом витке развития омниканальных платформ, где на первый план выходит не просто связь, а интеллектуальный контекст диалога.</p> Компания BSS представила новую версию Чат-платформы, в которой поддерживается глобальный тренд на гиперперсонализацию … message https://www.itweek.ru/themes/detail.php?ID=235113 Fri, 03 Jul 2026 09:43:18 +0300 <p><em>Пал Нараянан, директор по цифровым и информационным технологиям логистической компании Kenco, рассказывает на портале </em><em>InformationWeek</em> <em>о том, почему последние 20% проекта внедрения имеют решающее значение и как извлекать уроки из неудач.</em></p> <p>Любой ИТ-руководитель скажет вам, что внедрить новую технологию — это как сдвинуть гору. Нужно найти бюджет, обосновать расходы и заручиться поддержкой руководства. И это еще до того, как будут проведены переговоры с поставщиками или начнется разработка инструмента собственными силами. А после того, как продукт будет куплен или разработан, его внедрение может либо оправдать, либо не оправдать ожидания руководства.</p> <p>Для CIO и других руководителей соблюдение ряда правил при внедрении корпоративных ИТ-решений, ориентированных на сотрудников, может стать решающим фактором, который поможет командам принять новый инструмент или, наоборот, заставит их его игнорировать.</p> <h3>Важные правила</h3> <p>Помните о следующих трех вещах:</p> <p><strong>Адаптируйтесь к рабочим процессам, а не наоборот. </strong>От этого никуда не деться: рядовые сотрудники, привыкшие к своим рабочим процессам, скорее всего, отнесутся к внедрению новых ИТ-решений со скептицизмом. Дело не в самом новом инструменте, а в изменениях, которые неизбежно происходят при его внедрении.</p> <p>Возьмем, к примеру, мою отрасль — цепочки поставок. Сотрудники знают, по каким маршрутам нужно двигаться, чтобы забрать товары с определенных складских полок и доставить их на определенные упаковочные станции. Такая последовательность позволяет сборщикам максимально эффективно выполнять свою работу. Любой инструмент, требующий от сотрудников изменения подхода к работе, существенно повлияет на производительность в краткосрочной перспективе, даже если внедрение не встретит сопротивления.</p> <p>Кроме того, ИТ-команды должны учитывать, что не каждый инструмент подходит для любого здания. У каждого объекта свои эксплуатационные требования, уникальная планировка и особые потребности клиентов, которые влияют на внедрение новых ИТ-инструментов. Если внедрять универсальные технологии, то на одних объектах производительность повысится, а на других — снизится.</p> <p>Независимо от отрасли, ИТ-служба должна решить, внедрение каких технологий оправдывает краткосрочные разрушительные последствия ради долгосрочной выгоды, а какие следует адаптировать под существующие рабочие процессы. Цель должна заключаться в бесшовной интеграции, которая сокращает количество шагов, необходимых для выполнения задачи, без создания дополнительных сложностей на начальном этапе.</p> <p><strong>Не пренебрегайте последними 20% процесса управления изменениями. </strong>Когда компании внедряют какой-либо ИТ-инструмент, 80% плана внутренних коммуникаций строится на нисходящих стратегиях, таких как общее собрание с участием CIO, письмо от генерального директора или список часто задаваемых вопросов с ответами, который рассылается сотрудникам через интранет. Такие меры обычно направлены на то, чтобы ответить на самые распространенные возможные вопросы, и укладываются в схему четкого информирования.</p> <p>Но самая важная работа приходится на оставшиеся 20%: это личное общение руководителей с рядовыми сотрудниками во время и после внедрения ИТ-инструментов. Это может проходить не очень гладко, потому что у сотрудников появляется возможность рассказать о любых препятствиях или разочарованиях, с которыми они столкнулись. В такой момент сложно сформулировать выверенное сообщение.</p> <p>ИТ-службам следует поощрять такие обсуждения, а не избегать их. Через несколько месяцев после запуска руководству следует напрямую связаться с рядовыми сотрудниками, чтобы узнать, как изменилась или не изменилась их работа благодаря новой технологии. Возможно, у компании нет ресурсов, чтобы устранять все неполадки, но искреннее сопереживание может во многом помочь сотрудникам адаптироваться к изменениям.</p> <p>Такие разговоры полезны для обеих сторон. ИТ-руководители могут найти новые способы использования технологий, наблюдая за тем, как сотрудники взаимодействуют с ними в режиме реального времени.</p> <p><strong>Принимайте неудачи, не игнорируйте их. </strong>От ИТ-руководителей требуют отчета за потраченные деньги. С появлением на рынке множества новых технологий, основанных на ИИ, выбор подходящего продукта и обоснование решения о покупке могут стать непростой задачей.</p> <p>Приходится выбирать между расходами на обеспечение бесперебойной работы существующих систем и расходами на внедрение новых инструментов. Если внедрение ИТ-решений идет не так, как планировалось, у команд может возникнуть соблазн закрыть глаза на проблемы, чтобы оправдать свои вложения.</p> <p>Но хотя некоторые инвестиции настолько масштабны, что важно, чтобы они окупились, ИТ-службы не должны бояться признать, что сравнительно небольшой проект провалился, пока он не поглотил весь бюджет. Чем дольше вы будете пытаться исправить ситуацию, тем больше недоверия вы вызовете у рядовых сотрудников и тем больше времени вам понадобится, чтобы найти другой ИТ-инструмент или вернуть работу в прежнее русло.</p> <p>Вместо того чтобы просто счесть проект провальным, ИТ-службам следует тщательно проанализировать, что пошло не так, и использовать полученные уроки для дальнейших инноваций. Потраченные деньги не являются потерей, если процесс привел команду к гораздо большей эффективности при следующем запуске. Главное — честно разобраться в том, что сработало, а что нет, и какие шаги следует предпринять, чтобы избежать повторения ошибок.</p> <h3>Речь идет о честности и прозрачности</h3> <p>Всякий раз, когда компания объявляет о внедрении нового инструмента, часто возлагаются большие надежды на то, как это может упростить работу или повысить производительность. Но руководству следует быть осторожным и не позволять радужным надеждам затмевать реальность внедрения технологии на предприятии.</p> <p>Если сделать инструменты максимально простыми в освоении, напрямую обсуждать с сотрудниками, что можно улучшить, и честно рассказывать компании об успехах и неудачах, связанных с новыми инструментами, то можно сформировать коллектив, который будет поддерживать инновации и работать сообща, чтобы внедрение новых инструментов прошло успешно.</p> Пал Нараянан, директор по цифровым и информационным технологиям логистической компании Kenco, рассказывает … article https://www.itweek.ru/themes/detail.php?ID=235110 Fri, 03 Jul 2026 09:20:29 +0300 <p>Интерес бизнеса к искусственному интеллекту продолжает расти, однако количество успешных внедрений остается значительно ниже числа запущенных инициатив. Мы видим, что проблема чаще всего кроется не в качестве моделей, данных или уровне технологий. Основные ошибки возникают гораздо раньше — на этапе постановки задачи и расчета экономического эффекта.</p> <p>Мы смотрим на ИИ-проекты с разных сторон: один из нас регулярно сталкивается с компаниями, которые приходят за внедрением или пытаются реанимировать уже запущенные инициативы, второй — отвечает за развитие ИИ-продуктов и финансовый результат крупных цифровых сервисов. Несмотря на разный опыт, мы сходимся в одном: большинство проектов терпят неудачу из-за отсутствия понятной экономической модели. Значительная часть инициатив не доходит до промышленной эксплуатации, оставаясь на стадии пилотов и красивых презентаций, так как не удается доказать их ценность для бизнеса в понятных финансовых показателях.</p> <h3>Почему технологии не гарантируют результат</h3> <p>Традиционно неудачи ИИ-проектов объясняют техническими факторами: качеством данных, ошибками моделей или требованиями безопасности. Эти проблемы действительно встречаются, но мы наблюдаем парадокс: технологии становятся доступнее и эффективнее с каждым годом, а количество успешных кейсов растет медленно.</p> <p>Причина в том, что многие компании начинают проект с обсуждения «железа», моделей и архитектуры, оставляя вопрос о конкретной бизнес-задаче и финансовом результате на потом. В итоге оценка эффективности происходит тогда, когда бюджет уже потрачен, а остановка проекта воспринимается как признание поражения. Проект продолжают развивать по инерции, пока руководство не задает прямой вопрос об окупаемости.</p> <h3>Три модели окупаемости: почему важно выбрать одну</h3> <p>Разговор об эффективности ИИ бессмысленен, пока компания не определила, как именно технология будет приносить деньги. Мы предлагаем рассматривать ИИ-инициативы через три базовые модели создания ценности. Важно не смешивать их, так как они реализуются по разным механизмам:</p> <ol> <li><strong>Снижение издержек.</strong> ИИ берет на себя рутину: обработку документов, модерацию, типовые ответы. Эффект здесь прямой: замещение человеко-часов. При расчетах важно учитывать не только экономию на ФОТ, но и сопутствующие расходы (инфраструктура, ИБ), которые могут нивелировать результат.</li> <li><strong>Масштабирование принятия решений.</strong> Есть процессы, которые не растут вместе с увеличением штата. Ценность ИИ здесь — не в экономии, а в радикальном повышении скорости и охвата. Ключевая метрика — дополнительная выручка за счет обработки большего числа операций и снижение рисков благодаря глубокой аналитике.</li> <li><strong>Влияние на продажи.</strong> Рекомендательные системы, персонализация и скоринг напрямую повышают конверсию, средний чек и удержание аудитории. В этих проектах связь между алгоритмами и прибылью наиболее очевидна.</li> </ol> <p>Проблемы начинаются, когда компания пытается реализовать всё и сразу. Это размывает цели. Если нет одной главной бизнес-метрики, невозможно объективно оценить результат. Поэтому еще до старта необходимо зафиксировать основной источник экономического эффекта.</p> <h3>Как говорить с финансовым директором</h3> <p>Даже самый совершенный проект не получит поддержки, если его ценность выражена в технических терминах. Финансового директора не интересует рост точности модели (F1-score), ему важны сроки окупаемости, экономия и прирост выручки.</p> <p>Успешные команды переводят метрики на «финансовый язык»: не «точность выросла на 15%», а «экономия составит 20 млн. рублей в год». Мы настаиваем на том, чтобы расчеты велись интегратором совместно с заказчиком. Когда бизнес самостоятельно участвует в формировании исходных данных по процессам, обсуждение становится конструктивным, а ответственность за результат — общей.</p> <h3>Экономика как инструмент переговоров</h3> <p>Правильно рассчитанная экономика помогает выстроить честные отношения при согласовании стоимости внедрения. Обсуждение перестает быть торгом за цену разработки — в центре внимания оказывается создаваемая ценность. Однако здесь важно избегать завышенных ожиданий: они помогают получить бюджет на старте, но неизбежно ведут к потере доверия, если реальные показатели не совпадут с прогнозом.</p> <h3><strong>Почему сложно обещать фиксированный бюджет</strong></h3> <p>Индустрия ИИ меняется быстро. Новые модели требуют обновления инфраструктуры, а расходы на информационную безопасность только растут. В таких условиях рассчитывать на жесткий фиксированный бюджет в долгосрочной перспективе нереалистично.</p> <p>Более устойчивый подход — сценарное планирование. Оно включает базовую оценку затрат, учет рисков (рост цен на ИБ и «железо») и создание резервного фонда на случай изменения технологического ландшафта.</p> <h3>In-house или SaaS: вопрос контроля</h3> <p>Часто компании думают, что создают собственное решение, хотя по факту используют внешние сервисы. Проблемы начинаются, когда поставщик меняет тарифы или условия.</p> <p>Мы советуем оценивать этот выбор через критичность процесса:</p> <ul> <li> Если технология влияет на ключевую выручку или лежит в основе продукта — ее нужно развивать in-house, сохраняя контроль над архитектурой.</li> <li> Если задача типовая — SaaS-модель часто выгоднее.</li> </ul> <p>Главный вопрос: что будет, если поставщик исчезнет или увеличит цены в несколько раз? </p> <h3>Итог: экономика важнее технологий</h3> <p>Успешность ИИ-проекта определяется не выбором модели, а качеством его экономического обоснования. Если работа начинается с расчета эффекта, даже неудачный эксперимент становится полезным опытом — вы получаете данные о том, какие гипотезы не подтвердились.</p> <p>Поэтому главный вопрос до запуска любого проекта звучит не «какую модель выбрать», а «какую ценность она создаст для бизнеса и как мы будем ее измерять». Именно это отделяет работающий бизнес-инструмент от дорогостоящей презентации.</p> <p>#IMAGE_235111#</p> <p>#IMAGE_235112#</p> Интерес бизнеса к искусственному интеллекту продолжает расти, однако количество успешных внедрений остается значительно ниже … article Валерий Котелов, CEO digital-интегратора KOTELOV, Павел Боюка, директор по ИИ-продуктам ООО “Оператор Газпром ИД” https://www.itweek.ru/themes/detail.php?ID=235107 Thu, 02 Jul 2026 15:05:45 +0300 <p>Группа Arenadata представила новую версию системы потоковой передачи и обработки данных Arenadata Streaming (ADS). В релизе 4.0.0.b1 реализована поддержка спецификации Apache Iceberg V3, обновлён коннектор для работы с Arenadata DB и инструменты мониторинга.</p> <p>В новой версии расширена функциональность Iceberg Sink Connector, который теперь поддерживает спецификацию Iceberg V3. Это позволяет использовать современные возможности табличного формата без потери производительности — работать с типами данных VARIANT и UNKNOWN, временными метками с точностью до наносекунд, векторами удаления (Deletion Vectors) и ключами шифрования метаданных.</p> <p>Обновлён NiFi ADB Connector — в его состав включён процессор GetGreengageRecord, предназначенный для загрузки данных из Greengage DB через протокол gpfdist. Процессор поддерживает режим пошаговой выгрузки, предполагающий чтение только вновь появившихся диапазонов данных, что позволяет снизить нагрузку на СУБД и NiFi, в том числе в сценариях реального времени. Кроме того, теперь NiFi ADB Connector «из коробки» поддерживает работу с Arenadata DB (ADB) 7.</p> <p>В релизе добавлена поддержка операционной системы Astra Linux 1.8. Появилась возможность использования мастера ADCM Wizard для установки ADS: он позволяет развернуть кластер с предварительной настройкой конфигураций безопасности — SSL, Kerberos, плагинов Ranger или их комбинацией. Реализована поддержка мониторинга на базе VictoriaMetrics с использованием кластера Arenadata Monitoring (ADM). </p> <p>Обновлены версии сервисов экосистемы Kafka и NiFi, коннекторов Debezium и Iceberg, а также сервиса Arenadata Monitoring. </p> <p>Arenadata Streaming — масштабируемая отказоустойчивая система для потоковой обработки данных в режиме реального времени, адаптированная для корпоративного использования и построенная на базе Apache Kafka и NiFi. Продукт включает графический пользовательский веб-интерфейс для управления кластерами потоковой передачи (ADS Control, ADSC), поддержку расширенной безопасности (Arenadata Platform Security, ADPS), а также ряд дополнительных инструментов для реализации репликации, проверки качества данных и других необходимых для продуктовой эксплуатации функций.</p> <p>Arenadata Streaming позволяет:</p> <ul> <li>в реальном времени строить потоковые конвейеры данных, надёжно передающих данные между системами или приложениями;</li> <li>в реальном времени разрабатывать потоковые приложения, преобразующие потоки данных или реагирующие на них;</li> <li>хранить потоки записей отказоустойчивым долговечным способом;</li> <li>разграничивать права доступа к потокам данных.</li> </ul> <p>На Arenadata Streaming получено свидетельство о государственной регистрации программы для ЭВМ. Продукт включён в единый реестр российских программ для электронных вычислительных машин и баз данных.</p> Группа Arenadata представила новую версию системы потоковой передачи и обработки данных Arenadata Streaming (ADS … message https://www.itweek.ru/themes/detail.php?ID=235106 Thu, 02 Jul 2026 14:37:02 +0300 <p>Генеративный ИИ уже заметно ускоряет работу исследователей, однако его влияние на конечные научные результаты пока остается ограниченным. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил, как российские ученые оценивают эффекты применения генеративных ИИ-сервисов в своей деятельности.</p> <p>Большинство российских ученых, применяющих генеративный ИИ в своей работе, уже видят практическую пользу, а в перспективе ожидают дальнейшего усиления его роли. Каждый второй пользователь считает, что такие технологии способствуют развитию его области науки (52%), еще 41% оценивают их влияние неоднозначно.</p> <p>Наиболее высоко вклад генеративного ИИ оценивают представители медицинских наук (64%), наиболее сдержанно — гуманитарных (41%). Женщины-исследователи, использующие генеративный ИИ, чаще мужчин считают его одновременно полезным и бесполезным для своей области науки (46% против 36%). При этом возраст ученых практически не влияет на оценку воздействия этих сервисов.</p> <p>Основные эффекты генеративного ИИ сегодня проявляются на уровне исследовательского процесса, а не его конечных результатов. Пользователи отмечают, что такие технологии прежде всего сокращают время на поиск научной литературы (71%), анализ данных (65%) и подготовку текстов на иностранном языке (64,5%), одновременно улучшая качество выполнения этих задач. Вместе с тем около 60% не наблюдают изменений в собственной публикационной активности, а оценки влияния ИИ на качество научных результатов разделились практически поровну (42% против 47%).</p> <p>Несмотря на существующие ограничения, генеративный ИИ, по мнению опрошенных ученых, пока практически не создает негативных эффектов для исследовательской деятельности. Лишь 5% пользователей отмечают ухудшение качества поиска научной литературы, около 3% — снижение скорости такого поиска, а по большинству остальных параметров доля негативных оценок не превышает 2%.</p> Генеративный ИИ уже заметно ускоряет работу исследователей, однако его влияние на конечные научные результаты пока … message https://www.itweek.ru/themes/detail.php?ID=235105 Thu, 02 Jul 2026 14:33:10 +0300 <p>Провайдер облачной сетевой инфраструктуры и решений в области кибербезопасности и доставки контента CURATOR, специализирующийся на обеспечении доступности интернет-ресурсов, нейтрализации DDoS-атак и защите веб-приложений, в рамках развития технологического сотрудничества с ИБ-компанией Alpha Systems, представил CURATOR.SCANNER — решение для регулярного выявления уязвимостей во внешней инфраструктуре компании, интегрированное непосредственно в личный кабинет платформы CURATOR.</p> <p>CURATOR.SCANNER выявляет открытые сетевые сервисы, определяет версии программного обеспечения, обнаруживает известные уязвимости, ошибки конфигурации и потенциальные векторы атак, а также помогает приоритизировать найденные риски и получить рекомендации по их устранению. Для запуска CURATOR.SCANNER достаточно задать объект проверки — домен, IP-адрес, диапазон адресов или веб-приложение — и подходящий шаблон сканирования прямо в интерфейсе платформы CURATOR: установка дополнительного программного обеспечения не требуется.</p> <p>Решение поддерживает несколько типов проверок: активное сканирование, обнаружение веб-компонентов, определение версий программного обеспечения и их сопоставление с базами известных уязвимостей, сканирование веб-приложений, выявление уязвимостей класса SQL Injection и других распространенных веб-рисков. Также CURATOR.SCANNER может определять наличие WAF и учитывать особенности его работы при проверке веб-приложений.</p> <p> «Часто успешные атаки начинаются с эксплуатации конкретной уязвимости во внешнем периметре. При этом многие компании либо не проверяют периметр регулярно, либо используют для этого отдельные инструменты, которые требуют значительных ресурсов на внедрение и сопровождение. CURATOR.SCANNER закрывает этот пробел: клиент получает возможность регулярно проверять свои ресурсы прямо из личного кабинета, без лишних затрат на инфраструктуру», — поделился Дмитрий Ткачев, генеральный директор CURATOR.</p> <p>«Партнерство с CURATOR позволило нам объединить возможности непрерывного мониторинга доступности и защиты интернет-ресурсов с инструментами анализа уязвимостей и конфигурационных ошибок. В результате пользователи платформы получают единый контур контроля внешнего периметра: от выявления рисков и оценки потенциальных векторов атак до защиты ресурсов от реальных угроз», — отметил Игорь Смирнов, генеральный директор Alpha Systems.</p> <p>Для большинства найденных уязвимостей автоматически применяется безопасная валидация, которая помогает отделить подтвержденные риски от потенциальных и сфокусировать ресурсы команды на наиболее значимых проблемах.</p> <p>Результаты каждого сканирования отображаются в личном кабинете CURATOR. Для каждой обнаруженной уязвимости указываются уровень критичности, описание проблемы, затронутый объект и рекомендации по устранению. Уязвимости распределяются по четырем уровням критичности — от критического до низкого, что позволяет выстраивать приоритизированный план исправлений.</p> <p>CURATOR.SCANNER дополняет существующий портфель облачных решений CURATOR. DDoS-защита помогает обеспечивать доступность интернет-ресурсов, WAF снижает риск эксплуатации уязвимостей веб-приложений, а сканер помогает заранее выявлять слабые места в заданном внешнем периметре клиента — не только на уровне веб-приложений, но и на уровне открытых сетевых сервисов.</p> <p>Результаты сканирования могут использоваться не только для устранения уязвимостей в приложениях и инфраструктурных компонентах, но и для настройки защитных механизмов CURATOR. Если уязвимость нельзя устранить оперативно, WAF может применяться как компенсирующая мера: для настройки новых правил, оптимизации существующих политик фильтрации и снижения вероятности эксплуатации до исправления первопричины. Таким образом, клиент получает в одном личном кабинете инструменты для обеспечения непрерывной доступности, фильтрации вредоносного трафика и регулярного контроля защищенности интернет-периметра.</p> Провайдер облачной сетевой инфраструктуры и решений в области кибербезопасности и доставки контента CURATOR … message https://www.itweek.ru/themes/detail.php?ID=235104 Thu, 02 Jul 2026 14:31:18 +0300 <p>Бизнес в России активно переходит от пилотных проектов искусственного интеллекта к его промышленной эксплуатации, однако вместе с ростом внедрения резко увеличиваются и риски: модели становятся привлекательной целью для киберпреступников. По словам Владимира Лебедева, директора по развитию бизнеса M1Cloud, защищенное облако перестает быть просто «местом хранения мощностей» и превращается в полноценную платформу для цифровой ИИ-трансформации.</p> <p>Уже в 2026 году искусственный интеллект в промышленности широко применяется для предиктивного обслуживания оборудования, оптимизации производственных процессов, контроля качества и создания цифровых двойников.</p> <p>По данным НИР Груп, количество успешных атак на ИИ-модели в 2025 году выросло на 48% по сравнению с предыдущим годом. По данным «Кросс технолоджис», в первой половине 2025 года количество атак на ИИ-системы производственных предприятий составило 19% от общего числа киберугроз.</p> <p>Промышленный ИИ оперирует критически важными данными, такими как показания датчиков, технологические параметры и цепочки поставок. При этом он сталкивается с целым рядом специфических угроз: к основным векторам атак относятся состязательные (adversarial) атаки, при которых небольшие и незаметные искажения входных данных заставляют модель принимать неверные решения — например, пропускать брак на конвейере или вызывать ложное срабатывание защиты оборудования. Серьезную опасность представляет отравление данных (poisoning) на этапах обучения или дообучения модели. Кроме того, существуют инверсионные атаки, позволяющие восстановить конфиденциальную информацию о производственном процессе, а также внедрение вредоносных инструкций (prompt injection) в агентные системы, управляющие робототехникой и логистикой.</p> <p>Для промышленных компаний последствия таких инцидентов могут быть катастрофическими и выражаться не только в многодневном простое производственной линии стоимостью в десятки миллионов рублей в сутки, но и в утечке уникальных технологий или нарушении строгих требований промышленной безопасности.</p> <p>Облачные платформы позволяют выносить мониторинг ИИ-моделей на инфраструктурный уровень. Вместо разрозненных средств защиты предприятия получают централизованную систему, которая анализирует поведение моделей в реальном времени (drift detection), сравнивает входные данные с baseline-профайлами, автоматически изолирует подозрительные запросы, а также интегрируется с решениями специализированных вендоров по защите ИИ (например, платформой типа СЗИИ).</p> <p>Облако дает преимущество эластичности в моменты пиковых нагрузок (масштабное дообучение моделей) ресурсы GPUaaS выделяются автоматически, а чувствительные данные остаются в изолированных контурах, соответствующих требованиям регуляторов.</p> <p>Защищенное облако позволяет промышленным компаниям перейти от операционной автоматизации к стратегическому использованию ИИ. Ключевыми направлениями на <nobr>2026–2028</nobr> годы станут создание цифровых двойников предприятий и отдельных агрегатов, внедрение многоагентных систем, координирующих работу цехов и цепочек поставок, а также развитие предиктивной аналитики для прогнозирования спроса, износа оборудования и рисков.</p> <p>По прогнозам аналитиков M1Cloud, российский рынок ИИ в промышленности продолжит уверенный рост, следуя за глобальным трендом высоких темпов развития отрасли, где доминируют масштабируемые облачные решения. К 2028 году ожидается массовый переход к гибридным архитектурам: критически важные модели будут работать в защищенном облаке, а часть вычислений переместится на edge-устройства непосредственно на производстве.</p> <p>В 2026 году значительно выросли вложения в инструменты ИИ для информационной безопасности. Наблюдается переход от отдельных моделей к полноценным AI-native производственным системам, а также популяризация мультиклауд-подходов для баланса между безопасностью и стоимостью.</p> <p>К <nobr>2027–2028</nobr> годам ожидается ужесточение регуляторных требований к безопасности искусственного интеллекта на критически важных объектах. Компании, которые уже сейчас строят защиту на уровне инфраструктуры, получат значительное преимущество: они смогут быстрее проходить аудиты, снижать страховые риски и масштабировать ИИ-проекты опережающими темпами.</p> <p>Промышленные предприятия, использующие защищенное облако, смогут не только оперативно реагировать на киберугрозы, но и превращать данные в стратегическое конкурентное преимущество — точнее прогнозировать простои, оптимизировать энергопотребление и повышать общую эффективность производства на <nobr>10-20%</nobr> и более.</p> <p>Компании, которые сегодня внедряют мониторинг атак на искусственный интеллект и выстраивают стратегию на горизонте <nobr>3–5 лет,</nobr> будут готовы к новым регуляторным и рыночным вызовам.</p> Бизнес в России активно переходит от пилотных проектов искусственного интеллекта к его промышленной эксплуатации … message https://www.itweek.ru/themes/detail.php?ID=235102 Thu, 02 Jul 2026 09:42:01 +0300 <p><em>По мере того как внедрение искусственного интеллекта набирает обороты в корпоративном секторе, организации усваивают важный урок: поверхностного обучения, привязанного к отдельным сценариям использования, недостаточно. Чтобы добиться успеха, организации должны рассматривать грамотность в области ИИ как стратегически важный навык для всего предприятия, пишет в корпоративном блоге Джина Смит, директор </em><em>IDC</em> <em>по исследованиям в области ИТ-навыков для цифрового бизнеса.</em></p> <p>Это означает, что обучение работе с ИИ должно стать частью корпоративной культуры, структуры управления, процесса адаптации новых сотрудников и требований к эффективности работы. Это также означает отказ от подхода, ориентированного на пилотные проекты, и создание систематических программ с постоянной поддержкой со стороны руководства, учебных программ с учетом должностных обязанностей и реальной дисциплины управления изменениями.</p> <p>Исследование IDC выявило существующий разрыв в этой области.</p> <blockquote> <p><em>Согласно опросу IDC «2026 Global IT Skills Survey», только треть мировых ИТ-руководителей и бизнес-лидеров утверждают, что полностью готовы внедрить ИИ в повседневную работу. Около 93% ИТ-руководителей считают владение ИИ самым важным корпоративным навыком, однако многие организации еще не приступили к обучению сотрудников работе с ИИ.</em></p> </blockquote> <p>Тем временем компании продолжают реализовывать свои планы по внедрению ИИ. В результате многие сотрудники вынуждены импровизировать, используя те инструменты, на которые делают ставку их компании. Добрые намерения не заменят реальных организационных знаний о том, что может и чего не может ИИ, а также о том, как его лучше всего использовать.</p> <p>Как показало недавнее исследование IDC «Foundation AI Literacy», посвященное базовым компетенциям, необходимым каждому сотруднику для ответственного и эффективного использования ИИ, обучением работе с ИИ должны быть охвачены все, а не только технические специалисты. Масштабирование здесь означает переход от обучения на пилотных проектах и по конкретным сценариям использования к многоуровневой программе, охватывающей весь коллектив. Начните с основ для всех сотрудников: что такое ИИ и чем он не является, правила ответственного использования и основные риски, в том числе предвзятость, галлюцинации, нарушение конфиденциальности и утечка данных. Затем расскажите о преимуществах, возможностях для расширения функционала и повышения производительности. Большинство сотрудников не имеют систематической академической подготовки в области ИИ, поэтому важно, чтобы обучение было доступным и учитывало должностные обязанности.</p> <p>Вот шесть практик, которые отличают успешные инициативы в области ИИ в международных организациях.</p> <p>#IMAGE_235103#</p> <h3>1. Заручитесь поддержкой руководства</h3> <p>Успешные программы начинаются с видимой и постоянной поддержки со стороны высшего руководства. Когда генеральный или операционный директор ясно дает понять, что ответственное использование ИИ является приоритетом для бизнеса, внедрение ИИ ускоряется. Рассматривайте грамотность в вопросах ИИ как стратегический навык сотрудников, напрямую связанный с целями организации, системами управления рисками и приоритетами в области корпоративного управления. Он должен быть частью системы управления ИИ и соблюдения нормативных требований, а не существовать отдельно от них.</p> <h3>2. Адаптируйте программу под конкретные роли</h3> <p>После того как будет заложена основа, добавьте модули, ориентированные на конкретные роли. Бизнес-руководителям необходимы навыки принятия стратегических решений, контроля и оценки рисков. Техническим командам нужны навыки внедрения, проверки и мониторинга. Добавьте к этому обучение на основе сценариев: реалистичные отраслевые кейсы и примеры эффективного использования, взятые из вашей среды, по возможности в смоделированных условиях. Чем ближе обучение к реальной работе, тем лучше оно усваивается.</p> <h3>3. Внедрите принципы управления</h3> <p>Принципы ответственного использования ИИ, справедливости, прозрачности, подотчетности и конфиденциальности не должны быть отдельным модулем. Включите их в программу обучения. Обучение должно быть направлено на закрепление внутренних политик использования ИИ, стандартов классификации данных, процедур эскалации и контроля, а также требований к документации. Используйте реальные примеры из вашей отрасли. Конкретные примеры реальных последствий — как положительных, так и отрицательных — вот что помогает внедрить систему управления.</p> <h3>4. Закрепляйте и измеряйте результаты</h3> <p>Одноразовое обучение не дает результата, поскольку возможности, риски и политики, связанные с ИИ, постоянно меняются. Включите в программу периодические новшества, проверку знаний, обратную связь и постоянные обновления, а также внедрите закрепление материала непосредственно в повседневные рабочие процессы, чтобы повысить уровень усвоения. Оценивайте не только процент прохождения обучения. Отслеживайте изменения в поведении и их влияние. Внедрение одобренных ИИ-инструментов, сокращение нарушений правил, улучшение качества документации, а также повышение производительности и качества могут и должны быть связаны с ответственным подходом к использованию ИИ. Эти показатели дают уверенность в том, что программа действительно работает, а также доказательства, необходимые для сохранения инвестиций в нее.</p> <h3>5. Используйте разные способы обучения</h3> <p>Разные форматы закрепляют разные модели поведения, и зрелые программы не ограничиваются одним форматом. Они сочетают в себе самостоятельное электронное обучение, очные семинары, микрообучение, практические занятия и подсказки в приложениях. Встречаться с людьми там, где они работают, в процессе их деятельности, гораздо эффективнее, чем проводить разовые мероприятия.</p> <h3>6. Руководите и поддерживайте</h3> <p>Все это не сработает без видимой и постоянной поддержки со стороны руководства. Относитесь к грамотности в области ИИ как к базовой, обязательной компетенции для всех сотрудников, как к обучению по вопросам кибербезопасности или конфиденциальности данных. Четкая коммуникация помогает: делайте акцент на том, что ИИ — это инструмент, а не цель, подчеркивайте приверженность организации ответственному использованию ИИ и то, как грамотность в этой области помогает выполнять миссию, управлять ресурсами и рисками. Грамотное управление изменениями снижает неопределенность. Кроме того, это препятствует использованию теневого ИИ, когда люди прибегают к неутвержденным инструментам, потому что никто не показал им одобренный путь.</p> <p>Вывод прост. Организации, которые рассматривают грамотность в области ИИ как стратегический потенциал, смогут сократить разрыв между инвестициями в ИИ и результатами его применения. Те же, кто пренебрегает этой дисциплиной, столкнутся с растущим разрывом между амбициями и готовностью к переменам.</p> По мере того как внедрение искусственного интеллекта набирает обороты в корпоративном секторе, организации усваивают … article https://www.itweek.ru/themes/detail.php?ID=235100 Thu, 02 Jul 2026 09:32:44 +0300 <p><em>Low-code часто обсуждают в контексте скорости создания решений, и это действительно важное преимущество технологии. Однако настоящая проверка low-code начинается после запуска. Рассмотрим, как выстроить надежный ИТ-сервис с понятным жизненным циклом.</em></p> <h3>Почему low-code нельзя оставлять без системы управления</h3> <p>На этапе пилотного проекта low-code-решение часто находится в неформальной модели поддержки. Команда небольшая, пользователи известны, процесс ограничен, а изменения происходят быстро. Если возникают сбои, понятно, к кому обратиться. Если нужна доработка, ее можно обсудить напрямую.</p> <p>Как только приложение попадает в промышленную эксплуатацию, оно становится частью ИТ-сервиса. Количество обращений резко возрастает вместе с увеличением числа пользователей, при этом команде необходимо оперативно реагировать на инциденты, решать вопросы с доступами и заниматься обновлениями.</p> <p>Для промышленного low-code нужен выстроенный процесс управления ИТ-услугами (IT Service Management, ITSM): каталогизация сервисов, управление инцидентами и изменениями, контроль доступов, планирование релизов, ведение базы знаний и прозрачный жизненный цикл решений.</p> <p>Когда low-code становится корпоративным инструментом, появляются вопросы, которые нельзя решать в ручном режиме:</p> <ul> <li> куда пользователь обращается при ошибке;</li> <li> кто классифицирует инцидент;</li> <li> какой уровень поддержки у приложения;</li> <li> кто технический и бизнес-владелец;</li> <li> кто согласует изменение;</li> <li> как фиксируются доработки;</li> <li> какие системы и данные затрагивает приложение;</li> <li> как проверяется влияние обновлений платформы;</li> <li> кто управляет доступами;</li> <li> где хранится документация;</li> <li> как решение выводится из эксплуатации.</li> </ul> <p>Если ответов нет, low-code-портфель оказывается в серой зоне. Формально приложения работают, бизнес ими пользуется, процессы начинают от них зависеть, но в операционной модели ИТ они не отражены как управляемые сервисы. Для бизнеса это означает непредсказуемость: непонятно, кто отвечает за сбой и сколько времени займет восстановление, что будет при обновлении платформы и можно ли рассчитывать на решение в критичный момент.</p> <h3>Low-code-приложение как ИТ-сервис</h3> <p>При зрелом подходе промышленное low-code-приложение рассматривается не как быстрая автоматизация, а как ИТ-сервис с жизненным циклом.</p> <p>Он обладает понятными атрибутами:</p> <ul> <li> назначение;</li> <li> технический и бизнес-владелец;</li> <li> пользователи;</li> <li> критичность;</li> <li> уровень поддержки;</li> <li> связанные системы;</li> <li> данные и интеграции;</li> <li> правила доступа;</li> <li> порядок обработки инцидентов;</li> <li> порядок внесения изменений;</li> <li> требования к обновлениям;</li> <li> документация;</li> <li> условия вывода из эксплуатации.</li> </ul> <p>Это не значит, что даже небольшое low-code-решение должно сопровождаться как крупная ERP-система, но все решения должны быть классифицированы. Для простой внутренней формы можно использовать облегченный маршрут поддержки. Приложение, которое влияет на клиентский процесс или операционную цепочку, должно находиться в более строгой модели: с SLA, регламентом изменений, тестированием, контролем доступов и планом восстановления.</p> <h3>Каталог low-code-сервисов</h3> <p>Первый элемент ITSM-контура — каталог low-code-сервисов. Компания должна понимать, какие low-code-решения она использует, какие процессы они поддерживают и кто за них отвечает.</p> <p>Этот каталог может быть частью базы данных управления конфигурациями (CMDB), каталога ИТ-сервисов или отдельного реестра, который интегрирован с ITSM-процессами. Главное, чтобы low-code-решения не существовали отдельно от общей картины ИТ-ландшафта.</p> <p>Без каталога невозможно управлять портфелем. Если нет владельца, неясно, кто принимает решение о развитии. Если не указаны зависимости, обновление платформы может неожиданно затронуть бизнес-процесс. Когда неизвестна критичность, невозможно правильно расставить приоритеты при инциденте.</p> <h3>Управление инцидентами</h3> <p>Второй элемент — управление инцидентами. У пользователя должен быть понятный канал обращения. Ошибка не должна решаться через личные сообщения разработчику или случайный чат проектной команды. Инцидент должен попадать в общий процесс поддержки: регистрироваться, классифицироваться, назначаться ответственному, получать приоритет и закрываться с фиксацией результата.</p> <p>Для low-code особенно важно правильно определить источник проблемы. Сбой может быть связан не с самим приложением, а с платформой, интеграцией или другими факторами. Без классификации поддержка начинает работать вслепую. Пользователь видит одно: «приложение не работает», но для устранения причины нужно понять, где именно нарушился контур.</p> <p>Для low-code полезно выделять отдельные категории инцидентов:</p> <ul> <li> ошибка пользовательского сценария;</li> <li> ошибка бизнес-логики;</li> <li> проблема доступа;</li> <li> проблема интеграции;</li> <li> недоступность платформы;</li> <li> ошибка внешней системы;</li> <li> проблема данных;</li> <li> последствия обновления;</li> <li> ошибка ИИ-сценария или агента.</li> </ul> <p>Такая классификация помогает быстрее маршрутизировать обращения и видеть повторяющиеся проблемы.</p> <h3>Управление изменениями</h3> <p>Low-code создает ощущение, что изменения можно вносить почти мгновенно. Но если приложение уже используется в промышленной среде, любая доработка может повлиять на пользователей, данные, интеграции и смежные процессы. Поэтому изменение должно быть управляемым, даже если оно небольшое.</p> <p>Необязательно каждую правку проводить через длительные согласования. Однако нужно знать, кто инициировал изменение, какую проблему оно решает и кто согласовал бизнес-логику. Важно также понимать, когда изменение будет опубликовано, каких пользователей затронет, нужно ли тестирование и кто отвечает за откат, если что-то пойдет не так.</p> <p>Для простых изменений может быть легкий маршрут. Например, при добавлении поля без влияния на интеграции или настройке уведомлений. Однако для изменений, которые затрагивают права, данные, интеграции, критичные процессы или ИИ-агентов, нужен более строгий контроль.</p> <h3>Управление доступами</h3> <p>Low-code-решения работают с корпоративными данными, бизнес-процессами и интеграциями, поэтому доступы нельзя выдавать по принципу «попросили в чате — добавили». Должен быть понятный процесс: кто может запросить доступ, кто его утверждает и как он отзывается при смене роли сотрудника.</p> <p>Помимо пользовательских доступов, важно управлять сервисными учетными записями, интеграционными правами и правами ИИ-агентов. Если агент или автоматический сценарий может выполнять действия в системе, его права должны быть описаны так же строго, как права пользователя-человека: что он может видеть и менять, какие действия требуют подтверждения и где фиксируется цифровой след.</p> <h3>Релизы, обновления и уязвимости</h3> <p>Low-code-платформы постоянно развиваются: появляются новые компоненты, коннекторы, ИИ-функции и обновления безопасности. Каждое такое изменение может повлиять на работающие приложения. Если компания не знает, какие компоненты и интеграции используются в ее приложениях, обновление становится лотереей.</p> <p>В ITSM-контуре обновление должно проходить как управляемое изменение. Сначала оценивается его влияние и определяются затронутые сервисы, выполняется тестирование и оповещение владельцев, после чего проходит установка, проверка и фиксация результата.</p> <p>Для критичных уязвимостей нужен ускоренный маршрут. Откладывать исправления до удобного момента опасно: известные уязвимости быстро анализируются и используются злоумышленниками., но ускоренный маршрут не означает хаотичный. В любом случае он должен включать оценку риска, приоритизацию, тестовый контур, проверку ключевых сценариев и план отката.</p> <h3>База знаний и поддержка</h3> <p>Чтобы low-code-портфель сопровождался устойчиво, знания не должны замыкаться на отдельных разработчиках или подрядчиках.</p> <p>По каждому значимому решению нужны минимальные материалы: описание назначения, схема процесса, основные роли, типовые ошибки, инструкция для первой линии поддержки, контакты владельцев, список интеграций, правила доступа, сценарии восстановления и история изменений.</p> <p>Быстрые решения часто документируются хуже классических проектов. Пока рядом команда внедрения, проблема незаметна. Через полгода—год отсутствие знаний превращается в риск сопровождения. База знаний снижает зависимость от конкретных сотрудников и помогает встроить low-code в операционную поддержку.</p> <h3>Жизненный цикл и вывод из эксплуатации</h3> <p>Не каждое low-code-решение рассчитано на долгую эксплуатацию. Часть из них создается как минимально жизнеспособный продукт (MVP), часть — для закрытия временных потребностей. Некоторые приложения дублируют функциональность, которая позже появляется в основной корпоративной системе. Другие устаревают вместе с процессом.</p> <p>Если решения не выводить из эксплуатации, портфель начинает разрастаться. Поддерживать приходится все — от старых форм и неактуальных интеграций до устаревших доступов и приложений без владельца. Поэтому в ITSM-контуре должен быть статус жизненного цикла: пилот, промышленная эксплуатация, развитие, ограниченная поддержка, архивирование, вывод из эксплуатации.</p> <p>Вывод решения из эксплуатации — тоже управляемый процесс. Нужно понять, кто использует приложение, какие данные нужно сохранить, какие интеграции отключить, кого уведомить и чем заменить функцию. Без этого low-code превращается в накопитель технологического долга.</p> <h3>Как связать ITSM и центр компетенций</h3> <p>ITSM-контур не должен существовать отдельно от центра компетенций low-code. Центр компетенций отвечает за методологию, архитектурные правила, каталог компонентов, качество и развитие практики. ITSM берет на себя эксплуатационную дисциплину: инциденты, изменения, доступы, релизы, знания, SLA и жизненный цикл.</p> <p>Вместе они дают полноценную модель. Центр компетенций помогает определить, как low-code-приложение должно создаваться, а ITSM обеспечивает его работу после запуска. Если эти функции не связаны, возникает разрыв: проекты быстро создаются по методологии, но потом выпадают из поддержки. Возможна и обратная ситуация: поддержка пытается сопровождать приложения, о которых нет систематизированной архитектурной и продуктовой информации.</p> <p>В зрелой модели каждое промышленное low-code-решение попадает из проектного контура в операционный: с владельцем, документацией, уровнем поддержки, регламентом изменений и записью в каталоге сервисов.</p> <h3>Роль интегратора</h3> <p>Для крупного бизнеса роль интегратора не заканчивается разработкой приложения. Он помогает выстроить весь его жизненный цикл: от выбора сценариев и архитектуры до промышленной эксплуатации, поддержки и развития портфеля. В контексте ITSM это означает помощь в создании каталога low-code-сервисов, описании моделей поддержки, настройке процессов инцидентов и изменений, регламентах обновлений, базе знаний и выводе решений из эксплуатации.</p> <p>Low-code-направление может быть полезно не только как команда быстрой разработки, но также как партнер, способный встроить технологию в зрелую операционную модель ИТ. Это особенно важно для ИТ-директоров. Помимо скорости сборки, их волнует, как приложение будет поддерживаться, кто за него отвечает и как портфель решений будет жить через год.</p> <p> #IMAGE_235101#</p> Low-code часто обсуждают в контексте скорости создания решений, и это действительно важное преимущество технологии … article Михаил Миронов, директор отделения low-code-решений группы компаний IBS https://www.itweek.ru/themes/detail.php?ID=235099 Wed, 01 Jul 2026 16:30:06 +0300 <p>Научные открытия по-прежнему делают люди, но значительную часть работы с растущими потоками данных все чаще выполняют с помощью искусственного интеллекта. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал масштабы и направления использования этой технологии российскими учеными.</p> <p>Главные выводы:</p> <ul> <li>85% опрошенных ученых уже применяют ИИ-решения в своей работе;</li> <li>основным форматом взаимодействия с ИИ стали генеративные сервисы: ими пользуются 99% ученых, работающих с ИИ (84% всех ученых). Специализированные инструменты применяют около трети пользователей ИИ (32%), или 27% всех опрошенных ученых;</li> <li>ИИ быстро проходит путь от новой технологии к повседневному инструменту исследователя. Притом что генеративные сервисы большинство респондентов (76%) освоили лишь в последние два года, уже более двух третей их пользователей (68%) обращаются к ним не реже раза в неделю, в том числе 35% — ежедневно. Еще треть (32%) используют такие сервисы несколько раз в месяц или реже;</li> <li>генеративный ИИ широко распространен во всех областях науки: среди представителей социальных наук его используют 89% исследователей, технических, медицинских и естественных наук — <nobr>84–87%,</nobr> гуманитарных и сельскохозяйственных — <nobr>76–77%.</nobr> При этом дисциплинарные различия проявляются прежде всего в характере использования таких инструментов. Так, для работы с кодом генеративный ИИ применяют около трети представителей естественных и технических наук (по 32%), тогда как в гуманитарных науках — лишь 4%. В отношении специализированных инструментов значимые дисциплинарные различия почти не наблюдаются. Единственное исключение — гуманитарные науки, среди представителей которых только 16% применяют ИИ такого типа (против 29% в среднем по другим областям);</li> <li>возрастные различия также выражены умеренно: среди ученых до 44 лет ИИ используют около 90% респондентов, в группах <nobr>45–69</nobr> лет — <nobr>83–86%,</nobr> среди ученых 70 лет и старше — 71%. При этом молодые исследователи заметно чаще обращаются к ИИ для генерации и доработки кода, а представители старших возрастных групп — для перевода текстов и подготовки презентаций;</li> <li>генеративные ИИ-сервисы востребованы практически на всех этапах научной работы: не менее пятой части опрошенных их применяют для решения 16 из 19 исследовательских задач. Наиболее частыми сценариями использования ИИ стали поиск и отбор информации, работа с научной литературой и перевод текстов с русского на иностранные языки (каждую из этих задач с помощью ИИ решают более половины пользователей). Реже такие инструменты применяются для генерации и доработки кода, обобщения ненаучной информации и подготовки экспертных заключений.</li> </ul> Научные открытия по-прежнему делают люди, но значительную часть работы с растущими потоками данных все чаще выполняют … message https://www.itweek.ru/themes/detail.php?ID=235097 Wed, 01 Jul 2026 16:23:42 +0300 <p>На международной конференции по клиентскому сервису от CCGuru «Передовой опыт контактных центров — Excellence in Customer Contacts — 2026» эксперты BSS на кейсах показали, как устранить разрыв между данными и действиями, избежать бесконечных пилотов и сократить путь от проблемы до действия до одного дня. Компания также продемонстрировала ИИ-инструменты для управления клиентским опытом в действии.</p> <p>XVI конференции «Передовой опыт контактных центров — Excellence in Customer Contacts — 2026» собрала представителей крупнейших ИТ-компаний и руководителей контакт-центров из финансового сектора, телекома, розницы, логистики, государственного сектора и других отраслей. </p> <p>Компания BSS представила на мероприятии <nobr>CX-платформу</nobr> для управления клиентским опытом и выступила с экспертизой: эксперты поделились кейсами и организовали круглый стол для обсуждения актуальных вызовов отрасли.</p> <p>О главной дилемме клиентского обслуживания рассказал руководитель направления по развитию ИИ-продуктов компании BSS Михаил Воронин: «Большинство организаций умеют собирать данные о клиентах. Немногие умеют превращать эти данные в согласованные действия сотрудников и всей организации».</p> <p><nobr>CX-платформа</nobr> объединяет данные, аналитику и управленческие решения в единой среде — работа строится в несколько этапов:</p> <ol> <li>сбор сигналов клиентов: платформа фиксирует все, что происходит с клиентом или сотрудниками — темы обращений, поведенческие паттерны, отклонения KPI. То есть отвечает на вопрос: что происходит сейчас?</li> <li>ИИ-анализ: интеллектуальный модуль выявляет аномалии, определяет вероятные причины проблем и потребности клиентов. Появляется ответ на вопрос: что это значит для бизнеса и клиента?</li> <li>рекомендации: по результатам анализа система предлагает Next Best Action, которое может быть направлено и на развитие отношений с клиентом (например, персональные предложения), и на усиление сотрудника (например, подсказки или тренинги), и на развитие бизнеса (например, сигнал о необходимости автоматизировать процесс). Это уже ответ на вопрос: что делать?</li> <li>выполнение рекомендаций: например, если ИИ определил, что основной предиктор оттока — проблемы с информированием о статусе заказа, то предложенным решением может быть автоматизация через ИИ-агентов, которые будут самостоятельно проверять статусы заказов и отвечать клиенту. После внедрения изменений компания может оперативно оценить их результативность благодаря ИИ-модулю. Так можно быстро узнать: решена ли проблема?</li> </ol> <p>Как запускать пилотные проекты так, чтобы они переходили в промышленную эксплуатацию, рассказала ведущий аналитик по контактным центрам департамента голосовых технологий компании BSS Дарья Громова.</p> <p>Проблема традиционных пилотов в том, что они демонстрируют возможности инструмента, но не отвечают на главный вопрос бизнеса: какой результат он принесет компании. В них не тестируют показатели, на базе которых считают ROI — в итоге заказчику сложно принять решение о масштабировании, а внедрение откладывается на неопределенный срок.</p> <p>«Альтернатива — пилот с фиксированным KPI, где главным критерием успеха становится конкретный бизнес-показатель, который должна улучшить система. Например, в пилоте речевой аналитики с МТБ была поставлена цель за три месяца снизить AHT на 3%. В результате показатель удалось сократить на 8%», — рассказала Дарья Громова.</p> <p>Как ИИ-модуль в речевой аналитике позволяет бизнесу адаптироваться к постоянным изменениям рынка и проверять гипотезы за нескольких дней рассказала владелец продукта «Речевая аналитика» компании BSS Анна Ивлева.</p> <p>До недавних пор на проверку гипотез уходили недели: нужно было собрать данные, подготовить отчет, провести обсуждение и только потом запускать проект. Сегодня важным показателем зрелости компании становится скорость верификации идей — то, насколько быстро она может превратить вопрос в действие и оценить результат.</p> <p>Благодаря ИИ цикл проверки гипотез может выглядеть так:</p> <ul> <li>1 час — собрать и проанализировать данные;</li> <li>4 часа — выявить причины проблемы;</li> <li>8 часов — принять решение;</li> <li><nobr>1–3</nobr> дня — проверить эффект изменений.</li> </ul> <p>Анна Ивлева привела пример из практики BSS: «После того, как мы выявили низкий CSI в одной службе доставки, ИИ-агенты нашли паттерны в клиентских диалогах и определили основные причины недовольства: отсутствие связи с курьером, неясные формулировки на сайте и недостаток вариантов доставки. На их основе они тут же предложили рекомендации: предоставить клиентам выбор временного интервала доставки, упростить тексты на сайте и запустить программу лояльности. В результате CSI вырос с 5,7 до 6,5 всего за две недели».</p> <p>Во второй день ИИ-эксперты BSS провели круглый стол «От концепции к действиям: как CX‑платформа меняет управление контактным центром здесь и сейчас», где вместе с коллегами из контакт-центров обсудили ожидания клиентов, новые KPI и главное — как сделать так, чтобы ценные инсайты не терялись по пути к тем, кто принимает решения.</p> <p>Компания BSS благодарит всех, кто пришел на выступления, участвовал в дискуссиях, подходил знакомиться с <nobr>CX-платформой</nobr> и входящими в нее решениями, делился опытом, задачами и взглядом на развитие клиентского сервиса. Только вместе можно сделать CX умнее, технологичнее и эффективнее!</p> На международной конференции по клиентскому сервису от CCGuru «Передовой опыт контактных центров — Excellence … message https://www.itweek.ru/themes/detail.php?ID=235096 Wed, 01 Jul 2026 12:45:14 +0300 <p>Polywell Computers представила UC300L2V4M3 — высокопроизводительный мини-ПК на платформе Intel Core Ultra Series 3 (Panther Lake). Система предназначена для периферийных ИИ-вычислений, многоэкранной визуализации, систем мониторинга и управления, интерактивных терминалов, инженерных рабочих мест и специализированных коммерческих приложений, которым требуются высокая вычислительная производительность, быстрое локальное хранилище, гибкие сетевые возможности и широкий набор интерфейсов в компактном корпусе.</p> <p>UC300L2V4M3 поддерживает широкий выбор процессоров Intel Core Ultra Series 3: от энергоэффективных Core Ultra 5 до высокопроизводительных Core Ultra X9. В зависимости от выбранного процессора система может оснащаться графикой Intel Arc B390/B370 либо Intel Graphics, что позволяет подобрать оптимальное соотношение вычислительной мощности, графической производительности и стоимости.</p> <p>Благодаря поддержке до четырёх дисплеев через HDMI 2.1, DisplayPort 1.4 и два порта Thunderbolt 4, UC300L2V4M3 хорошо подходит для инсталляций, которым нужны несколько экранов высокого разрешения, высокоскоростное подключение периферии и удобная установка в условиях ограниченного пространства.</p> <p>UC300L2V4M3 расширяет ассортимент мини-ПК Polywell системой, рассчитанной на современные задачи периферийных вычислений, мультимедиа и визуализации:</p> <ul> <li>процессоры Intel Core Ultra Series 3 на платформе Panther Lake;</li> <li>графика Intel Arc B390/B370 в отдельных конфигурациях;</li> <li>Intel Graphics в других вариантах процессоров;</li> <li>до 64 Гб памяти LPDDR5X-8533;</li> <li>поддержка до четырёх дисплеев;</li> <li>HDMI 2.1 и DisplayPort 1.4 с поддержкой разрешения до 8K при 60 Гц;</li> <li>Два порта Thunderbolt 4: передача данных до 40 Гбит/с, DisplayPort Alt Mode и выход Power Delivery до 15 Вт;</li> <li>три слота M.2 2280 для NVMe SSD: один PCIe 5.0×4 и два PCIe 4.0×4;</li> <li>стандартная конфигурация с двумя портами 2.5GbE LAN;</li> <li>опциональная конфигурация с одним портом 2.5GbE и одним портом 10GbE;</li> <li>слот M.2 Key-E 2230 для опционального модуля Wi-Fi 6E / Wi-Fi 7 и Bluetooth;</li> <li>опциональное расширение OCuLink;</li> <li>поддержка крепления VESA и настенного монтажа;</li> <li>компактный корпус размером 205 × 192 × 70 мм;</li> <li>создан для продвинутых проектов визуализации и периферийных вычислений.</li> </ul> <p>UC300L2V4M3 ориентирован на заказчиков, которым недостаточно обычного офисного мини-ПК. Сочетание процессоров Core Ultra, современной интегрированной графики, поддержки нескольких экранов, Thunderbolt 4, высокоскоростного NVMe-хранилища и опциональной сети 10GbE делает систему подходящей для проектов, где важны функциональная насыщенность и широкий набор интерфейсов.</p> <p>Для визуальных задач система может использовать до четырёх дисплеев через HDMI, DisplayPort и Thunderbolt 4. Это делает её хорошим выбором для цифровой рекламы, интерактивных экранов, рабочих мест мониторинга, видеостен, систем отображения показателей и коммерческих визуальных решений.</p> <p>Архитектура хранения также даёт интеграторам возможность создавать более производительные локальные системы. Один слот M.2 PCIe 5.0×4 и два слота M.2 PCIe 4.0×4 позволяют использовать быстрые накопители для медиаконтента, ИИ-моделей, локального сбора данных, аналитики и одновременной работы нескольких приложений.</p> <p>Для сетевых приложений стандартная конфигурация предлагает два порта 2.5GbE LAN. В проектах, где требуется более высокая пропускная способность проводной сети, доступна опция с одним портом 2.5GbE и одним портом 10GbE. Поддержка Wi-Fi 6E или Wi-Fi 7 доступна опционально и даёт дополнительную гибкость там, где прокладка кабеля затруднена или нежелательна.</p> <p>Фактическое число одновременно подключённых дисплеев и их максимальное разрешение зависят от выбранного процессора, конфигурации дисплеев, операционной системы и графического драйвера.</p> <p>UC300L2V4M3 — удачный выбор для заказчиков, которым нужны компактные системы с высокой производительностью, несколькими дисплеями, быстрым хранилищем и гибким набором интерфейсов:</p> <ul> <li>сстемы цифровой рекламы и мультимедийного воспроизведения с несколькими дисплеями;</li> <li>интерактивные киоски и терминалы самообслуживания;</li> <li>периферийные ИИ- и AIoT-приложения;</li> <li>коммерческие решения для визуализации и отображения данных;</li> <li>системы мониторинга, информационные панели и диспетчерские;</li> <li>видеостены и сети распространения информации;</li> <li>интеллектуальная розничная торговля, гостиничный бизнес, образование и корпоративная среда;</li> <li>сетевые коммерческие устройства;</li> <li>платформы для разработки, интеграции и демонстрации;</li> <li>высокопроизводительные компактные настольные системы.</li> </ul> Polywell Computers представила UC300L2V4M3 — высокопроизводительный мини-ПК на платформе Intel Core Ultra Series 3 … message https://www.itweek.ru/themes/detail.php?ID=235094 Wed, 01 Jul 2026 12:39:46 +0300 <p>Postgres Professional представила Postgres Pro Enterprise 18.4.1 — обновление флагманской коммерческой СУБД на базе PostgreSQL. Новый релиз расширяет возможности горизонтального масштабирования читающей нагрузки, развивает встроенные механизмы отказоустойчивости и добавляет инструменты для контроля целостности данных и администрирования.</p> <p>Postgres Pro Enterprise предназначена для крупных корпоративных систем, где важны высокая производительность, отказоустойчивость, безопасность и предсказуемая эксплуатация.</p> <p>«В Postgres Pro Enterprise 18.4.1 мы сделали акцент на задачах, которые сейчас особенно актуальны для крупных инфраструктур: более эффективном использовании серверного оборудования и обеспечении надёжности, включая геораспределённую катастрофоустойчивость. Работа с временными объектами на standby-серверах и новая функциональность Proxima позволяют активнее использовать резервные узлы, а новые возможности BiHA и инструменты администрирования делают эксплуатацию сложных систем более гибкой и устойчивой», — отметил Василий Чепцов, Директор департамента разработки продуктов.</p> <p>Ключевым изменением версии 18.4.1 стала возможность полноценной работы с временными объектами на резервных серверах. Теперь на репликах поддерживаются операции чтения и записи для временных таблиц, последовательностей и представлений, а также создание и вызов временных функций. Это позволяет расширять сценарии горизонтального масштабирования без создания отдельных копий баз данных, например, для генерации сложных отчётов на standby-серверах, в том числе, для систем 1С.</p> <p>Развитие получило расширение Proxima, объединяющее функциональность прокси-сервера, балансировщика нагрузки и пула соединений:</p> <ul> <li>добавлены адаптивные алгоритмы распределения запросов к репликам с учётом потребления памяти и интенсивности дискового ввода-вывода;</li> <li>реализована возможность размещения Proxima на лёгковесном узле‑рефери кластера BiHA.</li> </ul> <p>В расширении BiHA (Built-in High Availability), для построения геораспределенных кластеров реализован новый механизм многоуровневой катастрофоустойчивости, позволяющий объединить узлы в логические сегменты, которые можно расположить в разных ЦОДах. Между сегментами используется каскадная репликация с автоматическим перестроением репликации в случае сбоя любого из узлов.</p> <p>В версию 18.4.1 вошло расширение pgpro_iheap для ускорения последовательного сканирования таблиц, а модуль автоматического подбора планов AQO обновлён до версии 4.1: оптимизирована внутренняя структура хранилища данных и улучшены механизмы выделения разделяемой памяти, что снижает вероятность блокировок в высоконагруженных сессиях.</p> <p>Также получило существенное развитие расширение pgpro_gbtree для работы с глобальными индексами на секционированных таблицах. Теперь поддерживаются совместимость глобальных уникальных индексов с конструкцией ON CONFLICT, создание глобального индекса по столбцу, входящему в состав первичного ключа, операции создания и перестроения индексов с параметром CONCURRENTLY, возможность использовать автоочистку (AUTOVACUUM) для глобальных индексов, указывать ссылки из дочерних таблиц на глобальный индекс при помощи внешнего ключа и добавлены настройки планировщика, управляющие использованием глобальных индексов.</p> <p>Также оптимизирована работа с системными ресурсами на секционированных таблицах: реализовано кеширование дескрипторов файлов для каталогов в директории PGDATA, что снижает нагрузку на процессор при планировании SQL-запросов. </p> <p>В состав Postgres Pro Enterprise 18.4.1 вошли новые инструменты для администраторов: pgpro_logical_slot для управления слотами логической репликации, pgpro_temp_stats для сбора статистики по временным таблицам и pgpro_validate для проверки физической и логической целостности данных экземпляра СУБД.</p> <p>Postgres Pro Enterprise 18.4.1 уже доступна пользователям. Подробные инструкции по установке обновления и миграции данных представлены в официальной документации к выпуску.</p> Postgres Professional представила Postgres Pro Enterprise 18.4.1 — обновление флагманской коммерческой СУБД … message https://www.itweek.ru/themes/detail.php?ID=235093 Wed, 01 Jul 2026 12:37:51 +0300 <p>DатаРу представила новое поколение корпоративных СХД. Обновленная линейка включает три продукта: «ДатаРу ПС1500», «ДатаРу ПС5500» и «ДатаРу ПС9500». В серии «Элит» усовершенствована архитектура СХД: используются современные низкопрофильные твердотельные накопители форм-фактора E3, а также средства интеллектуального управления. Предусмотрен плановый рост производительности систем в три этапа до 2036 года.</p> <p>Новое поколение СХД от DатаРу отличается высокой плотностью хранения, масштабируемостью и возможностью модернизации систем без остановки сервисов и миграции данных. Для этого полностью пересмотрена архитектура СХД. </p> <p>Системы «ДатаРу ПС1500», «ДатаРу ПС5500» и «ДатаРу ПС9500» построены на процессорах Intel с аппаратным ускорением QuickAssist Technology. Сетевой периметр выполнен по стандарту OCP 3.0 с возможностью замены модулей прямо во время работы системы, без отключения питания и использования инструментов. </p> <p>СХД поддерживают высокоскоростную технологию передачи данных Fibre Channel до 64 Гбит/с с возможностью расширения до 128 Гбит/с. Также СХД поддерживает Ethernet-подключения со скоростью портов 10/25/100 Гбит/с в зависимости от конфигурации и с резервом для роста до 200/400 Гбит/с.</p> <p>Одно из ключевых изменений в сравнении с предыдущим поколением СХД — переход на низкопрофильные твердотельные накопители форм-фактора E3. Использование современных SSD позволило увеличить плотность хранения в два раза и размещать до 40 накопителей в 3U. </p> <p>Предусмотрено до 40 портов на одно устройство — в среднем на 60% больше, чем у аналогов на рынке. Это дает значительный запас для роста трафика. При этом в архитектуре не используются выделенные служебные модули NVRAM — все слоты задействованы под накопители с данными. Эффективная емкость каждого устройства с учетом технологий экономии пространства достигает 5,8 петабайт. </p> <p>Кроме того, производитель берет на себя гарантию коэффициента сжатия данных 6:1. То есть на каждый 1 ТБ физически занятого пространства система в среднем может разместить около 6 ТБ пользовательских данных за счет механизмов сжатия и дедупликации. Такой подход, как рассчитывает вендор, позволит заказчикам точнее планировать развитие инфраструктуры и сократить избыточные затраты на расширение хранилищ.</p> <p>Отдельное внимание в новой линейке уделено автоматизации. Среди доступных возможностей — автоматическое развертывание NVMe/TCP через SmartFabric, проактивное выделение ресурсов и встроенные механизмы защиты от киберугроз. Опционально доступен модуль Cyber Detect на базе AI и аналитики, который проверяет целостность данных и помогает быстрее восстановиться после атаки. Все это заметно сокращает трудозатраты ИТ-отдела на администрирование СХД и повышает надежность хранения.</p> <p>Для защиты инвестиций заказчиков предусмотрена программа Lifecycle Extension. Она предполагает обновление вычислительной части без замены корпуса и дисковой подсистемы. Обновление контроллеров может выполняться без остановки сервисов или необходимости переноса данных на другое хранилище. В компании подчеркивают, что платформа рассчитана на три плановых повышения производительности до 2036 г.</p> <p>Упрощен и переход с ранее установленных решений. Для заказчиков, использующих СХД DатаРу предыдущих поколений, предусмотрено автоматическое добавление новой системы в кластер без перенастройки хостов. Также заявлена возможность объединения массивов Gen 1, Gen 2 и Gen 3 в единой среде с перераспределением текущих нагрузок между узлами. Ранее внедренные системы могут использоваться в качестве узлов репликации или дополнительных хранилищ. При этом все три поколения СХД работают под управлением единой программной платформы DатаРу, что должно упростить администрирование и перенос нагрузок между устройствами</p> <p>«При выпуске нового поколения СХД мы ставили перед собой задачу переосмыслить экономику хранения данных для российского бизнеса. Для нас было важно, чтобы заказчик получал современную с технологической точки зрения систему и одновременно — понятную модель развития инфраструктуры. Поэтому мы сосредоточились на повышении производительности СХД, более эффективном управлении нагрузками и возможности поэтапной модернизации без остановки критически важных сервисов», — прокомментировал Роман Гоц, генеральный директор ГК DатаРу. </p> DатаРу представила новое поколение корпоративных СХД. Обновленная линейка включает три продукта: «ДатаРу ПС1500», «ДатаРу ПС5500» … message https://www.itweek.ru/themes/detail.php?ID=235091 Wed, 01 Jul 2026 12:33:45 +0300 <p>Российский разработчик ПО СберТех объявил о выводе на рынок векторной системы управления базами данных (СУБД) Platform V Vector DB. Решение ориентировано на промышленное применение в корпоративных сценариях искусственного интеллекта. Оно дает возможность бизнесу работать с векторными представлениями информации и на их основе запускать надежные прикладные сервисы: семантический поиск и интеллектуальных помощников. Новая СУБД поможет компаниям обрабатывать сложные клиентские запросы, оптимизировать нагрузку на сотрудников и повышать эффективность бизнес-процессов.</p> <p>Platform V Vector DB создана для крупных предприятий, которым необходимо управлять большими объемами данных. Решение подходит финансовым, телекоммуникационным, логистическим организациям, ритейлерам и государственным структурам, где важны производительность и эксплуатационная зрелость программных продуктов. СУБД располагает инструментами для контроля безопасности и работоспособности, упрощенной интеграции в корпоративную инфраструктуру и предсказуемого сопровождения.</p> <p>Максим Тятюшев, генеральный директор СберТеха, отметил: «Мы разработали векторную СУБД, сочетающую в себе функциональность, надежность и управляемость, с фокусом на эксплуатации в высоконагруженных системах. Platform V Vector DB позволит бизнесу эффективно внедрять семантический поиск и ИИ-агентов для различных корпоративных сценариев: точного поиска по документам и базам знаний, быстрого реагирования на инциденты, детальной проработки клиентских обращений. Это поможет компаниям снизить эксплуатационные и инфраструктурные риски, усилить контроль безопасности, а также сократить путь от пилотного проекта до полноценного внедрения».</p> <p>Platform V Vector DB поставляется отдельным дистрибутивом для установки на серверах клиента, что актуально для компаний с высокими требованиями к безопасности и проверяемости программного обеспечения. Ранее Сбер представил руководство по AI-трансформации разработки и бизнеса в новой технологической реальности. Оно поможет переформатировать работу компаний в парадигме, где ИИ является базой, а не надстройкой.</p> Российский разработчик ПО СберТех объявил о выводе на рынок векторной системы управления базами данных (СУБД … message https://www.itweek.ru/themes/detail.php?ID=235090 Wed, 01 Jul 2026 10:18:20 +0300 <p><em>Исследование </em><em>GitLab</em><em> «</em><em>The</em> <em>2026 </em><em>AI</em> <em>Accountability</em> <em>Report</em><em>» показывает, почему для ускорения разработки ПО с использованием искусственного интеллекта необходим контроль инфраструктуры и надежное управление для смягчения растущего технического долга, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Манав Хурана, директор по продуктам и маркетингу компании GitLab.</em></p> <p>В течение последних двух лет в дискуссиях о разработке ПО с использованием ИИ доминировала скорость. Новый опрос GitLab, проведенный среди 1528 разработчиков и технологических лидеров, показал, что у 60% респондентов рентабельность инвестиций в ИИ-кодирование уже превзошла ожидания, а 78% сообщают, что их команды пишут и фиксируют код быстрее после внедрения инструментов ИИ.</p> <p>Но скорость без контроля — это проблема.</p> <p>Большинство организаций внедряют агентную инженерию, добавляя инструменты ИИ-кодирования поверх своей существующей инфраструктуры. Агенты кодирования обеспечивают скорость, но эта скорость не распространяется на весь жизненный цикл ПО: только 21% респондентов сообщают о повышении производительности за пределами самой генерации кода.</p> <p>Проблема инфраструктуры гораздо глубже. Бэкенды, наборы инструментов и системы управления Git были созданы для параллельной обработки данных в масштабах, сопоставимых с человеческими. Агенты же работают в масштабах машин, и это несоответствие проявляется быстро. Надежность платформы снижается, когда миллионы агентных сессий обращаются к одному и тому же бэкенду, риски безопасности возрастают, поскольку агенты затрагивают зависимости в больших масштабах, а перерасход средств увеличивается, поскольку агенты неэффективно используют токены на инфраструктуре, которая не была создана для них.</p> <h3>Внедрение агентов опередило управление ими</h3> <p>Кривая внедрения инструментов ИИ-кодирования опередила разработку необходимых мер защиты: 80% организаций заявили, что внедрили инструменты ИИ быстрее, чем разработали политики управления ими, а 82% сообщили, что сгенерированный ИИ код рискует создать новую форму технического долга, с которым их организации не готовы справиться.</p> <p>На практике это означает проблемы с надежностью платформы при агентных нагрузках, риски безопасности и соответствия нормативным требованиям, которые возрастают, поскольку агенты в больших объемах затрагивают зависимости, и работу агентов с искусственной уверенностью из-за отсутствия полного контекста. Только 28% организаций заявили, что их инструменты управления жизненным циклом разработки ПО полностью интегрированы с общими данными и рабочими процессами, а это значит, что большинство команд пытаются управлять действиями агентов с помощью цепочек инструментов, которые никогда не были для них предназначены.</p> <h3>Для агентной инженерии необходима агентная инфраструктура</h3> <p>Агентная инженерия требует двух вещей: агентного кодирования и агентной инфраструктуры. У большинства организаций есть первое, но отсутствует второе.</p> <p>Агентная инфраструктура охватывает четыре области: уровень выполнения, уровень контекста, уровень управления и уровень оркестрации, работающие вместе.</p> <ol> <li><strong> Выполнение в машинном масштабе.</strong> Бэкенды, конвейеры CI/CD и системы развертывания Git были разработаны для разработки в темпе человека. В эпоху агентов они должны обрабатывать миллионы сеансов агентов без сбоев. Когда происходит инцидент в производственной среде, путь от симптома до источника должен занимать минуты, а не дни.</li> <li><strong> Контекст, который передается вместе с кодом.</strong> «Эффективность агента зависит от контекста и семантики, которые ему предоставляются», — отметил Бастиан Стамер, руководитель подразделения разработки ПО для автомобилей в Mercedes-Benz, на одной из недавних панельных дискуссий. Граф контекста, связывающий код, рабочие элементы, конвейеры, результаты проверки безопасности и производственные сигналы, делает агентов действительно полезными в масштабе и позволяет держать искусственную уверенность под контролем.</li> <li><strong> Управление, встроенное в поток.</strong> Действия агента должны быть привязаны к идентификатору, регистрироваться в соответствии с политикой и быть доказуемыми для проверяющего. Изменения с низким риском выполняются быстро, в то время как изменения с более высоким риском инициируют проверку. Наример, для Mercedes, работающей в соответствии с автомобильными нормативными стандартами, требующими полной отслеживаемости и ответственности человека, необходима плоскость управления, где эта ответственность и находится.</li> <li><strong> Оркестрация.</strong> Эффективность выполнения, контекста и управления зависит от системы, которая их координирует. Уровень оркестрации координирует действия агентов на протяжении всего жизненного цикла ПО в соответствии с политиками, установленными командами, определяя, какие агенты и в каком порядке запускаются и как обрабатываются сбои и передачи задач. Без него агентная инфраструктура представляет собой набор независимых возможностей, а не работающую систему.</li> </ol> <h3>Что дальше?</h3> <p>Согласно мнению 85% респондентов, следующий этап развития ИИ в разработке ПО будет меньше фокусироваться на генерации кода и больше на его управлении. Этот сдвиг отражает то, как предприятия совершенствуют свое мышление об ИИ, превращая его из инструмента повышения производительности в базовую возможность, которой необходимо доверять, отслеживать и поддерживать в масштабе.</p> <p>Когда управление встроено в платформу, скорость и контроль больше не находятся в противоречии. Отслеживаемость становится конкурентным преимуществом. Контекст становится институциональной памятью. А кодовая база, вместо того чтобы накапливать невидимый риск, становится активом, который со временем становится более надежным.</p> Исследование GitLab «The 2026 AI Accountability Report» показывает, почему для ускорения разработки ПО … article https://www.itweek.ru/themes/detail.php?ID=235089 Wed, 01 Jul 2026 10:16:33 +0300 <p><em>Нечеткие идентификаторы тормозят работу агентов искусственного интеллекта на этапах проверки безопасности. Джексон Коннелл, старший менеджер по маркетингу продуктов IBM, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о четырех решениях, которые необходимо принять для обеспечения безопасности агентных систем на уровне платформы.</em></p> <p>Многие агентные проекты могут успешно пройти этап разработки. Затем они попадают на этап проверки безопасности — и именно здесь все может остановиться. Нечеткие модели идентификации и слишком широкие разрешения быстро становятся препятствием.</p> <p>Вы, вероятно, видели это: агент службы поддержки клиентов работает хорошо; он обрабатывает заявки и возвраты средств, обеспечивает без сбоев весь рабочий процесс. Затем служба безопасности задает простой вопрос: под чьим идентификатором это работает? Ответ останавливает процесс: это общая учетная запись с широкими разрешениями, без четкого владельца, без журнала аудита и без контроля минимальных привилегий.</p> <p>Коренная проблема несложная. Это неопределенная идентификация и плохо определенные разрешения. И эта проблема быстро усугубляется. <a href="https://www-api.ibm.com/adobe/assets/urn:aaid:aem:65c0601b-d998-408d-bb69-4dfb31ff4642/original/as/2026-tech-leader-study-redefining-the-tech-leader-s-mandate-report.pdf">Исследование</a> «Tech Leader Study 2026», проведенное Oxford Economics и IBM, показывает, что опрошенные предприятия планируют развернуть в среднем 1661 ИИ-агента, что на 38% больше, чем сегодня. Каждый новый агент добавляет еще одну идентификацию, которую необходимо защитить, и без четких ограничений проблема быстро усугубляется.</p> <p>В результате многие агентные системы фокусируются на том, что агенты могут делать, не определяя, что они должны делать и под чьим руководством. Агенты также не обладают фиксированным набором разрешений. Они запрашивают доступ, вызывают новые инструменты и принимают на себя роли в процессе работы, поэтому пути доступа усложняются способами, которые никто явно не предоставлял и не проверял. Без проверяемой идентификации отсутствует подотчетность, что затрудняет обеспечение минимальных привилегий, отслеживаемость и реагирование на инциденты.</p> <p>Для решения этих проблем разработчики, архитекторы и DevOps-инженеры, создающих агентные системы, а также ИТ-руководители, ответственные за их утверждение, могут воспользоваться следующим руководством.</p> <h3>Четыре решения по идентификации, которые требуются каждой агентной системе</h3> <p>Решения по идентификации нельзя рассматривать как второстепенный вопрос. Идентификация определяет, как агенты проходят аутентификацию, к чему они имеют доступ и как их действия контролируются и проверяются с течением времени. Если допустить ошибку на раннем этапе, вы будете строить на шатком фундаменте.</p> <p>Вот четыре наиболее важных выбора, которые необходимо сделать:</p> <p><strong>Идентификация рабочей нагрузки </strong><strong>vs</strong><strong>. общие учетные записи служб.</strong> Общие учетные записи служб просты в использовании, и именно это делает их опасными. Когда несколько агентов действуют под одной учетной записью, становится трудно определить, что произошло и что пошло не так после этого. Если учетная запись будет скомпрометирована или использована не по назначению, все, чего она касалась, будет раскрыто.</p> <p>Идентификация рабочей нагрузки назначает каждому агенту свою собственную идентификацию. Разрешения остаются ограниченными, а действия можно атрибутивировать. Это требует большей настройки, но создает изоляцию и возможность аудита.</p> <p><strong>Статические ключи API </strong><strong>vs</strong><strong>. краткосрочные учетные данные. </strong>Статические ключи API, как правило, остаются навсегда. Они жестко закодированы в приложениях, передаются между системами и редко меняются — это делает их постоянной уязвимостью, ожидающей эксплуатации.</p> <p>Краткосрочные учетные данные работают иначе. Они выдаются по запросу, привязаны к конкретной задаче и автоматически истекают. На практике это часто основано на федерации идентификации (например, с использованием токенов OIDC) в сочетании с системами, которые могут выдавать динамические учетные данные во время выполнения, а не хранить долговременные секреты в коде или конфигурации.</p> <p><strong>Прямая передача учетных данных </strong><strong>vs</strong><strong>. доступ через брокера. </strong>Передача учетных данных непосредственно агенту проста. Она также непрозрачна. У вас нет естественной точки для оценки политики или понимания того, что происходит в реальном времени.</p> <p>Доступ через брокера вводит в поток контрольную точку. Запросы проходят через брокера, политики оцениваются в реальном времени, и для каждой сессии выдаются временные учетные данные. Это добавляет инфраструктуру, но восстанавливает прозрачность и обеспечение соблюдения политик.</p> <p><strong>Фрагментированное логирование </strong><strong>vs</strong><strong>. полная история идентификации.</strong> Большинство систем регистрируют то, что произошло. Гораздо меньше систем фиксируют, кто инициировал действие или как оно распространялось по цепочке агентов и служб.</p> <p>Полная история идентификации связывает каждый шаг. Вы можете отслеживать операцию от триггеров до результатов, что может ускорить отладку и обеспечить более надежное реагирование на инциденты. Однако загвоздка в том, что это требует последовательного распространения идентификационных данных и структурированного логирования с самого начала — это сложно внедрить позже.</p> <h3>Когда компромиссы становятся реальными рисками</h3> <p>Это не абстрактные архитектурные предпочтения. Они проявляются как конкретные уязвимости.</p> <p>Nightfall AI сообщает, что организации ежегодно раскрывают почти 350 секретов на 100 сотрудников, при этом 35% раскрытых ключей API все еще активны. В сочетании с постоянными учетными данными и общими идентификаторами потенциальный радиус атаки быстро растет.</p> <p>Закономерность остается неизменной: общие учетные записи и долгосрочные ключи быстрее создавать, но их сложнее защитить. Идентификация рабочей нагрузки и краткосрочные учетные данные требуют бóльших первоначальных инвестиций, но могут обеспечить бóльшую безопасность в долгосрочной перспективе.</p> <h3>Отладка нарушений на интуитивном уровне</h3> <p>Рассмотрим ситуацию, когда агент, работающий под общей учетной записью с долгосрочным ключом, внезапно резко увеличивает доступ к данным. Это ошибка? Нарушение? Обычное поведение? Сложно сказать. Отзыв ключа может решить проблему, но при этом может нарушить работу полудюжины несвязанных рабочих процессов. Так вы отлаживаете на интуитивном уровне.</p> <p>Быстрые пути уменьшают трение на начальном этапе и накапливают риски со временем.</p> <h3>Стандартизация идентификации на уровне платформы</h3> <p>Решение не в том, чтобы заново создавать аутентификацию, авторизацию и аудит для каждого выпускаемого агента. Это не масштабируемо.</p> <p>Вместо этого стандартизируйте идентификацию на уровне платформы — с помощью централизованных поставщиков идентификационных данных, механизмов управления политиками и брокера учетных данных, чтобы обеспечить безопасные настройки по умолчанию и упростить соблюдение нормативных требований, избавив от необходимости постоянно вести переговоры.</p> <p>Агентный ИИ работоспособен в производственной среде, если идентификация проектируется заранее и обеспечивается во время выполнения, а не предполагается на основе предыдущего входа в систему. Когда проекты рассматриваются как второстепенные, они застопориваются. Агенты могут действовать с тем уровнем контроля, который требуется в производственной среде, если это заложено намеренно.</p> Нечеткие идентификаторы тормозят работу агентов искусственного интеллекта на этапах проверки безопасности. Джексон Коннелл … article https://www.itweek.ru/themes/detail.php?ID=235088 Tue, 30 Jun 2026 16:06:10 +0300 <p>НКК Машиностроение объявляет о выходе релиза ПО САРУС+ 2026.2. Ключевое обновление помогает пользователям осуществлять плавный переход из систем зарубежных разработчиков в российский PLM-продукт. Для этого создан механизм совместной работы в САРУС+ CAD и Siemens NX, который дает возможность открывать и проводить изменения в электронном макете изделия. Бесшовная интеграция между PLM-системой и САРУС+ CAD выстроена как единое целое, пользователь не должен заботиться о том, где он начал работать и как будут синхронизированы данные: САРУС+ отследит изменения, где бы они не возникли, и, автоматически, без дополнительных действий пользователя, синхронизирует информацию между PLM и CAD.</p> <p>Главные возможности релиза:</p> <ul> <li>бесшовная двунаправленная интеграция PLM — CAD и совместная одновременная работа в САРУС+ CAD и Siemens NX облегчат переход с иностранных систем в российский продукт;</li> <li>импорт данных из сторонних PLM-систем (иностранных и российских) на основе PLMXML и CSV с сопоставлением типов, атрибутов и отношений позволит перенести «исторические» данные без потерь. Маппинг данных настраивается один раз и может быть использован многократно;</li> <li>управление электронной структурой изделия. Ревизионное конфигурирование на основе правил (с визуализацией геометрического представления изделия) и по применяемости (финальное изделие, серийный номер, дата), добавление компонентов с учётом правил вхождений — обеспечат гибкое и ясное определение состава узлов и агрегатов изделия, технологических данных, требований и любых других конфигурируемых структур;</li> <li>визуализация 3D-моделей и 2D-данных в веб-клиенте с измерениями, сечениями, 3D-пометками и кросс-подсветкой решит задачу удобного просмотра 2D- и 3D-документации;</li> <li>управление изменениями. Полная взаимосвязь извещений об изменении с изменяемыми и заменяемыми объектами, работа с применяемостью по датам или по изделиям, а также автоматический пересчёт планируемой применяемости — гарантируют полный контроль над изменениями;</li> <li>быстрое получение информации о связях. Навигатор связей поможет проследить прямые и обратные взаимосвязи между объектами, отфильтровать и выделить нужные, а также позволит редактировать эти данные прямо в дереве графа;</li> <li>инструменты для управления и расширения модели данных, а также визуального проектирования интерфейса САРУС+ обеспечат пользователю возможность удобно работать с разнородными данными в минимальном количестве окон;</li> <li>система как конструктор. Возможность кастомизации интерфейса, простые инструменты для формирования собственного интерфейса системы вплоть до каждого пользователя удовлетворят запрос на собственное удобство и эргономику рабочего пространства;</li> <li>система как платформа. Документированный API для собственной разработки функционала или модификации существующего отроют путь к расширению возможностей системы под потребности предприятия.</li> </ul> НКК Машиностроение объявляет о выходе релиза ПО САРУС+ 2026.2. Ключевое обновление помогает пользователям осуществлять … message https://www.itweek.ru/themes/detail.php?ID=235087 Tue, 30 Jun 2026 13:35:24 +0300 <p>Selectel, крупнейший независимый провайдер IT-инфраструктуры в России, объявил о запуске новой версии собственной серверной операционной системы SelectOS. В новой версии системы на пакетной базе Debian 13 c использованием ядра Linux 6.12.86 улучшен пользовательский опыт, полученный в ходе работы с предыдущими версиями продукта, и учтены требования для сертификации во ФСТЭК. Всё это обеспечивает более высокий уровень поддержки современного оборудования и драйверов.</p> <p>Ключевым преимуществом обновленной SelectOS 2.0 является сочетание актуальной технологической базы и удобной модели эксплуатации. Для команд, работающих в экосистеме Debian и Ubuntu, это позволяет развивать серверную инфраструктуру без сложных миграций на другие семейства дистрибутивов, сохраняя привычные подходы к управлению пакетами, обновлениям и администрированию. Такой подход снижает операционные риски, сокращает затраты на обучение специалистов и упрощает внедрение системы в существующие IТ-процессы. Отдельное внимание в SelectOS 2.0 уделено готовности к AI-нагрузкам: система протестирована на совместимость с драйверами ведущих производителей GPU и может использоваться как основа для инфраструктуры машинного обучения, работы с нейросетевыми моделями и сервисами генеративного AI.</p> <p>Важным аспектом новой версии является внедрение управляемой цепочки поставок: собственные репозитории с GPG-подписью обеспечивают контроль происхождения каждого пакета, а серверный фокус дистрибутива, исключающий лишние десктопные компоненты, существенно сокращает поверхность атаки за счет минимизации потенциально уязвимого кода. Для специалистов по информационной безопасности SelectOS 2.0 предлагает отдельный канал для security-обновлений и гарантирует прозрачность изменений, что критически важно для соблюдения корпоративных ИБ-политик и регуляторных норм. </p> <p>«Для бизнеса операционная система — это не просто технологическая база, а часть критической IТ-инфраструктуры, от которой зависят бесперебойная работа сервисов, информационная безопасность и скорость развития компании. SelectOS 2.0 позволяет обновлять серверный стек без прерывания привычных процессов эксплуатации: команды получают знакомую Debian-среду, вендорскую поддержку, прозрачное происхождение пакетов и управляемый цикл обновлений. Мы создали эту версию с учетом требований корпоративных клиентов, регуляторной среды и задач долгосрочного развития инфраструктуры. Для компаний это надежная российская альтернатива внешним дистрибутивам и технологическая основа, на которую можно опираться в ближайшие годы», — отметил Кирилл Дмитриев, директор департамента системного ПО Selectel.</p> <p>SelectOS доступна для работы в формате ISO для физических серверов и виртуальных машин, в QCOW2 для облачных сред, а также в контейнерных образах, что позволяет компаниям стандартизировать развертывание в различных контурах и упростить процессы аудита и поддержки. Операционная система входит в Реестр российского программного обеспечения и доступна на облачных и выделенных серверах Selectel, обеспечивая работу в полностью контролируемой инфраструктуре с поддержкой на всех уровнях.</p> Selectel, крупнейший независимый провайдер IT-инфраструктуры в России, объявил о запуске новой версии собственной … message https://www.itweek.ru/themes/detail.php?ID=235086 Tue, 30 Jun 2026 13:33:38 +0300 <p>Компания «Райтек ДТГ», разработчик APS-системы RaytecAPS, выпустила новую версию продукта 1.5. Обновление направлено на повышение удобства сотрудников отдела планирования, расширение инструментов анализа рассчитанного плана и контроля обеспеченности заказов.</p> <p>RaytecAPS — система для предприятий с дискретным и гибридным типами производства. Решение позволяет автоматически рассчитывать производственный план с учетом доступности оборудования, доступности материалов, учитывать технологические ограничения, графики ремонтов оборудования, персонал и другие факторы. Программный продукт внесен в реестр российского программного обеспечения и может использоваться как отечественная альтернатива зарубежным APS-решениям, таким, как Opcenter APS и DELMIA Ortems.</p> <p>В версии RaytecAPS 1.5 появились новые механизмы визуального контроля результатов расчета плана, в том числе отображаемых на диаграмме Ганта. Новые инструменты анализа помогают плановикам быстрее и удобнее оценить обеспеченность производственного плана, увидеть опаздывающие операции и ошибки в расписании, которые могли быть вызваны ручными корректировками плана. Для быстрой оценки обеспеченности клиентских заказов и заявок добавлены статусы их обеспечения, а также плановая дата производства. Сведения отображаются непосредственно в списке заявок, в том числе с использованием цветовой подстветки.</p> <p>Расширены функции инструментов контроля и корректировки производственных расписаний. В новой версии реализована цветовая схема для выявления ошибок на диаграмме Ганта и функция автоматического исправления нарушенных технологических последовательностей производства, которые могли появится в результате ручных корректировок плана. Для ручного редактирования плана добавлена возможность снимать с диаграммы часть операций до указанной операции или после нее. Это позволяет более гибко выстраивать планирование, в том числе отталкиваясь от «узкого места» производства. Также расширены возможности анализа причин неразмещения операций на диаграмме Ганта. </p> <p>В RaytecAPS версии 1.5 расширены возможности работы с календарными состояниями оборудования. Теперь длительность операции корректно рассчитывается не только по состояниям «работает» и «поломка», но и с календарными периодами, эффективность которых ниже 100%. Это позволяет построить план с учетом износа оборудования или учесть интервалы выхода на режим, после переналадки или технического обслуживания линии.</p> <p>Для демонстрационных сценариев и самостоятельного старта работы с системой реализована возможность создания заказов на производство с учетом незавершенного производства. Благодаря этому, можно более эффективно проводить моделирование работы в системе RaytecAPS, выполнять расчет потребности к производству при изменении клиентских заказов, спецификаций и фактического выполнения производственных заданий.</p> <p>«Базовая функциональность RaytecAPS уже закрывает ключевые задачи оперативного планирования, поэтому в версии 1.5 мы сосредоточились на повышении удобства работы с планом. Для производственных предприятий важно не просто получить план, а быстро понять, какие заказы обеспечены, где возникают отклонения, какие заказы не размещены и по каким причинам. Новые инструменты визуального контроля, анализа обеспеченности и корректировки диаграммы Ганта помогают плановикам быстрее принимать решения и эффективнее управлять производственным контуром», — прокомментировал Антон Власов, руководитель практики цифровизации производственных предприятий «Райтек ДТГ».</p> <p>В дальнейших планах развития RaytecAPS — повышение удобства работы с системой: расширение модуля проверки нормативно-справочной информации на наличие ошибок, а также развитие инструментов анализа производственного плана — от оперативного на ближайший период, до долгосрочного.</p> Компания «Райтек ДТГ», разработчик APS-системы RaytecAPS, выпустила новую версию продукта 1.5. Обновление направлено … message https://www.itweek.ru/themes/detail.php?ID=235084 Tue, 30 Jun 2026 09:16:49 +0300 <p>Ещё несколько лет назад вход в личный кабинет банка, маркетплейса или оператора связи выглядел предельно просто: ввёл номер телефона, получил СМС с кодом, подтвердил вход. Эта модель была настолько привычной, что о её альтернативах мало кто задумывался.</p> <p>Но в последний год-два российский рынок авторизации начал меняться заметно быстрее, чем раньше. И дело не только в безопасности — у СМС как у технологии появились вполне конкретные деньги и инфраструктурные проблемы, которые бизнес уже не может игнорировать.</p> <h3>СМС подорожали и стали менее предсказуемыми</h3> <p>Раньше стоимость одного СМС-кода была для бизнеса почти незаметной строчкой расходов. Сейчас всё иначе: по оценкам участников рынка, с 2022 года стоимость СМС-сообщений в России выросла более чем в два раза, а операторы всё активнее переводят клиентов с фиксированной оплаты на пакетные тарифы по объёму трафика. Для сервиса, который отправляет миллионы кодов подтверждения в месяц — а это типичная ситуация для банков, маркетплейсов и доставки — даже небольшое удорожание одного сообщения превращается в заметную статью бюджета.</p> <p>Есть и вторая проблема — техническая. С августа 2025 года в России заработали нормы, позволяющие абонентам отказаться от массовых рассылок и звонков от компаний. Идея понятная — защитить людей от спама и мошенников. Но на практике операторы связи, выполняя требования закона, начали фильтровать вообще весь автоматический трафик от организаций для тех, кто подал такой отказ — включая коды подтверждения для входа и подтверждения операций. Получается, что пользователь, который хотел избавиться от рекламных СМС, неожиданно для себя перестаёт получать и коды от своего банка. Для бизнеса это значит, что доставка одноразового пароля стала менее предсказуемой: код может прийти с задержкой, а может не прийти вообще.</p> <h3>Банки сами просят отказаться от обязательной привязки к СМС</h3> <p>Показательная история произошла вокруг законопроекта «Антифрод 2.0», который должен был обязать подтверждать онлайн-операции одновременно через СМС и государственный мессенджер Max. Банковское сообщество в лице Национального совета финансового рынка выступило против этой нормы. Аргумент был довольно прямым: завязка на один канал создаёт «единую точку отказа» для всей системы онлайн-операций, а сама мера не особо повышает защиту, потому что современное мошенничество чаще строится на социальной инженерии, а не на нехватке способов подтверждения. Банки предложили альтернативу — пуш-уведомления, одноразовые TOTP-коды и биометрию, назвав их более надёжными способами подтверждения, чем СМС.</p> <p>Это важный сигнал: о ненадёжности СМС как канала подтверждения сегодня говорят не теоретики кибербезопасности, а крупные финансовые организации, для которых технология должна защищать деньги клиентов. СМС-код можно перехватить через подмену сим-карты или социальную инженерию, тогда как пуш-уведомление привязано к конкретному устройству — украсть его сложнее.</p> <p>Поэтому крупные банки уже на практике предлагают клиентам бесплатные пуш-уведомления вместо платных СМС-информирований. И эта замена работает не только для уведомлений об операциях по карте, но всё чаще и для самой авторизации.</p> <h3>Что стоит за безопасным входом по биометрии</h3> <p>Когда сервис предлагает войти по отпечатку пальца или лицу без пароля и СМС, обычно за этим стоит стандарт ВебАус (Webauthn). Работает он не так, как может показаться на первый взгляд: отпечаток пальца или фото лица никуда не передаются и не хранятся на сервере банка или сервиса. При первой настройке устройство — смартфон или ноутбук — создаёт пару криптографических ключей. Открытый ключ отправляется на сервер, а закрытый остаётся внутри защищённого чипа самого устройства и никогда его не покидает.</p> <p>При каждом следующем входе сервер присылает на устройство случайный запрос, который нужно подписать закрытым ключом, а подтвердить, что устройство держите именно вы, нужно отпечатком, лицом или пин-кодом — без набора кода и без ожидания СМС. Есть и встроенная защита от фишинга: ключ привязан к конкретному домену сервиса, поэтому даже идеальная копия сайта банка не получит рабочую подпись — устройство просто откажется её создавать для чужого адреса. СМС-код в этом смысле куда уязвимее: это обычный текст, который можно перехватить при подмене сим-карты или выманить через социальную инженерию.</p> <h3>Что уже работает в России</h3> <p>Российские экосистемы уже несколько лет выстраивают собственную инфраструктуру авторизации, и результаты заметны.</p> <p>Сервис авторизации ВК (VK ID) к концу 2025 года довела долю беспарольных входов — через QR-код, автологин и биометрию — до 90% от всех авторизаций, с охватом порядка 50 миллионов пользователей. Сбер ID работает по похожему принципу единого профиля: внутри приложения вход всё чаще подтверждается отпечатком пальца или сканом лица, а не кодом из СМС. Яндекс объединил свой генератор одноразовых кодов «Яндекс Ключ» с центром управления аккаунтом в единое приложение Яндекс ID, где можно включить вход по лицу или отпечатку — без пароля и без СМС-кода. Похожим путём идёт и Газпром ID — единая платформа авторизации внутри экосистемы Газпрома. Здесь уже работает биометрический быстрый вход, построенный именно на ВебАус: пользователь подтверждает вход отпечатком или лицом, а пароль и СМС-код в этом сценарии вообще не участвуют — ровно тот механизм, что описан выше.</p> <p>Отдельный уровень — государственная инфраструктура. На портале Госуслуг подтверждённую учётную запись имеют уже больше 120 миллионов человек, а Единая биометрическая система (ЕБС) постепенно становится основой межбанковской идентификации: если вы один раз пришли в отделение банка, показали паспорт и сдали биометрию, в перспективе другие банки смогут заочно подтверждать, что вы — это вы, без участия СМС.</p> <h3>СМС не умрут, но перестанут быть главным способом входа</h3> <p>Из всего этого не следует, что СМС исчезнут как технология. Слишком много людей по-прежнему пользуются кнопочными телефонами или просто не хотят разбираться в новых способах входа, поэтому СМС ещё долго останутся резервным каналом — для восстановления доступа, для пользователей без смартфона, для разовых операций с высоким риском.</p> <p>Но их роль точно меняется. Рынок движется к модели, в которой основной вход подтверждается пуш-уведомлением, биометрией или доверенным устройством, а СМС становится тем самым «запасным выходом» — на случай, если основной способ недоступен. Для бизнеса это означает одновременно экономию на инфраструктуре и более устойчивую, предсказуемую авторизацию — то, чего пользователям порой не хватало в последние пару лет.</p> <p>#IMAGE_235085#</p> Ещё несколько лет назад вход в личный кабинет банка, маркетплейса или оператора связи выглядел предельно просто: ввёл номер … article Вадим Иванков, руководитель цифровых продуктов по авторизации и аутентификации пользователей ООО “Оператор Газпром ИД” https://www.itweek.ru/themes/detail.php?ID=235083 Tue, 30 Jun 2026 08:57:58 +0300 <p><em>Сегодня можно утверждать, что сегмент SaaS не умирает, а претерпевает кардинальную трансформацию, и что модель оплаты за рабочее место уходит в прошлое, пишет в корпоративном блоге Бо Люккегор, заместитель вице-президента </em><em>IDC</em> <em>по исследованиям ПО в Европе.</em></p> <p>Резкое падение рыночной капитализации поставщиков SaaS-решений за последние 9 месяцев, иногда называемое «SaaS-апокалипсисом», частично связано с тем, что инвесторы учитывают опасения, что SaaS-приложения скроются за слоем агентов искусственного интеллекта. Это сделает их невидимыми поставщиками функций («featureware»), а агенты возьмут на себя отношения с пользователями, рабочие процессы и, в конечном итоге, бюджеты.</p> <p>Ниже будет показано, что корпоративные покупатели теперь ожидают от своих поставщиков ПО предоставления агентов и того, что они будут выступать в качестве надежного источника данных и контекста для агентов, созданных на заказ и сторонними разработчиками. Это естественный следующий этап развития для поставщиков SaaS-решений, и он открывает привлекательные рыночные возможности.</p> <p>Чтобы избежать путаницы, приведу определения, связанные с ИИ, от IDC. ИИ-помощник ведёт диалог и работает как инструмент человека. ИИ-агент автономен, использует другие инструменты и переносит память и контекст между задачами. Агентный рабочий процесс — это бизнес-процесс, который агент выполняет от начала до конца с ограниченным участием человека.</p> <h3>Поставщики SaaS сталкиваются с двойной угрозой, отсюда и «SaaS-апокалипсис»</h3> <p>Первая угроза заключается в том, что организации просто будут писать собственный софт вместо того, чтобы покупать стандартные SaaS-приложения. Эта угроза спровоцировала резкое обесценивание акций поставщиков SaaS в феврале, когда Anthropic продемонстрировала возможности Code. Разговоры с CIO в крупных компаниях частично подтверждают эти опасения. Хотя они не планируют создавать основные приложения для бухгалтерского учёта или управления персоналом, они могут разрабатывать, а не покупать вспомогательные приложения в таких областях, как планирование, управление производительностью, управление компенсациями, планирование логистики и т. д. В областях применения, где требования клиентов сильно различаются и где юридическая сложность низка, организации постепенно переходят от покупки к собственной разработке.</p> <p>Вторая угроза заключается в том, что агентные наложения будут все чаще обрабатывать взаимодействие с пользователем, в то время как агенты ИИ будут получать доступ к приложениям SaaS через API для выполнения транзакций от имени пользователя. Это означает, что ключевые факторы, обосновывающие цену приложений SaaS, такие как интерфейс, широкий функционал и бренд, постепенно исчезнут из поля зрения пользователей. Это также означает, что ценообразование за рабочее место перестанет иметь смысл, когда люди перестанут быть основными пользователями приложений SaaS.</p> <h3>Внедрение агентов ИИ уже прошло переломный момент</h3> <p>Согласно апрельскому опросу IDC «Future Enterprise Resiliency and Spending», проведенном среди организаций с численностью сотрудников 500 и более человек, 74% респондентов уже внедрили как минимум одного агента, 15% проводили пилотные проекты, и только 1% сообщил, что не использует и не планирует использовать агентов ИИ. Те же респонденты ожидают, что количество типов агентов в эксплуатации примерно утроится с 24 в марте 2026 г. до 62 к 2027 г. Покупатели не оценивают целесообразность вступления в эру агентов. Они решают, какие части своей деятельности передать им в первую очередь, и операционные и основные бизнес-данные являются для них высшим приоритетом.</p> <p>Большой вопрос заключается в том, кто будет предоставлять этих агентов ИИ. Большинство организаций внедрили стандартные инструменты ИИ и провели пилотные проекты, но лишь немногие перепроектировали основные процессы для масштабного использования ИИ. Результаты опроса показывают, что большинство организаций используют готовые агенты везде, где это возможно, вместо того, чтобы создавать собственные.</p> <h3>Где выигрывают агенты, предоставляемые поставщиками</h3> <p>IDC выделяет четыре типа агентов в зависимости от того, кто их создает и как покупатель их получает. Агенты, встроенные в приложение, поставляются в комплекте с приложением, и покупатель просто их использует. Low-code/no-code-агенты настраиваются покупателем в визуальном конструкторе, предоставляемом поставщиком. Самостоятельные (standalone) агенты — это сторонние продукты, которые покупатель внедряет вместе с существующими приложениями. Агенты, созданные на заказ, собираются внутренними командами с использованием полностековых фреймворков оркестрации.</p> <p>Данные опроса, которые фокусируются на количестве агентов ИИ, а не на затратах, указывают направления роста. Два типа агентов, которые поставщики предлагают напрямую — встроенные в приложение и low-code/no-code-конструкторы — имеют наибольшую инсталлированную базу и растут быстрее всего. Агенты, разработанные на заказ, демонстрируют самый медленный рост, поскольку требуемая для них оркестрация сложнее и требует больше внутренних навыков для создания. Покупатели предпочитают внедрять или настраивать агента, который уже понимает их данные и соблюдает их права доступа, вместо того, чтобы создавать его с нуля.</p> <h3>Приложения SaaS как поставщики доверенных данных и контекста для заказных агентов</h3> <p>IDC также наблюдает широкий спрос на заказных агентов ИИ, особенно для основных бизнес-процессов, уникальных для отрасли или организации. Самостоятельные продукты и заказные агенты будут работать в рамках одного предприятия, и им потребуются данные и контекст, которые находятся внутри вашего приложения.</p> <p>Заказной или сторонний агент, получающий доступ к данным «откуда угодно», по-прежнему нуждается в месте, где данные корректны, процесс соответствует нормативным требованиям, права доступа соблюдаются, а выполнение транзакции гарантировано. Поставщик SaaS-решений может предложить проверенные бизнес-процессы, управляемые данные и журналы аудита для использования заказными ИИ-агентами. По мнению IDC, это ключевая роль для SaaS-приложений в будущем.</p> <h3>Как выглядит SaaS-приложение, ориентированное на ИИ</h3> <p>Интерфейс перестает быть одним экраном и становится несколькими режимами, обслуживающими одни и те же процессы: традиционный пользовательский интерфейс, диалоговый интерфейс, интерфейс рабочего процесса, встроенный туда, где пользователь уже работает, и машинные интерфейсы, позволяющие внешним агентам напрямую и безопасно вызывать приложение.</p> <p>Переход к ИИ требует от поставщиков SaaS полного переосмысления рабочего процесса, что затрагивает весь стек: базовые модели, слой вложений, векторную базу данных, генерацию с расширенными возможностями поиска, слой оркестрации, механизмы защиты, мониторинг и управление версиями. Поставщик также должен предоставить покупателям собственный набор агентных инструментов, чтобы low-code/no-code-конфигурирование, которое все чаще требуют покупатели, происходило внутри управляемой среды поставщика, а не за ее пределами.</p> <p>Что касается региональных особенностей, то европейские поставщики, например, предъявляют дополнительные требования, которые при правильном подходе становятся конкурентным преимуществом. Соответствие GDPR, NIS2 и Закону ЕС об ИИ, гарантии резидентности данных и суверенного облака, подлинная многоязычная производительность модели и прозрачность в том, как ИИ принимает решение, — все это условия продажи для европейских покупателей, чувствительных к вопросам комплаенса.</p> <p>SaaS не умер, и игроки рынка не обречены. Однако актив, оправдывающий существование поставщика, смещается от экрана, на который смотрит пользователь, к агентам, которые этот поставщик предоставляет, и управляемым данным, на которые полагаются эти и другие агенты. Ваши клиенты уже ожидают, что вы будете их поставщиком агентов. Вопрос лишь в том, опережаете ли вы этот тренд или реагируете на него.</p> Сегодня можно утверждать, что сегмент SaaS не умирает, а претерпевает кардинальную трансформацию, и что модель … article https://www.itweek.ru/themes/detail.php?ID=235082 Mon, 29 Jun 2026 14:20:45 +0300 <p>Российская компания «Атомик Софт», специализирующаяся на разработке ПО для автоматизации промышленных и гражданских объектов, представила новый компонент своей платформы SCADA — Alpha.SmartControl. Это решение ориентировано на предприятия, которым необходимы отдельные функции системы управления производственными процессами MES (Manufacturing Execution System, система управления производственными процессами), но внедрение полноценного MES-решения является избыточным или требует значительных финансовых и временных вложений.</p> <p>Alpha.SmartControl представляет собой модульный инструмент, позволяющий заказчикам выбирать только необходимые функции, избегая переплат за неиспользуемый функционал. Компонент собирает данные из разнородных систем предприятия: АСУ ТП, MES, ERP и СУБД. На основе собранной информации формируются аналитические дашборды, рассчитываются ключевые показатели эффективности производства, а также предоставляются инструменты для оперативного управления — от цифровых бланков переключений до расчета остаточного ресурса оборудования.</p> <p>Alpha.SmartControl предлагает широкий спектр сценариев использования: от стандартных отчетов по ходу технологического процесса до углубленной аналитики состояния оборудования. Система позволяет рассчитывать наработку оборудования с отображением графиков режимов работы и остаточного ресурса, а также вычислять коэффициенты использования и простоев. Для оперативного управления предусмотрено ведение цифровых бланков переключений с контролем шагов и сигнализацией. Кроме того, доступен план-факт-анализ для сопоставления плановых и фактических показателей, а также формирование суточных ведомостей с основными показателями предприятия, заметками персонала и сравнением задания с фактом.</p> <p>Ключевые преимущества</p> <ul> <li>консолидация данных из разнородных систем в едином пространстве;</li> <li>три режима формирования отчетов — по запросу, по расписанию или при выполнении заданных условий;</li> <li>единая система безопасности с ПО «Альфа платформа» — разграничение прав доступа, групп и ролей пользователей в соответствии с политиками предприятия;</li> <li>граничные вычисления (edge computing) — обработка данных на уровне технологических сетей, а не в корпоративной сети, что повышает оперативность и снижает нагрузку на инфраструктуру.</li> </ul> <p>«Промышленности мало просто отчетов. Нужна аналитика, на которую можно опереться при принятии решений. Alpha.SmartControl как раз для этого: мы собрали в одном месте сбор данных, расчет эффективности и удобные инструменты для персонала — от оператора до главного инженера. Пользователь получает реальную картину производства», — прокомментировал Денис Алексеев, менеджер продуктового маркетинга «Атомик Софт».</p> <p>«Атомик Софт» планирует расширять функциональность Alpha.SmartControl модулями для расчета материальных и энергетических балансов, а также инструментами описания модели предприятия с нормативно-справочной информацией для упрощения генерации новых шаблонов отчетов.</p> Российская компания «Атомик Софт», специализирующаяся на разработке ПО для автоматизации промышленных … message https://www.itweek.ru/themes/detail.php?ID=235080 Mon, 29 Jun 2026 14:18:39 +0300 <p>«Яндекс Браузер» для организаций научился автоматически реагировать на действия, которые могут свидетельствовать о кибератаке или утечке данных. Новый инструмент активной защиты от киберугроз может в режиме реального времени анализировать события в Браузере, автоматически ограничивать доступ к веб-ресурсам или сообщать об этом сотрудникам информационной безопасности в соответствии с политиками. Это позволяет обнаруживать потенциально небезопасные действия до того, как их заметят специалисты информационной безопасности (СИБ) и усилить таким образом защиту организаций от потенциальных киберугроз.</p> <p>При настройке Браузера для организаций ИТ-администраторы могут самостоятельно настроить события-триггеры — потенциально небезопасные действия. Например, если на устройстве сотрудника запустится программа для удалённого управления, Браузер для организаций автоматически заблокирует доступ к корпоративному веб-ресурсу и очистит браузерные данные, если это предусмотрено политиками безопасности. Также компании могут выбрать конкретную реакцию на триггер — например, Браузер для организаций автоматически заблокирует страницу для сотрудника и сообщит о возможном инциденте в СИБ.</p> <p>Кроме этого, теперь Браузер для организаций анализирует не только URL, который открывает сотрудник, но и IP-адрес, на котором расположен сайт. Если система обнаружит, что IP-адрес может быть связан с распространением вредоносного программного обеспечения или с другой подозрительной активностью, она заблокирует загрузку страницы и уведомит специалистов по информационной безопасности компании. Такой подход позволяет выявлять потенциально опасные ресурсы ещё до того, как они успеют повлиять на работу корпоративной инфраструктуры.</p> <p>Новые возможности доступны в расширенной версии «Яндекс Браузера» для организаций при наличии действующей лицензии. </p> «Яндекс Браузер» для организаций научился автоматически реагировать на действия, которые могут свидетельствовать … message https://www.itweek.ru/themes/detail.php?ID=235078 Mon, 29 Jun 2026 14:17:11 +0300 <p>Консалтинговая технологическая компания Axenix провела исследование влияния искусственного интеллекта на процессы разработки программного обеспечения и кадровую ситуацию в ИТ-сегменте. Эксперты пришли к выводу, что внедрение ИИ в полный цикл разработки ПО — от генерации кода до тестирования и сопровождения — удваивает продуктивность разработки, но ожидаемого эффекта в ускорении вывода продуктов на рынок не происходит. При этом использование ИИ меняет требования к командам и требует пересмотра кадровой стратегии компаний.</p> <p>Согласно данным StackOverflow, сегодня инструменты ИИ используют 84% разработчиков на мировом рынке, с его помощью создается более 40% программного кода, при этом его генерация ускоряется в <nobr>2-3 раза.</nobr> Автоматизируются также создание документации, тестирование и другие задачи. В результате опытный ИТ-специалист, использующий современные ИИ-инструменты, способен выполнять объем работы, который ранее распределялся между двумя или тремя junior-работниками. </p> <p>Средняя экономия при отказе от найма одного начинающего специалиста может достигать <nobr>1-1,5</nobr> годовых оклада без учета налоговых отчислений. Вполне логично, что компании и в России, и в других странах снижают набор молодых сотрудников.</p> <p>При этом исследование показало, что рост производительности отдельных этапов разработки не всегда приводит к сокращению сроков вывода продукта на рынок. «Бутылочным горлышком» становится верификация сгенерированного кода, написанного с помощью ИИ, так как senior-специалисты тратят на эту работу до 70% своего времени.</p> <p>По мнению экспертов Axenix, долгосрочный риск для отрасли формируется под влиянием двух основных факторов. Во-первых, обеспокоенность вызывает качество сгенерированного кода. Так, в исследовании говорится, что команды с активным использованием ИИ накапливают технический долг значительно быстрее, чем при традиционном подходе к разработке.</p> <p>В частности, за последние годы в несколько раз увеличился показатель churn rate — доля кода, который переписывается в течение короткого времени после создания. Высокий churn rate означает, что код принимается в систему, но вскоре оказывается некорректным или не соответствующим требованиям. Из-за этого его приходится перерабатывать. Т.е., речь идет не просто об увеличении объема переделок, которое могло бы объясняться ростом общего объема разработки, а именно об ухудшении качества нового кода. Во-вторых, из-за активного внедрения ИИ senior-специалисты все больше времени тратят на проверку и исправление сгенерированного кода, тогда как новых кадров для их замены становится меньше. </p> <p>Поскольку компании все активнее замещают junior-позиции ИИ-инструментами и нанимают меньше молодых специалистов, воронка профессионального роста сужается уже сейчас. Некому проходить путь от junior до middle и senior. Учитывая, что этот путь традиционно занимает <nobr>10-15 лет,</nobr> последствия проявятся не сразу. Но через годы рынок столкнется с острым дефицитом опытных специалистов, которые смогли бы отвечать за развитие сложных цифровых продуктов. По мнению экспертов Axenix, формируется риск разрыва «кадрового конвейера». Если в 2020 году junior-разработчики составляли около 40% кадровой структуры, то в 2026 году их доля снизилась до 30%.</p> <p>«С точки зрения бизнеса краткосрочная экономия выглядит убедительно. Однако такая стратегия создает риск дефицита квалифицированных кадров на рынке и роста стоимости высококлассных специалистов. Через десять лет при текущем темпе развития вайбкодинга сами инструменты разработки и ИИ могут кардинально измениться. И если отрасль перестанет системно выращивать специалистов, способных понимать технологии на глубоком уровне, есть риск, что сложные продукты постепенно превратятся в „черные ящики“. Понимание того, как системы устроены в целом и как ими управлять, начнет утрачиватьcя. ИИ способен существенно повысить эффективность работы, но не может заменить систему подготовки экспертов, которая формировалась десятилетиями», — прокомментировал Андрей Толстов, старший менеджер Axenix. </p> <p>Наиболее эффективной стратегией, по его словам, является сочетание ИИ-инструментов разработки и сохранения программ подготовки junior-специалистов. Таким образом, компании и сокращают издержки, и сохраняют преемственность кадров.</p> <p>Кроме того, исследование указывает на дополнительный источник кадров для технических и архитектурных ролей — через переобучение системных аналитиков. ИИ снижает технический барьер входа в архитектуру: с его помощью проще генерировать прототип, оценить производительность решения, разбираться в чужой кодовой базе. Аналитики с <nobr>5-7</nobr> годами опыта уже успешно переходят на позиции технических аналитиков и младших архитекторов.</p> Консалтинговая технологическая компания Axenix провела исследование влияния искусственного интеллекта на процессы разработки … message https://www.itweek.ru/themes/detail.php?ID=235077 Mon, 29 Jun 2026 14:15:57 +0300 <p>«Гармония» обновила систему Arenadata Harmony MDM (AD.MDM). Среди ключевых изменений — наследование признаков по иерархии классов, автоматическая генерация наименований по шаблонам и асинхронная выгрузка отчетов через реплику базы данных. Поиск теперь поддерживает транслитерацию, а пакет записей или весь справочник можно рассылать по нескольким клиентским системам одной командой. Обновление повышает скорость работы с данными, делая процессы более гибкими, коммуникации — быстрее, а контроль качества — глубже.</p> <p>Arenadata Harmony MDM — российская система enterprise-уровня для управления мастер-данными, разработанная компанией «Решения «Гармония» (входит в группу Arenadata). Она предназначена для централизации управления нормативно-справочной информацией, нормализации данных из разрозненных источников и обеспечения их качества даже в сложных ИТ-ландшафтах с большим количеством корпоративных систем. </p> <p>Обновление Arenadata Harmony MDM нацелено на повышение удобства работы в системе, ее производительности и скорости обработки данных. Ключевое новшество в версии 3.1.1 — механизм наследования атрибутов по иерархии классов, поддерживающий обязательное, частичное и переопределяемое наследование. Теперь при настройке классификаторов можно выбрать, как именно дочерний класс будет наследовать признаки родительского. Нововведение приближает систему к полноценному объектному моделированию данных — это минимизирует необходимость ручных настроек.</p> <p>Для упрощения рутинных операций в версии 3.1.1 добавлена генерация текстовых атрибутов по шаблонам. <nobr>MDM-специалист</nobr> может задать правила формирования полей — например, «Полное наименование» — на основе данных классификации без написания скриптов и привлечения разработчиков. </p> <p>Улучшен и поисковой механизм. Система распознает различные варианты написания одного и того же слова с учетом транслитерации: к примеру, «шкаф», «shkaf» или «skaf» будут идентифицированы как один объект. Это исключает как потерю информации, так и дублирование данных.</p> <p>Для ускорения процессов информацию теперь можно отправлять сразу по нескольким клиентским системам одной командой. Массовая рассылка данных во внешние системы экономит время пользователей и снижает вероятность ошибок при ручной обработке записей. Это особенно важно для компаний с развитой ИТ-инфраструктурой, где требуется синхронизация НСИ между множеством ИТ-решений.</p> <p>Наконец, в фокусе Arenadata Harmony MDM 3.1.1 — расширение возможностей для работы с отчетностью. Система поддерживает подключение кастомных отчетов, что позволяет компаниям расширять стандартную аналитику под свои потребности. А для работы с большими объемами данных внедрена асинхронная выгрузка: решение использует механизм очередей для балансировки запросов, не блокируя интерфейс. Пользователь получает уведомление о готовности файла и может просмотреть его на отдельной странице.</p> <p>Для тяжелых запросов используется реплика базы данных, чтобы не нагружать основную базу и не замедлять работу остальных пользователей — это крайне важно для крупных компаний. Механизм позволяет обеспечить стабильную работу MDM вне зависимости от сложности запросов и количества сотрудников, использующих систему. </p> <p>«Arenadata Harmony MDM 3.1.1 оптимально подходит для решения задач крупного бизнеса. Гибкость моделирования дает возможность быстро реагировать на изменения бизнеса и рыночных условий, а архитектура системы гарантирует производительность даже в самых сложных enterprise-контурах. Мы даем таким компаниям фундамент для построения data-driven культуры без технических ограничений», — отметил Евгений Обелов, технический директор Arenadata Harmony MDM. </p> <p>AD. MDM обладает открытой архитектурой для интеграции с корпоративным ИТ-ландшафтом и внешними источниками, такими как ЕФРСБ, ФИАС, ЕГРЮЛ, НРД. Кроме того, решение разработано по модели low-code, что делает его доступным для бизнес-пользователей, не имеющих продвинутых навыков программирования.</p> «Гармония» обновила систему Arenadata Harmony MDM (AD.MDM). Среди ключевых изменений — наследование признаков … message https://www.itweek.ru/themes/detail.php?ID=235075 Mon, 29 Jun 2026 09:14:48 +0300 <p><em>Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как операционный долг разрушает стратегии в области искусственного интеллекта, и предлагает четыре важнейших шага для построения долгосрочной операционной устойчивости.</em></p> <p>Давление, требующее быстрых действий, никогда не было таким сильным. Однако скорость без устойчивости — это обуза. По мере перехода ИИ от пилотных проектов к производству, он не просто увеличивает преимущества; он увеличивает количество точек отказа.</p> <p>Согласно опросу <a href="https://investor.pagerduty.com/news/news-details/2025/Three-Quarters-of-Companies-Now-Consider-AI-Essential-to-Operations-PagerDuty-Survey-Reveals/">PagerDuty «AI Resilience Survey</a>», 84% компаний уже столкнулись как минимум с одним сбоем, связанным с ИИ. Тем не менее, большинство по-прежнему справляются с этими сбоями с помощью процессов, разработанных для более медленной, ориентированной на человека эпохи. Финансовые риски делают это неприемлемым: в отчете PagerDuty «<a href="https://www.pagerduty.com/state-of-ai-first-operations/">2026 PagerDuty State of AI-First Operations</a>» говорится, что 68% организаций теряют более 300 тыс. долл. в час, когда системы выходят из строя. И по мере роста сложности ИИ радиус поражения каждого сбоя также увеличивается.</p> <p>В спешке внедрения новых инструментов и функций организации рискуют оказаться в уязвимом положении, когда их операционная инфраструктура не справляется. Успех ИИ-инициативы зависит от понимания того, где может накапливаться операционный долг. Первая проблема: признание того, что эти сбои обнаружить сложнее, чем ожидает большинство команд.</p> <h3>Почему сбои ИИ сложнее обнаружить</h3> <p>Большинство организаций знают, что что-то идет не так: фактически, 85% говорят, что им нужны более эффективные способы обнаружения сбоев в инструментах ИИ. Но осведомленность — это не действие.</p> <p>Сбои ИИ ведут себя не так, как традиционные инциденты. Модели дрейфуют. Агенты неправильно интерпретируют контекст. Первопричины сложнее отследить, а окно для локализации ущерба короче. Организации, которые по-прежнему рассматривают ИИ-инциденты как частные случаи, накапливают технический долг, который они не заложили в бюджет. Специальные процессы управления инцидентами, разработанные специально для режимов сбоев ИИ, больше не являются необязательными.</p> <p>Чтобы справиться с этим эффективно, сначала нужно знать, где скрывается долг.</p> <h3>Три типа операционного долга, замедляющего ваш прогресс</h3> <p><strong>1. Технический долг и долг автоматизации. </strong>Устаревшие инструменты, ручные операции, которые никогда не были автоматизированы, нестандартизированные процессы в разных командах — они накапливаются незаметно и быстро увеличиваются в размерах. Но именно здесь ИИ и приносит свои плоды. При правильном применении ИИ может анализировать рабочие процессы, выявлять возможности автоматизации и постепенно устранять рутинную работу, а не просто отмечать её.</p> <p>«Постепенно» — ключевое слово. Организации, получающие наиболее быструю отдачу, не внедряют ИИ сразу повсюду. Они начинают с хорошо понятных, повторяющихся задач, укрепляют уверенность и расширяются дальше.</p> <p>Но одной автоматизации недостаточно. Если лежащие в её основе системы не связаны, выгода остаётся локальной.</p> <p><strong>2. Долг интеграции. </strong>Это тихий множитель. Встройте инструменты ИИ в изолированные среды, и вы не сможете сопоставлять сигналы, обмениваться контекстом или действовать на основе полной картины. Без надлежащей интеграции между инструментами, сервисами и источниками данных даже лучшие инвестиции в ИИ не смогут масштабироваться или обеспечивать ожидаемую рентабельность инвестиций.</p> <p>Вместо того чтобы добавлять больше инструментов, попробуйте улучшить связи между ними. Серверы Model Context Protocol (MCP) стали практичным решением, предоставляющим агентам ИИ безопасный доступ в режиме реального времени к источникам данных без многомесячных проектов интеграции. Данные опроса подтверждают это: 54% организаций связывают повышение отказоустойчивости с инструментами, поддерживающими полный жизненный цикл инцидента, а 51% — с объединением нескольких инструментов в единую платформу.</p> <p>Тем не менее, улучшенная интеграция инструментов все равно не спасет вас, если не решен вопрос с человеческим фактором.</p> <p><strong>3. Долг партнерства человека и ИИ. </strong>Самые дорогостоящие ошибки ИИ — не технические, а организационные. Если команды не определили, какие решения должны приниматься машинами, а какие людьми, они либо чрезмерно автоматизируют процесс и теряют контроль, либо недостаточно автоматизируют и теряют ценность.</p> <p>Решить эту проблему помогает трехуровневая модель:</p> <ul> <li> Рутинные, хорошо понятные задачи могут быть полностью автоматизированы.</li> <li> Частично понятные задачи выигрывают от сотрудничества ИИ и человека, где ИИ занимается анализом и рекомендациями, но окончательное решение остается за людьми.</li> <li> Новые или сложные задачи требуют глубоких человеческих знаний, а ИИ играет лишь вспомогательную роль.</li> </ul> <p>Команды, которые могут четко определить эти границы, создают убедительное обоснование для более широких инвестиций в ИИ.</p> <h3>Четыре шага к повышению операционной устойчивости</h3> <p>Определение долга — это половина работы. Другая половина — это четкий план устранения проблем.</p> <ol> <li><strong>Создайте систему управления инцидентами, специфичную для ИИ.</strong> Четко определите ответственность и пути эскалации и разработайте инструкции специально для режимов отказа ИИ, а не занимайтесь адаптацией устаревших правил. Рассматривайте управление инцидентами как межфункциональную дисциплину, а не как второстепенную ИТ-задачу.</li> <li><strong> Определите операционные границы ИИ.</strong> Используйте трехуровневую модель, описанную выше, чтобы определить, какие задачи ИИ может безопасно автоматизировать, а какие требуют человеческого суждения. Это основа для более быстрых операций и устойчивой ценности ИИ.</li> <li><strong> Инвестируйте в мониторинг ИИ. </strong>Традиционные инструменты мониторинга не были созданы для выявления деградации моделей или непреднамеренных решений агентов. Специализированные LLMOps-решения могут обнаруживать эти предупреждающие знаки до того, как проблемы достигнут клиентов.</li> <li><strong> Внедрите непрерывное обучение в процесс.</strong> Каждый инцидент должен предоставлять обратную связь для руководств по устранению неполадок, правил автоматизации и логики эскалации. Именно так организации снижают риски с течением времени, а не просто реагируют на них.</li> </ol> <h3>Операционная устойчивость как конкурентное преимущество</h3> <p>По мере роста внедрения ИИ во все большее число критически важных процессов растет и стоимость сбоев. Поэтому вот что стоит сделать: перестаньте рассматривать устойчивость как средство минимизации ущерба и начните рассматривать ее как накапливающийся актив. Каждый устраненный инцидент становится оперативной аналитикой. Каждый выявленный шаблон становится основой для будущей автоматизации.</p> <p>Со временем это обеспечит не просто более быстрое восстановление: это основа автономных операций, где машины выполняют рутинные задачи, а люди сосредотачиваются на том, что действительно продвигает бизнес вперед. Организации, которые начинают заниматься этим раньше, первыми достигают цели.</p> Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале The New Stack о том … article https://www.itweek.ru/themes/detail.php?ID=235074 Fri, 26 Jun 2026 13:32:39 +0300 <p>Хостинг-провайдер SpaceWeb запустил Serverless — сервис автоматического деплоя приложений из GitHub и GitLab. Сервис создан для размещения приложений без управления серверной инфраструктурой. Пользователь подключает репозиторий GitHub или GitLab, выбирает проект и ветку, задает параметры сборки, после чего сервис автоматически собирает приложение и выдает ссылку на рабочую версию.</p> <p>Сервис закрывает один из самых частых барьеров при запуске веб-проектов: код уже готов, но его еще нужно развернуть, настроить окружение, домен, SSL/TLS-сертификат, переменные и процесс обновления. В сервисе эти шаги собраны в одном интерфейсе. Веб-мастерам доступна конфигурация с 2 CPU, 4 ГБ RAM и 2 ГБ SSD. Решение поддерживает проекты на Static HTML/CSS/JS, Python, Node.js, Next.js, Flask и FastAPI. </p> <p>«Рынок разработки ускоряется: команды хотят проверять гипотезы и выводить продукты в продакшен за часы, а не недели. Но на практике их тормозит не код, а сама инфраструктура. Наша цель — убрать этот барьер и сделать запуск приложений таким же простым, как работа с репозиторием. Serverless — это шаг к тому, чтобы любой разработчик мог сосредоточиться на продукте, а не на настройке окружения», — прокомментировал Егор Шилов, руководитель продуктового направления SpaceWeb. </p> <p>Serverless продолжает развитие линейки готовых решений SpaceWeb для разработки. Ранее в каталоге VPS появились инструменты для Python- и веб-разработки, командной работы, мониторинга, управления доступами и DevOps-задач. Новый сервис дополняет эти решения на этапе деплоя: если готовые образы помогают быстрее подготовить окружение, то Serverless позволяет быстрее опубликовать проект из репозитория и обновлять его без ручной настройки серверов. </p> Хостинг-провайдер SpaceWeb запустил Serverless — сервис автоматического деплоя приложений из GitHub и GitLab … message https://www.itweek.ru/themes/detail.php?ID=235073 Fri, 26 Jun 2026 13:30:58 +0300 <p>Компания «Перфоманс Лаб» представила новый выпуск Russia Quality Report 2026 — ежегодного аналитического обзора рынка тестирования и обеспечения качества в российских IT-компаниях.</p> <p>Ключевые выводы:</p> <ul> <li>QA становится управляемой функцией. 60% компаний называют свои процессы управляемыми, еще 31% — оптимизированными. При этом эффективность QA всё чаще оценивают через бизнес-показатели: 62% смотрят на инциденты в продуктовой среде, 39% — на удовлетворенность пользователей, 34% — на скорость вывода продукта на рынок;</li> <li>главный приоритет рынка — автоматизация. На ней сейчас фокусируются 67% компаний. Следом идут взаимодействие с разработкой и бизнесом (35%), внедрение ИИ в QA (31%), развитие метрик качества (25%) и подготовка специалистов QA (25%);</li> <li>интерес к ИИ высокий, но рынок пока осторожен. Только 15% компаний активно используют ИИ в продуктивных QA-процессах, 21% ведут пилотные проекты, 30% изучают сценарии применения. В сумме 36% рынка уже перешли от интереса к практическому движению. Самый популярный сценарий использования ИИ — генерация тест-кейсов из требований (52%);</li> <li>импортозамещение стало системным процессом. К концу 2025 года в реестре отечественного ПО более 29 тысяч продуктов и 10,8 тысячи вендоров. За три года сформировалась переходная модель, когда в одних сегментах отечественные решения закрепились, в других зависимость от зарубежного стека остается высокой. Наиболее заметный прогресс произошел в области систем управления тестированием;</li> <li>автоматизация воспринимается как базовая практика, но ее развитие упирается в зрелость инфраструктуры. 67% компаний считают ее фокусным направлением, но среди трудностей называют дефицит компетенций (37%), нестабильность тестовой среды (31%), интеграцию инструментов (23%) и качество тестовых данных (23%). Главный измеримый эффект автоматизации — сокращение времени выполнения регрессионного тестирования (68%);</li> <li>32% компаний уже отлавливают большинство потенциальных инцидентов с помощью мониторинга и алертинга. За три года доля компаний, где есть инструкции, но нет командной работы, сократилась с 17 до 3%, а доля тех, кто с трудом восстанавливает работу, — с 13,6 до 1,8%;</li> <li>прогнозы 2023 года сбылись неравномерно. Shift-Left вырос быстрее ожиданий — с 29 до 48% при прогнозе 42%. QAOps достиг 23% вместо ожидаемых 27%, а ИИ/ML в тестировании — 23% вместо прогнозных 38%. Главный будущий приоритет — ИИ в тестировании: его планируют развивать 43% компаний.</li> </ul> <p>«Новый выпуск готовился более полугода. Наша команда собрала и проанализировала ответы сотен специалистов из самых разных сфер бизнеса, провела глубинные интервью с руководителями и практиками из компаний-лидеров. Всё это позволило нам составить объективную картину того, как сегодня устроено тестирование в российских IT-организациях, куда направляются тренды и что мешает отрасли двигаться быстрее. Лейтмотив этого выпуска — искусственный интеллект как новая реальность QA. Мы наблюдаем, как <nobr>LLM-модели</nobr> и ИИ-инструменты превращаются в полноценную часть рабочих процессов тестировщиков. Среди самых востребованных инструментов — OpenAI ChatGPT/GPT-4.5, Claude, GigaChat, YandexGPT и opensource решения, такие как Qwen и Mistral. Важно при этом, что ИИ не вытесняет тестировщика — он меняет его роль, усиливает возможности и поднимает планку ожиданий от специалиста», — прокомментировал Александр Канатов, Руководитель бизнес-юнита «Функциональное тестирование» в «Перфоманс Лаб»</p> <p>Скачать Russia Quality Report 2026 можно на сайте компании «Перфоманс Лаб».</p> Компания «Перфоманс Лаб» представила новый выпуск Russia Quality Report 2026 — ежегодного аналитического обзора рынка … message https://www.itweek.ru/themes/detail.php?ID=235072 Fri, 26 Jun 2026 13:25:45 +0300 <p>Postgres Professional представила обновление платформы администрирования СУБД — Postgres Pro Enterprise Manager 2.7. Главным нововведением релиза стала интеграция AI-ассистента AskPostgres непосредственно в интерфейс платформы. При этом AI-ассистент, в отличие от других графических платформ управления БД на рынке, доступен к использованию и в триальной версии PPEM 2.7. Также в новой версии появился журнал истории изменений в кластере, мастер настройки WAL-архивирования и улучшения модуля истории активных сессий.</p> <p>Версия 2.7 развивает платформу как единое рабочее пространство для задач корпоративного DBA: администратор может быстрее получать экспертную поддержку, видеть историю изменений в инфраструктуре, настраивать критически важные процессы резервного копирования и анализировать производительность без переключения между разными инструментами.</p> <p>«В PPEM 2.7 мы сделали шаг к более интеллектуальному администрированию СУБД. AI-ассистент AskPostgres помогает администраторам быстрее находить ответы на вопросы по диагностике и оптимизации, а новые инструменты истории изменений, WAL-архивирования и анализа активных сеансов делают эксплуатацию Postgres Pro Enterprise более прозрачной и эффективной», — отметил Борис Пищик, руководитель продукта Postgres Pro Enterprise Manager.</p> <p>Главным нововведением версии 2.7 стала интеграция с AI-ассистентом AskPostgres. Теперь администраторы могут получать экспертные ответы на вопросы по администрированию, диагностике и оптимизации PostgreSQL непосредственно в интерфейсе PPEM, не переключаясь на документацию.</p> <p>Кнопка вызова ассистента добавлена в правый верхний угол панели управления. Ответы от языковой модели поступают в режиме реального времени: пользователь может остановить генерацию или продолжить диалог в рамках одной сессии с сохранением контекста.</p> <p>В PPEM 2.7 добавлен специальный журнал, отслеживающий изменения в кластере. Он фиксирует обнаружение нового кластера, добавление и удаление отдельных узлов, изменение роли, включая повышение до primary или понижение до реплики, а также смену статуса узла и общего состояния здоровья кластера.</p> <p>В платформе появился мастер настройки непрерывного WAL-архивирования на базе Postgres Pro Backup Enterprise (pg_probackup), что упрощает подготовку СУБД к восстановлению на момент времени (PITR). Теперь в интерфейсе можно настроить количество потоков, размер пакета, таймауты, алгоритмы и уровни сжатия. Статус настройки WAL-архивации выводится на странице «Экземпляр / Обзор».</p> <p>Инструмент диагностики производительности ASE (Active Session Engine), впервые представленный еще в предыдущей версии платформы, получил ряд доработок, направленных на повышение стабильности и удобства анализа исторических профилей ожиданий. Например, пользователи могут просматривать план выполнения конкретного запроса непосредственно из таблиц детализации ASE.</p> <p>Раздел «Учёт ресурсов» дополнился почасовой детализацией по каждому экземпляру. Кликнув по параметру «Общее потребление CPU» для нужного инстанса, администратор попадает на страницу с почасовой таблицей.</p> <p>В PPEM 2.7 также появилась возможность заменить рефери-узел в BiHA-кластере напрямую, без предварительного удаления. Это снижает количество ручных шагов в операционном процессе. Также проведён ряд улучшений на уровне платформы: оптимизированы алгоритмы выполнения операций и определения ролей во встроенных кластерах. Завершен перевод интерфейса на английский язык.</p> Postgres Professional представила обновление платформы администрирования СУБД — Postgres Pro Enterprise Manager 2.7 … message https://www.itweek.ru/themes/detail.php?ID=235071 Fri, 26 Jun 2026 09:12:11 +0300 <p><em>Данные реального времени — это и есть реальность. Это контекст, отражающий физическую и цифровую реальность того, что происходит в вашем бизнесе прямо сейчас. Именно этот контекст необходим агентам искусственного интеллекта для принятия точных решений и совершения соответствующих действий, влияющих на клиентов, операции, персонал и рынок, пишет в корпоративном блоге Майк Гуальтьери, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>В отличие от людей, агенты ИИ действуют со скоростью цифровых технологий. Неправильное решение или ошибочное действие одного агента очень быстро усугубляется каждым последующим агентом ИИ. Наступает хаос.</p> <h3>Чтобы избежать этого хаоса, эксперты призывают: «Даешь управление!»</h3> <p>Конечно. Стопроцентное управление ИИ абсолютно необходимо, чтобы гарантировать, что агенты ИИ работают должным образом и не причиняют вреда. Но также применим и универсальный закон вычислений: «Мусор на входе — мусор на выходе». Избегание мусорных данных, безусловно, связано с точностью и полнотой, но также и со своевременностью. В мире ИИ-агентов мы называем данные, необходимые ИИ-агентам, «контекстом» — а ИИ-агентам нужен безупречный контекст.</p> <h3>Решение: использование контекста реального времени с помощью платформы потоковой передачи данных</h3> <p>Современная платформа потоковой передачи данных специально предназначена для предоставления именно этого: своевременных, обогащенных и точных данных с цифровой скоростью. Она действует как нервная система вашего предприятия реального времени, непрерывно преобразуя эти данные в то, что могут использовать ИИ-агенты. Это достигается за счет поддержки трех различных рабочих нагрузок, объединенных в единой платформе:</p> <ul> <li><strong> Подключение и передача событий.</strong> Платформа потоковой передачи данных постоянно подключается ко всем источникам предприятия: приложениям, базам данных, датчикам, API и внешним системам. Она передает события в реальном времени практически без задержки, поэтому ИИ-агенты всегда имеют максимально актуальную информацию о бизнес-реальности. Например, платформа мгновенно передает событие отказа от покупки от ценного клиента непосредственно ИИ-агенту по удержанию клиентов, запуская персонализированное предложение еще до того, как клиент закроет вкладку.</li> <li><strong> Обработка и обогащение для получения контекста.</strong> Платформа потоковой обработки данных мгновенно обрабатывает и обогащает эти события на лету посредством преобразований, объединений и корреляций. Это превращает необработанные данные в богатую, контекстуализированную информацию, на которую могут полагаться агенты ИИ для принятия точных решений. Например, платформа обрабатывает международный платеж, объединяя его с историей местоположения клиента и его недавним поведением, а затем обогащает поток, чтобы агент ИИ по обнаружению мошенничества получал контекстуализированные данные и мог одобрить или заблокировать транзакцию за миллисекунды с меньшим количеством ложных срабатываний.</li> <li><strong> Анализ для обнаружения событий или временных закономерностей.</strong> Платформа непрерывно анализирует данные из различных источников для обнаружения значимых бизнес-событий, аномалий и сложных закономерностей событий, а затем агрегирует их в момент их возникновения. На крупном производственном предприятии платформа анализирует данные о температуре и вибрации с десятков датчиков в режиме реального времени, мгновенно обнаруживая закономерность и предоставляя агенту ИИ информацию для прогнозирования технического обслуживания до того, как отказ оборудования остановит линию.</li> </ul> <h3>Технологическим лидерам следует внедрить платформу потоковой передачи «контекста»</h3> <p>Технологические руководители должны выбрать правильную платформу потоковой передачи данных, поскольку она необходима для предоставления агентам ИИ контекста в реальном времени. Ищите платформы, которые обладают следующими характеристиками:</p> <ul> <li><strong> Унифицированные рабочие нагрузки.</strong> Платформа должна изначально интегрировать рабочие нагрузки подключения, обработки и анализа в одном механизме, чтобы агенты ИИ получали бесперебойный, безупречный контекст без переключений, разрозненности или задержек, которые могут ухудшить качество принимаемых решений. Технологические руководители должны искать платформу, которая нативно интегрирует обмен сообщениями, потоковую обработку и аналитику для предоставления агентам ИИ контекстуализированной информации в реальном времени.</li> <li><strong> Инструменты корпоративного уровня для разработки и операций.</strong> Агентам ИИ требуется контекст реального времени, обеспечивающий отказоустойчивость, наблюдаемость и управление производственного уровня. Встроенные инструменты разработки, мониторинг, безопасность и модели данных ускоряют развертывание. Технологические руководители должны искать инструменты, которые охватывают весь жизненный цикл разработки и обеспечивают безопасные, наблюдаемые и управляемые операции.</li> <li><strong> Концепция ткани реального времени для автономных агентов ИИ.</strong> Будущее принадлежит организациям, где агенты ИИ действуют автономно на основе потоков реальных, достоверных данных. Для этого необходима архитектурная основа, которая связывает каждую систему, решение и результат в режиме реального времени. Технологические руководители должны искать поставщика платформы потоковой передачи данных, который разделяет видение единой, работающей в режиме реального времени нервной системы для предприятий, ориентированных на ИИ.</li> </ul> Данные реального времени — это и есть реальность. Это контекст, отражающий физическую и цифровую реальность того … article https://www.itweek.ru/themes/detail.php?ID=235070 Thu, 25 Jun 2026 15:15:07 +0300 <p>Эксперты компании «Информзащита» выявили, что в 2026 году украденные учетные данные по-прежнему используются более чем в 80% кибератак хотя бы на одном этапе развития инцидента. За последний год число случаев, когда злоумышленники входили в корпоративные системы под видом легитимных пользователей, выросло на 29%. В наиболее быстрых сценариях от первого доступа до попытки кражи данных проходило около 72 минут против 285 минут годом ранее — то есть окно реагирования сократилось почти вчетверо, и SOC физически не успевает в него вписаться при ручных процессах. Получив пароль, хэш, служебный ключ или данные активного сеанса, атакующий получает доступ не к одной системе, а к тем ресурсам, на которые уже имеет право сотрудник: почте, файловым хранилищам, внутренним приложениям, облачным сервисам и административным консолям.</p> <p>Система видит привычную учетную запись, разрешенное подключение, корректный пароль или действующий ключ доступа, и часто этого достаточно, чтобы злоумышленник получил доступ к тем же приложениям, что и сотрудник, а затем начал изучать доступные ресурсы, права групп и сетевые маршруты. Средства защиты, настроенные на обнаружение вредоносных файлов и попыток эксплуатации уязвимостей, могут не увидеть проблему в момент входа: формально пользователь авторизовался корректно. Особенно опасны учетные записи с расширенными правами, технические пользователи для интеграций, а также сотрудники, которые имеют доступ сразу к нескольким контурам компании.</p> <p>Пароли похищают через фишинговые страницы, вредоносные программы для кражи данных из браузеров, поддельные обновления, сообщения от имени подрядчиков и сервисов доставки. Отдельную нишу занимают личные устройства сотрудников. На них нередко сохраняются корпоративные пароли, данные доступа к почте и облачным сервисам, файлы с ключами или конфигурациями. В открытой статистике по журналам вредоносных программ для кражи данных 30% скомпрометированных устройств относились к корпоративным, а 46% устройств, где были обнаружены корпоративные учетные записи, не находились под управлением работодателя. Это означает, что <nobr>MDM-политики</nobr> и корпоративный антивирус физически отсутствовали на почти половине машин, с которых утекли рабочие пароли — компрометация произошла за пределами видимости любого корпоративного средства защиты. На практике это означает, что часть корпоративных доступов оказывается скомпрометированной за пределами корпоративной сети и без прямого взлома инфраструктуры компании.</p> <p>Разбивка по векторам атак показывает, что кража учетных данных почти всегда пересекается с другими техниками. На социальную инженерию приходится 33% первичных проникновений, причем 22% связаны непосредственно с фишингом. Еще в 13% случаев атакующие использовали учетные данные, скомпрометированные ранее, а в 8% — подбирали пароли к существующим учетным записям. Дополнительные 11% формируют ошибки в настройках прав доступа и злоупотребление легитимными полномочиями сотрудников или подрядчиков. В сумме атаки на идентификацию обеспечивают 65% первичных проникновений. Полученный пароль редко остается единственным инструментом злоумышленника: его проверяют в почтовых сервисах, на шлюзах удаленного доступа, во внутренних приложениях и на серверных ресурсах, а затем используют для закрепления и повышения привилегий.</p> <p>После первого входа наибольшую роль играет внутренняя связность инфраструктуры. В исследовании, посвященном боковому перемещению внутри сети, 87% серверов принимали удаленные подключения по RDP или SSH, а 78,7% были доступны по SMB или WinRM. При этом 43,2% внутреннего трафика аутентификации приходилось на NTLM — устаревший механизм проверки подлинности, который допускает повторное использование хэша пароля вместо самого пароля. У 12,2% организаций выявлены прямые административные маршруты от пользовательских рабочих станций к серверам. В такой среде скомпрометированная учетная запись превращается в точку входа сразу во все направления, к которым она имеет право: от файлового сервера и почтового ящика до систем резервного копирования и консоли управления доменом — без единого дополнительного эксплойта. .</p> <p>Отраслевой срез показывает, что проблема по-разному проявляется в зависимости от устройства ИТ-ландшафта. В добывающей отрасли учетные данные фигурировали среди скомпрометированных данных в 43% подтвержденных утечек, в управляющих и головных компаниях — в 33%, в строительстве — в 31%. Для ритейла показатель составил 26%, для профессиональных услуг — 24%. В финансовом секторе, промышленности и транспорте учетные данные были затронуты в 22% подтвержденных утечек. Этот показатель описывает состав похищенных данных; частоту всех инцидентов он не измеряет. Тем не менее распределение хорошо отражает зоны повышенного внимания: чем больше в компании подрядчиков, распределенных площадок, технических учетных записей, удаленного доступа и старых интеграций, тем выше вероятность, что один пароль сохранится дольше положенного и попадет в чужие руки. Высокие показатели в добыче и управляющих компаниях объясняются не слабостью ИТ-команд, а структурой доступа- все это создает длинный хвост учеток, которые никто не считает приоритетными для ротации. </p> <p>Причина часто кроется в накопившихся исключениях. Учетная запись создавалась для проекта, затем проект завершился, но доступ остался. Технический пользователь получил широкие права ради стабильной работы интеграции. Сотрудник сменил подразделение, а прежние полномочия не были отозваны. Подрядчик подключался к системе на время внедрения и продолжил иметь возможность входа после окончания работ. Одновременно часть паролей сохраняется в браузерах, файлах конфигурации, скриптах автоматизации и системах управления задачами. Внутри одной инфраструктуры могут сосуществовать современные механизмы аутентификации, старые протоколы, общие учетные записи и несколько независимых каталогов пользователей. Злоумышленнику достаточно найти наиболее слабый участок этой цепочки.</p> <p>Сокращать риск необходимо через управление полным жизненным циклом учетной записи. Компании стоит инвентаризировать пользовательские, привилегированные и технические учетные записи, определить владельца каждого доступа, проверить его фактические права и отключить неиспользуемые учетные записи. Для администраторов и систем с высокой критичностью требуется раздельная работа с обычными и привилегированными учетными записями, многофакторная аутентификация с использованием аппаратных ключей или других устойчивых к фишингу методов, ограничение доступа по времени и контроль действий в ходе сеанса. Техническим учетным записям необходимы регулярная смена секретов, запрет постоянных паролей, ограничение источников подключения и минимальные права, достаточные только для конкретной операции.</p> <p>Отдельного контроля требуют входы с новых устройств, попытки авторизации из непривычных регионов, одновременное использование одной учетной записи в разных средах и последовательные обращения к большому числу ресурсов. Не менее полезно регулярно сопоставлять корпоративные адреса электронной почты с данными о внешних утечках, но реагировать нужно не только сменой пароля. При подтвержденной компрометации требуется отозвать активные сеансы, проверить выданные ключи доступа, сбросить пароли технических пользователей и проанализировать, какие системы были доступны под этой учетной записью. Радиус поражения одного украденного пароля измеряется не его сложностью, а объемом прав, которые к нему прикреплены, и временем, за которое организация способна отозвать активные сессии после сигнала тревоги — в большинстве обследованных сред этот показатель составил от 4 до 18 часов. Украденные учетные данные остаются удобным инструментом для атакующих по одной причине: организация сама заранее определяет, насколько далеко можно пройти с чужим паролем. Чем уже права доступа и чем быстрее компания способна отозвать их после подозрительной активности, тем меньше шансов, что единичная компрометация перейдет в масштабный инцидент.</p> Эксперты компании «Информзащита» выявили, что в 2026 году украденные учетные данные по-прежнему используются более чем … message https://www.itweek.ru/themes/detail.php?ID=235069 Thu, 25 Jun 2026 15:08:36 +0300 <p><nobr>2024-2025</nobr> годы проходили под знаменем экстренной миграции и заполнения ниш ушедших вендоров, в начале 2026 года рынок начал фильтровать решения через призму совокупной стоимости владения, доступности железа и реальной облачной экспертизы. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, подвел итоги I полугодия и дал прогноз на 2026 год.</p> <p>В условиях отсутствия прямых поставок от глобальных вендоров, рынок адаптировался к параллельному импорту и использованию альтернативных платформ. Для российского облачного рынка теперь норма, что нет унифицированного стека.</p> <p>Однако в I полугодии 2026 года проблема трансформировалась: дефицит сместился с серверов на компоненты и сетевое оборудование. Заказчики готовы переплачивать за облако, чтобы не брать на себя риски простоя поставок и ремонта.</p> <p>Мультиоблако как гарантия независимости столкнулось с реальностью кадрового голода и сложностями администрирования. Стоимость поддержки полноценного мультиоблака выросла на 40% из-за дефицита мультикомпетентных DevOps-инженеров. Бизнес стремится снизить операционные расходы, предпочитая делегировать обслуживание сложной облачной инфраструктурой, поэтому в I полугодии 2026 года на рынке одна из востребованных моделей «Primary + Backup» (продуктовые / критические системы и резервные копии) — консолидация ИТ-систем у одного-двух стратегических провайдеров. Основной провайдер берет на себя 80% нагрузки и ответственность за интеграцию, второй используется исключительно как аварийный контур или для специфических сервисов (например, высокопроизводительные GPU-кластеры для ИИ).</p> <p>В 2026 году помимо нехватки на рынке высокопроизводительных GPU, рост плотности вычислений для ИИ уперся в лимиты электропитания стойко-мест. ИИ перестал быть отдельной вертикалью в бизнесе и стал параметром инфраструктуры — в приоритет выходит безопасность ИИ-моделей. Заказчики запрашивают не просто «GPU-сервер», а «платформу для инференса» с встроенными инструментами ИИ-безопасности.</p> <p>Тренд на гибридность в 2026 году трансформировался из стратегического выбора в тактику управления рисками дефицита. Заказчики строят гибрид, потому что публичное облако не может гарантировать SLA на определенные типы нагрузок из-за фрагментации парка, а приватное — слишком дорого масштабировать под пики. Таким образом, критичные ядра систем остаются на собственном или выделенном железе (bare metal), а эластичные фронтенды уходят в публичное облако. Это усложняет архитектуру, но страхует от простоев. В такой ситуации провайдер становится интегратором разнородных сред.</p> <p>По предварительным оценкам аналитиков M1Cloud, объем рынка облачных сервисов в РФ по итогам I полугодия 2026 года составил около 450 млрд рублей. Годовая динамика роста замедлилась до <nobr>25-30%</nobr> (против <nobr>35-40%</nobr> в аналогичном периоде 2025 года). При этом доля IaaS в структуре рынка занимает около 60%. Номинальное увеличение выручки провайдеров во многом обеспечено не кратным ростом потребления ресурсов, а индексацией цен из-за удорожания логистики оборудования и энергоносителей.</p> <p>Рынок продолжает консолидироваться, но не столько через поглощение крупных игроков, сколько через покупку компетенций и готовых мощностей, где объектом покупки выступают не клиентские базы, а развернутые кластеры с подключенной мощностью и штатом облачных инженеров, способных работать с гетерогенным парком.</p> <p>Российский облачный рынок остается одним из самых маржинальных в ИТ-секторе. Рынок сохранит темпы роста в диапазоне <nobr>25-30%,</nobr> но драйвером станет не количество заказчиков, а глубина проникновения сервисов. Наибольший рост покажут игроки со зрелым стеком, диверсифицированной базой поставок оборудования, собственной инженерной экспертизой и с опытной командой эксплуатации. Роль провайдера окончательно трансформировалась в технологического партнера и инфраструктурного интегратора, который способен обеспечить непрерывность бизнеса заказчика в условиях турбулентной внешней среды.</p> 2024-2025 годы проходили под знаменем экстренной миграции и заполнения ниш ушедших вендоров, в начале 2026 года рынок … message https://www.itweek.ru/themes/detail.php?ID=235067 Thu, 25 Jun 2026 11:22:35 +0300 <p>Yandex B2B Tech открыла публичный доступ к Vibecraft — сервису для создания сайтов и веб-приложений по текстовому описанию. С его помощью предприниматели, менеджеры могут создавать прототипы цифровых продуктов, трекеров, CRM-систем, мини-игр и не только. Попробовать сервис можно на сайте vibe.sourcecraft.dev — каждый пользователь получит 4000 нейрокредитов для тестирования.</p> <p>Для создания проекта в Vibecraft нужно описать задачу в чате с ИИ-помощником. Он уточнит, для какой аудитории создаётся сервис, какие функции нужны и как им будут пользоваться. По этим критериям Vibecraft собирает первую версию сайта или веб-приложения. Все проекты пользователи могут публиковать в интернете на собственных доменах. Vibecraft может собрать сайт или прототип веб-приложения с личным кабинетом, каталогом, формой загрузки файлов, встроенной базой данных и фирменным дизайном пользователя. </p> <p>Во время закрытого тестирования пользователи создали более 1000 проектов. Более половины обращений к Vibecraft были связаны с разработкой прикладных сервисов, а не только сайтов. Пользователи создавали панели управления, калькуляторы, мини-игры, инструменты аналитики, CRM-системы, интернет-магазины и другие проекты. </p> <p>«Vibecraft помогает превратить идею сервиса в работающий прототип, проверить интерес пользователей и затем принять решение о полноценной разработке. Так предприниматели и команды могут направлять ресурсы на проекты, которые уже подтвердили свою востребованность», — рассказал Иван Пузыревский, технический директор платформы Yandex Cloud.</p> <p>Сегмент no-code и low-code решений в России растёт на 40% в год и может достичь 30 млрд рублей к 2028 году. При этом около 36% представителей малого бизнеса в России по-прежнему работают без собственного сайта из-за ограничений бюджета, времени и отсутствия технических навыков. Менее 15% малых предпринимателей используют сайты как канал продвижения, при этом почти половина хотела бы их создать. Vibecraft помогает преодолеть эти барьеры: он уточняет детали, предлагает структуру и собирает рабочий сайт. По оценкам участников тестирования, первый результат можно получить за <nobr>5–10 минут.</nobr> Vibecraft также помогает определить состав проекта, предлагая необходимые формы, пользовательские сценарии и бизнес-логику.</p> Yandex B2B Tech открыла публичный доступ к Vibecraft — сервису для создания сайтов и веб-приложений … message https://www.itweek.ru/themes/detail.php?ID=235066 Thu, 25 Jun 2026 09:34:35 +0300 <p><em>Сетевые руководители знают, что их сотрудники ежедневно сталкиваются с огромным потоком данных и телеметрии, но готовы ли их команды доверить агентам искусственного интеллекта больше задач в области сетевых операций? Мэри Шеклет, президент консалтинговой компании Transworld Data, приводит на портале </em><em>InformationWeek</em> <em>четыре шага, которые помогут организациям подготовиться к этому.</em></p> <p>Навыки сетевых специалистов часто оказываются неактуальными, когда речь идет о внедрении ИИ и автоматизации в сетях. Это происходит в то время, когда компании ожидают мгновенного решения сетевых проблем, а также возможности масштабирования и развертывания как можно большего количества новых приложений внутри компании и в облаке — часто за считанные секунды. Разработчики уже имеют высокоавтоматизированные методы развертывания, но сетевые специалисты отстают.</p> <p>Пришло время взглянуть на следующую волну автоматизации сетевых операций. Другими словами, можно ли использовать развертывание сетевых ИИ-агентов и автоматизации для ускорения циклов развертывания сети и решения возникающих проблем?</p> <h3>Для чего предназначены агенты ИИ</h3> <p>Сетевые агенты ИИ находятся на стадии исследования. Их конечная цель — расширить автоматизацию сети за пределы мониторинга и AIOps, в область, где основы управления сетью максимально автоматизированы. Это включает мониторинг, оповещение, реагирование и разрешение инцидентов, а также соблюдение корпоративной безопасности и соответствия нормативным требованиям. После того, как будет достигнута уверенность в возможностях этих агентов, следующим шагом станет автоматическое масштабирование и управление сетевыми ресурсами для оптимизации рабочих нагрузок приложений.</p> <p>Для выполнения этих задач сетевым агентам ИИ требуется получить от команд, занимающихся сетью, безопасностью и комплаенсом, набор бизнес-правил. Далее агенты ИИ используют машинное обучение для понимания сети, чтобы самостоятельно улучшать свою производительность.</p> <h3>Почему сетевые агенты ИИ остаются в значительной степени желательным решением</h3> <p>Сегодня сочетание факторов привело к тому, что внедрение сетевых агентов ИИ остается скорее желательным, чем реальным.</p> <p>Хотя сетевые сотрудники могут создавать бизнес-правила для управления сетью и масштабируемости, необходимые сетевым агентам ИИ, они также должны обеспечить единообразие этих правил и рекомендаций во всех сетях, будь то в центре обработки данных, на периферии или в облаке. Многие организации сталкиваются с этой проблемой из-за множества разнородных сетей.</p> <p>Кроме того, существуют проблемы с интеграцией систем и сетей, а также с координацией безопасности, комплаенса и управления сетью, которые могут охватывать несколько различных функциональных отделов внутри компании. Сотрудничество между этими командами на практике может быть сложной задачей — но без него у агентов ИИ остаются пробелы в инструкциях.</p> <p>Как и в случае с обучением агентов, существует также кривая обучения персонала в отношении ИИ и автоматизации. Хотя большинство корпоративных сетевых команд перешли от стандартного мониторинга сети к наблюдаемости, они все еще лишь умеренно вовлечены в AIOps, который является критически важным шагом на пути к сетевым агентам ИИ. Хорошая новость заключается в том, что несколько крупных поставщиков сетевого оборудования предлагают четкие пути миграции технологий, которым могут следовать организации — пути, которые могут привести организации от стандартного мониторинга сети до сетевых агентов ИИ.</p> <h3>Как выглядят сетевые агенты ИИ на практике</h3> <p>Изучая сетевые агенты ИИ, сетевые команды хотят понять, как эти агенты работают и как могут принести пользу сетевым операциям.</p> <p>В ходе одного из испытаний, проведенного в ноябре 2025 г. компанией Nanites, которая предоставляет компонуемые (т. е. модульные) сетевые агенты ИИ, были получены интересные результаты. Исследователи смоделировали сбой интерфейса в сети Cisco IS-IS (промежуточная система — промежуточная система). Система Nanites AI проанализировала оповещение и устранила проблему за 3 минуты, что обычно занимает у квалифицированного инженера более 30 минут. Внутри системы были выполнены следующие действия:</p> <ul> <li> Автономная обработка оповещений от Grafana (ПО для сбора метрик, логирования и трассировки).</li> <li> Выявление первопричин путем логического анализа (вероятно, путем наблюдения за сетевыми паттернами, конфигурациями, топологией и трафиком, а затем формулирования выводов), а не просто на основе правил или сценариев.</li> <li> Динамическое определение точных шагов по устранению неполадок в режиме реального времени.</li> <li> Автономное выполнение этих шагов при непосредственном взаимодействии с системами.</li> <li> Применение исправлений за секунды (только с одобрения человека).</li> </ul> <p>Авторы сделали примечание, в котором говорится, что данное испытание проводилось в строго контролируемой сетевой среде.</p> <p>Время устранения неполадок в ходе испытания было впечатляющим; на первый взгляд, агент ИИ явно работал намного быстрее, чем инженер-человек. Но не менее примечательным было и то, что испытание проводилось в строго контролируемой сетевой среде, а также необходимость участия сотрудника сетевого отдела для принятия окончательного решения.</p> <p>Даже в идеальных системах — что для большинства не является реальностью — ИИ не доверяют действовать полностью автономно. Это поднимает вопросы о том, насколько необходимо участие человека, если организация передает управление своей сетью агентам ИИ.</p> <h3>Почему сетевые команды изучают возможности использования ИИ-агентов</h3> <p>Даже при наличии опасений сетевым менеджерам ясно, что инструменты, используемые их сотрудниками, не справятся с лавинами данных, которые они теперь видят ежедневно.</p> <p>В феврале 2026 г. Нерадж Кумар, директор по разработке решений Solarwinds, <a href="https://www.solarwinds.com/blog/from-data-overload-to-decisions-rethinking-itops-in-apj">сослался</a> на исследование IDC, которое показало, что 59% организаций инвестируют в AIOps как средство автоматизации мониторинга сети, но 75% организаций по-прежнему заняты «поддержанием работоспособности». Разрозненность инструментов оказалась одной из причин, по которой организациям трудно двигаться вперед, — но также и перегрузка инфоормацией от поступающих сетевых данных и телеметрии.</p> <p>«Ни один CIO не скажет, придя в офис в понедельник: „Сегодня моя среда проще, чем в прошлом году“. Внедрение гибридных и мультиоблачных решений дало командам больше гибкости, но также и больше точек интеграции, потоков телеметрии и способов распространения инцидентов по всей системе», — отметил Кумар.</p> <p>Очевидно, что для бесперебойной работы сетей и их масштабирования под конкретные задачи требуется больше ИИ и автоматизации. Это стимулирует внедрение сетевых агентов ИИ для выполнения большего объема работы — но готовы ли сотрудники сети эффективно их использовать?</p> <h3>Четыре способа подготовиться к внедрению сетевых агентов ИИ</h3> <p>Для организаций, которые в настоящее время не чувствуют себя готовыми к внедрению агентного ИИ, есть хорошие новости: сейчас самое время заложить основу для сетевых агентов ИИ, поскольку технология все еще находится на очень ранних этапах внедрения. Если эти шаги будут предприняты сейчас, управление сетью не будет отставать.</p> <p>Вот четыре рекомендации:</p> <ol> <li><strong> Начните с того, что у вас есть. </strong>Сетевые сотрудники уже знают, что при масштабировании сети они получают огромное количество данных и оповещений. Они также знают, что не могут справиться со всеми оповещениями и что имеющиеся инструменты не всегда справляются с этой задачей. В результате почти все приходят к тому, что необходима бóльшая автоматизация сетевых операций, будь то с помощью AIOps или сетевых агентов ИИ.<br/> <br/> В этот момент сетевые сотрудники должны начать свою оценку. Если бы вы могли автоматизировать любые операции в сети, какие операции вы бы больше всего хотели автоматизировать с помощью ИИ? Какого повышения производительности вы бы ожидали? Четко определяя приоритеты, сотрудники сужают фокус и организуют стратегию вокруг значимых бизнес-результатов. </li> <li><strong> Определите стратегию и составьте дорожную карту. </strong>После того, как сетевые сотрудники определили цели автоматизации и повышения производительности сети, следующим шагом является создание графика этих улучшений и определение технологий, которые могут обеспечить желаемые результаты.<br/> <br/> Было бы здорово представить себе полностью автономную сеть, использующую сетевых агентов ИИ, которые могли бы самостоятельно управлять сетью и достигать всех целей по производительности, но почти никто не согласился бы на это. Испытание агентов ИИ компанией Nanites — прекрасный пример: производительность была достигнута, но только в строго контролируемой сетевой среде, в присутствии сетевых специалистов, принимающего окончательное решение о том, каких сетевых агентов ИИ рекомендовать.<br/> <br/> Командам следует принимать это во внимание при разработке своей стратегии. Сетевые сотрудники должны учитывать, как повседневные проблемы в системе могут повлиять на эффективность ИИ, и разрабатывать дорожные карты, учитывающие необходимость участия человека. </li> <li><strong> Сотрудничайте с дальновидным сетевым вендором. </strong>В целом, предприятия и поставщики видят эволюцию управления сетью от стандартного мониторинга к наблюдаемости, затем к AIOps и, наконец, к сетевым агентам ИИ. Однако не все поставщики одинаково хороши в качестве деловых партнеров и имеют эффективную технологическую дорожную карту для своих продуктов. При выборе сетевых вендоров для сотрудничества следует учитывать долгосрочную перспективу; цель состоит в том, чтобы найти поставщиков, которые постоянно инвестируют в свою продукцию, поддерживают ее и предлагают отличную поддержку.</li> <li><strong> Протестируйте сетевых агентов ИИ в контролируемых сетевых средах. </strong>Nanites протестировала сетевых агентов ИИ в строго контролируемой сетевой среде. Это позволило адаптировать сценарий использования, чтобы наблюдать за тем, как набор сетевых агентов ИИ работает в конкретном контексте. Другими словами, тестирование проводилось не в гибридной конфигурации множества облачных и внутренних сетей, которые есть у большинства предприятий. Предприятиям следует извлечь из этого урок. Начните постепенно, тестируя сетевой ИИ и автоматизацию в строго контролируемой сетевой среде. Как только проблемы там будут устранены, агентный ИИ можно будет протестировать в новых областях и далее масштабировать.</li> </ol> Сетевые руководители знают, что их сотрудники ежедневно сталкиваются с огромным потоком данных и телеметрии … article https://www.itweek.ru/themes/detail.php?ID=235064 Thu, 25 Jun 2026 09:16:47 +0300 <p><em>Когда бизнесу предлагают open source-систему мониторинга для ИТ — от популярных решений вроде Zabbix до других инструментов этого класса — идея выглядит рационально: лицензии нет, продукт доступен, можно быстро начать и не тратить бюджет на коммерческое решение. Но в реальности компания получает не «бесплатный мониторинг», а задачу для своей команды. Систему нужно внедрить, настроить под инфраструктуру, связать с ИТ- и ИБ-процессами, поддерживать, обновлять, проверять и развивать. Поэтому главный вопрос не в том, сколько стоит лицензия, а в том, во сколько компании обходится эксплуатация такого стека. </em></p> <h3>Нулевая лицензия не означает нулевую стоимость</h3> <p>Главный миф про open source-мониторинг звучит просто: если за лицензию не надо платить, значит решение бесплатное. На практике это не так. Бесплатно компания получает только саму технологию: готовое ядро, которое умеет собирать данные, отслеживать состояние систем и показывать, что происходит в инфраструктуре. Это действительно ценно. Если писать такой инструмент с нуля, стоимость была бы несравнимо выше.</p> <p>Но между «скачали технологию» и «получили надежный мониторинг для бизнеса» лежит большая работа. Систему нужно настроить под конкретную инфраструктуру, подключить нужные источники данных, связать с другими ИТ- и ИБ-инструментами, настроить алерты, проверить обновления, описать правила эксплуатации. Все это не делает само ядро open source. Это делает команда компании.</p> <p>И здесь бесплатность быстро превращается в экономику. Допустим, компании нужно развернуть мониторинг для инфраструктуры хотя бы на 50+ рабочих мест и нескольких ключевых сервисов. Начинающий администратор с такой задачей, скорее всего, не справится. Нужен ИТ-специалист уровня senior, который будет разбираться в продукте, разворачивать систему, подключать источники данных, настраивать базовый сбор метрик, проверять совместимость и устранять первичные ошибки внедрения.</p> <p>Даже если считать консервативно, такой специалист может стоить компании <nobr>250-350 тыс.</nobr> рублей в месяц с учетом налогов и сопутствующих расходов. Если внедрение, настройка и стабилизация open source-мониторинга занимают около шести месяцев, только трудозатраты одного специалиста превращаются в <nobr>1,5-2,1 млн.</nobr> рублей. Параллельно появляются тестирование, документация, исправление ошибок после запуска, первичная поддержка, согласование алертов с владельцами систем, проверка интеграций и участие смежных специалистов. Даже в умеренном сценарии это может добавить еще несколько сотен тысяч рублей. В итоге проект, который на старте выглядел как «бесплатный», уже на первом этапе легко выходит на <nobr>2-3 млн.</nobr> рублей внутренних затрат. И это все еще не полная стоимость владения. Это только цена технического запуска.</p> <p>При этом open source не стоит списывать как неудачный вариант. У него есть сильные стороны: низкий порог входа, зачастую бесплатные лицензии даже для коммерческого использования, гибкость, большое сообщество, возможность быстро проверить гипотезу и собрать решение под нестандартную инфраструктуру. Для небольшой среды, пилотного проекта или команды с сильной инженерной экспертизой open source может быть рациональным выбором. Проблема начинается не там, где компания выбирает open source, а там, где она считает его бесплатным и не закладывает ресурсы на внедрение, поддержку и развитие.</p> <h3>Скрытая стоимость превращения метрик в пользу</h3> <p>Собрать данные — еще не значит получить управляемую картину инфраструктуры. После запуска мониторинг может показывать графики, статусы и сотни событий, но бизнесу важно не количество сигналов, а понимание, какие из них действительно влияют на работу сервисов.</p> <p>Именно это часто не учитывают на старте. Без донастройки системы мониторинга генерируют слишком много алертов. Формально контроль есть: устройства подключены, метрики собираются, уведомления приходят. Но, если алертов слишком много, ИТ-команда быстро перестает отличать важное от второстепенного. Вместо помощи мониторинг создает дополнительный шум. Значит, систему нужно настраивать не только технически, но и по смыслу. Например, для мониторинга коммутатор ядра и гостевой коммутатор могут выглядеть как похожие устройства. Оба отдают параметры, оба могут прислать алерт. Но для бизнеса это разные ситуации. Отказ коммутатора ядра может остановить ключевые сервисы. Сбой гостевого коммутатора обычно имеет другой уровень критичности.</p> <p>Поэтому после подключения источников начинается отдельная работа: убрать ложные срабатывания, настроить пороги, учесть критичность оборудования и сервисов, определить ответственных за реакцию. Иначе компания получает не инструмент управления доступностью, а генератор технических уведомлений.</p> <p>Часто качество мониторинга становится понятно только во время первого инцидента. Пока все работает, графики выглядят убедительно. Но сбой показывает, помогает ли система быстро найти причину или просто добавляет еще один поток сообщений. После таких ситуаций правила приходится пересматривать: менять приоритеты, уточнять сценарии уведомлений, донастраивать алерты. В open source-стеке эта работа остается на стороне компании. Можно читать документацию, искать статьи, писать на форумы, обращаться к сообществу. Но это не техническая поддержка с понятными сроками реакции и ответственностью за конкретный кейс. Сообщество может помочь, а может не ответить. Для бизнеса это риск: если проблема возникла в критичный момент, ждать ответа на форуме нельзя.</p> <p>У этой донастройки тоже есть понятная цена. После запуска мониторинга инженер может тратить не <nobr>30-40</nobr> часов в месяц, а <nobr>80-120 часов:</nobr> разбирать ложные срабатывания, менять пороги, проверять уведомления, согласовывать критичность сервисов, дорабатывать дашборды, уточнять сценарии реакции и исправлять ошибки, которые проявились только в реальной эксплуатации. При внутренней ставке <nobr>2,5-4 тыс.</nobr> рублей в час это уже <nobr>200-480 тыс.</nobr> рублей ежемесячно. За полгода такой период стабилизации добавляет к проекту еще <nobr>1,2-2,9 млн.</nobr> рублей. И это без учета времени смежных специалистов: владельцев сервисов, сетевых инженеров, специалистов по ИБ и эксплуатации, которые помогают определить приоритеты, проверить зависимости и подтвердить, что мониторинг показывает не просто набор событий, а реальное влияние на работу бизнеса.</p> <p>Это только цена, чтобы довести open source-мониторинг до рабочего состояния и настроить его под реальные приоритеты бизнеса. Но на этом расходы не заканчиваются.</p> <h3>Стоимость команды, которая держит мониторинг в рабочем состоянии</h3> <p>Компания развивается, а вместе с ней меняется инфраструктура: появляются новые сервисы, обновляется оборудование, добавляются интеграции, растет объем метрик, повышаются требования к надежности и безопасности. Поэтому мониторинг нельзя один раз настроить и оставить без внимания. Его нужно поддерживать: следить за системой, разбирать алерты, обновлять правила, проверять данные и актуализировать настройки. Все это требует времени специалистов, а значит становится отдельной статьей затрат. В сложных средах это уже не разовая задача, а постоянная нагрузка на человека или команду: обновления нужно тестировать, интеграции проверять, а реакцию на события закреплять за ответственными. Иначе мониторинг быстро устаревает, теряет ценность и сам становится источником проблем.</p> <h3>Скрытые риски open source-мониторинга</h3> <p>Риски open source-мониторинга связаны не с тем, что сама технология плохая. Наоборот, под многие бизнес-задачи есть зрелые open source-проекты. Риск появляется тогда, когда компания берет такой стек как готовую бесплатную систему, но не выстраивает вокруг него эксплуатацию, ответственность, безопасность и процесс обновлений.</p> <p>Первый риск — безопасность и зависимость от правил внешней экосистемы. Open source не означает, что продукт автоматически безопасен. Его тоже пишут люди, а значит, в коде, обновлениях и инфраструктуре проекта могут быть ошибки, уязвимости и атаки на цепочку поставки. Например, в 2026 году <a href="https://www.securitylab.ru/news/568899.php">сообщалось </a>о компрометации инфраструктуры Notepad++: злоумышленники использовали механизм обновлений, чтобы доставлять вредоносные файлы отдельным пользователям. В другом свежем <a href="https://xakep.ru/2026/06/08/hola-miner/">кейсе</a> Windows-версия браузера Hola распространяла скрытый майнер Monero после атаки на цепочку поставок. Это не значит, что open source опасен сам по себе. Но это показывает: открытый код не отменяет проверки обновлений, контроля источников, тестирования и ответственности за то, что компания ставит в свою инфраструктуру.</p> <p>Второй риск — изменение модели развития проекта. Open source-проект может постепенно перестать быть «бесплатной локальной историей» в том виде, в котором его выбрала компания. Сегодня бизнес разворачивает решение у себя, считает, что контролирует стек и не зависит от поставщика. А завтра вокруг проекта появляется коммерческий контур: облачная версия, подписка, платная поддержка, новые условия сопровождения. Формально продукт может оставаться open source, но самые удобные сценарии, поддержка и развитие начинают смещаться туда, где уже появляются деньги и зависимость от внешней площадки. Похожую логику рынок уже видит на примере Zabbix: ожидается версия 8.0 LTS, при этом рядом с классической бесплатной установкой активнее продвигается Zabbix Cloud. Это не значит, что локальная версия исчезнет или станет платной. Но для бизнеса это сигнал: если критичная система мониторинга строится на внешнем open source-проекте, нужно заранее понимать, куда он развивается и не станет ли завтрашняя модель неудобной, дорогой или рискованной.</p> <p>Третий риск — технический долг. Если после инцидента стало понятно, что нужно изменить порог алерта, но задачу отложили, она не исчезает. Если для сбора данных с отдельного узла сделали временный скрипт, но потом не заменили его нормальным решением, такой «костыль» остается в системе. Если источник данных подключили быстро, но не проверили влияние на безопасность или производительность, проблема тоже уходит в долг. Со временем таких мелочей становится много, и мониторинг превращается в хрупкую конструкцию: его сложнее обновлять, труднее сопровождать и опаснее менять.</p> <p>Четвертый риск — простой бизнеса. Плохо настроенный open source-мониторинг может пропустить ранние признаки проблемы: алертов слишком много, они не приоритизированы или не доходят до ответственных. В итоге компания узнает о сбое уже тогда, когда не работает сервис, CRM, почта или сайт. Показательный <a href="https://www.cnews.ru/news/top/2023-08-30_zavody_toyota_vozobnovili_rabotu">пример</a> — остановка всех 14 заводов Toyota в Японии в 2023 году. Причиной стал недостаток места на диске базы данных: во время регламентных работ произошла ошибка, серверы обработки заказов стали недоступны, резервное переключение не сработало, и это привело к остановке заводов. Это хороший пример того, как инфраструктурная проблема, которую мониторинг должен помогать выявлять заранее, может привести к остановке бизнеса.</p> <p>Пятый риск — масштабирование. Чем больше инфраструктура, тем дороже становится ее наблюдаемость. Растет число устройств, сервисов, метрик, алертов и интеграций. Нужно больше вычислительных ресурсов, больше хранилища, больше настроек и проверок. Если мониторинг интегрирован с другими системами, приходится следить за изменениями API, тестировать обновления и проверять, что после них не сломались сбор данных, уведомления и дашборды. В какой-то момент даже в непрофильной компании вокруг мониторинга появляется процесс, похожий на DevOps: пилотная зона, предпрод, тестирование обновлений, контроль совместимости.</p> <h3>Чем отличается экономика коммерческого решения</h3> <p>Коммерческие системы мониторинга устроены иначе. В большинстве случаев компания платит не только за лицензию, а за готовый продукт и ответственность вендора. Это включает развитие кода, выпуск обновлений, документацию, техническую поддержку, обучение, инструкции по внедрению и, при необходимости, сопровождение через интегратора.</p> <p>У коммерческого решения тоже есть ограничения. Как правило, оно требует бюджета на лицензию, внедрение и сопровождение. Компания может зависеть от roadmap вендора, условий договора, стоимости продления, доступности поддержки и политики обновлений. Кроме того, готовый продукт не всегда идеально ложится на конкретную инфраструктуру: часть сценариев все равно приходится адаптировать, а нестандартные доработки могут требовать отдельного проекта и дополнительных затрат.</p> <p>Для российского бизнеса важны и формальные требования. Как правило, коммерческое решение можно проверить по понятным признакам: входит ли продукт в реестр российского ПО, есть ли необходимые сертификаты, какие условия поддержки прописаны в договоре, какие SLA берет на себя поставщик. В open source-стеке значительную часть этих вопросов компания закрывает сама. В коммерческой модели часть ответственности переходит к вендору.</p> <p>Еще одно отличие — масштаб опыта. Вендор поставляет продукт десяткам или сотням компаний, собирает обратную связь, видит типовые проблемы внедрения и может включать доработки в roadmap. За счет этого появляются отраслевые практики, инструкции, готовые шаблоны, понятные сценарии интеграции и обновлений. Такой конвейер создается один раз и затем используется многими компаниями, поэтому в большинстве случаев он обходится дешевле, чем попытка каждой организации самостоятельно выстроить такую экспертизу внутри.</p> <p>Это не означает, что коммерческое решение всегда лучше open source. Но его экономика обычно устроена понятнее: компания платит за продукт, поддержку, обновления, ответственность поставщика и накопленную практику внедрений. Особенно это важно в российских условиях, где есть импортозамещение, проприетарное оборудование, требования регуляторов и специфические интеграции. В таких случаях общие практики open source-сообщества не всегда можно напрямую перенести на конкретную инфраструктуру и бизнес-задачу.</p> <h3>Заключение</h3> <p>Поэтому выбор между open source и коммерческим мониторингом не должен сводиться к вопросу, где дешевле лицензия. В open source компания получает гибкость и контроль, но берет на себя больше инженерной и эксплуатационной нагрузки. В коммерческом решении часть этой нагрузки переходит к вендору или интегратору, но появляется стоимость лицензии, договора поддержки и зависимость от поставщика. Рациональный выбор начинается не с цены входа, а с расчета полной стоимости владения: людей, времени, поддержки, рисков, масштабирования и требований бизнеса.</p> <p>#IMAGE_235065#</p> Когда бизнесу предлагают open source-систему мониторинга для ИТ — от популярных решений вроде Zabbix до других … article Владислав Ганжа, директор лаборатории кибербезопасности UDV Group https://www.itweek.ru/themes/detail.php?ID=235062 Wed, 24 Jun 2026 13:31:43 +0300 <p>Сейчас на стадии строительства находится 42 проекта ЦОДов совокупным объемом инвестиций 282,1 млрд рублей. В числе крупнейших — дата-центры крупных технологических и корпоративных заказчиков, включая проекты «Яндекса», Сбера, DataPro, АФК Системы, ГК «Монарх», Гознак, Вконтакте и других инвесторов.</p> <p>При этом рынок развивается неравномерно. За последние три года — с мая 2023 года по май 2026 года — количество проектов на активных стадиях снизилось на 41,6%, а объем инвестиций в них — на 26,3%. В приостановке находится 38 проектов суммарным объемом 168,6 млрд рублей.</p> <p>По оценке аналитиков, под давлением чаще оказываются коммерческие проекты, которые планировались за счет частных инвестиций и заемного финансирования. На них сильнее влияют высокая стоимость капитала, рост затрат на строительство и инженерную инфраструктуру, а также сложности с поставками оборудования и подключением к энергетическим мощностям.</p> <p>«Рынок дата-центров остается одним из ключевых инфраструктурных сегментов цифровой экономики, но сейчас он проходит этап отбора. Спрос на вычислительные мощности растет, особенно на фоне развития облачных сервисов и искусственного интеллекта. Однако для коммерческих проектов решающими становятся стоимость финансирования, доступ к энергии и возможность масштабировать объект без чрезмерной нагрузки на экономику проекта. В настоящее время количество проектов могло бы быть значительно выше, а отрасль получила бы больший объем финансирования и более существенный импульс к развитию при условии доступности заемного капитала», — отметил генеральный директор Инвестиционно-аналитической группы ПКР Даниил Новицкий.</p> <p>Региональная структура инвестиций также показывает концентрацию рынка вокруг крупных инфраструктурных центров. Наибольший объем инвестиций в активные проекты приходится на Иркутскую область — 4 проекта на 170 млрд рублей. Далее следуют Москва — 16 проектов на 165,5 млрд рублей и Московская область — 11 проектов на 132,7 млрд рублей. Иркутскую область в число лидеров выводят проекты EN+ Group и «РУСАЛ Тайшет», а в Московской области значимые проекты реализуют, в частности, «Икселерейт», «Яндекс», Сбер, Авито. Саратовскую область в число лидеров выводит крупный проект Сбера в Балаково.</p> <p>Концентрация рынка заметна не только по регионам, но и по составу инвесторов. Крупнейшим инвестором в активные проекты ЦОДов является EN+ Group, в портфеле которого три проекта общей стоимостью 140 млрд рублей. Они связаны с развитием ЦОДов Cloud X в Иркутской области, в том числе рядом с Усть-Илимской ГЭС. Ещё один значимый игрок — Сбер: холдинг реализует масштабный проект центра обработки данных в Балаково Саратовской области.</p> <p>В целом топ-10 инвесторов отрасли реализуют 31 проект на активных стадиях суммарным объемом 590,1 млрд рублей. Это подтверждает общий тренд: в условиях дорогого финансирования и высоких требований к энергетике устойчивее чувствуют себя крупные холдинги, у которых есть ресурсы для долгосрочных инфраструктурных проектов.</p> <p>В <nobr>2026–2030</nobr> годах к вводу в эксплуатацию ожидается 97 проектов ЦОДов суммарным объемом инвестиций 838,1 млрд рублей. Наибольший объем проектов и инвестиций запланирован на 2027 год. Среди крупнейших ожидаемых объектов — ЦОДы Сбера в Московской и Саратовской областях, проект «Русала» в Иркутской области, а также новые очереди дата-центра DataPro в Москве.</p> <p>«В ближайшие <nobr>2–3</nobr> года фокус рынка будет смещаться в регионы с избыточными энергетическими ресурсами и к площадкам, расположенным ближе к источникам генерации. Это особенно важно для ИИ-задач, которые требуют высокой энергоемкости. Одновременно будет расти интерес к модульным и компактным решениям: они требуют меньших первоначальных вложений, быстрее развертываются и позволяют масштабировать мощности под реальный спрос», — добавил генеральный директор Инвестиционно-аналитической группы ПКР Даниил Новицкий.</p> <p>По мнению Филиппа Врацких, генерального директора «Техэкспо», развитие рынка ЦОДов всё сильнее зависит не только от спроса на вычислительные мощности, но и от доступности энергетической инфраструктуры.</p> <p>«Дата-центр — это не только серверы и стойки, но и сложный энергетический объект. Чем выше нагрузка от облачных сервисов, искусственного интеллекта и государственных цифровых платформ, тем важнее становится вопрос надежного и масштабируемого энергоснабжения. В ближайшие годы преимущество будут получать проекты, где энергетическая часть продумана заранее: есть доступ к мощности, резервирование, возможность быстрого развертывания и понятная экономика эксплуатации. Именно поэтому рынок будет внимательнее смотреть на модульные решения, локальную генерацию и инфраструктуру, которую можно масштабировать по мере роста нагрузки», — прокомментировал Врацких.</p> <p>По словам экспертов, корпоративный сегмент будет чувствовать себя устойчивее коммерческого: крупные холдинги продолжат развивать собственные мощности, чтобы снизить зависимость от арендной инфраструктуры и обеспечить контроль над критически важными данными. Дополнительным драйвером станет господдержка ИТ-инфраструктуры, связанная с задачами информационной безопасности и цифрового суверенитета.</p> <p>«Несмотря на снижение инвестиционной активности в коммерческом сегменте, у отрасли ЦОДов остается потенциал к восстановлению и росту. Объем данных, развитие облачных технологий, искусственного интеллекта и цифровых сервисов продолжают увеличивать спрос на инфраструктуру хранения и обработки информации. Поэтому вопрос не в том, нужны ли рынку новые дата-центры, а в том, где и в какой экономической модели они будут строиться», — резюмировал генеральный директор Инвестиционно-аналитической группы ПКР Даниил Новицкий.</p> Сейчас на стадии строительства находится 42 проекта ЦОДов совокупным объемом инвестиций 282,1 млрд рублей. В числе … message https://www.itweek.ru/themes/detail.php?ID=235061 Wed, 24 Jun 2026 13:28:08 +0300 <p>Искусственный интеллект все заметнее влияет на содержание труда и требования к работникам. На этом фоне все чаще звучат предупреждения о нехватке ИИ-компетенций. Насколько эти опасения подтверждаются данными? Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ анализирует структурный разрыв между спросом и предложением навыков работы с искусственным интеллектом на российском рынке труда на основе результатов Обследования рабочей силы (ОРС) Росстата.</p> <p>Как ранее подробно сообщали, данные ОРС указывают на отсутствие массового дефицита ИИ-компетенций: навыками работы с ИИ владеют 37,5% занятых, тогда как необходимыми для текущей работы их считают лишь 4,9%.</p> <p>При этом «избыток» ИИ-компетенций встречается значительно чаще, чем их дефицит: у трети всех занятых фактический уровень владения ИИ превышает требования работодателя. Даже с учетом ограничений самооценок, данные ОРС фиксируют высокий уровень соответствия между имеющимися и востребованными ИИ-компетенциями: в 73% случаев работники обладают необходимым для работы уровнем подготовки.</p> <p>Однако за общей картиной отсутствия массового дефицита скрываются локальные зоны нехватки анализируемых навыков. Среди работников, которым ИИ необходим для выполнения текущей работы, о дефиците соответствующих компетенций сообщает каждый шестой (15%).</p> <p>На базовом уровне дефицит минимален (6%), но по мере роста требований заметно увеличивается: при требованиях среднего уровня о нем сообщает каждый пятый работник (20%), продвинутого — почти каждый четвертый (24%). Наибольшие сложности связаны с переходом от базового использования массовых ИИ-сервисов к профессиональной интеграции ИИ в рабочие процессы.</p> <p>В профессиональном разрезе самая высокая интенсивность дефицита наблюдается у специалистов по ИКТ и ИКТ-техников. Однако основной вклад в общий дефицит формируют массовые профессии: специалисты в области образования, науки и техники, бизнеса и администрирования. По численности работников с дефицитом ИИ-компетенций лидирует сфера образования, далее следуют обрабатывающие производства, информация и связь, профессиональная и научная деятельность, здравоохранение.</p> <p>ИИ постепенно становится технологией общего назначения и выходит за пределы ИКТ-сектора, распространяясь на массовые профессии и традиционные отрасли экономики. Анализ данных Обследования рабочей силы Росстата за 2025 год указывает на отсутствие массового дефицита навыков для работы с ИИ-инструментами. Имеющиеся у работников ИИ-компетенции в большинстве случаев соответствуют должностным требованиям, а нередко и превосходят их. Ключевой вызов связан не с нехваткой базовых пользовательских навыков работы с ИИ, а с переходом от использования массовых ИИ-сервисов к профессиональной интеграции ИИ в рабочие процессы.</p> Искусственный интеллект все заметнее влияет на содержание труда и требования к работникам. На этом фоне все … message https://www.itweek.ru/themes/detail.php?ID=235060 Wed, 24 Jun 2026 13:25:53 +0300 <p>Компания «Аладдин» объявила о выпуске обновленной версии JaCarta Identity Provider (JIP) — продукта для реализации корпоративного SSO (однократной аутентификации) в совместимые приложения. Основным нововведением стала реализация механизма строгой аутентификации, что позволит пользователям авторизоваться в корпоративных приложениях с помощью цифровых сертификатов на USB-токенах и смарт-картах.</p> <p>Новый функционал JIP поможет заказчикам привести свою ИТ-инфраструктуру в соответствие с требованиями <nobr>117-го</nobr> Приказа ФСТЭК России, который предписывает использование строгой аутентификации и механизмов однократного входа (SSO) для всего оборудования и ПО ГИС и КИИ. Это имеет очень важное значение для ИТ и ИБ-инфраструктур российского рынка, позволяя значительно усилить защиту от фишинга, MITM и других распространенных атак.</p> <p>JaCarta Identity Provider (JIP) позволяет реализовать:</p> <ul> <li>однократную аутентификацию в информационную систему и во все используемые приложения и сервисы (единый вход или SSO — Single Sign-On);</li> <li>аутентификацию по kerberos-билету (наличие Kerberos-билета определяется автоматически);</li> <li>строгую аутентификацию по цифровым сертификатам и усиленную аутентификацию с использованием OTP и PUSH (необходим высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS);</li> <li>поддержку SLO для клиентов SAML и кросс-протокольного SLO SAML/OIDC;</li> <li>полную автоматизацию учёта и управления настройками OIDC/SAML-клиентов JIP;</li> <li>аудит — формирование журнала аутентификаций и других действий администраторов и пользователей, которые необходимо отслеживать для обеспечения информационной безопасности;</li> <li>мониторинг — отслеживание параметров работы JIP.</li> </ul> <p>«Требования регуляторов к механизмам аутентификации в государственных информационных системах и объектах КИИ становятся всё более строгими. Мы видим растущий запрос заказчиков на решения, которые позволяют одновременно повысить уровень безопасности и сохранить удобство доступа пользователей к корпоративным ресурсам. Реализованный в JaCarta Identity Provider механизм строгой аутентификации по сертификатам на токенах и смарт-картах помогает выполнить требования <nobr>117-го</nobr> приказа ФСТЭК России и существенно снизить риски, связанные с компрометацией учётных данных и фишинговыми атаками», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».</p> Компания «Аладдин» объявила о выпуске обновленной версии JaCarta Identity Provider (JIP) — продукта для реализации … message https://www.itweek.ru/themes/detail.php?ID=235057 Wed, 24 Jun 2026 10:49:49 +0300 <p><em>Искусственный интеллект повысит производительность за счет трансформации рабочей силы, пишут в корпоративном блоге ведущие аналитики </em><em>IDC</em><em>, приводя в качестве подтверждения выводы нового отчета </em><em>IDC</em> <em>«</em><em>The</em> <em>Economic</em> <em>Impact</em> <em>of</em> <em>AI</em><em>: 2026 </em><em>Edition</em><em>».</em></p> <p>Искусственный интеллект больше не является обещанием будущего; это экономическая сила, активно меняющая отрасли, рабочую силу и прогнозы ВВП по всему миру. Хотя ожидается, что ИИ приведет к масштабной трансформации рабочей силы в течение ближайших пяти лет, сроки остаются неопределенными, поскольку организации продолжают испытывать трудности с определением оптимальных сценариев использования и измеримых бизнес-результатов. Несмотря на широко распространенные прогнозы о том, что ИИ заменит рабочие места, пока мало доказательств того, что это происходит в больших масштабах, и бóльшая выгода от повышения производительности может быть достигнута за счет замены работы, а не работников. Таковы основные выводы из отчета этого года об экономическом влиянии ИИ.</p> <p>Главная новость: инвестиции обусловлены прогнозируемым экономическим эффектом</p> <p>Мы приближаемся к тому, что, по прогнозам, <nobr>2027-й</nobr> станет началом «второй волной» расходов на ИТ, обусловленных ИИ, когда инвестиции в ИИ приведут к тому, что общие расходы на технологии достигнут уровней, которые наблюдались в середине <nobr>1990-х.</nobr></p> <p>Мировые расходы на ИТ выросли в 2025 г. более чем на 14%, в основном за счет инвестиций поставщиков услуг в инфраструктуру ИИ. Сервис-провайдеры продолжают активно инвестировать, но «вторая волна» — это ожидаемый всплеск корпоративных расходов на сценарии использования, связанные с агентным ИИ. Прогнозируется, что бюджеты корпоративных ИТ-подразделений будут расти самыми быстрыми темпами почти за 30 лет.</p> <p>Эта грядущая волна зависит от экономического воздействия ИИ, которое ожидают организации. Здесь есть важная оговорка: пока что эти запланированные инвестиции в значительной степени поддерживаются ожидаемым повышением производительности, которое будет зависеть от измеримых бизнес-результатов.</p> <p>Многие бизнес-руководители сообщают о расходах, которые, по крайней мере частично, обусловлены FOMO (страхом упустить возможность). Существуют пробелы в зрелости ИИ, которые многим организациям необходимо восполнить в течение следующих <nobr>6-12 месяцев.</nobr></p> <p>В начале <nobr>2026-го</nobr> IDC назвала этот год «годом расплаты» («year of reckoning») для мировой экономики и ИИ. Экономический рост и ИИ теперь тесно связаны, причем в последние два года ИИ в значительной степени отвечал за стабильный рост ВВП, особенно в США и Китае. В условиях инфляции, которая в 2026 г. создаст проблемы для ИИ-экономики, существуют риски торможения.</p> <p>Но если нынешние темпы внедрения сохранятся и если измеримые бизнес-результаты будут поддерживать расходы на ИТ, ИИ приведет к перестройке производительности, глобальной трансформации рабочей силы и созданию к 2031 г. ценности на сумму более 22 трлн. долл.</p> <h3>Колоссальная совокупная ценность</h3> <p>В базовом сценарии прогнозируется, что в период с 2025 по 2031 гг. экономический вклад ИИ будет расти со среднегодовым темпом 35,6% и к 2031 г. достигнет уровня 22,5 трлн. долл. Даже в ограниченном, негативном сценарии (с учетом геополитических потрясений, регуляторных трений и замедления внедрения в предприятиях) эта цифра составляет 18,1 трлн. долл. В сценарии ускоренного роста она возрастает до 24,5 трлн. долл..</p> <p>Это не абстрактные цифры. Они отражают реальные потоки прямых доходов от ИИ, эффекты в цепочках поставок и последующую экономическую активность, поскольку работники и домохозяйства получают выгоду от повышения производительности.</p> <p>Экономическое воздействие ИИ распределится по регионам мира:</p> <p>#IMAGE_235059#</p> <ul> <li> Северная и Южная Америки: 14,1 трлн. долл., более 60% глобального эффекта, обусловленного доминированием США в гиперскейлерах, базовых моделях и полупроводниках.</li> <li> Азиатско-Тихоокеанский регион: 4,4 трлн. долл., это регион с самым быстрым ростом, где Китай выступает в качестве двигателя поставок, а развитые рынки, такие как Япония, Корея и Сингапур, стимулируют корпоративные инновации.</li> <li> Европа, Ближний Восток и Африка: 4,0 трлн. долл. Европа устанавливает золотой стандарт регулирования посредством Закона ЕС об ИИ, в то время как Ближний Восток (в частности, ОАЭ и Саудовская Аравия) становится новым двигателем роста.</li> </ul> <p>Несмотря на все эти впечатляющие цифры, влияние ИИ на макроэкономические данные пока выделить сложно. Мы только сейчас переходим от оценок влияния ИИ, основанных на опросах, к точке, где измеримое отклонение от исторических тенденций должно стать видимым в течение следующих 12 месяцев.</p> <p>Что меняет ситуацию, так это агентный ИИ. В отличие от предыдущих волн ИИ, агенты могут выполнять сложные многоэтапные задачи с минимальным участием человека, сокращая неэффективность бизнес-процессов в масштабах, недоступных предыдущим инструментам автоматизации. Покупатели ИТ-решений ожидают экономии операционных расходов в результате внедрения автоматизации на основе ИИ.</p> <h3>Риски реальны и в основном внешние</h3> <p>В отчете выделены четыре основных фактора, которые могут нарушить график создания ценности с помощью ИИ:</p> <ol> <li><strong> Геополитика и фрагментация торговли. </strong>Экспортный контроль над полупроводниками уже меняет цепочки поставок. Если напряженность усилится, доступ к критически важному оборудованию для ИИ станет непредсказуемым как для бизнеса, так и для правительств.</li> <li><strong> Энергетическая инфраструктура.</strong> Потребности ИИ в энергии превышают пропускную способность существующих электросетей. Доступность электроэнергии становится настоящим узким местом для расширения центров обработки данных и стратегическим фактором, который нельзя игнорировать ни в одной серьезной дорожной карте ИИ.</li> <li><strong> Дефицит квалифицированных кадров.</strong> Спрос на специалистов, обладающих навыками разработки, внедрения и управления ИИ, растет быстрее, чем успевают реагировать программы обучения. Переквалификация сейчас так же важна, как и инфраструктура.</li> <li><strong> Отставание внедрения систем управления.</strong> Менее трети предприятий полностью внедрили структуры управления ИИ. В условиях резкого расхождения регуляторных подходов между ЕС и США, многонациональные организации сталкиваются с действительно сложной ситуацией в сфере соблюдения нормативных требований.</li> </ol> <h3>ИИ заменяет работу, а не работников (пока что)</h3> <p>Главный вывод прост: в официальных данных по безработице нет доказательств того, что ИИ приводит к существенному сокращению рабочих мест. Уровень безработицы в США остается на исторически низком уровне.</p> <p>Но отсутствие массового сокращения рабочих мест — это не то же самое, что «обычное положение дел». Происходит и будет ускоряться трансформация рабочей силы: переход от рутинных задач к нерутинной когнитивной и межличностной работе.</p> <p>Этот переход происходит уже несколько десятилетий и в значительной степени связан с расходами на ИТ. Доля рутинных задач в общей занятости снизилась с примерно <nobr>60-65%</nobr> в 1960 г. до <nobr>40-45%</nobr> в <nobr>2020-м.</nobr> ИИ не создает нового направления, но значительно ускоряет эту траекторию. IDC прогнозирует дальнейшее снижение доли рутинных задач до примерно 30% к 2031 г.</p> <p>В отчете в качестве конкретного примера приводится разработка ПО: ИИ может в значительной степени автоматизировать рутинное кодирование и документирование (сокращение времени выполнения задач до 70%), в то время как работа по тестированию и архитектуре дополняется, а не заменяется ИИ. Разработчики, которые смогут адаптироваться, будут тратить больше времени на стратегическую, требующую принятия решений работу, в которой, в конечном итоге, и заключается ценность.</p> <h3>Что это значит для ИТ-поставщиков: три императива</h3> <p>ИТ-поставщикам необходимо срочно заняться следующими стратегическими направлениями:</p> <ol> <li><strong> Получение краткосрочной прибыли за счет агентного ИИ. </strong>Наиболее значимая возможность в краткосрочной перспективе заключается в применении агентов ИИ на уровне задач, в рамках рабочих процессов и во всех приложениях. Продукты должны отражать быстро меняющиеся сценарии использования и помогать клиентам достигать экономического эффекта в масштабе, а не просто проводить пилотные проекты.</li> <li><strong> Инвестирование в долгосрочный успех клиентов. </strong>Передача знаний важнее, чем контракты на поддержку. Покупателям ИТ-решений нужна помощь в управлении изменениями, повышении квалификации и достижении реальных бизнес-результатов от агентного ИИ. Если конечные пользователи не смогут получить экономическую выгоду в масштабе, инвестиционный импульс застопорится.</li> <li><strong> Взятие на себя ответственности за управление ИИ. </strong>Социальные последствия широкого внедрения ИИ огромны. Поставщики, которые активно взаимодействуют с политиками и бизнес-лидерами, направляя их к результатам, которые раскрывают человеческий потенциал, а не просто автоматизируют его, будут лучше подготовлены к сохранению актуальности и доверия в долгосрочной перспективе.</li> </ol> <h3>Итог</h3> <p>Новый отчет рисует картину ИИ-экономики, которая является масштабной, ускоряющейся и неопределенной по срокам. Увеличение экономического вклада ИИ до 22,5 трлн. долл. не является гарантированным; оно зависит от того, насколько организации перейдут от пилотных проектов к масштабному внедрению, насколько энергетическая инфраструктура и навыки будут успевать за прогрессом, а также от рамок управления, которые способствуют, а не препятствуют инновациям.</p> <p>Ясно одно: предприятия и поставщики, которые рассматривают ИИ как стратегический приоритет, инвестируя в трансформацию рабочей силы, управление изменениями и ответственное внедрение, будут в наилучшем положении для получения выгоды, даже если ожидаемые сроки будут нарушены. Те, кто будет ждать определенности, могут обнаружить, что окно для конкурентной дифференциации уже закрылось.</p> Искусственный интеллект повысит производительность за счет трансформации рабочей силы, пишут в корпоративном блоге … article https://www.itweek.ru/themes/detail.php?ID=235056 Wed, 24 Jun 2026 10:31:35 +0300 <p><em>Давление, связанное с необходимостью добиваться успехов в области искусственного интеллекта, может стать рецептом выгорания ИТ-руководителей. CIO компаний Expereo и Quadient рассказали порталу </em><em>InformationWeek</em><em>, как разделение ответственности за результаты внедрения ИИ может помочь предотвратить перегрузку, продолжая при этом стимулировать внедрение и получение ценности.</em></p> <p>В условиях, когда советы директоров все больше стремятся к успехам в области ИИ, CIO начинают понимать, что попытка взять на себя всю ответственность — это быстрый путь к выгоранию.</p> <p>Нина Татсия, CIO компании Quadient, столкнулась с этой реальностью после того, как в прошлом году заняла высшую технологическую должность в компании-поставщике ПО для автоматизации бизнеса. «Когда я ступила в должность, я обнаружила, что работаю по 20 часов в день... потому что хотела делать все, включая ИИ, — рассказывает она. — Конечно, это нежизнеспособно».</p> <p>Выгорание среди ИТ-руководителей не является чем-то новым. Например, должность CISO давно несет в себе этот риск: согласно <a href="https://www.proofpoint.com/us/newsroom/press-releases/proofpoint-2025-voice-ciso-report">отчету</a> Proofpoint «2025 Voice of the CISO Report», 63% опрошенных руководителей служб информационной безопасности испытывали или наблюдали профессиональное выгорание в течение предыдущего года.</p> <p>Поскольку CIO испытывают давление по поводу внедрения ИИ и его быстрой эволюции, они могут столкнуться с аналогичными рисками.</p> <h3>CIO под давлением</h3> <p>CIO, как правило, увлечены новыми технологиями, но ИИ — пожалуй, наиболее близкая к имитации человеческого интеллекта технология — создает уникальный набор проблем:</p> <ul> <li> все еще неясный путь к возврату инвестиций после миллионов и миллиардов, потраченных компаниями;</li> <li> тревога сотрудников по поводу возможной потери работы;</li> <li> ожидания заинтересованных сторон в отношении трансформации бизнеса с помощью ИИ.</li> </ul> <p><a href="https://www.ibm.com/downloads/documents/us-en/16ddce7b4954875d">Исследование</a> IBM «2026 Tech Leader Study» иллюстрирует давление, с которым сталкиваются CIO, стремясь вывести ИИ из пилотных проектов в корпоративную эксплуатацию. Только 11% из 2000 опрошенных технологических руководителей высшего звена заявили, что готовы к развертыванию агентов ИИ, запланированному на следующий год. Кроме того, 77% опрошенных организаций сообщили о том, что управление ИИ отстает. Несмотря на отсутствие полного контроля над системами, две трети технологических руководителей заявили, что несут ответственность за результаты работы этих систем.</p> <p>И, наконец, есть финансовый аспект руководства со стороны CIO. Расходы на ИИ стремительно растут, однако 84% технологических руководителей, опрошенных IBM, заявили, что они не полностью внедрили финансовое управление ИИ, а 85% заявили, что у них нет полной информации о расходах на ИИ в режиме реального времени.</p> <h3>Путь к выгоранию</h3> <p>В гонке за внедрением ИИ CIO могут сильно нагружать себя и свои команды, но Жан-Филипп Авеланж, CIO компании Expereo, предоставляющей управляемые сетевые услуги, считает, что риски выходят за рамки проблем с рабочими нагрузками. «Можно проделывать большую работу, но не это приводит к выгоранию ИТ-отдела или CIO, — поясняет он. — Проблема в несоответствии ожиданиям». Если разрыв между ожиданиями от CIO советов директоров и высшего руководства и реальностью не удастся преодолеть, высок риск выгорания.</p> <p>Авеланж отмечает, что выгорание CIO оказывает мультипликативный эффект на всю организацию. Выгоревшие сотрудники, обеспокоенные тем, что их рабочие места будут изменены — или ликвидированы — ИИ, могут затруднить для организации получение выгоды от этой технологии.</p> <p>«FOBO — страх упустить выгоду — теперь стал частью рабочего жаргона», — говорит Стейси Кэдиган, партнер Information Services Group, отмечая, что эта тревога угрожает подорвать достижения, которых организации стремятся добиться с помощью ИИ. «Ожидаемое повышение производительности может оказаться невозможным, если сотрудники будут дезориентированы, потрясены и истощены переходом к ИИ», — поясняет она.</p> <h3>Путь к успеху вместо забвения ИИ</h3> <p>CIO должны принять реальность того, что они не могут решить все проблемы, возникающие в процессе работы их организаций над тем, чтобы максимально использовать возможности ИИ, считает Татсия. «Невозможно изучить всё, и не следует изучать всё. Необходимо... сохранять свои навыки как человека, управляющего этой сферой», — говорит она.</p> <p>Эксперты отмечают важность следующего:</p> <ul> <li><strong>Мягкие навыки. </strong>Креативность, понимание людей и понимание бизнес-целей гораздо важнее для CIO, чем понимание каждой мельчайшей детали существующих технологий, считает Татсия.</li> <li><strong>Новая структура команды и повышение квалификации.</strong> Чтобы соответствовать новым требованиям к ИТ, CIO следует сосредоточиться на повышении квалификации нынешних членов команды и стратегическом найме, говорит Татсия. CIO определенно должны изменить форму и структуру команды, чтобы соответствовать этому технологическому сдвигу и новым способам работы.</li> <li><strong>Управление ожиданиями.</strong> По мере того, как CIO реформируют свои команды и учатся быть агентами перемен на своих предприятиях, им необходимо найти способы общаться с другими руководителями и советами директоров по поводу принимаемых ими стратегических решений. CIO должны управлять ожиданиями, а не обрекать себя на отставание, пытаясь выполнить все задачи и угодить всем, говорит Авеланж.</li> </ul> <h3>Всем нужна возможность выпустить пар</h3> <p>Как бы всепоглощающе ни был ИИ, посвятить ему всю работу, отдать все время — это нежизнеспособно. Если CIO хотят избежать выгорания сейчас или в будущем, им необходимо выделить время на другие аспекты своей жизни. «Мне нужно найти тот час в день, когда я не думаю о работе, что очень сложно. Занимайтесь спортом или гуляйте... иначе вы не будете по-настоящему полезны для себя, своей семьи или работы», — советует Татсия.</p> <p>CIO могут лучше управлять риском выгорания, окружая себя правильными людьми и расставляя приоритеты в использовании своего времени, но им также необходима структурная поддержка со стороны своих предприятий. «Организации, которые действительно смогут уменьшить усталость руководства и помочь ему наиболее эффективно справиться с выгоранием, — это те, которые действительно инвестируют в перепроектирование управления ИИ», — считает Кэдиган. Разделение ответственности за результаты ИИ и ранний анализ операционных моделей могут быть более эффективными, чем просто постоянное давление только на CIO.</p> Давление, связанное с необходимостью добиваться успехов в области искусственного интеллекта, может стать рецептом … article https://www.itweek.ru/themes/detail.php?ID=235055 Tue, 23 Jun 2026 15:03:11 +0300 <p>Компания AppSec Solutions, российский разработчик решений для кибербезопасности, выпустила крупное обновление платформы анализа защищённости мобильных приложений AppSec.Sting. Платформа полностью переведена с монолитной на микросервисную архитектуру на базе Kubernetes и получила переработанный подход к анализу: расширено покрытие SCA с интеграцией в AppSec.Track, обновлён динамический анализ под iOS, полностью обновлен пользовательский интерфейс. Таким образом, AppSec.Sting повышает пропускную способность и отказоустойчивость для клиентов, что ускоряет сканирование и снижает затраты на вычислительные ресурсы — в облаке и в инфраструктуре заказчика.</p> <p>Микросервисная модель снимает ключевые ограничения «монолита» — избыточное потребление ресурсов и сложность масштабирования. Теперь вычислительные мощности выделяются точечно: их получают только те компоненты, которые участвуют в сканировании в конкретный момент, а при росте нагрузки система масштабируется горизонтально. Это позволяет одновременно выполнять значительно больше сканирований без деградации производительности и убирает простаивающие мощности.</p> <p>Для заказчиков, разворачивающих решение в собственном контуре, это означает ощутимое снижение требований к серверному парку и совокупной стоимости владения. Параллельно команда переработала ядро анализа — платформа стала находить больше и работать быстрее:</p> <ul> <li>SCA — анализ состава ПО. Переработан движок извлечения компонентов и существенно расширено покрытие: платформа точнее определяет, из каких библиотек и зависимостей собрано приложение. Добавлена интеграция с AppSec.Track — для контроля open-source-рисков и безопасности цепочки поставок;</li> <li>iOS — переработанный динамический анализ. Реализован перехват трафика и обновлены инструменты DAST — сканирование приложений для iPhone стало точнее и глубже;</li> <li>WebView — отдельный модуль. Добавлен поиск уязвимостей в WebView, одной из самых частых точек уязвимостей в мобильных приложениях;</li> <li>Правила детектирования. Обновлены и расширены правила поиска — выше покрытие и точность.</li> </ul> <p>«Мы провели технологическую трансформацию продукта, которая напрямую экономит ресурсы клиентов: вычислительных мощностей требуется меньше, а объём одновременной работы кратно вырос. При этом мы вложились не только в инфраструктуру, но и в сам анализ — заметно расширили покрытие SCA и связали его с AppSec.Track, переработали динамический анализ под iOS и полностью обновили интерфейс. Наша цель — гибкая и современная платформа, которая находит больше, работает быстрее и удобнее в эксплуатации», — рассказал Никита Пинаев, руководитель продукта AppSec.Sting в AppSec Solutions.</p> <p>AppSec.Sting — часть экосистемы AppSec Solutions для автоматизированного анализа и безопасной разработки ПО и один из первых продуктов компании, запущенный в 2020 году. Платформа объединяет ключевые практики анализа защищённости мобильных приложений — DAST, SAST/BCA (анализ бинарного кода), IAST, API Security Testing и SCA — и в автоматическом режиме выявляет и приоритизирует уязвимости, отделяя наиболее критичные. Это помогает владельцам приложений находить и закрывать уязвимости до того, как ими воспользуются злоумышленники. AppSec.Sting регулярно проводит исследования мобильных приложений в популярных магазинах приложений.</p> Компания AppSec Solutions, российский разработчик решений для кибербезопасности, выпустила крупное обновление платформы анализа … message https://www.itweek.ru/themes/detail.php?ID=235054 Tue, 23 Jun 2026 10:02:12 +0300 <p><em>Согласно прогнозам </em><em>IDC</em><em>, глобальные ИТ-расходы на искусственный интеллект в 2026 г. достигнут 409 млрд. долл., что примерно на 53% больше, чем в прошлом году, и к 2029 г. они выйдут на уровень 700 млрд. долл. Это не тенденция. Это структурная трансформация глобальной технологической экономики, происходящая в режиме реального времени, пишет в корпоративном блоге Эрик Ньюмарк, вице-президент и генеральный директор подразделения SaaS, корпоративного ПО, CX и решений для рабочих мест IDC.</em></p> <p>И все же, несмотря на все эти инвестиции, предприятия не успевают за ИИ. Он уже широко применяется в производственной среде: по состоянию на начало 2026 г. примерно две трети организаций уже использовали ИИ в реальных производственных средах. Но большинство из них не масштабировали ИИ существенно за пределы целевых, изолированных развертываний. Широкое, полномасштабное внедрение остается исключением, а не правилом. Исследование IDC «FutureScape 2026» уточняет этот момент, прогнозируя, что почти 50% цифровых сценариев использования ИИ не достигнут целевых показателей ROI в 2026 г. из-за неясной выгоды для бизнеса, слабого взаимодействия человека и машины и недостаточного фундамента данных.</p> <p>Это не технологическая проблема. Технологии сейчас развиваются быстрее, чем когда-либо в истории современных корпоративных вычислений. Согласно отчету IDC «The Speed of AI Value Creation in Applications: What’s Causing the Delay?», это проблема обеспечения внедрения. Суть в том, что разрыв увеличивается. ИИ-инновации опережают принятие ИИ на предприятиях, и только вендоры, разрабатывающие и продающие ПО ИИ, могут решить эту проблему.</p> <h3>Разрыв между пилотными проектами и производством — где умирает ценность</h3> <p>Мы это уже проходили. В начале облачной эры организации проводили десятки успешных пилотных проектов, одновременно пытаясь мигрировать основные рабочие нагрузки. В начале эры SaaS внедрение застопорилось из-за сложности интеграции и управления изменениями, а не из-за возможностей продуктов. Эта картина знакома. Технологии стремительно развиваются, а корпоративной экосистеме (интеграции, управление, навыки, инфраструктура данных) требуются годы, чтобы догнать их.</p> <p>ИИ повторяет этот цикл с большей скоростью и более значительными последствиями. Вендоры, которые это понимают и действуют в соответствии с этим, определят следующую эру лидерства в сфере корпоративного ПО. Вендоры, которые этого не понимают, обнаружат, что одних лишь отличных технологий недостаточно для устранения разрыва доходов.</p> <h3>Ориентируйтесь на результаты, а не на возможности</h3> <p>Первое, что необходимо сделать, — это переосмыслить то, что вендоры на самом деле продают. Предприятиям не сложно понять, что может делать ИИ на демонстрации. Им сложно связать возможности ИИ с измеримыми бизнес-результатами в рамках их конкретных операционных сред, данных, рабочих процессов и требований комплаенса.</p> <p>Вендоры, которые ориентируются на эталонные показатели моделей и планы развития функций, говорят на языке, который их покупатели перестали считать приоритетным. Вендоры, которые ориентируются на количественно измеримые результаты (сокращение времени обработки счетов, снижение количества ошибок в прогнозировании спроса, ускорение закрытия финансовой отчетности), завоюют доверие и внутреннюю поддержку, необходимые для перехода от пилотного проекта к производству. Это не маркетинговая корректировка. Это фундаментальное перепозиционирование ценностного предложения с прямым влиянием на выручку. Для любого поставщика ИИ рост больше не связан с количеством лицензий. Он связан с тем, насколько глубоко клиенты интегрируют ИИ в повседневные рабочие процессы. Продажи, ориентированные на результат, ускоряют этот процесс.</p> <h3>Время получения выгоды теперь является конкурентным преимуществом</h3> <p>Одним из наиболее важных показателей, которые должны отслеживать вендоры, является время получения выгоды: как быстро новый клиент получает существенно улучшенный рабочий процесс благодаря ИИ. Сейчас этот срок слишком велик для слишком многих предприятий. Сложность интеграции, пробелы в готовности данных и нехватка внутренних навыков создают трение, которое замедляет темпы и дает комитетам по закупкам поводы для раздумий.</p> <p>Вендоры могут напрямую устранить этот пробел. Готовые интеграции для распространенных корпоративных архитектур, шаблоны рабочих процессов, адаптированные к конкретным отраслевым сценариям использования, и структурированные программы адаптации, которые сопровождают клиентов от пилотного проекта до внедрения в производство, перестали быть просто желательными услугами. Теперь это сам продукт. Предприятия, успешно масштабирующие ИИ, делают это с помощью партнеров-поставщиков, которые работают с ними там, где они находятся, а не там, где, по мнению поставщика, они должны быть.</p> <h3>Прекратите перекладывать проблему данных на клиента</h3> <p>Плохой фундамент данных неизменно является одним из главных препятствий для окупаемости инвестиций в ИИ. Наше исследование это наглядно показало, и это основная причина, по которой примерно половина пилотных ИИ-проектов не приносят окупаемости. Тем не менее, многие вендоры по-прежнему ошибочно рассматривают готовность данных как необходимое условие для клиента, а не как их общую проблему.</p> <p>От этого предположения нужно отказаться. На следующем этапе развития рынка победят те вендоры, которые помогут предприятиям оценивать, очищать и структурировать свои данные в рамках процесса внедрения, а не в качестве предварительного условия, которое клиенты должны выполнить до начала реального взаимодействия. Это означает инвестиции в инструменты обеспечения готовности данных, предложение предварительных оценок и явное включение качества данных в критерии успеха с самого первого дня. В лучшем случае, передача проблемы с данными клиенту задерживает развертывание. В худшем случае, это полностью губит проект и лишает его возможности продления.</p> <h3>Управление — это не функция, это фундамент</h3> <p>Проблемы управления (безопасность, возможность аудита, соответствие нормативным требованиям, ответственное использование ИИ) значительно замедляют циклы принятия решений предприятиями. Вендоры, рассматривающие управление как дополнительный уровень, который можно добавить позже, сами себе создают препятствия. Предприятия, которые останавливаются после успешного пилотного проекта, часто делают это не потому, что ИИ перестал работать, а потому, что юридические вопросы, вопросы комплаенса или ИТ-безопасности выявили проблемы, для решения которых продукт не был предназначен.</p> <p>Внедрение объяснимости, контроля доступа, журналов аудита и схем обеспечения нормативных требований в основной продукт, а не их добавление поверх, — вот что отличает вендоров, хорошо подготовленных к корпоративным внедрениям, от тех, кто вечно застревает на стадии проверки концепции. И окно возможностей для правильного решения этой задачи сужается, поскольку требования к управлению быстро приближаются к нормативным требованиям.</p> <h3>Согласование коммерческих моделей с успехом клиентов</h3> <p>Наиболее подготовленными к преодолению разрыва во внедрении ИИ будут те вендоры, которые строят свои коммерческие отношения вокруг результатов клиентов, а не вокруг количества рабочих мест или потребления токенов. Недавно анонсированные Oracle 22 приложения Fusion Agentic являются отличным примером такого переориентирования, поскольку они переводят корпоративные программные решения из пассивных «систем учета» в автономные «системы результатов». SAP и ServiceNow недавно объявили о подобном позиционировании. SAP выходит за рамки традиционного SaaS в сторону модели, ориентированной на результат, где агентный ИИ, основанный на Joule, находится между пользователем и корпоративным исполнением. Пользователи заявляют о своих бизнес-целях, а автономные системы SAP обрабатывают все остальное, более тесно согласовывая исполнение с результатом. ServiceNow также целенаправленно переориентировалась на выполнение задач, ориентированных на результат, перепозиционировав себя из платформы учета в то, что теперь называется «диспетчерской вышкой ИИ». Этот сдвиг распространяется и на ее партнерскую экосистему, где обновленные программы теперь вознаграждают участников на основе реальных результатов клиентов и успешных внедрений, а не традиционных уровней членства.</p> <p>Вендорам необходимо постоянно уделять больше внимания ценообразованию, основанному на результатах, стимулированию к завершению основных этапов внедрения и выделению ресурсов для обеспечения успеха клиентов, чтобы четко демонстрировать, что их финансовые интересы соответствуют результатам клиентов, а не только первоначальной транзакции. Такое соответствие укрепляет доверие, необходимое для долгосрочного расширения, выгодного обеим сторонам.</p> <p>Растущий разрыв между ИИ-инновациями и внедрением ИИ на предприятиях реален, но его можно сократить. Технология не является препятствием. Путь к его сокращению лежит непосредственно в том, как вендоры ПО взаимодействуют со своими клиентами не только в точке продажи, но и на протяжении всего пути от пилотного проекта до производства и масштабирования. Вендоры, которые возьмут на себя эту ответственность, выиграют дважды: завоюют доверие предприятий и благодаря этому увеличат долю рынка.</p> Согласно прогнозам IDC, глобальные ИТ-расходы на искусственный интеллект в 2026 г. достигнут 409 млрд. долл … article https://www.itweek.ru/themes/detail.php?ID=235052 Tue, 23 Jun 2026 09:44:38 +0300 <p><em>Компании продолжают массово внедрять искусственный интеллект. По данным Gartner, к 2028 году агентный ИИ будет встроен в 33% корпоративных приложений — против менее 1% в 2024</em><em>-м</em><em>. Но на практике большинство компаний сталкиваются не с проблемой доведения ИИ задач до результата, а с проблемой внедрения: инструменты закуплены, пилоты запущены, а реального эффекта бизнес не видит.</em></p> <p><em>Причина часто оказывается неожиданной. Судьбу ИИ-трансформации в компании сегодня решают не отдельные команды и не центры компетенций, а руководители среднего звена — люди, которые управляют процессами, KPI и ежедневной работой команд. Именно от них зависит, станет ли ИИ рабочим инструментом или останется дорогим экспериментом.</em></p> <p><em>Обсудим</em><em>, почему внедрением не может заниматься только центр компетенций и что стоит учесть руководителям.</em></p> <h3>Автоматизация ради автоматизации: как делать не надо</h3> <p>Одна из самых распространенных ошибок — начинать внедрение с технологии вместо бизнес-задачи. Внутри компании это выглядит так: «Нам нужен ИИ-агент. Все вокруг используют — значит, и нам надо». Но для чего?</p> <p>Представьте, что в отдел — допустим, в тендерный — приходит руководство и говорит: «Похоже, вы тратите слишком много времени на ручную работу. Давайте что-то автоматизируем». Команда анализирует процессы и находит задачу, которая действительно занимает до 40% рабочего времени сотрудников. Ее автоматизируют, внедрение проходит успешно, люди начинают работать быстрее.</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>В то время как задача второго — обеспечивать стабильность. На английском языке этот принцип называется «keep the lights on»: проще говоря, нужно делать все, чтобы свет не погас.</p> <p>Именно поэтому мидл-менеджмент обычно сопротивляется изменениям. Дело не в том, что руководитель «боится ИИ», это даже не назвать саботажем — просто любое изменение разрушает систему, которую он так тщательно выстраивал. Особенно болезненно это выглядит в случаях, когда процессы только-только удалось стабилизировать, а теперь их нужно перестраивать под искусственный интеллект.</p> <p>С точки зрения руководителя все выглядит примерно так:</p> <ul> <li> KPI только начали работать;</li> <li> команда уже адаптировалась;</li> <li> процессы стабилизировались;</li> <li> риски стали понятными.</li> </ul> <p>И в этот момент команду снова переводят в режим изменений, которые нарушают хрупкий баланс, выстроенный с большим трудом. При таком раскладе сопротивление — совершенно нормальная реакция.</p> <h3>Почему мидл-менеджмент может сопротивляться ИИ</h3> <p>Одна из ключевых причин — несовпадение ожиданий и реальности.</p> <p>Сегодня информационное поле устроено так, будто искусственный интеллект уже умеет практически все. Тут вам и агенты вместо сотрудников, и полноценная команда без живых разработчиков, и автоматизация всех-всех бизнес-процессов — не просто ИИ, а какой-то Брюс Всемогущий.</p> <p>В результате топ-менеджмент ожидает мгновенного эффекта, мидл — копит скепсис и ищет подтверждения того, что это не работает. Особенно если неудачные кейсы уже были: например, пилот оказался слишком дорогим или качество оказалось нестабильным.</p> <p>Внутри компаний это может привести к аллергии на любые ИИ-инициативы.</p> <p>Важно и то, чтобы руководитель верил в изменения. Мидл-менеджеру недостаточно просто стоять в стороне и не мешать, если компания решила внедрить искусственный интеллект: он должен стать драйвером новых процессов.</p> <p>На практике это означает:</p> <ul> <li> перестраивать работу команды;</li> <li> менять сценарии;</li> <li> вводить новые правила;</li> <li> переобучать сотрудников;</li> <li> контролировать результат.</li> </ul> <p>Без этого внедрение почти всегда останавливается на уровне пилота.</p> <h3>Что должен делать руководитель отдела</h3> <p>Успешное внедрение ИИ начинается не с выбора инструмента, а с ответов на несколько базовых вопросов.</p> <p>До запуска пилота руководителю важно определить:</p> <ul> <li> какой бизнес-показатель должен измениться;</li> <li>сколько времени, денег или ресурсов процесс требует сейчас;</li> <li> кто отвечает за итоговый результат;</li> <li> какие данные можно передавать в ИИ, а какие нельзя;</li> <li> какой бюджет компания готова потратить на эксперимент.</li> </ul> <p>После пилота появляются другие вопросы:</p> <ul> <li> изменился ли KPI;</li> <li> появился ли экономический эффект;</li> <li> куда направить высвобожденное время сотрудников;</li> <li> масштабировать решение, дорабатывать его или отключить.</li> </ul> <p>На практике именно здесь проходит граница между экспериментом и реальным внедрением. Если руководитель не понимает, что должно измениться после автоматизации, пилот почти гарантированно останется красивой демонстрацией возможностей технологии.</p> <h3>Теневой ИИ: самый опасный сценарий</h3> <p>Когда руководители процессов не вовлечены во внедрение искусственного интеллекта, сотрудники берут ситуацию в свои руки — и на сцену выходит теневой ИИ.</p> <p>Это значит, что команда сама покупает инструменты и использует открытые модели, загружает туда корпоративные данные, не заботясь о том, нарушает ли при этом NDA, и автоматизирует процессы. Но автоматизирует хаотично, как попало — и может генерировать при этом расходы, которые никто не контролирует.</p> <p>В результате компания перестает понимать сразу несколько вещей:</p> <ul> <li> где именно используется ИИ;</li> <li> какие данные попадают во внешние сервисы;</li> <li> сколько денег тратится на модели и токены;</li> <li> какой эффект дают эти расходы.</li> </ul> <p>Известны случаи, когда руководство выдавало доступ к новым инструментам без ограничений, а спустя несколько недель обнаруживало счета на тысячи долларов за использование моделей. При этом никто не мог ответить, какой бизнес-результат был получен за эти деньги.</p> <p>Именно поэтому без владельца ИИ не становится технологическим преимуществом бизнеса. Он просто сеет хаос. Использование системы должно быть управляемым и прозрачным.</p> <h3>Почему ИИ требует от руководителей новых навыков</h3> <p>Мидл-менеджеры умеют поддерживать процессы, мастерски управляют стабильностью, обеспечивают выполнение KPI — но в случае с ИИ этого уже недостаточно. Он требует другого типа управления: change management, или управления изменениями.</p> <p>То есть здесь важна способность экспериментировать, быстро пересобирать процессы, тестировать новые сценарии, адаптировать команду под новые инструменты. Нужно уметь работать в условиях неопределенности, а это не каждому по силам.</p> <p>Сейчас конкуренция компаний заключается не только в том, у кого «круче технология». Бизнесу важно и то, насколько быстро и легко мидл-менеджмент приспосабливается к переменам.</p> <h3>Итог: почему судьба внедрения решается именно на уровне мидл-менеджмента</h3> <p>На практике все упирается в простую вещь: эффективность компании складывается из эффективности отдельных подразделений.</p> <p>Не нужно быть «в десять раз лучше рынка». Достаточно, чтобы каждый отдел работал хоть на 10% эффективнее конкурентов — быстрее обрабатывал заявки, точнее работал с тендерами, дешевле привлекал лиды, быстрее выпускал продукт.</p> <p>ИИ — как раз инструмент такого усиления, и с его внедрением роль мидл-менеджмента меняется. Если раньше руководитель процесса в значительной степени выступал координатором и контролером исполнения, то теперь ему все чаще приходится становиться архитектором изменений. Понимать, какие задачи должны выполнять люди, какие можно передать ИИ, как измерять эффект и куда направлять высвобожденный ресурс.</p> <p>В конечном счете искусственный интеллект привел к тому, что мир меняется намного быстрее, и все больше компаний переходят к change management. Теперь недостаточно поддерживать привычный порядок вещей — нужно уметь перестраивать его под новые инструменты.</p> <p>#IMAGE_235053#</p> Компании продолжают массово внедрять искусственный интеллект. По данным Gartner, к 2028 году агентный ИИ будет … article Алексей Феофанов, директор по развитию бизнеса Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235048 Mon, 22 Jun 2026 13:51:28 +0300 <p>Российский рынок облачных сервисов продолжает расти, однако драйверы этого роста заметно меняются. Если еще несколько лет назад компании переходили в облако ради скорости запуска сервисов или отказа от части капитальных затрат, то сегодня ключевым фактором становится стремление бизнеса обеспечить предсказуемость развития ИТ-инфраструктуры в условиях роста стоимости оборудования и сохраняющейся неопределенности на рынке поставок, отмечают эксперты компании DataSpace Cloud.</p> <p>По оценкам компании, до конца 2026 года спрос на облачные решения продолжит увеличиваться. При этом меняется не только структура проектов, но и сама роль облака в ИТ-стратегиях компаний.</p> <h3> Тренд 1. Удорожание инфраструктуры меняет экономику ИТ-проектов</h3> <p>Одним из наиболее заметных событий на рынке в конце 2025 — начале 2026 года стало резкое подорожание оперативной памяти. По отдельным позициям рост цен достигал нескольких сотен процентов. Вслед за памятью выросли цены на серверы, системы хранения данных и другие элементы серверной инфраструктуры.</p> <p>В результате многие компании столкнулись с необходимостью пересматривать ранее утвержденные бюджеты и финансовые модели. Проекты, которые изначально предполагали закупку оборудования в собственность, все чаще трансформируются в сервисную модель потребления ресурсов через облако.</p> <h3>Тренд 2. На первый план выходит прогнозируемость</h3> <p>Дополнительное давление на инфраструктурные проекты продолжают оказывать сложности с поставками оборудования. Несмотря на адаптацию рынка к новым условиям, сроки поставок остаются значительными, а параллельный импорт не всегда позволяет гарантировать получение необходимого оборудования в требуемые сроки.</p> <p>В такой ситуации компаниям становится сложно планировать модернизацию инфраструктуры на несколько лет вперед. Облако позволяет снять значительную часть этих рисков, обеспечивая доступ к необходимым ресурсам без зависимости от закупочных циклов, логистики и наличия оборудования на рынке.</p> <h3>Тренд 3. Меняется подход к оценке эффективности облака</h3> <p>Одновременно меняются и критерии, по которым компании оценивают эффективность облачных сервисов.</p> <p>Сегодня высокий SLA, отказоустойчивая инфраструктура, сертифицированные дата-центры уровня Tier III, резервирование инженерных систем, возможности масштабирования и современные технологические стеки уже перестали быть факторами выбора. Для корпоративных заказчиков это базовая гигиена облачного провайдера. Именно поэтому критерии оценки смещаются из технологической плоскости в экономическую: компании анализируют влияние облака на CAPEX, скорость вывода новых сервисов на рынок (time-to-market), устойчивость бизнес-процессов и способность снижать инфраструктурные риски.</p> <p>В собственном контуре компаний остаются legacy-системы, проприетарные базы данных и критически важные приложения с жесткими требованиями к задержкам. В облако, напротив, переносятся веб-приложения, CRM, корпоративные сервисы, среды разработки и тестирования, аналитические платформы, AI/ML-нагрузки и системы обработки данных. </p> <p>«Облачная стратегия в 2026 году строится на прагматичном распределении нагрузок: большинство систем и данных мигрирует в облако, а в собственной инфраструктуре остается только то, что невозможно или нецелесообразно переносить. Аргумент „данные слишком чувствительны для облака“ утратил силу — провайдеры предлагают аттестованные контуры для персональных данных <nobr>(152-ФЗ),</nobr> сертифицированные платформы для банков (PCI DSS, ГОСТ <nobr>57580-1)</nobr> и отраслевые compliance-решения, что снимает регуляторные барьеры для миграции», — отметил Алексей Макаркин, директор по продукту DataSpace Cloud.</p> <p>По его мнению, до конца года рынок продолжит движение от модели владения инфраструктурой к модели потребления сервисов. </p> Российский рынок облачных сервисов продолжает расти, однако драйверы этого роста заметно меняются. Если еще несколько лет назад … message https://www.itweek.ru/themes/detail.php?ID=235047 Mon, 22 Jun 2026 13:50:33 +0300 <p>Холдинг «Росэл» Госкорпорации Ростех проапгрейдил коммерческую платформу виртуализации ECP VeiL, усилив ее киберустойчивость при помощи новых опций. Ранее такие механизмы защиты были доступны только в версии ECP VeiL SE для госкомпаний, ведомств и предприятий ОПК. Обновленная платформа в условиях роста уровня киберугроз позволит организовать цифровую защиту малому и среднему бизнесу.</p> <p>В ECP VeiL версии 5.3.0 внедрена доверенная загрузка виртуальных машин. Решение не позволяет запустить удаленное рабочее место, если его конфигурация, файлы или компоненты были изменены несанкционированно. Это защищает систему от запуска уязвимых или вредоносных компонентов. </p> <p>Обновленная платформа контролирует физические серверы. Она не позволяет изменять важные системные файлы и программную среду. При возникновении угрозы система может принудительно отключить всех пользователей. Также платформа централизованно проверяет запуск приложений и выполнение команд. Любые подозрительные действия автоматически блокируются. Снять блок и разрешить выполнение может только администратор.</p> <p>В новой версии также оптимизированы алгоритмы балансировки нагрузки. Теперь система переносит виртуальные машины с перегруженных узлов на свободные. Это обеспечивает стабильную работу сервисов в часы пик и более эффективное использование серверных мощностей. Кроме того, усилена отказоустойчивость — улучшен механизм переключения ролей контроллеров при авариях. Это снижает риски простоя и гарантирует непрерывность работы даже в нештатных ситуациях.</p> <p>Платформа VeiL — разработка научно-исследовательского института «Масштаб» (входит в «Росэл»).</p> <p>«Ранее механизмы доверенной загрузки виртуальных машин, контроля целостности узлов виртуализации и обеспечения защищенной программной среды были доступны только пользователям ECP VeiL SE. Среди них — госкомпании, ведомства, предприятия ОПК и другие организации, которые в силу закона должны соответствовать строгим требованиям регуляторов в сфере информационной безопасности. Однако сегодняшний уровень киберугроз настолько велик, что мы посчитали необходимым адаптировать наши решения и под коммерческую версию VeiL. Теперь представители малого и среднего бизнеса смогут построить в своих компаниях действительно доверенную виртуальную инфраструктуру», — прокомментировал генеральный директор НИИ «Масштаб» Антон Балицкий.</p> <p>ЕСР VeiL предназначена для создания виртуализованной инфраструктуры на базе универсальных серверных платформ с архитектурой х86-64. На виртуальных машинах ЕСР VeiL могут функционировать практически все распространенные бизнес-приложения, включая межсетевые экраны, маршрутизаторы, IP-АТС, почтовые и прокси-серверы, корпоративные порталы, веб-сайты, ERP, CRM и системы документооборота.</p> Холдинг «Росэл» Госкорпорации Ростех проапгрейдил коммерческую платформу виртуализации ECP VeiL, усилив ее киберустойчивость … message https://www.itweek.ru/themes/detail.php?ID=235046 Mon, 22 Jun 2026 09:32:36 +0300 <p><em>По мере того, как кодирование с помощью искусственного интеллекта переходит от промптов к циклам, верификация становится главной задачей для нативно-облачных команд разработчиков, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Арджун Айер, генеральный директор Signadot.</em></p> <p>Недавно в дискуссии об ИИ-кодировании произошли перемены. Спор больше не о том, могут ли агенты писать производственный код или какая модель лучше. Он теперь о том, кто или что должен им подсказывать.</p> <p>Теперь на слуху идея «проектировать циклы, которые выдают промпты вашим агентам». Становится ясно: формируется третья эра агентной разработки, и она поднимает важные вопросы о том, что делают инженеры, каковы затраты на доставку ПО и какая инфраструктура должна ее обеспечивать.</p> <p>Для команд, создающих нативно-облачные приложения на Kubernetes, ответы на эти три вопроса вскоре будут иметь огромное значение.</p> <h3>Три эры, одно направление</h3> <p>Агентная разработка на каждом этапе эволюции продвигает человека на один уровень абстракции вверх.</p> <p>Первая эпоха была ориентирована на промпты. Разработчик находился внутри цикла, набирая инструкции, читая вывод, внося исправления. Пропускная способность ограничивалась вниманием одного разработчика.</p> <p>Вторая эпоха ориентирована на спецификации, и именно на этом этапе сегодня находится большинство команд, внедряющих подобные подходы. Разработчик инвестирует на начальном этапе: подробные спецификации, контекстные документы, соглашения, закодированные в репозитории. Агент выполняет действия в соответствии со спецификацией, а человек проверяет выполненную работу. Единица работы выросла из промпта в задачу.</p> <p>Третья эпоха делает сам цикл единицей работы. Цикл — это небольшая программа, которая выдает агенту промпт, оценивает ответ, решает, достигнута ли цель, и, если нет, снова выдает промпт, используя полученные данные. Она работает по расписанию, а не зависит от внимания человека. Циклы запускают другие циклы.</p> <p>Разработчик больше не пишет код и все чаще не пишет задачи. Он пишет систему, которая генерирует, оценивает и повторяет работу.</p> <p>Скептики называют это «cron job (индивидуальное задание, которое выполняется согласно заданному расписанию) с улучшенным маркетингом», и это сравнение полезно для понимания того, где здесь возникают проблемы. Cron job выполняет фиксированный скрипт. В цикле же присутствует лицо, принимающее решения: модель, которая считывает состояние работы и выбирает следующее действие. Инженерная задача состоит в том, чтобы всё, что окружает это решение, сходилось к правильному результату, а не блуждало.</p> <h3>Кем становится разработчик</h3> <p>В мире, управляемом промптами, сила разработчика заключалась в умении управлять процессом. В мире, управляемом спецификациями, она заключается в ясности намерений.</p> <p>В мире, управляемом циклами, сила — в качестве системы, окружающей агента. Важный инженерный вопрос сводится к следующему: что проверяет этот цикл, прежде чем объявить об успехе? Какую обратную связь он получает при сбое? Когда он останавливается?</p> <p>Эти вопросы разделяют инженерную роль на две части. Разработчики приложений становятся авторами намерений и циклов: они решают, что создавать, и кодируют цель. Платформенные инженеры становятся владельцами того, что означает «сделано».</p> <p>Проверки, выполняемые циклом, среды, в которых он выполняется, бюджет, в рамках которого он работает, и доказательства, прилагаемые к его результатам, — все это должно быть согласовано во всех циклах в организации, а не импровизироваться каждым из них.</p> <p>Это знакомая схема, но с новой темой. Десять лет назад платформенные команды превратили CI/CD из чего-то, что каждая команда создавала на скорую руку, в мощеную дорогу. Уровень верификации для агентных циклов — это тот же переход, за исключением того, что он находится во внутреннем цикле, до появления каких-либо запросов на изменения (PR), независимо от параллелизма, который генерируют циклы.</p> <h3>Экономика: циклы сходятся или сгорают</h3> <p>Заманчиво предположить, что агенты сделали генерацию кода дешевой, поэтому все это не имеет значения. Это не совсем так.</p> <p>Благодаря агентам генерация стала быстрой и дешевле, чем затраты на рабочее время разработчиков, но токены — это реальная и растущая статья расходов. Работа агента в течение нескольких часов — это решение о расходах, а цикл — это бесконечная работа агента по задумке. Бюджеты, сохранившиеся после интерактивных сессий, не обязательно сохранятся после циклов.</p> <p>Первоочередная мера реагирования — это ограничители: лимиты итераций, обнаружение отсутствия прогресса и потолки затрат. Они необходимы, но они только ограничивают ущерб от неэффективного цикла. Они не делают его эффективным.</p> <p>Эффективность цикла сводится к двум измерениям, и они перемножаются.</p> <p>Первое — это качество обратной связи, которое определяет, сколько итераций требуется циклу. Цикл, получающий нечеткий сигнал об ошибке, пытается угадать причину и делает это снова. Цикл, получающий реальную ошибку от реальной системы с достаточным контекстом для локализации причины, исправляет фактическую проблему и переходит к следующему шагу. Качество обратной связи также определяет то, насколько правильным может быть цикл: он может сходиться только к тому, что видит его обратная связь.</p> <p>Второе — это момент завершения цикла, который определяет стоимость каждой итерации. Если цикл завершается в CI или после PR, каждый цикл оплачивает выполнение конвейера плюс время ожидания в очереди, а частота выполнения составляет от минут до часов. Если же завершение происходит во внутреннем цикле, то при условии прямого доступа агента к среде выполнения частота составляет секунды.</p> <p>Общая стоимость цикла — это произведение: количество итераций до проверки, умноженное на стоимость одной итерации.</p> <p>Эти измерения также подпитывают друг друга. Если передавать достоверную обратную связь в CI, каждый цикл замедляется, пока агент обрабатывает частичные сигналы между ними. Если же включить её во внутренний цикл, то оба параметра сжимаются одновременно.</p> <h3>Нативные облачные системы поднимают планку качества «сделано»</h3> <p>Для изолированной программы оба измерения практически бесплатны. Набор тестов выполняется локально за секунды и сообщает всю правду, потому что вся правда локальна.</p> <p>В распределенной системе правда не локальна. Изменение считается правильным или неправильным в зависимости от того, как оно взаимодействует с вызываемыми им сервисами, хранилищами данных и очередями, которые оно затрагивает, а также уровнями маршрутизации и политик, под которыми оно работает.</p> <p>Обратная связь, которую агент может получить быстро, — локальные тесты и заглушки — является частичной. Обратная связь, которая сообщает правду, традиционно находится в CI и общей среде тестирования, где циклы медленные и конфликтные. Нативно-облачные команды вынуждены выбирать между быстрым циклом, который сходится к неправильной цели, и циклом, содержащим достоверную информацию, который итерируется со скоростью конвейера.</p> <p>Традиционные варианты окружения неэффективны в масштабе агентов. Здесь важно следующее: в нативно-облачных системах обратная связь цикла должна поступать из среды выполнения, и эта среда должна быть доступна из внутреннего цикла. Архитектура нативно-облачного агентного цикла — это, по большей части, архитектура поверхности проверки, которую вы ему предоставляете.</p> <h3>Четыре уровня нативно-облачного агентного цикла</h3> <p>Полная система имеет четыре уровня. Сам цикл — это самая маленькая часть.</p> <p><strong>Уровень среды выполнения.</strong> Циклу требуется среда для каждой итерации, которая ведет себя как производственная среда, но не требует таких же затрат. Решение — легковесные временные среды на общем кластере: развертывайте только те сервисы, которые затрагиваются изменением, и используйте маршрутизацию запросов на одном общем кластере, чтобы направлять трафик цикла через них и через общую базовую конфигурацию для всего остального.</p> <p>Среды материализуются за секунды, предельные затраты отслеживают измененные поды, а не весь стек, и обратная связь поступает из реальных зависимостей и реальных путей передачи данных. Именно это приводит к завершению цикла во внутренний цикл.</p> <p><strong>Интерфейс проверки.</strong> Агенты не просматривают панели мониторинга и не должны придумывать собственное определение завершения. Проверки, которые должно пройти изменение, должны быть частью декларативных рабочих процессов, которые платформенные команды определяют, версионируют и предоставляют агентам в качестве утвержденного способа подтверждения изменения.</p> <p>Организация, а не агент, решает, что означает «прохождение». Доказательства, связанные с изменением, поступают из процесса, который могут проверять люди, и человеческая проверка может сосредоточиться на намерениях и дизайне.</p> <p><strong>Слой обратной связи.</strong> Это механизм сходимости. Бит «пройдено» или «не пройдено» указывает циклу на необходимость повторной попытки, но не на то, что нужно изменить. Среда выполнения должна возвращать структурированные результаты: какая проверка не удалась, журналы и трассировки, относящиеся к собственным запросам цикла, разница в поведении на границе, которая нарушилась.</p> <p>Каждое увеличение точности обратной связи исключает догадки, а устранение догадок означает устранение затрат.</p> <p><strong>Слой управления.</strong> Бюджеты, потолки итераций, обнаружение отсутствия прогресса и надежная запись того, что было выполнено и доказано в каждом цикле. Это то, что позволяет организации уверенно выполнять множество циклов вместо одного, вызывающего беспокойство.</p> <p>Когда расходы ограничены, а сходимость измеряется, агентная разработка становится возможностью, которую можно планировать, а не неожиданной статьей расходов.</p> <p>«Пишите циклы, а не промпты» — это видимая вершина более масштабного заявления: теперь сила команды заключается в системе проверки, которую используют циклы, а эта система принадлежит организации, предоставляющей платформу.</p> <h3>С чего начать?</h3> <p>Переход к разработке на основе циклов не произойдет в результате какого-то одного решения. Он произойдет в результате сравнения эксперимента одной команды, который быстро сходится, и эксперимента другой, который сжигает квартальный бюджет, создавая изменения, которым никто не доверяет. Разница будет заключаться в четырех уровнях, а не в продуманности циклов.</p> <p>Нативно-облачным командам следует начать с уровня среды выполнения, потому что от него зависит каждый другой уровень. Рабочие процессы верификации имеют смысл только в той мере, в какой и среда, в которой они выполняются, а обратная связь правдива только в той мере, в какой правдива система, которая ее генерирует.</p> <p>Если ваши агенты пишут код быстрее, чем ваша команда может ему доверять, цикл наверняка подскажет вам, какого слоя не хватает.</p> По мере того, как кодирование с помощью искусственного интеллекта переходит от промптов к циклам, верификация … article https://www.itweek.ru/themes/detail.php?ID=235044 Mon, 22 Jun 2026 09:06:30 +0300 <p><em>В современном мире многие чат-боты или голосовые помощники могут не только проконсультировать по какому-то вопросу, но и полноценно записать на прием, вызвать врача на дом или отменить визит. Все это возможно благодаря интеграции с информационной системой. Главная задача интеграции — скрыть внутреннюю сложность </em><em>предметной области</em><em> и выдать сценарию уже готовые, «чистые» данные. Если инженеру или аналитику приходится самому разбирать технические ошибки или сложные форматы, такая интеграция считается слабой и ненадежной.</em> <em>Давайте рассмотрим всё на примере медицинской информационной системы (МИС).</em></p> <h2>Техническая сторона: какими способами программы «общаются» между собой</h2> <p>Выбор способа обмена данными API (Application Programming Interface) — SOAP (Simple Object Access Protocol) или REST (Representational State Transfer) — определяет логику взаимодействия систем. В медицинской среде оба подхода имеют свои области применения, и понимание их специфики важно для создания надежных интерфейсов.</p> <p>Пример использования API в жизни:</p> <ul> <li> <strong>Оплата картой:</strong> сайт использует API банка для проведения платежа.</li> <li><strong>Карты на сайтах:</strong> интеграция карт Google или «Яндекса» на сторонних сайтах.</li> <li><strong>Войти через Google/VK: </strong>использование учетных данных одной системы на другой.</li> </ul> <p>Определение REST и SOAP:</p> <p><strong>REST (Representational State Transfer)</strong> — это архитектурный стиль взаимодействия компонентов распределенных приложений в сети, обычно использующий протокол HTTP (HyperText Transfer Protocol). Он определяет набор правил для обмена данными между клиентом и сервером (например, мобильным приложением и сервером), обеспечивая стандартизированный, гибкий и масштабируемый способ взаимодействия.</p> <p><strong>SOAP (Simple Object Access Protocol)</strong> — это строгий протокол обмена структурированными сообщениями в формате XML (eXtensible Markup Language), используемый для взаимодействия приложений. Он обеспечивает высокую безопасность и надежность, часто применяется в банковских системах и корпоративных сервисах (API), работая поверх HTTP, HTTPS (HyperText Transfer Protocol Secure), SMTP (Simple Mail Transfer Protocol) и других протоколов.</p> <p>Для простого понимания можно использовать аналогии из жизни:</p> <ul> <li> SOAP — это официальное заказное письмо в плотном конверте с кучей печатей и подписей. Чтобы его прочитать и подтвердить получение, нужно соблюсти множество формальностей, что делает процесс медленным и тяжелым.</li> <li> REST — это быстрая записка, СМС или почтовая открытка. Она короткая, легкая и содержит только самую суть, поэтому передается мгновенно.</li> </ul> <p>Давайте сравним оба метода:</p> <table> <tbody> <tr> <th> Параметр сравнения</th> <th> Протокол SOAP (тяжелый)</th> <th> Архитектура REST (легкий)</th> </tr> <tr> <td> <strong>Формат обмена</strong></td> <td> Только сложный код XML</td> <td> Обычно легкий код JSON (JavaScript Object Notation)</td> </tr> <tr> <td> <strong>Гибкость</strong></td> <td> Жесткие правила и структура </td> <td> Высокая, легко адаптировать под нужды </td> </tr> <tr> <td> <strong>Скорость</strong></td> <td> Ниже из-за объема данных </td> <td> Выше за счет компактности</td> </tr> <tr> <td> <strong>Безопасность</strong></td> <td> Высокая, на уровне сообщения</td> <td> На уровне канала связи (стандарт интернета)</td> </tr> </tbody> </table> <h2>API: что такое «хорошо» и что такое «плохо»</h2> <p>Логика работы любого виртуального помощника в медицине обычно состоит из трех этапов: выбор услуги, идентификация пациента и получение услуги (запись или вызов врача на дом). То, как технически реализованы эти этапы, определяет, будет ли сервис полезен людям.</p> <h3>Чего стоит избегать</h3> <p><strong>«</strong>Плохая» интеграция перекладывает технические проблемы системы на плечи инженера. Это делает сервис нестабильным и сложным в поддержке.</p> <ul> <li> <strong>Низкоуровневые вызовы на этапе выбора услуги</strong><strong>:</strong> когда для одного простого действия боту нужно вызвать десять разных методов. Логика при этом запутывается. При такой долгой загрузке человек чаще всего просто кладет трубку, не дождавшись ответа. Исследования показывают, что если ожидание превышает 5 секунд, большинство пользователей прекращают общение.</li> <li> <strong>Сложные форматы данных:</strong> получение данных в виде «матрешки» (один код внутри другого). Сценарий не должен заниматься очисткой служебных таблиц с описанием типов и технического шума. Работа с такими данными заметно снижает долю успешно завершенных заявок.</li> <li> <strong>Сырые данные при идентификации:</strong> передача пустых полей или дат в техническом формате. Если процесс подтверждения личности затягивается из-за технических заминок, вероятность того, что человек завершит звонок, вырастает в разы.</li> <li><strong>Чрезмерная сложность для </strong><strong>медучреждения</strong><strong>:</strong> иногда системы настолько запутаны, что сами медучреждения не понимают, как правильно заводить в них врачей или услуги. Это ведет к тому, что в справочниках появляются дубли и ошибки, которые не должны исправляться в сценарии робота.</li> </ul> <h3>К чему нужно стремиться</h3> <p><strong>«</strong>Хорошая» интеграция работает по принципу «одной кнопки»: сценарий просит выполнить действие и получает понятный результат. Это позволяет почти каждому обратившемуся успешно получить услугу.</p> <ul> <li> <strong>Умный выбор услуги через параметры:</strong> сервис будет работать гораздо лучше, если вместо цепочки из десяти запросов использовать получение информации через несколько запросов с четкими параметрами.<br/> Пример<em>:</em> вместо того чтобы сначала просить список всех специальностей, потом всех врачей, а потом все даты, лучше использовать метод «Получить свободные слоты», передав в него сразу код специальности и нужный диапазон дат. Это сокращает время ожидания, и человек не бросает трубку. </li> <li> <strong>Надежная идентификация:</strong> система должна позволять быстро и однозначно подтвердить личность пациента. Чаще всего это происходит тремя способами: по ФИО и дате рождения, по номеру СНИЛС или по номеру полиса ОМС. Качественная интеграция позволяет боту мгновенно сверить эти данные с базой.</li> <li><strong>Понятные ответы:</strong> на этапе получения услуги система возвращает статус: «Пациент не найден», «Найдено несколько совпадений», «Запись успешно создана». Такие сценарии работают гораздо эффективнее других.</li> <li><strong>Автоматизация рутины:</strong> система сама приводит даты к нужному виду и проверяет обязательные поля.</li> </ul> <h2>Что делать, если в системе не хватает данных</h2> <p>Одной из наиболее коварных ловушек при интеграции является интерпретация отсутствующих данных. Поля в МИС могут быть не заполнены по историческим причинам или из-за особенностей работы конкретного отделения.</p> <p>Интеграционная часть должна выступать в роли «умного фильтра», который оценивает достоверность информации. Например, если для оформления вызова врача на дом требуется адрес, а система возвращает пустую строку, качественный интегратор действует так:</p> <ol> <li><strong>Ищет альтернативы:</strong> пытается получить адрес из истории предыдущих вызовов пациента у себя внутри.</li> <li><strong>Оценивает важность:</strong> проверяет, является ли это поле критическим для данного действия.</li> <li><strong>Запрашивает уточнение:</strong> если данные необходимы, система передает в код информацию чтобы в дальнейшем уточнить ее у пациента.</li> </ol> <p>Такой подход делает работу виртуального помощника надежной. Инженер по интеграции знает: если данные получены, они проверены, а если их нет это реальное отсутствие информации в базе, а не ошибка связи.</p> <h2>Путь пациента: стресс против комфорта</h2> <p>То, как медучреждение настроило методы и справочники в своей системе, напрямую влияет на то, получит ли человек пользу от сервиса.</p> <p><strong>Вариант «</strong><strong>с</strong><strong>тресс».</strong> Организация использует множество мелких методов, а данные в системе заполнены с ошибками (дубли врачей, пустые адреса). Человек хочет записаться, но робот делает <nobr>10-15</nobr> последовательных запросов, после каждого вопроса наступает долгая пауза. При длительной задержке ответа человек просто <strong>кладет трубку</strong>. В итоге бот предлагает время, которое уже занято. Человек остается без записи и разочаровывается в сервисе.</p> <ul> <li> <strong>Для инженера</strong> такая работа превращается в бесконечное «латание дыр» и ручную чистку данных. До <nobr>60-80%</nobr> времени тратится не на развитие сервиса, а на исправление ошибок и попытки понять, почему цепочка запросов оборвалась.</li> <li><strong>Итог:</strong> проект обрастает техническим долгом, становится очень дорогим в обслуживании, а любые изменения в МИС приводят к полной остановке сервиса.</li> </ul> <p><strong>Вариант «</strong><strong>к</strong><strong>омфорт».</strong> Организация настроила получение информации посредством нескольких запросов с параметрами.</p> <ul> <li><strong>Выбор услуги</strong><strong>.</strong> Человек говорит: «Запиши к терапевту на завтра». Система мгновенно находит доступные варианты.</li> <li><strong>Идентификация</strong><strong>.</strong> Робот быстро находит пациента по ФИО, СНИЛС или ОМС.</li> <li><strong>Получение услуги</strong><strong>.</strong> Бот предлагает время: «Есть на 10:00 и 11:30. Какое выбрать?». После ответа запись подтверждается мгновенно. Человек быстро и четко записывается к врачу, он доволен, а медицинская организация получила запись без лишних усилий персонала. В медицине такая скорость работы значительно увеличивает количество реальных визитов граждан к врачам.</li> <li> <strong>Инженер</strong> в такой системе работает с готовыми и надежными блоками данных. Это позволяет внедрять новые функции (например, автоматические опросы о качестве обслуживания) за считанные часы, а не недели.</li> <li><strong>Итог:</strong> создается масштабируемая система с низкими затратами на поддержку, которая стабильно работает и легко растет вместе с потребностями организации.</li> </ul> <h2>Итог правильной интеграции</h2> <p>Сценарий должен работать с понятными человеческими понятиями (врач, время, пациент), а не с техническими деталями базы данных. Качественная интеграция и порядок в данных заказчика это залог того, что ваш сервис будет приносить реальную пользу, а люди будут доверять виртуальным помощникам.</p> <p>И при правильной (хорошей) интеграции конверсия сервисов, например «запись на прием к врачу» или «вызов врача на дом», будет превышать 70%, при «плохой» будет втрое меньше.</p> <p> #IMAGE_235045#</p> В современном мире многие чат-боты или голосовые помощники могут не только проконсультировать по какому-то … article Михаил Гончарук, руководитель проектов департамента голосовых цифровых технологий компании BSS