<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
<title>itWeek</title>
<link>https://www.itweek.ru</link>
<description>itWeek</description>
<language>ru</language>
<item>
<title><![CDATA[Когда сотрудники находят ответ сами: как ИИ гид-помощник в SimpleOne ITSM разгружает поддержку и бюджет]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235506]]></link>
<description><![CDATA[Портал самообслуживания давно стал привычным элементом корпоративной поддержки. Однако это ещё не означает, что сотрудники будут пользоваться порталом, и что нагрузка на первую линию снизится. В этой статье — о том, как решить проблему портала самообслуживания с помощью ИИ-помощника, который позволит пользователю общаться с системой на своём языке, на примере ИИ гида-помощника в SimpleOne ITSM. Также в материале приводим расчет, сколько можно сэкономить ресурсов бизнеса с помощью ИИ-оптимизации обработки обращений. Рассказывает Андрей Вишняков, директор по бизнес-продуктам SimpleOne, корпорация ITG, ITIL 4 Master, ITIL 3 Expert, Practitioner, автор РИТМ. Почему первая линия загружена, даже когда есть портал Последние десять лет компании инвестировали в самообслуживание: проектировали каталоги услуг, создавали формы типовых запросов, наполняли базы знаний, публиковали объявления о плановых и аварийных работах. Цель была очевидной — дать сотрудникам возможность решать типовые вопросы самостоятельно, а первую линию поддержки освободить для действительно сложных случаев. На практике портал часто не становится привычной точкой входа. Сотрудник открывает каталог и видит десятки или сотни карточек с названиями вроде «Предоставление прав доступа к информационным ресурсам» или «Выдача прав для пользователей». Чтобы получить доступ к отчётам, ему нужно сначала понять внутреннюю логику ИТ-службы: какая услуга подходит, чем отличаются похожие формы, какие поля обязательны и почему. Проще написать в почту, мессенджер или создать обращение свободным текстом: «Не открывается отчёт, помогите». «У большинства крупных компаний порталы самообслуживания уже есть, но с точки зрения пользователя порталы и каталоги услуг неудобные, перегруженные и запутанные. Пользователи предпочитают позвонить, написать письмо или оставить обращение в свободной форме, потому что это быстрее, чем разбираться в большом количестве типовых запросов с непонятными названиями. Портал есть, но он не работает так, как задумывалось», — Андрей Вишняков, директор по бизнес-продуктам SimpleOne, корпорация ITG, ITIL 4 Master, ITIL 3 Expert, ITIL Practitioner В итоге первую линию превращают в ручной маршрутизатор. Агенту приходится расшифровывать описание, выяснять детали, переводить обращение в корректный тип запроса и передавать его исполнителю. Профильный специалист получает неполную заявку и запрашивает дополнительные данные. В результате пользователю приходится ждать, агентам службы сервис-деск — выполнять однотипную работу, а бизнесу — тратить ресурсы на обработку обращений, которые могли бы не попасть в поддержку вовсе. О том, как решить проблему порталов самообслуживания, — в полной версии аналитического обзора. Что меняется Раньше проблему навигации по порталу пытались решить через чат-ботов, но они работали только по жёстким сценариям. Пользователь должен был выбрать правильную ветку, сформулировать запрос ожидаемым образом и последовательно отвечать на вопросы. Стоило отклониться от сценария — например, написать «не открывается отчёт» вместо «не работает корпоративная система отчётности», — и бот переставал быть полезным. Технология искусственного интеллекта заставила чат-ботов потерять актуальность. Согласно официальному прогнозу Gartner, развитие агентного ИИ приведет к тому, что к 2029 году системы смогут автономно разрешать до 80% всех рутинных пользовательских обращений без вмешательства человека. Например, когда на портале есть ИИ-помощник, пользователь описывает задачу так, как привык: «мне нужен доступ к отчётам», «не работает почта», «как настроить VPN». Помощник понимает смысл запроса, учитывает контекст диалога и ищет релевантную информацию в данных, которые уже есть в системе: каталоге услуг, моделях типовых запросов, статьях базы знаний, объявлениях и известных ошибках. Если вопрос можно закрыть без обращения, помощник покажет подходящую статью, объявление или обходное решение. Если пользователю нужна услуга, он найдёт соответствующую модель запроса, уточнит необходимые данные и подготовит форму с уже заполненными полями. Если речь идёт о нарушении работы сервиса, помощник поможет оформить инцидент и передать специалистам контекст без дополнительных итераций. Техническую основу такого подхода составляет технология RAG (Retrieval-Augmented Generation, генерация с дополненной выборкой). Сначала система находит в корпоративных источниках материалы, близкие по смыслу к вопросу пользователя. Затем генеративная модель использует найденные данные, чтобы сформировать понятный ответ или предложить следующее действие. Поэтому помощник не заменяет настроенные процессы и базу знаний, а делает их доступными для человека, который не знает внутренней структуры портала. #IMAGE_235509# Для этого не нужно вручную обрабатывать каждый документ или менять существующую модель данных. Для каталога услуг, статей, объявлений и известных ошибок настраиваются векторные коллекции: в них попадают поля, по которым помощник должен искать информацию. После настройки новые и изменённые записи обновляются автоматически с заданной периодичностью. При этом важно определить, какие данные попадут в поиск и по каким условиям, например, включать опубликованные и актуальные объявления, а архивные — исключать. Так качество ответа зависит не только от модели, но и от актуальности и структуры корпоративных знаний. Организационный и экономический эффект Для сотрудника ИИ-помощник сокращает путь от вопроса до результата. Не нужно искать нужную карточку в каталоге, разбираться в терминологии или вручную заполнять форму. Достаточно описать ситуацию своими словами, а помощник найдёт ответ, предложит обходное решение либо подготовит обращение. В типовом сценарии пользователь получает нужную информацию или корректную форму за 30–60 секунд, а число повторных обращений снижается. У первой линии будет меньше ручной работы: типовые обращения либо не будут создаваться совсем, либо будут поступать уже классифицированными, с заполненными полями и контекстом. Агенты не тратят время на расшифровку свободного текста, уточнения и переоформление заявок, и могут сосредоточиться на инцидентах, где действительно требуется экспертиза. Профильные специалисты при этом будут получать запросы, в которых уже есть обязательные данные. Это повышает долю решений с первого обращения (First Call Resolution) и снижает риск выгорания команды. Для финансового расчета возьмем перспективу по уменьшению количества обращений — по упомянутому выше прогнозу Gartner агентный ИИ будет автономно решать 80% типовых обращений в клиентской поддержке. Чтобы не завышать эффект, особенно в вопросе обслуживания внутренних клиентов, возьмем более сдержанную цифру в 20%. По данным глобального ИТ-бенчмаркинга (MetricNet, HDI), средняя стоимость обработки одного обращения на первой линии постоянно растет из-за удорожания ручного труда. В российских реалиях при расчете через фонд оплаты труда (ФОТ), налоги и накладные расходы базовая стоимость одного рутинного тикета варьируется от 240 до 480 рублей. Рассчитаем экономику прямым методом: годовой ФОТ отдела поддержки, поделенный на годовой объем запросов: 	 		 			 Параметр 			 Малый объем 			 Средний объем 			 Большой объем 		 		 			 Обращений в год 			 50 000 			 150 000 			 300 000 		 		 			 Агентов 1-й линии 			 10 			 20 			 35 		 		 			 ФОТ в год* 			 9 600 000 руб. 			 19 200 000 руб. 			 33 600 000 руб. 		 		 			 Стоимость одного обращения 			 320 руб. 			 ~274 руб. 			 ~258 руб. 		 		 			 Предотвращенных обращений (20%) 			 10 000 			 30 000 			 60 000 		 		 			 Прямая экономия 			 3 200 000 руб./год 			 8 220 000 руб./год 			 15 480 000 руб./год 		 	 * ФОТ в примерах рассчитан из зарплаты агента 80 000 руб./мес с учетом налогов и накладных расходов. Эффект масштаба на средних и больших объемах снижает удельную стоимость запроса, но совокупная экономия кратно возрастает. Помимо прямой экономии от не созданных заявок, имеет место и второй важный экономический фактор — сокращение времени обработки. За счет устранения итераций на сбор контекста и уточнение деталей время реакции и обработки тикетов может сократиться более чем на треть. Это дополнительно высвобождает дорогие часы узкопрофильных специалистов. При этом стоимость часа второй и особенно третьей линии поддержки в разы выше, чем первой. Поэтому эффект от сокращения итераций накапливается, и экономия происходит не только на объёме заявок, но и на самых дорогих часах в структуре поддержки, и итоговая оптимизация расходов оказывается выше, чем сумма отдельных факторов. В результате бизнес получает измеримый эффект: 	 Сокращение затрат на постоянный найм и обучение новых агентов первой линии. 	 Высвобождение ИТ-бюджета: средства направляются на развитие услуг, а не на расширение штата. 	 Рост операционной эффективности: кратно большее количество обращений обрабатывается меньшими силами. При этом, когда портал самообслуживания становится по-настоящему эффективным и окупаемым в ИТ, бизнес может масштабировать эту же практику на другие подразделения: HR, АХО, бухгалтерию, юридический отдел. В логике Enterprise Service Management (ESM) это создает единый консистентный опыт для сотрудников: к какому бы подразделению ни относилась услуга, механизм ее получения одинаков — достаточно просто описать свою потребность на естественном языке. Оцените оптимизацию на ваших задачах — на демонстрации с помощью специального калькулятор посчитаем эффект экономии для трёх линий поддержки при внедрении ИИ-помощника. Оставьте заявку на сайте. Что умеет ИИ-гид в SimpleOne ITSM ИИ гид-помощник в SimpleOne ITSM не заменяет каталог услуг, базу знаний или привычные формы, а, скорее, становится единой точкой входа в эти ресурсы. Находит услугу и готовит запрос Пользователь пишет: «Мне нужен доступ к отчётам по продажам». Ему не нужно знать, как услуга называется в каталоге и чем она отличается от похожих карточек. ИИ-гид распознаёт, что речь идёт о запросе на обслуживание, находит подходящую модель типового запроса и задаёт только нужные уточняющие вопросы — например, о срочности и ссылке на нужный раздел портала. Затем помощник формирует ссылку на обращение с предзаполненными полями. Пользователю остаётся проверить данные, при необходимости дополнить описание и отправить запрос. Он сразу поступает профильному исполнителю с необходимым контекстом. #IMAGE_235510# Показывает обходное решение Если ситуация уже известна поставщику услуг, не всегда нужен новый инцидент. Пользователь описывает проблему в чате, а ИИ-гид сопоставляет её с записями в базе известных ошибок (KEDB). Если в карточке есть обходное решение, помощник показывает его прямо в диалоге. Пользователь быстрее восстанавливает работу, а команда поддержки не получает повторяющиеся обращения по одной и той же проблеме. #IMAGE_235511# Предупреждает о работах Представим, что сотрудник пишет: «Не работает корпоративная почта». Вместо регистрации инцидента ИИ-гид может найти опубликованное объявление о временной недоступности почтовой службы и показать его в чате. Пользователь видит, что причина уже известна, работы ведутся, а отдельное обращение создавать не требуется. #IMAGE_235512# Отвечает по базе знаний Не каждый вопрос требует участия специалиста. Например, сотрудник хочет настроить рабочий инструмент, но не знает, где искать инструкцию. ИИ-гид находит подходящую статью базы знаний, формирует короткий ответ в чате и при необходимости предлагает перейти к полному материалу. Так база знаний перестаёт быть архивом, который пользователь должен самостоятельно просматривать по ключевым словам. Она становится источником ответа в момент, когда он нужен. #IMAGE_235513# При этом в SimpleOne новые и обновлённые записи не нужно вручную заново загружать для каждой консультации: после настройки коллекций они синхронизируются автоматически с заданной периодичностью. Однако владельцам базы знаний и каталога услуг важно поддерживать материалы в актуальном состоянии — помощник работает с тем корпоративным контекстом, который ему доступен. Помогает оформить инцидент Если помощник не нашёл известную ошибку, актуальное объявление или подходящее решение в базе знаний, он определяет, что нужно зарегистрировать инцидент. Затем уточняет детали, которые понадобятся специалисту: например, срочность и описание условий, при которых возникла проблема. В результате пользователь получает форму с предзаполненными данными, а Service Desk — обращение с контекстом. #IMAGE_235514# Как масштабировать ИИ-помощника на другие отделы ИИ-гид работает не с ИТ-терминами, а со смыслом запроса и корпоративными данными. Поэтому после отладки сценариев на сервисном портале ITSM тот же подход можно использовать в других подразделениях — в логике Enterprise Service Management. Например, сотрудник может написать: «Нужна справка 2-НДФЛ» или «Хочу оформить отпуск» — помощник найдёт нужную услугу HR, уточнит необходимые данные и подготовит форму обращения. В бухгалтерии он подскажет, как оформить авансовый отчёт, найдёт инструкцию по возмещению расходов или направит запрос на нужную услугу. В юридическом отделе — поможет найти шаблон договора, правила согласования или зарегистрировать запрос на проверку документа. Для сотрудника путь остаётся одинаковым: описать потребность обычными словами. А для сервисных подразделений сохраняются их собственные процессы, каталог услуг, база знаний и маршрутизация. Помощник не унифицирует работу HR, бухгалтерии и юристов под ИТ-процессы — он делает их сервисы понятнее и доступнее, становясь единым интерфейсом между сотрудником и внутренними функциями компании. Резюме Портал самообслуживания долго оставался витриной внутренних услуг, где сотрудник сам находит нужное. С появлением ИИ меняется логика взаимодействия. Портал перестаёт требовать навигации и начинает вести диалог — принимать задачу в той формулировке, в которой она возникает у человека. Для компаний это повод пересмотреть не только интерфейс поддержки, но и качество сервисных знаний. Чем точнее описаны услуги, чем актуальнее статьи и объявления, тем полезнее становится помощник. Поэтому его внедрение — не разовая автоматизация, а практический способ сделать накопленные процессы и знания реально доступными сотрудникам. Чтобы увидеть, как работает ИИ гид-помощник, запросите демонстрацию SimpleOne ITSM на сайте SimpleOne]]></description>
<source><![CDATA[&lltt;p&ggtt;Портал самообслуживания давно стал привычным элементом корпоративной поддержки. Однако это ещё не&nbsp;означает, что сотрудники будут пользоваться порталом, и&nbsp;что нагрузка на&nbsp;первую линию снизится. В&nbsp;этой статье&nbsp;— о&nbsp;том, как решить проблему портала самообслуживания с&nbsp;помощью ИИ-помощника, который позволит пользователю общаться с&nbsp;системой на&nbsp;своём языке, на&nbsp;примере&nbsp;ИИ гида-помощника в&nbsp;SimpleOne ITSM. Также в&nbsp;материале приводим расчет, сколько можно сэкономить ресурсов бизнеса с&nbsp;помощью ИИ-оптимизации обработки обращений. Рассказывает Андрей Вишняков, директор по&nbsp;бизнес-продуктам SimpleOne, корпорация ITG, ITIL 4&nbsp;Master, ITIL 3&nbsp;Expert, Practitioner, автор РИТМ.&lltt;/p&ggtt;
&lltt;h2&ggtt;Почему первая линия загружена, даже когда есть портал&lltt;/h2&ggtt;
&lltt;p&ggtt;Последние десять лет компании инвестировали в&nbsp;самообслуживание: проектировали каталоги услуг, создавали формы типовых запросов, наполняли базы знаний, публиковали объявления о&nbsp;плановых и&nbsp;аварийных работах. Цель была очевидной&nbsp;— дать сотрудникам возможность решать типовые вопросы самостоятельно, а&nbsp;первую линию поддержки освободить для действительно сложных случаев.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;практике портал часто не&nbsp;становится привычной точкой входа. Сотрудник открывает каталог и&nbsp;видит десятки или сотни карточек с&nbsp;названиями вроде «Предоставление прав доступа к&nbsp;информационным ресурсам» или «Выдача прав для пользователей». Чтобы получить доступ к&nbsp;отчётам, ему нужно сначала понять внутреннюю логику ИТ-службы: какая услуга подходит, чем отличаются похожие формы, какие поля обязательны и&nbsp;почему. Проще написать в&nbsp;почту, мессенджер или создать обращение свободным текстом: «Не&nbsp;открывается отчёт, помогите».&lltt;/p&ggtt;
&lltt;p&ggtt;«У&nbsp;большинства крупных компаний порталы самообслуживания уже есть, но&nbsp;с&nbsp;точки зрения пользователя порталы и&nbsp;каталоги услуг неудобные, перегруженные и&nbsp;запутанные. Пользователи предпочитают позвонить, написать письмо или оставить обращение в&nbsp;свободной форме, потому что это быстрее, чем разбираться в&nbsp;большом количестве типовых запросов с&nbsp;непонятными названиями. Портал есть, но&nbsp;он&nbsp;не&nbsp;работает так, как задумывалось»,&nbsp;— &lltt;strong&ggtt;Андрей Вишняков&lltt;/strong&ggtt;, директор по&nbsp;бизнес-продуктам SimpleOne, корпорация ITG, ITIL 4&nbsp;Master, ITIL 3&nbsp;Expert, ITIL Practitioner&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;итоге первую линию превращают в&nbsp;ручной маршрутизатор. Агенту приходится расшифровывать описание, выяснять детали, переводить обращение в&nbsp;корректный тип запроса и&nbsp;передавать его исполнителю. Профильный специалист получает неполную заявку и&nbsp;запрашивает дополнительные данные. В&nbsp;результате пользователю приходится ждать, агентам службы сервис-деск&nbsp;— выполнять однотипную работу, а&nbsp;бизнесу&nbsp;— тратить ресурсы на&nbsp;обработку обращений, которые могли&nbsp;бы не&nbsp;попасть в&nbsp;поддержку вовсе. &lltt;/p&ggtt;
&lltt;p&ggtt;О&nbsp;том, как решить проблему порталов самообслуживания,&nbsp;— в&nbsp;&lltt;a href="https://simpleone.ru/materials/ai-self-service?utm_source=itweek&utm_medium=article&utm_campaign=ai_gid_itsm"&ggtt;полной версии аналитического обзора&lltt;/a&ggtt;. &lltt;/p&ggtt;
&lltt;h2&ggtt;Что меняется&lltt;/h2&ggtt;
&lltt;p&ggtt;Раньше проблему навигации по&nbsp;порталу пытались решить через чат-ботов, но&nbsp;они работали только по&nbsp;жёстким сценариям. Пользователь должен был выбрать правильную ветку, сформулировать запрос ожидаемым образом и&nbsp;последовательно отвечать на&nbsp;вопросы. Стоило отклониться от&nbsp;сценария&nbsp;— например, написать «не&nbsp;открывается отчёт» вместо «не&nbsp;работает корпоративная система отчётности»,&nbsp;— и&nbsp;бот переставал быть полезным. &lltt;/p&ggtt;
&lltt;p&ggtt;Технология искусственного интеллекта заставила чат-ботов потерять актуальность. Согласно &lltt;a href="https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290?utm_term=1742993448&utm_campaign=SM_GB_YOY_GTR_SOC_SF1_SM-PR-GBS-CSS&utm_source=linkedin,threads,twitter&utm_medium=social&utm_content=1742993448"&ggtt;официальному прогнозу Gartner&lltt;/a&ggtt;, развитие агентного&nbsp;ИИ приведет к&nbsp;тому, что к&nbsp;2029 году системы смогут автономно разрешать до&nbsp;80% всех рутинных пользовательских обращений без вмешательства человека. Например, когда на&nbsp;портале есть ИИ-помощник, пользователь описывает задачу так, как привык: «мне нужен доступ к&nbsp;отчётам», «не&nbsp;работает почта», «как настроить VPN». Помощник понимает смысл запроса, учитывает контекст диалога и&nbsp;ищет релевантную информацию в&nbsp;данных, которые уже есть в&nbsp;системе: каталоге услуг, моделях типовых запросов, статьях базы знаний, объявлениях и&nbsp;известных ошибках.&lltt;/p&ggtt;
&lltt;p&ggtt;Если вопрос можно закрыть без обращения, помощник покажет подходящую статью, объявление или обходное решение. Если пользователю нужна услуга, он&nbsp;найдёт соответствующую модель запроса, уточнит необходимые данные и&nbsp;подготовит форму с&nbsp;уже заполненными полями. Если речь идёт о&nbsp;нарушении работы сервиса, помощник поможет оформить инцидент и&nbsp;передать специалистам контекст без дополнительных итераций.&lltt;/p&ggtt;
&lltt;p&ggtt;Техническую основу такого подхода составляет технология RAG (Retrieval-Augmented Generation, генерация с&nbsp;дополненной выборкой). Сначала система находит в&nbsp;корпоративных источниках материалы, близкие по&nbsp;смыслу к&nbsp;вопросу пользователя. Затем генеративная модель использует найденные данные, чтобы сформировать понятный ответ или предложить следующее действие. Поэтому помощник не&nbsp;заменяет настроенные процессы и&nbsp;базу знаний, а&nbsp;делает их&nbsp;доступными для человека, который не&nbsp;знает внутренней структуры портала.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235509#&lltt;/p&ggtt;
&lltt;p&ggtt;Для этого не&nbsp;нужно вручную обрабатывать каждый документ или менять существующую модель данных. Для каталога услуг, статей, объявлений и&nbsp;известных ошибок настраиваются векторные коллекции: в&nbsp;них попадают поля, по&nbsp;которым помощник должен искать информацию. После настройки новые и&nbsp;изменённые записи обновляются автоматически с&nbsp;заданной периодичностью. При этом важно определить, какие данные попадут в&nbsp;поиск и&nbsp;по&nbsp;каким условиям, например, включать опубликованные и&nbsp;актуальные объявления, а&nbsp;архивные&nbsp;— исключать. Так качество ответа зависит не&nbsp;только от&nbsp;модели, но&nbsp;и&nbsp;от&nbsp;актуальности и&nbsp;структуры корпоративных знаний.&lltt;/p&ggtt;
&lltt;h2&ggtt;Организационный и&nbsp;экономический эффект&lltt;/h2&ggtt;
&lltt;p&ggtt;Для сотрудника ИИ-помощник сокращает путь от&nbsp;вопроса до&nbsp;результата. Не&nbsp;нужно искать нужную карточку в&nbsp;каталоге, разбираться в&nbsp;терминологии или вручную заполнять форму. Достаточно описать ситуацию своими словами, а&nbsp;помощник найдёт ответ, предложит обходное решение либо подготовит обращение. В&nbsp;типовом сценарии пользователь получает нужную информацию или корректную форму за&nbsp;&lltt;nobr&ggtt;30–60 секунд,&lltt;/nobr&ggtt; а&nbsp;число повторных обращений снижается.&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;первой линии будет меньше ручной работы: типовые обращения либо не&nbsp;будут создаваться совсем, либо будут поступать уже классифицированными, с&nbsp;заполненными полями и&nbsp;контекстом. Агенты не&nbsp;тратят время на&nbsp;расшифровку свободного текста, уточнения и&nbsp;переоформление заявок, и&nbsp;могут сосредоточиться на&nbsp;инцидентах, где действительно требуется экспертиза. Профильные специалисты при этом будут получать запросы, в&nbsp;которых уже есть обязательные данные. Это повышает долю решений с&nbsp;первого обращения (First Call Resolution) и&nbsp;снижает риск выгорания команды.&lltt;/p&ggtt;
&lltt;p&ggtt;Для финансового расчета возьмем перспективу по&nbsp;уменьшению количества обращений&nbsp;— по&nbsp;упомянутому выше &lltt;a href="https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290"&ggtt;прогнозу Gartner&lltt;/a&ggtt; агентный&nbsp;ИИ будет автономно решать&nbsp;80% типовых обращений в&nbsp;клиентской поддержке. Чтобы не&nbsp;завышать эффект, особенно в&nbsp;вопросе обслуживания внутренних клиентов, возьмем более сдержанную цифру в&nbsp;20%.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;данным &lltt;a href="https://www.metricnet.com/resolved-level-1-capable-a-critical-desktop-support-metric/"&ggtt;глобального ИТ-бенчмаркинга&lltt;/a&ggtt; (MetricNet, HDI), средняя стоимость обработки одного обращения на&nbsp;первой линии постоянно растет из-за удорожания ручного труда. В&nbsp;российских реалиях при расчете через фонд оплаты труда (ФОТ), налоги и&nbsp;накладные расходы базовая стоимость одного рутинного тикета варьируется от&nbsp;240 до&nbsp;480&nbsp;рублей.&lltt;/p&ggtt;
&lltt;p&ggtt;Рассчитаем экономику прямым методом: годовой ФОТ отдела поддержки, поделенный на&nbsp;годовой объем запросов:&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;thead&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;th&ggtt; Параметр&lltt;/th&ggtt;
			&lltt;th&ggtt; Малый объем&lltt;/th&ggtt;
			&lltt;th&ggtt; Средний объем&lltt;/th&ggtt;
			&lltt;th&ggtt; Большой объем&lltt;/th&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; Обращений в&nbsp;год&lltt;/td&ggtt;
			&lltt;td&ggtt; 50&nbsp;000&lltt;/td&ggtt;
			&lltt;td&ggtt; 150&nbsp;000&lltt;/td&ggtt;
			&lltt;td&ggtt; 300&nbsp;000&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; Агентов &lltt;nobr&ggtt;1-й&lltt;/nobr&ggtt; линии&lltt;/td&ggtt;
			&lltt;td&ggtt; 10&lltt;/td&ggtt;
			&lltt;td&ggtt; 20&lltt;/td&ggtt;
			&lltt;td&ggtt; 35&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; ФОТ в&nbsp;год*&lltt;/td&ggtt;
			&lltt;td&ggtt; 9&nbsp;600&nbsp;000&nbsp;руб.&lltt;/td&ggtt;
			&lltt;td&ggtt; 19&nbsp;200&nbsp;000&nbsp;руб.&lltt;/td&ggtt;
			&lltt;td&ggtt; 33&nbsp;600&nbsp;000&nbsp;руб.&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; Стоимость одного обращения&lltt;/td&ggtt;
			&lltt;td&ggtt; 320&nbsp;руб.&lltt;/td&ggtt;
			&lltt;td&ggtt; ~274&nbsp;руб.&lltt;/td&ggtt;
			&lltt;td&ggtt; ~258&nbsp;руб.&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; Предотвращенных обращений (20%)&lltt;/td&ggtt;
			&lltt;td&ggtt; 10&nbsp;000&lltt;/td&ggtt;
			&lltt;td&ggtt; 30&nbsp;000&lltt;/td&ggtt;
			&lltt;td&ggtt; 60&nbsp;000&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; Прямая экономия&lltt;/td&ggtt;
			&lltt;td&ggtt; 3&nbsp;200&nbsp;000 руб./год&lltt;/td&ggtt;
			&lltt;td&ggtt; 8&nbsp;220&nbsp;000 руб./год&lltt;/td&ggtt;
			&lltt;td&ggtt; 15&nbsp;480&nbsp;000 руб./год&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/thead&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;&lltt;em&ggtt;* ФОТ в&nbsp;примерах рассчитан из&nbsp;зарплаты агента 80&nbsp;000 руб./мес с&nbsp;учетом налогов и&nbsp;накладных расходов. Эффект масштаба на&nbsp;средних и&nbsp;больших объемах снижает удельную стоимость запроса, но&nbsp;совокупная экономия кратно возрастает.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Помимо прямой экономии от&nbsp;не&nbsp;созданных заявок, имеет место и&nbsp;второй важный экономический фактор&nbsp;— сокращение времени обработки. За&nbsp;счет устранения итераций на&nbsp;сбор контекста и&nbsp;уточнение деталей время реакции и&nbsp;обработки тикетов может сократиться более чем на&nbsp;треть. Это дополнительно высвобождает дорогие часы узкопрофильных специалистов. &lltt;/p&ggtt;
&lltt;p&ggtt;При этом стоимость часа второй и&nbsp;особенно третьей линии поддержки в&nbsp;разы выше, чем первой. Поэтому эффект от&nbsp;сокращения итераций накапливается, и&nbsp;экономия происходит не&nbsp;только на&nbsp;объёме заявок, но&nbsp;и&nbsp;на&nbsp;самых дорогих часах в&nbsp;структуре поддержки, и&nbsp;итоговая оптимизация расходов оказывается выше, чем сумма отдельных факторов.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;В&nbsp;результате бизнес получает измеримый эффект:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; Сокращение затрат на&nbsp;постоянный найм и&nbsp;обучение новых агентов первой линии.&lltt;/li&ggtt;
	&lltt;li&ggtt; Высвобождение ИТ-бюджета: средства направляются на&nbsp;развитие услуг, а&nbsp;не&nbsp;на&nbsp;расширение штата.&lltt;/li&ggtt;
	&lltt;li&ggtt; Рост операционной эффективности: кратно большее количество обращений обрабатывается меньшими силами.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;При этом, когда портал самообслуживания становится по-настоящему эффективным и&nbsp;окупаемым в&nbsp;ИТ, бизнес может масштабировать эту&nbsp;же практику на&nbsp;другие подразделения: HR, АХО, бухгалтерию, юридический отдел. В&nbsp;логике Enterprise Service Management (ESM) это создает единый консистентный опыт для сотрудников: к&nbsp;какому&nbsp;бы подразделению ни&nbsp;относилась услуга, механизм ее&nbsp;получения одинаков&nbsp;— достаточно просто описать свою потребность на&nbsp;естественном языке.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;em&ggtt;Оцените оптимизацию на&nbsp;ваших задачах&nbsp;— на&nbsp;демонстрации с&nbsp;помощью специального калькулятор посчитаем эффект экономии для трёх линий поддержки при внедрении ИИ-помощника. &lltt;/em&ggtt;&lltt;a href="https://simpleone.ru/itsm?utm_source=itweek&utm_medium=article&utm_campaign=ai_gid_itsm"&ggtt;&lltt;em&ggtt;Оставьте заявку на&nbsp;сайте&lltt;/em&ggtt;&lltt;/a&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h2&ggtt;Что умеет ИИ-гид в&nbsp;SimpleOne ITSM&lltt;/h2&ggtt;
&lltt;p&ggtt;ИИ&nbsp;гид-помощник в&nbsp;SimpleOne ITSM&nbsp;не заменяет каталог услуг, базу знаний или привычные формы, а, скорее, становится единой точкой входа в&nbsp;эти ресурсы.&lltt;/p&ggtt;

&lltt;p align="center"&ggtt;&lltt;iframe width="650" height="366" src="https://rutube.ru/play/embed/75676b2633ab248e942c74138e03a3b6/" style="border: none;" allow="clipboard-write; autoplay" allowFullScreen&ggtt;&lltt;/iframe&ggtt;&lltt;/p&ggtt;

&lltt;h3&ggtt;Находит услугу и&nbsp;готовит запрос&lltt;/h3&ggtt;
&lltt;p&ggtt;Пользователь пишет: «Мне нужен доступ к&nbsp;отчётам по&nbsp;продажам». Ему не&nbsp;нужно знать, как услуга называется в&nbsp;каталоге и&nbsp;чем она отличается от&nbsp;похожих карточек. ИИ-гид распознаёт, что речь идёт о&nbsp;запросе на&nbsp;обслуживание, находит подходящую модель типового запроса и&nbsp;задаёт только нужные уточняющие вопросы&nbsp;— например, о&nbsp;срочности и&nbsp;ссылке на&nbsp;нужный раздел портала.&lltt;/p&ggtt;
&lltt;p&ggtt;Затем помощник формирует ссылку на&nbsp;обращение с&nbsp;предзаполненными полями. Пользователю остаётся проверить данные, при необходимости дополнить описание и&nbsp;отправить запрос. Он&nbsp;сразу поступает профильному исполнителю с&nbsp;необходимым контекстом.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235510#&lltt;/p&ggtt;
&lltt;h3&ggtt;Показывает обходное решение&lltt;/h3&ggtt;
&lltt;p&ggtt;Если ситуация уже известна поставщику услуг, не&nbsp;всегда нужен новый инцидент. Пользователь описывает проблему в&nbsp;чате, а&nbsp;ИИ-гид сопоставляет её&nbsp;с&nbsp;записями в&nbsp;базе известных ошибок (KEDB). Если в&nbsp;карточке есть обходное решение, помощник показывает его прямо в&nbsp;диалоге. Пользователь быстрее восстанавливает работу, а&nbsp;команда поддержки не&nbsp;получает повторяющиеся обращения по&nbsp;одной и&nbsp;той&nbsp;же проблеме.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235511#&lltt;/p&ggtt;
&lltt;h3&ggtt;Предупреждает о&nbsp;работах&lltt;/h3&ggtt;
&lltt;p&ggtt;Представим, что сотрудник пишет: «Не&nbsp;работает корпоративная почта». Вместо регистрации инцидента ИИ-гид может найти опубликованное объявление о&nbsp;временной недоступности почтовой службы и&nbsp;показать его в&nbsp;чате. Пользователь видит, что причина уже известна, работы ведутся, а&nbsp;отдельное обращение создавать не&nbsp;требуется.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235512#&lltt;/p&ggtt;
&lltt;h3&ggtt;Отвечает по&nbsp;базе знаний&lltt;/h3&ggtt;
&lltt;p&ggtt;Не&nbsp;каждый вопрос требует участия специалиста. Например, сотрудник хочет настроить рабочий инструмент, но&nbsp;не&nbsp;знает, где искать инструкцию. ИИ-гид находит подходящую статью базы знаний, формирует короткий ответ в&nbsp;чате и&nbsp;при необходимости предлагает перейти к&nbsp;полному материалу. Так база знаний перестаёт быть архивом, который пользователь должен самостоятельно просматривать по&nbsp;ключевым словам. Она становится источником ответа в&nbsp;момент, когда он&nbsp;нужен.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235513#&lltt;/p&ggtt;
&lltt;p&ggtt;При этом в&nbsp;SimpleOne новые и&nbsp;обновлённые записи не&nbsp;нужно вручную заново загружать для каждой консультации: после настройки коллекций они синхронизируются автоматически с&nbsp;заданной периодичностью. Однако владельцам базы знаний и&nbsp;каталога услуг важно поддерживать материалы в&nbsp;актуальном состоянии&nbsp;— помощник работает с&nbsp;тем корпоративным контекстом, который ему доступен. &lltt;/p&ggtt;
&lltt;h3&ggtt;Помогает оформить инцидент&lltt;/h3&ggtt;
&lltt;p&ggtt;Если помощник не&nbsp;нашёл известную ошибку, актуальное объявление или подходящее решение в&nbsp;базе знаний, он&nbsp;определяет, что нужно зарегистрировать инцидент. Затем уточняет детали, которые понадобятся специалисту: например, срочность и&nbsp;описание условий, при которых возникла проблема. В&nbsp;результате пользователь получает форму с&nbsp;предзаполненными данными, а&nbsp;Service Desk&nbsp;— обращение с&nbsp;контекстом.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235514#&lltt;/p&ggtt;
&lltt;h2&ggtt;Как масштабировать ИИ-помощника на&nbsp;другие отделы&lltt;/h2&ggtt;
&lltt;p&ggtt;ИИ-гид работает не&nbsp;с&nbsp;ИТ-терминами, а&nbsp;со&nbsp;смыслом запроса и&nbsp;корпоративными данными. Поэтому после отладки сценариев на&nbsp;сервисном портале ITSM тот&nbsp;же подход можно использовать в&nbsp;других подразделениях&nbsp;— в&nbsp;логике Enterprise Service Management.&lltt;/p&ggtt;
&lltt;p&ggtt;Например, сотрудник может написать: «Нужна справка &lltt;nobr&ggtt;2-НДФЛ»&lltt;/nobr&ggtt; или «Хочу оформить отпуск»&nbsp;— помощник найдёт нужную услугу&nbsp;HR, уточнит необходимые данные и&nbsp;подготовит форму обращения. В&nbsp;бухгалтерии он&nbsp;подскажет, как оформить авансовый отчёт, найдёт инструкцию по&nbsp;возмещению расходов или направит запрос на&nbsp;нужную услугу. В&nbsp;юридическом отделе&nbsp;— поможет найти шаблон договора, правила согласования или зарегистрировать запрос на&nbsp;проверку документа.&lltt;/p&ggtt;
&lltt;p&ggtt;Для сотрудника путь остаётся одинаковым: описать потребность обычными словами. А&nbsp;для сервисных подразделений сохраняются их&nbsp;собственные процессы, каталог услуг, база знаний и&nbsp;маршрутизация. Помощник не&nbsp;унифицирует работу&nbsp;HR, бухгалтерии и&nbsp;юристов под ИТ-процессы&nbsp;— он&nbsp;делает их&nbsp;сервисы понятнее и&nbsp;доступнее, становясь единым интерфейсом между сотрудником и&nbsp;внутренними функциями компании.&lltt;/p&ggtt;
&lltt;h2&ggtt;Резюме&lltt;/h2&ggtt;
&lltt;p&ggtt;Портал самообслуживания долго оставался витриной внутренних услуг, где сотрудник сам находит нужное. С&nbsp;появлением&nbsp;ИИ меняется логика взаимодействия. Портал перестаёт требовать навигации и&nbsp;начинает вести диалог&nbsp;— принимать задачу в&nbsp;той формулировке, в&nbsp;которой она возникает у&nbsp;человека.&lltt;/p&ggtt;
&lltt;p&ggtt;Для компаний это повод пересмотреть не&nbsp;только интерфейс поддержки, но&nbsp;и&nbsp;качество сервисных знаний. Чем точнее описаны услуги, чем актуальнее статьи и&nbsp;объявления, тем полезнее становится помощник. Поэтому его внедрение&nbsp;— не&nbsp;разовая автоматизация, а&nbsp;практический способ сделать накопленные процессы и&nbsp;знания реально доступными сотрудникам.&lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы увидеть, как работает&nbsp;ИИ гид-помощник, запросите демонстрацию SimpleOne ITSM&nbsp;на сайте SimpleOne.&lltt;/p&ggtt;]]></source>
<adate>11.09.2020</adate>
<dbid>235506</dbid>
<rubric>1</rubric>
<orubric>135315</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/e57/s2qn71baqyc9zttbo2q0gahay5linpfx.jpg;;https://www.itweek.ru/upload/iblock/756/m36vl2kfdo24esg9fl4axqq7rv4mowxy.jpg;;https://www.itweek.ru/upload/iblock/e21/v0fssg7g1y8g5vyl7fn26gv5sbzbh48s.jpg;;https://www.itweek.ru/upload/iblock/0ec/0hue9k76fgidkvki0ngeo6k0y7qk7vgq.jpg;;https://www.itweek.ru/upload/iblock/717/0gljq19jo5ftkbqwj8t7e02573ygzlhz.jpg;;https://www.itweek.ru/upload/iblock/9cc/dm55wq62oyd10i0sbj9j4dofsvr1h35p.jpg]]>
</images>
<imagesname><![CDATA[;;Принцип работы RAG в GenAI-платформе SimpleOne   ;; ;; ;; ;; ;; ]]></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[ИСИЭЗ НИУ ВШЭ: поддержка применения ИИ в организациях сферы науки]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235505]]></link>
<description><![CDATA[Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как вузы и научные организации регулируют и поддерживают применение искусственного интеллекта сотрудниками. Руководители организаций сферы науки в целом поддерживают применение ИИ сотрудниками для целей, связанных с исследованиями. Положительно к такой практике относятся 49% опрошенных организаций, еще 34% считают технологию полезной для одних исследовательских задач, но не подходящей для других. Нейтральной позиции придерживаются 14% респондентов, негативной — лишь 3%. Практические меры поддержки уже реализуют 65% организаций. В вузах они распространены заметно шире, чем в НИИ: 76% против 49%. Разрыв может быть связан с наличием у вузов собственной образовательной инфраструктуры, облегчающей развертывание обучающих форматов. Наиболее распространены малозатратные образовательные семинары, встречи и мастер-классы: их проводят 48% организаций. Почти четверть (23%) реализуют более системные форматы — долгосрочные программы ДПО и повышения квалификации. Разрабатывают собственные ИИ-модели для научных исследований 23% организаций. Однако эту деятельность следует рассматривать прежде всего как направление исследований и разработок и лишь косвенно — как меру развития сотрудников. Финансовая и ресурсная поддержка встречается заметно реже. Внутренние гранты на исследования с использованием ИИ выделяют 10% организаций. Междисциплинарные команды, объединяющие специалистов по ИИ и исследователей-предметников, поддерживают 6%. Подписки на ИИ-сервисы и доступ к внешним вычислительным мощностям оплачивают лишь единичные организации — хотя сами ученые относят именно эти меры к наиболее востребованным. Формализация политики заметно отстает от практики. Внутренние документы, регулирующие работу с ИИ (регламенты, положения, концепции и др.), утвердили лишь 60 участников опроса (14%); из них только 35 включили в эти документы положения об использовании ИИ непосредственно в научных исследованиях. Результаты опроса ИСИЭЗ НИУ ВШЭ показали, что руководители вузов и НИИ в целом одобряют использование ИИ сотрудниками в научных исследованиях, а две трети организаций уже реализуют конкретные меры поддержки. При этом практическая поддержка опережает нормативное оформление и чаще всего строится по принципу наименьших затрат. Переход к системному применению ИИ в российской науке требует не только стимулирования со стороны государства, но и развития внутренних механизмов на уровне организаций]]></description>
<source><![CDATA[&lltt;p&ggtt;Институт статистических исследований и&nbsp;экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как вузы и&nbsp;научные организации регулируют и&nbsp;поддерживают применение искусственного интеллекта сотрудниками.&lltt;/p&ggtt;
&lltt;p&ggtt;Руководители организаций сферы науки в&nbsp;целом поддерживают применение&nbsp;ИИ сотрудниками для целей, связанных с&nbsp;исследованиями. Положительно к&nbsp;такой практике относятся&nbsp;49% опрошенных организаций, еще&nbsp;34% считают технологию полезной для одних исследовательских задач, но&nbsp;не&nbsp;подходящей для других. Нейтральной позиции придерживаются&nbsp;14% респондентов, негативной&nbsp;— лишь 3%.&lltt;/p&ggtt;
&lltt;p&ggtt;Практические меры поддержки уже реализуют&nbsp;65% организаций. В&nbsp;вузах они распространены заметно шире, чем в&nbsp;НИИ: 76% против 49%. Разрыв может быть связан с&nbsp;наличием у&nbsp;вузов собственной образовательной инфраструктуры, облегчающей развертывание обучающих форматов.&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее распространены малозатратные образовательные семинары, встречи и&nbsp;мастер-классы: их&nbsp;проводят&nbsp;48% организаций. Почти четверть (23%) реализуют более системные форматы&nbsp;— долгосрочные программы ДПО и&nbsp;повышения квалификации.&lltt;/p&ggtt;
&lltt;p&ggtt;Разрабатывают собственные ИИ-модели для научных исследований&nbsp;23% организаций. Однако эту деятельность следует рассматривать прежде всего как направление исследований и&nbsp;разработок и&nbsp;лишь косвенно&nbsp;— как меру развития сотрудников.&lltt;/p&ggtt;
&lltt;p&ggtt;Финансовая и&nbsp;ресурсная поддержка встречается заметно реже. Внутренние гранты на&nbsp;исследования с&nbsp;использованием&nbsp;ИИ выделяют&nbsp;10% организаций. Междисциплинарные команды, объединяющие специалистов по&nbsp;ИИ и&nbsp;исследователей-предметников, поддерживают 6%.&lltt;/p&ggtt;
&lltt;p&ggtt;Подписки на&nbsp;ИИ-сервисы и&nbsp;доступ к&nbsp;внешним вычислительным мощностям оплачивают лишь единичные организации&nbsp;— хотя сами ученые относят именно эти меры к&nbsp;наиболее востребованным.&lltt;/p&ggtt;
&lltt;p&ggtt;Формализация политики заметно отстает от&nbsp;практики. Внутренние документы, регулирующие работу с&nbsp;ИИ (регламенты, положения, концепции и&nbsp;др.), утвердили лишь 60&nbsp;участников опроса (14%); из&nbsp;них только 35&nbsp;включили в&nbsp;эти документы положения об&nbsp;использовании&nbsp;ИИ непосредственно в&nbsp;научных исследованиях.&lltt;/p&ggtt;
&lltt;p&ggtt;Результаты опроса ИСИЭЗ НИУ ВШЭ показали, что руководители вузов и&nbsp;НИИ в&nbsp;целом одобряют использование&nbsp;ИИ сотрудниками в&nbsp;научных исследованиях, а&nbsp;две трети организаций уже реализуют конкретные меры поддержки. При этом практическая поддержка опережает нормативное оформление и&nbsp;чаще всего строится по&nbsp;принципу наименьших затрат. Переход к&nbsp;системному применению&nbsp;ИИ в&nbsp;российской науке требует не&nbsp;только стимулирования со&nbsp;стороны государства, но&nbsp;и&nbsp;развития внутренних механизмов на&nbsp;уровне организаций.&lltt;/p&ggtt;]]></source>
<adate>10.09.2026</adate>
<dbid>235505</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Сбер разработал новую reasoning-нейросеть, которая уже доступна пользователям и разработчикам]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235504]]></link>
<description><![CDATA[Сбер представил GigaChat 3.5 Reasoning — новую флагманскую мультимодальную нейросеть с режимом рассуждений. Она не спешит сразу отвечать на сложный вопрос: сначала разбирает задачу на этапы, определяет план решения, при необходимости обращается к поиску и другим инструментам, ищет ошибки в своих промежуточных результатах и только после этого формирует ответ. GigaChat 3.5 Reasoning — быстрая и экономная модель: она решает задачи с меньшими ресурсами, существенно экономя токены на рассуждение в сравнении с ведущими открытыми нейросетями. Рассуждения особенно полезны в задачах, где недостаточно одного действия или простого поиска информации. Например, модель может найти противоречия между пунктами договора, провести финансовые расчёты или разобраться в сложной ошибке в коде. Флагманская модель уже доступна всем пользователям ГигаЧата, а разработчикам — бесплатно по лицензии MIT для интеграции в свои продукты. Модель станет доступна бизнесу по API в ближайшее время. Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Сегодня от ИИ ждут не просто быстрого ответа, а способности разобраться в сложной задаче. Теперь GigaChat способен самостоятельно разложить задачу на этапы, понять, каких данных не хватает, проверить промежуточные выводы и при необходимости изменить ход решения. Такой подход особенно важен для агентных сценариев, программирования, аналитики — везде, где результат зависит от целой последовательности решений. Это важный шаг к ИИ, который способен самостоятельно выстраивать путь к результату, действовать проактивно и взаимодействовать с другими сервисами. GigaChat — единственная российская модель с режимом рассуждений». Пользователь может сам определить, когда требуется рассуждение и включить режим отдельной кнопкой. На простой вопрос модель отвечает сразу, а для сложной задачи может использовать десятки тысяч токенов на поиск решения. Новая версия лучше справляется с написанием кода и агентными сценариями, в которых необходимо последовательно выполнить несколько действий. Например, при организации поездки модель может уточнить недостающие параметры, подобрать рейс и отель, проверить, укладывается ли маршрут в бюджет, а при обнаружении противоречия — перестроить план. Благодаря поддержке рассуждений качество GigaChat выросло почти по всем замерам, наиболее заметный прогресс — в агентских задачах, работе с функциями и инструментами, программировании и задачах со сложной логикой. По ключевым направлениям — следованию сложным инструкциям, планированию и написанию кода — GigaChat 3.5 Ultra Reasoning вплотную приблизился к лучшим мировым моделям. Например, в бенчмарке IFBench результат вырос с 44 до 77 баллов, на Natural Plan — с 64 до 80, на Live Code Bench v6 — с 56 до 85. Это заметный рост по сравнению с версией без режима рассуждений. GigaChat 3.5 Reasoning — экономная модель: на рассуждения она тратит существенно меньше токенов, чем ведущие открытые модели при сопоставимом качестве ответов. Например, на решение математических задач она тратит в среднем на 37% меньше токенов, чем DeepSeek V4 Flash Preview. Рассуждающая модель будет наиболее полезна в таких сферах, как: 	финансы и банкинг — прогнозирование сценариев, проверка сделок на соответствие нормативным требованиям; 	юриспруденция — поиск противоречий в договорах, проверка документов на соответствие регламенту или прецедентам; 	разработка ПО — поиск и исправление багов, выбор архитектуры с учётом скорости, цены и надёжности; 	логистика и планирование — построение маршрутов и расписаний с учётом сроков, бюджета и доступных ресурсов; 	образование — пошаговый разбор задач по математике, физике и программированию с проверкой каждого шага; 	наука и аналитика данных — анализ данных в несколько этапов: расчёты и проверка гипотез; 	поддержка клиентов — уточнение деталей у клиента и проверка данных в разных системах перед ответом. Нейросети без режима рассуждения на сложных задачах модель могут давать быстрый, но неполный ответ — просто не размышляя над ними. Новую модель целенаправленно обучили рассуждать, взял за основу базовую GigaChat 3.5 Ultra. Для обучения модель решала математические и кодовые задачи разными способами, раскладывая их на последовательные шаги. Автоматическая проверка определяла, какой вариант рассуждения привёл к правильному ответу, и закрепляла именно такие пути решения. Так она научилась не только выстраивать последовательность действий, но и самостоятельно решать, когда обратиться к внешнему инструменту или пересмотреть предыдущий шаг. GigaChat 3.5 Reasoning использует собственную архитектуру с технологией линейного внимания. Она помогает эффективнее работать с длинным контекстом: вместо того, чтобы повторного сопоставлять каждый новый запрос со всем предыдущим текстом модель запоминает его ключевое содержание и дополняет его по мере обработки информации]]></description>
<source><![CDATA[&lltt;p&ggtt;Сбер представил GigaChat 3.5 Reasoning&nbsp;— новую флагманскую мультимодальную нейросеть с&nbsp;режимом рассуждений. Она не&nbsp;спешит сразу отвечать на&nbsp;сложный вопрос: сначала разбирает задачу на&nbsp;этапы, определяет план решения, при необходимости обращается к&nbsp;поиску и&nbsp;другим инструментам, ищет ошибки в&nbsp;своих промежуточных результатах и&nbsp;только после этого формирует ответ. GigaChat 3.5 Reasoning&nbsp;— быстрая и&nbsp;экономная модель: она решает задачи с&nbsp;меньшими ресурсами, существенно экономя токены на&nbsp;рассуждение в&nbsp;сравнении с&nbsp;ведущими открытыми нейросетями.&lltt;/p&ggtt;
&lltt;p&ggtt;Рассуждения особенно полезны в&nbsp;задачах, где недостаточно одного действия или простого поиска информации. Например, модель может найти противоречия между пунктами договора, провести финансовые расчёты или разобраться в&nbsp;сложной ошибке в&nbsp;коде. Флагманская модель уже доступна всем пользователям ГигаЧата, а&nbsp;разработчикам&nbsp;— бесплатно по&nbsp;лицензии MIT для интеграции в&nbsp;свои продукты. Модель станет доступна бизнесу по&nbsp;API&nbsp;в ближайшее время. &lltt;/p&ggtt;
&lltt;p&ggtt;Антон Фролов, старший вице-президент, руководитель блока «Развитие генеративного ИИ» Сбербанка, отметил: «Сегодня от&nbsp;ИИ ждут не&nbsp;просто быстрого ответа, а&nbsp;способности разобраться в&nbsp;сложной задаче. Теперь GigaChat способен самостоятельно разложить задачу на&nbsp;этапы, понять, каких данных не&nbsp;хватает, проверить промежуточные выводы и&nbsp;при необходимости изменить ход решения. Такой подход особенно важен для агентных сценариев, программирования, аналитики&nbsp;— везде, где результат зависит от&nbsp;целой последовательности решений. Это важный шаг к&nbsp;ИИ, который способен самостоятельно выстраивать путь к&nbsp;результату, действовать проактивно и&nbsp;взаимодействовать с&nbsp;другими сервисами. GigaChat&nbsp;— единственная российская модель с&nbsp;режимом рассуждений».&lltt;/p&ggtt;
&lltt;p&ggtt;Пользователь может сам определить, когда требуется рассуждение и&nbsp;включить режим отдельной кнопкой. На&nbsp;простой вопрос модель отвечает сразу, а&nbsp;для сложной задачи может использовать десятки тысяч токенов на&nbsp;поиск решения. Новая версия лучше справляется с&nbsp;написанием кода и&nbsp;агентными сценариями, в&nbsp;которых необходимо последовательно выполнить несколько действий. Например, при организации поездки модель может уточнить недостающие параметры, подобрать рейс и&nbsp;отель, проверить, укладывается&nbsp;ли маршрут в&nbsp;бюджет, а&nbsp;при обнаружении противоречия&nbsp;— перестроить план.&lltt;/p&ggtt;
&lltt;p&ggtt;Благодаря поддержке рассуждений качество GigaChat выросло почти по&nbsp;всем замерам, наиболее заметный прогресс&nbsp;— в&nbsp;агентских задачах, работе с&nbsp;функциями и&nbsp;инструментами, программировании и&nbsp;задачах со&nbsp;сложной логикой. По&nbsp;ключевым направлениям&nbsp;— следованию сложным инструкциям, планированию и&nbsp;написанию кода&nbsp;— GigaChat 3.5 Ultra Reasoning вплотную приблизился к&nbsp;лучшим мировым моделям. Например, в&nbsp;бенчмарке IFBench результат вырос с&nbsp;44&nbsp;до&nbsp;77&nbsp;баллов, на&nbsp;Natural Plan&nbsp;— с&nbsp;64&nbsp;до&nbsp;80, на&nbsp;Live Code Bench v6&nbsp;— с&nbsp;56&nbsp;до&nbsp;85. Это заметный рост по&nbsp;сравнению с&nbsp;версией без режима рассуждений. &lltt;/p&ggtt;
&lltt;p&ggtt;GigaChat 3.5 Reasoning&nbsp;— экономная модель: на&nbsp;рассуждения она тратит существенно меньше токенов, чем ведущие открытые модели при сопоставимом качестве ответов. Например, на&nbsp;решение математических задач она тратит в&nbsp;среднем на&nbsp;37% меньше токенов, чем DeepSeek V4&nbsp;Flash Preview.&lltt;/p&ggtt;
&lltt;p&ggtt;Рассуждающая модель будет наиболее полезна в&nbsp;таких сферах, как:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;финансы и&nbsp;банкинг&nbsp;— прогнозирование сценариев, проверка сделок на&nbsp;соответствие нормативным требованиям;&lltt;/li&ggtt;
	&lltt;li&ggtt;юриспруденция&nbsp;— поиск противоречий в&nbsp;договорах, проверка документов на&nbsp;соответствие регламенту или прецедентам;&lltt;/li&ggtt;
	&lltt;li&ggtt;разработка ПО&nbsp;— поиск и&nbsp;исправление багов, выбор архитектуры с&nbsp;учётом скорости, цены и&nbsp;надёжности;&lltt;/li&ggtt;
	&lltt;li&ggtt;логистика и&nbsp;планирование&nbsp;— построение маршрутов и&nbsp;расписаний с&nbsp;учётом сроков, бюджета и&nbsp;доступных ресурсов;&lltt;/li&ggtt;
	&lltt;li&ggtt;образование&nbsp;— пошаговый разбор задач по&nbsp;математике, физике и&nbsp;программированию с&nbsp;проверкой каждого шага;&lltt;/li&ggtt;
	&lltt;li&ggtt;наука и&nbsp;аналитика данных&nbsp;— анализ данных в&nbsp;несколько этапов: расчёты и&nbsp;проверка гипотез;&lltt;/li&ggtt;
	&lltt;li&ggtt;поддержка клиентов&nbsp;— уточнение деталей у&nbsp;клиента и&nbsp;проверка данных в&nbsp;разных системах перед ответом.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Нейросети без режима рассуждения на&nbsp;сложных задачах модель могут давать быстрый, но&nbsp;неполный ответ&nbsp;— просто не&nbsp;размышляя над ними. Новую модель целенаправленно обучили рассуждать, взял за&nbsp;основу базовую GigaChat 3.5&nbsp;Ultra. Для обучения модель решала математические и&nbsp;кодовые задачи разными способами, раскладывая их&nbsp;на&nbsp;последовательные шаги. Автоматическая проверка определяла, какой вариант рассуждения привёл к&nbsp;правильному ответу, и&nbsp;закрепляла именно такие пути решения. Так она научилась не&nbsp;только выстраивать последовательность действий, но&nbsp;и&nbsp;самостоятельно решать, когда обратиться к&nbsp;внешнему инструменту или пересмотреть предыдущий шаг.&lltt;/p&ggtt;
&lltt;p&ggtt;GigaChat 3.5 Reasoning использует собственную архитектуру с&nbsp;технологией линейного внимания. Она помогает эффективнее работать с&nbsp;длинным контекстом: вместо того, чтобы повторного сопоставлять каждый новый запрос со&nbsp;всем предыдущим текстом модель запоминает его ключевое содержание и&nbsp;дополняет его по&nbsp;мере обработки информации.&lltt;/p&ggtt;]]></source>
<adate>10.09.2026</adate>
<dbid>235504</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Ковровые бомбардировки в сети: как меняется природа киберугроз]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235499]]></link>
<description><![CDATA[Заказать DDoS-атаку сегодня дешевле чашки кофе. Злоумышленники тратят от 1 рубля за 1 Мбит/с — это в тысячи раз дешевле, чем 20 лет назад. Обсудим, что с этим делать. DDoS перестал быть угрозой только для крупных компаний Еще несколько лет назад DDoS-атаки ассоциировались прежде всего с банками, государственными сервисами, интернет-магазинами и крупными медиа. Сегодня ситуация изменилась. Целью атаки может стать практически любой сайт независимо от размера бизнеса или отрасли. По данным сервиса Statonline.ru, более 90% ресурсов Рунета размещены на виртуальном хостинге. И каждый из них потенциально может стать целью атаки. Одна из причин — изменение самого характера атак. Они стали «ковровыми»: злоумышленники бьют не по одному сайту, а по тысячам одновременно. И число таких атак в прошлом году выросло на 83%. Одна из причин — изменение экономики киберугроз. По оценкам участников рынка, стоимость организации DDoS-атак за последние два десятилетия снизилась примерно в тысячу раз. Сегодня такие услуги продаются по модели массового сервиса: они доступны широкому кругу заказчиков и не требуют высокой технической квалификации. Одновременно меняется характер самих атак. Всё чаще злоумышленники распределяют трафик сразу на тысячи или десятки тысяч ресурсов. В результате выбор конкретной жертвы становится менее важным, а риск столкнуться с атакой возникает практически у любого владельца сайта. Для бизнеса это означает изменение подхода к информационной безопасности. Вопрос уже не в том, произойдет ли атака, а в том, насколько инфраструктура готова сохранить работоспособность сервисов в случае инцидента. Почему традиционная модель защиты теряет эффективность На протяжении многих лет защита от DDoS строилась по простой схеме: компания размещала сайт, а при необходимости подключала отдельный сервис фильтрации трафика. Такой подход был оправдан, пока атаки оставались относительно редкими и были нацелены преимущественно на крупные ресурсы. Сегодня он всё чаще сталкивается с ограничениями. 	Первая проблема — цена. Профессиональные сервисы защиты от DDoS-атак могут стоить десятки и даже сотни тысяч рублей в год. Для крупных компаний такие расходы оправданы, однако для большинства сайтов на виртуальном хостинге стоимость защиты нередко оказывается выше стоимости самой инфраструктуры, которую она должна защищать. 	Вторая проблема — архитектура. Внешние сервисы требуют дополнительной интеграции. Владельцам сайтов приходится менять DNS-настройки, корректировать сетевую архитектуру и передавать часть управления сторонним поставщикам услуг. 	Третья проблема — сами атаки становятся сложнее. Всё чаще злоумышленники работают на уровне приложений (L7), имитируя действия обычных пользователей. Такой трафик значительно сложнее отличить от легитимного, поэтому традиционные механизмы фильтрации оказываются менее эффективными. Показательный пример — ботнет Kimwolf. В марте 2026 года он объединил более 4 млн. зараженных устройств по всему миру и генерировал до 700 тыс. запросов в секунду. На Россию пришлось 6,7% устройств, участвовавших в атаках. Безопасность становится частью инфраструктуры Подобные изменения уже происходили в других сегментах цифровой инфраструктуры. Когда-то SSL/TLS-сертификаты были дополнительной услугой. Резервное копирование также подключалось отдельно. То же можно сказать о системах мониторинга, защите электронной почты и ряде других сервисов. Со временем рынок пришел к выводу, что некоторые функции настолько важны для устойчивой работы цифровых ресурсов, что должны быть встроены в инфраструктуру по умолчанию. Похожий процесс сегодня происходит и с защитой от DDoS-атак. Традиционная модель предполагает, что владелец сайта сначала запускает ресурс, а затем при необходимости подключает внешние средства защиты. Такой подход работал, пока атаки оставались относительно редким явлением и касались преимущественно крупных компаний. Однако в условиях, когда под угрозой может оказаться практически любой сайт, эта модель начинает терять эффективность. Во многом это связано с экономикой самой защиты. Внешние сервисы фильтрации требуют отдельного подключения, настройки и сопровождения. Для многих владельцев сайтов стоимость таких решений оказывается сопоставимой со стоимостью самой инфраструктуры. Кроме того, подключение внешней защиты часто связано с изменением DNS-настроек и IP-адресов. Для фильтрации HTTPS-трафика владельцу сайта нередко приходится передавать стороннему провайдеру SSL/TLS-сертификат и соответствующий закрытый ключ либо предоставлять возможность выпустить новый сертификат для домена. В результате критически важные элементы криптографической защиты оказываются за пределами инфраструктуры владельца ресурса. Поэтому рынок постепенно движется к другому подходу — переносу защитных механизмов непосредственно на уровень хостинговой платформы. В этом случае фильтрация вредоносного трафика становится частью инфраструктуры, а не отдельной надстройкой над ней. Для владельцев сайтов это означает несколько важных изменений: 	 Защита начинает масштабироваться вместе с платформой. Один инфраструктурный контур может одновременно обеспечивать безопасность сотен тысяч сайтов без необходимости подключать отдельные сервисы для каждого ресурса. 	Снижается сложность эксплуатации. Владельцам сайтов больше не нужно менять DNS-настройки, перестраивать сетевую архитектуру или разбираться в особенностях интеграции различных решений безопасности. 	Упрощается экономика защиты. Безопасность перестает быть отдельной статьей расходов и становится частью базовой инфраструктурной услуги. 	Повышается эффективность против современных атак. Поскольку защита встроена непосредственно в платформу, она может анализировать не только источник трафика, но и его поведение. Это особенно важно для противодействия атакам на уровне приложений (L7), которые имитируют действия обычных пользователей и всё чаще обходят традиционные механизмы фильтрации. По сути, рынок движется от модели «защита как отдельная услуга» к модели «защита как свойство инфраструктуры». Так же как сегодня никто не рассматривает резервное копирование или шифрование соединений в качестве дополнительной опции, встроенная защита от DDoS постепенно становится базовым требованием к платформам размещения сайтов. Как меняются требования бизнеса к хостингу Для компаний это означает пересмотр критериев выбора площадки для размещения сайтов. Если раньше основное внимание уделяли стоимости ресурсов, объему дискового пространства или производительности серверов, то сегодня всё большее значение приобретают устойчивость платформы и встроенные механизмы безопасности. Для многих компаний сайт стал не просто корпоративной витриной, а частью бизнес-процессов: каналом продаж, коммуникации с клиентами или основой предоставления цифровых услуг. Даже кратковременная недоступность напрямую влияет на выручку, клиентский опыт и репутацию. Поэтому бизнес всё чаще оценивает не отдельные инструменты защиты, а способность самой платформы обеспечивать непрерывность работы сервисов. Особенно заметен этот тренд среди небольшого бизнеса, где редко существуют собственные команды информационной безопасности и наиболее востребованы решения, в которых критически важные функции уже реализованы на уровне инфраструктуры. #IMAGE_235500#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Заказать DDoS-атаку сегодня дешевле чашки кофе. Злоумышленники тратят от&nbsp;1&lltt;/em&ggtt;&lltt;em&ggtt;&nbsp;рубля за&nbsp;1&nbsp;Мбит/с&nbsp;— это в&nbsp;тысячи раз дешевле, чем 20&nbsp;лет назад. Обсудим, что с&nbsp;этим делать.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;DDoS перестал быть угрозой только для крупных компаний&lltt;/h3&ggtt;
&lltt;p&ggtt;Еще несколько лет назад DDoS-атаки ассоциировались прежде всего с&nbsp;банками, государственными сервисами, интернет-магазинами и&nbsp;крупными медиа. Сегодня ситуация изменилась. Целью атаки может стать практически любой сайт независимо от&nbsp;размера бизнеса или отрасли.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;данным сервиса Statonline.ru, более&nbsp;90% ресурсов Рунета размещены на&nbsp;виртуальном хостинге. И&nbsp;каждый из&nbsp;них потенциально может стать целью атаки. Одна из&nbsp;причин&nbsp;— изменение самого характера атак. Они стали «ковровыми»: злоумышленники бьют не&nbsp;по&nbsp;одному сайту, а&nbsp;по&nbsp;тысячам одновременно. И&nbsp;число таких атак в&nbsp;прошлом году &lltt;a href="https://companies.rbc.ru/news/FcIZ5wgrOW/kod-bezopasnosti-predupredil-o-roste-mnogovektornyih-ddos-atak/"&ggtt;выросло&lltt;/a&ggtt; на&nbsp;83%.&lltt;/p&ggtt;
&lltt;p&ggtt;Одна из&nbsp;причин&nbsp;— изменение экономики киберугроз. По&nbsp;оценкам участников рынка, стоимость организации DDoS-атак за&nbsp;последние два десятилетия снизилась примерно в&nbsp;тысячу раз. Сегодня такие услуги продаются по&nbsp;модели массового сервиса: они доступны широкому кругу заказчиков и&nbsp;не&nbsp;требуют высокой технической квалификации.&lltt;/p&ggtt;
&lltt;p&ggtt;Одновременно меняется характер самих атак. Всё чаще злоумышленники распределяют трафик сразу на&nbsp;тысячи или десятки тысяч ресурсов. В&nbsp;результате выбор конкретной жертвы становится менее важным, а&nbsp;риск столкнуться с&nbsp;атакой возникает практически у&nbsp;любого владельца сайта.&lltt;/p&ggtt;
&lltt;p&ggtt;Для бизнеса это означает изменение подхода к&nbsp;информационной безопасности. Вопрос уже не&nbsp;в&nbsp;том, произойдет&nbsp;ли атака, а&nbsp;в&nbsp;том, насколько инфраструктура готова сохранить работоспособность сервисов в&nbsp;случае инцидента.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему традиционная модель защиты теряет эффективность&lltt;/h3&ggtt;
&lltt;p&ggtt;На&nbsp;протяжении многих лет защита от&nbsp;DDoS строилась по&nbsp;простой схеме: компания размещала сайт, а&nbsp;при необходимости подключала отдельный сервис фильтрации трафика.&lltt;/p&ggtt;
&lltt;p&ggtt;Такой подход был оправдан, пока атаки оставались относительно редкими и&nbsp;были нацелены преимущественно на&nbsp;крупные ресурсы. Сегодня он&nbsp;всё чаще сталкивается с&nbsp;ограничениями.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Первая проблема&nbsp;— цена. &lltt;/strong&ggtt;Профессиональные сервисы защиты от&nbsp;DDoS-атак могут стоить десятки и&nbsp;даже сотни тысяч рублей в&nbsp;год. Для крупных компаний такие расходы оправданы, однако для большинства сайтов на&nbsp;виртуальном хостинге стоимость защиты нередко оказывается выше стоимости самой инфраструктуры, которую она должна защищать.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Вторая проблема&nbsp;— архитектура.&lltt;/strong&ggtt; Внешние сервисы требуют дополнительной интеграции. Владельцам сайтов приходится менять DNS-настройки, корректировать сетевую архитектуру и&nbsp;передавать часть управления сторонним поставщикам услуг.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Третья проблема&nbsp;— сами атаки становятся сложнее.&lltt;/strong&ggtt; Всё чаще злоумышленники работают на&nbsp;уровне приложений (L7), имитируя действия обычных пользователей. Такой трафик значительно сложнее отличить от&nbsp;легитимного, поэтому традиционные механизмы фильтрации оказываются менее эффективными.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Показательный пример&nbsp;— ботнет Kimwolf. В&nbsp;марте 2026 года он&nbsp;&lltt;a href="https://www.gazeta.ru/tech/news/2026/03/18/28080523.shtml?utm_auth=false"&ggtt;объединил&lltt;/a&ggtt; более 4&nbsp;млн. зараженных устройств по&nbsp;всему миру и&nbsp;генерировал до&nbsp;700&nbsp;тыс. запросов в&nbsp;секунду. На&nbsp;Россию пришлось 6,7% устройств, участвовавших в&nbsp;атаках.&lltt;/p&ggtt;
&lltt;h3&ggtt;Безопасность становится частью инфраструктуры&lltt;/h3&ggtt;
&lltt;p&ggtt;Подобные изменения уже происходили в&nbsp;других сегментах цифровой инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Когда-то SSL/TLS-сертификаты были дополнительной услугой. Резервное копирование также подключалось отдельно. То&nbsp;же можно сказать о&nbsp;системах мониторинга, защите электронной почты и&nbsp;ряде других сервисов. Со&nbsp;временем рынок пришел к&nbsp;выводу, что некоторые функции настолько важны для устойчивой работы цифровых ресурсов, что должны быть встроены в&nbsp;инфраструктуру по&nbsp;умолчанию.&lltt;/p&ggtt;
&lltt;p&ggtt;Похожий процесс сегодня происходит и&nbsp;с&nbsp;защитой от&nbsp;DDoS-атак.&lltt;/p&ggtt;
&lltt;p&ggtt;Традиционная модель предполагает, что владелец сайта сначала запускает ресурс, а&nbsp;затем при необходимости подключает внешние средства защиты. Такой подход работал, пока атаки оставались относительно редким явлением и&nbsp;касались преимущественно крупных компаний. Однако в&nbsp;условиях, когда под угрозой может оказаться практически любой сайт, эта модель начинает терять эффективность.&lltt;/p&ggtt;
&lltt;p&ggtt;Во&nbsp;многом это связано с&nbsp;экономикой самой защиты. Внешние сервисы фильтрации требуют отдельного подключения, настройки и&nbsp;сопровождения. Для многих владельцев сайтов стоимость таких решений оказывается сопоставимой со&nbsp;стоимостью самой инфраструктуры. Кроме того, подключение внешней защиты часто связано с&nbsp;изменением DNS-настроек и&nbsp;IP-адресов. Для фильтрации HTTPS-трафика владельцу сайта нередко приходится передавать стороннему провайдеру SSL/TLS-сертификат и&nbsp;соответствующий закрытый ключ либо предоставлять возможность выпустить новый сертификат для домена. В&nbsp;результате критически важные элементы криптографической защиты оказываются за&nbsp;пределами инфраструктуры владельца ресурса.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому рынок постепенно движется к&nbsp;другому подходу&nbsp;— переносу защитных механизмов непосредственно на&nbsp;уровень хостинговой платформы. В&nbsp;этом случае фильтрация вредоносного трафика становится частью инфраструктуры, а&nbsp;не&nbsp;отдельной надстройкой над ней.&lltt;/p&ggtt;
&lltt;p&ggtt;Для владельцев сайтов это означает несколько важных изменений:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Защита начинает масштабироваться вместе с&nbsp;платформой. &lltt;/strong&ggtt;Один инфраструктурный контур может одновременно обеспечивать безопасность сотен тысяч сайтов без необходимости подключать отдельные сервисы для каждого ресурса.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Снижается сложность эксплуатации. &lltt;/strong&ggtt;Владельцам сайтов больше не&nbsp;нужно менять DNS-настройки, перестраивать сетевую архитектуру или разбираться в&nbsp;особенностях интеграции различных решений безопасности.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Упрощается экономика защиты.&lltt;/strong&ggtt; Безопасность перестает быть отдельной статьей расходов и&nbsp;становится частью базовой инфраструктурной услуги.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Повышается эффективность против современных атак. &lltt;/strong&ggtt;Поскольку защита встроена непосредственно в&nbsp;платформу, она может анализировать не&nbsp;только источник трафика, но&nbsp;и&nbsp;его поведение. Это особенно важно для противодействия атакам на&nbsp;уровне приложений (L7), которые имитируют действия обычных пользователей и&nbsp;всё чаще обходят традиционные механизмы фильтрации.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;По&nbsp;сути, рынок движется от&nbsp;модели «защита как отдельная услуга» к&nbsp;модели «защита как свойство инфраструктуры». Так&nbsp;же как сегодня никто не&nbsp;рассматривает резервное копирование или шифрование соединений в&nbsp;качестве дополнительной опции, встроенная защита от&nbsp;DDoS постепенно становится базовым требованием к&nbsp;платформам размещения сайтов.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как меняются требования бизнеса к&nbsp;хостингу&lltt;/h3&ggtt;
&lltt;p&ggtt;Для компаний это означает пересмотр критериев выбора площадки для размещения сайтов.&lltt;/p&ggtt;
&lltt;p&ggtt;Если раньше основное внимание уделяли стоимости ресурсов, объему дискового пространства или производительности серверов, то&nbsp;сегодня всё большее значение приобретают устойчивость платформы и&nbsp;встроенные механизмы безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;Для многих компаний сайт стал не&nbsp;просто корпоративной витриной, а&nbsp;частью бизнес-процессов: каналом продаж, коммуникации с&nbsp;клиентами или основой предоставления цифровых услуг. Даже кратковременная недоступность напрямую влияет на&nbsp;выручку, клиентский опыт и&nbsp;репутацию.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому бизнес всё чаще оценивает не&nbsp;отдельные инструменты защиты, а&nbsp;способность самой платформы обеспечивать непрерывность работы сервисов.&lltt;/p&ggtt;
&lltt;p&ggtt;Особенно заметен этот тренд среди небольшого бизнеса, где редко существуют собственные команды информационной безопасности и&nbsp;наиболее востребованы решения, в&nbsp;которых критически важные функции уже реализованы на&nbsp;уровне инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235500#&lltt;/p&ggtt;]]></source>
<adate>10.09.2026</adate>
<dbid>235499</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/461/vqd7w6mp134q2mod3rx6slestahfslxs.jpg]]>
</images>
<imagesname><![CDATA[;;Валентин Бостанов, руководитель направления хостинга &#8220;Руцентра&#8221;   ]]></imagesname>
<tag><![CDATA[Безопасность;;Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[Новый релиз Security Vision 5: гибкое хранение событий, автоматизация обслуживания БД и развитие виджетов]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235503]]></link>
<description><![CDATA[Компания Security Vision представила очередное обновление платформ. Релиз расширяет возможности управления хранением и доступом к событиям, автоматизирует обслуживание базы данных, упрощает изменение типов событий и развивает сценарии работы с аналитическими виджетами и настройками Платформы. В Платформе появилась настройка горячего и холодного хранения событий. Для типов событий можно задать период нахождения в горячем хранилище, срок хранения в холодном и последующее удаление. Это позволяет переносить архивные события на более медленные диски и гибко управлять сроками их хранения. Доступ к событиям и алертам теперь учитывает организацию пользователя. События и алерты, для которых указана организация, доступны в соответствии с организационной принадлежностью пользователя. Таким образом, механизм Multitenancy распространяется на данные событий и алертов. Добавлены системные настройки для автоматического обслуживания БД Платформы: выполнение VACUUM, перестроение индексов и установка необходимых значений ключевых параметров производительности. Операции обслуживания можно выполнять по настроенному расписанию. В форме ввода свойства типа «Файл» появилась настройка, запрещающая загрузку исполняемых файлов. Для многострочного свойства типа «Строка» с автоматической шириной предусмотрено значение «Не задано», которое возвращает поле к ширине на весь блок карточки. Для форм ввода и вывода свойств также добавлена подсветка синтаксиса кода. Состав свойств типа события теперь можно изменять без реиндексации хранилища: добавлять новые свойства и удалять существующие. Это упрощает изменение структуры типов событий при развитии модели данных. Обновлён интерфейс раздела лицензирования и добавлена отдельная страница с информацией о лицензии. Если лицензия отсутствует или срок её действия завершён, соответствующая главная страница теперь отображается ещё до входа в Платформу. В виджетах добавлены действия, по выполнению которых открываются представления типа «Ссылка на внутренний URL». Также реализована возможность группировать объекты в кластеры по заданным условиям на базе постоянных и динамических значений: входных параметров, переменных и результатов блока]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания Security Vision представила очередное обновление платформ. Релиз расширяет возможности управления хранением и доступом к событиям, автоматизирует обслуживание базы данных, упрощает изменение типов событий и развивает сценарии работы с аналитическими виджетами и настройками Платформы.&lltt;/p&ggtt;
&lltt;p&ggtt;В Платформе появилась настройка горячего и холодного хранения событий. Для типов событий можно задать период нахождения в горячем хранилище, срок хранения в холодном и последующее удаление. Это позволяет переносить архивные события на более медленные диски и гибко управлять сроками их хранения.&lltt;/p&ggtt;
&lltt;p&ggtt;Доступ к событиям и алертам теперь учитывает организацию пользователя. События и алерты, для которых указана организация, доступны в соответствии с организационной принадлежностью пользователя. Таким образом, механизм Multitenancy распространяется на данные событий и алертов.&lltt;/p&ggtt;
&lltt;p&ggtt;Добавлены системные настройки для автоматического обслуживания БД Платформы: выполнение VACUUM, перестроение индексов и установка необходимых значений ключевых параметров производительности. Операции обслуживания можно выполнять по настроенному расписанию.&lltt;/p&ggtt;
&lltt;p&ggtt;В форме ввода свойства типа «Файл» появилась настройка, запрещающая загрузку исполняемых файлов. Для многострочного свойства типа «Строка» с автоматической шириной предусмотрено значение «Не задано», которое возвращает поле к ширине на весь блок карточки. Для форм ввода и вывода свойств также добавлена подсветка синтаксиса кода.&lltt;/p&ggtt;
&lltt;p&ggtt;Состав свойств типа события теперь можно изменять без реиндексации хранилища: добавлять новые свойства и удалять существующие. Это упрощает изменение структуры типов событий при развитии модели данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Обновлён интерфейс раздела лицензирования и добавлена отдельная страница с информацией о лицензии. Если лицензия отсутствует или срок её действия завершён, соответствующая главная страница теперь отображается ещё до входа в Платформу.&lltt;/p&ggtt;
&lltt;p&ggtt;В виджетах добавлены действия, по выполнению которых открываются представления типа «Ссылка на внутренний URL». Также реализована возможность группировать объекты в кластеры по заданным условиям на базе постоянных и динамических значений: входных параметров, переменных и результатов блока.&lltt;/p&ggtt;]]></source>
<adate>09.09.2026</adate>
<dbid>235503</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Angara MTDR: ИТ-отрасль была главной целью киберпреступников в 2025 году]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235502]]></link>
<description><![CDATA[Сфера информационных технологий в 2025 году стала самой атакуемой отраслью в стране — на нее пришлось 29% зафиксированных киберинцидентов. При этом нередко злоумышленники рассматривают ИТ-компании как точку входа в инфраструктуру конечной цели. Далее по числу атак следуют финансы и страхование (17%), ритейл и торговля (12%), здравоохранение и транспортно-логистический сектор (по 8%). Такие данные приведены в исследовании «От реагирования к предотвращению: инциденты 2025», подготовленном экспертами отдела реагирования и цифровой криминалистики Angara MTDR. В основе исследования лежат десятки успешных расследованных кейсов, каждый из которых привнес уникальный контекст, будь то финансовый сектор, промышленность, ретейл или отдельные государственные структуры. Что касается мотивации атакующих, наибольшая доля расследованных компанией инцидентов пришлась на атаки с целью шпионажа (40%), еще 25% — на хактивизм, и 15% на классическую финансовую мотивацию. В 20% случаев точно установить мотивацию атакующих не удалось. Существенную часть инцидентов также составили кампании, которые можно отнести к APT-группировкам. Их организаторы заинтересованы не только в немедленной выгоде, но и в длительном скрытном присутствии в инфраструктуре жертвы. Как отмечают исследователи, значительные изменения за прошлый год претерпел хактивизм. Если раньше в эту категорию, как правило, попадали группировки, ориентированные на публичный эффект и шум, то в 2025 году значительная часть подобных атак была связана с нанесением российским организациям максимального ущерба. Вместе с этим усложнился и сам ландшафт киберпреступности. С одной стороны, появились новые кластеры активности (группы, которые объединены общими инструментами, тактиками и целями), с другой — усложнилась точная атрибуция инцидентов. Например, то, что первоначально выглядело как случайная активность, во время расследования нередко оказывалось частью хорошо подготовленной кампании. Отдельно аналитики подчеркивают, что инструментарий атакующих все чаще дополнялся решениями на основе ИИ. В 2025 году в компании столкнулись не только с использованием сгенерированных сценариев и скриптов для автоматизации рутинных задач, но и со случаями применения C2-агентов, написанных или адаптированных с помощью ИИ. Порог входа для создания кастомного инструментария снижается, что усложняет сигнатурное обнаружение и ускоряет появление новых вредоносных программ. Медианный показатель обнаружения злоумышленников по итогам 2025 года составил 17 дней. В атаках с использованием программ-вымогателей показатель был ниже — всего 7 дней. Однако подобные атаки разворачиваются настолько быстро, что даже за этот срок компании чаще всего узнавали о взломе уже на финальной стадии. Если говорить об инцидентах в целом, то почти в половине случаев (45%) на обнаружение атаки уходило больше месяца: 15% атак обнаруживались в срок от месяца до полугода, 5% — от полугода до года, а 25% присутствовали в инфраструктуре больше года. Часть таких долгих случаев связана с низкоквалифицированными атаками ботнет-сетей, размещающих майнеры на уязвимых серверах, а другая — с деятельностью группировок, специализирующихся на шпионаже. «Количество и разнообразие киберугроз растет с каждым годом. Тем не менее мы видим, что в прошлом году заметно выросла доля организаций, которые быстрее реагирует на инциденты и подозрительную активность, охотнее взаимодействуют с командами реагирования и осознаннее инвестируют в защиту. Это однозначно позитивная тенденция. Но потенциал для роста в области кибербезопасности остается значительным, особенно в части проактивного обнаружения угроз и готовности к восстановлению после инцидентов», — добавил Артем Грибков, заместитель генерального директора Angara MTDR]]></description>
<source><![CDATA[&lltt;p&ggtt;Сфера информационных технологий в 2025 году стала самой атакуемой отраслью в стране — на нее пришлось 29% зафиксированных киберинцидентов. При этом нередко злоумышленники рассматривают ИТ-компании как точку входа в инфраструктуру конечной цели. Далее по числу атак следуют финансы и страхование (17%), ритейл и торговля (12%), здравоохранение и транспортно-логистический сектор (по 8%).&lltt;/p&ggtt;
&lltt;p&ggtt;Такие данные приведены в исследовании «От реагирования к предотвращению: инциденты 2025», подготовленном экспертами отдела реагирования и цифровой криминалистики Angara MTDR. В основе исследования лежат десятки успешных расследованных кейсов, каждый из которых привнес уникальный контекст, будь то финансовый сектор, промышленность, ретейл или отдельные государственные структуры. &lltt;/p&ggtt;
&lltt;p&ggtt;Что касается мотивации атакующих, наибольшая доля расследованных компанией инцидентов пришлась на атаки с целью шпионажа (40%), еще 25% — на хактивизм, и 15% на классическую финансовую мотивацию. В 20% случаев точно установить мотивацию атакующих не удалось. Существенную часть инцидентов также составили кампании, которые можно отнести к APT-группировкам. Их организаторы заинтересованы не только в немедленной выгоде, но и в длительном скрытном присутствии в инфраструктуре жертвы.&lltt;/p&ggtt;
&lltt;p&ggtt;Как отмечают исследователи, значительные изменения за прошлый год претерпел хактивизм. Если раньше в эту категорию, как правило, попадали группировки, ориентированные на публичный эффект и шум, то в 2025 году значительная часть подобных атак была связана с нанесением российским организациям максимального ущерба.&lltt;/p&ggtt;
&lltt;p&ggtt;Вместе с этим усложнился и сам ландшафт киберпреступности. С одной стороны, появились новые кластеры активности (группы, которые объединены общими инструментами, тактиками и целями), с другой — усложнилась точная атрибуция инцидентов. Например, то, что первоначально выглядело как случайная активность, во время расследования нередко оказывалось частью хорошо подготовленной кампании.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельно аналитики подчеркивают, что инструментарий атакующих все чаще дополнялся решениями на основе ИИ. В 2025 году в компании столкнулись не только с использованием сгенерированных сценариев и скриптов для автоматизации рутинных задач, но и со случаями применения C2-агентов, написанных или адаптированных с помощью ИИ. Порог входа для создания кастомного инструментария снижается, что усложняет сигнатурное обнаружение и ускоряет появление новых вредоносных программ.&lltt;/p&ggtt;
&lltt;p&ggtt;Медианный показатель обнаружения злоумышленников по итогам 2025 года составил 17 дней. В атаках с использованием программ-вымогателей показатель был ниже — всего 7 дней. Однако подобные атаки разворачиваются настолько быстро, что даже за этот срок компании чаще всего узнавали о взломе уже на финальной стадии. Если говорить об инцидентах в целом, то почти в половине случаев (45%) на обнаружение атаки уходило больше месяца: 15% атак обнаруживались в срок от месяца до полугода, 5% — от полугода до года, а 25% присутствовали в инфраструктуре больше года. Часть таких долгих случаев связана с низкоквалифицированными атаками ботнет-сетей, размещающих майнеры на уязвимых серверах, а другая — с деятельностью группировок, специализирующихся на шпионаже.&lltt;/p&ggtt;
&lltt;p&ggtt;«Количество и разнообразие киберугроз растет с каждым годом. Тем не менее мы видим, что в прошлом году заметно выросла доля организаций, которые быстрее реагирует на инциденты и подозрительную активность, охотнее взаимодействуют с командами реагирования и осознаннее инвестируют в защиту. Это однозначно позитивная тенденция. Но потенциал для роста в области кибербезопасности остается значительным, особенно в части проактивного обнаружения угроз и готовности к восстановлению после инцидентов», — добавил Артем Грибков, заместитель генерального директора Angara MTDR.&lltt;/p&ggtt;]]></source>
<adate>09.09.2026</adate>
<dbid>235502</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Forrester: ИИ может переписать код, но не может восстановить намерения]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235501]]></link>
<description><![CDATA[На протяжении десятилетий критически важные приложения накапливали бизнес-правила, интеграции, обходные пути и зависимости быстрее, чем организации успевали их документировать, пишет в корпоративном блоге Бишваджит Махапатра, главный аналитик Forrester. Документация неполна, первоначальные разработчики ушли, а специалисты по приложениям выходят на пенсию, унося с собой свои критически важные институциональные знания. В результате возникает бизнес-проблема, замаскированная под технологическую. Команды по модернизации сталкиваются со скрытыми зависимостями, неожиданными требованиями и дорогостоящими переделками, потому что они не до конца понимают системы, которые пытаются изменить. Но прежде чем решать, что переписать, рефакторизовать, заменить или вывести из эксплуатации, CIO должны сначала получить ответ ответить на более фундаментальный вопрос: как на самом деле работает приложение? Искусственный интеллект меняет экономику ответа на этот вопрос. То, что раньше требовало месяцев ручного поиска, теперь можно ускорить с помощью анализа, поддерживаемого ИИ. Мне бы хотелось представить эту возможность как более глубокие знания, а не как более быстрое документирование, и что с более глубокими знаниями приходят более эффективные решения по модернизации. ИИ раскрывает поведение, но не намерения ИИ может анализировать исходный код, документацию, API, конфигурацию, операционную телеметрию, инциденты и историю изменений гораздо быстрее, чем ручные методы обнаружения. Все чаще платформы обнаружения организуют эти данные в графы знаний, которые связывают приложения, данные, сервисы, интеграции и бизнес-правила в рамках всей инфраструктуры. Такое взаимосвязанное представление помогает командам выявлять скрытые зависимости, оценивать риски интеграции, обнаруживать дублирующуюся логику и понимать, как приложения фактически ведут себя до начала модернизации. Но поведение — это не намерение. Правило, найденное в коде, может представлять собой допустимое бизнес-требование, устаревшую политику, обходной путь для устаревшей системы или дефект, который оставался незамеченным годами. Платформы обнаружения могут идентифицировать правило. Они не могут определить, отвечает ли оно будущему состоянию приложения. Модернизация требует подтверждения того, что обнаружено В большинстве систем недостающий контекст находится у людей, которые управляют системой. Они знают, какие правила отражают нормативные обязательства, какие поддерживают законные бизнес-исключения, а какие существуют просто потому, что их никто не удалил. Граф может идентифицировать правило. Только люди могут объяснить, почему это существует и соответствует ли это будущему состоянию приложения. Таким образом, модернизация требует двух форм обнаружения, но большинство программ финансируют только одну. Автоматизированная часть собирает, анализирует и отображает ресурсы приложений. Человеческая часть проверяет бизнес-цели посредством структурированных интервью с пользователями, операторами и владельцами бизнеса, а затем записывает эти решения как подтвержденные правила. Демонстрации поставщиков сосредоточены на первой половине. Успешные программы модернизации вкладывают равные средства и в первую, и во вторую. Это создает новое ограничение на реализацию. Поскольку ИИ сокращает циклы разработки и проверки, доступ к бизнес-экспертам становится узким местом. Команды обнаружения могут выявлять правила за считанные минуты, но проверка этих правил по-прежнему зависит от людей, которые их понимают. Организации, в которых команды модернизации дистанцированы от заинтересованных сторон бизнеса, могут обнаружить, что задержка принятия решений заменяет техническую сложность в качестве основного ограничения на реализацию. Пусть ИИ реализует архитектуру, а не изобретает ее Понимание текущего приложения — это половина задачи. Без архитектурного руководства ИИ будет переписывать код, сохраняя при этом тесные взаимосвязи, устаревшие шаблоны интеграции и накопленный долг. В результате получается работающий на устаревшей архитектуре современный код, который внедряется быстрее, чем когда-либо. Модернизация успешна, когда понимание текущего состояния сочетается с намерениями достижения целевого состояния. Доменные модели, ограниченные контексты, утвержденные шаблоны интеграции, средства контроля безопасности и архитектурные стандарты обеспечивают ограничения, необходимые ИИ для эффективной работы. ИИ может внедрять архитектурные решения в масштабе. Он не должен их принимать. Последовательность проста. Проверенные бизнес-правила определяют доменные модели. Доменные модели формируют архитектурные шаблоны. Архитектурные шаблоны становятся инженерными шаблонами. ИИ генерирует и рефакторит в этих рамках, а автоматизированное тестирование, проверка безопасности, проверка соответствия архитектуры и человеческий анализ подтверждают, что эта работа улучшает приложение, а не воспроизводит его. Организации, которые больше всего выиграют от модернизации с помощью ИИ, будут не теми, кто быстрее всего генерирует код. Это будут те, кто сохранит институциональные знания до того, как они исчезнут, подтвердит, какие бизнес-правила все еще важны, и целенаправленно спроектирует архитектуру, которую они хотят использовать в будущем. ИИ может ускорить каждое из этих действий. Он не может решить, какие части прошлого заслуживают места в будущем]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;На протяжении десятилетий критически важные приложения накапливали бизнес-правила, интеграции, обходные пути и зависимости быстрее, чем организации успевали их документировать, пишет в корпоративном блоге Бишваджит Махапатра, главный аналитик &lltt;/em&ggtt;&lltt;em&ggtt;Forrester&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Документация неполна, первоначальные разработчики ушли, а специалисты по приложениям выходят на пенсию, унося с собой свои критически важные институциональные знания. В результате возникает бизнес-проблема, замаскированная под технологическую. Команды по модернизации сталкиваются со скрытыми зависимостями, неожиданными требованиями и дорогостоящими переделками, потому что они не до конца понимают системы, которые пытаются изменить.&lltt;/p&ggtt;
&lltt;p&ggtt;Но прежде чем решать, что переписать, рефакторизовать, заменить или вывести из эксплуатации, CIO должны сначала получить ответ ответить на более фундаментальный вопрос: как на самом деле работает приложение?&lltt;/p&ggtt;
&lltt;p&ggtt;Искусственный интеллект меняет экономику ответа на этот вопрос. То, что раньше требовало месяцев ручного поиска, теперь можно ускорить с помощью анализа, поддерживаемого ИИ. Мне бы хотелось представить эту возможность как более глубокие знания, а не как более быстрое документирование, и что с более глубокими знаниями приходят более эффективные решения по модернизации.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ раскрывает поведение, но не намерения&lltt;/h3&ggtt;
&lltt;p&ggtt;ИИ может анализировать исходный код, документацию, API, конфигурацию, операционную телеметрию, инциденты и историю изменений гораздо быстрее, чем ручные методы обнаружения. Все чаще платформы обнаружения организуют эти данные в графы знаний, которые связывают приложения, данные, сервисы, интеграции и бизнес-правила в рамках всей инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Такое взаимосвязанное представление помогает командам выявлять скрытые зависимости, оценивать риски интеграции, обнаруживать дублирующуюся логику и понимать, как приложения фактически ведут себя до начала модернизации.&lltt;/p&ggtt;
&lltt;p&ggtt;Но поведение — это не намерение. Правило, найденное в коде, может представлять собой допустимое бизнес-требование, устаревшую политику, обходной путь для устаревшей системы или дефект, который оставался незамеченным годами. Платформы обнаружения могут идентифицировать правило. Они не могут определить, отвечает ли оно будущему состоянию приложения.&lltt;/p&ggtt;
&lltt;h3&ggtt;Модернизация требует подтверждения того, что обнаружено&lltt;/h3&ggtt;
&lltt;p&ggtt;В большинстве систем недостающий контекст находится у людей, которые управляют системой. Они знают, какие правила отражают нормативные обязательства, какие поддерживают законные бизнес-исключения, а какие существуют просто потому, что их никто не удалил. Граф может идентифицировать правило. Только люди могут объяснить, почему это существует и соответствует ли это будущему состоянию приложения.&lltt;/p&ggtt;
&lltt;p&ggtt;Таким образом, модернизация требует двух форм обнаружения, но большинство программ финансируют только одну. Автоматизированная часть собирает, анализирует и отображает ресурсы приложений. Человеческая часть проверяет бизнес-цели посредством структурированных интервью с пользователями, операторами и владельцами бизнеса, а затем записывает эти решения как подтвержденные правила. Демонстрации поставщиков сосредоточены на первой половине. Успешные программы модернизации вкладывают равные средства и в первую, и во вторую.&lltt;/p&ggtt;
&lltt;p&ggtt;Это создает новое ограничение на реализацию. Поскольку ИИ сокращает циклы разработки и проверки, доступ к бизнес-экспертам становится узким местом. Команды обнаружения могут выявлять правила за считанные минуты, но проверка этих правил по-прежнему зависит от людей, которые их понимают. Организации, в которых команды модернизации дистанцированы от заинтересованных сторон бизнеса, могут обнаружить, что задержка принятия решений заменяет техническую сложность в качестве основного ограничения на реализацию.&lltt;/p&ggtt;
&lltt;h3&ggtt;Пусть ИИ реализует архитектуру, а не изобретает ее&lltt;/h3&ggtt;
&lltt;p&ggtt;Понимание текущего приложения — это половина задачи. Без архитектурного руководства ИИ будет переписывать код, сохраняя при этом тесные взаимосвязи, устаревшие шаблоны интеграции и накопленный долг. В результате получается работающий на устаревшей архитектуре современный код, который внедряется быстрее, чем когда-либо.&lltt;/p&ggtt;
&lltt;p&ggtt;Модернизация успешна, когда понимание текущего состояния сочетается с намерениями достижения целевого состояния. Доменные модели, ограниченные контексты, утвержденные шаблоны интеграции, средства контроля безопасности и архитектурные стандарты обеспечивают ограничения, необходимые ИИ для эффективной работы. ИИ может внедрять архитектурные решения в масштабе. Он не должен их принимать.&lltt;/p&ggtt;
&lltt;p&ggtt;Последовательность проста. Проверенные бизнес-правила определяют доменные модели. Доменные модели формируют архитектурные шаблоны. Архитектурные шаблоны становятся инженерными шаблонами. ИИ генерирует и рефакторит в этих рамках, а автоматизированное тестирование, проверка безопасности, проверка соответствия архитектуры и человеческий анализ подтверждают, что эта работа улучшает приложение, а не воспроизводит его.&lltt;/p&ggtt;
&lltt;p&ggtt;Организации, которые больше всего выиграют от модернизации с помощью ИИ, будут не теми, кто быстрее всего генерирует код. Это будут те, кто сохранит институциональные знания до того, как они исчезнут, подтвердит, какие бизнес-правила все еще важны, и целенаправленно спроектирует архитектуру, которую они хотят использовать в будущем. ИИ может ускорить каждое из этих действий. Он не может решить, какие части прошлого заслуживают места в будущем.&lltt;/p&ggtt;]]></source>
<adate>10.09.2026</adate>
<dbid>235501</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Почему компаниям пора уходить с Confluence и как превратить миграцию в шаг вперед]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235497]]></link>
<description><![CDATA[Еще несколько лет назад Confluence казался для многих компаний вполне рабочим и привычным решением. Даже после ухода Atlassian с российского рынка в 2022 году часть бизнеса продолжала использовать систему в закрытом контуре, откладывая вопрос замены. Но теперь этот сценарий подходит к завершению: on-prem-формат сворачивается, новые лицензии перестают продаваться, а привычная модель работы с Confluence становится все менее устойчивой. Для российских компаний это сигнал, что миграцию больше нельзя откладывать. Перейти в зарубежное облако большинству организаций мешают и требования законодательства, и вопросы безопасности, и общая зависимость от внешней инфраструктуры. Поэтому разговор сейчас идет не о том, «нужно ли менять Confluence», а о том, как сделать это спокойно, без потерь и с пользой для бизнеса. Уже в ближайшие годы возникнут ограничения по расширению лицензий и подключению новых пользователей. А следом наступит и полное завершение поддержки on-prem-формата. В этот момент система станет не просто неудобной, а потенциально опасной: без обновлений, без развития и с растущими рисками для безопасности. Почему искать замену нужно уже сейчас Любая миграция — это полноценный проект. Чем больше в компании материалов, подразделений и пользователей, которые работают с Confluence, тем выше сложность такого проекта. Если затянуть с переходом, высоки риски того, что придется все делать в спешке: разрабатывать конфигурацию нового решения, проверять функциональные требования, переносить данные. Это приводит к потерям, недовольству пользователей и лишним финансовым затратам. Сейчас у бизнеса есть редкая возможность пройти этот путь без спешки: спокойно сформулировать требования, сравнить варианты и выбрать платформу, которая не только заменит Confluence, но и даст запас для дальнейшего развития. Как не попасть в ловушку при поиска альтернатив Confluence Чаще всего компании пытаются найти максимально похожий инструмент, чтобы сохранить привычные сценарии работы с системой. Однако это не всегда лучшее решение. Confluence — платформа, призванная решать задачи, связанные хранением и управлением данными, но не все ее механики хороши. И если искать полную кальку системы, компания рискует сузить выбор и потратить слишком много сил на копирование старой логики там, где можно было бы построить более удобную и современную модель. Поэтому при выборе замены лучше смотреть не на то, насколько новая система похожа на Confluence, а на то, какие бизнес-задачи она закрывает. Важно понять, как в компании хранится информация, кто и как ею пользуется, где нужна жесткая структура, а где — гибкость, и какие сценарии уже сейчас не покрываются текущим решением. Как выстроить миграцию Прежде всего, не стоит воспринимать миграцию как простую замену одной системы на другую. Это хороший повод пересмотреть, как компания вообще работает со знаниями: что действительно нужно переносить, какие сценарии стоит сохранить, а от каких можно отказаться. Ориентироваться лучше не на попытку воспроизвести Confluence один в один, а на реальные бизнес-задачи. Важно понимать, какие процессы система поддерживает сейчас, что понадобится компании в будущем и не пришло ли время собрать разрозненные инструменты в единую платформу. Отдельное внимание стоит уделить выбору решения. Здесь полезно сравнивать не абстрактные функции, а то, как платформа закрывает ваши конкретные сценарии работы. Если в Confluence накоплен большой объем данных, обязательно проверьте наличие мигратора у новой платформы. Для крупного бизнеса также критичны устойчивость системы, ее масштабируемость и способность выдерживать высокую нагрузку. Не менее важен и процесс запуска. Если бизнес крупный, информации и сценариев работы много, начинать стоит с пилотного проекта или проводить запуск постепенно: это даст возможность увидеть слабые места, собрать обратную связь, сформировать группу экспертов по работе с решением. Еще один важный момент — обновление контента. Миграция почти всегда показывает, что значительная часть старых материалов уже неактуальна. Перенос — удобный момент, чтобы избавиться от лишнего, пересмотреть структуру и не тащить в новую систему цифровой балласт. Наконец, стоит заранее решить, что делать с текущей структурой Confluence. Если она логична и удобна, ее можно сохранить в новой системе. Если же пространство со временем превратилось в набор разрозненных блоков, миграция дает шанс собрать все в единый корпоративный портал и сделать работу с информацией более прозрачной и управляемой. Миграцию с Confluence стоит воспринимать не как вынужденную замену решения, а как возможность пересобрать подход к управлению знаниями. Если сделать это вдумчиво, компания получит не просто новую платформу, а более зрелую среду для хранения, поиска, обновления и использования информации. #IMAGE_235498#]]></description>
<source><![CDATA[&lltt;p&ggtt;Еще несколько лет назад Confluence казался для многих компаний вполне рабочим и&nbsp;привычным решением. Даже после ухода Atlassian с&nbsp;российского рынка в&nbsp;2022 году часть бизнеса продолжала использовать систему в&nbsp;закрытом контуре, откладывая вопрос замены. Но&nbsp;теперь этот сценарий подходит к&nbsp;завершению: on-prem-формат сворачивается, новые лицензии перестают продаваться, а&nbsp;привычная модель работы с&nbsp;Confluence становится все менее устойчивой.&lltt;/p&ggtt;
&lltt;p&ggtt;Для российских компаний это сигнал, что миграцию больше нельзя откладывать. Перейти в&nbsp;зарубежное облако большинству организаций мешают и&nbsp;требования законодательства, и&nbsp;вопросы безопасности, и&nbsp;общая зависимость от&nbsp;внешней инфраструктуры. Поэтому разговор сейчас идет не&nbsp;о&nbsp;том, «нужно&nbsp;ли менять Confluence», а&nbsp;о&nbsp;том, как сделать это спокойно, без потерь и&nbsp;с&nbsp;пользой для бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;Уже в&nbsp;ближайшие годы возникнут ограничения по&nbsp;расширению лицензий и&nbsp;подключению новых пользователей. А&nbsp;следом наступит и&nbsp;полное завершение поддержки on-prem-формата. В&nbsp;этот момент система станет не&nbsp;просто неудобной, а&nbsp;потенциально опасной: без обновлений, без развития и&nbsp;с&nbsp;растущими рисками для безопасности.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему искать замену нужно уже сейчас&lltt;/h3&ggtt;
&lltt;p&ggtt;Любая миграция&nbsp;— это полноценный проект. Чем больше в&nbsp;компании материалов, подразделений и&nbsp;пользователей, которые работают с&nbsp;Confluence, тем выше сложность такого проекта. Если затянуть с&nbsp;переходом, высоки риски того, что придется все делать в&nbsp;спешке: разрабатывать конфигурацию нового решения, проверять функциональные требования, переносить данные. Это приводит к&nbsp;потерям, недовольству пользователей и&nbsp;лишним финансовым затратам.&lltt;/p&ggtt;
&lltt;p&ggtt;Сейчас у&nbsp;бизнеса есть редкая возможность пройти этот путь без спешки: спокойно сформулировать требования, сравнить варианты и&nbsp;выбрать платформу, которая не&nbsp;только заменит Confluence, но&nbsp;и&nbsp;даст запас для дальнейшего развития.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как не&nbsp;попасть в&nbsp;ловушку при поиска альтернатив Confluence&lltt;/h3&ggtt;
&lltt;p&ggtt;Чаще всего компании пытаются найти максимально похожий инструмент, чтобы сохранить привычные сценарии работы с&nbsp;системой. Однако это не&nbsp;всегда лучшее решение. Confluence&nbsp;— платформа, призванная решать задачи, связанные хранением и&nbsp;управлением данными, но&nbsp;не&nbsp;все ее&nbsp;механики хороши. И&nbsp;если искать полную кальку системы, компания рискует сузить выбор и&nbsp;потратить слишком много сил на&nbsp;копирование старой логики там, где можно было&nbsp;бы построить более удобную и&nbsp;современную модель.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому при выборе замены лучше смотреть не&nbsp;на&nbsp;то, насколько новая система похожа на&nbsp;Confluence, а&nbsp;на&nbsp;то, какие бизнес-задачи она закрывает. Важно понять, как в&nbsp;компании хранится информация, кто и&nbsp;как ею&nbsp;пользуется, где нужна жесткая структура, а&nbsp;где&nbsp;— гибкость, и&nbsp;какие сценарии уже сейчас не&nbsp;покрываются текущим решением.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как выстроить миграцию&lltt;/h3&ggtt;
&lltt;p&ggtt;Прежде всего, не&nbsp;стоит воспринимать миграцию как простую замену одной системы на&nbsp;другую. Это хороший повод пересмотреть, как компания вообще работает со&nbsp;знаниями: что действительно нужно переносить, какие сценарии стоит сохранить, а&nbsp;от&nbsp;каких можно отказаться.&lltt;/p&ggtt;
&lltt;p&ggtt;Ориентироваться лучше не&nbsp;на&nbsp;попытку воспроизвести Confluence один в&nbsp;один, а&nbsp;на&nbsp;реальные бизнес-задачи. Важно понимать, какие процессы система поддерживает сейчас, что понадобится компании в&nbsp;будущем и&nbsp;не&nbsp;пришло&nbsp;ли время собрать разрозненные инструменты в&nbsp;единую платформу.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельное внимание стоит уделить выбору решения. Здесь полезно сравнивать не&nbsp;абстрактные функции, а&nbsp;то, как платформа закрывает ваши конкретные сценарии работы. Если в&nbsp;Confluence накоплен большой объем данных, обязательно проверьте наличие мигратора у&nbsp;новой платформы. Для крупного бизнеса также критичны устойчивость системы, ее&nbsp;масштабируемость и&nbsp;способность выдерживать высокую нагрузку.&lltt;/p&ggtt;
&lltt;p&ggtt;Не&nbsp;менее важен и&nbsp;процесс запуска. Если бизнес крупный, информации и&nbsp;сценариев работы много, начинать стоит с&nbsp;пилотного проекта или проводить запуск постепенно: это даст возможность увидеть слабые места, собрать обратную связь, сформировать группу экспертов по&nbsp;работе с&nbsp;решением.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще один важный момент&nbsp;— обновление контента. Миграция почти всегда показывает, что значительная часть старых материалов уже неактуальна. Перенос&nbsp;— удобный момент, чтобы избавиться от&nbsp;лишнего, пересмотреть структуру и&nbsp;не&nbsp;тащить в&nbsp;новую систему цифровой балласт.&lltt;/p&ggtt;
&lltt;p&ggtt;Наконец, стоит заранее решить, что делать с&nbsp;текущей структурой Confluence. Если она логична и&nbsp;удобна, ее&nbsp;можно сохранить в&nbsp;новой системе. Если&nbsp;же пространство со&nbsp;временем превратилось в&nbsp;набор разрозненных блоков, миграция дает шанс собрать все в&nbsp;единый корпоративный портал и&nbsp;сделать работу с&nbsp;информацией более прозрачной и&nbsp;управляемой.&lltt;/p&ggtt;
&lltt;p&ggtt;Миграцию с&nbsp;Confluence стоит воспринимать не&nbsp;как вынужденную замену решения, а&nbsp;как возможность пересобрать подход к&nbsp;управлению знаниями. Если сделать это вдумчиво, компания получит не&nbsp;просто новую платформу, а&nbsp;более зрелую среду для хранения, поиска, обновления и&nbsp;использования информации.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235498#&lltt;/p&ggtt;]]></source>
<adate>10.09.2026</adate>
<dbid>235497</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/3d1/x1ad23y058gzsj7gey8jz2kkp9q8332c.jpg]]>
</images>
<imagesname><![CDATA[;;Дмитрий Лактионов, руководитель продуктового направления компании BSS   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Не модели, а инфраструктура: что мешает ИИ изменить логистику уже сегодня]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235493]]></link>
<description><![CDATA[Логистика с ее сложными процессами и огромными массивами данных — одна из тех отраслей, где искусственный интеллект способен изменить саму архитектуру бизнеса. Однако произойдет это не благодаря появлению очередной языковой модели. Рассмотрим, из каких уровней складывается ИИ-инфраструктура и какие ограничения сегодня существуют на каждом из них. ИИ как инфраструктура Сегодня искусственный интеллект воспринимается бизнесом скорее как отдельный продукт, и разговор о нем обычно сводится к сравнению моделей. Но на самом деле смотреть стоит гораздо шире. Бизнес начинает получать ощутимый эффект только тогда, когда одновременно развиваются три компонента: 	 наличие самих моделей искусственного интеллекта; 	 компетенции людей; 	 наличие качественных данных. Но и это лишь фундамент. Если представить эту систему в виде пирамиды, то в ее основании находятся именно эти три компонента. Следующий уровень — ИИ-агенты и коннекторы, которые позволяют им взаимодействовать между собой и с внешними системами. И на вершине этой пирамиды находится бизнес-эффект — возможность быстрее, точнее и с меньшими затратами решать реальные задачи. Именно поэтому бизнесу сегодня стоит сосредоточиться не столько на вопросе, какая модель окажется сильнее, сколько на том, насколько быстро удастся построить всю пирамиду — инфраструктуру вокруг ИИ. Проблемы российских моделей С точки зрения моделей ситуация в России остается сложной. Наиболее качественные и развитые мировые решения, такие как Claude от Anthropic и ChatGPT, находятся фактически вне легального контура использования для российского бизнеса. Бизнес не может официально приобрести модель, оплачивать ее использование, учитывать эти расходы в финансовом контуре и выстраивать полноценную корпоративную инфраструктуру вокруг нее. Российские модели пока уступают мировым по возможностям. Пока развитие отечественных решений сосредоточено преимущественно на пользовательских чат-ботах. Например, GigaChat получил инструменты для создания ИИ-агентов совсем недавно, тогда как у OpenAI и Anthropic они появились значительно раньше. За это время вокруг зарубежных моделей успела сформироваться зрелая экосистема инструментов, интеграций и практических сценариев внедрения, тогда как российские решения только проходят этот этап. Даже идеальная нейросеть бесполезна без данных Однако основная проблема с внедрением ИИ в России сегодня не в моделях и не в людях, которые пока только начинают накапливать практический опыт работы с нейросетями. Самый ценный ресурс — понятные, структурированные данные: это основа для принятия решений и одновременно материал, на котором обучаются сами модели. Например, кажется, что подготовить коммерческое предложение перевозчику — типичная задача для человека. На самом деле это практически идеальный кейс для ИИ. Но чтобы агент мог рассчитать тариф, ему нужна информация: 	 собственная база тарифов и алгоритмы, которые описывают, как формируется стоимость перевозки; 	 исторические данные: количество рейсов с конкретным перевозчиком и клиентом, качество работы, платежную дисциплину, возникавшие проблемы и претензии — возможно, эти риски необходимо закладывать в тариф заранее; 	 система также должна учитывать будущие тренды: изменение стоимости топлива, инфляцию, динамику заработных плат водителей; 	 еще один важный элемент — рыночные данные. Целевая маржинальность на рынке может составлять 5, 15 или 30% — и выбор зависит от текущего баланса спроса и предложения по конкретному направлению. Для этого нужны дополнительные коэффициенты и отраслевые базы данных. Фактически сейчас человек выполняет всю эту работу самостоятельно: он держит множество факторов в голове, опирается на опыт и часто интуитивно формирует предложение. Это как раз задача, где искусственный интеллект может быть особенно эффективен, но без качественных данных он будет решать ее ограниченно. И здесь у российской логистики есть серьезная проблема. Рынок автологистики в России сильно деконсолидирован, и даже крупнейший игрок занимает всего около 2-3% рынка. У нас фактически нет сформированных единых больших баз данных, которые позволяли бы бизнесу строить алгоритмы с использованием ИИ. Кто станет владельцем инфраструктуры данных Если данные — главное топливо для искусственного интеллекта, то кто будет владеть этим ресурсом? Мы видим, что государство уже формирует базовую цифровую инфраструктуру, вводя обязательный электронный документооборот. В перспективе такая система способна аккумулировать информацию о значительной части перевозок на рынке. Это может стать серьезной основой для дальнейшего применения искусственного интеллекта в логистике, однако остается открытым вопрос: насколько эти данные будут доступны бизнесу для практического использования. Если регуляторные требования помогают сформировать единое информационное пространство и накапливать данные, то бизнес способен наполнить его практической ценностью, создавая сервисы на основе этих данных. Хороший пример — компания ATI, которая собирает данные по ставкам на перевозки в России. Сейчас это один из основных источников информации по тарифам на рынке. Модель построена на добровольной основе: компания платит участникам за предоставление данных, консолидирует их и затем предоставляет бизнесу в удобном формате. Потенциал у такого подхода действительно большой. Если в России развитие пойдет ближе к китайской модели, где участников рынка стимулируют работать через цифровые платформы, а сами платформы создают полезные сервисы для бизнеса, эффект, вероятно, будет очень высоким. В такой модели компании заинтересованы в использовании платформ не только из-за требований регуляторов, а потому что понимают, какую конкретную пользу получают от обмена этой информацией. Настоящая революция начнется в эпоху ИИ-агентов Итак, для построения полноценной ИИ-инфраструктуры требуются три элемента: сами модели, люди с компетенциями и качественные данные. Хотя на каждом из этих уровней пока есть свои ограничения, фундамент для будущей ИИ-инфраструктуры уже постепенно формируется. По мере его развития будут появляться новые классы решений. Именно следующий этап — появление большого количества специализированных агентов, которые смогут работать поверх этой инфраструктуры, взаимодействовать между собой и самостоятельно выполнять бизнес-задачи — может стать настоящим прорывом с точки зрения повышения эффективности бизнеса. В перспективе можно представить ситуацию, когда в логистической компании из 20 сотрудников, условно, 17 цифровых агентов будут закрывать рутинные процессы, а люди будут заниматься более сложными задачами, требующими экспертизы и стратегических решений. При этом сами агенты будут развиваться в двух основных направлениях. Первое — внутренние агенты. Это системы, которые помогают решать задачи внутри компании: формировать дополнительные соглашения, создавать должностные инструкции, готовить коммерческие предложения. Подобные решения уже начинают появляться во многих отраслях, и первые результаты подтверждают их эффективность. Так, согласно свежему исследованию McKinsey «The Future of B2B Sales», 59% компаний-лидеров роста сообщили, что благодаря ИИ повысилась эффективность работы их отделов продаж, а внедрение ИИ-агентов хотя бы в один из ключевых процессов способно высвободить дополнительно около 10% времени продавцов. Однако прорыв, вероятнее всего, будет связан со вторым типом — агентами, которые смогут взаимодействовать не только с внутренними системами компании, но и с внешним рынком. Например, внешний агент сможет искать подходящий транспорт не только из парка компании, а среди всех доступных участников рынка. Или готовить коммерческое предложение, анализируя тендеры и взаимодействуя с внешними торговыми площадками. Однако потребуется еще один важный элемент — коннекторы. Сегодня люди взаимодействуют через привычные каналы: мессенджеры, электронную почту, видеосвязь. Но человеку достаточно получить сообщение, а дальше он сам найдет нужные данные, вспомнит контекст, проверит информацию, оценит риски и примет решение. Для ИИ-агента такой подход неэффективен. Ему недостаточно просто передать сообщение — вместе с ним необходимо предоставить структурированные данные, бизнес-контекст, правила принятия решений и возможность выполнить нужное действие в другой системе. Именно поэтому в будущем будут развиваться специальные коннекторы — цифровые каналы взаимодействия ИИ-агентов. Коннектор можно сравнить с мессенджером для ИИ-агентов, однако его роль выходит далеко за рамки обмена сообщениями. Это среда, которая обеспечивает агенту доступ к данным, контексту и инструментам, необходимым для принятия решений и выполнения действий. В логистике это может быть поиск перевозчика, расчет тарифа, проверка контрагента или оформление документов; в других отраслях — свои специализированные сценарии. Победят не те, у кого лучше нейросеть Сегодня рынок по-прежнему сосредоточен на сравнении языковых моделей: какая лучше и сильнее. Однако конкурентное преимущество будут создавать не сами модели, а вся инфраструктура вокруг них. В логистике это приобретает особое значение. Сегодня, чтобы найти подходящий транспорт, специалист иногда обзванивает десятки перевозчиков, выясняя, у кого есть свободная машина на нужном направлении. Теоретически эту задачу мог бы выполнять ИИ-агент — быстрее, дешевле и точнее. Но для этого ему нужен доступ к данным обо всем рынке, а не только к информации одной компании. Пока такой системы нет, даже самые совершенные модели не способны раскрыть свой потенциал. В конечном счете главным фактором развития станет уже не сама языковая модель, а инфраструктура вокруг нее. Когда появятся качественные данные, механизмы их обмена, специализированные коннекторы и экосистема ИИ-агентов, искусственный интеллект сможет решать задачи не отдельных компаний, а всей отрасли. Именно этот этап и станет настоящим переломным моментом — будь то для логистика или любая другая сфера. #IMAGE_235494#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Логистика с&nbsp;ее&nbsp;сложными процессами и&nbsp;огромными массивами данных&nbsp;— одна из&nbsp;тех отраслей, где искусственный интеллект способен изменить саму архитектуру бизнеса. Однако произойдет это не&nbsp;благодаря появлению очередной языковой модели. Рассмотрим, из&nbsp;каких уровней складывается ИИ-инфраструктура и&nbsp;какие ограничения сегодня существуют на&nbsp;каждом из&nbsp;них.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ&nbsp;как инфраструктура&lltt;/h3&ggtt;
&lltt;p&ggtt;Сегодня искусственный интеллект воспринимается бизнесом скорее как отдельный продукт, и&nbsp;разговор о&nbsp;нем обычно сводится к&nbsp;сравнению моделей. Но&nbsp;на&nbsp;самом деле смотреть стоит гораздо шире. Бизнес начинает получать ощутимый эффект только тогда, когда одновременно развиваются три компонента:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; наличие самих моделей искусственного интеллекта;&lltt;/li&ggtt;
	&lltt;li&ggtt; компетенции людей;&lltt;/li&ggtt;
	&lltt;li&ggtt; наличие качественных данных.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Но&nbsp;и&nbsp;это лишь фундамент. Если представить эту систему в&nbsp;виде пирамиды, то&nbsp;в&nbsp;ее&nbsp;основании находятся именно эти три компонента. Следующий уровень&nbsp;— ИИ-агенты и&nbsp;коннекторы, которые позволяют им&nbsp;взаимодействовать между собой и&nbsp;с&nbsp;внешними системами. И&nbsp;на&nbsp;вершине этой пирамиды находится бизнес-эффект&nbsp;— возможность быстрее, точнее и&nbsp;с&nbsp;меньшими затратами решать реальные задачи.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому бизнесу сегодня стоит сосредоточиться не&nbsp;столько на&nbsp;вопросе, какая модель окажется сильнее, сколько на&nbsp;том, насколько быстро удастся построить всю пирамиду&nbsp;— инфраструктуру вокруг ИИ.&lltt;/p&ggtt;
&lltt;h3&ggtt;Проблемы российских моделей&lltt;/h3&ggtt;
&lltt;p&ggtt;С&nbsp;точки зрения моделей ситуация в&nbsp;России остается сложной. Наиболее качественные и&nbsp;развитые мировые решения, такие как Claude от&nbsp;Anthropic и&nbsp;ChatGPT, находятся фактически вне легального контура использования для российского бизнеса. Бизнес не&nbsp;может официально приобрести модель, оплачивать ее&nbsp;использование, учитывать эти расходы в&nbsp;финансовом контуре и&nbsp;выстраивать полноценную корпоративную инфраструктуру вокруг нее.&lltt;/p&ggtt;
&lltt;p&ggtt;Российские модели пока уступают мировым по&nbsp;возможностям. Пока развитие отечественных решений сосредоточено преимущественно на&nbsp;пользовательских чат-ботах. Например, GigaChat получил инструменты для создания ИИ-агентов совсем недавно, тогда как у&nbsp;OpenAI и&nbsp;Anthropic они появились значительно раньше. За&nbsp;это время вокруг зарубежных моделей успела сформироваться зрелая экосистема инструментов, интеграций и&nbsp;практических сценариев внедрения, тогда как российские решения только проходят этот этап.&lltt;/p&ggtt;
&lltt;h3&ggtt;Даже идеальная нейросеть бесполезна без данных&lltt;/h3&ggtt;
&lltt;p&ggtt;Однако основная проблема с&nbsp;внедрением&nbsp;ИИ в&nbsp;России сегодня не&nbsp;в&nbsp;моделях и&nbsp;не&nbsp;в&nbsp;людях, которые пока только начинают накапливать практический опыт работы с&nbsp;нейросетями. Самый ценный ресурс&nbsp;— понятные, структурированные данные: это основа для принятия решений и&nbsp;одновременно материал, на&nbsp;котором обучаются сами модели.&lltt;/p&ggtt;
&lltt;p&ggtt;Например, кажется, что подготовить коммерческое предложение перевозчику&nbsp;— типичная задача для человека. На&nbsp;самом деле это практически идеальный кейс для ИИ. Но&nbsp;чтобы агент мог рассчитать тариф, ему нужна информация:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; собственная база тарифов и&nbsp;алгоритмы, которые описывают, как формируется стоимость перевозки;&lltt;/li&ggtt;
	&lltt;li&ggtt; исторические данные: количество рейсов с&nbsp;конкретным перевозчиком и&nbsp;клиентом, качество работы, платежную дисциплину, возникавшие проблемы и&nbsp;претензии&nbsp;— возможно, эти риски необходимо закладывать в&nbsp;тариф заранее;&lltt;/li&ggtt;
	&lltt;li&ggtt; система также должна учитывать будущие тренды: изменение стоимости топлива, инфляцию, динамику заработных плат водителей;&lltt;/li&ggtt;
	&lltt;li&ggtt; еще один важный элемент&nbsp;— рыночные данные. Целевая маржинальность на&nbsp;рынке может составлять 5, 15&nbsp;или 30%&nbsp;— и&nbsp;выбор зависит от&nbsp;текущего баланса спроса и&nbsp;предложения по&nbsp;конкретному направлению. Для этого нужны дополнительные коэффициенты и&nbsp;отраслевые базы данных.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Фактически сейчас человек выполняет всю эту работу самостоятельно: он&nbsp;держит множество факторов в&nbsp;голове, опирается на&nbsp;опыт и&nbsp;часто интуитивно формирует предложение. Это как раз задача, где искусственный интеллект может быть особенно эффективен, но&nbsp;без качественных данных он&nbsp;будет решать ее&nbsp;ограниченно.&lltt;/p&ggtt;
&lltt;p&ggtt;И&nbsp;здесь у&nbsp;российской логистики есть серьезная проблема. Рынок автологистики в&nbsp;России сильно деконсолидирован, и&nbsp;даже крупнейший игрок занимает всего около &lltt;nobr&ggtt;2-3%&lltt;/nobr&ggtt; рынка. У&nbsp;нас фактически нет сформированных единых больших баз данных, которые позволяли&nbsp;бы бизнесу строить алгоритмы с&nbsp;использованием ИИ.&lltt;/p&ggtt;
&lltt;h3&ggtt;Кто станет владельцем инфраструктуры данных&lltt;/h3&ggtt;
&lltt;p&ggtt;Если данные&nbsp;— главное топливо для искусственного интеллекта, то&nbsp;кто будет владеть этим ресурсом?&lltt;/p&ggtt;
&lltt;p&ggtt;Мы&nbsp;видим, что государство уже формирует базовую цифровую инфраструктуру, вводя обязательный электронный документооборот. В&nbsp;перспективе такая система способна аккумулировать информацию о&nbsp;значительной части перевозок на&nbsp;рынке. Это может стать серьезной основой для дальнейшего применения искусственного интеллекта в&nbsp;логистике, однако остается открытым вопрос: насколько эти данные будут доступны бизнесу для практического использования.&lltt;/p&ggtt;
&lltt;p&ggtt;Если регуляторные требования помогают сформировать единое информационное пространство и&nbsp;накапливать данные, то&nbsp;бизнес способен наполнить его практической ценностью, создавая сервисы на&nbsp;основе этих данных. Хороший пример&nbsp;— компания ATI, которая собирает данные по&nbsp;ставкам на&nbsp;перевозки в&nbsp;России. Сейчас это один из&nbsp;основных источников информации по&nbsp;тарифам на&nbsp;рынке. Модель построена на&nbsp;добровольной основе: компания платит участникам за&nbsp;предоставление данных, консолидирует их&nbsp;и&nbsp;затем предоставляет бизнесу в&nbsp;удобном формате.&lltt;/p&ggtt;
&lltt;p&ggtt;Потенциал у&nbsp;такого подхода действительно большой. Если в&nbsp;России развитие пойдет ближе к&nbsp;китайской модели, где участников рынка стимулируют работать через цифровые платформы, а&nbsp;сами платформы создают полезные сервисы для бизнеса, эффект, вероятно, будет очень высоким. В&nbsp;такой модели компании заинтересованы в&nbsp;использовании платформ не&nbsp;только из-за требований регуляторов, а&nbsp;потому что понимают, какую конкретную пользу получают от&nbsp;обмена этой информацией.&lltt;/p&ggtt;
&lltt;h3&ggtt;Настоящая революция начнется в&nbsp;эпоху ИИ-агентов&lltt;/h3&ggtt;
&lltt;p&ggtt;Итак, для построения полноценной ИИ-инфраструктуры требуются три элемента: сами модели, люди с&nbsp;компетенциями и&nbsp;качественные данные. Хотя на&nbsp;каждом из&nbsp;этих уровней пока есть свои ограничения, фундамент для будущей ИИ-инфраструктуры уже постепенно формируется. По&nbsp;мере его развития будут появляться новые классы решений.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно следующий этап&nbsp;— появление большого количества специализированных агентов, которые смогут работать поверх этой инфраструктуры, взаимодействовать между собой и&nbsp;самостоятельно выполнять бизнес-задачи&nbsp;— может стать настоящим прорывом с&nbsp;точки зрения повышения эффективности бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;перспективе можно представить ситуацию, когда в&nbsp;логистической компании из&nbsp;20&nbsp;сотрудников, условно, 17&nbsp;цифровых агентов будут закрывать рутинные процессы, а&nbsp;люди будут заниматься более сложными задачами, требующими экспертизы и&nbsp;стратегических решений.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом сами агенты будут развиваться в&nbsp;двух основных направлениях.&lltt;/p&ggtt;
&lltt;p&ggtt;Первое&nbsp;— внутренние агенты. Это системы, которые помогают решать задачи внутри компании: формировать дополнительные соглашения, создавать должностные инструкции, готовить коммерческие предложения. Подобные решения уже начинают появляться во&nbsp;многих отраслях, и&nbsp;первые результаты подтверждают их&nbsp;эффективность. Так, согласно свежему &lltt;a href="https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-future-of-b2b-sales-how-growth-champions-rewire-their-playbooks-with-ai"&ggtt;исследованию&lltt;/a&ggtt; McKinsey «The Future of&nbsp;B2B Sales», 59% компаний-лидеров роста сообщили, что благодаря&nbsp;ИИ повысилась эффективность работы их&nbsp;отделов продаж, а&nbsp;внедрение ИИ-агентов хотя&nbsp;бы в&nbsp;один из&nbsp;ключевых процессов способно высвободить дополнительно около&nbsp;10% времени продавцов.&lltt;/p&ggtt;
&lltt;p&ggtt;Однако прорыв, вероятнее всего, будет связан со&nbsp;вторым типом&nbsp;— агентами, которые смогут взаимодействовать не&nbsp;только с&nbsp;внутренними системами компании, но&nbsp;и&nbsp;с&nbsp;внешним рынком. Например, внешний агент сможет искать подходящий транспорт не&nbsp;только из&nbsp;парка компании, а&nbsp;среди всех доступных участников рынка. Или готовить коммерческое предложение, анализируя тендеры и&nbsp;взаимодействуя с&nbsp;внешними торговыми площадками.&lltt;/p&ggtt;
&lltt;p&ggtt;Однако потребуется еще один важный элемент&nbsp;— коннекторы. Сегодня люди взаимодействуют через привычные каналы: мессенджеры, электронную почту, видеосвязь. Но&nbsp;человеку достаточно получить сообщение, а&nbsp;дальше он&nbsp;сам найдет нужные данные, вспомнит контекст, проверит информацию, оценит риски и&nbsp;примет решение. Для ИИ-агента такой подход неэффективен. Ему недостаточно просто передать сообщение&nbsp;— вместе с&nbsp;ним необходимо предоставить структурированные данные, бизнес-контекст, правила принятия решений и&nbsp;возможность выполнить нужное действие в&nbsp;другой системе.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому в&nbsp;будущем будут развиваться специальные коннекторы&nbsp;— цифровые каналы взаимодействия ИИ-агентов. Коннектор можно сравнить с&nbsp;мессенджером для ИИ-агентов, однако его роль выходит далеко за&nbsp;рамки обмена сообщениями. Это среда, которая обеспечивает агенту доступ к&nbsp;данным, контексту и&nbsp;инструментам, необходимым для принятия решений и&nbsp;выполнения действий. В&nbsp;логистике это может быть поиск перевозчика, расчет тарифа, проверка контрагента или оформление документов; в&nbsp;других отраслях&nbsp;— свои специализированные сценарии.&lltt;/p&ggtt;
&lltt;h3&ggtt;Победят не&nbsp;те, у&nbsp;кого лучше нейросеть&lltt;/h3&ggtt;
&lltt;p&ggtt;Сегодня рынок по-прежнему сосредоточен на&nbsp;сравнении языковых моделей: какая лучше и&nbsp;сильнее. Однако конкурентное преимущество будут создавать не&nbsp;сами модели, а&nbsp;вся инфраструктура вокруг них.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;логистике это приобретает особое значение. Сегодня, чтобы найти подходящий транспорт, специалист иногда обзванивает десятки перевозчиков, выясняя, у&nbsp;кого есть свободная машина на&nbsp;нужном направлении. Теоретически эту задачу мог&nbsp;бы выполнять ИИ-агент&nbsp;— быстрее, дешевле и&nbsp;точнее. Но&nbsp;для этого ему нужен доступ к&nbsp;данным обо всем рынке, а&nbsp;не&nbsp;только к&nbsp;информации одной компании. Пока такой системы нет, даже самые совершенные модели не&nbsp;способны раскрыть свой потенциал.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;конечном счете главным фактором развития станет уже не&nbsp;сама языковая модель, а&nbsp;инфраструктура вокруг нее. Когда появятся качественные данные, механизмы их&nbsp;обмена, специализированные коннекторы и&nbsp;экосистема ИИ-агентов, искусственный интеллект сможет решать задачи не&nbsp;отдельных компаний, а&nbsp;всей отрасли. Именно этот этап и&nbsp;станет настоящим переломным моментом&nbsp;— будь то&nbsp;для логистика или любая другая сфера.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235494#&lltt;/p&ggtt;]]></source>
<adate>09.09.2026</adate>
<dbid>235493</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/92c/52h002b6u6m25hazwj7o7jf0iq6vaadk.jpg]]>
</images>
<imagesname><![CDATA[;;Михаил Чушков, генеральный директор онлайн-сервиса Pooling   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Почему контексту вашего агента необходим цикл разработки]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235495]]></link>
<description><![CDATA[Анкит Джайн, соучредитель и генеральный директор Aviator, рассказывает на портале The New Stack о том, почему контекстом вашего ИИ-агента следует управлять как ПО и как цикл разработки контекста улучшает качество навыков, тестирование и масштабируемость. Навыки, конфигурации агентов, инструкции к промптам и файлы правил. Эти артефакты теперь определяют то, что создают ваши агенты по кодированию. Они определяют каждую строку сгенерированного кода, каждое архитектурное решение, каждое соглашение, которому агент следует или которое игнорирует. По сути, это ПО. Но никто к ним так не относится. Команды пишут навыки, добавляют их в репозиторий и никогда не проверяют, работают ли они после обновления модели. Конфигурации агентов копируются и переносятся между командами без версионирования. Файлы правил теряют синхронизацию с кодовой базой, которую они описывают. Когда что-то ломается, об этом сигнализирует разработчик, заметивший странный вывод и пожаловавшийся в Slack. Независимый ИТ-консультант Патрик Дюбуа предложил концепцию того, чего не хватает: цикл разработки контекста (Context Development Lifecycle, CDLC). CDLC — это не управление окном контекста или размещение большего количества токенов в запросе. Речь идёт об управлении качеством элементов, которые попадают в контекстное окно. Актуален ли навык? Действительно ли модель правильно реагирует на него? Предоставляете ли вы контекст, который модель уже знает? Если контекст — это новый код, каков его жизненный цикл разработки? Четыре фазы жизненного цикла разработки контекста CDLC имеет четыре фазы, которые напрямую соответствуют тому, что мы уже делаем с кодом. #IMAGE_235496# Генерация — это то, с чего все начинают. Написание навыков, создание конфигураций промптов, настройка правил агента. Это эквивалент написания кода, и именно на это сегодня уходит бóльшая часть времени. Оценка — это тестирование. Проверка правильности линтинга во фронтенде или не слишком ли длинный синтаксис. На более сложном этапе вы запускаете сценарии: загружаете навык, задаёте конкретный вопрос, проверяете, выдаёт ли агент ожидаемый результат. Вы тестируете разные модели и версии. Вы проверяете, не пишете ли вы контекст, который модель уже знает, что приводит к нерациональному использованию токенов. Вы проверяете, активируется ли навык по правильным ключевым словам. Это цикл разработки через тестирование (TDD) для контекста. Пишите навык, пишите сценарий, проверяете результат, итерируете. Дистрибуция — это доставка. На самом простом уровне это добавление навыка в репозиторий. На более зрелом уровне команды публикуют навыки в установленный реестр с версионированием, возможностью обнаружения и контролем доступа. Вставка навыка в канал Slack — это не дистрибуция, так же как отправка файла .jar по электронной почте — это не управление зависимостями. Наблюдаемость — это мониторинг производственной среды. Используется ли навык? Выдает ли он правильные результаты? Сколько итераций проходит агент, прежде чем вмешается разработчик? Где разработчики переопределяют агента или исправляют его вывод? Это наблюдаемость для вашего контекста. Не пропускайте тестирование Кривая зрелости здесь идентична тому, что происходило с практиками разработки ПО за последние два десятилетия. Организации создают и распространяют. Они полностью пропускают оценку. Они отправляют навыки в производственную среду, то есть разработчикам, которые их используют, и ждут, что произойдет. Это напрямую сравнимо с тем, как команды игнорируют разработку через тестирование, несмотря на указания делать это. Они не знают, что такое боль, поэтому сразу передают в производство. Боль возникает, когда навык работает в одной версии модели, но ломается в следующей, или когда он срабатывает на неправильный вопрос и дает разработчику заведомо неверные инструкции. Когда соглашение, которое навязывал навык, было правильным полгода назад, но кодовая база с тех пор изменилась. Это те же самые режимы сбоев, которые мы видим в непротестированном коде. Регрессии, ложные срабатывания, устаревшие предположения. В каждой кодовой базе есть шаблоны, в которых ИИ постоянно ошибается. Слепота к соглашениям, галлюцинаторные API, код карго-культа, избыточное проектирование. Мы называем это инвариантами, или реестром ошибок ИИ. И реестр навыков, и реестр ошибок ИИ иллюстрируют один и тот же основополагающий принцип на обоих концах жизненного цикла разработки: каталогизируйте свои инженерные стандарты и передавайте их агентам. До генерации кода это означает навыки. На этапе проверки кода это каталог шаблонов, в которых ИИ постоянно ошибается на вашей кодовой базе. Реестр ошибок служит основой для автоматизированных проверок, выявляющих все, что осталось незамеченным. Вы не можете масштабировать качество кода, требуя от людей более тщательной проверки. Вы масштабируете его, инвестируя в механизмы контроля, которые кодифицируют ваши стандарты на обоих концах. От 1x до 50x Разработчик, оптимизирующий собственный цикл работы агента, получает лучшие индивидуальные результаты, но это улучшение остается с ним. Когда он исправляет ошибку в навыке, никто другой от этого не выигрывает. Когда он обнаруживает ошибку, никто другой извлекает из этого урок. ROI здесь однократный (1x). Дюбуа схематизирует вопрос масштабирования, используя две метрики, которые лежат в основе традиционных показателей DORA. Первая — это участие человека: как часто разработчику приходится вмешиваться в рабочий процесс конкретного агента? Каждое вмешательство — это сигнал о том, что контекст отсутствует или неверен. Сокращение участия человека — это прямой показатель того, насколько автономен цикл кодирования вашего агента, и он часто коррелирует со стоимостью, поскольку больше циклов означает больше затрат на агентов. Вторая — это эффект повторного использования: сколько разработчиков получают выгоду от улучшения одного навыка? Если один разработчик исправляет навык, и только он получает от этого выгоду, это 1x. Если это исправление попадает в общий реестр, и его получают 50 разработчиков, это 50x. Эти две метрики вместе заставляют организацию стремиться к общей инфраструктуре. Вы не можете сократить участие человека в масштабе без общего, хорошо протестированного контекста. Вы не можете получить эффект повторного использования без дистрибуции и версионирования. Ваша команда платформы уже знает, как это делать Организационная структура для этого уже существует. Платформенные команды потратили десятилетие на создание инфраструктуры, позволяющей командам разработчиков надежно выпускать код: системы контроля версий, конвейеры CI/CD, реестры артефактов, сканирование безопасности, управление зависимостями и контроль доступа. Этот подход практически напрямую применим и к разработке контекста. То, что команда платформы делает для репозиториев кода, она делает и для навыков. Предоставляет реестр. Настраивает контроль доступа и разрешения для групп. Создает инфраструктуру для оценки. Запускает сканирование безопасности и сообщает о результатах. Создает дашборды, показывающие, какие навыки работают хорошо, а какие ухудшаются. Отслеживает ответственность, чтобы, когда навык ломается после обновления модели, был ответственный за его исправление. Чего команда платформы не делает, так это не пишет навыки и не исправляет их, когда они ломаются. Команда, которая владеет предметной областью, владеет и навыком. Команда платформы предоставляет уровень управления и инструменты, здесь то же самое разделение ответственности, которое работает и для кода. Проблема «осиротевших навыков» уже начинает проявляться. Разработчик пишет навык, делится им, переходит в другую команду, и теперь никто его не поддерживает. Обновление модели приводит к сбою, и команда платформы по умолчанию наследует эту проблему. Это снова история с осиротевшими репозиториями GitHub. Решение то же самое: политики владения, требования к поддержке, пути вывода из эксплуатации. Советы Дюбуа звучат лаконично: «Не создавайте инструмент. Создайте инструмент, который создает инструмент. Команда платформы создает инструмент для тех, кто создает инструмент, который создает инструмент». Замыкание цикла с помощью наблюдаемости Наименее развитый этап в большинстве организаций — это наблюдаемость, хотя он и самый важный. Без него нет системы обучения. Вы вручную генерируете и распространяете контекст, надеясь, что это сработает, и исправляете ошибки, когда кто-то подает жалобу. Наблюдаемость агентов все еще находится на ранней стадии. Стандарты только формируются. Agent MD уже широко используется. Стандарты навыков и плагинов относительно новые. Инструментарий еще не зрелый, но схема ясна: инструментируйте своих агентов, централизуйте сигналы и анализируйте их в разных командах. По нашему мнению, петли обратной связи в производственной среде — это недостающий элемент в разработке с использованием ИИ. Когда что-то ломается в производственной среде, отследите это до изменения, определите категорию ошибки и передайте ее обратно как на уровень промптов, так и на уровень проверки. Этап наблюдаемости в CDLC расширяет эту идею от качества кода до качества контекста. Сигналы, собранные из журналов агентов, исправлений разработчиков и подсчета шагов, напрямую используются для создания более качественных навыков, написания более целенаправленных оценок и дистрибуции улучшенных версий. Самосовершенствующаяся агентная разработка Полностью замкнутый цикл выглядит как система, в которой журналы агентов используются для анализа, выявляющего пробелы. Эти пробелы генерируют новые навыки или обновления существующих. Обновленные навыки проходят оценку перед выпуском. Они распространяются через реестр с контролем версий. И цикл повторяется. Дюбуа реалистично оценивает конечный результат. Видение «темной фабрики», где агенты создают код без участия человека, он называет «благородным направлением, но рискованной игрой». Команды, которые приближаются к этому (те, кто может с уверенностью сказать, что они больше не читают код), — это те, кто вложили значительные средства в контекст, тестирование и инфраструктуру наблюдаемости, которые делают их агентов достаточно надежными, чтобы требовать меньшего количество человеческих вмешательств в цикле]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Анкит Джайн, соучредитель и&nbsp;генеральный директор Aviator, рассказывает на&nbsp;портале &lltt;/em&ggtt;&lltt;em&ggtt;The&lltt;/em&ggtt; &lltt;em&ggtt;New&lltt;/em&ggtt; &lltt;em&ggtt;Stack&lltt;/em&ggtt; &lltt;em&ggtt;о&nbsp;том, почему контекстом вашего ИИ-агента следует управлять как&nbsp;ПО и&nbsp;как цикл разработки контекста улучшает качество навыков, тестирование и&nbsp;масштабируемость.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Навыки, конфигурации агентов, инструкции к&nbsp;промптам и&nbsp;файлы правил. Эти артефакты теперь определяют&nbsp;то, что создают ваши агенты по&nbsp;кодированию. Они определяют каждую строку сгенерированного кода, каждое архитектурное решение, каждое соглашение, которому агент следует или которое игнорирует. По&nbsp;сути, это ПО.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;никто к&nbsp;ним так не&nbsp;относится. Команды пишут навыки, добавляют их&nbsp;в&nbsp;репозиторий и&nbsp;никогда не&nbsp;проверяют, работают&nbsp;ли они после обновления модели. Конфигурации агентов копируются и&nbsp;переносятся между командами без версионирования. Файлы правил теряют синхронизацию с&nbsp;кодовой базой, которую они описывают. Когда что-то ломается, об&nbsp;этом сигнализирует разработчик, заметивший странный вывод и&nbsp;пожаловавшийся в&nbsp;Slack.&lltt;/p&ggtt;
&lltt;p&ggtt;Независимый ИТ-консультант Патрик Дюбуа предложил &lltt;a href="https://tessl.io/blog/context-development-lifecycle-better-context-for-ai-coding-agents"&ggtt;концепцию&lltt;/a&ggtt; того, чего не&nbsp;хватает: цикл разработки контекста (Context Development Lifecycle, CDLC). CDLC&nbsp;— это не&nbsp;управление окном контекста или размещение большего количества токенов в&nbsp;запросе. Речь идёт об&nbsp;управлении качеством элементов, которые попадают в&nbsp;контекстное окно. Актуален&nbsp;ли навык? Действительно&nbsp;ли модель правильно реагирует на&nbsp;него? Предоставляете&nbsp;ли вы&nbsp;контекст, который модель уже знает? Если контекст&nbsp;— это новый код, каков его жизненный цикл разработки?&lltt;/p&ggtt;
&lltt;h3&ggtt;Четыре фазы жизненного цикла разработки контекста&lltt;/h3&ggtt;
&lltt;p&ggtt;CDLC имеет четыре фазы, которые напрямую соответствуют тому, что мы&nbsp;уже делаем с&nbsp;кодом.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235496#&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Генерация&lltt;/strong&ggtt;&nbsp;— это&nbsp;то, с&nbsp;чего все начинают. Написание навыков, создание конфигураций промптов, настройка правил агента. Это эквивалент написания кода, и&nbsp;именно на&nbsp;это сегодня уходит бóльшая часть времени.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Оценка&lltt;/strong&ggtt;&nbsp;— это тестирование. Проверка правильности линтинга во&nbsp;фронтенде или не&nbsp;слишком&nbsp;ли длинный синтаксис. На&nbsp;более сложном этапе вы&nbsp;запускаете сценарии: загружаете навык, задаёте конкретный вопрос, проверяете, выдаёт&nbsp;ли агент ожидаемый результат. Вы&nbsp;тестируете разные модели и&nbsp;версии. Вы&nbsp;проверяете, не&nbsp;пишете&nbsp;ли вы&nbsp;контекст, который модель уже знает, что приводит к&nbsp;нерациональному использованию токенов. Вы&nbsp;проверяете, активируется&nbsp;ли навык по&nbsp;правильным ключевым словам.&lltt;/p&ggtt;
&lltt;p&ggtt;Это цикл разработки через тестирование (TDD) для контекста. Пишите навык, пишите сценарий, проверяете результат, итерируете.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Дистрибуция&lltt;/strong&ggtt;&nbsp;— это доставка. На&nbsp;самом простом уровне это добавление навыка в&nbsp;репозиторий. На&nbsp;более зрелом уровне команды публикуют навыки в&nbsp;установленный реестр с&nbsp;версионированием, возможностью обнаружения и&nbsp;контролем доступа. Вставка навыка в&nbsp;канал Slack&nbsp;— это не&nbsp;дистрибуция, так&nbsp;же как отправка файла .jar по&nbsp;электронной почте&nbsp;— это не&nbsp;управление зависимостями.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Наблюдаемость&lltt;/strong&ggtt;&nbsp;— это мониторинг производственной среды. Используется&nbsp;ли навык? Выдает&nbsp;ли он&nbsp;правильные результаты? Сколько итераций проходит агент, прежде чем вмешается разработчик? Где разработчики переопределяют агента или исправляют его вывод? Это наблюдаемость для вашего контекста.&lltt;/p&ggtt;
&lltt;h3&ggtt;Не&nbsp;пропускайте тестирование&lltt;/h3&ggtt;
&lltt;p&ggtt;Кривая зрелости здесь идентична тому, что происходило с&nbsp;практиками разработки&nbsp;ПО за&nbsp;последние два десятилетия. Организации создают и&nbsp;распространяют. Они полностью пропускают оценку. Они отправляют навыки в&nbsp;производственную среду, то&nbsp;есть разработчикам, которые их&nbsp;используют, и&nbsp;ждут, что произойдет.&lltt;/p&ggtt;
&lltt;p&ggtt;Это напрямую сравнимо с&nbsp;тем, как команды игнорируют разработку через тестирование, несмотря на&nbsp;указания делать это. Они не&nbsp;знают, что такое боль, поэтому сразу передают в&nbsp;производство.&lltt;/p&ggtt;
&lltt;p&ggtt;Боль возникает, когда навык работает в&nbsp;одной версии модели, но&nbsp;ломается в&nbsp;следующей, или когда он&nbsp;срабатывает на&nbsp;неправильный вопрос и&nbsp;дает разработчику заведомо неверные инструкции. Когда соглашение, которое навязывал навык, было правильным полгода назад, но&nbsp;кодовая база с&nbsp;тех пор изменилась. Это те&nbsp;же самые режимы сбоев, которые мы&nbsp;видим в&nbsp;непротестированном коде. Регрессии, ложные срабатывания, устаревшие предположения.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;каждой кодовой базе есть шаблоны, в&nbsp;которых&nbsp;ИИ постоянно ошибается. Слепота к&nbsp;соглашениям, галлюцинаторные API, код карго-культа, избыточное проектирование. Мы&nbsp;называем это инвариантами, или реестром ошибок ИИ. И&nbsp;реестр навыков, и&nbsp;реестр ошибок&nbsp;ИИ иллюстрируют один и&nbsp;тот&nbsp;же основополагающий принцип на&nbsp;обоих концах жизненного цикла разработки: каталогизируйте свои инженерные стандарты и&nbsp;передавайте их&nbsp;агентам.&lltt;/p&ggtt;
&lltt;p&ggtt;До&nbsp;генерации кода это означает навыки. На&nbsp;этапе проверки кода это каталог шаблонов, в&nbsp;которых&nbsp;ИИ постоянно ошибается на&nbsp;вашей кодовой базе. Реестр ошибок служит основой для автоматизированных проверок, выявляющих все, что осталось незамеченным. Вы&nbsp;не&nbsp;можете масштабировать качество кода, требуя от&nbsp;людей более тщательной проверки. Вы&nbsp;масштабируете его, инвестируя в&nbsp;механизмы контроля, которые кодифицируют ваши стандарты на&nbsp;обоих концах.&lltt;/p&ggtt;
&lltt;h3&ggtt;От&nbsp;1x&nbsp;до&nbsp;50x&lltt;/h3&ggtt;
&lltt;p&ggtt;Разработчик, оптимизирующий собственный цикл работы агента, получает лучшие индивидуальные результаты, но&nbsp;это улучшение остается с&nbsp;ним. Когда он&nbsp;исправляет ошибку в&nbsp;навыке, никто другой от&nbsp;этого не&nbsp;выигрывает. Когда он&nbsp;обнаруживает ошибку, никто другой извлекает из&nbsp;этого урок. ROI здесь однократный (1x).&lltt;/p&ggtt;
&lltt;p&ggtt;Дюбуа схематизирует вопрос масштабирования, используя две метрики, которые лежат в&nbsp;основе традиционных показателей DORA.&lltt;/p&ggtt;
&lltt;p&ggtt;Первая&nbsp;— это &lltt;strong&ggtt;участие человека&lltt;/strong&ggtt;: как часто разработчику приходится вмешиваться в&nbsp;рабочий процесс конкретного агента? Каждое вмешательство&nbsp;— это сигнал о&nbsp;том, что контекст отсутствует или неверен. Сокращение участия человека&nbsp;— это прямой показатель того, насколько автономен цикл кодирования вашего агента, и&nbsp;он&nbsp;часто коррелирует со&nbsp;стоимостью, поскольку больше циклов означает больше затрат на&nbsp;агентов.&lltt;/p&ggtt;
&lltt;p&ggtt;Вторая&nbsp;— это &lltt;strong&ggtt;эффект повторного использования&lltt;/strong&ggtt;: сколько разработчиков получают выгоду от&nbsp;улучшения одного навыка? Если один разработчик исправляет навык, и&nbsp;только он&nbsp;получает от&nbsp;этого выгоду, это 1x. Если это исправление попадает в&nbsp;общий реестр, и&nbsp;его получают 50&nbsp;разработчиков, это 50x.&lltt;/p&ggtt;
&lltt;p&ggtt;Эти две метрики вместе заставляют организацию стремиться к&nbsp;общей инфраструктуре. Вы&nbsp;не&nbsp;можете сократить участие человека в&nbsp;масштабе без общего, хорошо протестированного контекста. Вы&nbsp;не&nbsp;можете получить эффект повторного использования без дистрибуции и&nbsp;версионирования.&lltt;/p&ggtt;
&lltt;h3&ggtt;Ваша команда платформы уже знает, как это делать&lltt;/h3&ggtt;
&lltt;p&ggtt;Организационная структура для этого уже существует. Платформенные команды потратили десятилетие на&nbsp;создание инфраструктуры, позволяющей командам разработчиков надежно выпускать код: системы контроля версий, конвейеры CI/CD, реестры артефактов, сканирование безопасности, управление зависимостями и&nbsp;контроль доступа. Этот подход практически напрямую применим и&nbsp;к&nbsp;разработке контекста.&lltt;/p&ggtt;
&lltt;p&ggtt;То, что команда платформы делает для репозиториев кода, она делает и&nbsp;для навыков. Предоставляет реестр. Настраивает контроль доступа и&nbsp;разрешения для групп. Создает инфраструктуру для оценки. Запускает сканирование безопасности и&nbsp;сообщает о&nbsp;результатах. Создает дашборды, показывающие, какие навыки работают хорошо, а&nbsp;какие ухудшаются. Отслеживает ответственность, чтобы, когда навык ломается после обновления модели, был ответственный за&nbsp;его исправление.&lltt;/p&ggtt;
&lltt;p&ggtt;Чего команда платформы не&nbsp;делает, так это не&nbsp;пишет навыки и&nbsp;не&nbsp;исправляет&nbsp;их, когда они ломаются. Команда, которая владеет предметной областью, владеет и&nbsp;навыком. Команда платформы предоставляет уровень управления и&nbsp;инструменты, здесь то&nbsp;же самое разделение ответственности, которое работает и&nbsp;для кода.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема «осиротевших навыков» уже начинает проявляться. Разработчик пишет навык, делится&nbsp;им, переходит в&nbsp;другую команду, и&nbsp;теперь никто его не&nbsp;поддерживает. Обновление модели приводит к&nbsp;сбою, и&nbsp;команда платформы по&nbsp;умолчанию наследует эту проблему. Это снова история с&nbsp;осиротевшими репозиториями GitHub. Решение то&nbsp;же самое: политики владения, требования к&nbsp;поддержке, пути вывода из&nbsp;эксплуатации.&lltt;/p&ggtt;
&lltt;p&ggtt;Советы Дюбуа звучат лаконично: «Не&nbsp;создавайте инструмент. Создайте инструмент, который создает инструмент. Команда платформы создает инструмент для тех, кто создает инструмент, который создает инструмент».&lltt;/p&ggtt;
&lltt;h3&ggtt;Замыкание цикла с&nbsp;помощью наблюдаемости&lltt;/h3&ggtt;
&lltt;p&ggtt;Наименее развитый этап в&nbsp;большинстве организаций&nbsp;— это наблюдаемость, хотя он&nbsp;и&nbsp;самый важный. Без него нет системы обучения. Вы&nbsp;вручную генерируете и&nbsp;распространяете контекст, надеясь, что это сработает, и&nbsp;исправляете ошибки, когда кто-то подает жалобу.&lltt;/p&ggtt;
&lltt;p&ggtt;Наблюдаемость агентов все еще находится на&nbsp;ранней стадии. Стандарты только формируются. Agent MD&nbsp;уже широко используется. Стандарты навыков и&nbsp;плагинов относительно новые. Инструментарий еще не&nbsp;зрелый, но&nbsp;схема ясна: инструментируйте своих агентов, централизуйте сигналы и&nbsp;анализируйте их&nbsp;в&nbsp;разных командах.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;нашему мнению, петли обратной связи в&nbsp;производственной среде&nbsp;— это недостающий элемент в&nbsp;разработке с&nbsp;использованием ИИ. Когда что-то ломается в&nbsp;производственной среде, отследите это до&nbsp;изменения, определите категорию ошибки и&nbsp;передайте ее&nbsp;обратно как на&nbsp;уровень промптов, так и&nbsp;на&nbsp;уровень проверки. Этап наблюдаемости в&nbsp;CDLC расширяет эту идею от&nbsp;качества кода до&nbsp;качества контекста. Сигналы, собранные из&nbsp;журналов агентов, исправлений разработчиков и&nbsp;подсчета шагов, напрямую используются для создания более качественных навыков, написания более целенаправленных оценок и&nbsp;дистрибуции улучшенных версий.&lltt;/p&ggtt;
&lltt;h3&ggtt;Самосовершенствующаяся агентная разработка&lltt;/h3&ggtt;
&lltt;p&ggtt;Полностью замкнутый цикл выглядит как система, в&nbsp;которой журналы агентов используются для анализа, выявляющего пробелы. Эти пробелы генерируют новые навыки или обновления существующих. Обновленные навыки проходят оценку перед выпуском. Они распространяются через реестр с&nbsp;контролем версий. И&nbsp;цикл повторяется.&lltt;/p&ggtt;
&lltt;p&ggtt;Дюбуа реалистично оценивает конечный результат. Видение «темной фабрики», где агенты создают код без участия человека, он&nbsp;называет «благородным направлением, но&nbsp;рискованной игрой». Команды, которые приближаются к&nbsp;этому (те, кто может с&nbsp;уверенностью сказать, что они больше не&nbsp;читают код),&nbsp;— это&nbsp;те, кто вложили значительные средства в&nbsp;контекст, тестирование и&nbsp;инфраструктуру наблюдаемости, которые делают их&nbsp;агентов достаточно надежными, чтобы требовать меньшего количество человеческих вмешательств в&nbsp;цикле.&lltt;/p&ggtt;]]></source>
<adate>09.09.2026</adate>
<dbid>235495</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/c45/hmwhjdu2sxuavlyep6uxwg3rlgznavz5.jpg]]>
</images>
<imagesname><![CDATA[;; ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Почему AI-пилоты не становятся продуктами]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235491]]></link>
<description><![CDATA[Создать работающий прототип искусственного интеллекта сегодня значительно проще, чем довести его до промышленного внедрения. Современные модели позволяют быстро показать убедительный результат, однако именно после успешного пилота начинается самая сложная часть работы. На основе опыта разработки AI-решений для медицины и юриспруденции я разберу, почему многие проекты так и не становятся полноценными продуктами и какие ошибки чаще всего приводят к этому. По данным McKinsey «Global Survey 2025», 88% респондентов сообщили, что в их организации регулярно используют AI хотя бы в одной бизнес-функции. При этом почти две трети организаций ещё не начали масштабировать AI на уровне всей компании. Лишь 39% респондентов сообщили о влиянии AI на EBIT на уровне всей организации. Этот разрыв показателен. Ограничением всё реже становится техническая реализация AI-модели. Основные проблемы начинаются после того, как модель впервые выдала правильный ответ. Похожая картина видна и в российских данных. В исследовании ИСИЭЗ НИУ ВШЭ «Применение искусственного интеллекта в российских компаниях» отмечается, что среди организаций, использующих ИИ, значимыми барьерами остаются не только затраты, но и инфраструктура, нехватка квалифицированных кадров, дефицит данных, сложность интеграции ИИ в бизнес-процессы, законодательные ограничения и качество данных. Пилот должен доказать не только техническую возможность, но и три более важные вещи: организация готова платить за продукт, пользователи хотят его применять и решение можно встроить в реальный процесс без потери всей ожидаемой экономии. Если хотя бы одно из этих условий не выполнено, даже сильный ИИ рискует остаться демонстрацией. Главная причина неудачи большинства AI-проектов — не слабая модель, а разрыв между демонстрацией технологии и ее использованием в реальном рабочем процессе. Демо оптимизирует ответ, бизнес — весь процесс На демонстрации AI-продукт обычно получает подготовленные данные и за несколько секунд может сформировать хорошее впечатление. На этом фоне легко решить, что основная часть задачи уже выполнена. Но ответ модели — только один этап рабочего процесса. После него результат необходимо проверить, исправить, согласовать, сохранить в корпоративной системе и использовать для принятия решения. До обращения к модели данные также нужно найти, подготовить и передать в подходящем формате. Поэтому локальное ускорение одной операции не гарантирует ускорения процесса целиком. AI ускоряет отдельную операцию. Бизнес оценивает, насколько быстрее завершился весь процесс. Именно здесь чаще всего возникает разрыв между успешным пилотом и реальным внедрением. Похожий эффект виден в разработке ПО. Исследование NBER по более чем 100 тыс. GitHub-разработчиков показало, что для автономных AI-инструментов рост coding activity составил около 180%, но рост фактически выпущенных релизов — только около 30%. Авторы объясняют разрыв последующими человеческими и производственными ограничениями: проверкой, интеграцией и выпуском. С похожей ситуацией я сталкивался при разработке AI-решений для медицины и юриспруденции. Даже когда модель демонстрировала высокое качество на тестовых сценариях, этого было недостаточно для внедрения. Основная работа начиналась после получения ответа модели: нужно было встроить систему в существующие процессы, сократить объем ручной проверки и сделать так, чтобы использование AI действительно экономило время специалиста, а не создавало новые этапы работы. Для отраслевого AI действует тот же принцип. Система может подготовить документ за минуту, но специалисту потребуется значительно больше времени, чтобы проверить факты, источники и применимость результата. Она может предложить решение, которое затем придётся вручную переносить в другую информационную систему. Она может ускорить работу одного сотрудника и одновременно создать дополнительную очередь у следующего участника процесса. Поэтому заказчика интересует не скорость первого ответа, его интересует время до завершенного и проверенного результата. Перед началом разработки полезно ответить на несколько вопросов: какое действие пользователя должно измениться, какой этап процесса исчезнет или сократится, сколько времени займет проверка, что произойдёт после получения ответа и не возникнет ли новое узкое место дальше по цепочке. Позднее вовлечение пользователей создает мертворожденные продукты Одна из самых распространённых ошибок — подключать будущих пользователей только на этапе пилота. Эта ошибка встречается и в начинающих стартапах, и во внутренних командах крупных компаний. Разработчики несколько месяцев создают решение, исходя из собственного представления о работе врача, юриста, бухгалтера, инженера, оператора или менеджера. На демонстрации всё выглядит убедительно. Данные подготовлены, сценарий заранее выбран, сложные случаи исключены или специально подобраны такие, с которыми решение справляется. Но когда продукт впервые попадает к специалисту, возникают базовые вопросы. Как вообще пользоваться решением? Как оно будет интегрировано в привычные рабочие инструменты? На чем основан ответ системы? Откуда должны поступать данные? Что делать с ответом? Почему новый сценарий лучше привычного? Кто отвечает, если результат окажется неверным? Будет ли у специалиста время проверять вывод модели? Если эти вопросы появляются в конце разработки, команда проверяет продуктовую гипотезу слишком поздно. Так возникает демонстрационный долг: набор неподтвержденных предположений о поведении пользователя, данных, интеграциях и ответственности. Чем дольше команда строит продукт, не проверяя эти предположения, тем дороже становится их пересмотр. Обратная связь специалиста нужна не после создания MVP, а до выбора основного сценария. Недостаточно провести интервью и попросить пользователя перечислить проблемы. Полезнее наблюдать за реальной работой: какие системы он открывает, где копирует данные, что перепроверяет, кому передает результат и в каких случаях действует в обход официального процесса, где сейчас узкое горлышко. В профессиональных областях пользователь не просто оценивает удобство интерфейса. Он помогает определить саму логику продукта: какие данные обязательны, какие исключения критичны, когда автоматизация допустима, где нужен контроль человека и какие ошибки нельзя пропустить. Поэтому участие пользователя не должно превращаться в бесконечный сбор пожеланий. Команда должна проверять конкретные гипотезы: возникает ли проблема достаточно часто, меняет ли прототип поведение специалиста, возвращается ли он к продукту без напоминаний, готов ли использовать его на реальных данных и становится ли процесс быстрее или качественнее после проверки результата. Если ответы отрицательные, продукт нужно менять, а не дополнять новыми функциями. На старте важнее не пытаться создать идеального ИИ-юриста, врача или бухгалтера, а качественно закрыть одну актуальную задачу и только после успешного MVP расширять функциональность. Иначе команда рискует создать продукт-Франкенштейн: он претендует на решение всего сразу, но по факту не закрывает достаточно хорошо ни один сценарий. На раннем этапе гораздо ценнее решить одну повторяющуюся задачу лучше существующих инструментов, чем пытаться автоматизировать весь процесс сразу. Именно так появляются продукты, которыми специалисты начинают пользоваться каждый день. Пользователь, эксперт и покупатель — не один человек Для вертикального AI-продукта недостаточно найти отраслевого эксперта. На практике я быстро убедился, что понимание профессиональной задачи — только часть работы. Даже если специалисты высоко оценивают решение, это еще не означает, что оно будет внедрено. Для появления продукта в организации должны совпасть интересы сразу нескольких участников процесса. Эксперт помогает понять процесс, профессиональные требования и цену ошибок. Но он не обязательно распоряжается бюджетом и может не влиять на закупку. В сложных B2B-продажах вокруг продукта обычно возникает несколько ролей: специалист, который будет им пользоваться; эксперт, помогающий его проектировать; внутренний сторонник, продвигающий решение; владелец бюджета; лицо, подписывающее договор; ИТ и информационная безопасность; юридическая служба и закупки. Команда может сделать отличный продукт для пользователя, но не иметь доступа к покупателю. В этом случае продажи не начнутся. Обратная ситуация тоже возможна: руководитель видит экономический смысл и готов приобрести решение, хотя часть специалистов относится к нему скептически. Такой сценарий может привести к первому контракту, но не гарантирует регулярного применения. Первая продажа и устойчивое внедрение — разные задачи. Лицо, принимающее решение, определяет вероятность контракта. Пользователь определяет вероятность регулярного использования, измеримого результата и продления. Продать AI-продукт и добиться его ежедневного использования — две разные задачи. Первый контракт подтверждает интерес рынка. Регулярная работа пользователей подтверждает ценность продукта. Поэтому до создания полноценного MVP команде полезно составить карту участников: кто испытывает проблему, кто будет пользоваться системой, кто получает экономический эффект, кто выделяет бюджет, кто может заблокировать внедрение и через какой контакт можно выйти на организацию. В узких B2B- и B2G-сегментах человек, умеющий открывать двери к нужным лицам, иногда решает половину коммерческой задачи. Хороший продукт без канала выхода на покупателя может годами оставаться экспериментом. Считать нужно стоимость проверенного результата Экономику AI часто оценивают через стоимость модели и время генерации. Для профессиональных продуктов этого недостаточно. Полная стоимость операции включает получение и подготовку данных, работу модели, проверку человеком, исправление результата, перенос в рабочую систему и ожидаемую стоимость возможных ошибок. Для бизнеса важна не стоимость работы модели, а стоимость получения проверенного результата. Именно этот показатель определяет экономический эффект внедрения. Особенно важна стоимость проверки. Если специалисту нужно заново прочитать все источники, чтобы убедиться в правильности подготовленного анализа, продукт может почти не экономить время. Если пользователь после автоматической обработки данных вынужден заново собирать структуру результата, автоматизация создает дополнительную работу. Средняя точность модели здесь тоже мало говорит об экономике. Десятипроцентная доля ошибок может быть приемлемой, если ошибки легко заметить и дёшево исправить. Она может быть недопустимой, если результат выглядит убедительно, ошибка обнаруживается поздно и влияет на последующие решения. В профессиональных процессах особенно опасны ошибки, которые не выглядят как ошибки. Пользователь видит аккуратно оформленный текст, таблицу или рекомендацию и тратит меньше внимания на проверку. В результате риск смещается с этапа генерации на этап принятия решения. Поэтому полезнее измерять не только точность модели, но и продуктовые показатели: время до проверенного результата, долю ответов, потребовавших исправления, частоту критических пропусков, долю результатов, принятых пользователем, долю случаев, переданных человеку, и стоимость одного полностью завершенного случая. Отдельно важно раскладывать процесс на этапы. Недостаточно сказать, что AI-автоматизация улучшила работу специалиста. Нужно понимать, сколько ресурсов уходит на подготовку данных, поиск релевантной информации, проверку источников, формирование итогового ответа, перенос результата в рабочую систему и последующую коммуникацию. Но сами метрики мало что дают, если процесс рассматривается как единая неделимая задача. Его нужно раскладывать на отдельные операции: подготовку документов, поиск релевантной информации, перепроверку источников, формирование итогового ответа, перенос данных в рабочую систему и последующую коммуникацию. Такая декомпозиция позволяет понять, какой именно участок ИИ действительно улучшает, а где эффект теряется. Иногда оказывается, что на первом этапе не нужно автоматизировать всю цепочку. Более сильной продуктовой гипотезой может быть узкое решение, которое качественно закрывает один дорогой этап, например, поиск и структурирование релевантной информации для специалиста, оставляя финальный вывод или коммуникацию человеку. Поэтому главный вопрос для разработчиков должен звучать не «насколько хорошо модель отвечает?», а «насколько качественно и надежно система закрывает выбранный участок реальной задачи и делает ли это выгоднее текущего процесса?» Пилот должен проверять организацию, а не только технологию У пилота почти всегда более благоприятные условия, чем у будущего продукта. В нём участвуют мотивированные пользователи, команда разработчиков быстро помогает при сбоях, данные можно подготовить вручную, нестандартные случаи временно исключаются, интеграции заменяются переносом информации между системами. Такой пилот может подтвердить техническую гипотезу, но ничего не сказать о готовности к эксплуатации. За последние несколько лет я пришел к выводу, что пилот проверяет не столько технологию, сколько готовность организации изменить собственные процессы. Если компания не готова встроить новое решение в ежедневную работу, даже успешная демонстрация не приведет к масштабному внедрению. Промышленное внедрение требует ответов на другие вопросы: кто отвечает за результат, как система получает реальные данные, как управляются права доступа, кто устраняет сбои, как обучаются новые сотрудники, из какого бюджета оплачивается эксплуатация, что происходит после обновления модели и по каким критериям решение масштабируется или закрывается. Именно эти вопросы часто оказываются важнее качества демонстрации. Российский аналитический доклад «Индекс готовности приоритетных отраслей экономики Российской Федерации к внедрению искусственного интеллекта» рассматривает готовность к ИИ не только через наличие технологий, но и через нецифровые факторы: государственную политику, регулирование, стратегическое планирование, корпоративное управление, кадры и компетенции, исследования и разработки. Отдельно учитываются цифровые основы: инфраструктура, данные, доверие и безопасность. На практике это означает, что зрелость AI-проекта определяется всей системой вокруг модели: процессами, ответственностью, инфраструктурой и готовностью сотрудников использовать новый инструмент. Отдельная проблема — интеграции. Во многих отраслях рабочий процесс уже распределен между несколькими системами. Если AI-инструмент требует от пользователя копировать данные между окнами, вручную переносить результат и отдельно проверять источники, часть экономии исчезает. Кроме того, у разных клиентов могут быть разные вендоры внутрикорпоративных систем. В таком случае именно вопрос интеграции может стать главным узким горлышком всего проекта. Важно вовремя признать неверную гипотезу После нескольких кварталов разработки команде становится сложно отказаться от продукта. Уже потрачен бюджет, руководству обещан результат, подготовлены презентации, участники проекта связали с ним свою профессиональную репутацию. С этой ситуацией сталкиваются и стартапы, и крупные компании. Чем больше времени и ресурсов вложено в проект, тем сложнее объективно оценить, действительно ли он решает проблему пользователя или команда продолжает развивать его по инерции. Если видно, что продукт не находит ожидаемого рыночного спроса, вместо признания ошибки иногда начинается поиск любого подразделения или внешнего клиента, которому можно предложить уже созданное решение. Команда перестает искать продукт под проблему и начинает искать проблему под продукт. Продажа в таком случае становится способом оправдать предыдущую работу, но необходимо различать проблемы выхода на рынок и отсутствие самой потребности. Самая дорогая ошибка в AI — не отказаться от неверной гипотезы вовремя. Если специалисты регулярно используют решение, самостоятельно возвращаются к нему и готовы мириться с несовершенствами, но компания не может выйти на владельца бюджета, вероятно, проблема находится в продажах. Если пользователь открывает продукт только по просьбе команды, не меняет привычный процесс и не замечает его улучшения, проблема, скорее всего, находится в продуктовой гипотезе. Если покупатель заинтересован, но стоимость интеграции превышает ожидаемый эффект, нужно менять архитектуру или целевой сегмент. Чтобы не принимать решения под влиянием уже понесенных затрат, проект полезно разделить на последовательные проверки. Первая проверка — проблема. Подтверждена ли она реальным поведением, а не только интервью? Вторая — пользователь. Становится ли его работа лучше после проверки результата? Продолжает ли он пользоваться продуктом без напоминания? Третья — покупатель. Существует ли владелец бюджета и понятный мотив для покупки? Четвертая — экономика. Сокращается ли полная стоимость процесса? Повышается ли итоговая ценность результата? Пятая — эксплуатация. Способна ли организация поддерживать решение без постоянного участия команды разработки? Как и на каких условиях будет осуществляться дальнейшее взаимодействие покупателя и разработчика? После каждого этапа должно оставаться три равноправных варианта: продолжить развитие продукта, изменить направление или остановить проект. Отказ от первоначальной гипотезы — это не поражение, а результат качественной проверки идеи. На практике успех AI-проекта определяется не тем, насколько быстро команда обучила модель, а тем, насколько рано она получила честные ответы на ключевые вопросы: существует ли проблема, готовы ли специалисты менять свои рабочие процессы, увидит ли бизнес экономический эффект и сможет ли организация поддерживать решение после внедрения. Именно поэтому главный показатель зрелости AI-команды сегодня — не количество разработанных моделей, а способность вовремя отказаться от неверных предположений и сосредоточиться на задачах, которые действительно создают ценность для пользователей и бизнеса. Путь от AI-пилота до востребованного продукта начинается не с обучения модели, а с понимания задачи, которую действительно необходимо решить. #IMAGE_235492#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Создать работающий прототип искусственного интеллекта сегодня значительно проще, чем довести его до&nbsp;промышленного внедрения. Современные модели позволяют быстро показать убедительный результат, однако именно после успешного пилота начинается самая сложная часть работы. На&nbsp;основе опыта разработки AI-решений для медицины и&nbsp;юриспруденции &lltt;/em&ggtt;&lltt;em&ggtt;я&lltt;/em&ggtt;&lltt;em&ggtt;&nbsp;разбер&lltt;/em&ggtt;&lltt;em&ggtt;у&lltt;/em&ggtt;&lltt;em&ggtt;, почему многие проекты так и&nbsp;не&nbsp;становятся полноценными продуктами и&nbsp;какие ошибки чаще всего приводят к&nbsp;этому.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;данным McKinsey «Global Survey 2025», 88% респондентов сообщили, что в&nbsp;их&nbsp;организации регулярно используют&nbsp;AI хотя&nbsp;бы в&nbsp;одной бизнес-функции. При этом почти две трети организаций ещё не&nbsp;начали масштабировать AI&nbsp;на уровне всей компании. Лишь&nbsp;39% респондентов сообщили о&nbsp;влиянии AI&nbsp;на EBIT на&nbsp;уровне всей организации.&lltt;/p&ggtt;
&lltt;p&ggtt;Этот разрыв показателен. Ограничением всё реже становится техническая реализация AI-модели. Основные проблемы начинаются после того, как модель впервые выдала правильный ответ.&lltt;/p&ggtt;
&lltt;p&ggtt;Похожая картина видна и&nbsp;в&nbsp;российских данных. В&nbsp;исследовании ИСИЭЗ НИУ ВШЭ «Применение искусственного интеллекта в&nbsp;российских компаниях» отмечается, что среди организаций, использующих&nbsp;ИИ, значимыми барьерами остаются не&nbsp;только затраты, но&nbsp;и&nbsp;инфраструктура, нехватка квалифицированных кадров, дефицит данных, сложность интеграции&nbsp;ИИ в&nbsp;бизнес-процессы, законодательные ограничения и&nbsp;качество данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Пилот должен доказать не&nbsp;только техническую возможность, но&nbsp;и&nbsp;три более важные вещи: организация готова платить за&nbsp;продукт, пользователи хотят его применять и&nbsp;решение можно встроить в&nbsp;реальный процесс без потери всей ожидаемой экономии. Если хотя&nbsp;бы одно из&nbsp;этих условий не&nbsp;выполнено, даже сильный&nbsp;ИИ рискует остаться демонстрацией.&lltt;/p&ggtt;
&lltt;p&ggtt;Главная причина неудачи большинства AI-проектов&nbsp;— не&nbsp;слабая модель, а&nbsp;разрыв между демонстрацией технологии и&nbsp;ее&nbsp;использованием в&nbsp;реальном рабочем процессе.&lltt;/p&ggtt;
&lltt;h3&ggtt;Демо оптимизирует ответ, бизнес&nbsp;— весь процесс&lltt;/h3&ggtt;
&lltt;p&ggtt;На&nbsp;демонстрации AI-продукт обычно получает подготовленные данные и&nbsp;за&nbsp;несколько секунд может сформировать хорошее впечатление. На&nbsp;этом фоне легко решить, что основная часть задачи уже выполнена. Но&nbsp;ответ модели&nbsp;— только один этап рабочего процесса. После него результат необходимо проверить, исправить, согласовать, сохранить в&nbsp;корпоративной системе и&nbsp;использовать для принятия решения. До&nbsp;обращения к&nbsp;модели данные также нужно найти, подготовить и&nbsp;передать в&nbsp;подходящем формате.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому локальное ускорение одной операции не&nbsp;гарантирует ускорения процесса целиком.&lltt;/p&ggtt;
&lltt;p&ggtt;AI&nbsp;ускоряет отдельную операцию. Бизнес оценивает, насколько быстрее завершился весь процесс. Именно здесь чаще всего возникает разрыв между успешным пилотом и&nbsp;реальным внедрением.&lltt;/p&ggtt;
&lltt;p&ggtt;Похожий эффект виден в&nbsp;разработке ПО. Исследование NBER по&nbsp;более чем 100&nbsp;тыс. GitHub-разработчиков показало, что для автономных AI-инструментов рост coding activity составил около 180%, но&nbsp;рост фактически выпущенных релизов&nbsp;— только около 30%. Авторы объясняют разрыв последующими человеческими и&nbsp;производственными ограничениями: проверкой, интеграцией и&nbsp;выпуском.&lltt;/p&ggtt;
&lltt;p&ggtt;С&nbsp;похожей ситуацией я&nbsp;сталкивался при разработке AI-решений для медицины и&nbsp;юриспруденции. Даже когда модель демонстрировала высокое качество на&nbsp;тестовых сценариях, этого было недостаточно для внедрения. Основная работа начиналась после получения ответа модели: нужно было встроить систему в&nbsp;существующие процессы, сократить объем ручной проверки и&nbsp;сделать так, чтобы использование&nbsp;AI действительно экономило время специалиста, а&nbsp;не&nbsp;создавало новые этапы работы.&lltt;/p&ggtt;
&lltt;p&ggtt;Для отраслевого&nbsp;AI действует тот&nbsp;же принцип. Система может подготовить документ за&nbsp;минуту, но&nbsp;специалисту потребуется значительно больше времени, чтобы проверить факты, источники и&nbsp;применимость результата. Она может предложить решение, которое затем придётся вручную переносить в&nbsp;другую информационную систему. Она может ускорить работу одного сотрудника и&nbsp;одновременно создать дополнительную очередь у&nbsp;следующего участника процесса. Поэтому заказчика интересует не&nbsp;скорость первого ответа, его интересует время до&nbsp;завершенного и&nbsp;проверенного результата.&lltt;/p&ggtt;
&lltt;p&ggtt;Перед началом разработки полезно ответить на&nbsp;несколько вопросов: какое действие пользователя должно измениться, какой этап процесса исчезнет или сократится, сколько времени займет проверка, что произойдёт после получения ответа и&nbsp;не&nbsp;возникнет&nbsp;ли новое узкое место дальше по&nbsp;цепочке.&lltt;/p&ggtt;
&lltt;h3&ggtt;Позднее вовлечение пользователей создает мертворожденные продукты&lltt;/h3&ggtt;
&lltt;p&ggtt;Одна из&nbsp;самых распространённых ошибок&nbsp;— подключать будущих пользователей только на&nbsp;этапе пилота. Эта ошибка встречается и&nbsp;в&nbsp;начинающих стартапах, и&nbsp;во&nbsp;внутренних командах крупных компаний. Разработчики несколько месяцев создают решение, исходя из&nbsp;собственного представления о&nbsp;работе врача, юриста, бухгалтера, инженера, оператора или менеджера.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;демонстрации всё выглядит убедительно. Данные подготовлены, сценарий заранее выбран, сложные случаи исключены или специально подобраны такие, с&nbsp;которыми решение справляется. Но&nbsp;когда продукт впервые попадает к&nbsp;специалисту, возникают базовые вопросы.&lltt;/p&ggtt;
&lltt;p&ggtt;Как вообще пользоваться решением? Как оно будет интегрировано в&nbsp;привычные рабочие инструменты? На&nbsp;чем основан ответ системы? Откуда должны поступать данные? Что делать с&nbsp;ответом? Почему новый сценарий лучше привычного? Кто отвечает, если результат окажется неверным? Будет&nbsp;ли у&nbsp;специалиста время проверять вывод модели?&lltt;/p&ggtt;
&lltt;p&ggtt;Если эти вопросы появляются в&nbsp;конце разработки, команда проверяет продуктовую гипотезу слишком поздно. Так возникает демонстрационный долг: набор неподтвержденных предположений о&nbsp;поведении пользователя, данных, интеграциях и&nbsp;ответственности. Чем дольше команда строит продукт, не&nbsp;проверяя эти предположения, тем дороже становится их&nbsp;пересмотр.&lltt;/p&ggtt;
&lltt;p&ggtt;Обратная связь специалиста нужна не&nbsp;после создания MVP, а&nbsp;до&nbsp;выбора основного сценария. Недостаточно провести интервью и&nbsp;попросить пользователя перечислить проблемы. Полезнее наблюдать за&nbsp;реальной работой: какие системы он&nbsp;открывает, где копирует данные, что перепроверяет, кому передает результат и&nbsp;в&nbsp;каких случаях действует в&nbsp;обход официального процесса, где сейчас узкое горлышко.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;профессиональных областях пользователь не&nbsp;просто оценивает удобство интерфейса. Он&nbsp;помогает определить саму логику продукта: какие данные обязательны, какие исключения критичны, когда автоматизация допустима, где нужен контроль человека и&nbsp;какие ошибки нельзя пропустить.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому участие пользователя не&nbsp;должно превращаться в&nbsp;бесконечный сбор пожеланий. Команда должна проверять конкретные гипотезы: возникает&nbsp;ли проблема достаточно часто, меняет&nbsp;ли прототип поведение специалиста, возвращается&nbsp;ли он&nbsp;к&nbsp;продукту без напоминаний, готов&nbsp;ли использовать его на&nbsp;реальных данных и&nbsp;становится&nbsp;ли процесс быстрее или качественнее после проверки результата.&lltt;/p&ggtt;
&lltt;p&ggtt;Если ответы отрицательные, продукт нужно менять, а&nbsp;не&nbsp;дополнять новыми функциями. На&nbsp;старте важнее не&nbsp;пытаться создать идеального ИИ-юриста, врача или бухгалтера, а&nbsp;качественно закрыть одну актуальную задачу и&nbsp;только после успешного MVP расширять функциональность. Иначе команда рискует создать продукт-Франкенштейн: он&nbsp;претендует на&nbsp;решение всего сразу, но&nbsp;по&nbsp;факту не&nbsp;закрывает достаточно хорошо ни&nbsp;один сценарий.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;раннем этапе гораздо ценнее решить одну повторяющуюся задачу лучше существующих инструментов, чем пытаться автоматизировать весь процесс сразу. Именно так появляются продукты, которыми специалисты начинают пользоваться каждый день.&lltt;/p&ggtt;
&lltt;h3&ggtt;Пользователь, эксперт и&nbsp;покупатель&nbsp;— не&nbsp;один человек&lltt;/h3&ggtt;
&lltt;p&ggtt;Для вертикального AI-продукта недостаточно найти отраслевого эксперта.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;практике я&nbsp;быстро убедился, что понимание профессиональной задачи&nbsp;— только часть работы. Даже если специалисты высоко оценивают решение, это еще не&nbsp;означает, что оно будет внедрено. Для появления продукта в&nbsp;организации должны совпасть интересы сразу нескольких участников процесса.&lltt;/p&ggtt;
&lltt;p&ggtt;Эксперт помогает понять процесс, профессиональные требования и&nbsp;цену ошибок. Но&nbsp;он&nbsp;не&nbsp;обязательно распоряжается бюджетом и&nbsp;может не&nbsp;влиять на&nbsp;закупку.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;сложных B2B-продажах вокруг продукта обычно возникает несколько ролей: специалист, который будет им&nbsp;пользоваться; эксперт, помогающий его проектировать; внутренний сторонник, продвигающий решение; владелец бюджета; лицо, подписывающее договор; ИТ&nbsp;и&nbsp;информационная безопасность; юридическая служба и&nbsp;закупки.&lltt;/p&ggtt;
&lltt;p&ggtt;Команда может сделать отличный продукт для пользователя, но&nbsp;не&nbsp;иметь доступа к&nbsp;покупателю. В&nbsp;этом случае продажи не&nbsp;начнутся. Обратная ситуация тоже возможна: руководитель видит экономический смысл и&nbsp;готов приобрести решение, хотя часть специалистов относится к&nbsp;нему скептически. Такой сценарий может привести к&nbsp;первому контракту, но&nbsp;не&nbsp;гарантирует регулярного применения.&lltt;/p&ggtt;
&lltt;p&ggtt;Первая продажа и&nbsp;устойчивое внедрение&nbsp;— разные задачи. Лицо, принимающее решение, определяет вероятность контракта. Пользователь определяет вероятность регулярного использования, измеримого результата и&nbsp;продления. Продать AI-продукт и&nbsp;добиться его ежедневного использования&nbsp;— две разные задачи. Первый контракт подтверждает интерес рынка. Регулярная работа пользователей подтверждает ценность продукта.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому до&nbsp;создания полноценного MVP команде полезно составить карту участников: кто испытывает проблему, кто будет пользоваться системой, кто получает экономический эффект, кто выделяет бюджет, кто может заблокировать внедрение и&nbsp;через какой контакт можно выйти на&nbsp;организацию.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;узких B2B- и&nbsp;B2G-сегментах человек, умеющий открывать двери к&nbsp;нужным лицам, иногда решает половину коммерческой задачи. Хороший продукт без канала выхода на&nbsp;покупателя может годами оставаться экспериментом.&lltt;/p&ggtt;
&lltt;h3&ggtt;Считать нужно стоимость проверенного результата&lltt;/h3&ggtt;
&lltt;p&ggtt;Экономику AI&nbsp;часто оценивают через стоимость модели и&nbsp;время генерации. Для профессиональных продуктов этого недостаточно. Полная стоимость операции включает получение и&nbsp;подготовку данных, работу модели, проверку человеком, исправление результата, перенос в&nbsp;рабочую систему и&nbsp;ожидаемую стоимость возможных ошибок. Для бизнеса важна не&nbsp;стоимость работы модели, а&nbsp;стоимость получения проверенного результата. Именно этот показатель определяет экономический эффект внедрения.&lltt;/p&ggtt;
&lltt;p&ggtt;Особенно важна стоимость проверки. Если специалисту нужно заново прочитать все источники, чтобы убедиться в&nbsp;правильности подготовленного анализа, продукт может почти не&nbsp;экономить время. Если пользователь после автоматической обработки данных вынужден заново собирать структуру результата, автоматизация создает дополнительную работу.&lltt;/p&ggtt;
&lltt;p&ggtt;Средняя точность модели здесь тоже мало говорит об&nbsp;экономике. Десятипроцентная доля ошибок может быть приемлемой, если ошибки легко заметить и&nbsp;дёшево исправить. Она может быть недопустимой, если результат выглядит убедительно, ошибка обнаруживается поздно и&nbsp;влияет на&nbsp;последующие решения.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;профессиональных процессах особенно опасны ошибки, которые не&nbsp;выглядят как ошибки. Пользователь видит аккуратно оформленный текст, таблицу или рекомендацию и&nbsp;тратит меньше внимания на&nbsp;проверку. В&nbsp;результате риск смещается с&nbsp;этапа генерации на&nbsp;этап принятия решения.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому полезнее измерять не&nbsp;только точность модели, но&nbsp;и&nbsp;продуктовые показатели: время до&nbsp;проверенного результата, долю ответов, потребовавших исправления, частоту критических пропусков, долю результатов, принятых пользователем, долю случаев, переданных человеку, и&nbsp;стоимость одного полностью завершенного случая.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельно важно раскладывать процесс на&nbsp;этапы. Недостаточно сказать, что AI-автоматизация улучшила работу специалиста. Нужно понимать, сколько ресурсов уходит на&nbsp;подготовку данных, поиск релевантной информации, проверку источников, формирование итогового ответа, перенос результата в&nbsp;рабочую систему и&nbsp;последующую коммуникацию.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;сами метрики мало что дают, если процесс рассматривается как единая неделимая задача. Его нужно раскладывать на&nbsp;отдельные операции: подготовку документов, поиск релевантной информации, перепроверку источников, формирование итогового ответа, перенос данных в&nbsp;рабочую систему и&nbsp;последующую коммуникацию.&lltt;/p&ggtt;
&lltt;p&ggtt;Такая декомпозиция позволяет понять, какой именно участок&nbsp;ИИ действительно улучшает, а&nbsp;где эффект теряется. Иногда оказывается, что на&nbsp;первом этапе не&nbsp;нужно автоматизировать всю цепочку. Более сильной продуктовой гипотезой может быть узкое решение, которое качественно закрывает один дорогой этап, например, поиск и&nbsp;структурирование релевантной информации для специалиста, оставляя финальный вывод или коммуникацию человеку.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому главный вопрос для разработчиков должен звучать не&nbsp;«насколько хорошо модель отвечает?», а&nbsp;«насколько качественно и&nbsp;надежно система закрывает выбранный участок реальной задачи и&nbsp;делает&nbsp;ли это выгоднее текущего процесса?»&lltt;/p&ggtt;
&lltt;h3&ggtt;Пилот должен проверять организацию, а&nbsp;не&nbsp;только технологию&lltt;/h3&ggtt;
&lltt;p&ggtt;У&nbsp;пилота почти всегда более благоприятные условия, чем у&nbsp;будущего продукта. В&nbsp;нём участвуют мотивированные пользователи, команда разработчиков быстро помогает при сбоях, данные можно подготовить вручную, нестандартные случаи временно исключаются, интеграции заменяются переносом информации между системами. Такой пилот может подтвердить техническую гипотезу, но&nbsp;ничего не&nbsp;сказать о&nbsp;готовности к&nbsp;эксплуатации.&lltt;/p&ggtt;
&lltt;p&ggtt;За&nbsp;последние несколько лет я&nbsp;пришел к&nbsp;выводу, что пилот проверяет не&nbsp;столько технологию, сколько готовность организации изменить собственные процессы. Если компания не&nbsp;готова встроить новое решение в&nbsp;ежедневную работу, даже успешная демонстрация не&nbsp;приведет к&nbsp;масштабному внедрению.&lltt;/p&ggtt;
&lltt;p&ggtt;Промышленное внедрение требует ответов на&nbsp;другие вопросы: кто отвечает за&nbsp;результат, как система получает реальные данные, как управляются права доступа, кто устраняет сбои, как обучаются новые сотрудники, из&nbsp;какого бюджета оплачивается эксплуатация, что происходит после обновления модели и&nbsp;по&nbsp;каким критериям решение масштабируется или закрывается. Именно эти вопросы часто оказываются важнее качества демонстрации.&lltt;/p&ggtt;
&lltt;p&ggtt;Российский аналитический доклад «Индекс готовности приоритетных отраслей экономики Российской Федерации к&nbsp;внедрению искусственного интеллекта» рассматривает готовность к&nbsp;ИИ не&nbsp;только через наличие технологий, но&nbsp;и&nbsp;через нецифровые факторы: государственную политику, регулирование, стратегическое планирование, корпоративное управление, кадры и&nbsp;компетенции, исследования и&nbsp;разработки. Отдельно учитываются цифровые основы: инфраструктура, данные, доверие и&nbsp;безопасность.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;практике это означает, что зрелость AI-проекта определяется всей системой вокруг модели: процессами, ответственностью, инфраструктурой и&nbsp;готовностью сотрудников использовать новый инструмент.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельная проблема&nbsp;— интеграции. Во&nbsp;многих отраслях рабочий процесс уже распределен между несколькими системами. Если AI-инструмент требует от&nbsp;пользователя копировать данные между окнами, вручную переносить результат и&nbsp;отдельно проверять источники, часть экономии исчезает. Кроме того, у&nbsp;разных клиентов могут быть разные вендоры внутрикорпоративных систем. В&nbsp;таком случае именно вопрос интеграции может стать главным узким горлышком всего проекта.&lltt;/p&ggtt;
&lltt;h3&ggtt;Важно вовремя признать неверную гипотезу&lltt;/h3&ggtt;
&lltt;p&ggtt;После нескольких кварталов разработки команде становится сложно отказаться от&nbsp;продукта. Уже потрачен бюджет, руководству обещан результат, подготовлены презентации, участники проекта связали с&nbsp;ним свою профессиональную репутацию.&lltt;/p&ggtt;
&lltt;p&ggtt;С&nbsp;этой ситуацией сталкиваются и&nbsp;стартапы, и&nbsp;крупные компании. Чем больше времени и&nbsp;ресурсов вложено в&nbsp;проект, тем сложнее объективно оценить, действительно&nbsp;ли он&nbsp;решает проблему пользователя или команда продолжает развивать его по&nbsp;инерции.&lltt;/p&ggtt;
&lltt;p&ggtt;Если видно, что продукт не&nbsp;находит ожидаемого рыночного спроса, вместо признания ошибки иногда начинается поиск любого подразделения или внешнего клиента, которому можно предложить уже созданное решение. Команда перестает искать продукт под проблему и&nbsp;начинает искать проблему под продукт. Продажа в&nbsp;таком случае становится способом оправдать предыдущую работу, но&nbsp;необходимо различать проблемы выхода на&nbsp;рынок и&nbsp;отсутствие самой потребности. Самая дорогая ошибка в&nbsp;AI&nbsp;— не&nbsp;отказаться от&nbsp;неверной гипотезы вовремя.&lltt;/p&ggtt;
&lltt;p&ggtt;Если специалисты регулярно используют решение, самостоятельно возвращаются к&nbsp;нему и&nbsp;готовы мириться с&nbsp;несовершенствами, но&nbsp;компания не&nbsp;может выйти на&nbsp;владельца бюджета, вероятно, проблема находится в&nbsp;продажах.&lltt;/p&ggtt;
&lltt;p&ggtt;Если пользователь открывает продукт только по&nbsp;просьбе команды, не&nbsp;меняет привычный процесс и&nbsp;не&nbsp;замечает его улучшения, проблема, скорее всего, находится в&nbsp;продуктовой гипотезе.&lltt;/p&ggtt;
&lltt;p&ggtt;Если покупатель заинтересован, но&nbsp;стоимость интеграции превышает ожидаемый эффект, нужно менять архитектуру или целевой сегмент.&lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы не&nbsp;принимать решения под влиянием уже понесенных затрат, проект полезно разделить на&nbsp;последовательные проверки.&lltt;/p&ggtt;
&lltt;p&ggtt;Первая проверка&nbsp;— проблема. Подтверждена&nbsp;ли она реальным поведением, а&nbsp;не&nbsp;только интервью?&lltt;/p&ggtt;
&lltt;p&ggtt;Вторая&nbsp;— пользователь. Становится&nbsp;ли его работа лучше после проверки результата? Продолжает&nbsp;ли он&nbsp;пользоваться продуктом без напоминания?&lltt;/p&ggtt;
&lltt;p&ggtt;Третья&nbsp;— покупатель. Существует&nbsp;ли владелец бюджета и&nbsp;понятный мотив для покупки?&lltt;/p&ggtt;
&lltt;p&ggtt;Четвертая&nbsp;— экономика. Сокращается&nbsp;ли полная стоимость процесса? Повышается&nbsp;ли итоговая ценность результата?&lltt;/p&ggtt;
&lltt;p&ggtt;Пятая&nbsp;— эксплуатация. Способна&nbsp;ли организация поддерживать решение без постоянного участия команды разработки? Как и&nbsp;на&nbsp;каких условиях будет осуществляться дальнейшее взаимодействие покупателя и&nbsp;разработчика?&lltt;/p&ggtt;
&lltt;p&ggtt;После каждого этапа должно оставаться три равноправных варианта: продолжить развитие продукта, изменить направление или остановить проект. Отказ от&nbsp;первоначальной гипотезы&nbsp;— это не&nbsp;поражение, а&nbsp;результат качественной проверки идеи.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;практике успех AI-проекта определяется не&nbsp;тем, насколько быстро команда обучила модель, а&nbsp;тем, насколько рано она получила честные ответы на&nbsp;ключевые вопросы: существует&nbsp;ли проблема, готовы&nbsp;ли специалисты менять свои рабочие процессы, увидит&nbsp;ли бизнес экономический эффект и&nbsp;сможет&nbsp;ли организация поддерживать решение после внедрения.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому главный показатель зрелости AI-команды сегодня&nbsp;— не&nbsp;количество разработанных моделей, а&nbsp;способность вовремя отказаться от&nbsp;неверных предположений и&nbsp;сосредоточиться на&nbsp;задачах, которые действительно создают ценность для пользователей и&nbsp;бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;Путь от&nbsp;AI-пилота до&nbsp;востребованного продукта начинается не&nbsp;с&nbsp;обучения модели, а&nbsp;с&nbsp;понимания задачи, которую действительно необходимо решить.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235492#&lltt;/p&ggtt;]]></source>
<adate>09.09.2026</adate>
<dbid>235491</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/922/5r5hswe28ou2f1yechednvsxrqdfztsd.jpg]]>
</images>
<imagesname><![CDATA[;;Владимир Воробьев, генеральный директор АО &#8220;Экспертные платформы&#8221;   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Насколько защищены облака в России: Cloud Advisor проанализировал 40 000 виртуальных машин]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235489]]></link>
<description><![CDATA[Cloud Advisor представил первый в России отчёт о состоянии облачной безопасности: у 88% компаний — критические уязвимости на периметре, в каждой четвёртой инфраструктуре — вредоносное ПО. Российский бизнес стремительно осваивает публичные облака: всё больше компаний переносят туда свои сервисы и данные. Однако рост популярности облачных технологий закономерно привлекает и внимание злоумышленников. Чтобы оценить реальный уровень защищённости российских облачных инфраструктур, компания Cloud Advisor — #1 CNAPP в России — разработчик единой платформы облачной безопасности, проанализировала обезличенные данные десятков организаций: суммарно более 40 000 виртуальных машин в облаках Cloud.ru и Yandex Cloud. Результаты вошли в отчёт «Состояние облачной безопасности в России 2026». Главный вывод исследования: проблемы облачной безопасности носят системный характер и встречаются независимо от облачного провайдера, отрасли и размера компании. «Отчёт показывает тревожную картину — защищённость облачных инфраструктур в России остаётся низкой: практически нет организаций, у которых не были обнаружены критические проблемы. Причины сложившейся ситуации: нехватка знаний и экспертизы в облачной безопасности, а также попытки защитить облако привычными инструментами из on-premises сред. Такие решения не учитывают специфику облачных технологий и не способны обеспечить комплексную защиту. На глобальном уровне для защиты облаков стандартом де-факто стали специализированные решения класса CNAPP, которые обеспечивают полный контроль над облачной инфраструктурой. Отчёт — ориентир, по которому каждая компания может оценить возможные слабые места в своей инфраструктуре и начать действовать», — прокомментировал Михаил Захряпин, генеральный директор Cloud Advisor. Критические уязвимости на периметре — у 88% организаций. На публично доступных виртуальных машинах у 88% компаний есть уязвимости с CVSS-оценкой выше 9,0. Одна из причин — традиционные агентские и сетевые сканеры не успевают за темпом изменений в облаке и неизбежно создают «слепые зоны». В каждой четвёртой организации атака уже состоялась. У 24% организаций в инфраструктуре обнаружено вредоносное ПО. Это не потенциальный риск, а свидетельство состоявшегося проникновения: злоумышленники уже могли получить доступ к данным или использовать ресурсы компании для DDoS-атак и рассылки спама. Секреты на публично доступных ресурсах в открытом виде — у 39% организаций. На публично доступных виртуальных машинах у 39% компаний хранятся в открытом виде ключи, токены и пароли. Скомпрометировав такой ресурс, атакующий получает возможность бокового перемещения (lateral movement) по остальной инфраструктуре. Половина пользовательских учётных записей без MFA. 48% пользовательских учётных записей не защищены многофакторной аутентификацией, а у каждой второй организации есть привилегированная учётная запись без второго фактора. При этом 24% учётных записей не использовались более 90 дней — их удаление сократит эту часть поверхности атаки на четверть. Большинство ресурсов работает вхолостую. 55% виртуальных машин загружены менее чем на 10%. Оптимизация неиспользуемых и недостаточно загруженных ресурсов позволяет снизить затраты на облако до 30%. Полная версия отчёта содержит расширенную статистику и практические рекомендации по устранению угроз в публичном облаке. Компании могут использовать его как чек-лист для выявления рисков в собственной инфраструктуре, бенчмарк для сравнения своего уровня защищённости с другими пользователями облаков, набор аргументов для обоснования бюджета на информационную безопасность, а также — дорожную карту по защите облачной инфраструктуры на ближайший год]]></description>
<source><![CDATA[&lltt;p&ggtt;Cloud Advisor представил первый в&nbsp;России отчёт о&nbsp;состоянии облачной безопасности: у&nbsp;88% компаний&nbsp;— критические уязвимости на&nbsp;периметре, в&nbsp;каждой четвёртой инфраструктуре&nbsp;— вредоносное ПО.&lltt;/p&ggtt;
&lltt;p&ggtt;Российский бизнес стремительно осваивает публичные облака: всё больше компаний переносят туда свои сервисы и&nbsp;данные. Однако рост популярности облачных технологий закономерно привлекает и&nbsp;внимание злоумышленников. &lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы оценить реальный уровень защищённости российских облачных инфраструктур, компания Cloud Advisor&nbsp;— #1&nbsp;CNAPP в&nbsp;России&nbsp;— разработчик единой платформы облачной безопасности, проанализировала обезличенные данные десятков организаций: суммарно более 40&nbsp;000 виртуальных машин в&nbsp;облаках Cloud.ru и&nbsp;Yandex Cloud. Результаты вошли в&nbsp;отчёт «Состояние облачной безопасности в&nbsp;России 2026».&lltt;/p&ggtt;
&lltt;p&ggtt;Главный вывод исследования: проблемы облачной безопасности носят системный характер и&nbsp;встречаются независимо от&nbsp;облачного провайдера, отрасли и&nbsp;размера компании.&lltt;/p&ggtt;
&lltt;p&ggtt;«Отчёт показывает тревожную картину&nbsp;— защищённость облачных инфраструктур в&nbsp;России остаётся низкой: практически нет организаций, у&nbsp;которых не&nbsp;были обнаружены критические проблемы. Причины сложившейся ситуации: нехватка знаний и&nbsp;экспертизы в&nbsp;облачной безопасности, а&nbsp;также попытки защитить облако привычными инструментами из&nbsp;on-premises сред. Такие решения не&nbsp;учитывают специфику облачных технологий и&nbsp;не&nbsp;способны обеспечить комплексную защиту. На&nbsp;глобальном уровне для защиты облаков стандартом де-факто стали специализированные решения класса CNAPP, которые обеспечивают полный контроль над облачной инфраструктурой. Отчёт&nbsp;— ориентир, по&nbsp;которому каждая компания может оценить возможные слабые места в&nbsp;своей инфраструктуре и&nbsp;начать действовать»,&nbsp;— прокомментировал Михаил Захряпин, генеральный директор Cloud Advisor. &lltt;/p&ggtt;
&lltt;p&ggtt;Критические уязвимости на&nbsp;периметре&nbsp;— у&nbsp;88% организаций. На&nbsp;публично доступных виртуальных машинах у&nbsp;88% компаний есть уязвимости с&nbsp;CVSS-оценкой выше 9,0. Одна из&nbsp;причин&nbsp;— традиционные агентские и&nbsp;сетевые сканеры не&nbsp;успевают за&nbsp;темпом изменений в&nbsp;облаке и&nbsp;неизбежно создают «слепые зоны».&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;каждой четвёртой организации атака уже состоялась. У&nbsp;24% организаций в&nbsp;инфраструктуре обнаружено вредоносное ПО. Это не&nbsp;потенциальный риск, а&nbsp;свидетельство состоявшегося проникновения: злоумышленники уже могли получить доступ к&nbsp;данным или использовать ресурсы компании для DDoS-атак и&nbsp;рассылки спама.&lltt;/p&ggtt;
&lltt;p&ggtt;Секреты на&nbsp;публично доступных ресурсах в&nbsp;открытом виде&nbsp;— у&nbsp;39% организаций. На&nbsp;публично доступных виртуальных машинах у&nbsp;39% компаний хранятся в&nbsp;открытом виде ключи, токены и&nbsp;пароли. Скомпрометировав такой ресурс, атакующий получает возможность бокового перемещения (lateral movement) по&nbsp;остальной инфраструктуре.&lltt;/p&ggtt;
&lltt;p&ggtt;Половина пользовательских учётных записей без MFA. 48% пользовательских учётных записей не&nbsp;защищены многофакторной аутентификацией, а&nbsp;у&nbsp;каждой второй организации есть привилегированная учётная запись без второго фактора. При этом&nbsp;24% учётных записей не&nbsp;использовались более 90&nbsp;дней&nbsp;— их&nbsp;удаление сократит эту часть поверхности атаки на&nbsp;четверть.&lltt;/p&ggtt;
&lltt;p&ggtt;Большинство ресурсов работает вхолостую.&nbsp;55% виртуальных машин загружены менее чем на&nbsp;10%. Оптимизация неиспользуемых и&nbsp;недостаточно загруженных ресурсов позволяет снизить затраты на&nbsp;облако до&nbsp;30%.&lltt;/p&ggtt;
&lltt;p&ggtt;Полная версия отчёта содержит расширенную статистику и&nbsp;практические рекомендации по&nbsp;устранению угроз в&nbsp;публичном облаке. Компании могут использовать его как чек-лист для выявления рисков в&nbsp;собственной инфраструктуре, бенчмарк для сравнения своего уровня защищённости с&nbsp;другими пользователями облаков, набор аргументов для обоснования бюджета на&nbsp;информационную безопасность, а&nbsp;также&nbsp;— дорожную карту по&nbsp;защите облачной инфраструктуры на&nbsp;ближайший год.&lltt;/p&ggtt;]]></source>
<adate>08.09.2026</adate>
<dbid>235489</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[ICT.Moscow: в индустрии ИИ ищут пути эволюции LLM]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235488]]></link>
<description><![CDATA[Физический ИИ берет числом, при этом глобальная индустрия ищет пути эволюции LLM. Это следует из результатов опроса, проведенного ICT.Moscow в рамках исследования перспективных технологических тем. ICT.Moscow опросил более 200 российских специалистов в сфере искусственного интеллекта, чтобы определить, какие не массовые тренды, по данным глобальных прогнозов и анализа популярных тем в отечественных медиа, имеют потенциал к последующему развитию в ближайшее время в России. Респондентам было предложено выбрать несколько перспективных, по их мнению, вариантов из предложенных. Для интерпретации результатов авторами также была составлена визуализация с хронологией возникновения того или иного термина и отнесения его к целевой концепции ИИ, а также прошлому или текущему стеку этой технологии. Среди трендов, исследуемых в опросе, почти половина относится к направлению физического ИИ (Physical AI). В этой группе наиболее приоритетными (43%) стали VLA-модели (Vision-Language-Action Models). Их применяют в робототехнике для объединения компьютерного зрения, обработки естественного языка и управления физическими устройствами. Почти каждый третий проголосовавший (31%) ожидает дальнейшего развития моделей мира (World Models). Еще 23% получили более общие крупные модели действия (Large Action Models), создаваемые для того, чтобы реагировать действиями на получаемую внешнюю информацию. Этот термин применяется как в области робототехники, так и для обозначения ИИ-агентов, не имеющих физической оболочки. Среди ответов, относимых к физическому ИИ (но не ограничивающихся им), пока меньше всего ожиданий (18%) у респондентов связано с крупными поведенческими моделями (Large Behavior Models, LBM), которые нужны для понимания действий человека в физическом мире или виртуальной среде и обучения на их основе, с тем чтобы их моделировать или воспроизводить. Базовые модели (Foundation Models) хоть и находятся уже в списке не самых распространенных в аналитике и новостях понятий, тем не менее собрали 23% оценок у опрошенных. Сам термин во многом уже воспринимают как синоним LLM, и его смысловое наполнение пересматривается по мере развития этого класса моделей. Однако тот факт, что развивавшиеся с 2015 года диффузионные модели (Diffusion Models) переживают новую волну интереса, а также появление моделей взаимодействия (Interaction Models) как нового вида UX в контексте нативных мультимодальных нейросетей, цель которых — сделать более естественным общение человека с моделью, скорее всего, говорят о том, что в индустрии ищут новый виток развития LLM, в том числе в части взаимодействия их с человеком, или даже альтернативы им. В данном опросе за них отдали 23% и 17% голосов соответственно. Отдельное место среди вариантов ответов занимают целевые представления об ИИ, которые многими воспринимаются как финальные точки развития технологии и продолжают сохранять этот статус уже не одно десятилетие. Речь идет об общем (или сильном) искусственном интеллекте (Artificial General Intelligence, AGI) и искусственном сверх- или суперинтеллекте (Artificial Superintelligence, ASI). Тем не менее даже такие пока что гипотетические и отдаленные концепции получили поддержку как имеющие потенциал для развития. За общий ИИ проголосовали 22% участников, а за более отдаленный сверхинтеллект — 12%]]></description>
<source><![CDATA[&lltt;p&ggtt;Физический ИИ&nbsp;берет числом, при этом глобальная индустрия ищет пути эволюции LLM. Это следует из&nbsp;результатов опроса, проведенного ICT.Moscow в&nbsp;рамках исследования перспективных технологических тем.&lltt;/p&ggtt;
&lltt;p&ggtt;ICT.Moscow опросил более 200 российских специалистов в&nbsp;сфере искусственного интеллекта, чтобы определить, какие не&nbsp;массовые тренды, по&nbsp;данным глобальных прогнозов и&nbsp;анализа популярных тем в&nbsp;отечественных медиа, имеют потенциал к&nbsp;последующему развитию в&nbsp;ближайшее время в&nbsp;России. Респондентам было предложено выбрать несколько перспективных, по&nbsp;их&nbsp;мнению, вариантов из&nbsp;предложенных.&lltt;/p&ggtt;
&lltt;p&ggtt;Для интерпретации результатов авторами также была составлена визуализация с&nbsp;хронологией возникновения того или иного термина и&nbsp;отнесения его к&nbsp;целевой концепции&nbsp;ИИ, а&nbsp;также прошлому или текущему стеку этой технологии.&lltt;/p&ggtt;
&lltt;p&ggtt;Среди трендов, исследуемых в&nbsp;опросе, почти половина относится к&nbsp;направлению физического&nbsp;ИИ (Physical AI). В&nbsp;этой группе наиболее приоритетными (43%) стали VLA-модели (Vision-Language-Action Models). Их&nbsp;применяют в&nbsp;робототехнике для объединения компьютерного зрения, обработки естественного языка и&nbsp;управления физическими устройствами. Почти каждый третий проголосовавший (31%) ожидает дальнейшего развития моделей мира (World Models). Еще&nbsp;23% получили более общие крупные модели действия (Large Action Models), создаваемые для того, чтобы реагировать действиями на&nbsp;получаемую внешнюю информацию. Этот термин применяется как в&nbsp;области робототехники, так и&nbsp;для обозначения ИИ-агентов, не&nbsp;имеющих физической оболочки. Среди ответов, относимых к&nbsp;физическому&nbsp;ИИ (но&nbsp;не&nbsp;ограничивающихся&nbsp;им), пока меньше всего ожиданий (18%) у&nbsp;респондентов связано с&nbsp;крупными поведенческими моделями (Large Behavior Models, LBM), которые нужны для понимания действий человека в&nbsp;физическом мире или виртуальной среде и&nbsp;обучения на&nbsp;их&nbsp;основе, с&nbsp;тем чтобы их&nbsp;моделировать или воспроизводить.&lltt;/p&ggtt;
&lltt;p&ggtt;Базовые модели (Foundation Models) хоть и&nbsp;находятся уже в&nbsp;списке не&nbsp;самых распространенных в&nbsp;аналитике и&nbsp;новостях понятий, тем не&nbsp;менее собрали&nbsp;23% оценок у&nbsp;опрошенных. Сам термин во&nbsp;многом уже воспринимают как синоним LLM, и&nbsp;его смысловое наполнение пересматривается по&nbsp;мере развития этого класса моделей.&lltt;/p&ggtt;
&lltt;p&ggtt;Однако тот факт, что развивавшиеся с&nbsp;2015 года диффузионные модели (Diffusion Models) переживают новую волну интереса, а&nbsp;также появление моделей взаимодействия (Interaction Models) как нового вида UX&nbsp;в контексте нативных мультимодальных нейросетей, цель которых&nbsp;— сделать более естественным общение человека с&nbsp;моделью, скорее всего, говорят о&nbsp;том, что в&nbsp;индустрии ищут новый виток развития LLM, в&nbsp;том числе в&nbsp;части взаимодействия их&nbsp;с&nbsp;человеком, или даже альтернативы&nbsp;им. В&nbsp;данном опросе за&nbsp;них отдали&nbsp;23% и&nbsp;17% голосов соответственно.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельное место среди вариантов ответов занимают целевые представления об&nbsp;ИИ, которые многими воспринимаются как финальные точки развития технологии и&nbsp;продолжают сохранять этот статус уже не&nbsp;одно десятилетие. Речь идет об&nbsp;общем (или сильном) искусственном интеллекте (Artificial General Intelligence, AGI) и&nbsp;искусственном сверх- или суперинтеллекте (Artificial Superintelligence, ASI). Тем не&nbsp;менее даже такие пока что гипотетические и&nbsp;отдаленные концепции получили поддержку как имеющие потенциал для развития. За&nbsp;общий&nbsp;ИИ проголосовали&nbsp;22% участников, а&nbsp;за&nbsp;более отдаленный сверхинтеллект&nbsp;— 12%.&lltt;/p&ggtt;]]></source>
<adate>08.09.2026</adate>
<dbid>235488</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Indeed PAM 3.5 автоматизирует контроль сессий и ускоряет работу администраторов]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235486]]></link>
<description><![CDATA[Компания «Индид», российский разработчик решений в области защиты айдентити, представила новую версию Indeed Privileged Access Manager (Indeed PAM) 3.5 — системы для управления доступом привилегированных пользователей. Среди ключевых обновлений — автоматический контроль действий во время удаленных сессий, поддержка Kerberos для Linux-инсталляций и дополнительные сценарии работы через Web Terminal. Одним из главных обновлений Indeed PAM 3.5 стала возможность создавать правила контроля действий пользователей во время RDP-сессий. Администратор определяет события, которые необходимо отслеживать, например запуск определенного приложения или смену окна браузера, и задает реакцию системы: запись события в журнал, завершение сессии или блокировку пользователя. Так служба информационной безопасности может автоматически реагировать на нежелательные действия непосредственно во время подключения, не дожидаясь завершения сессии и последующего разбора событий. Это сокращает время между обнаружением действия и ответной мерой и снижает необходимость постоянно контролировать каждое подключение вручную. Правила можно вводить постепенно. На первом этапе Indeed PAM может только фиксировать заданные события, чтобы специалисты собрали статистику и оценили реальные сценарии работы пользователей. После этого для отдельных действий можно настроить более строгую реакцию. Такой сценарий позволяет последовательно распространять единые требования контроля на инфраструктуру с большим количеством привилегированных подключений. Другим важным улучшением стала поддержка аутентификации через Kerberos на серверах Indeed PAM под управлением Linux. Она доступна пользователям, учетные записи которых хранятся в Active Directory. Если пользователь входит в Indeed PAM с доменного компьютера, браузер выполняет сквозную аутентификацию — повторно вводить логин и пароль не нужно. При этом добавлять сервер управления в домен не требуется. Ранее такой сценарий поддерживался только при развертывании Indeed PAM на Windows. Новый функционал также расширяет возможности работы с учетными записями администраторов, включенных в группу Active Directory Protected Users. Участники этой группы не могут аутентифицироваться по протоколу NTLM и обязаны использовать Kerberos с шифрованием AES. Теперь такие пользователи получают доступ к Indeed PAM на Linux-инсталляциях, что позволяет соблюдать усиленные требования к защите учетных данных и одновременно продолжать перевод инфраструктуры на отечественные операционные системы. В Indeed PAM 3.5 разработчик уделил отдельное внимание возможностям Web Terminal — инструмента для удаленных подключений через браузер. Теперь через него можно устанавливать не только RDP- и SSH-сессии, но и подключаться к серверам Remote Desktop Services (RDS). Пользователь может открыть удаленный рабочий стол или опубликованное RemoteApp-приложение непосредственно в браузере — без скачивания RDP-файлов, установки локального клиента и повторной аутентификации. Благодаря этому компании могут предоставлять сотрудникам и подрядчикам доступ к рабочим средам и бизнес-приложениям, в том числе с неуправляемых устройств. Все подключения проходят через Indeed PAM, поэтому служба информационной безопасности может контролировать и записывать привилегированные сессии. Кроме этого, В Web Terminal также появилась передача файлов между устройством пользователя и целевым ресурсом. Для этого достаточно перенести файл в окно активной сессии. Это возможность управляется политиками Indeed PAM, поэтому организация может разрешить ее только для согласованных сценариев. «По мере роста числа привилегированных подключений компаниям становится все сложнее их контролировать. Поэтому одна из ключевых задач развития Indeed PAM — автоматизировать контроль там, где раньше требовалось постоянное участие специалиста. В новой версии 3.5 мы усилили именно этот сценарий: Indeed PAM может автоматически реагировать на заданные действия пользователей. Это особенно актуально для крупных инфраструктур, где число контролируемых ресурсов постоянно растет. Одновременно мы расширяем поддержку Linux-сред и браузерных сценариев удаленной работы, чтобы заказчики могли применять единые требования к защите привилегированного доступа в разных инфраструктурах», — отметил Михаил Елычев, руководитель продукта Indeed PAM в компании «Индид»]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания «Индид», российский разработчик решений в&nbsp;области защиты айдентити, представила новую версию Indeed Privileged Access Manager (Indeed PAM) 3.5&nbsp;— системы для управления доступом привилегированных пользователей. Среди ключевых обновлений&nbsp;— автоматический контроль действий во&nbsp;время удаленных сессий, поддержка Kerberos для Linux-инсталляций и&nbsp;дополнительные сценарии работы через Web Terminal.&lltt;/p&ggtt;
&lltt;p&ggtt;Одним из&nbsp;главных обновлений Indeed PAM 3.5 стала возможность создавать правила контроля действий пользователей во&nbsp;время RDP-сессий. Администратор определяет события, которые необходимо отслеживать, например запуск определенного приложения или смену окна браузера, и&nbsp;задает реакцию системы: запись события в&nbsp;журнал, завершение сессии или блокировку пользователя.&lltt;/p&ggtt;
&lltt;p&ggtt;Так служба информационной безопасности может автоматически реагировать на&nbsp;нежелательные действия непосредственно во&nbsp;время подключения, не&nbsp;дожидаясь завершения сессии и&nbsp;последующего разбора событий. Это сокращает время между обнаружением действия и&nbsp;ответной мерой и&nbsp;снижает необходимость постоянно контролировать каждое подключение вручную.&lltt;/p&ggtt;
&lltt;p&ggtt;Правила можно вводить постепенно. На&nbsp;первом этапе Indeed PAM может только фиксировать заданные события, чтобы специалисты собрали статистику и&nbsp;оценили реальные сценарии работы пользователей. После этого для отдельных действий можно настроить более строгую реакцию. Такой сценарий позволяет последовательно распространять единые требования контроля на&nbsp;инфраструктуру с&nbsp;большим количеством привилегированных подключений.&lltt;/p&ggtt;
&lltt;p&ggtt;Другим важным улучшением стала поддержка аутентификации через Kerberos на&nbsp;серверах Indeed PAM под управлением Linux. Она доступна пользователям, учетные записи которых хранятся в&nbsp;Active Directory. Если пользователь входит в&nbsp;Indeed PAM&nbsp;с доменного компьютера, браузер выполняет сквозную аутентификацию&nbsp;— повторно вводить логин и&nbsp;пароль не&nbsp;нужно. При этом добавлять сервер управления в&nbsp;домен не&nbsp;требуется. Ранее такой сценарий поддерживался только при развертывании Indeed PAM&nbsp;на Windows.&lltt;/p&ggtt;
&lltt;p&ggtt;Новый функционал также расширяет возможности работы с&nbsp;учетными записями администраторов, включенных в&nbsp;группу Active Directory Protected Users. Участники этой группы не&nbsp;могут аутентифицироваться по&nbsp;протоколу NTLM и&nbsp;обязаны использовать Kerberos с&nbsp;шифрованием AES. Теперь такие пользователи получают доступ к&nbsp;Indeed PAM&nbsp;на Linux-инсталляциях, что позволяет соблюдать усиленные требования к&nbsp;защите учетных данных и&nbsp;одновременно продолжать перевод инфраструктуры на&nbsp;отечественные операционные системы.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;Indeed PAM 3.5 разработчик уделил отдельное внимание возможностям Web Terminal&nbsp;— инструмента для удаленных подключений через браузер. Теперь через него можно устанавливать не&nbsp;только RDP- и&nbsp;SSH-сессии, но&nbsp;и&nbsp;подключаться к&nbsp;серверам Remote Desktop Services (RDS).&lltt;/p&ggtt;
&lltt;p&ggtt;Пользователь может открыть удаленный рабочий стол или опубликованное RemoteApp-приложение непосредственно в&nbsp;браузере&nbsp;— без скачивания RDP-файлов, установки локального клиента и&nbsp;повторной аутентификации.&lltt;/p&ggtt;
&lltt;p&ggtt;Благодаря этому компании могут предоставлять сотрудникам и&nbsp;подрядчикам доступ к&nbsp;рабочим средам и&nbsp;бизнес-приложениям, в&nbsp;том числе с&nbsp;неуправляемых устройств. Все подключения проходят через Indeed PAM, поэтому служба информационной безопасности может контролировать и&nbsp;записывать привилегированные сессии.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме этого, В&nbsp;Web Terminal также появилась передача файлов между устройством пользователя и&nbsp;целевым ресурсом. Для этого достаточно перенести файл в&nbsp;окно активной сессии. Это возможность управляется политиками Indeed PAM, поэтому организация может разрешить ее&nbsp;только для согласованных сценариев.&lltt;/p&ggtt;
&lltt;p&ggtt;«По&nbsp;мере роста числа привилегированных подключений компаниям становится все сложнее их&nbsp;контролировать. Поэтому одна из&nbsp;ключевых задач развития Indeed PAM&nbsp;— автоматизировать контроль там, где раньше требовалось постоянное участие специалиста. В&nbsp;новой версии 3.5&nbsp;мы усилили именно этот сценарий: Indeed PAM может автоматически реагировать на&nbsp;заданные действия пользователей. Это особенно актуально для крупных инфраструктур, где число контролируемых ресурсов постоянно растет. Одновременно мы&nbsp;расширяем поддержку Linux-сред и&nbsp;браузерных сценариев удаленной работы, чтобы заказчики могли применять единые требования к&nbsp;защите привилегированного доступа в&nbsp;разных инфраструктурах»,&nbsp;— отметил Михаил Елычев, руководитель продукта Indeed PAM&nbsp;в компании «Индид».&lltt;/p&ggtt;]]></source>
<adate>08.09.2026</adate>
<dbid>235486</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Внедрение &#8220;умных&#8221; электронных ценников: опыт &#8220;Лемана ПРО&#8221;]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235480]]></link>
<description><![CDATA[Внедрение «умных» электронных ценников увеличило продажи и высвободило 24 тыс. рабочих часов в год. «Лемана ПРО» начала масштабирование технологии «умных» электронных ценников на всю сеть: в течение двух лет они появятся во всех гипермаркетах. Рассмотрим, почему на внедрение технологии ушел почти год подготовки, зачем потребовалось менять бумажные ценники на электронные, как устроена архитектура решения, какими функциями обладают новые ценники и какие результаты уже показал пилотный запуск. Почему потребовалось менять бумажные ценники Идея перейти на электронные ценники обсуждалась в компании, еще когда эта технология только начинала набирать популярность. Но долгое время высокая стоимость самой технологии в России делала внедрение невыгодным. Ситуация изменилась, когда электронные ценники стали более доступными, а дефицит кадров на рынке труда и рост стоимости рабочего времени сделали такие вложения экономически оправданными. «Лемана ПРО» стала первым российским ритейлером в сегменте товаров для строительства, ремонта и обустройства, внедрившим «умные» электронные ценники в процессы логистики. Электронный ценник становится частью цифровой инфраструктуры магазина, которая делает покупки более удобными, предсказуемыми и прозрачными. Если раньше офлайн-магазины конкурировали в цене друг с другом, то сегодня они конкурируют с маркетплейсами, где покупатель привык видеть актуальную цену, отзывы, характеристики товара и получать всю информацию буквально за несколько минут. Поэтому сегодня задача ритейлера — обеспечить единый уровень удобства и клиентского опыта в любом канале, в том числе непосредственно у полки в магазине. Мало кто задумывается, сколько времени уходит на замену бумажных ценников. Каждое утро сотрудники печатают, сортируют и вручную меняют сотни карточек с ценами — на это уходит ежедневно по 2-3 часа, которые можно направить на обслуживание покупателей. Это одна из самых трудоемких операций в розничной торговле, которая практически незаметна клиенту, но напрямую влияет на его покупательский опыт. Год подготовки: выбор технологии и партнеров Прежде чем принять решение о внедрении, мы провели масштабный анализ рынка производителей и интеграторов. Российский рынок электронных ценников сегодня только формируется, а мировой рынок производителей и компаний-интеграторов сравнительно узкий. Почти год команда R&#38;D и автоматизации «Лемана ПРО» работала над выбором технологии, совершала визиты в Китай к производителям и на профильные выставки, чтобы сформировать требования к продукту. Параллельно мы консультировались с российскими ритейлерами, у которых уже был опыт внедрения подобных решений: у одних технология прижилась и продолжает развиваться, у других опыт оказался неудачным. Изучение обеих сторон помогло сформировать собственный путь внедрения и заранее обойти уже известные подводные камни. Итоговая модель работы — трехстороннее партнерство: китайский производитель оборудования и программного обеспечения, российский интегратор, который адаптирует решение под ИТ-ландшафт конкретного заказчика и обеспечивает обучение и поддержку, и сама компания. На старте проекта мы регулярно проводили совместные встречи, а на этапе внедрения в магазинах присутствовали разработчики китайского партнера, которые могли оперативно вносить корректировки в работу системы. При этом мы сознательно отказались от идеи писать программное обеспечение с нуля: кастомизации подвергаются только те элементы, которые создают конкурентное преимущество для компании, а не уже отлаженные вендором процессы. Один из таких принципиальных выборов — архитектура решения: мы выбрали облачную модель хранения и обмена данными, тогда как часть игроков рынка предпочитает локальные серверы в каждом магазине, ориентируясь на собственную ИТ-стратегию. Как устроена техническая архитектура В доставке цены от корпоративных систем до полки участвуют пять ключевых контуров: продукты ценообразования, слой агрегации и кеширования, планировщик обновлений, облачный сервер управления ESL (Electronic Shelf Labels, электронные ценники) и радиосеть магазина. Цены на товары устанавливаются в соответствии со стратегией компании «Низкие цены каждый день». Мы регулярно анализируем открытые данные о стоимости товаров на рынке и в соответствии с этим снижаем цены в магазинах, чтобы гарантировать покупателям наиболее выгодные условия. Роль Price Hub выполняет собственный репозиторий цен (Price Repository) — целевая мастер-система хранения, проверки и применения розничных цен. Это единый источник данных для десятков внутренних систем: касс, электронных ценников, онлайн-каналов и систем бизнес-аналитики. Репозиторий хранит полную историю изменений и несколько миллионов активных цен, поддерживает более 600 запросов на чтение и более 350 операций записи в секунду; 95% запросов на чтение обрабатываются не дольше 200 миллисекунд, а доступность обработки поступающих запросов составляет 99,9%. Сервис агрегации данных объединяет все параметры товара: цену за штуку или единицу измерения товара, уникальный код, дату применения, доступный остаток, клиентский рейтинг, баллы лояльности и другие атрибуты. Профиль сохраняется в специализированном кеше, чтобы минимизировать задержку при подготовке пакетов обновлений для ценников. «Умный» планировщик формирует график обновлений с учетом даты вступления цены в силу, состава данных, часового пояса магазина и смен сотрудников. Он распределяет пиковую нагрузку на инфраструктуру, помогает экономить заряд батарей и инициирует применение цены точно к назначенному времени. ПО вендора для управления электронными ценниками развернуто в защищенном приватном облаке «Лемана ПРО». Оно управляет связками «товар — ценник», картой радиопокрытия, жизненным циклом устройств и рендерингом: накладывает данные на дизайн-шаблон и формирует растровое изображение под разрешение E-ink-дисплея нужного формата. По защищенному сетевому протоколу изображения поступают на точки доступа под потолком торгового зала, а затем по энергоэффективному радиопротоколу — на конкретные ценники. Облачная модель позволила отказаться от дополнительных серверов в гипермаркетах. Обновления ПО централизованно распространяются по всей сети через единый конвейер данных, а микросервисы, базы данных, очереди сообщений и API контролируются в едином контуре мониторинга. Ресурсы можно гибко наращивать по мере подключения магазинов и при массовой плановой передаче обновлений на ценники, а резервирование обеспечивается на уровне облачного кластера. Что умеют новые ценники Электронные ценники в «Лемана ПРО» работают в двух режимах: в режиме «день» для покупателя и продавца-консультанта и «ночь» для сотрудника пополнения и сборки. Режимы переключаются автоматически по расписанию, индивидуальному для каждого магазина, в момент его открытия и закрытия. #IMAGE_235483# В режиме «день» на ценнике отображается не только цена, но и информация о размере кешбэка за покупку данного товара, оценка товара на основе отзывов покупателей на сайте, место товара на полке, наименование, объем/размер товара и его артикул. В режиме «ночь» отображается информация о необходимости пополнения товара на полке и ее вместимости, а также увеличивается размер шрифта для необходимых атрибутов — например, артикула товара, чтобы сотруднику магазина было проще и быстрее его найти. На сегодняшний день мы — единственный ритейлер на российском рынке, который работает в мультиформатном режиме с электронными ценниками, совмещая оба сценария использования. Отдельная функция электронных ценников — это «мигание»: она уже интегрирована в мобильное приложение сотрудника и используется в процессах пополнения и сборки заказов. Например, среди визуально похожих друг на друга товаров сотрудник может нажать в приложении кнопку — и нужный ценник начнет мигать, показывая, где лежит необходимый артикул. Эта функция экономит время, которое раньше уходило на поиск нужной позиции среди множества похожих товаров. Мы не рассматриваем электронные ценники просто как замену бумаги на цифровое решение. Это скорее инфраструктурный базис, который можно интегрировать в разные процессы магазина — от ценообразования до логистики — и получать кумулятивный эффект. В планах — тестирование новых форматов, включая более крупные цифровые дисплеи (13 дюймов), которые смогут показывать дополнительный контент для покупателя. Что доработали внутри компании Платформа вендора стала базовым транспортным и инфраструктурным решением, однако прикладной слой и пользовательские сценарии команда разработала самостоятельно. Привязку и отвязку ценников встроили в корпоративное мобильное приложение сотрудника: операция выполняется в один шаг — сканированием штрихкода камерой смартфона. В приложении также появились пакетная привязка, принудительное обновление экрана и проверка соответствия цены данным репозитория цен. Для семи размеров ESL создана библиотека шаблонов в дневном и ночном режимах. Помимо ценовых атрибутов, в них передаются баллы лояльности, признак «лучшая цена» и навигационные элементы. Для плотной выкладки разработаны шаблоны с номером места и стрелками, а для кухонь, ванных комнат и других проектных зон — крупноформатный ценник А4 с составом экспозиции, перечнем артикулов и суммарной стоимостью решения. Отдельный программный сервис управляет светодиодами ценников для световой навигации при сборке заказов и пополнении полок. Одним из главных технических вызовов пилота стала пропускная способность радиоканала при массовом переключении режимов «день» и «ночь». В каждом гипермаркете работает около 60 тыс. ценников, поэтому одновременная смена экранов в коротком временном окне создавала большие очереди обновлений. Команда совместно с интегратором и вендором оптимизировала процесс на нескольких уровнях, включая доработку прошивки устройств. Как контролируется работа ценников Мониторинг построен на логах и телеметрии сервера управления ESL. Система непрерывно получает данные о состоянии точек доступа, сессиях связи, уровне радиосигнала и остаточном заряде батарей. Автоматические правила алертинга (оповещения) контролируют как сетевую инфраструктуру, так и состояние отдельных устройств: фиксируют потерю связи с точкой доступа, пропуск ценником регламентных интервалов выхода на связь и разряд элемента питания. На основании событий формируются задачи на обслуживание, плановую замену батарей или самого ценника. Если сеть временно недоступна, E-ink-экран продолжает автономно показывать последнее отрисованное изображение — пустого экрана в торговом зале не возникает. Такой контроль позволяет быстро устранять аппаратные и сетевые сбои. Первые результаты пилота Изначально пилот планировался только в одном московском магазине. Но для того, чтобы результаты были показательны как коммерчески, так и технологически, требовалась контрольная группа — так в проект добавили магазин в Твери. Дополнительным фактором стала близость обеих точек к проектной команде — это позволяло оперативно сопровождать пилот и вносить коррективы на старте проекта. Главный эффект проекта не в экономии средств, а в высвобождении времени сотрудников на более важные задачи. Это время они перераспределяют на работу с покупателями и, соответственно, на повышение продаж. По нашей оценке, в масштабе сети речь идет примерно о 2 тыс. человеко-часов в месяц. В среднем за время пилота товарооборот в пилотных магазинах вырос на 1,3% — вдвое больше планового показателя. А суммарное высвобождение рабочего времени превысило план почти в 2 раза и составило 16 тыс. часов (+7%) против плановых 9 тыс. часов (+2%). Рост товарооборота связан с тремя факторами: 	 автоматической синхронизацией цены во всех каналах: после применения новой цены в системе она передается на электронный ценник без ручной переклейки; 	 эффектом «полной полки» — высвобожденное утреннее время до открытия торгового зала сотрудники теперь направляют на пополнение и выкладку товара, а не на замену ценников; 	 сокращением расхождений цены на кассе. Также мы измерили уровень удовлетворенности покупателей по параметрам доступности и доброжелательности сотрудников: за первые два месяца пилота показатель вырос на 0,22 п. п. (по 5-балльной шкале). Экономия на печати и расходных материалах в среднем составила около 200 тыс. рублей в месяц на один магазин. В масштабах всей сети это ощутимая экономия — более 270 млн. в год, хотя изначально она не являлась целью проекта. Важен и экологический эффект от внедрения «умных» ценников. Отказ от печати бумажных ценников позволяет сэкономить порядка 60 кг бумаги в месяц на один магазин, или порядка 720 кг в год. В масштабах всей сети это около 80 тонн в год. Что дальше До конца 2026 года на электронные ценники перейдут более 50 магазинов, в том числе в Москве, Санкт-Петербурге, Краснодаре, Новосибирске, Казани, Самаре, Екатеринбурге, Ростове-на-Дону, Нижнем Новгороде, Красноярске и Иркутске. За 2 года планируется оснастить электронными ценниками всю сеть. В каждом магазине в среднем будет установлено около 60 тыс. электронных ценников семи форматов, адаптированных под различные типы товаров и особенности выкладки. Производство оборудования для масштабирования проекта было запущено в марте 2026 года. Первым кластером, где технология была запущена во всех магазинах, стал Новосибирск. На электронные ценники перешли четыре гипермаркета в городе, в которых заменили около 200 тыс. бумажных ценников. Одновременно еще более 50 магазинов готовятся к монтажу. Структурированная кабельная система (СКС) уже смонтирована более чем в 35 магазинах. При этом для каждого магазина после завершения монтажных работ заложен двухнедельный период тестовой стабилизации. Сейчас мы готовимся к следующей волне запуска со стартом реализации в 2027 году. Параллельно рассматриваем тестирование новых форматов и доработку функциональности как для сотрудников, так и для покупателей. Важно уточнить, что с точки зрения покупателя переход на электронные ценники остается бесшовным. Наши внутренние исследования показали, что клиенты не замечают замену бумажного ценника на электронный. Новые возможности — вроде мгновенно отображающейся информации о повышенном кешбэке или актуальных отзывах — воспринимаются как естественное дополнение к привычному клиентскому опыту. В течение пилота мы не только замеряли эффекты, но и готовили необходимые процессы для масштабирования. Над проектом работала вовлеченная профессиональная команда энтузиастов. Отдельно хочу отметить важность совместной работы команды и надежность партнеров, которые должны стать единым организмом для реализации таких трансформаций. #IMAGE_235481#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Внедрение «умных» электронных ценников увеличило продажи и&nbsp;высвободило 24&nbsp;тыс. рабочих часов в&nbsp;год.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;«Лемана ПРО» начала масштабирование технологии «умных» электронных ценников на&nbsp;всю сеть: в&nbsp;течение двух лет они появятся во&nbsp;всех гипермаркетах. Рассмотрим, почему на&nbsp;внедрение технологии ушел почти год подготовки, зачем потребовалось менять бумажные ценники на&nbsp;электронные, как устроена архитектура решения, какими функциями обладают новые ценники и&nbsp;какие результаты уже показал пилотный запуск.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему потребовалось менять бумажные ценники&lltt;/h3&ggtt;
&lltt;p&ggtt;Идея перейти на&nbsp;электронные ценники обсуждалась в&nbsp;компании, еще когда эта технология только начинала набирать популярность. Но&nbsp;долгое время высокая стоимость самой технологии в&nbsp;России делала внедрение невыгодным. Ситуация изменилась, когда электронные ценники стали более доступными, а&nbsp;дефицит кадров на&nbsp;рынке труда и&nbsp;рост стоимости рабочего времени сделали такие вложения экономически оправданными.&lltt;/p&ggtt;
&lltt;p&ggtt;«Лемана ПРО» стала первым российским ритейлером в&nbsp;сегменте товаров для строительства, ремонта и&nbsp;обустройства, внедрившим «умные» электронные ценники в&nbsp;процессы логистики. Электронный ценник становится частью цифровой инфраструктуры магазина, которая делает покупки более удобными, предсказуемыми и&nbsp;прозрачными. Если раньше офлайн-магазины конкурировали в&nbsp;цене друг с&nbsp;другом, то&nbsp;сегодня они конкурируют с&nbsp;маркетплейсами, где покупатель привык видеть актуальную цену, отзывы, характеристики товара и&nbsp;получать всю информацию буквально за&nbsp;несколько минут. Поэтому сегодня задача ритейлера&nbsp;— обеспечить единый уровень удобства и&nbsp;клиентского опыта в&nbsp;любом канале, в&nbsp;том числе непосредственно у&nbsp;полки в&nbsp;магазине.&lltt;/p&ggtt;
&lltt;p&ggtt;Мало кто задумывается, сколько времени уходит на&nbsp;замену бумажных ценников. Каждое утро сотрудники печатают, сортируют и&nbsp;вручную меняют сотни карточек с&nbsp;ценами&nbsp;— на&nbsp;это уходит ежедневно по&nbsp;&lltt;nobr&ggtt;2-3 часа,&lltt;/nobr&ggtt; которые можно направить на&nbsp;обслуживание покупателей. Это одна из&nbsp;самых трудоемких операций в&nbsp;розничной торговле, которая практически незаметна клиенту, но&nbsp;напрямую влияет на&nbsp;его покупательский опыт.&lltt;/p&ggtt;
&lltt;h3&ggtt;Год подготовки: выбор технологии и&nbsp;партнеров&lltt;/h3&ggtt;
&lltt;p&ggtt;Прежде чем принять решение о&nbsp;внедрении, мы&nbsp;провели масштабный анализ рынка производителей и&nbsp;интеграторов. Российский рынок электронных ценников сегодня только формируется, а&nbsp;мировой рынок производителей и&nbsp;компаний-интеграторов сравнительно узкий.&lltt;/p&ggtt;
&lltt;p&ggtt;Почти год команда R&D и&nbsp;автоматизации «Лемана ПРО» работала над выбором технологии, совершала визиты в&nbsp;Китай к&nbsp;производителям и&nbsp;на&nbsp;профильные выставки, чтобы сформировать требования к&nbsp;продукту. Параллельно мы&nbsp;консультировались с&nbsp;российскими ритейлерами, у&nbsp;которых уже был опыт внедрения подобных решений: у&nbsp;одних технология прижилась и&nbsp;продолжает развиваться, у&nbsp;других опыт оказался неудачным. Изучение обеих сторон помогло сформировать собственный путь внедрения и&nbsp;заранее обойти уже известные подводные камни.&lltt;/p&ggtt;
&lltt;p&ggtt;Итоговая модель работы&nbsp;— трехстороннее партнерство: китайский производитель оборудования и&nbsp;программного обеспечения, российский интегратор, который адаптирует решение под ИТ-ландшафт конкретного заказчика и&nbsp;обеспечивает обучение и&nbsp;поддержку, и&nbsp;сама компания. На&nbsp;старте проекта мы&nbsp;регулярно проводили совместные встречи, а&nbsp;на&nbsp;этапе внедрения в&nbsp;магазинах присутствовали разработчики китайского партнера, которые могли оперативно вносить корректировки в&nbsp;работу системы.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом мы&nbsp;сознательно отказались от&nbsp;идеи писать программное обеспечение с&nbsp;нуля: кастомизации подвергаются только те&nbsp;элементы, которые создают конкурентное преимущество для компании, а&nbsp;не&nbsp;уже отлаженные вендором процессы. Один из&nbsp;таких принципиальных выборов&nbsp;— архитектура решения: мы&nbsp;выбрали облачную модель хранения и&nbsp;обмена данными, тогда как часть игроков рынка предпочитает локальные серверы в&nbsp;каждом магазине, ориентируясь на&nbsp;собственную ИТ-стратегию.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как устроена техническая архитектура&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;доставке цены от&nbsp;корпоративных систем до&nbsp;полки участвуют пять ключевых контуров: продукты ценообразования, слой агрегации и&nbsp;кеширования, планировщик обновлений, облачный сервер управления ESL (Electronic Shelf Labels, электронные ценники) и&nbsp;радиосеть магазина.&lltt;/p&ggtt;
&lltt;p&ggtt;Цены на&nbsp;товары устанавливаются в&nbsp;соответствии со&nbsp;стратегией компании «Низкие цены каждый день». Мы&nbsp;регулярно анализируем открытые данные о&nbsp;стоимости товаров на&nbsp;рынке и&nbsp;в&nbsp;соответствии с&nbsp;этим снижаем цены в&nbsp;магазинах, чтобы гарантировать покупателям наиболее выгодные условия. Роль Price Hub выполняет собственный репозиторий цен (Price Repository)&nbsp;— целевая мастер-система хранения, проверки и&nbsp;применения розничных цен. Это единый источник данных для десятков внутренних систем: касс, электронных ценников, онлайн-каналов и&nbsp;систем бизнес-аналитики. Репозиторий хранит полную историю изменений и&nbsp;несколько миллионов активных цен, поддерживает более 600 запросов на&nbsp;чтение и&nbsp;более 350 операций записи в&nbsp;секунду; 95% запросов на&nbsp;чтение обрабатываются не&nbsp;дольше 200&nbsp;миллисекунд, а&nbsp;доступность обработки поступающих запросов составляет 99,9%.&lltt;/p&ggtt;
&lltt;p&ggtt;Сервис агрегации данных объединяет все параметры товара: цену за&nbsp;штуку или единицу измерения товара, уникальный код, дату применения, доступный остаток, клиентский рейтинг, баллы лояльности и&nbsp;другие атрибуты. Профиль сохраняется в&nbsp;специализированном кеше, чтобы минимизировать задержку при подготовке пакетов обновлений для ценников.&lltt;/p&ggtt;
&lltt;p&ggtt;«Умный» планировщик формирует график обновлений с&nbsp;учетом даты вступления цены в&nbsp;силу, состава данных, часового пояса магазина и&nbsp;смен сотрудников. Он&nbsp;распределяет пиковую нагрузку на&nbsp;инфраструктуру, помогает экономить заряд батарей и&nbsp;инициирует применение цены точно к&nbsp;назначенному времени.&lltt;/p&ggtt;
&lltt;p&ggtt;ПО&nbsp;вендора для управления электронными ценниками развернуто в&nbsp;защищенном приватном облаке «Лемана ПРО». Оно управляет связками «товар&nbsp;— ценник», картой радиопокрытия, жизненным циклом устройств и&nbsp;рендерингом: накладывает данные на&nbsp;дизайн-шаблон и&nbsp;формирует растровое изображение под разрешение E-ink-дисплея нужного формата. По&nbsp;защищенному сетевому протоколу изображения поступают на&nbsp;точки доступа под потолком торгового зала, а&nbsp;затем по&nbsp;энергоэффективному радиопротоколу&nbsp;— на&nbsp;конкретные ценники.&lltt;/p&ggtt;
&lltt;p&ggtt;Облачная модель позволила отказаться от&nbsp;дополнительных серверов в&nbsp;гипермаркетах. Обновления ПО&nbsp;централизованно распространяются по&nbsp;всей сети через единый конвейер данных, а&nbsp;микросервисы, базы данных, очереди сообщений и&nbsp;API контролируются в&nbsp;едином контуре мониторинга. Ресурсы можно гибко наращивать по&nbsp;мере подключения магазинов и&nbsp;при массовой плановой передаче обновлений на&nbsp;ценники, а&nbsp;резервирование обеспечивается на&nbsp;уровне облачного кластера.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что умеют новые ценники&lltt;/h3&ggtt;
&lltt;p&ggtt;Электронные ценники в&nbsp;«Лемана ПРО» работают в&nbsp;двух режимах: в&nbsp;режиме «день» для покупателя и&nbsp;продавца-консультанта и&nbsp;«ночь» для сотрудника пополнения и&nbsp;сборки. Режимы переключаются автоматически по&nbsp;расписанию, индивидуальному для каждого магазина, в&nbsp;момент его открытия и&nbsp;закрытия.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235483#&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;режиме «день» на&nbsp;ценнике отображается не&nbsp;только цена, но&nbsp;и&nbsp;информация о&nbsp;размере кешбэка за&nbsp;покупку данного товара, оценка товара на&nbsp;основе отзывов покупателей на&nbsp;сайте, место товара на&nbsp;полке, наименование, объем/размер товара и&nbsp;его артикул. В&nbsp;режиме «ночь» отображается информация о&nbsp;необходимости пополнения товара на&nbsp;полке и&nbsp;ее&nbsp;вместимости, а&nbsp;также увеличивается размер шрифта для необходимых атрибутов&nbsp;— например, артикула товара, чтобы сотруднику магазина было проще и&nbsp;быстрее его найти. На&nbsp;сегодняшний день мы&nbsp;— единственный ритейлер на&nbsp;российском рынке, который работает в&nbsp;мультиформатном режиме с&nbsp;электронными ценниками, совмещая оба сценария использования.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельная функция электронных ценников&nbsp;— это «мигание»: она уже интегрирована в&nbsp;мобильное приложение сотрудника и&nbsp;используется в&nbsp;процессах пополнения и&nbsp;сборки заказов. Например, среди визуально похожих друг на&nbsp;друга товаров сотрудник может нажать в&nbsp;приложении кнопку&nbsp;— и&nbsp;нужный ценник начнет мигать, показывая, где лежит необходимый артикул. Эта функция экономит время, которое раньше уходило на&nbsp;поиск нужной позиции среди множества похожих товаров.&lltt;/p&ggtt;
&lltt;p&ggtt;Мы&nbsp;не&nbsp;рассматриваем электронные ценники просто как замену бумаги на&nbsp;цифровое решение. Это скорее инфраструктурный базис, который можно интегрировать в&nbsp;разные процессы магазина&nbsp;— от&nbsp;ценообразования до&nbsp;логистики&nbsp;— и&nbsp;получать кумулятивный эффект. В&nbsp;планах&nbsp;— тестирование новых форматов, включая более крупные цифровые дисплеи (13&nbsp;дюймов), которые смогут показывать дополнительный контент для покупателя.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что доработали внутри компании&lltt;/h3&ggtt;
&lltt;p&ggtt;Платформа вендора стала базовым транспортным и&nbsp;инфраструктурным решением, однако прикладной слой и&nbsp;пользовательские сценарии команда разработала самостоятельно. Привязку и&nbsp;отвязку ценников встроили в&nbsp;корпоративное мобильное приложение сотрудника: операция выполняется в&nbsp;один шаг&nbsp;— сканированием штрихкода камерой смартфона. В&nbsp;приложении также появились пакетная привязка, принудительное обновление экрана и&nbsp;проверка соответствия цены данным репозитория цен.&lltt;/p&ggtt;
&lltt;p&ggtt;Для семи размеров ESL создана библиотека шаблонов в&nbsp;дневном и&nbsp;ночном режимах. Помимо ценовых атрибутов, в&nbsp;них передаются баллы лояльности, признак «лучшая цена» и&nbsp;навигационные элементы. Для плотной выкладки разработаны шаблоны с&nbsp;номером места и&nbsp;стрелками, а&nbsp;для кухонь, ванных комнат и&nbsp;других проектных зон&nbsp;— крупноформатный ценник А4&nbsp;с составом экспозиции, перечнем артикулов и&nbsp;суммарной стоимостью решения. Отдельный программный сервис управляет светодиодами ценников для световой навигации при сборке заказов и&nbsp;пополнении полок.&lltt;/p&ggtt;
&lltt;p&ggtt;Одним из&nbsp;главных технических вызовов пилота стала пропускная способность радиоканала при массовом переключении режимов «день» и&nbsp;«ночь». В&nbsp;каждом гипермаркете работает около 60&nbsp;тыс. ценников, поэтому одновременная смена экранов в&nbsp;коротком временном окне создавала большие очереди обновлений. Команда совместно с&nbsp;интегратором и&nbsp;вендором оптимизировала процесс на&nbsp;нескольких уровнях, включая доработку прошивки устройств.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как контролируется работа ценников&lltt;/h3&ggtt;
&lltt;p&ggtt;Мониторинг построен на&nbsp;логах и&nbsp;телеметрии сервера управления ESL. Система непрерывно получает данные о&nbsp;состоянии точек доступа, сессиях связи, уровне радиосигнала и&nbsp;остаточном заряде батарей. Автоматические правила алертинга (оповещения) контролируют как сетевую инфраструктуру, так и&nbsp;состояние отдельных устройств: фиксируют потерю связи с&nbsp;точкой доступа, пропуск ценником регламентных интервалов выхода на&nbsp;связь и&nbsp;разряд элемента питания.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;основании событий формируются задачи на&nbsp;обслуживание, плановую замену батарей или самого ценника. Если сеть временно недоступна, E-ink-экран продолжает автономно показывать последнее отрисованное изображение&nbsp;— пустого экрана в&nbsp;торговом зале не&nbsp;возникает. Такой контроль позволяет быстро устранять аппаратные и&nbsp;сетевые сбои.&lltt;/p&ggtt;
&lltt;h3&ggtt;Первые результаты пилота&lltt;/h3&ggtt;
&lltt;p&ggtt;Изначально пилот планировался только в&nbsp;одном московском магазине. Но&nbsp;для того, чтобы результаты были показательны как коммерчески, так и&nbsp;технологически, требовалась контрольная группа&nbsp;— так в&nbsp;проект добавили магазин в&nbsp;Твери. Дополнительным фактором стала близость обеих точек к&nbsp;проектной команде&nbsp;— это позволяло оперативно сопровождать пилот и&nbsp;вносить коррективы на&nbsp;старте проекта.&lltt;/p&ggtt;
&lltt;p&ggtt;Главный эффект проекта не&nbsp;в&nbsp;экономии средств, а&nbsp;в&nbsp;высвобождении времени сотрудников на&nbsp;более важные задачи. Это время они перераспределяют на&nbsp;работу с&nbsp;покупателями&nbsp;и, соответственно, на&nbsp;повышение продаж. По&nbsp;нашей оценке, в&nbsp;масштабе сети речь идет примерно о&nbsp;2&nbsp;тыс. человеко-часов в&nbsp;месяц.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;среднем за&nbsp;время пилота товарооборот в&nbsp;пилотных магазинах вырос на&nbsp;1,3%&nbsp;— вдвое больше планового показателя. А&nbsp;суммарное высвобождение рабочего времени превысило план почти в&nbsp;2&nbsp;раза и&nbsp;составило 16&nbsp;тыс. часов (+7%) против плановых 9&nbsp;тыс. часов (+2%).&lltt;/p&ggtt;
&lltt;p&ggtt;Рост товарооборота связан с&nbsp;тремя факторами:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; автоматической синхронизацией цены во&nbsp;всех каналах: после применения новой цены в&nbsp;системе она передается на&nbsp;электронный ценник без ручной переклейки;&lltt;/li&ggtt;
	&lltt;li&ggtt; эффектом «полной полки»&nbsp;— высвобожденное утреннее время до&nbsp;открытия торгового зала сотрудники теперь направляют на&nbsp;пополнение и&nbsp;выкладку товара, а&nbsp;не&nbsp;на&nbsp;замену ценников;&lltt;/li&ggtt;
	&lltt;li&ggtt; сокращением расхождений цены на&nbsp;кассе.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Также мы&nbsp;измерили уровень удовлетворенности покупателей по&nbsp;параметрам доступности и&nbsp;доброжелательности сотрудников: за&nbsp;первые два месяца пилота показатель вырос на&nbsp;0,22&nbsp;п.&nbsp;п. (по&nbsp;&lltt;nobr&ggtt;5-балльной&lltt;/nobr&ggtt; шкале).&lltt;/p&ggtt;
&lltt;p&ggtt;Экономия на&nbsp;печати и&nbsp;расходных материалах в&nbsp;среднем составила около 200&nbsp;тыс. рублей в&nbsp;месяц на&nbsp;один магазин. В&nbsp;масштабах всей сети это ощутимая экономия&nbsp;— более 270&nbsp;млн.&nbsp;в&nbsp;год, хотя изначально она не&nbsp;являлась целью проекта.&lltt;/p&ggtt;
&lltt;p&ggtt;Важен и&nbsp;экологический эффект от&nbsp;внедрения «умных» ценников. Отказ от&nbsp;печати бумажных ценников позволяет сэкономить порядка 60&nbsp;кг бумаги в&nbsp;месяц на&nbsp;один магазин, или порядка 720&nbsp;кг в&nbsp;год. В&nbsp;масштабах всей сети это около 80&nbsp;тонн в&nbsp;год.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что дальше&lltt;/h3&ggtt;
&lltt;p&ggtt;До&nbsp;конца 2026 года на&nbsp;электронные ценники перейдут более 50&nbsp;магазинов, в&nbsp;том числе в&nbsp;Москве, Санкт-Петербурге, Краснодаре, Новосибирске, Казани, Самаре, Екатеринбурге, Ростове-на-Дону, Нижнем Новгороде, Красноярске и&nbsp;Иркутске. За&nbsp;2&nbsp;года планируется оснастить электронными ценниками всю сеть. В&nbsp;каждом магазине в&nbsp;среднем будет установлено около 60&nbsp;тыс. электронных ценников семи форматов, адаптированных под различные типы товаров и&nbsp;особенности выкладки.&lltt;/p&ggtt;
&lltt;p&ggtt;Производство оборудования для масштабирования проекта было запущено в&nbsp;марте 2026&nbsp;года. Первым кластером, где технология была запущена во&nbsp;всех магазинах, стал Новосибирск. На&nbsp;электронные ценники перешли четыре гипермаркета в&nbsp;городе, в&nbsp;которых заменили около 200&nbsp;тыс. бумажных ценников. Одновременно еще более 50&nbsp;магазинов готовятся к&nbsp;монтажу. Структурированная кабельная система (СКС) уже смонтирована более чем в&nbsp;35&nbsp;магазинах. При этом для каждого магазина после завершения монтажных работ заложен двухнедельный период тестовой стабилизации.&lltt;/p&ggtt;
&lltt;p&ggtt;Сейчас мы&nbsp;готовимся к&nbsp;следующей волне запуска со&nbsp;стартом реализации в&nbsp;2027&nbsp;году. Параллельно рассматриваем тестирование новых форматов и&nbsp;доработку функциональности как для сотрудников, так и&nbsp;для покупателей. Важно уточнить, что с&nbsp;точки зрения покупателя переход на&nbsp;электронные ценники остается бесшовным. Наши внутренние исследования показали, что клиенты не&nbsp;замечают замену бумажного ценника на&nbsp;электронный. Новые возможности&nbsp;— вроде мгновенно отображающейся информации о&nbsp;повышенном кешбэке или актуальных отзывах&nbsp;— воспринимаются как естественное дополнение к&nbsp;привычному клиентскому опыту.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;течение пилота мы&nbsp;не&nbsp;только замеряли эффекты, но&nbsp;и&nbsp;готовили необходимые процессы для масштабирования. Над проектом работала вовлеченная профессиональная команда энтузиастов. Отдельно хочу отметить важность совместной работы команды и&nbsp;надежность партнеров, которые должны стать единым организмом для реализации таких трансформаций.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235481#&lltt;/p&ggtt;]]></source>
<adate>08.09.2026</adate>
<dbid>235480</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/54f/z7spl6vq13pgv57svtws2h4h5z9wsmp9.jpg;;https://www.itweek.ru/upload/iblock/0c6/ha9n7qw66hl8m8kb3ayfq62uveo3r3f3.jpg;;https://www.itweek.ru/upload/iblock/101/h16lb5qzozqugut4zgmft8t1st0ctbih.jpg]]>
</images>
<imagesname><![CDATA[;;Дмитрий Коченко, директор продукта компании &#8220;Лемана ПРО&#8221;   ;; ;;Дневной и ночной ценники   ]]></imagesname>
<tag><![CDATA[Идеи и практики автоматизации;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Наталья Коливошко: создание инфраструктуры цифрового рубля]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235411]]></link>
<description><![CDATA[В меняющемся ландшафте мировой финансовой системы, где центральные банки все активнее изучают цифровые валюты, работа инженеров чаще всего остается за кадром. Но именно этот слой технической экспертизы определяет, смогут ли амбициозные денежные инициативы надежно работать в масштабах реальной экономики. Наталья Коливошко, эксперт разработки в системно значимом российском банке, играла ключевую техническую роль в формировании банковского интеграционного контура, необходимого для подключения к российской платформе цифрового рубля. #IMAGE_235412# Ее профессиональный путь отражает последовательное продвижение через сложные инженерные роли в одном из крупнейших финансовых институтов страны. Со временем Коливошко перешла от непосредственного инженерного исполнения к более широким архитектурным и межкомандным задачам, участвуя в определении стандартов системного проектирования, релизных процессов, наблюдаемости и надежности для крупномасштабных банковских систем. В системно значимом финансовом институте, обслуживающем миллионы розничных и корпоративных клиентов, инженерные решения редко бывают изолированными. Системы должны работать под высокой нагрузкой, интегрироваться с внешними платформами и соответствовать регуляторным требованиям, которые меняются вместе с национальными финансовыми стратегиями. Именно в таком контексте работа Натальи Коливошко пересеклась с одной из самых амбициозных инициатив российской финансовой системы — цифровым рублем. Проект цифрового рубля представляет собой новую форму суверенной валюты, выпускаемой центральным банком и предназначенной для сосуществования с наличными деньгами и традиционными безналичными средствами. В отличие от децентрализованных криптовалют, он полностью регулируется и интегрируется в национальную финансовую систему. Для коммерческих банков участие в проекте требовало создания защищённой и масштабируемой интеграционной инфраструктуры для взаимодействия с платформой Банка России при одновременном обеспечении бесшовного доступа для конечных пользователей. Коливошко присоединилась к проекту на этапе подготовки банковской инфраструктуры к пилотным операциям с реальными цифровыми рублями и последующему переходу к промышленной эксплуатации. Ее роль выходила за рамки реализации. Она работала над переводом регуляторных требований на язык технической архитектуры, определяла, как должны взаимодействовать различные компоненты, и обеспечивала способность системы надежно функционировать в реальных условиях. Ключевой частью работы Коливошко стало определение референсной архитектуры интеграции банка с платформой цифрового рубля. Это включало установление границ предметных областей, проектирование контрактных интерфейсов и распределение ответственности между слоями системы: от интеграционных адаптеров и оркестрации процессов до доменной логики, аудита и управления состоянием. Она участвовала в создании инженерных стандартов, которые определяли, как сервисы взаимодействуют друг с другом, как обрабатываются ошибки и как поведение системы можно наблюдать в реальном времени. Эти стандарты не были абстрактными рекомендациями: они становились операционными требованиями, применявшимися разными командами и формировавшими поведение системы в промышленной среде. Еще одно измерение ее работы было связано с отказоустойчивостью. Финансовая инфраструктура должна сохранять стабильность даже тогда, когда отдельные компоненты дают сбой. Коливошко внедряла такие механизмы, как логика повторных попыток, изоляция отказов и сквозная трассируемость, что позволяло инженерам понимать поведение системы во время нарушений и восстанавливать нормальную работу с минимальным воздействием на пользователей и процессы. Безопасность стала неотъемлемой частью архитектуры проекта. Интеграция с платформой цифрового рубля требовала соблюдения строгих криптографических и регуляторных требований. Наталья Коливошко координировала их техническую проработку и встраивание в системную архитектуру совместно с подразделениями информационной безопасности и инфраструктуры. Работа охватывала защищённые каналы связи, сертификатную аутентификацию, управление доступом и обеспечение аудируемости транзакционных операций. Благодаря такому подходу требования безопасности учитывались уже на этапе проектирования, а не добавлялись как отдельный контрольный слой после завершения разработки. Во время пилотного этапа, когда начались операции с реальными цифровыми рублями, фокус сместился к мониторингу и операционной стабильности. Коливошко помогла спроектировать механизмы наблюдаемости: структурированные журналы, метрики и распределенную трассировку, которые позволяли командам подробно анализировать поведение системы. Такой уровень видимости был необходим для выявления проблем, понимания их причин и постепенного повышения производительности системы. Она также инициировала подход к анализу телеметрии, ориентированный на AIOps: стандартизировала журналы, метрики и трассы, чтобы обеспечить системное выявление аномалий и кластеризацию инцидентов по всей системе. На практике это перевело диагностику от ручного анализа журналов к структурированному процессу, сократив время первичного разбора типовых инцидентов с нескольких часов до нескольких минут. Более широкое значение проекта заключается в его роли внутри национальной финансовой инфраструктуры. Цифровой рубль — не самостоятельный продукт, а часть масштабной трансформации того, как деньги могут выпускаться, переводиться и контролироваться. Для банков-участников раннее вовлечение требовало как технической готовности, так и способности адаптироваться к меняющимся регуляторным нормам. Вклад Натальи Коливошко можно понимать именно через эту призму: не как отдельную функцию или компонент, а как часть скоординированной работы по созданию надежной интеграции между коммерческими банковскими системами и платформой центрального банка. Ее роль охватывала архитектуру, эксплуатацию и межфункциональную координацию, отражая многогранный характер современной финансовой инженерии. За пределами проекта цифрового рубля ее опыт также включает внутренние системы, созданные для повышения операционной эффективности внутри банка. Эти проекты, хотя и менее заметны внешней аудитории, формируют основу крупных финансовых организаций, позволяя сотрудникам управлять показателями и бизнес-процессами в режиме реального времени. В совокупности работа Натальи Коливошко показывает, как инженерные роли развиваются вместе с системами, которые они поддерживают. По мере того как финансовая инфраструктура становится все более взаимосвязанной и технологически сложной, способность проектировать, интегрировать и эксплуатировать такие системы приобретает все большее значение. В случае цифрового рубля эта работа вносит вклад в более широкий сдвиг финансовых систем к модели, в которой цифровые платформы, регуляторные рамки и инженерные практики сходятся в одной точке. И внутри этой конвергенции такие инженеры, как Наталья Коливошко, играют определяющую роль, превращая концептуальные модели в работающую инфраструктуру]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;В меняющемся ландшафте мировой финансовой системы, где центральные банки все активнее изучают цифровые валюты, работа инженеров чаще всего остается за кадром. Но именно этот слой технической экспертизы определяет, смогут ли амбициозные денежные инициативы надежно работать в масштабах реальной экономики. &lltt;strong&ggtt;Наталья Коливошко&lltt;/strong&ggtt;, эксперт разработки в системно значимом российском банке, играла ключевую техническую роль в формировании банковского интеграционного контура, необходимого для подключения к российской платформе цифрового рубля.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235412#&lltt;/p&ggtt;
&lltt;p&ggtt;Ее профессиональный путь отражает последовательное продвижение через сложные инженерные роли в одном из крупнейших финансовых институтов страны. Со временем Коливошко перешла от непосредственного инженерного исполнения к более широким архитектурным и межкомандным задачам, участвуя в определении стандартов системного проектирования, релизных процессов, наблюдаемости и надежности для крупномасштабных банковских систем.&lltt;/p&ggtt;
&lltt;p&ggtt;В системно значимом финансовом институте, обслуживающем миллионы розничных и корпоративных клиентов, инженерные решения редко бывают изолированными. Системы должны работать под высокой нагрузкой, интегрироваться с внешними платформами и соответствовать регуляторным требованиям, которые меняются вместе с национальными финансовыми стратегиями. Именно в таком контексте работа Натальи Коливошко пересеклась с одной из самых амбициозных инициатив российской финансовой системы — цифровым рублем.&lltt;/p&ggtt;
&lltt;p&ggtt;Проект цифрового рубля представляет собой новую форму суверенной валюты, выпускаемой центральным банком и предназначенной для сосуществования с наличными деньгами и традиционными безналичными средствами. В отличие от децентрализованных криптовалют, он полностью регулируется и интегрируется в национальную финансовую систему. Для коммерческих банков участие в проекте требовало создания защищённой и масштабируемой интеграционной инфраструктуры для взаимодействия с платформой Банка России при одновременном обеспечении бесшовного доступа для конечных пользователей.&lltt;/p&ggtt;
&lltt;p&ggtt;Коливошко присоединилась к проекту на этапе подготовки банковской инфраструктуры к пилотным операциям с реальными цифровыми рублями и последующему переходу к промышленной эксплуатации. Ее роль выходила за рамки реализации. Она работала над переводом регуляторных требований на язык технической архитектуры, определяла, как должны взаимодействовать различные компоненты, и обеспечивала способность системы надежно функционировать в реальных условиях.&lltt;/p&ggtt;
&lltt;p&ggtt;Ключевой частью работы Коливошко стало определение референсной архитектуры интеграции банка с платформой цифрового рубля. Это включало установление границ предметных областей, проектирование контрактных интерфейсов и распределение ответственности между слоями системы: от интеграционных адаптеров и оркестрации процессов до доменной логики, аудита и управления состоянием.&lltt;/p&ggtt;
&lltt;p&ggtt;Она участвовала в создании инженерных стандартов, которые определяли, как сервисы взаимодействуют друг с другом, как обрабатываются ошибки и как поведение системы можно наблюдать в реальном времени. Эти стандарты не были абстрактными рекомендациями: они становились операционными требованиями, применявшимися разными командами и формировавшими поведение системы в промышленной среде.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще одно измерение ее работы было связано с отказоустойчивостью. Финансовая инфраструктура должна сохранять стабильность даже тогда, когда отдельные компоненты дают сбой. Коливошко внедряла такие механизмы, как логика повторных попыток, изоляция отказов и сквозная трассируемость, что позволяло инженерам понимать поведение системы во время нарушений и восстанавливать нормальную работу с минимальным воздействием на пользователей и процессы.&lltt;/p&ggtt;
&lltt;p&ggtt;Безопасность стала неотъемлемой частью архитектуры проекта. Интеграция с платформой цифрового рубля требовала соблюдения строгих криптографических и регуляторных требований. Наталья Коливошко координировала их техническую проработку и встраивание в системную архитектуру совместно с подразделениями информационной безопасности и инфраструктуры. Работа охватывала защищённые каналы связи, сертификатную аутентификацию, управление доступом и обеспечение аудируемости транзакционных операций. Благодаря такому подходу требования безопасности учитывались уже на этапе проектирования, а не добавлялись как отдельный контрольный слой после завершения разработки.&lltt;/p&ggtt;
&lltt;p&ggtt;Во время пилотного этапа, когда начались операции с реальными цифровыми рублями, фокус сместился к мониторингу и операционной стабильности. Коливошко помогла спроектировать механизмы наблюдаемости: структурированные журналы, метрики и распределенную трассировку, которые позволяли командам подробно анализировать поведение системы. Такой уровень видимости был необходим для выявления проблем, понимания их причин и постепенного повышения производительности системы.&lltt;/p&ggtt;
&lltt;p&ggtt;Она также инициировала подход к анализу телеметрии, ориентированный на AIOps: стандартизировала журналы, метрики и трассы, чтобы обеспечить системное выявление аномалий и кластеризацию инцидентов по всей системе. На практике это перевело диагностику от ручного анализа журналов к структурированному процессу, сократив время первичного разбора типовых инцидентов с нескольких часов до нескольких минут.&lltt;/p&ggtt;
&lltt;p&ggtt;Более широкое значение проекта заключается в его роли внутри национальной финансовой инфраструктуры. Цифровой рубль — не самостоятельный продукт, а часть масштабной трансформации того, как деньги могут выпускаться, переводиться и контролироваться. Для банков-участников раннее вовлечение требовало как технической готовности, так и способности адаптироваться к меняющимся регуляторным нормам.&lltt;/p&ggtt;
&lltt;p&ggtt;Вклад Натальи Коливошко можно понимать именно через эту призму: не как отдельную функцию или компонент, а как часть скоординированной работы по созданию надежной интеграции между коммерческими банковскими системами и платформой центрального банка. Ее роль охватывала архитектуру, эксплуатацию и межфункциональную координацию, отражая многогранный характер современной финансовой инженерии.&lltt;/p&ggtt;
&lltt;p&ggtt;За пределами проекта цифрового рубля ее опыт также включает внутренние системы, созданные для повышения операционной эффективности внутри банка. Эти проекты, хотя и менее заметны внешней аудитории, формируют основу крупных финансовых организаций, позволяя сотрудникам управлять показателями и бизнес-процессами в режиме реального времени.&lltt;/p&ggtt;
&lltt;p&ggtt;В совокупности работа Натальи Коливошко показывает, как инженерные роли развиваются вместе с системами, которые они поддерживают. По мере того как финансовая инфраструктура становится все более взаимосвязанной и технологически сложной, способность проектировать, интегрировать и эксплуатировать такие системы приобретает все большее значение.&lltt;/p&ggtt;
&lltt;p&ggtt;В случае цифрового рубля эта работа вносит вклад в более широкий сдвиг финансовых систем к модели, в которой цифровые платформы, регуляторные рамки и инженерные практики сходятся в одной точке. И внутри этой конвергенции такие инженеры, как Наталья Коливошко, играют определяющую роль, превращая концептуальные модели в работающую инфраструктуру.&lltt;/p&ggtt;]]></source>
<adate>12.03.2025</adate>
<dbid>235411</dbid>
<rubric>1</rubric>
<orubric>135315</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/c18/zu6hlxnqfvgr08h6fb389637mfqa50la.jpg]]>
</images>
<imagesname><![CDATA[;;Наталья Коливошко   ]]></imagesname>
<tag><![CDATA[Блокчейн]]></tag>
</item>
<item>
<title><![CDATA[Почему ИИ-аналитики уверенно отвечают на неправильные вопросы]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235484]]></link>
<description><![CDATA[Данные могут быть правильными. Определение может быть правильным. Но ответ искусственного интеллекта все равно может быть неверным. ИИ-аналитикам необходим контекст принятия решения до того, как поступит вопрос, пишет на портале InformationWeek Пол Вахтлер, старший вице-президент Exiger по ИИ, данным и стратегии. Если вы работаете с данными, вы, вероятно, сталкивались с примерно с таким вопросом от вашего руководства: «Можем ли мы запустить LLM на наших данных и заставить ее проанализировать все за нас?». Это нормальный вопрос. Руководители хотят получать ответы быстрее, не отправляя каждый вопрос через BI-очередь. Они видят, что могут делать LLM с текстом, и предполагают, что тот же принцип должен применяться и к бизнес-данным. Проблема в том, что корпоративные данные не объясняют сами себя. Я наблюдал это во время тестирования ИИ-аналитика на реальных бизнес-вопросах. Меня интересовало, какие клиенты представляют наибольший риск в текущем квартале или какие возможности с наибольшей вероятностью будут закрыты в следующие 30 дней. Система уверенно называла клиентов или возможности. Некоторые ответы были неверными; некоторые — вымышленными; а другие имели мало отношения к вопросу. Система выдавала ответы, не понимая масштаба запроса или того, что бизнес подразумевает под «аккаунт подвержен риску» и «аккаунт вероятно будет закрыт». Она также не знала, означают ли «показатели текущего квартала» данные на сегодня или ожидаемые результаты к концу квартала. ИИ-аналитик не может понять бизнес лишь благодаря потому, что у него есть доступ к хранилищу данных. Он может написать SQL-запрос и вернуть число, которое выглядит правдоподобным. Риск заключается в том, что ему приходится где-то брать бизнес-логику, лежащую в основе ответа. Если компания не определила эту логику, модель сама заполнит пробел. Большинство компаний никогда не документировали всю эту бизнес-логику, потому что ею владели опытные аналитики. Сильная BI-команда знала, каким показателям выручки доверяют руководители. Они понимали, что дашборд хорош для определения направления, но не подходит для оперативного анализа. Они знали, что результат требует контекста, чтобы на нем можно было строить какие-либо действия. Во многих компаниях аналитик был семантическим слоем. Такая схема могла работать, когда одни и те же аналитики оставались в тесном контакте с бизнесом. Проблема возникает, когда от системы ожидается, что она будет отвечать самостоятельно. Теперь от LLM требуют использовать логику, которую организация ей никогда не давала. Проблему сложнее обнаружить, когда ответ не кажется явно ошибочным. Он может звучать разумно, но при этом быть неверным, что негативно сказывается на бизнесе. Помочь может проработанный семантический слой. Он предоставляет системе утвержденные определения и логику, связывающую их с данными. Но эти определения все равно должны применяться к соответствующей ситуации. Модель может использовать правильное определение дохода, но при этом выбрать неправильный временной период. Она может точно рассчитать показатели эффективности, но при этом неправильно понять, что пытается выяснить руководитель. Данные могут быть правильными. Определение может быть правильным. Ответ все равно может быть неверным. За пределами семантического слоя Семантический слой может определить, какой аккаунт следует считать подверженным риску или что делает вероятным его закрытие. Контекстный слой сообщает системе, применимы ли эти определения к задаваемому вопросу. Аккаунт может соответствовать формальным критериям риска, но эта оценка может не соответствовать временному периоду, которым пытается управлять руководитель. Определение верное; его применение неверное. Этот контекст также меняется со временем. Определение, утвержденное в начале квартала, может перестать соответствовать прогнозу после его изменения или корректировки руководством принимаемого решения. Система должна знать, какой контекст актуален, а какие предположения устарели. В противном случае она может правильно применить устаревшее предположение и выдать неверный ответ. Аналитики обычно учитывают все эти аспекты в рамках своей работы. Они знают, когда определение технически верно, но все же неверно для рассматриваемого решения. ИИ-аналитик должен понимать эти аспекты до того, как поступит вопрос. Если человеку приходится каждый раз переформулировать его, система теряет значительную часть той скорости, на которую была рассчитана. Агенту также необходимы операционные правила обработки неполного или противоречивого контекста. Эти правила определяют, когда агент может продолжить работу, а когда неопределенность достаточно велика, чтобы вмешался человек. Они также предотвращают незаметное превращение временных сигналов в постоянную бизнес-логику. Владельцы бизнеса не исчезают Владельцы бизнеса не могут проверять каждый ответ, не становясь узким местом. Им необходимо проверять результаты тестирования и оценки ответов на множества вопросов и понимать, когда контекст, лежащий в основе этих ответов, изменился. Бизнес поддерживает этот контекст, связывая каждое определение с решением и периодом, для которого оно было разработано. При изменении любого из этих параметров затронутый контекст помечается для проверки бизнесом. Этот анализ также должен охватывать сам процесс оценки. Если результат изменился, система может повысить свою оценку, улучшив выполнение неправильной задачи. Хотя система может собирать новую информацию и предлагать изменения, существенные изменения в контексте по-прежнему требуют одобрения бизнеса. Эта ответственность лежит на владельце бизнеса. Инженеры могут правильно построить систему, и система может работать точно так, как задумано, даже если лежащие в её основе предположения неверны. Раньше большую часть этой ответственности несли аналитики, опираясь на свой опыт. С ИИ-аналитиком ситуация меняется: бизнес должен брать на себя ответственность за логику, лежащую в основе ответа, и решать, когда эту логику необходимо изменить]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Данные могут быть правильными. Определение может быть правильным. Но ответ искусственного интеллекта все равно может быть неверным. ИИ-аналитикам необходим контекст принятия решения до того, как поступит вопрос, пишет на портале &lltt;/em&ggtt;&lltt;em&ggtt;InformationWeek&lltt;/em&ggtt; &lltt;em&ggtt;Пол Вахтлер, старший вице-президент Exiger по ИИ, данным и стратегии.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Если вы работаете с данными, вы, вероятно, сталкивались с примерно с таким вопросом от вашего руководства: «Можем ли мы запустить LLM на наших данных и заставить ее проанализировать все за нас?».&lltt;/p&ggtt;
&lltt;p&ggtt;Это нормальный вопрос. Руководители хотят получать ответы быстрее, не отправляя каждый вопрос через BI-очередь. Они видят, что могут делать LLM с текстом, и предполагают, что тот же принцип должен применяться и к бизнес-данным.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема в том, что корпоративные данные не объясняют сами себя.&lltt;/p&ggtt;
&lltt;p&ggtt;Я наблюдал это во время тестирования ИИ-аналитика на реальных бизнес-вопросах. Меня интересовало, какие клиенты представляют наибольший риск в текущем квартале или какие возможности с наибольшей вероятностью будут закрыты в следующие 30 дней. Система уверенно называла клиентов или возможности. Некоторые ответы были неверными; некоторые — вымышленными; а другие имели мало отношения к вопросу.&lltt;/p&ggtt;
&lltt;p&ggtt;Система выдавала ответы, не понимая масштаба запроса или того, что бизнес подразумевает под «аккаунт подвержен риску» и «аккаунт вероятно будет закрыт». Она также не знала, означают ли «показатели текущего квартала» данные на сегодня или ожидаемые результаты к концу квартала.&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ-аналитик не может понять бизнес лишь благодаря потому, что у него есть доступ к хранилищу данных. Он может написать SQL-запрос и вернуть число, которое выглядит правдоподобным. Риск заключается в том, что ему приходится где-то брать бизнес-логику, лежащую в основе ответа. Если компания не определила эту логику, модель сама заполнит пробел.&lltt;/p&ggtt;
&lltt;p&ggtt;Большинство компаний никогда не документировали всю эту бизнес-логику, потому что ею владели опытные аналитики. Сильная BI-команда знала, каким показателям выручки доверяют руководители. Они понимали, что дашборд хорош для определения направления, но не подходит для оперативного анализа. Они знали, что результат требует контекста, чтобы на нем можно было строить какие-либо действия.&lltt;/p&ggtt;
&lltt;p&ggtt;Во многих компаниях аналитик был семантическим слоем.&lltt;/p&ggtt;
&lltt;p&ggtt;Такая схема могла работать, когда одни и те же аналитики оставались в тесном контакте с бизнесом. Проблема возникает, когда от системы ожидается, что она будет отвечать самостоятельно. Теперь от LLM требуют использовать логику, которую организация ей никогда не давала.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблему сложнее обнаружить, когда ответ не кажется явно ошибочным. Он может звучать разумно, но при этом быть неверным, что негативно сказывается на бизнесе.&lltt;/p&ggtt;
&lltt;p&ggtt;Помочь может проработанный семантический слой. Он предоставляет системе утвержденные определения и логику, связывающую их с данными. Но эти определения все равно должны применяться к соответствующей ситуации. Модель может использовать правильное определение дохода, но при этом выбрать неправильный временной период. Она может точно рассчитать показатели эффективности, но при этом неправильно понять, что пытается выяснить руководитель.&lltt;/p&ggtt;
&lltt;p&ggtt;Данные могут быть правильными. Определение может быть правильным. Ответ все равно может быть неверным.&lltt;/p&ggtt;
&lltt;h3&ggtt;За пределами семантического слоя&lltt;/h3&ggtt;
&lltt;p&ggtt;Семантический слой может определить, какой аккаунт следует считать подверженным риску или что делает вероятным его закрытие. Контекстный слой сообщает системе, применимы ли эти определения к задаваемому вопросу. Аккаунт может соответствовать формальным критериям риска, но эта оценка может не соответствовать временному периоду, которым пытается управлять руководитель. Определение верное; его применение неверное.&lltt;/p&ggtt;
&lltt;p&ggtt;Этот контекст также меняется со временем. Определение, утвержденное в начале квартала, может перестать соответствовать прогнозу после его изменения или корректировки руководством принимаемого решения. Система должна знать, какой контекст актуален, а какие предположения устарели. В противном случае она может правильно применить устаревшее предположение и выдать неверный ответ.&lltt;/p&ggtt;
&lltt;p&ggtt;Аналитики обычно учитывают все эти аспекты в рамках своей работы. Они знают, когда определение технически верно, но все же неверно для рассматриваемого решения. ИИ-аналитик должен понимать эти аспекты до того, как поступит вопрос. Если человеку приходится каждый раз переформулировать его, система теряет значительную часть той скорости, на которую была рассчитана.&lltt;/p&ggtt;
&lltt;p&ggtt;Агенту также необходимы операционные правила обработки неполного или противоречивого контекста. Эти правила определяют, когда агент может продолжить работу, а когда неопределенность достаточно велика, чтобы вмешался человек. Они также предотвращают незаметное превращение временных сигналов в постоянную бизнес-логику.&lltt;/p&ggtt;
&lltt;h3&ggtt;Владельцы бизнеса не исчезают&lltt;/h3&ggtt;
&lltt;p&ggtt;Владельцы бизнеса не могут проверять каждый ответ, не становясь узким местом. Им необходимо проверять результаты тестирования и оценки ответов на множества вопросов и понимать, когда контекст, лежащий в основе этих ответов, изменился.&lltt;/p&ggtt;
&lltt;p&ggtt;Бизнес поддерживает этот контекст, связывая каждое определение с решением и периодом, для которого оно было разработано. При изменении любого из этих параметров затронутый контекст помечается для проверки бизнесом.&lltt;/p&ggtt;
&lltt;p&ggtt;Этот анализ также должен охватывать сам процесс оценки. Если результат изменился, система может повысить свою оценку, улучшив выполнение неправильной задачи. Хотя система может собирать новую информацию и предлагать изменения, существенные изменения в контексте по-прежнему требуют одобрения бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;Эта ответственность лежит на владельце бизнеса. Инженеры могут правильно построить систему, и система может работать точно так, как задумано, даже если лежащие в её основе предположения неверны.&lltt;/p&ggtt;
&lltt;p&ggtt;Раньше большую часть этой ответственности несли аналитики, опираясь на свой опыт. С ИИ-аналитиком ситуация меняется: бизнес должен брать на себя ответственность за логику, лежащую в основе ответа, и решать, когда эту логику необходимо изменить.&lltt;/p&ggtt;]]></source>
<adate>08.09.2026</adate>
<dbid>235484</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;Big Data/Аналитика]]></tag>
</item>
<item>
<title><![CDATA[Postgres Professional представила PPEM 2.9]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235476]]></link>
<description><![CDATA[Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — Postgres Pro Enterprise Manager (PPEM) 2.9. В релиз вошли усовершенствования центра оперативного контроля, улучшенные инструменты диагностики производительности, а также усиленные механизмы защиты взаимодействия между компонентами системы. Одним из ключевых нововведений стало расширение центра оперативного контроля. Теперь администраторы могут просматривать в нём не только отдельные экземпляры СУБД, но и отказоустойчивые кластеры. Это упрощает мониторинг распределённых инфраструктур: состояние кластера отображается как состояние единого объекта, а переход к анализу отдельных узлов занимает меньше времени. Существенные улучшения получил инструмент диагностики производительности Active Session Engine (ASE). Помимо общей стабилизации и доработок, в PPEM 2.9 появилась возможность управлять параметрами профилирования и выгружать данные снимков в необработанном виде для последующего анализа во внешних системах. Реализован просмотр исходных подготовленных операторов, позволяющий получить более полную картину при разборе запросов. Также добавлен бесшовный переход из истории сеансов в SQL-статистику, что упрощает диагностику проблем. Кроме того, улучшены интерфейс раздела, фильтры и визуализация графиков. В сфере безопасности ключевым изменением стала реализация взаимной TLS-аутентификации (mTLS). В дополнение к аутентификации по API-ключам менеджер и агенты теперь могут взаимно подтверждать подлинность друг друга с помощью сертификатов при установлении HTTPS-соединения. Это усиливает защиту взаимодействия между компонентами и снижает риск подключения недоверенной стороны, что особенно важно для инфраструктур с повышенными требованиями к безопасности. Платформа также получила ряд других улучшений: 	в части управления задачами и резервными копиями добавлена возможность переназначать задачи и перепривязывать хранилища для удаляемых экземпляров; 	для BiHA-кластеров реализовано управление минимальным числом исправных узлов при создании и изменении топологии; 	в обслуживании репозитория появилась возможность вручную очищать таблицы репозитория, чтобы предотвратить остановку сервера из-за нехватки дискового пространства; 	в конфигурацию добавлен параметр для задания пользовательского шаблона имени экземпляра при использовании режима автоматического обнаружения; 	исправлен ряд уязвимостей общего характера (CVE), а язык Go обновлён до версии 1.26.6. Postgres Pro Enterprise Manager входит в состав всех редакций СУБД Postgres Pro и предоставляет единый веб-интерфейс для мониторинга, администрирования и диагностики баз данных. Компания также анонсировала выход модуля Healthcheck Advisor в одном из ближайших релизов PPEM. Он будет автоматически анализировать состояние экземпляров СУБД на основе собранной телеметрии, выявлять отклонения по ключевым показателям работы баз данных, определять уровень их критичности и формировать рекомендации по дальнейшим действиям. Для каждого обнаруженного отклонения будут доступны сведения о метрике, объекте анализа, нормативном и фактическом значениях, времени срабатывания и рекомендуемых мерах по устранению проблемы. Результаты будут представлены в разделе «Проблемы и рекомендации»: в нём будет размещена сводная информация по управляемым экземплярам, распределение обнаружений по уровням критичности и перечень экземпляров с наибольшим числом выявленных проблем. PPEM Healthcheck Advisor войдёт в базовую поставку платформы и не потребует отдельной установки или лицензирования. Подробная информация об изменениях и инструкции по обновлению до PPEM 2.9 доступны в документации Postgres Pro Enterprise Manager]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания Postgres Professional объявила о выпуске новой версии платформы для управления и мониторинга баз данных — Postgres Pro Enterprise Manager (PPEM) 2.9. В релиз вошли усовершенствования центра оперативного контроля, улучшенные инструменты диагностики производительности, а также усиленные механизмы защиты взаимодействия между компонентами системы.&lltt;/p&ggtt;
&lltt;p&ggtt;Одним из ключевых нововведений стало расширение центра оперативного контроля. Теперь администраторы могут просматривать в нём не только отдельные экземпляры СУБД, но и отказоустойчивые кластеры. Это упрощает мониторинг распределённых инфраструктур: состояние кластера отображается как состояние единого объекта, а переход к анализу отдельных узлов занимает меньше времени.&lltt;/p&ggtt;
&lltt;p&ggtt;Существенные улучшения получил инструмент диагностики производительности Active Session Engine (ASE). Помимо общей стабилизации и доработок, в PPEM 2.9 появилась возможность управлять параметрами профилирования и выгружать данные снимков в необработанном виде для последующего анализа во внешних системах. Реализован просмотр исходных подготовленных операторов, позволяющий получить более полную картину при разборе запросов. Также добавлен бесшовный переход из истории сеансов в SQL-статистику, что упрощает диагностику проблем. Кроме того, улучшены интерфейс раздела, фильтры и визуализация графиков.&lltt;/p&ggtt;
&lltt;p&ggtt;В сфере безопасности ключевым изменением стала реализация взаимной TLS-аутентификации (mTLS). В дополнение к аутентификации по API-ключам менеджер и агенты теперь могут взаимно подтверждать подлинность друг друга с помощью сертификатов при установлении HTTPS-соединения. Это усиливает защиту взаимодействия между компонентами и снижает риск подключения недоверенной стороны, что особенно важно для инфраструктур с повышенными требованиями к безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;Платформа также получила ряд других улучшений:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;в части управления задачами и резервными копиями добавлена возможность переназначать задачи и перепривязывать хранилища для удаляемых экземпляров;&lltt;/li&ggtt;
	&lltt;li&ggtt;для BiHA-кластеров реализовано управление минимальным числом исправных узлов при создании и изменении топологии;&lltt;/li&ggtt;
	&lltt;li&ggtt;в обслуживании репозитория появилась возможность вручную очищать таблицы репозитория, чтобы предотвратить остановку сервера из-за нехватки дискового пространства;&lltt;/li&ggtt;
	&lltt;li&ggtt;в конфигурацию добавлен параметр для задания пользовательского шаблона имени экземпляра при использовании режима автоматического обнаружения;&lltt;/li&ggtt;
	&lltt;li&ggtt;исправлен ряд уязвимостей общего характера (CVE), а язык Go обновлён до версии 1.26.6.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Postgres Pro Enterprise Manager входит в состав всех редакций СУБД Postgres Pro и предоставляет единый веб-интерфейс для мониторинга, администрирования и диагностики баз данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Компания также анонсировала выход модуля Healthcheck Advisor в одном из ближайших релизов PPEM. Он будет автоматически анализировать состояние экземпляров СУБД на основе собранной телеметрии, выявлять отклонения по ключевым показателям работы баз данных, определять уровень их критичности и формировать рекомендации по дальнейшим действиям.&lltt;/p&ggtt;
&lltt;p&ggtt;Для каждого обнаруженного отклонения будут доступны сведения о метрике, объекте анализа, нормативном и фактическом значениях, времени срабатывания и рекомендуемых мерах по устранению проблемы. Результаты будут представлены в разделе «Проблемы и рекомендации»: в нём будет размещена сводная информация по управляемым экземплярам, распределение обнаружений по уровням критичности и перечень экземпляров с наибольшим числом выявленных проблем.&lltt;/p&ggtt;
&lltt;p&ggtt;PPEM Healthcheck Advisor войдёт в базовую поставку платформы и не потребует отдельной установки или лицензирования. Подробная информация об изменениях и инструкции по обновлению до PPEM 2.9 доступны в документации Postgres Pro Enterprise Manager.&lltt;/p&ggtt;]]></source>
<adate>07.09.2026</adate>
<dbid>235476</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[«Информзащита»: число алертов на атаки через корпоративные сервисы коммуникации выросло более чем в 2 раза]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235475]]></link>
<description><![CDATA[Число алертов на вредоносную активность в корпоративных сервисах коммуникации за последние 12 месяцев выросло более чем в два раза, выяснили эксперты компании «Информзащита». При этом большинство таких срабатываний относились к фишинговым операциям в чатах. Корпоративные мессенджеры и другие платформы для совместной работы все чаще используются злоумышленниками для атак на учетные записи, доставки вредоносных файлов и развития атаки после первоначального проникновения. Особенности корпоративных коммуникационных сред создают дополнительные возможности для таких атак. В отличие от электронной почты, такие сервисы поддерживают федеративный доступ между организациями, гостевой доступ, общие рабочие пространства и интеграции со сторонними системами. Для бизнеса это упрощает взаимодействие, но одновременно расширяет число доверенных каналов, через которые злоумышленник может обратиться к пользователю. Сообщение, поступившее из корпоративного или знакомого пользователю рабочего пространства, может восприниматься как часть обычного рабочего процесса. Если злоумышленнику удается получить доступ к учетной записи сотрудника, он наследует ее права, связи и историю переписки. Фишинговая ссылка или просьба передать файл в таком случае уже не обязательно выглядит как внешняя атака. Она приходит от сотрудника или аккаунта, который имеет легитимный доступ к нужной среде. Именно поэтому основной объем выявленной активности связан с чат-фишингом. Злоумышленники используют внешние коммуникации и скомпрометированные учетные записи, чтобы инициировать диалог, выдать себя за сотрудника службы поддержки или другого знакомого человека и затем подтолкнуть жертву к определенному действию. Это может быть переход на страницу сбора учетных данных, подтверждение запроса многофакторной аутентификации, установка программного обеспечения удаленного доступа или передача корпоративной информации. В атаках используются прямые сообщения, упоминания в каналах и легитимные уведомления платформ. После получения действующей корпоративной учетной записи атакующий может использовать ее для доступа к облачным сервисам и другим ресурсам с правами скомпрометированного пользователя. При этом традиционные средства контроля часто сосредоточены на событиях аутентификации и электронной почте и могут не иметь достаточной видимости того, что происходит внутри уже установленной и аутентифицированной сессии. Показатель роста алертов более чем в два раза при этом нельзя сводить только к увеличению количества фишинговых сообщений. Меняется сама роль коммуникационных платформ в цепочке атаки. Зафиксированы случаи, когда доверенные сервисы применялись для дальнейшего развития атаки. В декабре 2025 года при расследовании инцидента на производственном предприятии в Польше злоумышленник использовал скомпрометированные сетевые устройства, чтобы получить пароль привилегированной учетной записи, изменить параметры безопасности и отключить двухфакторную аутентификацию. Результаты операций передавались через штатную возможность отправки уведомлений. Легитимная интеграция с сервисом коммуникации стала частью механизма сохранения доступа и вывода данных. Такие сценарии особенно актуальны для организаций, которые активно используют внешние рабочие пространства и интеграции с партнерами. Чем больше у компании гостевых учетных записей, федеративных соединений и сторонних подключений, тем шире пространство для злоупотребления доверенными отношениями. При этом сам факт успешной аутентификации пользователя уже не дает достаточного основания считать последующие действия безопасными. Скомпрометированная учетная запись продолжает выглядеть легитимно, пока система не сопоставит ее действия с контекстом поведения. Для защиты от подобных сценариев контроль коммуникационных платформ следует расширять за пределы обычной проверки входа в систему. Администраторам необходимо регулярно пересматривать федеративный доступ между организациями, гостевой доступ и сторонние интеграции, удаляя ненужные разрешения. Мониторинг должен охватывать события обмена файлами, подключения внешних пользователей и приложений, изменения прав и необычную активность учетных записей, а также неожиданные исходящие обращения к сервисам коммуникации через встроенные интеграции. Проверку ссылок и вложений в сообщениях необходимо настраивать отдельно с учетом возможностей платформы. Дополнительно следует применять устойчивые к фишингу методы аутентификации, например на основе FIDO2, если используемые системы их поддерживают. Использование средств удаленного доступа необходимо ограничивать согласованными инструментами и установленными процедурами технической поддержки. На уровне пользователей особое значение имеет проверка чувствительных запросов через независимый канал. Пароли и одноразовые коды нельзя передавать другим людям, в том числе сотрудникам поддержки. Запрос MFA следует подтверждать только для входа или операции, которые пользователь инициировал самостоятельно. Запросы на установку ПО удаленного доступа, передачу рабочих данных или изменение прав необходимо проверять через заранее известный номер телефона, внутреннюю систему заявок или другой установленный процесс. Сотрудникам также должен быть понятен порядок сообщения о подозрительных обращениях в службу информационной безопасности. Данные мониторинга коммуникационных платформ, сетевых устройств и конечных точек целесообразно сводить в единую систему анализа, чтобы связать подозрительное сообщение с последующими действиями учетной записи и устройства. Порядок реагирования должен предусматривать оперативный отзыв скомпрометированных сессий. Рост числа алертов более чем в два раза показывает, что корпоративные мессенджеры становятся самостоятельной частью поверхности атаки. Для службы информационной безопасности это уже не только каналы рабочих коммуникаций, но и источник событий, по которым можно выявлять компрометацию учетных записей и дальнейшее развитие атаки. При этом 99% алертов, связанных с корпоративными сервисами коммуникации, приходятся на чат-фишинг. Поэтому в защите таких сред приоритетом остается выявление подозрительных сообщений и контроль действий, которые следуют за ними]]></description>
<source><![CDATA[&lltt;p&ggtt;Число алертов на вредоносную активность в корпоративных сервисах коммуникации за последние 12 месяцев выросло более чем в два раза, выяснили эксперты компании «Информзащита». При этом большинство таких срабатываний относились к фишинговым операциям в чатах. Корпоративные мессенджеры и другие платформы для совместной работы все чаще используются злоумышленниками для атак на учетные записи, доставки вредоносных файлов и развития атаки после первоначального проникновения.&lltt;/p&ggtt;
&lltt;p&ggtt;Особенности корпоративных коммуникационных сред создают дополнительные возможности для таких атак. В отличие от электронной почты, такие сервисы поддерживают федеративный доступ между организациями, гостевой доступ, общие рабочие пространства и интеграции со сторонними системами. Для бизнеса это упрощает взаимодействие, но одновременно расширяет число доверенных каналов, через которые злоумышленник может обратиться к пользователю.&lltt;/p&ggtt;
&lltt;p&ggtt;Сообщение, поступившее из корпоративного или знакомого пользователю рабочего пространства, может восприниматься как часть обычного рабочего процесса. Если злоумышленнику удается получить доступ к учетной записи сотрудника, он наследует ее права, связи и историю переписки. Фишинговая ссылка или просьба передать файл в таком случае уже не обязательно выглядит как внешняя атака. Она приходит от сотрудника или аккаунта, который имеет легитимный доступ к нужной среде.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому основной объем выявленной активности связан с чат-фишингом. Злоумышленники используют внешние коммуникации и скомпрометированные учетные записи, чтобы инициировать диалог, выдать себя за сотрудника службы поддержки или другого знакомого человека и затем подтолкнуть жертву к определенному действию. Это может быть переход на страницу сбора учетных данных, подтверждение запроса многофакторной аутентификации, установка программного обеспечения удаленного доступа или передача корпоративной информации. В атаках используются прямые сообщения, упоминания в каналах и легитимные уведомления платформ.&lltt;/p&ggtt;
&lltt;p&ggtt;После получения действующей корпоративной учетной записи атакующий может использовать ее для доступа к облачным сервисам и другим ресурсам с правами скомпрометированного пользователя. При этом традиционные средства контроля часто сосредоточены на событиях аутентификации и электронной почте и могут не иметь достаточной видимости того, что происходит внутри уже установленной и аутентифицированной сессии.&lltt;/p&ggtt;
&lltt;p&ggtt;Показатель роста алертов более чем в два раза при этом нельзя сводить только к увеличению количества фишинговых сообщений. Меняется сама роль коммуникационных платформ в цепочке атаки. Зафиксированы случаи, когда доверенные сервисы применялись для дальнейшего развития атаки. В декабре 2025 года при расследовании инцидента на производственном предприятии в Польше злоумышленник использовал скомпрометированные сетевые устройства, чтобы получить пароль привилегированной учетной записи, изменить параметры безопасности и отключить двухфакторную аутентификацию. Результаты операций передавались через штатную возможность отправки уведомлений. Легитимная интеграция с сервисом коммуникации стала частью механизма сохранения доступа и вывода данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Такие сценарии особенно актуальны для организаций, которые активно используют внешние рабочие пространства и интеграции с партнерами. Чем больше у компании гостевых учетных записей, федеративных соединений и сторонних подключений, тем шире пространство для злоупотребления доверенными отношениями. При этом сам факт успешной аутентификации пользователя уже не дает достаточного основания считать последующие действия безопасными. Скомпрометированная учетная запись продолжает выглядеть легитимно, пока система не сопоставит ее действия с контекстом поведения.&lltt;/p&ggtt;
&lltt;p&ggtt;Для защиты от подобных сценариев контроль коммуникационных платформ следует расширять за пределы обычной проверки входа в систему. Администраторам необходимо регулярно пересматривать федеративный доступ между организациями, гостевой доступ и сторонние интеграции, удаляя ненужные разрешения. Мониторинг должен охватывать события обмена файлами, подключения внешних пользователей и приложений, изменения прав и необычную активность учетных записей, а также неожиданные исходящие обращения к сервисам коммуникации через встроенные интеграции. Проверку ссылок и вложений в сообщениях необходимо настраивать отдельно с учетом возможностей платформы. Дополнительно следует применять устойчивые к фишингу методы аутентификации, например на основе FIDO2, если используемые системы их поддерживают. Использование средств удаленного доступа необходимо ограничивать согласованными инструментами и установленными процедурами технической поддержки.&lltt;/p&ggtt;
&lltt;p&ggtt;На уровне пользователей особое значение имеет проверка чувствительных запросов через независимый канал. Пароли и одноразовые коды нельзя передавать другим людям, в том числе сотрудникам поддержки. Запрос MFA следует подтверждать только для входа или операции, которые пользователь инициировал самостоятельно. Запросы на установку ПО удаленного доступа, передачу рабочих данных или изменение прав необходимо проверять через заранее известный номер телефона, внутреннюю систему заявок или другой установленный процесс. Сотрудникам также должен быть понятен порядок сообщения о подозрительных обращениях в службу информационной безопасности. Данные мониторинга коммуникационных платформ, сетевых устройств и конечных точек целесообразно сводить в единую систему анализа, чтобы связать подозрительное сообщение с последующими действиями учетной записи и устройства. Порядок реагирования должен предусматривать оперативный отзыв скомпрометированных сессий.&lltt;/p&ggtt;
&lltt;p&ggtt;Рост числа алертов более чем в два раза показывает, что корпоративные мессенджеры становятся самостоятельной частью поверхности атаки. Для службы информационной безопасности это уже не только каналы рабочих коммуникаций, но и источник событий, по которым можно выявлять компрометацию учетных записей и дальнейшее развитие атаки. При этом 99% алертов, связанных с корпоративными сервисами коммуникации, приходятся на чат-фишинг. Поэтому в защите таких сред приоритетом остается выявление подозрительных сообщений и контроль действий, которые следуют за ними.&lltt;/p&ggtt;]]></source>
<adate>07.09.2026</adate>
<dbid>235475</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Почему хорошего кода больше недостаточно]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235472]]></link>
<description><![CDATA[Код — это только половина продукта. Вторая половина — ваша способность доказать заказчику, что он безопасен сегодня и останется таким завтра. Весной 2026 года вступили в силу обновленные требования ФСТЭК России к защите государственных информационных систем. Регулятор смещает акцент с разового подтверждения безопасности на ее непрерывное обеспечение в течение всего жизненного цикла системы. На первый взгляд это выглядит как очередная регуляторная нагрузка на госсектор. Но на самом деле новые правила бьют по самому больному месту любого коммерческого вендора — его маржинальности. ФСТЭК официально закрепил то, о чем рынок шептался годами: стоимость вашего продукта теперь равна стоимости времени вашей реакции на инцидент. Если поиск уязвимости в сотнях зависимостей занимает дни, ваш продукт для крупного заказчика стоит ноль, каким бы качественным ни был собственный код. Мы привыкли считать, что главная ценность ИТ-компании — талантливые разработчики. Но сегодня этого уже недостаточно. Качественный код остается обязательным условием, однако он перестал быть конкурентным преимуществом. Им становятся инженерные процессы. Безопасность как производственный процесс Современное программное обеспечение перестало быть статичным продуктом. Оно постоянно обновляется, интегрируется с внешними сервисами и использует десятки сторонних компонентов. По оценкам Sonatype, до 90% современного софта составляют компоненты с открытым исходным кодом (Open Source). Программный продукт превратился в сложную цепочку поставок, где защищенность зависит не только от собственного кода разработчика, но и от десятков внешних библиотек. Именно поэтому мы больше не можем один раз проверить систему и считать вопрос безопасности закрытым. Доверие определяется зрелостью процессов разработки, сопровождения и обновления. Что меняется в критериях выбора Еще несколько лет назад ключевыми преимуществами были функциональность, скорость написания кода и стоимость проекта. Сегодня крупный заказчик оценивает не только то, что умеет продукт, но и то, как компания гарантирует его развитие. Для него вопрос «как создается продукт» становится не менее важным, чем «что он умеет». Зрелость инженерных процессов превращается в решающий фактор доверия: заказчику нужна уверенность в безопасном развитии решения на годы вперед, а не просто зафиксированный набор функций на момент поставки. Open Source как экзамен для процессов Открытый код остается фундаментом разработки, однако он же стал главным источником рисков в цепочке поставок ПО. Когда появляется новость об уязвимости нулевого дня, счет идет на часы. Заказчик хочет сразу понять, затронута ли его система, каков риск и когда будет готово исправление. Ответить на эти вопросы за пару часов можно только при выстроенных процессах управления зависимостями (наличии актуального реестра компонентов — SBOM) и регламенте экстренного выпуска патчей. Наличие такого конвейера превращает информационную безопасность из статьи расходов в реальное рыночное преимущество. Конкуренция инженерной зрелости Автоматизация проверок, управление зависимостями и скорость выпуска обновлений перестают быть сугубо внутренними инженерными задачами. Они становятся частью рыночной ценности продукта. Инвестиции в выстраивание этих процессов нельзя рассматривать только как выполнение требований регулятора — это вложения в устойчивость бизнеса и капитализацию компании. Мне кажется символичным, что именно требования информационной безопасности подталкивают отрасль к тому, чтобы качество ПО оценивалось не только по функциональности, но и по предсказуемости его развития. Российский рынок переходит от конкуренции продуктов к конкуренции инженерной зрелости. И выигрывать будут компании, которые смогут гарантировать надежное, безопасное и прозрачное сопровождение своего решения на протяжении всего его жизненного цикла. #IMAGE_235473#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Код&nbsp;— это только половина продукта. Вторая половина&nbsp;— ваша способность доказать заказчику, что он&nbsp;безопасен сегодня и&nbsp;останется таким завтра.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Весной 2026 года вступили в&nbsp;силу обновленные требования ФСТЭК России к&nbsp;защите государственных информационных систем. Регулятор смещает акцент с&nbsp;разового подтверждения безопасности на&nbsp;ее&nbsp;непрерывное обеспечение в&nbsp;течение всего жизненного цикла системы. На&nbsp;первый взгляд это выглядит как очередная регуляторная нагрузка на&nbsp;госсектор. Но&nbsp;на&nbsp;самом деле новые правила бьют по&nbsp;самому больному месту любого коммерческого вендора&nbsp;— его маржинальности.&lltt;/p&ggtt;
&lltt;p&ggtt;ФСТЭК официально закрепил&nbsp;то, о&nbsp;чем рынок шептался годами: стоимость вашего продукта теперь равна стоимости времени вашей реакции на&nbsp;инцидент. Если поиск уязвимости в&nbsp;сотнях зависимостей занимает дни, ваш продукт для крупного заказчика стоит ноль, каким&nbsp;бы качественным ни&nbsp;был собственный код. Мы&nbsp;привыкли считать, что главная ценность ИТ-компании&nbsp;— талантливые разработчики. Но&nbsp;сегодня этого уже недостаточно. Качественный код остается обязательным условием, однако он&nbsp;перестал быть конкурентным преимуществом. Им&nbsp;становятся инженерные процессы.&lltt;/p&ggtt;
&lltt;h3&ggtt;Безопасность как производственный процесс&lltt;/h3&ggtt;
&lltt;p&ggtt;Современное программное обеспечение перестало быть статичным продуктом. Оно постоянно обновляется, интегрируется с&nbsp;внешними сервисами и&nbsp;использует десятки сторонних компонентов. По&nbsp;оценкам Sonatype, до&nbsp;90% современного софта составляют компоненты с&nbsp;открытым исходным кодом (Open Source). Программный продукт превратился в&nbsp;сложную цепочку поставок, где защищенность зависит не&nbsp;только от&nbsp;собственного кода разработчика, но&nbsp;и&nbsp;от&nbsp;десятков внешних библиотек. Именно поэтому мы&nbsp;больше не&nbsp;можем один раз проверить систему и&nbsp;считать вопрос безопасности закрытым. Доверие определяется зрелостью процессов разработки, сопровождения и&nbsp;обновления.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что меняется в&nbsp;критериях выбора&lltt;/h3&ggtt;
&lltt;p&ggtt;Еще несколько лет назад ключевыми преимуществами были функциональность, скорость написания кода и&nbsp;стоимость проекта. Сегодня крупный заказчик оценивает не&nbsp;только&nbsp;то, что умеет продукт, но&nbsp;и&nbsp;то, как компания гарантирует его развитие. Для него вопрос «как создается продукт» становится не&nbsp;менее важным, чем «что он&nbsp;умеет». Зрелость инженерных процессов превращается в&nbsp;решающий фактор доверия: заказчику нужна уверенность в&nbsp;безопасном развитии решения на&nbsp;годы вперед, а&nbsp;не&nbsp;просто зафиксированный набор функций на&nbsp;момент поставки.&lltt;/p&ggtt;
&lltt;h3&ggtt;Open Source как экзамен для процессов&lltt;/h3&ggtt;
&lltt;p&ggtt;Открытый код остается фундаментом разработки, однако он&nbsp;же стал главным источником рисков в&nbsp;цепочке поставок ПО. Когда появляется новость об&nbsp;уязвимости нулевого дня, счет идет на&nbsp;часы. Заказчик хочет сразу понять, затронута&nbsp;ли его система, каков риск и&nbsp;когда будет готово исправление. Ответить на&nbsp;эти вопросы за&nbsp;пару часов можно только при выстроенных процессах управления зависимостями (наличии актуального реестра компонентов&nbsp;— SBOM) и&nbsp;регламенте экстренного выпуска патчей. Наличие такого конвейера превращает информационную безопасность из&nbsp;статьи расходов в&nbsp;реальное рыночное преимущество.&lltt;/p&ggtt;
&lltt;h3&ggtt;Конкуренция инженерной зрелости&lltt;/h3&ggtt;
&lltt;p&ggtt;Автоматизация проверок, управление зависимостями и&nbsp;скорость выпуска обновлений перестают быть сугубо внутренними инженерными задачами. Они становятся частью рыночной ценности продукта. Инвестиции в&nbsp;выстраивание этих процессов нельзя рассматривать только как выполнение требований регулятора&nbsp;— это вложения в&nbsp;устойчивость бизнеса и&nbsp;капитализацию компании.&lltt;/p&ggtt;
&lltt;p&ggtt;Мне кажется символичным, что именно требования информационной безопасности подталкивают отрасль к&nbsp;тому, чтобы качество&nbsp;ПО оценивалось не&nbsp;только по&nbsp;функциональности, но&nbsp;и&nbsp;по&nbsp;предсказуемости его развития. Российский рынок переходит от&nbsp;конкуренции продуктов к&nbsp;конкуренции инженерной зрелости. И&nbsp;выигрывать будут компании, которые смогут гарантировать надежное, безопасное и&nbsp;прозрачное сопровождение своего решения на&nbsp;протяжении всего его жизненного цикла.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235473#&lltt;/p&ggtt;]]></source>
<adate>07.09.2026</adate>
<dbid>235472</dbid>
<rubric>8</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/b3d/yznvlz3c3qp3cqrapvs7plp18txv3qxt.jpg]]>
</images>
<imagesname><![CDATA[;;Ирина Мягкова, заместитель генерального директора по развитию АО НПП РЕЛЭКС   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Безопасность;;ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[McKinsey: корпоративный ИИ превращается в гонку на двух скоростях]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235471]]></link>
<description><![CDATA[Гонка в сфере корпоративного искусственного интеллекта начинает демонстрировать некоторое разделение. Хотя внедрение ИИ продолжает распространяться по организациям, новое исследование McKinsey показывает, что крупные предприятия и небольшая группа высокоэффективных компаний движутся значительно быстрее всех остальных. Результатом может стать начало формирования двухскоростного рынка корпоративного ИИ, сообщает портал BigDataWire. Отчет McKinsey «State of AI in 2026» основан на опросе 1719 участников из 97 стран. Исследование выявило резкие различия во внедрении агентов ИИ. 40% респондентов из организаций с годовым доходом более 1 млрд. долл. заявили, что сейчас масштабируют агентов ИИ. Это больше, чем 27% в прошлом году. В небольших организациях этот показатель составляет всего 22% и не увеличился по сравнению с прошлым годом. Аналогичное разделение наблюдается и в отношении агентов для кодирования. В целом около 20% организаций масштабируют эту технологию, по сравнению с 31% крупных предприятий. Но более интересным изменением может стать то, как компании используют эти инструменты. ИИ начинает менять дилемму «разрабатывать или покупать» Почти треть респондентов (32%) заявили, что их организация отказалась от покупки хотя бы одного программного продукта или функции, поскольку могла бы разработать функциональность внутри компании, используя инструменты агентного кодирования. Это значительное событие для рынка корпоративных технологий, построенного вокруг компаний, покупающих специализированное ПО для решения специализированных задач. ИИ-агенты кодирования потенциально меняют ситуацию, снижая затраты и время, необходимые для разработки ПО внутри компании. Это не означает, что предприятия внезапно заменят Salesforce, SAP или другие основные платформы ПО, созданным агентами ИИ. Разработка функции внутри компании и замена крупного корпоративного приложения — это совершенно разные вещи. Но результаты исследования McKinsey показывают, что ИИ начинает влиять на решения о покупке технологий, а не просто становится еще одной статьей технологического бюджета. И организации, получающие наибольшую выгоду от ИИ, похоже, движутся в этом направлении. McKinsey классифицирует только 6% респондентов как высокоэффективных пользователей ИИ. Это означает, что они относят не менее 5% прибыли до вычета процентов и налогов (EBIT) к ИИ и описывают его влияние как значительное. Эта доля не увеличилась по сравнению с прошлым годом. Зато стало яснее, насколько по-разному компании подходят к ИИ. Успешные компании внедряют более широкий спектр технологий ИИ и чаще используют ИИ для роста и инноваций, а не для повышения эффективности. Они также в 3,3 раза чаще, чем другие организации, заявляют о намерении коренным образом трансформировать свой бизнес с помощью ИИ в течение следующих трех лет. Все остальные по-прежнему ищут окупаемости инвестиций Обнаруженный разрыв имеет значение, потому что финансовое влияние корпоративного ИИ в целом остается на удивление неизменным. Только 37% респондентов заявили, что ИИ внес положительный вклад в EBIT их организации, их доля практически не изменилась по сравнению с 2025-м. Это резко контрастирует с тем, что сообщают сами работники. Четверо из пяти (80%) заявили, что ИИ повысил их индивидуальную производительность, а 50% сказали, что он помогает им принимать более обоснованные решения. Таким образом, у корпоративного ИИ есть необычная проблема. Компании, похоже, накопили множество доказательств того, что технология может повысить производительность отдельных сотрудников, но им гораздо сложнее превратить эти достижения в измеримые улучшения финансовых показателей компании в целом. Экономические факторы также становится все труднее игнорировать. Каждый пятый респондент заявил, что операционные расходы, связанные с ИИ, включая затраты на токены, ограничивают использование ИИ. Тем не менее, большинство организаций по-прежнему ожидают увеличения своих инвестиций в ИИ в течение следующего года. Это означает, что требование демонстрации отдачи, вероятно, будет расти по мере того, как внедрение будет становиться все более масштабным и дорогостоящим. Одного масштаба может быть недостаточно У крупнейших компаний есть очевидное преимущество. У них больше денег, которые они могут потратить на модели, инфраструктуру, обработку данных и организационные изменения, необходимые для внедрения ИИ в сложные рабочие процессы. Но результаты исследования McKinsey показывают, что одних только затрат и масштаба недостаточно. Даже по мере расширения внедрения ИИ доля компаний, генерирующих значительную финансовую ценность, остается на уровне 6%. Организации, начинающие выделяться, похоже, делают нечто более фундаментальное: перестраивают способы выполнения работы с использованием ИИ, а не просто добавляют инструменты ИИ к существующим процессам. Это различие станет еще более важным, когда агенты выйдут за рамки просто ответов на вопросы и начнут писать ПО, получать доступ к корпоративным данным и действовать в рамках бизнес-процессов. Поэтому следующий этап развития корпоративного ИИ может быть связан не столько с тем, кто внедряет ИИ, сколько с тем, что происходит после этого. В гонку вступают почти все. Но отрываться начинает гораздо меньшая группа]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Гонка в сфере корпоративного искусственного интеллекта начинает демонстрировать некоторое разделение. Хотя внедрение ИИ продолжает распространяться по организациям, новое исследование McKinsey показывает, что крупные предприятия и небольшая группа высокоэффективных компаний движутся значительно быстрее всех остальных. Результатом может стать начало формирования двухскоростного рынка корпоративного ИИ, сообщает портал &lltt;/em&ggtt;&lltt;em&ggtt;BigDataWire&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Отчет McKinsey «State of AI in 2026» основан на опросе 1719 участников из 97 стран. Исследование выявило резкие различия во внедрении агентов ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;40% респондентов из организаций с годовым доходом более 1 млрд. долл. заявили, что сейчас масштабируют агентов ИИ. Это больше, чем 27% в прошлом году. В небольших организациях этот показатель составляет всего 22% и не увеличился по сравнению с прошлым годом.&lltt;/p&ggtt;
&lltt;p&ggtt;Аналогичное разделение наблюдается и в отношении агентов для кодирования. В целом около 20% организаций масштабируют эту технологию, по сравнению с 31% крупных предприятий. Но более интересным изменением может стать то, как компании используют эти инструменты.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ начинает менять дилемму «разрабатывать или покупать»&lltt;/h3&ggtt;
&lltt;p&ggtt;Почти треть респондентов (32%) заявили, что их организация отказалась от покупки хотя бы одного программного продукта или функции, поскольку могла бы разработать функциональность внутри компании, используя инструменты агентного кодирования.&lltt;/p&ggtt;
&lltt;p&ggtt;Это значительное событие для рынка корпоративных технологий, построенного вокруг компаний, покупающих специализированное ПО для решения специализированных задач.&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ-агенты кодирования потенциально меняют ситуацию, снижая затраты и время, необходимые для разработки ПО внутри компании. Это не означает, что предприятия внезапно заменят Salesforce, SAP или другие основные платформы ПО, созданным агентами ИИ. Разработка функции внутри компании и замена крупного корпоративного приложения — это совершенно разные вещи.&lltt;/p&ggtt;
&lltt;p&ggtt;Но результаты исследования McKinsey показывают, что ИИ начинает влиять на решения о покупке технологий, а не просто становится еще одной статьей технологического бюджета. И организации, получающие наибольшую выгоду от ИИ, похоже, движутся в этом направлении.&lltt;/p&ggtt;
&lltt;p&ggtt;McKinsey классифицирует только 6% респондентов как высокоэффективных пользователей ИИ. Это означает, что они относят не менее 5% прибыли до вычета процентов и налогов (EBIT) к ИИ и описывают его влияние как значительное. Эта доля не увеличилась по сравнению с прошлым годом. Зато стало яснее, насколько по-разному компании подходят к ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Успешные компании внедряют более широкий спектр технологий ИИ и чаще используют ИИ для роста и инноваций, а не для повышения эффективности. Они также в 3,3 раза чаще, чем другие организации, заявляют о намерении коренным образом трансформировать свой бизнес с помощью ИИ в течение следующих трех лет.&lltt;/p&ggtt;
&lltt;h3&ggtt;Все остальные по-прежнему ищут окупаемости инвестиций&lltt;/h3&ggtt;
&lltt;p&ggtt;Обнаруженный разрыв имеет значение, потому что финансовое влияние корпоративного ИИ в целом остается на удивление неизменным.&lltt;/p&ggtt;
&lltt;p&ggtt;Только 37% респондентов заявили, что ИИ внес положительный вклад в EBIT их организации, их доля практически не изменилась по сравнению с &lltt;nobr&ggtt;2025-м.&lltt;/nobr&ggtt; Это резко контрастирует с тем, что сообщают сами работники. Четверо из пяти (80%) заявили, что ИИ повысил их индивидуальную производительность, а 50% сказали, что он помогает им принимать более обоснованные решения.&lltt;/p&ggtt;
&lltt;p&ggtt;Таким образом, у корпоративного ИИ есть необычная проблема. Компании, похоже, накопили множество доказательств того, что технология может повысить производительность отдельных сотрудников, но им гораздо сложнее превратить эти достижения в измеримые улучшения финансовых показателей компании в целом.&lltt;/p&ggtt;
&lltt;p&ggtt;Экономические факторы также становится все труднее игнорировать. Каждый пятый респондент заявил, что операционные расходы, связанные с ИИ, включая затраты на токены, ограничивают использование ИИ. Тем не менее, большинство организаций по-прежнему ожидают увеличения своих инвестиций в ИИ в течение следующего года. Это означает, что требование демонстрации отдачи, вероятно, будет расти по мере того, как внедрение будет становиться все более масштабным и дорогостоящим.&lltt;/p&ggtt;
&lltt;h3&ggtt;Одного масштаба может быть недостаточно&lltt;/h3&ggtt;
&lltt;p&ggtt;У крупнейших компаний есть очевидное преимущество. У них больше денег, которые они могут потратить на модели, инфраструктуру, обработку данных и организационные изменения, необходимые для внедрения ИИ в сложные рабочие процессы. Но результаты исследования McKinsey показывают, что одних только затрат и масштаба недостаточно.&lltt;/p&ggtt;
&lltt;p&ggtt;Даже по мере расширения внедрения ИИ доля компаний, генерирующих значительную финансовую ценность, остается на уровне 6%. Организации, начинающие выделяться, похоже, делают нечто более фундаментальное: перестраивают способы выполнения работы с использованием ИИ, а не просто добавляют инструменты ИИ к существующим процессам.&lltt;/p&ggtt;
&lltt;p&ggtt;Это различие станет еще более важным, когда агенты выйдут за рамки просто ответов на вопросы и начнут писать ПО, получать доступ к корпоративным данным и действовать в рамках бизнес-процессов. Поэтому следующий этап развития корпоративного ИИ может быть связан не столько с тем, &lltt;em&ggtt;кто&lltt;/em&ggtt; внедряет ИИ, сколько с тем, &lltt;em&ggtt;что&lltt;/em&ggtt; происходит после этого. В гонку вступают почти все. Но отрываться начинает гораздо меньшая группа.&lltt;/p&ggtt;]]></source>
<adate>07.09.2026</adate>
<dbid>235471</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[ИСИЭЗ НИУ ВШЭ: Китай и Республика Корея делают ИИ частью инфраструктуры науки]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235469]]></link>
<description><![CDATA[Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований, технологического развития и трансформации экономики. Этот переход отчетливо прослеживается в стратегических документах Китая и Республики Корея на 2026–2030 гг. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как эти страны адаптируют научно-технологическую политику к новой роли ИИ. Справочно: анализ охватывает Шестой базовый план развития науки и технологий Республики Корея (июнь 2026), Основные положения 15-го пятилетнего плана социально-экономического развития КНР (март 2026) и Мнения Госсовета КНР об углубленной реализации инициативы «ИИ+» (август 2025). В обеих странах ИИ-трансформация выходит далеко за пределы научного сектора. В Китае акцент переносится с «гонки моделей» на массовую диффузию ИИ и создание новых сценариев его применения. В Южной Корее ИИ-трансформация наряду с научной системой охватывает промышленность и региональные кластеры. ИИ-трансформация науки опирается на национальную вычислительную инфраструктуру. Китай развивает интегрированную сеть суперкомпьютеров, центров интеллектуальных вычислений и облачных платформ; Республика Корея планирует сформировать к 2030 г. государственно-частный пул из 260 тыс. GPU. Китайский план ориентирован на полный цикл — от исследований до ускоренной коммерциализации. Один из новых фронтиров — физический ИИ: развитие сред для обучения роботизированных систем и разработка гуманоидных роботов. Параллельно создаются институты отраслей будущего, центры проверки концепций, механизмы разделения инвестиционных рисков и регуляторные песочницы. В Республике Корея ИИ встраивают непосредственно в исследовательский процесс: план предусматривает развитие ИИ-соисследователей (AI Co-Scientist), автономных лабораторий и междисциплинарных проектов с применением ИИ. Масштабная технологическая трансформация сопровождается институциональной реформой науки, включающей переход к более долгосрочному и предсказуемому финансированию исследований, а также снижение административной нагрузки. В совокупности опыт двух стран показывает, что комплексная ИИ-трансформация науки требует не отдельной программы поддержки ИИ, а согласованного изменения всей исследовательской среды. Наибольший интерес представляет сочетание вычислительной инфраструктуры и широкого доступа к ее ресурсам, внедрения ИИ непосредственно в исследовательский процесс, долгосрочных механизмов финансирования науки и инструментов, ускоряющих переход от исследований к практическому применению]]></description>
<source><![CDATA[&lltt;p&ggtt;Искусственный интеллект из самостоятельного направления разработок превращается в сквозной инструмент исследований, технологического развития и трансформации экономики. Этот переход отчетливо прослеживается в стратегических документах Китая и Республики Корея на &lltt;nobr&ggtt;2026–2030 гг.&lltt;/nobr&ggtt; Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал, как эти страны адаптируют научно-технологическую политику к новой роли ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Справочно: анализ охватывает Шестой базовый план развития науки и технологий Республики Корея (июнь 2026), Основные положения &lltt;nobr&ggtt;15-го&lltt;/nobr&ggtt; пятилетнего плана социально-экономического развития КНР (март 2026) и Мнения Госсовета КНР об углубленной реализации инициативы «ИИ+» (август 2025).&lltt;/p&ggtt;
&lltt;p&ggtt;В обеих странах ИИ-трансформация выходит далеко за пределы научного сектора. В Китае акцент переносится с «гонки моделей» на массовую диффузию ИИ и создание новых сценариев его применения. В Южной Корее ИИ-трансформация наряду с научной системой охватывает промышленность и региональные кластеры.&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ-трансформация науки опирается на национальную вычислительную инфраструктуру. Китай развивает интегрированную сеть суперкомпьютеров, центров интеллектуальных вычислений и облачных платформ; Республика Корея планирует сформировать к 2030 г. государственно-частный пул из 260 тыс. GPU.&lltt;/p&ggtt;
&lltt;p&ggtt;Китайский план ориентирован на полный цикл — от исследований до ускоренной коммерциализации. Один из новых фронтиров — физический ИИ: развитие сред для обучения роботизированных систем и разработка гуманоидных роботов. Параллельно создаются институты отраслей будущего, центры проверки концепций, механизмы разделения инвестиционных рисков и регуляторные песочницы.&lltt;/p&ggtt;
&lltt;p&ggtt;В Республике Корея ИИ встраивают непосредственно в исследовательский процесс: план предусматривает развитие ИИ-соисследователей (AI Co-Scientist), автономных лабораторий и междисциплинарных проектов с применением ИИ. Масштабная технологическая трансформация сопровождается институциональной реформой науки, включающей переход к более долгосрочному и предсказуемому финансированию исследований, а также снижение административной нагрузки.&lltt;/p&ggtt;
&lltt;p&ggtt;В совокупности опыт двух стран показывает, что комплексная ИИ-трансформация науки требует не отдельной программы поддержки ИИ, а согласованного изменения всей исследовательской среды. Наибольший интерес представляет сочетание вычислительной инфраструктуры и широкого доступа к ее ресурсам, внедрения ИИ непосредственно в исследовательский процесс, долгосрочных механизмов финансирования науки и инструментов, ускоряющих переход от исследований к практическому применению.&lltt;/p&ggtt;]]></source>
<adate>04.09.2026</adate>
<dbid>235469</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[MWS Cloud развернула передовую модель GLM-5.3 в собственном облаке]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235468]]></link>
<description><![CDATA[MWS Cloud, входящая в МТС Web Services, развернула передовую модель GLM-5.3 в собственной облачной инфраструктуре. Она доступна в сервисе MWS GPT Model Hub и полностью локализована на территории России: данные пользователей и запросы к ней не покидают страну. Стоимость останется на уровне GLM-5.2. Развертывание GLM-5.3 в облаке MWS Cloud позволяет российским компаниям использовать модель для разработки программного обеспечения и решения агентских задач в российском ИТ-контуре. Среди возможных сценариев — генерация и анализ кода, поиск ошибок, работа с репозиториями, автоматизация многоэтапных процессов и создание ИИ-агентов. GLM-5.3 разработана китайской компанией Z.ai и опубликована с открытыми весами. По данным разработчика, модель использует ту же базовую архитектуру, что и GLM-5.2, а прирост качества получен за счет масштабирования посттренинга. Модель ориентирована на сложные задачи программирования и длительные последовательности действий с использованием инструментов. Z.ai опубликовала веса через две недели после запуска модели — это время разработчик отвел на дополнительную оценку и усиление мер безопасности. Локальное размещение модели в инфраструктуре MWS Cloud дает компаниям возможность работать с GLM-5.3 без передачи запросов и обрабатываемых данных за пределы России. Вычисления выполняются в облаке MWS Cloud на территории страны. По данным Z.ai и независимым оценкам, GLM-5.3 выступает на уровне передовых закрытых моделей. В задачах программирования она стабильно опережает Claude Opus 4.8 и сопоставима с новейшими Claude Fable 5 и GPT-5.6 Sol, лишь немного уступая им в самых сложных тестах. Сильнее всего модель проявляет себя в длительных агентских сценариях: здесь она в большинстве тестов не уступает закрытым моделям, а в части из них выходит вперед. В пользовательском рейтинге Text Arena модель идет практически вровень с лидером, а по качеству создания веб-интерфейсов входит в число лучших. В краудсорсинговом рейтинге Design Arena, где реальные пользователи сравнивают модели по качеству дизайна, GLM-5.3 входит в тройку лучших в общем зачете, заметно поднявшись относительно предыдущей версии, и занимает второе место среди моделей с открытыми весами]]></description>
<source><![CDATA[&lltt;p&ggtt;MWS Cloud, входящая в МТС Web Services, развернула передовую модель GLM-5.3 в собственной облачной инфраструктуре. Она доступна в сервисе MWS GPT Model Hub и полностью локализована на территории России: данные пользователей и запросы к ней не покидают страну. Стоимость останется на уровне GLM-5.2.&lltt;/p&ggtt;
&lltt;p&ggtt;Развертывание GLM-5.3 в облаке MWS Cloud позволяет российским компаниям использовать модель для разработки программного обеспечения и решения агентских задач в российском ИТ-контуре. Среди возможных сценариев — генерация и анализ кода, поиск ошибок, работа с репозиториями, автоматизация многоэтапных процессов и создание ИИ-агентов.&lltt;/p&ggtt;
&lltt;p&ggtt;GLM-5.3 разработана китайской компанией Z.ai и опубликована с открытыми весами. По данным разработчика, модель использует ту же базовую архитектуру, что и GLM-5.2, а прирост качества получен за счет масштабирования посттренинга. Модель ориентирована на сложные задачи программирования и длительные последовательности действий с использованием инструментов. Z.ai опубликовала веса через две недели после запуска модели — это время разработчик отвел на дополнительную оценку и усиление мер безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;Локальное размещение модели в инфраструктуре MWS Cloud дает компаниям возможность работать с GLM-5.3 без передачи запросов и обрабатываемых данных за пределы России. Вычисления выполняются в облаке MWS Cloud на территории страны.&lltt;/p&ggtt;
&lltt;p&ggtt;По данным Z.ai и независимым оценкам, GLM-5.3 выступает на уровне передовых закрытых моделей. В задачах программирования она стабильно опережает Claude Opus 4.8 и сопоставима с новейшими Claude Fable 5 и GPT-5.6 Sol, лишь немного уступая им в самых сложных тестах. Сильнее всего модель проявляет себя в длительных агентских сценариях: здесь она в большинстве тестов не уступает закрытым моделям, а в части из них выходит вперед. В пользовательском рейтинге Text Arena модель идет практически вровень с лидером, а по качеству создания веб-интерфейсов входит в число лучших. В краудсорсинговом рейтинге Design Arena, где реальные пользователи сравнивают модели по качеству дизайна, GLM-5.3 входит в тройку лучших в общем зачете, заметно поднявшись относительно предыдущей версии, и занимает второе место среди моделей с открытыми весами.&lltt;/p&ggtt;]]></source>
<adate>04.09.2026</adate>
<dbid>235468</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Три роли, которые ИИ-агенты играют на платформе для разработчиков]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235463]]></link>
<description><![CDATA[Матар Пелеш, инженер по разработке решений компании Port, рассказывает на портале The New Stack о том, как агенты искусственного интеллекта функционируют в качестве потребителей, внутренних компонентов и управляемых ресурсов на современных платформах для разработчиков. Инженерные организации стараются работать настолько быстро, насколько позволяют технологии, внедряя агентный ИИ в свои платформы для разработчиков и разрабатывая способы использования ИИ-агентов для максимизации производительности инженеров. Но когда речь заходит об агентной платформе для разработчиков, каждая команда, с которой мы общаемся, видит роль этих агентов немного по-разному. После сотен обсуждений мы определили три типа ролей. Роль 1: ИИ-агенты как потребители платформы В этой роли агент, по сути, является пользователем платформы. Он использует платформу в рамках своей задачи по чтению контекста и выполнению действий. Когда агенты впервые появились, многие компании заявили, что относятся к ним как к сотрудникам, а в платформе разработки агент становится просто еще одним инженерным ресурсом, использующим ее. #IMAGE_235465# Типичный пример: инженер просит Claude Code добавить конечную точку в платежный сервис. Прежде чем начать писать какой-либо код, агент получает от платформы информацию о владельце сервиса, зависимостях и стандартах, которым он должен соответствовать, затем запускает среду предварительного просмотра с помощью действия самообслуживания и выполняет тесты. Для корректной работы агенту необходимо проанализировать реальную, актуальную информацию о ваших системах, начиная с каталога услуг и заканчивая владельцами, зависимостями, стандартами и текущим состоянием. Если контекст неверен, высока вероятность того, что агент станет слишком самоуверенным и допустит ошибку. Большинство команд решают эту проблему, предоставляя локальный контекст отдельно для каждого агента. Из-за этого эта информация оказывается связана с агентами ненадежным образом, не говоря уже о том, что ни один из них не управляется. Сравните это с озером контекста, которое предоставляет каждому агенту единый управляемый источник достоверной информации. Платформа также должна быть доступна для работы агента, что означает ориентацию на API и MCP. Что требуется от платформы? Интерфейс, ориентированный на API и MCP, управляемый контекстный слой, из которого агент считывает данные, и набор действий самообслуживания, которые он может вызывать. Роль 2: ИИ-агенты как внутренние компоненты платформы Платформы, способные регистрировать агентов и запускать их в рамках рабочих процессов, используют агентов как часть полноценного бизнес-процесса. Агент работает внутри платформы, запускается событием, а не запрашивается человеком, и находится в механизме оркестровки рядом с детерминированными шагами. #IMAGE_235466# Возьмем запуск ежевечерней проверки, которая выявляет уязвимые зависимости в 40 сервисах. Платформа извлекает средство исправления из реестра и запускает его один раз для каждой службы, так что каждая команда владельцев получает доступ к открытому запросу на слияние (PR), ожидающему проверки. Что требуется от платформы? Уровень оркестровки для запуска агентов, реестр для выбора нужного агента, идентификационный номер для каждого агента, чтобы действие регистрировалось для конкретного агента, а не для заимствованных учетных данных человека, и этап с участием человека, где риск значителен. Роль 3: ИИ как ресурс со своим собственным жизненным циклом (также известно как AgenticOps) В этой роли агент является таким же ресурсом, как и LLM, серверы MCP и навыки, которые с этим связаны. Платформа предоставляет их, управляет ими и возвращает обратно, точно так же, как это происходит с сервисом, базой данных или средой. #IMAGE_235467# Например, предположим, инженеру нужен дежурный агент для сортировки обращений. Он выбирает модель, инструменты и среду выполнения либо через форму, либо описывая свои потребности, и платформа предоставляет все необходимое, подобно торговому автомату, включая хорошо управляемого агента, соответствующего необходимым стандартам. Это создает проблему «золотого пути». «Золотой путь» — это маршрут, который по умолчанию обеспечивает команде доступ к ресурсу правильным образом, и он нужен для жизненного цикла агента: запрос, получение и регистрация, а затем публикация для следующей команды. Это также то, чем чаще всего интересуются организации: реестр агентов и навыков был востребован 47% организаций, с которыми мы общались. Что требуется от платформы? Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификационные и ограниченные учетные данные, подключает утвержденный контекст и регистрирует агента на выходе, а также маршрут для публикации для следующей команды. Краткое описание трех ролей 	 		 			 				Роль 			 			 				Что агент собой представляет 			 			 				Пример 			 			 				Что требуется от платформы 			 		 	 	 		 			 				Роль 1: ИИ-агенты как потребители платформы 			 			 				Пользователь платформы, считывающий контекст и выполняющий действия в рамках своей задачи 			 			 				Claude Code определяет владельца сервиса, зависимости и стандарты, затем запускает среду предварительного просмотра и запускает тесты 			 			 				Управляемый контекстный слой, например, озеро контекста, и действия самообслуживания, которые он может вызывать 			 		 		 			 				Роль 2: ИИ-агенты как внутренние компоненты платформы 			 			 				Шаг в рабочем процессе, запускаемый событием, а не по запросу пользователя 			 			 				Ежевечернее сканирование выявляет уязвимую зависимость в 40 службах, и агент исправления открывает PR для каждой из них 			 			 				Слой оркестрации для запуска агентов, реестр для получения нужных данных, идентификация агентов и человек, вовлеченный в процесс там, где риск реален 			 		 		 			 				Роль 3: ИИ как многоразовые строительные блоки (AgenticOps) 			 			 				Ресурс, который платформа предоставляет, управляет им и возвращает обратно 			 			 				Инженер запрашивает агента сортировки по вызову, выбирает модель и инструменты и возвращает уже зарегистрированными 			 			 				Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификатор и ограниченные учетные данные, подключается в утвержденном контексте и регистрирует агента 			 		 	 Иногда эти три роли оказываются связанными Интересный случай с цепочкой ролей. Инженер запрашивает агента сортировки в роли 3; тот добавляется в реестр агентов как часть рабочего процесса создания, а неделю спустя рабочий процесс инцидента вызывает его как компонент (роль 2). Когда агент запускается, он считывает данные о владельце службы и последних развертываниях из того же контекстного хранилища, реализуя роль 1. Это один и тот же агент, которого вы видите в разных ролях. Как может выглядеть платформа, охватывающая все три роли Агент может использовать платформу в качестве пользователя через учетную запись службы, читая контекстное озеро и выполняя действия самообслуживания. Агенты работают в рамках рабочих процессов платформы как часть бизнес-процесса. Кроме того, AgenticOps работает в режиме самообслуживания, поэтому команда может запросить агента и получить уже зарегистрированного. Все три роли находятся в одном каталоге, в одном контексте и в одном журнале аудита]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Матар Пелеш, инженер по&nbsp;разработке решений компании Port, рассказывает на&nbsp;портале &lltt;/em&ggtt;&lltt;em&ggtt;The&lltt;/em&ggtt; &lltt;em&ggtt;New&lltt;/em&ggtt; &lltt;em&ggtt;Stack&lltt;/em&ggtt; &lltt;em&ggtt;о&nbsp;том, как агенты искусственного интеллекта функционируют в&nbsp;качестве потребителей, внутренних компонентов и&nbsp;управляемых ресурсов на&nbsp;современных платформах для разработчиков.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Инженерные организации стараются работать настолько быстро, насколько позволяют технологии, внедряя агентный&nbsp;ИИ в&nbsp;свои платформы для разработчиков и&nbsp;разрабатывая способы использования ИИ-агентов для максимизации производительности инженеров.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;когда речь заходит об&nbsp;агентной платформе для разработчиков, каждая команда, с&nbsp;которой мы&nbsp;общаемся, видит роль этих агентов немного по-разному. После сотен обсуждений мы&nbsp;определили три типа ролей.&lltt;/p&ggtt;
&lltt;h3&ggtt;Роль&nbsp;1: ИИ-агенты как потребители платформы&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;этой роли агент, по&nbsp;сути, является пользователем платформы. Он&nbsp;использует платформу в&nbsp;рамках своей задачи по&nbsp;чтению контекста и&nbsp;выполнению действий. Когда агенты впервые появились, многие компании заявили, что относятся к&nbsp;ним как к&nbsp;сотрудникам, а&nbsp;в&nbsp;платформе разработки агент становится просто еще одним инженерным ресурсом, использующим&nbsp;ее.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235465#&lltt;/p&ggtt;
&lltt;p&ggtt;Типичный пример: инженер просит Claude Code добавить конечную точку в&nbsp;платежный сервис. Прежде чем начать писать какой-либо код, агент получает от&nbsp;платформы информацию о&nbsp;владельце сервиса, зависимостях и&nbsp;стандартах, которым он&nbsp;должен соответствовать, затем запускает среду предварительного просмотра с&nbsp;помощью действия самообслуживания и&nbsp;выполняет тесты.&lltt;/p&ggtt;
&lltt;p&ggtt;Для корректной работы агенту необходимо проанализировать реальную, актуальную информацию о&nbsp;ваших системах, начиная с&nbsp;каталога услуг и&nbsp;заканчивая владельцами, зависимостями, стандартами и&nbsp;текущим состоянием. Если контекст неверен, высока вероятность того, что агент станет слишком самоуверенным и&nbsp;допустит ошибку. Большинство команд решают эту проблему, предоставляя локальный контекст отдельно для каждого агента. Из-за этого эта информация оказывается связана с&nbsp;агентами ненадежным образом, не&nbsp;говоря уже о&nbsp;том, что ни&nbsp;один из&nbsp;них не&nbsp;управляется. Сравните это с&nbsp;озером контекста, которое предоставляет каждому агенту единый управляемый источник достоверной информации. Платформа также должна быть доступна для работы агента, что означает ориентацию на&nbsp;API и&nbsp;MCP.&lltt;/p&ggtt;
&lltt;p&ggtt;Что требуется от&nbsp;платформы? Интерфейс, ориентированный на&nbsp;API и&nbsp;MCP, управляемый контекстный слой, из&nbsp;которого агент считывает данные, и&nbsp;набор действий самообслуживания, которые он&nbsp;может вызывать.&lltt;/p&ggtt;
&lltt;h3&ggtt;Роль&nbsp;2: ИИ-агенты как внутренние компоненты платформы&lltt;/h3&ggtt;
&lltt;p&ggtt;Платформы, способные регистрировать агентов и&nbsp;запускать их&nbsp;в&nbsp;рамках рабочих процессов, используют агентов как часть полноценного бизнес-процесса. Агент работает внутри платформы, запускается событием, а&nbsp;не&nbsp;запрашивается человеком, и&nbsp;находится в&nbsp;механизме оркестровки рядом с&nbsp;детерминированными шагами.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235466#&lltt;/p&ggtt;
&lltt;p&ggtt;Возьмем запуск ежевечерней проверки, которая выявляет уязвимые зависимости в&nbsp;40&nbsp;сервисах. Платформа извлекает средство исправления из&nbsp;реестра и&nbsp;запускает его один раз для каждой службы, так что каждая команда владельцев получает доступ к&nbsp;открытому запросу на&nbsp;слияние (PR), ожидающему проверки.&lltt;/p&ggtt;
&lltt;p&ggtt;Что требуется от&nbsp;платформы? Уровень оркестровки для запуска агентов, реестр для выбора нужного агента, идентификационный номер для каждого агента, чтобы действие регистрировалось для конкретного агента, а&nbsp;не&nbsp;для заимствованных учетных данных человека, и&nbsp;этап с&nbsp;участием человека, где риск значителен.&lltt;/p&ggtt;
&lltt;h3&ggtt;Роль&nbsp;3: ИИ&nbsp;как ресурс со&nbsp;своим собственным жизненным циклом (также известно как AgenticOps)&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;этой роли агент является таким&nbsp;же ресурсом, как и&nbsp;LLM, серверы MCP и&nbsp;навыки, которые с&nbsp;этим связаны. Платформа предоставляет&nbsp;их, управляет ими и&nbsp;возвращает обратно, точно так&nbsp;же, как это происходит с&nbsp;сервисом, базой данных или средой.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235467#&lltt;/p&ggtt;
&lltt;p&ggtt;Например, предположим, инженеру нужен дежурный агент для сортировки обращений. Он&nbsp;выбирает модель, инструменты и&nbsp;среду выполнения либо через форму, либо описывая свои потребности, и&nbsp;платформа предоставляет все необходимое, подобно торговому автомату, включая хорошо управляемого агента, соответствующего необходимым стандартам.&lltt;/p&ggtt;
&lltt;p&ggtt;Это создает проблему «золотого пути». «Золотой путь»&nbsp;— это маршрут, который по&nbsp;умолчанию обеспечивает команде доступ к&nbsp;ресурсу правильным образом, и&nbsp;он&nbsp;нужен для жизненного цикла агента: запрос, получение и&nbsp;регистрация, а&nbsp;затем публикация для следующей команды. Это также&nbsp;то, чем чаще всего интересуются организации: реестр агентов и&nbsp;навыков был востребован&nbsp;47% организаций, с&nbsp;которыми мы&nbsp;общались.&lltt;/p&ggtt;
&lltt;p&ggtt;Что требуется от&nbsp;платформы? Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификационные и&nbsp;ограниченные учетные данные, подключает утвержденный контекст и&nbsp;регистрирует агента на&nbsp;выходе, а&nbsp;также маршрут для публикации для следующей команды.&lltt;/p&ggtt;
&lltt;h3&ggtt;Краткое описание трех ролей&lltt;/h3&ggtt;
&lltt;table&ggtt; 
	&lltt;thead&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Роль&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Что агент собой представляет &lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Пример&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Что требуется от&nbsp;платформы&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/thead&ggtt;
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Роль&nbsp;1: ИИ-агенты как потребители платформы&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Пользователь платформы, считывающий контекст и&nbsp;выполняющий действия в&nbsp;рамках своей задачи&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Claude Code определяет владельца сервиса, зависимости и&nbsp;стандарты, затем запускает среду предварительного просмотра и&nbsp;запускает тесты&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Управляемый контекстный слой, например, озеро контекста, и&nbsp;действия самообслуживания, которые он&nbsp;может вызывать&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Роль&nbsp;2: ИИ-агенты как внутренние компоненты платформы&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Шаг в&nbsp;рабочем процессе, запускаемый событием, а&nbsp;не&nbsp;по&nbsp;запросу пользователя&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Ежевечернее сканирование выявляет уязвимую зависимость в&nbsp;40&nbsp;службах, и&nbsp;агент исправления открывает&nbsp;PR для каждой из&nbsp;них&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Слой оркестрации для запуска агентов, реестр для получения нужных данных, идентификация агентов и&nbsp;человек, вовлеченный в&nbsp;процесс там, где риск реален&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Роль&nbsp;3: ИИ&nbsp;как многоразовые строительные блоки (AgenticOps)&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Ресурс, который платформа предоставляет, управляет им&nbsp;и&nbsp;возвращает обратно&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Инженер запрашивает агента сортировки по&nbsp;вызову, выбирает модель и&nbsp;инструменты и&nbsp;возвращает уже зарегистрированными&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Путь самообслуживания, который обеспечивает среду выполнения, выдает идентификатор и&nbsp;ограниченные учетные данные, подключается в&nbsp;утвержденном контексте и&nbsp;регистрирует агента&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;h3&ggtt;Иногда эти три роли оказываются связанными&lltt;/h3&ggtt;
&lltt;p&ggtt;Интересный случай с&nbsp;цепочкой ролей. Инженер запрашивает агента сортировки в&nbsp;роли&nbsp;3; тот добавляется в&nbsp;реестр агентов как часть рабочего процесса создания, а&nbsp;неделю спустя рабочий процесс инцидента вызывает его как компонент (роль 2). Когда агент запускается, он&nbsp;считывает данные о&nbsp;владельце службы и&nbsp;последних развертываниях из&nbsp;того&nbsp;же контекстного хранилища, реализуя роль 1. Это один и&nbsp;тот&nbsp;же агент, которого вы&nbsp;видите в&nbsp;разных ролях.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как может выглядеть платформа, охватывающая все три роли&lltt;/h3&ggtt;
&lltt;p&ggtt;Агент может использовать платформу в&nbsp;качестве пользователя через учетную запись службы, читая контекстное озеро и&nbsp;выполняя действия самообслуживания. Агенты работают в&nbsp;рамках рабочих процессов платформы как часть бизнес-процесса. Кроме того, AgenticOps работает в&nbsp;режиме самообслуживания, поэтому команда может запросить агента и&nbsp;получить уже зарегистрированного. Все три роли находятся в&nbsp;одном каталоге, в&nbsp;одном контексте и&nbsp;в&nbsp;одном журнале аудита.&lltt;/p&ggtt;]]></source>
<adate>04.09.2026</adate>
<dbid>235463</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/5cb/hf5wn4pry1kd7hknl8d46d1ffs9nghzc.jpg;;https://www.itweek.ru/upload/iblock/405/9fl6ziiezwr44wtqem9lkwwozrznxlhc.jpg;;https://www.itweek.ru/upload/iblock/db7/s9iqs42fdkt2uegra6sg3cqa0ijybeig.jpg]]>
</images>
<imagesname><![CDATA[;; ;; ;; ]]></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[BI в реальном времени: какие показатели важно отслеживать руководителю]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235461]]></link>
<description><![CDATA[В операционном управлении — будь то производство, логистика, ритейл или сфера услуг — внедрение систем бизнес-аналитики давно перестало быть просто модным трендом. Это базовый стандарт конкурентоспособности. При этом многие компании совершают одну и ту же стратегическую ошибку: заказывают ИТ-подрядчикам «красивые панели показателей в реальном времени» и получают на выходе плоский список из десятков разрозненных цифр. Это создает иллюзию контроля, но на деле лишь нагружает руководителя информационным шумом. Как ИТ-эксперт, сопровождающий цифровую трансформацию, я предлагаю компаниям сместить фокус. В управления важны не сами по себе показатели. Главное — возможность иметь динамическую иерархическую отчетность. Руководителю жизненно необходимо за секунды переходить от показателей верхнего уровня к нижнему, сравнивать любые периоды между собой и делать это непосредственно в любой момент времени. Все всегда начинается с финансов. Но аналитическая система должна жестко ассоциировать финансовые результаты с физическими, так называемыми натуральными показателями. Финансы — это всегда запаздывающий индикатор, результат уже свершившихся событий. Чтобы управлять бизнесом, мы должны привязать деньги к количеству выпущенной продукции, отработанным сменам, объему потраченных материалов или скорости движения запасов на складах. В любом бизнесе существует 3-5 ключевых физических метрик, которые характеризуют его «биение сердца». Они обычно хорошо известны грамотному руководителю. Вокруг них строится семейство зависимых показателей. Вот универсальный перечень таких натуральных метрик и обоснование их выбора: 	Выработка на единицу трудозатрат (человеко-часов). Обоснование: напрямую связывает фонд оплаты труда с физическим объемом работы. Позволяет увидеть не просто рост затрат на персонал, а падение реальной эффективности конкретных смен или участков. 	Процент отклонений от стандарта (брак, переделки, ошибки). Обоснование: главный индикатор качества процессов. Рост этого показателя мгновенно объясняет рост себестоимости без необходимости глубокого финансового аудита. 	Время простоя оборудования или логистических узлов. Обоснование: натуральная метрика, которая конвертируется в упущенную выручку и сверхурочные выплаты. Показывает реальную загрузку мощностей и узкие места. 	Расход материалов или энергии на единицу продукции. Обоснование: позволяет отследить скрытые потери. Если деньги растут, а физический расход на единицу стабилен — проблема в ценах поставщиков. Если растет физический расход — проблема в технологии или персонале. Показательный кейс: как это работает на практике Представим производственную или торговую компанию. Во вторник утром генеральный директор видит, что операционная прибыль за вчера просела относительно плана на 8%. В «плоской» системе: директор звонит финдиректору и просит «поднять цифры». Через два дня приходит сводная таблица, из которой следует, что выросла себестоимость. Еще день уходит на запрос объяснительных от начальников. Время упущено, убыток закреплен. В иерархической системе: директор нажимает на просевший показатель прибыли на Экране № 1. Система мгновенно показывает, что драйвером стал рост затрат на конкретном участке. Он переходит на уровень ниже (Экран № 2) и видит: финансовый рост вызван натуральным показателем «процент отклонений», который резко подскочил в предыдущую смену. Переходя к еще большей детализации (Экран № 3), он видит прямую корреляцию: пик брака совпал с выходом новой бригады и партией сырья от нового поставщика. Итог: руководитель не ждет еженедельного совещания. Он прямо между встречами звонит начальнику производства, корректирует процесс и изолирует бракованную партию. На планерке вопрос уже закрыт. Как руководителю читать и анализировать данные Самое главное требование к системе: она должна позволять на одном, двух или трех экранах динамически отслеживать причинно-следственные связи. 	Экран «Капитанский мостик» (стратегический). Здесь только финансовые итоги и 3-5 главных натуральных индикаторов. Руководитель смотрит сюда каждое утро. Цель: увидеть отклонение от плана и сравнение с прошлыми периодами. 	Экран «Операционный разрез» (тактический). Сюда руководитель переходит по клику, если видит «красную зону». Здесь детализация по блокам: производство, склад, логистика. 	Экран «Контекст и связи» (аналитический). Возможность наложить любые показатели друг на друга. Например, сопоставить график «количества отработанных человеко-часов» с графиком «объема выпуска». Если линии расходятся, вы сразу видите неэффективность использования ресурсов без необходимости сводить сложные таблицы. Конец эры «давайте запросим статистику» Главная ценность такого подхода к аналитике в реальном времени заключается в фундаментальном изменении культуры управления. Раньше на регулярных совещаниях руководителей часто звучала фраза: «Давайте после встречи запросим статистику по этой гипотезе». Это убивало динамику и скорость реакции. Когда выстроена правильная иерархическая система, связывающая рубли с натуральными показателями (штуками, часами, килограммами), любые гипотезы проверяются прямо на экране за полминуты. Это позволяет управленцам быстро находить корневые причины проблем, назначать ответственных и действовать на опережение. Чтобы на регулярных совещаниях никогда не стоял вопрос о необходимости «запросить цифры», а любой вопрос мог быть проверен сразу же, на экране нашей системы. Именно это дает реальную власть над операционной деятельностью. #IMAGE_235462#]]></description>
<source><![CDATA[&lltt;p&ggtt;В&nbsp;операционном управлении&nbsp;— будь то&nbsp;производство, логистика, ритейл или сфера услуг&nbsp;— внедрение систем бизнес-аналитики давно перестало быть просто модным трендом. Это базовый стандарт конкурентоспособности. При этом многие компании совершают одну и&nbsp;ту&nbsp;же стратегическую ошибку: заказывают ИТ-подрядчикам «красивые панели показателей в&nbsp;реальном времени» и&nbsp;получают на&nbsp;выходе плоский список из&nbsp;десятков разрозненных цифр. Это создает иллюзию контроля, но&nbsp;на&nbsp;деле лишь нагружает руководителя информационным шумом.&lltt;/p&ggtt;
&lltt;p&ggtt;Как ИТ-эксперт, сопровождающий цифровую трансформацию, я&nbsp;предлагаю компаниям сместить фокус. В&nbsp;управления важны не&nbsp;сами по&nbsp;себе показатели. Главное&nbsp;— возможность иметь динамическую иерархическую отчетность. Руководителю жизненно необходимо за&nbsp;секунды переходить от&nbsp;показателей верхнего уровня к&nbsp;нижнему, сравнивать любые периоды между собой и&nbsp;делать это непосредственно в&nbsp;любой момент времени.&lltt;/p&ggtt;
&lltt;p&ggtt;Все всегда начинается с&nbsp;финансов. Но&nbsp;аналитическая система должна жестко ассоциировать финансовые результаты с&nbsp;физическими, так называемыми натуральными показателями. Финансы&nbsp;— это всегда запаздывающий индикатор, результат уже свершившихся событий. Чтобы управлять бизнесом, мы&nbsp;должны привязать деньги к&nbsp;количеству выпущенной продукции, отработанным сменам, объему потраченных материалов или скорости движения запасов на&nbsp;складах.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;любом бизнесе существует &lltt;nobr&ggtt;3-5&lltt;/nobr&ggtt; ключевых физических метрик, которые характеризуют его «биение сердца». Они обычно хорошо известны грамотному руководителю. Вокруг них строится семейство зависимых показателей. Вот универсальный перечень таких натуральных метрик и&nbsp;обоснование их&nbsp;выбора:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Выработка на&nbsp;единицу трудозатрат (человеко-часов). &lltt;/strong&ggtt;Обоснование: напрямую связывает фонд оплаты труда с&nbsp;физическим объемом работы. Позволяет увидеть не&nbsp;просто рост затрат на&nbsp;персонал, а&nbsp;падение реальной эффективности конкретных смен или участков.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Процент отклонений от&nbsp;стандарта (брак, переделки, ошибки). &lltt;/strong&ggtt;Обоснование: главный индикатор качества процессов. Рост этого показателя мгновенно объясняет рост себестоимости без необходимости глубокого финансового аудита.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Время простоя оборудования или логистических узлов. &lltt;/strong&ggtt;Обоснование: натуральная метрика, которая конвертируется в&nbsp;упущенную выручку и&nbsp;сверхурочные выплаты. Показывает реальную загрузку мощностей и&nbsp;узкие места.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Расход материалов или энергии на&nbsp;единицу продукции. &lltt;/strong&ggtt;Обоснование: позволяет отследить скрытые потери. Если деньги растут, а&nbsp;физический расход на&nbsp;единицу стабилен&nbsp;— проблема в&nbsp;ценах поставщиков. Если растет физический расход&nbsp;— проблема в&nbsp;технологии или персонале.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Показательный кейс: как это работает на&nbsp;практике&lltt;/h3&ggtt;
&lltt;p&ggtt;Представим производственную или торговую компанию. Во&nbsp;вторник утром генеральный директор видит, что операционная прибыль за&nbsp;вчера просела относительно плана на&nbsp;8%.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;«плоской» системе: директор звонит финдиректору и&nbsp;просит «поднять цифры». Через два дня приходит сводная таблица, из&nbsp;которой следует, что выросла себестоимость. Еще день уходит на&nbsp;запрос объяснительных от&nbsp;начальников. Время упущено, убыток закреплен.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;иерархической системе: директор нажимает на&nbsp;просевший показатель прибыли на&nbsp;Экране №&nbsp;1. Система мгновенно показывает, что драйвером стал рост затрат на&nbsp;конкретном участке. Он&nbsp;переходит на&nbsp;уровень ниже (Экран №&nbsp;2) и&nbsp;видит: финансовый рост вызван натуральным показателем «процент отклонений», который резко подскочил в&nbsp;предыдущую смену. Переходя к&nbsp;еще большей детализации (Экран №&nbsp;3), он&nbsp;видит прямую корреляцию: пик брака совпал с&nbsp;выходом новой бригады и&nbsp;партией сырья от&nbsp;нового поставщика.&lltt;/p&ggtt;
&lltt;p&ggtt;Итог: руководитель не&nbsp;ждет еженедельного совещания. Он&nbsp;прямо между встречами звонит начальнику производства, корректирует процесс и&nbsp;изолирует бракованную партию. На&nbsp;планерке вопрос уже закрыт.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как руководителю читать и&nbsp;анализировать данные&lltt;/h3&ggtt;
&lltt;p&ggtt;Самое главное требование к&nbsp;системе: она должна позволять на&nbsp;одном, двух или трех экранах динамически отслеживать причинно-следственные связи.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Экран «Капитанский мостик»&lltt;/strong&ggtt;&lltt;strong&ggtt; (стратегический).&lltt;/strong&ggtt; Здесь только финансовые итоги и&nbsp;&lltt;nobr&ggtt;3-5&lltt;/nobr&ggtt; главных натуральных индикаторов. Руководитель смотрит сюда каждое утро. Цель: увидеть отклонение от&nbsp;плана и&nbsp;сравнение с&nbsp;прошлыми периодами.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Экран «Операционный разрез» (тактический).&lltt;/strong&ggtt; Сюда руководитель переходит по&nbsp;клику, если видит «красную зону». Здесь детализация по&nbsp;блокам: производство, склад, логистика.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Экран «Контекст и&nbsp;связи» (аналитический).&lltt;/strong&ggtt; Возможность наложить любые показатели друг на&nbsp;друга. Например, сопоставить график «количества отработанных человеко-часов» с&nbsp;графиком «объема выпуска». Если линии расходятся, вы&nbsp;сразу видите неэффективность использования ресурсов без необходимости сводить сложные таблицы.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Конец эры «давайте запросим статистику»&lltt;/h3&ggtt;
&lltt;p&ggtt;Главная ценность такого подхода к&nbsp;аналитике в&nbsp;реальном времени заключается в&nbsp;фундаментальном изменении культуры управления.&lltt;/p&ggtt;
&lltt;p&ggtt;Раньше на&nbsp;регулярных совещаниях руководителей часто звучала фраза: «Давайте после встречи запросим статистику по&nbsp;этой гипотезе». Это убивало динамику и&nbsp;скорость реакции. &lltt;/p&ggtt;
&lltt;p&ggtt;Когда выстроена правильная иерархическая система, связывающая рубли с&nbsp;натуральными показателями (штуками, часами, килограммами), любые гипотезы проверяются прямо на&nbsp;экране за&nbsp;полминуты. Это позволяет управленцам быстро находить корневые причины проблем, назначать ответственных и&nbsp;действовать на&nbsp;опережение. Чтобы на&nbsp;регулярных совещаниях никогда не&nbsp;стоял вопрос о&nbsp;необходимости «запросить цифры», а&nbsp;любой вопрос мог быть проверен сразу&nbsp;же, на&nbsp;экране нашей системы. Именно это дает реальную власть над операционной деятельностью.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235462#&lltt;/p&ggtt;]]></source>
<adate>04.09.2026</adate>
<dbid>235461</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/362/2vfy48xuvg6gr83912egokfpjm3yz378.jpg]]>
</images>
<imagesname><![CDATA[;;Сергей Капарис, управляющий партнер Umbrella Consulting Group   ]]></imagesname>
<tag><![CDATA[Big Data/Аналитика]]></tag>
</item>
<item>
<title><![CDATA[M1Cloud: прогноз трансформации от IaaS к AI-IaaS на российском облачном рынке до 2030 года]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235457]]></link>
<description><![CDATA[Российский облачный рынок проходит через структурную трансформацию, сравнимую по масштабу с переходом от физических серверов к виртуализации. Наряду с классической моделью IaaS — аренда виртуальных машин, дискового пространства и сетевых ресурсов — будет расти спрос на AI-IaaS: инфраструктуру как сервис, предназначенную для обучения, дообучения и эксплуатации моделей искусственного интеллекта. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что в традиционном облаке объектом выступают виртуальные машины, контейнеры и хранилища, а в AI-IaaS к ним добавляются поведение модели, происхождение данных, промпты, векторные индексы, GPU-кластеры и действия подключенных инструментов. По оценкам аналитиков M1Cloud, прогноз роста облачного рынка до 2030 года предполагает среднегодовой темп 25-32% с учетом миграции нагрузок из зарубежных платформ и расширения ИИ-проектов в госсекторе, финансах, промышленности и телекоме. Трансформация российского облачного рынка определяется не только технологической логикой, но и регуляторными ограничениями. Требования локализации данных, ограничение трансграничной передачи, необходимость использования инфраструктуры российских провайдеров и доказательного соответствия нормативным актам создают уникальный контур, в котором AI-IaaS становится не опцией, а условием продолжения цифровизации. Для суверенного ИИ критичны локализация вычислений, география GPU, логирование и воспроизводимость цикла и не менее важны, чем производительность. В 2026 году доля AI-IaaS в общем объеме российского облачного рынка оценивается в 12-15%, что соответствует 18-22 млрд рублей. Ключевым драйвером выступают пилотные GPU-кластеры и первые промышленные инференс-нагрузки крупных языковых моделей. Заказчики тестируют сценарии RAG (генерация с дополненным поиском), чат-ботов и автоматизации документооборота, но объемы пока ограничены экспериментальными бюджетами. К 2027 году доля AI-IaaS вырастет до 22-27%, а абсолютный объем достигнет 38-48 млрд рублей. На этом этапе произойдет переход от пилотов к промышленной эксплуатации: банки, страховые компании и государственные структуры запустят продуктивные RAG-контуры и внутренние ассистенты. Спрос сместится от аренды «сырых» GPU к управляемым сервисам с встроенной фильтрацией промптов, журналированием и контролем цепочки данных. В 2028 году ожидается рост доли до 33-38% и объема до 62-78 млрд рублей. Массовое дообучение моделей на корпоративных данных станет стандартом. AI Firewall и контроль цепочки поставки модели превратятся из конкурентного преимущества в обязательное требование. Регулятор, вероятно, утвердит отраслевые стандарты безопасности для ИИ-инфраструктуры, аналогичные требованиям к КИИ. К 2029 году доля AI-IaaS достигнет 42-48%, объем — 95-115 млрд рублей. Доминирующим сценарием станут мультиагентные системы и автономные бизнес-процессы, в которых модель не просто отвечает на запрос, а инициирует действия в CRM, ERP и платежных контурах. Это увеличит требования к разграничению прав инструментов и непрерывному мониторингу дрейфа. Наконец, к 2030 году более половины инфраструктурных расходов российских компаний, использующих облака, будет приходиться на ИИ-нагрузки: инференс, дообучение, хранение векторных баз, оркестрацию GPU-заданий и обеспечение безопасности цепочки принятия решений модели. Обучение крупных моделей с нуля остается нишевым из-за стоимости и ограничений на поставки передовых ускорителей. Прогнозируемая доля — 50-55%, абсолютный объем — 130-160 млрд рублей. AI-IaaS станет базовым слоем корпоративной ИТ-архитектуры, а не надстройкой над классическим облаком. Ускоренный сценарий роста сегмента AI-IaaS реализуется при государственных программах субсидирования и обязательном внедрении ИИ в госуслуги и КИИ. Рост может достичь 35-40% в год, к 2030 году AI-IaaS займет более 60% облачных расходов. Сформируются отраслевые ИИ-платформы с жесткой изоляцией. С другой стороны, сдержанный сценарий наступит при дефиците GPU, ужесточении экспортных ограничений и замедлении корпоративных бюджетов. Рост ограничится 18-22% в год, и к 2030 году доля AI-IaaS не превысит 35-40%, значительная часть нагрузок остается в on-premise. К 2030 году российский облачный рынок завершит переход от парадигмы «аренда серверов» к парадигме «управление цепочкой принятия решений модели». Для российских компаний и провайдеров окно стратегического маневра открыто в 2026–2028 годах, после чего архитектура рынка будет определяться теми, кто первым встроил безопасность, суверенитет и наблюдаемость в архитектуру ИИ-инфраструктуры]]></description>
<source><![CDATA[&lltt;p&ggtt;Российский облачный рынок проходит через структурную трансформацию, сравнимую по масштабу с переходом от физических серверов к виртуализации. Наряду с классической моделью IaaS — аренда виртуальных машин, дискового пространства и сетевых ресурсов — будет расти спрос на AI-IaaS: инфраструктуру как сервис, предназначенную для обучения, дообучения и эксплуатации моделей искусственного интеллекта. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что в традиционном облаке объектом выступают виртуальные машины, контейнеры и хранилища, а в AI-IaaS к ним добавляются поведение модели, происхождение данных, промпты, векторные индексы, GPU-кластеры и действия подключенных инструментов.&lltt;/p&ggtt;
&lltt;p&ggtt;По оценкам аналитиков M1Cloud, прогноз роста облачного рынка до 2030 года предполагает среднегодовой темп &lltt;nobr&ggtt;25-32%&lltt;/nobr&ggtt; с учетом миграции нагрузок из зарубежных платформ и расширения ИИ-проектов в госсекторе, финансах, промышленности и телекоме.&lltt;/p&ggtt;
&lltt;p&ggtt;Трансформация российского облачного рынка определяется не только технологической логикой, но и регуляторными ограничениями. Требования локализации данных, ограничение трансграничной передачи, необходимость использования инфраструктуры российских провайдеров и доказательного соответствия нормативным актам создают уникальный контур, в котором AI-IaaS становится не опцией, а условием продолжения цифровизации. Для суверенного ИИ критичны локализация вычислений, география GPU, логирование и воспроизводимость цикла и не менее важны, чем производительность.&lltt;/p&ggtt;
&lltt;p&ggtt;В 2026 году доля AI-IaaS в общем объеме российского облачного рынка оценивается в &lltt;nobr&ggtt;12-15%,&lltt;/nobr&ggtt; что соответствует &lltt;nobr&ggtt;18-22&lltt;/nobr&ggtt; млрд рублей. Ключевым драйвером выступают пилотные GPU-кластеры и первые промышленные инференс-нагрузки крупных языковых моделей. Заказчики тестируют сценарии RAG (генерация с дополненным поиском), чат-ботов и автоматизации документооборота, но объемы пока ограничены экспериментальными бюджетами.&lltt;/p&ggtt;
&lltt;p&ggtt;К 2027 году доля AI-IaaS вырастет до &lltt;nobr&ggtt;22-27%,&lltt;/nobr&ggtt; а абсолютный объем достигнет &lltt;nobr&ggtt;38-48&lltt;/nobr&ggtt; млрд рублей. На этом этапе произойдет переход от пилотов к промышленной эксплуатации: банки, страховые компании и государственные структуры запустят продуктивные RAG-контуры и внутренние ассистенты. Спрос сместится от аренды «сырых» GPU к управляемым сервисам с встроенной фильтрацией промптов, журналированием и контролем цепочки данных.&lltt;/p&ggtt;
&lltt;p&ggtt;В 2028 году ожидается рост доли до &lltt;nobr&ggtt;33-38%&lltt;/nobr&ggtt; и объема до &lltt;nobr&ggtt;62-78&lltt;/nobr&ggtt; млрд рублей. Массовое дообучение моделей на корпоративных данных станет стандартом. AI Firewall и контроль цепочки поставки модели превратятся из конкурентного преимущества в обязательное требование. Регулятор, вероятно, утвердит отраслевые стандарты безопасности для ИИ-инфраструктуры, аналогичные требованиям к КИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;К 2029 году доля AI-IaaS достигнет &lltt;nobr&ggtt;42-48%,&lltt;/nobr&ggtt; объем — &lltt;nobr&ggtt;95-115&lltt;/nobr&ggtt; млрд рублей. Доминирующим сценарием станут мультиагентные системы и автономные бизнес-процессы, в которых модель не просто отвечает на запрос, а инициирует действия в CRM, ERP и платежных контурах. Это увеличит требования к разграничению прав инструментов и непрерывному мониторингу дрейфа.&lltt;/p&ggtt;
&lltt;p&ggtt;Наконец, к 2030 году более половины инфраструктурных расходов российских компаний, использующих облака, будет приходиться на ИИ-нагрузки: инференс, дообучение, хранение векторных баз, оркестрацию GPU-заданий и обеспечение безопасности цепочки принятия решений модели. Обучение крупных моделей с нуля остается нишевым из-за стоимости и ограничений на поставки передовых ускорителей. Прогнозируемая доля — &lltt;nobr&ggtt;50-55%,&lltt;/nobr&ggtt; абсолютный объем — &lltt;nobr&ggtt;130-160&lltt;/nobr&ggtt; млрд рублей. AI-IaaS станет базовым слоем корпоративной ИТ-архитектуры, а не надстройкой над классическим облаком.&lltt;/p&ggtt;
&lltt;p&ggtt;Ускоренный сценарий роста сегмента AI-IaaS реализуется при государственных программах субсидирования и обязательном внедрении ИИ в госуслуги и КИИ. Рост может достичь &lltt;nobr&ggtt;35-40%&lltt;/nobr&ggtt; в год, к 2030 году AI-IaaS займет более 60% облачных расходов. Сформируются отраслевые ИИ-платформы с жесткой изоляцией.&lltt;/p&ggtt;
&lltt;p&ggtt;С другой стороны, сдержанный сценарий наступит при дефиците GPU, ужесточении экспортных ограничений и замедлении корпоративных бюджетов. Рост ограничится &lltt;nobr&ggtt;18-22%&lltt;/nobr&ggtt; в год, и к 2030 году доля AI-IaaS не превысит &lltt;nobr&ggtt;35-40%,&lltt;/nobr&ggtt; значительная часть нагрузок остается в on-premise.&lltt;/p&ggtt;
&lltt;p&ggtt;К 2030 году российский облачный рынок завершит переход от парадигмы «аренда серверов» к парадигме «управление цепочкой принятия решений модели». Для российских компаний и провайдеров окно стратегического маневра открыто в &lltt;nobr&ggtt;2026–2028 годах,&lltt;/nobr&ggtt; после чего архитектура рынка будет определяться теми, кто первым встроил безопасность, суверенитет и наблюдаемость в архитектуру ИИ-инфраструктуры.&lltt;/p&ggtt;]]></source>
<adate>03.09.2026</adate>
<dbid>235457</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[Basis Workplace 3.4: виртуализация приложений и работа в нескольких средах одновременно]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235458]]></link>
<description><![CDATA[«Базис» выпустила новую версию Basis Workplace, флагманской платформы для управления инфраструктурой виртуальных рабочих столов (VDI). Ключевыми изменениями релиза 3.4 стали возможность работы с несколькими инсталляциями с одного рабочего места, поддержка виртуализации приложений и нативный инструмент миграции с Basis Workplace второго поколения. Помимо этого, в релизе был расширен инструментарий управления пулами и виртуальными рабочими местами, добавлены новые сценарии развертывания и средства управления сертификатами, а также обновлен протокол Basis Connect. В Basis Workplace 3.4 администраторы получили возможность определять набор приложений, которые автоматически устанавливаются на виртуальные рабочие места (ВРМ) пользователей. Настройки применяются централизованно для пулов, что исключает ручную установку на каждом ВРМ, снижает нагрузку на поддержку и гарантирует единообразное рабочее окружение для сотрудников. Гибкие политики позволяют контролировать, каким сотрудникам какие приложения доступны, а пользователь получает готовую, полностью оснащенную среду с первого же сеанса — без ожидания и запросов в техподдержку. В новом релизе добавлен режим мультиклиента, который позволяет администраторам одновременно работать в нескольких инсталляциях Basis Workplace с одного рабочего места. Единая точка администрирования упрощает обслуживание VDI-инфраструктуры, расположенной в разных ЦОДах, филиалах, контурах и т.д., а также позволяет быстро переключаться между средами и ускоряет реакцию на инциденты. В персонализированных пулах — логических объединениях виртуальных рабочих столов, использующих общие ресурсы и настройки — стало доступно использование персональных дисков пользователей, а также перемещение дисков между пулами. В случае изменения индивидуального шаблона, с использованием которого создавался персонализированный пул, реализованный механизм рекомпозиции позволяет пересобирать виртуальные машины этого пула. Клиентскую часть Basis Workplace теперь можно устанавливать отдельно от протоколов доставки, в том числе для включения в дистрибутив заказчика. На одну виртуальную машину допускается последовательная установка нескольких дополнительных сервисов, а брокер сообщений NATS можно развернуть как отдельный сервис, объединив три его экземпляра в кластер. Все перечисленное позволяет администратору учесть потребности и особенности создаваемой VDI-инфраструктуры уже на этапе инсталляции Basis Workplace. Basis Workplace позволяет загружать серверный сертификат заказчика непосредственно на этапе инсталляции, а для SSL-запросов в новой версии был реализован переход на системное хранилище сертификатов операционной системы. Для заказчиков, использующих Basis Workplace 2.6.4 и планирующих переход на версию платформы 3.4 создан новый инструмент миграции пулов. Он переносит объекты и их настройки, поддерживает миграцию сессионных, персональных и терминальных пулов. Для персональных пулов предусмотрена возможность отката миграции. В собственном протоколе доставки Basis Connect появилось управление направлением проброса буфера обмена. Теперь администратор может включать и выключать передачу файлов, текста и изображений через буфер; обмен данными можно разрешить только с пользовательского устройства на сервер, только в обратную сторону или в обе стороны одновременно. В окне протокола также добавлен графический интерфейс с подробными сведениями о доступных USB-устройствах, смарт-картах, токенах, принтерах и других. Список поддерживаемого платформой Basis Workplace ПО пополнили операционные системы Windows 11 и «Альт» 11 в качестве гостевых и клиентских ОС, а также платформа виртуализации VMware vCenter Server 6.7u3. В версии платформы 3.4 появились новые инструменты создания отчетности по запуску приложений и подключениям к терминальным пулам. Теперь администратор может получать списки уникальных пользователей и устройств доступа, а также вручную выгружать эти данные. Все это обеспечивает прозрачность использования опубликованных ресурсов и помогает эффективнее управлять инфраструктурой. «Basis Workplace развивается как самодостаточная платформа, закрывающая все больше сценариев работы с VDI-инфраструктурой внутри одного продукта. Виртуализация отдельных приложений стала ключевым новшеством релиза. Она позволяет централизованно и быстро обеспечивать сотрудников доступом к необходимым корпоративным приложениям. Отдельно в новом релизе мне бы хотелось отметить появление инструментов для миграции с Basis Workplace второго поколения — функциональной и надежной, но уже архитектурно устаревшей версии нашей платформы», — прокомментировал Дмитрий Сорокин, технический директор «Базис»]]></description>
<source><![CDATA[&lltt;p&ggtt;«Базис» выпустила новую версию Basis Workplace, флагманской платформы для управления инфраструктурой виртуальных рабочих столов (VDI). Ключевыми изменениями релиза 3.4 стали возможность работы с несколькими инсталляциями с одного рабочего места, поддержка виртуализации приложений и нативный инструмент миграции с Basis Workplace второго поколения. Помимо этого, в релизе был расширен инструментарий управления пулами и виртуальными рабочими местами, добавлены новые сценарии развертывания и средства управления сертификатами, а также обновлен протокол Basis Connect.&lltt;/p&ggtt;
&lltt;p&ggtt;В Basis Workplace 3.4 администраторы получили возможность определять набор приложений, которые автоматически устанавливаются на виртуальные рабочие места (ВРМ) пользователей. Настройки применяются централизованно для пулов, что исключает ручную установку на каждом ВРМ, снижает нагрузку на поддержку и гарантирует единообразное рабочее окружение для сотрудников. Гибкие политики позволяют контролировать, каким сотрудникам какие приложения доступны, а пользователь получает готовую, полностью оснащенную среду с первого же сеанса — без ожидания и запросов в техподдержку.&lltt;/p&ggtt;
&lltt;p&ggtt;В новом релизе добавлен режим мультиклиента, который позволяет администраторам одновременно работать в нескольких инсталляциях Basis Workplace с одного рабочего места. Единая точка администрирования упрощает обслуживание &lltt;nobr&ggtt;VDI-инфраструктуры,&lltt;/nobr&ggtt; расположенной в разных ЦОДах, филиалах, контурах и т.д., а также позволяет быстро переключаться между средами и ускоряет реакцию на инциденты.&lltt;/p&ggtt;
&lltt;p&ggtt;В персонализированных пулах — логических объединениях виртуальных рабочих столов, использующих общие ресурсы и настройки — стало доступно использование персональных дисков пользователей, а также перемещение дисков между пулами. В случае изменения индивидуального шаблона, с использованием которого создавался персонализированный пул, реализованный механизм рекомпозиции позволяет пересобирать виртуальные машины этого пула.&lltt;/p&ggtt;
&lltt;p&ggtt;Клиентскую часть Basis Workplace теперь можно устанавливать отдельно от протоколов доставки, в том числе для включения в дистрибутив заказчика. На одну виртуальную машину допускается последовательная установка нескольких дополнительных сервисов, а брокер сообщений NATS можно развернуть как отдельный сервис, объединив три его экземпляра в кластер. Все перечисленное позволяет администратору учесть потребности и особенности создаваемой &lltt;nobr&ggtt;VDI-инфраструктуры&lltt;/nobr&ggtt; уже на этапе инсталляции Basis Workplace.&lltt;/p&ggtt;
&lltt;p&ggtt;Basis Workplace позволяет загружать серверный сертификат заказчика непосредственно на этапе инсталляции, а для SSL-запросов в новой версии был реализован переход на системное хранилище сертификатов операционной системы.&lltt;/p&ggtt;
&lltt;p&ggtt;Для заказчиков, использующих Basis Workplace 2.6.4 и планирующих переход на версию платформы 3.4 создан новый инструмент миграции пулов. Он переносит объекты и их настройки, поддерживает миграцию сессионных, персональных и терминальных пулов. Для персональных пулов предусмотрена возможность отката миграции.&lltt;/p&ggtt;
&lltt;p&ggtt;В собственном протоколе доставки Basis Connect появилось управление направлением проброса буфера обмена. Теперь администратор может включать и выключать передачу файлов, текста и изображений через буфер; обмен данными можно разрешить только с пользовательского устройства на сервер, только в обратную сторону или в обе стороны одновременно. В окне протокола также добавлен графический интерфейс с подробными сведениями о доступных USB-устройствах, смарт-картах, токенах, принтерах и других.&lltt;/p&ggtt;
&lltt;p&ggtt;Список поддерживаемого платформой Basis Workplace ПО пополнили операционные системы Windows 11 и «Альт» 11 в качестве гостевых и клиентских ОС, а также платформа виртуализации VMware vCenter Server 6.7u3.&lltt;/p&ggtt;
&lltt;p&ggtt;В версии платформы 3.4 появились новые инструменты создания отчетности по запуску приложений и подключениям к терминальным пулам. Теперь администратор может получать списки уникальных пользователей и устройств доступа, а также вручную выгружать эти данные. Все это обеспечивает прозрачность использования опубликованных ресурсов и помогает эффективнее управлять инфраструктурой.&lltt;/p&ggtt;
&lltt;p&ggtt;«Basis Workplace развивается как самодостаточная платформа, закрывающая все больше сценариев работы с &lltt;nobr&ggtt;VDI-инфраструктурой&lltt;/nobr&ggtt; внутри одного продукта. Виртуализация отдельных приложений стала ключевым новшеством релиза. Она позволяет централизованно и быстро обеспечивать сотрудников доступом к необходимым корпоративным приложениям. Отдельно в новом релизе мне бы хотелось отметить появление инструментов для миграции с Basis Workplace второго поколения — функциональной и надежной, но уже архитектурно устаревшей версии нашей платформы», — прокомментировал Дмитрий Сорокин, технический директор «Базис».&lltt;/p&ggtt;]]></source>
<adate>03.09.2026</adate>
<dbid>235458</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Сети/Серверы/СХД/ЦОД]]></tag>
</item>
<item>
<title><![CDATA[«Информзащита»: доля инцидентов с использованием удаленного доступа достигла 62%]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235455]]></link>
<description><![CDATA[Эксперты компании «Информзащита» выявили, что в 2026 году средства удаленного доступа использовались в 62% киберинцидентов, не связанных с компрометацией деловой электронной почты. В 2025 году их доля составляла 49%, за год показатель вырос на 13 п. п. В эту категорию входят атаки через RDP, VPN и системы удаленного мониторинга и управления RMM. Причина такой динамики связана прежде всего с тем, что удаленный доступ изначально предполагает возможность подключения к корпоративной инфраструктуре извне. VPN-шлюзы, серверы RDP и RMM-платформы используются администраторами, подрядчиками, технической поддержкой и сотрудниками филиалов, поэтому полностью убрать их из внешнего контура во многих компаниях невозможно. Для атакующего такой сервис представляет удобную точку входа. При наличии действующей учетной записи или возможности обойти механизм аутентификации ему не требуется доставлять сложное вредоносное ПО на рабочую станцию пользователя. Активность может начинаться с обычного подключения к легитимному сервису и внешне выглядеть как действия штатного специалиста. Пароли от VPN, RDP и административных систем попадают в руки злоумышленников после фишинговых кампаний, заражений инфостилерами, утечек из сторонних сервисов и компрометации подрядчиков. Риск возрастает там, где для удаленного подключения не используется MFA, разрешена парольная аутентификация без дополнительных факторов, учетные записи годами сохраняют избыточные права, а доступ открыт для широкого диапазона внешних адресов. Отдельная проблема связана с сервисными и техническими учетными записями. Они реже используются людьми в повседневной работе, поэтому смена паролей и пересмотр привилегий для них нередко откладываются. При этом именно такие записи могут давать расширенный доступ к инфраструктуре. Разбивка по основным векторам первоначального проникновения показывает, что удаленный доступ заметно опережает эксплуатацию программных уязвимостей. На RDP, VPN, RMM и другие внешние средства удаленного подключения приходится 65% инцидентов вне BEC. Еще 11% связаны с эксплуатацией известных уязвимостей, причем в рассмотренных случаях исправления для них уже существовали. Годом ранее доля этого вектора достигала 29%. Еще 8% пришлось на ошибки конфигурации и злоупотребление доверенными связями, хотя ранее их совокупная доля не превышала 1%. Оставшиеся около 16% распределяются между другими сценариями первоначального доступа, включая загрузку вредоносного ПО, социальную инженерию и менее распространенные способы компрометации. Получается, что злоумышленники все чаще выбирают сценарии, в которых можно использовать уже существующую инфраструктуру доступа и доверия, вместо разработки отдельного эксплойта. Рост доли удаленного доступа объясняется и архитектурой корпоративных сетей. Пограничные устройства часто совмещают несколько функций и обладают высокими привилегиями. Компрометация VPN-шлюза, RMM-сервера или системы администрирования может сразу дать атакующему возможность работать с несколькими сегментами сети. После входа начинается сбор информации об инфраструктуре, поиск доменных учетных записей, повышение привилегий и горизонтальное перемещение. Скорость такого сценария заметно выше, когда удаленный сервис уже интегрирован с Active Directory, имеет доверительные отношения с другими системами или позволяет запускать команды на множестве рабочих станций. В расследованиях фиксировались случаи, когда после первоначального доступа злоумышленники переходили к контролю доменной инфраструктуры за считанные минуты. Наиболее заметные риски формируются в отраслях, где удаленное администрирование используется постоянно и охватывает большое число систем. В здравоохранении показатель составил 33%, в образовании — 25%. Эти значения нельзя напрямую приравнивать к доле атак через RDP, VPN или RMM из статистики расследований, поскольку использовалась другая методика, однако отраслевой разрез показывает, где проблемы с безопасностью удаленного доступа проявляются особенно часто. Для технологических и сервисных компаний риск связан с большим числом административных подключений и клиентских сред, для промышленности — с сочетанием удаленного обслуживания и устаревающей инфраструктуры, а для здравоохранения и образования — с большим числом разнородных систем и ограниченными возможностями быстро менять их конфигурацию. Отдельное внимание требуется RMM-платформам. Такие системы создавались именно для централизованного управления парком устройств, поэтому их функции совпадают с тем, что нужно атакующему после проникновения. Через легитимный агент можно запускать команды, устанавливать программное обеспечение, передавать файлы и управлять удаленной машиной. Это осложняет детектирование, поскольку сам факт запуска RMM-клиента не является признаком атаки. Аналогичная проблема возникает с VPN. Успешная аутентификация с корректными учетными данными может не вызвать срабатывания средств защиты, хотя подключение выполняется злоумышленником. Поэтому контроль только вредоносных файлов и сигнатур сетевых атак не закрывает этот сценарий. Снижать риск необходимо одновременно на уровне идентификации пользователя, сетевой архитектуры и мониторинга. Для всех внешних административных подключений необходимо использовать MFA и по возможности отказаться от факторов, которые можно повторно применить после кражи учетных данных. Прямой RDP-доступ из интернета следует исключить, а VPN и RMM-сервисы ограничить по источникам подключения и доступным сегментам. Административные и сервисные учетные записи необходимо отделять от пользовательских, сокращать их привилегии и регулярно менять учетные данные, особенно после устранения уязвимостей на пограничных устройствах. Логи VPN, RDP, RMM, служб каталогов и средств защиты конечных точек должны анализироваться совместно, поскольку аномалия часто заметна не в самом факте подключения, а в последовательности действий после него. Дополнительный эффект дают сегментация сети, контроль новых RMM-инструментов, ограничение административных интерфейсов и регулярная инвентаризация всех внешних сервисов. При доле удаленного доступа в 65% инцидентов защита этого контура должна рассматриваться как отдельная задача управления доступом, а не только как часть стандартной настройки сетевого периметра]]></description>
<source><![CDATA[&lltt;p&ggtt;Эксперты компании «Информзащита» выявили, что в 2026 году средства удаленного доступа использовались в 62% киберинцидентов, не связанных с компрометацией деловой электронной почты. В 2025 году их доля составляла 49%, за год показатель вырос на 13 п. п. В эту категорию входят атаки через RDP, VPN и системы удаленного мониторинга и управления RMM.&lltt;/p&ggtt;
&lltt;p&ggtt;Причина такой динамики связана прежде всего с тем, что удаленный доступ изначально предполагает возможность подключения к корпоративной инфраструктуре извне. VPN-шлюзы, серверы RDP и RMM-платформы используются администраторами, подрядчиками, технической поддержкой и сотрудниками филиалов, поэтому полностью убрать их из внешнего контура во многих компаниях невозможно. Для атакующего такой сервис представляет удобную точку входа. При наличии действующей учетной записи или возможности обойти механизм аутентификации ему не требуется доставлять сложное вредоносное ПО на рабочую станцию пользователя. Активность может начинаться с обычного подключения к легитимному сервису и внешне выглядеть как действия штатного специалиста.&lltt;/p&ggtt;
&lltt;p&ggtt;Пароли от VPN, RDP и административных систем попадают в руки злоумышленников после фишинговых кампаний, заражений инфостилерами, утечек из сторонних сервисов и компрометации подрядчиков. Риск возрастает там, где для удаленного подключения не используется MFA, разрешена парольная аутентификация без дополнительных факторов, учетные записи годами сохраняют избыточные права, а доступ открыт для широкого диапазона внешних адресов. Отдельная проблема связана с сервисными и техническими учетными записями. Они реже используются людьми в повседневной работе, поэтому смена паролей и пересмотр привилегий для них нередко откладываются. При этом именно такие записи могут давать расширенный доступ к инфраструктуре.&lltt;/p&ggtt;
&lltt;p&ggtt;Разбивка по основным векторам первоначального проникновения показывает, что удаленный доступ заметно опережает эксплуатацию программных уязвимостей. На RDP, VPN, RMM и другие внешние средства удаленного подключения приходится 65% инцидентов вне BEC. Еще 11% связаны с эксплуатацией известных уязвимостей, причем в рассмотренных случаях исправления для них уже существовали. Годом ранее доля этого вектора достигала 29%. Еще 8% пришлось на ошибки конфигурации и злоупотребление доверенными связями, хотя ранее их совокупная доля не превышала 1%. Оставшиеся около 16% распределяются между другими сценариями первоначального доступа, включая загрузку вредоносного ПО, социальную инженерию и менее распространенные способы компрометации. Получается, что злоумышленники все чаще выбирают сценарии, в которых можно использовать уже существующую инфраструктуру доступа и доверия, вместо разработки отдельного эксплойта.&lltt;/p&ggtt;
&lltt;p&ggtt;Рост доли удаленного доступа объясняется и архитектурой корпоративных сетей. Пограничные устройства часто совмещают несколько функций и обладают высокими привилегиями. Компрометация VPN-шлюза, RMM-сервера или системы администрирования может сразу дать атакующему возможность работать с несколькими сегментами сети. После входа начинается сбор информации об инфраструктуре, поиск доменных учетных записей, повышение привилегий и горизонтальное перемещение. Скорость такого сценария заметно выше, когда удаленный сервис уже интегрирован с Active Directory, имеет доверительные отношения с другими системами или позволяет запускать команды на множестве рабочих станций. В расследованиях фиксировались случаи, когда после первоначального доступа злоумышленники переходили к контролю доменной инфраструктуры за считанные минуты.&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее заметные риски формируются в отраслях, где удаленное администрирование используется постоянно и охватывает большое число систем. В здравоохранении показатель составил 33%, в образовании — 25%. Эти значения нельзя напрямую приравнивать к доле атак через RDP, VPN или RMM из статистики расследований, поскольку использовалась другая методика, однако отраслевой разрез показывает, где проблемы с безопасностью удаленного доступа проявляются особенно часто. Для технологических и сервисных компаний риск связан с большим числом административных подключений и клиентских сред, для промышленности — с сочетанием удаленного обслуживания и устаревающей инфраструктуры, а для здравоохранения и образования — с большим числом разнородных систем и ограниченными возможностями быстро менять их конфигурацию.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельное внимание требуется RMM-платформам. Такие системы создавались именно для централизованного управления парком устройств, поэтому их функции совпадают с тем, что нужно атакующему после проникновения. Через легитимный агент можно запускать команды, устанавливать программное обеспечение, передавать файлы и управлять удаленной машиной. Это осложняет детектирование, поскольку сам факт запуска RMM-клиента не является признаком атаки. Аналогичная проблема возникает с VPN. Успешная аутентификация с корректными учетными данными может не вызвать срабатывания средств защиты, хотя подключение выполняется злоумышленником. Поэтому контроль только вредоносных файлов и сигнатур сетевых атак не закрывает этот сценарий.&lltt;/p&ggtt;
&lltt;p&ggtt;Снижать риск необходимо одновременно на уровне идентификации пользователя, сетевой архитектуры и мониторинга. Для всех внешних административных подключений необходимо использовать MFA и по возможности отказаться от факторов, которые можно повторно применить после кражи учетных данных. Прямой RDP-доступ из интернета следует исключить, а VPN и RMM-сервисы ограничить по источникам подключения и доступным сегментам. Административные и сервисные учетные записи необходимо отделять от пользовательских, сокращать их привилегии и регулярно менять учетные данные, особенно после устранения уязвимостей на пограничных устройствах. Логи VPN, RDP, RMM, служб каталогов и средств защиты конечных точек должны анализироваться совместно, поскольку аномалия часто заметна не в самом факте подключения, а в последовательности действий после него. Дополнительный эффект дают сегментация сети, контроль новых RMM-инструментов, ограничение административных интерфейсов и регулярная инвентаризация всех внешних сервисов. При доле удаленного доступа в 65% инцидентов защита этого контура должна рассматриваться как отдельная задача управления доступом, а не только как часть стандартной настройки сетевого периметра.&lltt;/p&ggtt;]]></source>
<adate>03.09.2026</adate>
<dbid>235455</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Аутсорс vs. инхаус: стоит ли бизнесу держать в штате веб-разработчика]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235451]]></link>
<description><![CDATA[Обсудим, почему в 2026 году чистый инхаус всё чаще проигрывает гибридной модели. В России работает около 1 млн. ИТ-специалистов, но дефицит кадров, по оценкам Минцифры, всё еще составляет 500-700 тыс. человек. Параллельно растет рынок ИТ-аутсорсинга: в 2024 году его оборот достиг 262 млрд. руб., рост на 24% к предыдущему году. Согласно исследованию CNews Research, более 72% компаний с цифровыми продуктами привлекают внешних разработчиков хотя бы на одном из этапов жизненного цикла проекта. Вопрос «нанять своего или взять подрядчика» остается одним из самых частых у малого и среднего бизнеса. Однозначного ответа нет, но есть конкретные критерии, которые помогают сделать выбор. Экономика вопроса: сколько стоит собственный разработчик По данным «Хабр Карьеры», в первой половине 2025 года медианная зарплата ИТ-специалиста в России составила 191 тыс. руб./мес — на 4% больше, чем во втором полугодии 2025 года. В Москве этот показатель уже 235 тыс. руб./мес. К зарплате прибавляются страховые взносы (15-30% сверху в зависимости от статуса компании), оборудованное рабочее место, лицензии на ПО, корпоративное обучение, время HR на поиск и онбординг. Реальная нагрузка на бизнес примерно на 30-40% выше окладной части. Мидл-разработчик в Москве обходится компании в 270-350 тыс. руб./мес, а годовой бюджет на одного специалиста стартует от 3,2 млн. руб. Сравним с аутсорсом. Час работы мидла в агентстве — 3-5 тыс. руб., у проверенного фрилансера — 2-3 тыс. руб. На бюджет одного штатного разработчика можно купить 800-1200 часов внешней разработки в год. Этого хватает почти любому бизнесу, который не строит вокруг сайта основной продукт. Рынок поменялся: ситуация в 2026 году Картина в ИТ-найме за последние два года резко изменилась. По данным hh.ru и «РБК Трендов», количество вакансий в ИТ просело примерно на 20%, а активных резюме стало больше на четверть. На одну вакансию сейчас приходится 12-15 кандидатов. Однако нанимать стало не проще. Дефицит сместился в сторону точечной экспертизы: архитекторы, специалисты по информационной безопасности, инженеры данных, DevOps. Мидлы и сеньоры с конкретным сочетанием технологий по-прежнему уходят с рынка за 1-2 недели. Зарплатные ожидания продолжают расти: за год средняя по веб-разработке поднялась на 10-15%. Для бизнеса это означает простую вещь: окно «найму своего, пока недорого» закрылось. Экономика инхауса работает только при стабильной загрузке. Когда инхаус оправдан Свой разработчик окупается в четырех сценариях. 	Постоянный поток задач. Если на сайте каждый день что-то меняется — тесты гипотез, новые лендинги, доработки личного кабинета, интеграции с маркетплейсами — внешний подрядчик тормозит процессы. 	Глубокая связка с бизнес-логикой. Кастомные системы управления взаимоотношениями с клиентами (CRM), ERP, нестандартные процессы обработки заказов требуют погружения в специфику. Подрядчик, который параллельно ведет десяток клиентов, не удержит в голове все нюансы. 	Чувствительные данные и безопасность. Когда сайт обрабатывает персональные или финансовые данные, важна предсказуемость доступов и зон ответственности. 	Сайт как продукт. Если приложение или платформа — ядро бизнеса, отдавать их разработку наружу стратегически рискованно. Когда выгоднее аутсорс Большинству небольших и средних компаний штатный разработчик не нужен. Аутсорс выигрывает, когда: 	 сайт меняется редко: раз в месяц-два появляется новая страница, баннер или акция; 	 нужны специфические компетенции на короткий срок — например, разработка мобильного приложения или интеграция со специфической платежной системой; 	 бизнес сезонный: летом нагрузка одна, зимой другая, и держать постоянного разработчика нерационально; 	 стартап проверяет гипотезы, и пока непонятно, какой технический стек нужен в долгую. У многих небольших интернет-магазинов нет ни одного разработчика в штате — и при этом их сайты работают годами. Гибрид — самый частый сценарий Чаще всего выстраивается гибридная модель. У бизнеса есть один технический специалист уровня тимлида или продакт-менеджера, а основная разработка идет на стороне. Этот человек знает бизнес и продукт изнутри. Управляет подрядчиками, ставит задачи, принимает работу. Закрывает срочные инциденты: отвалилась форма заказа, упала страница, нужно за час добавить виджет под акцию. Гибрид закрывает главную слабость аутсорса — отсутствие человека, который держит в голове всю картину. И не требует найма команды из трех-пяти разработчиков. На что смотреть при выборе подрядчика Перед подписанием договора стоит проверить четыре вещи. 	Регламент реагирования на инциденты. Узнайте, что произойдет, если сайт упадет в субботу вечером. У хорошего подрядчика прописаны SLA с конкретными временами реакции. У плохого — общие слова про «оперативное решение». 	Доступы и документация. Код, доступы к хостингу, репозитории, базы данных принадлежат вам, а не подрядчику. Регулярно видим истории, где владелец бизнеса не может попасть на собственный сайт, потому что всем владеет агентство, с которым испортились отношения. 	Передача дел. Что произойдет, если решите сменить подрядчика? Хорошая команда умеет передавать проекты и не пытается удерживать клиента собственной незаменимостью. 	Прозрачность отчетности. Часы, задачи, статусы видны заказчику. Любая модель «доверьтесь нам, мы всё сделаем» в долгосрочной перспективе превращается в проблему. Как принять решение: три вопроса самому себе Сколько часов разработки реально нужно в месяц? 	Меньше 60-80 — аутсорс. Стабильно больше 120-160 — пора думать про штат. Насколько уникален продукт? Сайт-визитка, типовой интернет-магазин на готовом движке, корпоративный портал на коробочном решении — аутсорс. Сложный сервис с собственной бизнес-логикой — инхаус или гибрид. Готовы быть работодателем для разработчика? 	Если в команде нет человека, который понимает в разработке хотя бы на уровне тимлида, штатный сотрудник быстро превращается в черный ящик: непонятно, как его оценивать, что он делает и за что ему платить. Главная ошибка, которую мы видим в малом и среднем бизнесе — найм разработчика «на вырост». Компания берет человека в расчете на будущие задачи, но будущее не наступает, специалист недозагружен, а 3 млн. руб. в год продолжают уходить с расчетного счета. Простая проверка: если реальный объем задач занимает меньше 70% рабочего времени разработчика, штат не окупится. Считайте не зарплату, а часовую ставку и фактический объем работы, и берите подрядчика, пока стабильная загрузка не подтвердилась цифрами хотя бы за полгода. #IMAGE_235452#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Обсудим, п&lltt;/em&ggtt;&lltt;em&ggtt;очему в&nbsp;2026 году чистый инхаус всё чаще проигрывает гибридной модели&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;России &lltt;a href="https://www.interfax.ru/russia/1028484"&ggtt;работает&lltt;/a&ggtt; около 1&nbsp;млн. ИТ-специалистов, но&nbsp;дефицит кадров, по&nbsp;оценкам Минцифры, всё еще составляет &lltt;nobr&ggtt;500-700 тыс.&lltt;/nobr&ggtt; человек. Параллельно растет&lltt;a href="https://marketing.rbc.ru/research/52099/"&ggtt; рынок ИТ-аутсорсинга&lltt;/a&ggtt;: в&nbsp;2024 году его оборот достиг 262&nbsp;млрд. руб., рост на&nbsp;24% к&nbsp;предыдущему году. Согласно исследованию CNews Research, &lltt;a href="https://codingteam.ru/blog/autsorsing-razrabotchikov-v-2025-kogda-vigodnee-na"&ggtt;более&nbsp;72% компаний&lltt;/a&ggtt; с&nbsp;цифровыми продуктами привлекают внешних разработчиков хотя&nbsp;бы на&nbsp;одном из&nbsp;этапов жизненного цикла проекта. Вопрос «нанять своего или взять подрядчика» остается одним из&nbsp;самых частых у&nbsp;малого и&nbsp;среднего бизнеса. Однозначного ответа нет, но&nbsp;есть конкретные критерии, которые помогают сделать выбор.&lltt;/p&ggtt;
&lltt;h3&ggtt;Экономика вопроса: сколько стоит собственный разработчик&lltt;/h3&ggtt;
&lltt;p&ggtt;По&nbsp;данным &lltt;a href="https://habr.com/ru/specials/1060148/"&ggtt;«Хабр Карьеры»&lltt;/a&ggtt;, в&nbsp;первой половине 2025 года медианная зарплата ИТ-специалиста в&nbsp;России составила 191&nbsp;тыс. руб./мес&nbsp;— на&nbsp;4% больше, чем во&nbsp;втором полугодии 2025&nbsp;года. В&nbsp;Москве этот показатель уже 235&nbsp;тыс. руб./мес.&lltt;/p&ggtt;
&lltt;p&ggtt;К&nbsp;зарплате прибавляются страховые взносы &lltt;nobr&ggtt;(15-30%&lltt;/nobr&ggtt; сверху в&nbsp;зависимости от&nbsp;статуса компании), оборудованное рабочее место, лицензии на&nbsp;ПО, корпоративное обучение, время&nbsp;HR на&nbsp;поиск и&nbsp;онбординг. Реальная нагрузка на&nbsp;бизнес примерно на&nbsp;&lltt;nobr&ggtt;30-40%&lltt;/nobr&ggtt; выше окладной части. Мидл-разработчик в&nbsp;Москве обходится компании в&nbsp;&lltt;nobr&ggtt;270-350 тыс.&lltt;/nobr&ggtt; руб./мес, а&nbsp;годовой бюджет на&nbsp;одного специалиста стартует от&nbsp;3,2&nbsp;млн. руб.&lltt;/p&ggtt;
&lltt;p&ggtt;Сравним с&nbsp;аутсорсом. Час работы мидла в&nbsp;агентстве&nbsp;— &lltt;nobr&ggtt;3-5 тыс.&lltt;/nobr&ggtt; руб., у&nbsp;проверенного фрилансера&nbsp;— &lltt;nobr&ggtt;2-3 тыс.&lltt;/nobr&ggtt; руб. На&nbsp;бюджет одного штатного разработчика можно купить &lltt;nobr&ggtt;800-1200&lltt;/nobr&ggtt; часов внешней разработки в&nbsp;год. Этого хватает почти любому бизнесу, который не&nbsp;строит вокруг сайта основной продукт.&lltt;/p&ggtt;
&lltt;h3&ggtt;Рынок поменялся: ситуация в&nbsp;2026 году&lltt;/h3&ggtt;
&lltt;p&ggtt;Картина в&nbsp;ИТ-найме за&nbsp;последние два года резко изменилась. По&nbsp;данным &lltt;a href="https://trends.rbc.ru/trends/social/cmrm/698da33a9a79474de4341261"&ggtt;hh.ru и&nbsp;«РБК Трендов»&lltt;/a&ggtt;, количество вакансий в&nbsp;ИТ просело примерно на&nbsp;20%, а&nbsp;активных резюме стало больше на&nbsp;четверть. На&nbsp;одну вакансию сейчас приходится &lltt;nobr&ggtt;12-15 кандидатов.&lltt;/nobr&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Однако нанимать стало не&nbsp;проще. Дефицит сместился в&nbsp;сторону точечной экспертизы: архитекторы, специалисты по&nbsp;информационной безопасности, инженеры данных, DevOps. Мидлы и&nbsp;сеньоры с&nbsp;конкретным сочетанием технологий по-прежнему уходят с&nbsp;рынка за&nbsp;&lltt;nobr&ggtt;1-2 недели.&lltt;/nobr&ggtt; Зарплатные ожидания продолжают расти: за&nbsp;год средняя по&nbsp;веб-разработке поднялась на&nbsp;&lltt;nobr&ggtt;10-15%.&lltt;/nobr&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Для бизнеса это означает простую вещь: окно «найму своего, пока недорого» закрылось. Экономика инхауса работает только при стабильной загрузке.&lltt;/p&ggtt;
&lltt;h3&ggtt;Когда инхаус оправдан&lltt;/h3&ggtt;
&lltt;p&ggtt;Свой разработчик окупается в&nbsp;четырех сценариях.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Постоянный поток задач.&lltt;/strong&ggtt; Если на&nbsp;сайте каждый день что-то меняется&nbsp;— тесты гипотез, новые лендинги, доработки личного кабинета, интеграции с&nbsp;маркетплейсами&nbsp;— внешний подрядчик тормозит процессы.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Глубокая связка с&nbsp;бизнес-логикой.&lltt;/strong&ggtt; Кастомные системы управления взаимоотношениями с&nbsp;клиентами (CRM), ERP, нестандартные процессы обработки заказов требуют погружения в&nbsp;специфику. Подрядчик, который параллельно ведет десяток клиентов, не&nbsp;удержит в&nbsp;голове все нюансы.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Чувствительные данные и&nbsp;безопасность.&lltt;/strong&ggtt; Когда сайт обрабатывает персональные или финансовые данные, важна предсказуемость доступов и&nbsp;зон ответственности.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Сайт как продукт.&lltt;/strong&ggtt; Если приложение или платформа&nbsp;— ядро бизнеса, отдавать их&nbsp;разработку наружу стратегически рискованно.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Когда выгоднее аутсорс&lltt;/h3&ggtt;
&lltt;p&ggtt;Большинству небольших и&nbsp;средних компаний штатный разработчик не&nbsp;нужен. Аутсорс выигрывает, когда:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; сайт меняется редко: раз в&nbsp;месяц-два появляется новая страница, баннер или акция;&lltt;/li&ggtt;
	&lltt;li&ggtt; нужны специфические компетенции на&nbsp;короткий срок&nbsp;— например, разработка мобильного приложения или интеграция со&nbsp;специфической платежной системой;&lltt;/li&ggtt;
	&lltt;li&ggtt; бизнес сезонный: летом нагрузка одна, зимой другая, и&nbsp;держать постоянного разработчика нерационально;&lltt;/li&ggtt;
	&lltt;li&ggtt; стартап проверяет гипотезы, и&nbsp;пока непонятно, какой технический стек нужен в&nbsp;долгую.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;У&nbsp;многих небольших интернет-магазинов нет ни&nbsp;одного разработчика в&nbsp;штате&nbsp;— и&nbsp;при этом их&nbsp;сайты работают годами.&lltt;/p&ggtt;
&lltt;h3&ggtt;Гибрид&nbsp;— самый частый сценарий&lltt;/h3&ggtt;
&lltt;p&ggtt;Чаще всего выстраивается гибридная модель. У&nbsp;бизнеса есть один технический специалист уровня тимлида или продакт-менеджера, а&nbsp;основная разработка идет на&nbsp;стороне.&lltt;/p&ggtt;
&lltt;p&ggtt;Этот человек знает бизнес и&nbsp;продукт изнутри. Управляет подрядчиками, ставит задачи, принимает работу. Закрывает срочные инциденты: отвалилась форма заказа, упала страница, нужно за&nbsp;час добавить виджет под акцию.&lltt;/p&ggtt;
&lltt;p&ggtt;Гибрид закрывает главную слабость аутсорса&nbsp;— отсутствие человека, который держит в&nbsp;голове всю картину. И&nbsp;не&nbsp;требует найма команды из&nbsp;трех-пяти разработчиков.&lltt;/p&ggtt;
&lltt;h3&ggtt;На&nbsp;что смотреть при выборе подрядчика&lltt;/h3&ggtt;
&lltt;p&ggtt;Перед подписанием договора стоит проверить четыре вещи.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Регламент реагирования на&nbsp;инциденты.&lltt;/strong&ggtt; Узнайте, что произойдет, если сайт упадет в&nbsp;субботу вечером. У&nbsp;хорошего подрядчика прописаны SLA с&nbsp;конкретными временами реакции. У&nbsp;плохого&nbsp;— общие слова про «оперативное решение».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Доступы и&nbsp;документация.&lltt;/strong&ggtt; Код, доступы к&nbsp;хостингу, репозитории, базы данных принадлежат вам, а&nbsp;не&nbsp;подрядчику. Регулярно видим истории, где владелец бизнеса не&nbsp;может попасть на&nbsp;собственный сайт, потому что всем владеет агентство, с&nbsp;которым испортились отношения.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Передача дел.&lltt;/strong&ggtt; Что произойдет, если решите сменить подрядчика? Хорошая команда умеет передавать проекты и&nbsp;не&nbsp;пытается удерживать клиента собственной незаменимостью.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Прозрачность отчетности.&lltt;/strong&ggtt; Часы, задачи, статусы видны заказчику. Любая модель «доверьтесь нам, мы&nbsp;всё сделаем» в&nbsp;долгосрочной перспективе превращается в&nbsp;проблему.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Как принять решение: три вопроса самому себе&lltt;/h3&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Сколько часов разработки реально нужно в&nbsp;месяц?&lltt;br/&ggtt;
	&lltt;/strong&ggtt;Меньше &lltt;nobr&ggtt;60-80 —&lltt;/nobr&ggtt; аутсорс. Стабильно больше &lltt;nobr&ggtt;120-160 —&lltt;/nobr&ggtt; пора думать про штат. 
&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Насколько уникален продукт?&lltt;/strong&ggtt;&lltt;br/&ggtt;
Сайт-визитка, типовой интернет-магазин на&nbsp;готовом движке, корпоративный портал на&nbsp;коробочном решении&nbsp;— аутсорс. Сложный сервис с&nbsp;собственной бизнес-логикой&nbsp;— инхаус или гибрид. 
&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Готовы быть работодателем для разработчика?&lltt;br/&ggtt;
	&lltt;/strong&ggtt;Если в&nbsp;команде нет человека, который понимает в&nbsp;разработке хотя&nbsp;бы на&nbsp;уровне тимлида, штатный сотрудник быстро превращается в&nbsp;черный ящик: непонятно, как его оценивать, что он&nbsp;делает и&nbsp;за&nbsp;что ему платить. 
&lltt;/p&ggtt;
&lltt;p&ggtt;Главная ошибка, которую мы&nbsp;видим в&nbsp;малом и&nbsp;среднем бизнесе&nbsp;— найм разработчика «на&nbsp;вырост». Компания берет человека в&nbsp;расчете на&nbsp;будущие задачи, но&nbsp;будущее не&nbsp;наступает, специалист недозагружен, а&nbsp;3&nbsp;млн. руб.&nbsp;в&nbsp;год продолжают уходить с&nbsp;расчетного счета. Простая проверка: если реальный объем задач занимает меньше&nbsp;70% рабочего времени разработчика, штат не&nbsp;окупится. Считайте не&nbsp;зарплату, а&nbsp;часовую ставку и&nbsp;фактический объем работы, и&nbsp;берите подрядчика, пока стабильная загрузка не&nbsp;подтвердилась цифрами хотя&nbsp;бы за&nbsp;полгода.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235452#&lltt;/p&ggtt;]]></source>
<adate>03.09.2026</adate>
<dbid>235451</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/718/h8wkbedlzc03z2nd21veu1017no1d3do.jpg]]>
</images>
<imagesname><![CDATA[;;Алексей Солдатов, руководитель технической поддержки SpaceWeb   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[&#8221;Не могу остановиться&#8221;: 80% разработчиков считают, что ИИ-кодирование скорее засасывает, чем помогает]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235453]]></link>
<description><![CDATA[Опрос разработчиков, проведенный компанией Coddy, показал, что программирование с помощью искусственного интеллекта приводит к новому виду эмоционального выгорания, сообщает портал ZDNet. Наверное, в этом нет ничего неожиданного. Благодаря GitHub Copilot, Claude Code, Cursor и любого другого нового ИИ-инструмента для разработчиков, вы как программист можете выполнять больше работы, чем когда-либо прежде. Но даже несмотря на то, что разработчики все чаще используют их для создания шаблонов, объяснения незнакомого кода, составления тестов, рефакторинга модулей и устранения неполадок, многие из них также обнаруживают, что те же самые инструменты могут вызывать проблемы. Трудоголизм, вызванный ИИ «Сейчас 2:47 ночи... Я не устраняю сбой. Крайнего срока нет. Я просто наблюдаю, как Claude Code проводит рефакторинг модуля... и я не могу отвести взгляд», — пишет в своем посте в LinkedIn Квентин Руссо, технический директор и соучредитель компании Rootly, занимающейся отчетами об инцидентах на основе ИИ. Почему так происходит? Потому что, продолжает он, «агентное кодирование вызывает привыкание. Когда агент делает все правильно, ты получаешь дофаминовый заряд. Когда это не удается, ты испытываешь прилив адреналина». Руссо признается, что не мог спать и был вынужден обратиться за медицинской помощью. В этом нет ничего удивительного. Программисты уже давно склонны к трудоголизму. Однако ИИ придал работе новый темп, когда, как выразился Руссо, «наблюдение за работой агента достаточно пассивно, чтобы не чувствовать усталости, и достаточно активно, чтобы держать вас на крючке». В результате возникает новый вид эмоционального выгорания. Это не просто опыт одного программиста. ИИ-кодирование может превратить разработку ПО в непрерывный цикл обратной связи. Вместо того, чтобы завершить задачу и отвлечься, разработчики могут постоянно просить агента о другой реализации, переписывании, оптимизации или рефакторинге, или сочетать это с беспокойством о том, что остановка означает невыполнение работы. Когда ИИ становится не помощником, а кандалами Компания Coddy Tech, занимающаяся обучением программированию, в ходе опроса 305 разработчиков выяснила, что для 80% из них использование ИИ больше похоже на зависимость, чем на преимущество. Конечно, они находят эти инструменты полезными, но они также обеспокоены тем, что возникновение привычки зависеть от ИИ ослабляет их собственные возможности решения проблем, увеличивает их рабочую нагрузку и формирует нездоровые отношения с работой. Согласно отчету, 43% респондентов продолжают программировать с помощью ИИ в нерабочее время, даже когда они собирались остановиться, а 32% откладывают сон, чтобы продолжить работу. Кроме того, 39% опрошенных отмечают, что инструменты ИИ усложняют возможность отключиться от рабочего процесса. Дело не только в том, что инструменты ИИ вызывают привыкание. 74% разработчиков сообщают, что интенсивное использование ИИ увеличивает вероятность повышения зарплаты или продвижения по службе. Однако 51% также заявляют, что у них стало больше шансов перегореть. Доверяй, но проверяй: ИИ не безупречен Как показал опрос Stack Overflow «2025 Developer Survey», 45% респондентов разочарованы ответами ИИ, которые могут быть «почти правильными, но не совсем». В результате вывод выглядит убедительно, но приводит к сложной работы по отладке. Исследование Stack Overflow также показало, что, хотя внедрение инструментов ИИ продолжает расти и в настоящее время 80% разработчиков используют их в своих рабочих процессах, доверие к точности ИИ упало с 40% в предыдущие годы до всего лишь 29% в этом году. В результате положительное отношение программистов к ИИ за год снизилось с 72 до 60%. С одной стороны, повышается удобство использования, с другой — растет рабочая нагрузка разработчика. Помимо попыток понять, насколько правильно угадал ИИ, они должны понимать требования, распознавать конфликты сгенерированного кода с архитектурой системы, тестировать крайние случаи, устранять риски безопасности и нести ответственность за последствия в производственной среде. Это создает «долг верификации». Результат появляется быстро, но вы все равно вынуждены устанавливать, является ли он правильным, безопасным, поддерживаемым и подходящим для конкретной кодовой базы. Кроме того, зависимость, описанная в исследовании Coddy, может быть усилена тем, как работодатели интерпретируют результаты, полученные с помощью ИИ. Если организация рассматривает ИИ как способ увеличить возможности разработчиков, сотрудники могут столкнуться с необходимостью предоставлять больше функций, закрывать больше заявок и выполнять больше проверок за то же количество часов. Это, в свою очередь, может привести к тому, что время, сэкономленное на отдельных задачах по кодированию, будет перенаправлено на другие задачи: больше запросов на слияние, больше сгенерированных изменений для проверки, больше зависимостей для проверки и больше операционных рисков для управления. Таким образом, ИИ-кодирование становится вопросом баланса работы и отдыха в не меньшей степени, чем вопрос применения ИИ-инструментов. Команды, которые используют агентов для устранения рутинного труда, могут увидеть реальные преимущества. Команды, которые используют их для ускорения каждого этапа разработки ПО, рискуют создать более быструю и безжалостную версию той же работы. Для разработчиков, таких как Руссо, проблема уже не только в том, может ли ИИ писать код. Он может. Вопрос теперь заключается в том, могут ли разработчики по-прежнему решать, когда заканчивается их рабочий день и цикл работы агента]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Опрос разработчиков, проведенный компанией Coddy, &lltt;/em&ggtt;&lltt;a href="https://coddy.tech/blog/coding-for-beginners/ai-coding-addiction-report"&ggtt;&lltt;em&ggtt;показал&lltt;/em&ggtt;&lltt;/a&ggtt;&lltt;em&ggtt;, что программирование с помощью искусственного интеллекта приводит к новому виду эмоционального выгорания, сообщает портал &lltt;/em&ggtt;&lltt;em&ggtt;ZDNet&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Наверное, в этом нет ничего неожиданного. Благодаря GitHub Copilot, Claude Code, Cursor и любого другого нового ИИ-инструмента для разработчиков, вы как программист можете выполнять больше работы, чем когда-либо прежде. Но даже несмотря на то, что разработчики все чаще используют их для создания шаблонов, объяснения незнакомого кода, составления тестов, рефакторинга модулей и устранения неполадок, многие из них также обнаруживают, что те же самые инструменты могут вызывать проблемы.&lltt;/p&ggtt;
&lltt;h3&ggtt;Трудоголизм, вызванный ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;«Сейчас 2:47 ночи... Я не устраняю сбой. Крайнего срока нет. Я просто наблюдаю, как Claude Code проводит рефакторинг модуля... и я не могу отвести взгляд», — пишет в своем посте в LinkedIn Квентин Руссо, технический директор и соучредитель компании Rootly, занимающейся отчетами об инцидентах на основе ИИ. Почему так происходит? Потому что, продолжает он, «агентное кодирование вызывает привыкание. Когда агент делает все правильно, ты получаешь дофаминовый заряд. Когда это не удается, ты испытываешь прилив адреналина». Руссо признается, что не мог спать и был вынужден обратиться за медицинской помощью.&lltt;/p&ggtt;
&lltt;p&ggtt;В этом нет ничего удивительного. Программисты уже давно склонны к трудоголизму. Однако ИИ придал работе новый темп, когда, как выразился Руссо, «наблюдение за работой агента достаточно пассивно, чтобы не чувствовать усталости, и достаточно активно, чтобы держать вас на крючке». В результате возникает новый вид эмоционального выгорания.&lltt;/p&ggtt;
&lltt;p&ggtt;Это не просто опыт одного программиста. ИИ-кодирование может превратить разработку ПО в непрерывный цикл обратной связи. Вместо того, чтобы завершить задачу и отвлечься, разработчики могут постоянно просить агента о другой реализации, переписывании, оптимизации или рефакторинге, или сочетать это с беспокойством о том, что остановка означает невыполнение работы.&lltt;/p&ggtt;
&lltt;h3&ggtt;Когда ИИ становится не помощником, а кандалами&lltt;/h3&ggtt;
&lltt;p&ggtt;Компания Coddy Tech, занимающаяся обучением программированию, в ходе опроса 305 разработчиков выяснила, что для 80% из них использование ИИ больше похоже на зависимость, чем на преимущество. Конечно, они находят эти инструменты полезными, но они также обеспокоены тем, что возникновение привычки зависеть от ИИ ослабляет их собственные возможности решения проблем, увеличивает их рабочую нагрузку и формирует нездоровые отношения с работой.&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно отчету, 43% респондентов продолжают программировать с помощью ИИ в нерабочее время, даже когда они собирались остановиться, а 32% откладывают сон, чтобы продолжить работу. Кроме того, 39% опрошенных отмечают, что инструменты ИИ усложняют возможность отключиться от рабочего процесса.&lltt;/p&ggtt;
&lltt;p&ggtt;Дело не только в том, что инструменты ИИ вызывают привыкание. 74% разработчиков сообщают, что интенсивное использование ИИ увеличивает вероятность повышения зарплаты или продвижения по службе. Однако 51% также заявляют, что у них стало больше шансов перегореть.&lltt;/p&ggtt;
&lltt;h3&ggtt;Доверяй, но проверяй: ИИ не безупречен&lltt;/h3&ggtt;
&lltt;p&ggtt;Как показал опрос Stack Overflow «2025 Developer Survey», 45% респондентов разочарованы ответами ИИ, которые могут быть «почти правильными, но не совсем». В результате вывод выглядит убедительно, но приводит к сложной работы по отладке.&lltt;/p&ggtt;
&lltt;p&ggtt;Исследование Stack Overflow также показало, что, хотя внедрение инструментов ИИ продолжает расти и в настоящее время 80% разработчиков используют их в своих рабочих процессах, доверие к точности ИИ упало с 40% в предыдущие годы до всего лишь 29% в этом году. В результате положительное отношение программистов к ИИ за год снизилось с 72 до 60%.&lltt;/p&ggtt;
&lltt;p&ggtt;С одной стороны, повышается удобство использования, с другой — растет рабочая нагрузка разработчика. Помимо попыток понять, насколько правильно угадал ИИ, они должны понимать требования, распознавать конфликты сгенерированного кода с архитектурой системы, тестировать крайние случаи, устранять риски безопасности и нести ответственность за последствия в производственной среде.&lltt;/p&ggtt;
&lltt;p&ggtt;Это создает «долг верификации». Результат появляется быстро, но вы все равно вынуждены устанавливать, является ли он правильным, безопасным, поддерживаемым и подходящим для конкретной кодовой базы.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме того, зависимость, описанная в исследовании Coddy, может быть усилена тем, как работодатели интерпретируют результаты, полученные с помощью ИИ. Если организация рассматривает ИИ как способ увеличить возможности разработчиков, сотрудники могут столкнуться с необходимостью предоставлять больше функций, закрывать больше заявок и выполнять больше проверок за то же количество часов.&lltt;/p&ggtt;
&lltt;p&ggtt;Это, в свою очередь, может привести к тому, что время, сэкономленное на отдельных задачах по кодированию, будет перенаправлено на другие задачи: больше запросов на слияние, больше сгенерированных изменений для проверки, больше зависимостей для проверки и больше операционных рисков для управления.&lltt;/p&ggtt;
&lltt;p&ggtt;Таким образом, ИИ-кодирование становится вопросом баланса работы и отдыха в не меньшей степени, чем вопрос применения ИИ-инструментов. Команды, которые используют агентов для устранения рутинного труда, могут увидеть реальные преимущества. Команды, которые используют их для ускорения каждого этапа разработки ПО, рискуют создать более быструю и безжалостную версию той же работы.&lltt;/p&ggtt;
&lltt;p&ggtt;Для разработчиков, таких как Руссо, проблема уже не только в том, может ли ИИ писать код. Он может. Вопрос теперь заключается в том, могут ли разработчики по-прежнему решать, когда заканчивается их рабочий день и цикл работы агента.&lltt;/p&ggtt;]]></source>
<adate>03.09.2026</adate>
<dbid>235453</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Yandex B2B Tech представила новый формат частных облаков для компаний]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235449]]></link>
<description><![CDATA[Yandex B2B Tech запустила Yandex BareMetal Extend — решение, с помощью которого компании могут получить готовую инфраструктуру на выделенных серверах без закупки и поддержки дорогостоящего оборудования. В отличие от классических частных облаков, в новом решении инфраструктура заказчика физически отделена от публичного облака. Yandex BareMetal Extend позволит бизнесу сохранять повышенный контроль над инфраструктурой, но при этом не потерять гибкость и скорость разработки. Уже сейчас можно оставить заявку на сайте и получить консультацию. Yandex BareMetal Extend — это не классическое решение по аренде «железа». В нем есть три заранее преднастроенных модуля: виртуализация, Kubernetes® и платформа для разработки приложений Stackland. В зависимости от задач компания может выбрать один из них и развернуть на выделенных серверах контейнерные приложения или критичные бизнес-системы. ИТ-командам компаний не придется самостоятельно поддерживать виртуальные мощности. По данным Atlassian DX Report, 50% разработчиков теряют более 10 часов в неделю на непрофильную работу. Партнером по разработке решения с виртуализацией стал облачный провайдер с экспертизой интегратора K2 Cloud. Совместно со специалистами Yandex Cloud компания будет оказывать техническую поддержку клиентам в формате единого окна. «Крупным компаниям важно одновременно соблюдать требования информационной безопасности и сокращать время на запуск ИТ-систем. В Yandex BareMetal Extend клиент получает выделенную инфраструктуру с уже настроенной средой, поэтому команде не нужно самостоятельно собирать и поддерживать её из отдельных компонентов. Мы отдаём клиенту не набор компонентов для самостоятельной сборки, а среду, готовую к работе с первого дня аренды», — рассказал Иван Пузыревский, технический директор платформы Yandex Cloud. «У K2 Cloud большой опыт создания изолированной программной среды для крупного бизнеса — с соответствием требований ИБ, аттестациями и строгими SLA. Мы объединили нашу экспертизу с технологиями Yandex Cloud и получили уникальное решение. Заказчики получат готовую изолированную инфраструктуру с управлением виртуальными ресурсами из единого интерфейса под критичные системы», — отметил Сергей Зинкевич, CEO K2 Cloud. Yandex BareMetal соответствует первому уровню защищённости персональных данных и обеспечивает защиту на уровнях ЦОД, сети и сервиса. Клиенты также могут резервировать ресурсы и объединять инфраструктуру на выделенных серверах с помощью приватного соединения]]></description>
<source><![CDATA[&lltt;p&ggtt;Yandex B2B Tech запустила Yandex BareMetal Extend — решение, с помощью которого компании могут получить готовую инфраструктуру на выделенных серверах без закупки и поддержки дорогостоящего оборудования. В отличие от классических частных облаков, в новом решении инфраструктура заказчика физически отделена от публичного облака. Yandex BareMetal Extend позволит бизнесу сохранять повышенный контроль над инфраструктурой, но при этом не потерять гибкость и скорость разработки. Уже сейчас можно оставить заявку на сайте и получить консультацию.&lltt;/p&ggtt;
&lltt;p&ggtt;Yandex BareMetal Extend — это не классическое решение по аренде «железа». В нем есть три заранее преднастроенных модуля: виртуализация, Kubernetes&lltt;sup class="reg"&ggtt;®&lltt;/sup&ggtt; и платформа для разработки приложений Stackland. В зависимости от задач компания может выбрать один из них и развернуть на выделенных серверах контейнерные приложения или критичные бизнес-системы. ИТ-командам компаний не придется самостоятельно поддерживать виртуальные мощности. По данным Atlassian DX Report, 50% разработчиков теряют более 10 часов в неделю на непрофильную работу. &lltt;/p&ggtt;
&lltt;p&ggtt;Партнером по разработке решения с виртуализацией стал облачный провайдер с экспертизой интегратора K2 Cloud. Совместно со специалистами Yandex Cloud компания будет оказывать техническую поддержку клиентам в формате единого окна. &lltt;/p&ggtt;
&lltt;p&ggtt;«Крупным компаниям важно одновременно соблюдать требования информационной безопасности и сокращать время на запуск ИТ-систем. В Yandex BareMetal Extend клиент получает выделенную инфраструктуру с уже настроенной средой, поэтому команде не нужно самостоятельно собирать и поддерживать её из отдельных компонентов. Мы отдаём клиенту не набор компонентов для самостоятельной сборки, а среду, готовую к работе с первого дня аренды», — рассказал Иван Пузыревский, технический директор платформы Yandex Cloud.&lltt;/p&ggtt;
&lltt;p&ggtt;«У K2 Cloud большой опыт создания изолированной программной среды для крупного бизнеса — с соответствием требований ИБ, аттестациями и строгими SLA. Мы объединили нашу экспертизу с технологиями Yandex Cloud и получили уникальное решение. Заказчики получат готовую изолированную инфраструктуру с управлением виртуальными ресурсами из единого интерфейса под критичные системы», — отметил Сергей Зинкевич, CEO K2 Cloud.&lltt;/p&ggtt;
&lltt;p&ggtt;Yandex BareMetal соответствует первому уровню защищённости персональных данных и обеспечивает защиту на уровнях ЦОД, сети и сервиса. Клиенты также могут резервировать ресурсы и объединять инфраструктуру на выделенных серверах с помощью приватного соединения.&lltt;/p&ggtt;]]></source>
<adate>02.09.2026</adate>
<dbid>235449</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[Когда атакует машина: как генеративный ИИ переписал правила кибервойны]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235444]]></link>
<description><![CDATA[За тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но ни один из них не менял расстановку сил так быстро, как генеративный ИИ. Раньше между появлением нового класса атак и его массовым применением проходили годы: злоумышленникам нужно было время, квалификация и инфраструктура. Сегодня этот барьер обрушился. Написать фишинговое письмо на безупречном русском, собрать досье на жертву, сгенерировать вариант вредоносного кода, обходящий сигнатурный детектор, — всё это стало доступно человеку без глубокой технической подготовки и занимает минуты, а не недели. Рассмотрим, как эволюционировали методы кибератак с появлением ИИ. Масштаб перемен уже поддаётся измерению. По данным отчёта Bugcrowd Inside the Mind of a Hacker, к концу 2025 года 82% исследователей (в том числе действующих не по правилам; против 64% в 2023-м) применяли ИИ в своей работе. Искусственный интеллект перестал быть экзотикой в арсенале атакующего и стал рабочим инструментом по умолчанию. Эволюцию «наступательного» ИИ удобно разложить на три волны, которые не сменяют, а наслаиваются друг на друга. Три этапа взросления атакующих нейросетей Первая волна — автоматизация рутины. Здесь ИИ не принимает решений, а масштабирует то, что человек и так делал руками: генерирует тексты фишинга, переводит их на десятки языков без характерных ошибок, пишет шаблоны, парсит открытые источники. Это уже полностью реальность и массовая практика. Стоимость подготовки убедительной атаки упала на порядок, а качество — выросло. Вторая волна — ассистирование в сложных задачах. ИИ становится «вторым пилотом» атакующего: помогает разобраться в незнакомом коде, предлагает варианты эксплуатации уязвимости, адаптирует полезную нагрузку под конкретное окружение, ведёт разведку и приоритизирует цели. Решение по-прежнему за человеком, но скорость и охват растут кратно. Именно на этом этапе мы находимся сейчас. Третья волна — автономное принятие решений. Это агентные системы, которые получают цель («получить доступ к сегменту сети») и самостоятельно строят цепочку действий: разведка → выбор вектора → эксплуатация → закрепление → латеральное перемещение, реагируя на обратную связь от среды без участия оператора. Полноценных автономных атакующих агентов «в дикой природе» пока единицы, и они несовершенны, но направление обозначено предельно чётко. Именно к этому сценарию защиты нужно готовиться уже сегодня, а не когда он станет мейнстримом. Что случилось с классическими векторами Важно понимать: генеративный ИИ не создал новых классов атак. Фишинг, социальная инженерия и вредоносное ПО были и двадцать лет назад. ИИ изменил их экономику и качество. 	Фишинг. Раньше защитой служили сами письма: корявый язык, нелепые обращения, кривая верстка — «маркеры мошенника», которым учили сотрудников. Генеративные модели эти маркеры стёрли. Показателен рубеж, зафиксированный в сети детектирования Hoxhunt: несколько лет доля писем с признаками ИИ-генерации держалась ниже 5%, а в декабре 2025 года подскочила примерно в 14 раз — до 56% всех выявленных атак. Изменилась и экономика: по оценкам, приводимым в индустриальных отчётах, LLM сократили время подготовки убедительной кампании с примерно 16 часов ручной работы до нескольких минут, а затраты на массовую рассылку упали примерно на 95%. Письмо теперь грамотное, персонализированное под должность и контекст получателя, а массовая кампания легко превращается в тысячи уникальных вариантов, каждый из которых обходит фильтры по «шаблонности». 	Социальная инженерия. Здесь качественный скачок дали дипфейки. Хрестоматийный пример — инцидент с инженерной компанией Arup в начале 2024 года: сотрудника финансового отдела в Гонконге убедили провести 15 переводов на общую сумму около 25 млн. долл. после видеозвонка, на котором все «руководители», включая финансового директора, были сгенерированы ИИ. И это не единичный случай: по оценке Surfshark на основе AI Incident Database, совокупные потери от дипфейк-мошенничества к концу прошлого года достигли порядка 1,56 млрд. долл., причём более 1 млрд. пришлось только на 2025 год. Опаснее всего то, что человек здесь беззащитен по природе: в контролируемых исследованиях качественные видео-дипфейки люди правильно распознают лишь примерно в четверти случаев. Доверие к «знакомому лицу и голосу» из защитного механизма превратилось в вектор атаки. 	Вредоносное ПО. ИИ ускорил разработку и, что опаснее, — вариативность. Полиморфный код, который на каждой итерации меняет структуру, сохраняя функциональность, генерируется теперь программно и в промышленных объёмах. Для сигнатурного детектирования это тяжёлый удар: сигнатура ловит известное, а машина производит бесконечный поток «нового». 	Пентест. Автоматизация многих этапов внешнего и внутреннего тестирования на проникновение с помощью нейросетей значительно сокращает время от обнаружения уязвимого ресурса до получения доступа во внутреннюю инфраструктуру. Разница и преимущество опытного оператора с нейростью перед специалистом без такого инструмента сразу заметны. Там, где человеческий глаз и подход могут не заметить сложную уязвимость, ИИ может показать новый вектор или атаку, находя решение даже в самых сложных условиях. #IMAGE_235448# Как показывает The 2026 Vulnerability Forecast Update, в этом году ожидается 66 000 новых публичных CVE, что на 46,3% выше первоначального прогноза в 2026 году. Это на 37% больше по сравнению с 2025-м, в котором нашли 48 185 CVE, и на 20% больше чем в 2024-м (40 009 CVE). По прогнозу заметна высокая динамика, и с помощью нейросетей теперь обнаруживают намного больше новых 0-day уязвимостей. Гонка вооружений: где был переломный момент Противостояние атакующих и защитных алгоритмов — не новость. ML в антивирусах и системах обнаружения вторжений применяется больше десяти лет: поведенческий анализ, классификаторы вредоносных файлов, детекторы аномалий появились задолго до нынешнего хайпа. Массовый разворот защиты в сторону ИИ произошёл в конце 2010-х, когда EDR- и NGAV-решения сделали машинное обучение стандартом, а не экзотикой. Настоящий перелом наступил в 2022-2023 годах, с выходом больших языковых моделей в широкий доступ. До этого преимущество в автоматизации было скорее на стороне защиты — у неё было больше ресурсов и данных. Генеративный ИИ впервые дал атакующему инструмент такой же мощности, что и у обороняющегося, и почти бесплатно. Симметрия нарушилась: порог входа в качественную атаку упал быстрее, чем успела адаптироваться защита. Именно этот разрыв мы сейчас и наблюдаем. Какие задачи атакующие уже делегируют машине Если рассмотреть по отдельности каждый из этапов проникновения с точки зрения атакующего, ИИ сегодня применяется почти в каждом из них: 	 Разведка (recon). Сбор и категоризация больших объемов данных по компании из открытых источников, составление карты внешнего периметра, анализ утечек и построение профилей сотрудников. То, что раньше отнимало у аналитка дни, модель делает за десятки минут. 	 Активная эксплуатация. Пентест-агенты позволяют проанализировать каждый из обнаруженных ресурсов как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, и все это автоматически. 	Социальная инженерия. Генерация фишинга и приманок. Уникальные письма, поддельные страницы, легенды для переписки — под конкретную жертву и её контекст. Сюда же относятся дипфейки: голос и видео для обхода процедур подтверждения личности и «звонка руководителя». 	Разработка и мутация ПО. Написание и обфускация полезной нагрузки, генерация полиморфных вариантов, адаптация под окружение. 	Полноценная имитация атакующего. Пентест-агенты позволяют проанализировать сайт как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, генерация proof-of-concept под свежие багии помощь в написании эксплойтов, и все это автоматически. Отдельно — обход защиты. Генеративные модели используются для мимикрии под легитимный трафик: вредоносная активность «размазывается» так, чтобы статистически не отличаться от нормального поведения пользователя или приложения, а команды управления прячутся в обычных на вид запросах. Это прямая атака на детекторы аномалий, построенные на «отклонении от нормы». Как ИИ работает на стороне защиты: SOC, SIEM, поведенческий анализ Хорошая новость в том, что те же технологии усиливают и оборону — причём защита научилась применять ИИ раньше и системнее. В современных SOC и SIEM-системах машинное обучение решает главную боль аналитика — шум. Классические корреляционные правила генерируют тысячи срабатываний, большинство из которых ложные. ML-модели строят поведенческий базлайн (UEBA, анализ поведения пользователей и сущностей): что для конкретного аккаунта, сервера или сервиса является нормой по времени, объёму, географии, набору действий. Отклонение от этого профиля — сигнал, даже если формально ни одно сигнатурное правило не сработало. Именно так ловятся атаки, у которых нет известной сигнатуры. По эффективности для сложных угроз можно выделить несколько подходов: 	 Обучение без учителя (кластеризация, детекторы аномалий) — для zero-day и незнакомых атак, где нет размеченных примеров. Модель ищет не «известное плохое», а «непохожее на нормальное». 	 Графовые модели и анализ последовательностей — для APT и латерального перемещения. Продвинутая целевая атака растянута во времени и складывается из событий, каждое из которых по отдельности выглядит безобидно. Увидеть её можно только как цепочку — граф связей между хостами, аккаунтами и процессами. 	 Рекуррентные и трансформерные архитектуры — для анализа временных рядов событий и выявления аномального контекста в потоке логов. 	 Модели на данных цепочки поставок — для атак через доверенных поставщиков, где вредоносный код приходит легитимным каналом обновления и требует анализа отклонений в самом артефакте, а не в сети. Ни один из этих методов не самодостаточен. Работает ансамбль: сигнатуры закрывают известное дёшево и точно, ML — неизвестное и поведенческое. И это окупается: по данным отчёта IBM Cost of a Data Breach 2025, организации, широко применяющие ИИ и автоматизацию в безопасности, обнаруживают и локализуют инциденты заметно быстрее и с ощутимо меньшими издержками, чем те, кто этого не делает. Предиктивные модели угроз пытаются ответить на вопрос «где ударят следующим». Они анализируют профиль организации, её поверхность атаки, историю инцидентов в отрасли, активность конкретных группировок и приоритизируют риски: какие активы и какие уязвимости с наибольшей вероятностью станут целью. Дефицит кадров в ИБ — структурная проблема, и здесь ИИ даёт ощутимый эффект. Системы SOAR (оркестрация, автоматизация и реагирование) берут на себя рутину: обогащение инцидента данными, первичную сортировку, изоляцию заражённого хоста, блокировку индикатора компрометации по готовому сценарию (playbook). Языковые модели добавляют к этому автоматическое резюмирование инцидента и черновики отчётов. Смысл не в том, чтобы заменить аналитика, а в том, чтобы он занимался расследованиями, а не перекладыванием тикетов. Когда 80% типовых срабатываний обрабатывается автоматически, у человека высвобождается время на то, что машине пока не по силам, — сложные, нестандартные, целевые атаки. Тут важно предостеречь: полная автоматизация реагирования без контроля человека опасна, потому что автономный ответ на ложный или спровоцированный сигнал сам становится вектором атаки — злоумышленник может намеренно заставить защиту «выстрелить себе в ногу». Цикл «атака — защита», когда с обеих сторон ИИ Мы движемся к ситуации, где и атакующий, и обороняющийся — это алгоритмы, соревнующиеся в скорости адаптации. Атакующая модель генерирует вариант, обходящий детектор; защитная — учится его ловить; атакующая — генерирует следующий. Цикл, который раньше измерялся месяцами, сжимается до дней и часов, а на этапе исполнения — до секунд. По данным CrowdStrike, среднее «время прорыва» (от первичной компрометации до первого латерального перемещения) в 2025 году составило 29 минут — на 65% быстрее, чем годом ранее, а рекордный показатель — 27 секунд; передача доступа от брокера первичного доступа к операторам вымогательского ПО, по данным Mandiant, сжалась до 22 секунд. Тот же CrowdStrike фиксирует рост ИИ-опосредованных атак примерно на 89% год к году. Кто выигрывает в такой гонке? Тот, у кого качественнее данные и быстрее петля обратной связи. И здесь у защиты есть структурное преимущество, о котором часто забывают: обороняющийся видит свою инфраструктуру целиком, а атакующий — только снаружи и по частям. Это преимущество работает при одном условии — если защита действительно видит всё. Слепые зоны — забытые тестовые серверы, теневые облачные сервисы, неучтённые VPN-точки, старые поддомены — обнуляют его. Автоматизированный сканер злоумышленника найдёт их за часы, и никакой продвинутый SOC не защитит актив, о существовании которого он не знает. Именно поэтому фундамент защиты в эпоху ИИ — это полная и непрерывная видимость поверхности атаки. Что будет через 5-10 лет Прогнозировать в ИБ на десять лет — сложно, но тренды достаточно устойчивы, чтобы обозначить контур. ИИ — полезный инструмент, который уже активно используется защитниками, но он не спасёт там, где нет базовой кибергигиены. Сначала база — классические процессы сканирования. Для них использование агентских систем — пустая трата токенов. А дальше — не бояться экспериментировать, решать свои задачи. Атаки станут агентными и автономными. Значительная часть операций — от разведки до эксплуатации — будет выполняться без прямого участия человека, а атаки станут по-настоящему массово-персонализированными: индивидуальный подход к каждой жертве при промышленном масштабе. Скорость выйдет на первый план. Ключевой метрикой станет не «есть ли у вас защита», а «за сколько вы обнаруживаете и реагируете». Человек останется в контуре принятия стратегических решений, но операционную скорость будут задавать машины с обеих сторон. Доверие к цифровому контенту продолжит расти. Дипфейки сделают верификацию личности отдельной инженерной дисциплиной. Пароля и даже голоса будет недостаточно — потребуются криптографические и поведенческие методы подтверждения. Защита консолидируется. Контроль периметра, SIEM, XDR и SOAR срастутся в единые экосистемы, где данные о поверхности атаки становятся общим контекстом для решений. Рынок уже движется к модели непрерывного управления экспозицией угроз (Continuous Threat Exposure Management) — от разовых проверок к постоянному мониторингу. Генеративный ИИ — это усилитель, и он укрепляет обе стороны. Проиграет не тот, у кого нет ИИ, а кто продолжает жить в логике реактивной защиты: узнавать о проблеме постфактум и проверять периметр по расписанию. Важно принять новую реальность, где всё меняется каждый день и с обеих сторон работают машины, построить защиту как непрерывный процесс, а не разовое действие. Технологии здесь скорее вторичны. Первична дисциплина видеть всё и вовремя. #IMAGE_235445#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;За&nbsp;тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но&nbsp;ни&nbsp;один из&nbsp;них не&nbsp;менял расстановку сил так быстро, как генеративный ИИ. Раньше между появлением нового класса атак и&nbsp;его массовым применением проходили годы: злоумышленникам нужно было время, квалификация и&nbsp;инфраструктура. Сегодня этот барьер обрушился. Написать фишинговое письмо на&nbsp;безупречном русском, собрать досье на&nbsp;жертву, сгенерировать вариант вредоносного кода, обходящий сигнатурный детектор,&nbsp;— всё это стало доступно человеку без глубокой технической подготовки и&nbsp;занимает минуты, а&nbsp;не&nbsp;недели. &lltt;/em&ggtt;&lltt;em&ggtt;Рассмотрим, &lltt;/em&ggtt;&lltt;em&ggtt;к&lltt;/em&ggtt;&lltt;em&ggtt;ак эволюционировали методы кибератак с&nbsp;появлением ИИ&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Масштаб перемен уже поддаётся измерению. По&nbsp;данным отчёта Bugcrowd Inside the Mind of&nbsp;a&nbsp;Hacker, к&nbsp;концу 2025 года&nbsp;82% исследователей (в&nbsp;том числе действующих не&nbsp;по&nbsp;правилам; против&nbsp;64% в&nbsp;&lltt;nobr&ggtt;2023-м)&lltt;/nobr&ggtt; применяли&nbsp;ИИ в&nbsp;своей работе. Искусственный интеллект перестал быть экзотикой в&nbsp;арсенале атакующего и&nbsp;стал рабочим инструментом по&nbsp;умолчанию.&lltt;/p&ggtt;
&lltt;p&ggtt;Эволюцию «наступательного» ИИ&nbsp;удобно разложить на&nbsp;три волны, которые не&nbsp;сменяют, а&nbsp;наслаиваются друг на&nbsp;друга.&lltt;/p&ggtt;
&lltt;h3&ggtt;Три этапа взросления атакующих нейросетей&lltt;/h3&ggtt;
&lltt;p&ggtt;Первая волна&nbsp;— автоматизация рутины. Здесь ИИ&nbsp;не&nbsp;принимает решений, а&nbsp;масштабирует&nbsp;то, что человек и&nbsp;так делал руками: генерирует тексты фишинга, переводит их&nbsp;на&nbsp;десятки языков без характерных ошибок, пишет шаблоны, парсит открытые источники. Это уже полностью реальность и&nbsp;массовая практика. Стоимость подготовки убедительной атаки упала на&nbsp;порядок, а&nbsp;качество&nbsp;— выросло.&lltt;/p&ggtt;
&lltt;p&ggtt;Вторая волна&nbsp;— ассистирование в&nbsp;сложных задачах. ИИ&nbsp;становится «вторым пилотом» атакующего: помогает разобраться в&nbsp;незнакомом коде, предлагает варианты эксплуатации уязвимости, адаптирует полезную нагрузку под конкретное окружение, ведёт разведку и&nbsp;приоритизирует цели. Решение по-прежнему за&nbsp;человеком, но&nbsp;скорость и&nbsp;охват растут кратно. Именно на&nbsp;этом этапе мы&nbsp;находимся сейчас.&lltt;/p&ggtt;
&lltt;p&ggtt;Третья волна&nbsp;— автономное принятие решений. Это агентные системы, которые получают цель («получить доступ к&nbsp;сегменту сети») и&nbsp;самостоятельно строят цепочку действий: разведка → выбор вектора → эксплуатация → закрепление → латеральное перемещение, реагируя на&nbsp;обратную связь от&nbsp;среды без участия оператора. Полноценных автономных атакующих агентов «в&nbsp;дикой природе» пока единицы, и&nbsp;они несовершенны, но&nbsp;направление обозначено предельно чётко. Именно к&nbsp;этому сценарию защиты нужно готовиться уже сегодня, а&nbsp;не&nbsp;когда он&nbsp;станет мейнстримом.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что случилось с&nbsp;классическими векторами&lltt;/h3&ggtt;
&lltt;p&ggtt;Важно понимать: генеративный&nbsp;ИИ не&nbsp;создал новых классов атак. Фишинг, социальная инженерия и&nbsp;вредоносное&nbsp;ПО были и&nbsp;двадцать лет назад. ИИ&nbsp;изменил их&nbsp;экономику и&nbsp;качество.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Фишинг&lltt;/strong&ggtt;. Раньше защитой служили сами письма: корявый язык, нелепые обращения, кривая верстка&nbsp;— «маркеры мошенника», которым учили сотрудников. Генеративные модели эти маркеры стёрли. Показателен рубеж, зафиксированный в&nbsp;сети детектирования Hoxhunt: несколько лет доля писем с&nbsp;признаками ИИ-генерации держалась ниже&nbsp;5%, а&nbsp;в&nbsp;декабре 2025 года подскочила примерно в&nbsp;14&nbsp;раз&nbsp;— до&nbsp;56% всех выявленных атак. Изменилась и&nbsp;экономика: по&nbsp;оценкам, приводимым в&nbsp;индустриальных отчётах, LLM сократили время подготовки убедительной кампании с&nbsp;примерно 16&nbsp;часов ручной работы до&nbsp;нескольких минут, а&nbsp;затраты на&nbsp;массовую рассылку упали примерно на&nbsp;95%. Письмо теперь грамотное, персонализированное под должность и&nbsp;контекст получателя, а&nbsp;массовая кампания легко превращается в&nbsp;тысячи уникальных вариантов, каждый из&nbsp;которых обходит фильтры по&nbsp;«шаблонности».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Социальная инженерия&lltt;/strong&ggtt;&lltt;strong&ggtt;.&lltt;/strong&ggtt; Здесь качественный скачок дали дипфейки. Хрестоматийный пример&nbsp;— инцидент с&nbsp;инженерной компанией Arup в&nbsp;начале 2024&nbsp;года: сотрудника финансового отдела в&nbsp;Гонконге убедили провести 15&nbsp;переводов на&nbsp;общую сумму около 25&nbsp;млн. долл. после видеозвонка, на&nbsp;котором все «руководители», включая финансового директора, были сгенерированы ИИ. И&nbsp;это не&nbsp;единичный случай: по&nbsp;оценке Surfshark на&nbsp;основе AI&nbsp;Incident Database, совокупные потери от&nbsp;дипфейк-мошенничества к&nbsp;концу прошлого года достигли порядка 1,56&nbsp;млрд. долл., причём более 1&nbsp;млрд. пришлось только на&nbsp;2025&nbsp;год. Опаснее всего&nbsp;то, что человек здесь беззащитен по&nbsp;природе: в&nbsp;контролируемых исследованиях качественные видео-дипфейки люди правильно распознают лишь примерно в&nbsp;четверти случаев. Доверие к&nbsp;«знакомому лицу и&nbsp;голосу» из&nbsp;защитного механизма превратилось в&nbsp;вектор атаки.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Вредоносное ПО&lltt;/strong&ggtt;&lltt;strong&ggtt;.&lltt;/strong&ggtt; ИИ&nbsp;ускорил разработку&nbsp;и, что опаснее,&nbsp;— вариативность. Полиморфный код, который на&nbsp;каждой итерации меняет структуру, сохраняя функциональность, генерируется теперь программно и&nbsp;в&nbsp;промышленных объёмах. Для сигнатурного детектирования это тяжёлый удар: сигнатура ловит известное, а&nbsp;машина производит бесконечный поток «нового».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Пентест.&lltt;/strong&ggtt; Автоматизация многих этапов внешнего и&nbsp;внутреннего тестирования на&nbsp;проникновение с&nbsp;помощью нейросетей значительно сокращает время от&nbsp;обнаружения уязвимого ресурса до&nbsp;получения доступа во&nbsp;внутреннюю инфраструктуру. Разница и&nbsp;преимущество опытного оператора с&nbsp;нейростью перед специалистом без такого инструмента сразу заметны. Там, где человеческий глаз и&nbsp;подход могут не&nbsp;заметить сложную уязвимость, ИИ&nbsp;может показать новый вектор или атаку, находя решение даже в&nbsp;самых сложных условиях.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;#IMAGE_235448#&lltt;/p&ggtt;
&lltt;p&ggtt;Как показывает &lltt;a href="https://www.first.org/blog/20260615-vulnerability-forecast-update"&ggtt;The 2026 Vulnerability Forecast Update&lltt;/a&ggtt;, в&nbsp;этом году ожидается 66&nbsp;000 новых публичных CVE, что на&nbsp;46,3% выше первоначального прогноза в&nbsp;2026&nbsp;году. Это на&nbsp;37% больше по&nbsp;сравнению с&nbsp;&lltt;nobr&ggtt;2025-м,&lltt;/nobr&ggtt; в&nbsp;котором нашли &lltt;a href="https://www.stingrai.io/blog/vulnerability-statistics-2026"&ggtt;48&nbsp;185&nbsp;CVE&lltt;/a&ggtt;, и&nbsp;на&nbsp;20% больше чем в&nbsp;&lltt;nobr&ggtt;2024-м&lltt;/nobr&ggtt; (40&nbsp;009&nbsp;CVE). По&nbsp;прогнозу заметна высокая динамика, и&nbsp;с&nbsp;помощью нейросетей теперь обнаруживают намного больше новых &lltt;nobr&ggtt;0-day&lltt;/nobr&ggtt; уязвимостей.&lltt;/p&ggtt;
&lltt;h3&ggtt;Гонка вооружений: где был переломный момент&lltt;/h3&ggtt;
&lltt;p&ggtt;Противостояние атакующих и&nbsp;защитных алгоритмов&nbsp;— не&nbsp;новость. ML&nbsp;в антивирусах и&nbsp;системах обнаружения вторжений применяется больше десяти лет: поведенческий анализ, классификаторы вредоносных файлов, детекторы аномалий появились задолго до&nbsp;нынешнего хайпа. Массовый разворот защиты в&nbsp;сторону&nbsp;ИИ произошёл в&nbsp;конце &lltt;nobr&ggtt;2010-х,&lltt;/nobr&ggtt; когда EDR- и&nbsp;NGAV-решения сделали машинное обучение стандартом, а&nbsp;не&nbsp;экзотикой.&lltt;/p&ggtt;
&lltt;p&ggtt;Настоящий перелом наступил в&nbsp;&lltt;nobr&ggtt;2022-2023 годах,&lltt;/nobr&ggtt; с&nbsp;выходом больших языковых моделей в&nbsp;широкий доступ. До&nbsp;этого преимущество в&nbsp;автоматизации было скорее на&nbsp;стороне защиты&nbsp;— у&nbsp;неё было больше ресурсов и&nbsp;данных. Генеративный ИИ&nbsp;впервые дал атакующему инструмент такой&nbsp;же мощности, что и&nbsp;у&nbsp;обороняющегося, и&nbsp;почти бесплатно. Симметрия нарушилась: порог входа в&nbsp;качественную атаку упал быстрее, чем успела адаптироваться защита. Именно этот разрыв мы&nbsp;сейчас и&nbsp;наблюдаем.&lltt;/p&ggtt;
&lltt;h3&ggtt;Какие задачи атакующие уже делегируют машине&lltt;/h3&ggtt;
&lltt;p&ggtt;Если рассмотреть по&nbsp;отдельности каждый из&nbsp;этапов проникновения с&nbsp;точки зрения атакующего, ИИ&nbsp;сегодня применяется почти в&nbsp;каждом из&nbsp;них:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Разведка (recon).&lltt;/strong&ggtt; Сбор и&nbsp;категоризация больших объемов данных по&nbsp;компании из&nbsp;открытых источников, составление карты внешнего периметра, анализ утечек и&nbsp;построение профилей сотрудников. То, что раньше отнимало у&nbsp;аналитка дни, модель делает за&nbsp;десятки минут.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;Активная эксплуатация&lltt;/strong&ggtt;. Пентест-агенты позволяют проанализировать каждый из&nbsp;обнаруженных ресурсов как если&nbsp;бы это делал реальный злоумышленник&nbsp;— использовать инъекции, анализировать поведение приложения на&nbsp;различные запросы, обнаруживать сложные цепочки уязвимостей, и&nbsp;все это автоматически.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Социальная инженерия.&lltt;/strong&ggtt; Генерация фишинга и&nbsp;приманок. Уникальные письма, поддельные страницы, легенды для переписки&nbsp;— под конкретную жертву и&nbsp;её&nbsp;контекст. Сюда&nbsp;же относятся дипфейки: голос и&nbsp;видео для обхода процедур подтверждения личности и&nbsp;«звонка руководителя».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Разработка и&nbsp;мутация ПО.&lltt;/strong&ggtt; Написание и&nbsp;обфускация полезной нагрузки, генерация полиморфных вариантов, адаптация под окружение.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Полноценная имитация атакующего.&lltt;/strong&ggtt; Пентест-агенты позволяют проанализировать сайт как если&nbsp;бы это делал реальный злоумышленник&nbsp;— использовать инъекции, анализировать поведение приложения на&nbsp;различные запросы, обнаруживать сложные цепочки уязвимостей, генерация proof-of-concept под свежие багии помощь в&nbsp;написании эксплойтов, и&nbsp;все это автоматически.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Отдельно&nbsp;— обход защиты. Генеративные модели используются для мимикрии под легитимный трафик: вредоносная активность «размазывается» так, чтобы статистически не&nbsp;отличаться от&nbsp;нормального поведения пользователя или приложения, а&nbsp;команды управления прячутся в&nbsp;обычных на&nbsp;вид запросах. Это прямая атака на&nbsp;детекторы аномалий, построенные на&nbsp;«отклонении от&nbsp;нормы».&lltt;/p&ggtt;
&lltt;h3&ggtt;Как ИИ&nbsp;работает на&nbsp;стороне защиты: SOC, SIEM, поведенческий анализ&lltt;/h3&ggtt;
&lltt;p&ggtt;Хорошая новость в&nbsp;том, что те&nbsp;же технологии усиливают и&nbsp;оборону&nbsp;— причём защита научилась применять&nbsp;ИИ раньше и&nbsp;системнее.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;современных SOC и&nbsp;SIEM-системах машинное обучение решает главную боль аналитика&nbsp;— шум. Классические корреляционные правила генерируют тысячи срабатываний, большинство из&nbsp;которых ложные. &lltt;nobr&ggtt;ML-модели&lltt;/nobr&ggtt; строят поведенческий базлайн (UEBA, анализ поведения пользователей и&nbsp;сущностей): что для конкретного аккаунта, сервера или сервиса является нормой по&nbsp;времени, объёму, географии, набору действий. Отклонение от&nbsp;этого профиля&nbsp;— сигнал, даже если формально ни&nbsp;одно сигнатурное правило не&nbsp;сработало. Именно так ловятся атаки, у&nbsp;которых нет известной сигнатуры.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;эффективности для сложных угроз можно выделить несколько подходов:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Обучение без учителя (кластеризация, детекторы аномалий)&lltt;/strong&ggtt;&nbsp;— для zero-day и&nbsp;незнакомых атак, где нет размеченных примеров. Модель ищет не&nbsp;«известное плохое», а&nbsp;«непохожее на&nbsp;нормальное».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Графовые модели и&nbsp;анализ последовательностей&lltt;/strong&ggtt;&nbsp;— для APT и&nbsp;латерального перемещения. Продвинутая целевая атака растянута во&nbsp;времени и&nbsp;складывается из&nbsp;событий, каждое из&nbsp;которых по&nbsp;отдельности выглядит безобидно. Увидеть её&nbsp;можно только как цепочку&nbsp;— граф связей между хостами, аккаунтами и&nbsp;процессами.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Рекуррентные и&nbsp;трансформерные архитектуры&lltt;/strong&ggtt;&nbsp;— для анализа временных рядов событий и&nbsp;выявления аномального контекста в&nbsp;потоке логов.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Модели на&nbsp;данных цепочки поставок&lltt;/strong&ggtt;&nbsp;— для атак через доверенных поставщиков, где вредоносный код приходит легитимным каналом обновления и&nbsp;требует анализа отклонений в&nbsp;самом артефакте, а&nbsp;не&nbsp;в&nbsp;сети.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Ни&nbsp;один из&nbsp;этих методов не&nbsp;самодостаточен. Работает ансамбль: сигнатуры закрывают известное дёшево и&nbsp;точно, ML&nbsp;— неизвестное и&nbsp;поведенческое. И&nbsp;это окупается: по&nbsp;данным отчёта IBM Cost of&nbsp;a&nbsp;Data Breach 2025, организации, широко применяющие&nbsp;ИИ и&nbsp;автоматизацию в&nbsp;безопасности, обнаруживают и&nbsp;локализуют инциденты заметно быстрее и&nbsp;с&nbsp;ощутимо меньшими издержками, чем&nbsp;те, кто этого не&nbsp;делает.&lltt;/p&ggtt;
&lltt;p&ggtt;Предиктивные модели угроз пытаются ответить на&nbsp;вопрос «где ударят следующим». Они анализируют профиль организации, её&nbsp;поверхность атаки, историю инцидентов в&nbsp;отрасли, активность конкретных группировок и&nbsp;приоритизируют риски: какие активы и&nbsp;какие уязвимости с&nbsp;наибольшей вероятностью станут целью.&lltt;/p&ggtt;
&lltt;p&ggtt;Дефицит кадров в&nbsp;ИБ&nbsp;— структурная проблема, и&nbsp;здесь&nbsp;ИИ даёт ощутимый эффект. Системы SOAR (оркестрация, автоматизация и&nbsp;реагирование) берут на&nbsp;себя рутину: обогащение инцидента данными, первичную сортировку, изоляцию заражённого хоста, блокировку индикатора компрометации по&nbsp;готовому сценарию (playbook). Языковые модели добавляют к&nbsp;этому автоматическое резюмирование инцидента и&nbsp;черновики отчётов.&lltt;/p&ggtt;
&lltt;p&ggtt;Смысл не&nbsp;в&nbsp;том, чтобы заменить аналитика, а&nbsp;в&nbsp;том, чтобы он&nbsp;занимался расследованиями, а&nbsp;не&nbsp;перекладыванием тикетов. Когда&nbsp;80% типовых срабатываний обрабатывается автоматически, у&nbsp;человека высвобождается время на&nbsp;то, что машине пока не&nbsp;по&nbsp;силам,&nbsp;— сложные, нестандартные, целевые атаки. Тут важно предостеречь: полная автоматизация реагирования без контроля человека опасна, потому что автономный ответ на&nbsp;ложный или спровоцированный сигнал сам становится вектором атаки&nbsp;— злоумышленник может намеренно заставить защиту «выстрелить себе в&nbsp;ногу».&lltt;/p&ggtt;
&lltt;h3&ggtt;Цикл «атака&nbsp;— защита», когда с&nbsp;обеих сторон ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Мы&nbsp;движемся к&nbsp;ситуации, где и&nbsp;атакующий, и&nbsp;обороняющийся&nbsp;— это алгоритмы, соревнующиеся в&nbsp;скорости адаптации. Атакующая модель генерирует вариант, обходящий детектор; защитная&nbsp;— учится его ловить; атакующая&nbsp;— генерирует следующий. Цикл, который раньше измерялся месяцами, сжимается до&nbsp;дней и&nbsp;часов, а&nbsp;на&nbsp;этапе исполнения&nbsp;— до&nbsp;секунд. По&nbsp;данным CrowdStrike, среднее «время прорыва» (от&nbsp;первичной компрометации до&nbsp;первого латерального перемещения) в&nbsp;2025 году составило 29&nbsp;минут&nbsp;— на&nbsp;65% быстрее, чем годом ранее, а&nbsp;рекордный показатель&nbsp;— 27&nbsp;секунд; передача доступа от&nbsp;брокера первичного доступа к&nbsp;операторам вымогательского&nbsp;ПО, по&nbsp;данным Mandiant, сжалась до&nbsp;22&nbsp;секунд. Тот&nbsp;же CrowdStrike фиксирует рост ИИ-опосредованных атак примерно на&nbsp;89% год к&nbsp;году.&lltt;/p&ggtt;
&lltt;p&ggtt;Кто выигрывает в&nbsp;такой гонке? Тот, у&nbsp;кого качественнее данные и&nbsp;быстрее петля обратной связи. И&nbsp;здесь у&nbsp;защиты есть структурное преимущество, о&nbsp;котором часто забывают: обороняющийся видит свою инфраструктуру целиком, а&nbsp;атакующий&nbsp;— только снаружи и&nbsp;по&nbsp;частям. Это преимущество работает при одном условии&nbsp;— если защита действительно видит всё. Слепые зоны&nbsp;— забытые тестовые серверы, теневые облачные сервисы, неучтённые VPN-точки, старые поддомены&nbsp;— обнуляют его. Автоматизированный сканер злоумышленника найдёт их&nbsp;за&nbsp;часы, и&nbsp;никакой продвинутый SOC&nbsp;не защитит актив, о&nbsp;существовании которого он&nbsp;не&nbsp;знает.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому фундамент защиты в&nbsp;эпоху ИИ&nbsp;— это полная и&nbsp;непрерывная видимость поверхности атаки.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что будет через 5&lltt;strong&ggtt;-&lltt;/strong&ggtt;10 лет&lltt;/h3&ggtt;
&lltt;p&ggtt;Прогнозировать в&nbsp;ИБ на&nbsp;десять лет&nbsp;— сложно, но&nbsp;тренды достаточно устойчивы, чтобы обозначить контур. ИИ&nbsp;— полезный инструмент, который уже активно используется защитниками, но&nbsp;он&nbsp;не&nbsp;спасёт там, где нет базовой кибергигиены. Сначала база&nbsp;— классические процессы сканирования. Для них использование агентских систем&nbsp;— пустая трата токенов. А&nbsp;дальше&nbsp;— не&nbsp;бояться экспериментировать, решать свои задачи.&lltt;/p&ggtt;
&lltt;p&ggtt;Атаки станут агентными и&nbsp;автономными. Значительная часть операций&nbsp;— от&nbsp;разведки до&nbsp;эксплуатации&nbsp;— будет выполняться без прямого участия человека, а&nbsp;атаки станут по-настоящему массово-персонализированными: индивидуальный подход к&nbsp;каждой жертве при промышленном масштабе.&lltt;/p&ggtt;
&lltt;p&ggtt;Скорость выйдет на&nbsp;первый план. Ключевой метрикой станет не&nbsp;«есть&nbsp;ли у&nbsp;вас защита», а&nbsp;«за&nbsp;сколько вы&nbsp;обнаруживаете и&nbsp;реагируете». Человек останется в&nbsp;контуре принятия стратегических решений, но&nbsp;операционную скорость будут задавать машины с&nbsp;обеих сторон.&lltt;/p&ggtt;
&lltt;p&ggtt;Доверие к&nbsp;цифровому контенту продолжит расти. Дипфейки сделают верификацию личности отдельной инженерной дисциплиной. Пароля и&nbsp;даже голоса будет недостаточно&nbsp;— потребуются криптографические и&nbsp;поведенческие методы подтверждения.&lltt;/p&ggtt;
&lltt;p&ggtt;Защита консолидируется. Контроль периметра, SIEM, XDR и&nbsp;SOAR срастутся в&nbsp;единые экосистемы, где данные о&nbsp;поверхности атаки становятся общим контекстом для решений. Рынок уже движется к&nbsp;модели непрерывного управления экспозицией угроз (Continuous Threat Exposure Management)&nbsp;— от&nbsp;разовых проверок к&nbsp;постоянному мониторингу.&lltt;/p&ggtt;
&lltt;p&ggtt;Генеративный ИИ&nbsp;— это усилитель, и&nbsp;он&nbsp;укрепляет обе стороны. Проиграет не&nbsp;тот, у&nbsp;кого нет&nbsp;ИИ, а&nbsp;кто продолжает жить в&nbsp;логике реактивной защиты: узнавать о&nbsp;проблеме постфактум и&nbsp;проверять периметр по&nbsp;расписанию. Важно принять новую реальность, где всё меняется каждый день и&nbsp;с&nbsp;обеих сторон работают машины, построить защиту как непрерывный процесс, а&nbsp;не&nbsp;разовое действие. Технологии здесь скорее вторичны. Первична дисциплина видеть всё и&nbsp;вовремя.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235445#&lltt;/p&ggtt;]]></source>
<adate>02.09.2026</adate>
<dbid>235444</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/1c5/ib0rj92gunnl5mhmpp3alrylofrowott.jpg;;https://www.itweek.ru/upload/iblock/a9f/p1abandpeq6ppzccydy6zs8r32i7x565.jpg]]>
</images>
<imagesname><![CDATA[;;Давид Ордян, основатель и генеральный директор METASCAN   ;; ]]></imagesname>
<tag><![CDATA[Безопасность;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Почему подавляющее большинство компаний отстает в использовании ИИ — и как это исправить]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235443]]></link>
<description><![CDATA[Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией на практике, но хорошая новость заключается в том, что специалисты могут его преодолеть, сосредоточившись на тщательных исследованиях и убедительных сценариях использования в производстве, сообщает портал ZDNet. Согласно отчету глобальной контентной и технологической компании Thomson Reuters «2026 Future of Professionals Report», до 91% сотрудников заявляют, что их организации не в полной мере используют потенциал ИИ. Исследование, основанное на глобальном опросе 1800 специалистов из различных секторов, показывает растущий разрыв между амбициями в области ИИ и реальностью, что становится все более серьезной проблемой, отмечает Кирсти Рот, операционный директор Thomson Reuters. Полтора года назад сотрудники с энтузиазмом экспериментировали с ИИ, а их руководители с готовностью поддерживали эти исследования. Сегодня ситуация изменилась. Специалисты тратят токены на использование ИИ, а их руководители обеспокоены ростом расходов на ИТ. Учитывая, что исследования MIT показывают, что 95% проектов в области ИИ не приносят пользы, неудивительно, что компании начинают сомневаться. ИИ крайне фрагментирован и раздроблен «Люди начинают понимать, что эти технологии стоят больших денег, и они пока не обязательно видят от них пользу, — говорит Рот. — И поэтому разговор сводится к классическому вопросу управления изменениями: „Хорошо, у нас есть все эти технологии и все эти инструменты, но как мы можем реально изменить наши процессы и способы работы, чтобы быть более эффективными?“». Новые развивающиеся технологии, от агентных моделей ИИ до инструментов глубокого исследования, будут продолжать проникать в бизнес. Как считает генеральный директор Boomi Стив Лукас, общее положение дел в области ИИ крайне фрагментировано и раздроблено: «Сейчас профессионалы знакомятся со множеством терминов — передовые модели, частные модели, доменные модели, модели с открытыми весами, агентные структуры, агентные механизмы и агентные циклы — которые не существовали еще несколько месяцев назад, не говоря уже о нескольких годах». Рот, опираясь на исследование своей фирмы и личный опыт, предлагает компаниям и их специалистам, получающим выгоду от ИИ, сосредоточиться на двух областях: тщательных исследованиях и надежных сценариях использования в производстве. Поддержка тщательных исследований Профессионалы, принявшие участие в опросе, четко понимают, что должны делать их инструменты ИИ: защищать конфиденциальные данные (96%), обосновывать результаты авторитетным контентом (94%) и предоставлять объяснимые и обоснованные рассуждения (90%). Однако двое из пяти специалистов (41%), использующих ИИ в своей работе, отмечают, что у них нет доступа к высококачественным инструментам. Согласно исследованию, даже при наличии ИИ-стратегии ее реализация часто отстает. Чуть более трети (35%) специалистов в компаниях, имеющих четко определенную ИИ-стратегию, говорят, что этот подход не проявляется в их повседневной работе. По словам Рот, одно из объяснений — это то, что она называет «инструментальным взрывом» («tool blast»), когда организации навязывают сотрудникам широкий спектр ИИ-сервисов без четкого понимания бизнес-результатов. «Я слышала, как люди говорят: „Мне дали все это. Но что я должен с этим делать?“ Слишком многие компании не понимают, какие инструменты должны использовать сотрудники. Я думаю, что в этом случае очень трудно увидеть рост, за исключением того, что ваши затраты на ПО значительно возрастут», — отмечает она. Согласно прогнозу Gartner, 40% предприятий к 2027 г. сократят использование или выведут из эксплуатации автономных агентов ИИ из-за опасений по поводу их ценности. Рот говорит, что вдумчивые бизнес-руководители ищут действенные решения на основе ИИ для сложных задач, предоставляя специалистам возможность изучать новые технологии, не принимая на себя слишком большого риска. Это то, что она делает в Thomson Reuters, где, по ее словам, придерживаются непредвзятого подхода к генеративному ИИ. «Если у вас появляется классный инструмент, и вы работаете в отделах маркетинга, продаж или программирования, и хотите его попробовать, мы позволим вам это сделать», — поясняет она. Рот отмечает, что вместо того, чтобы ориентироваться на целевые показатели затрат, компания поощряет людей тестировать инструменты ИИ и искать лучшие способы работы. «Мы говорим людям: „Вот инструменты. Переосмыслите, что вы можете сделать“, — рассказывает она. — Конечно, некоторые показывают себя лучше, чем другие, а некоторым требуется больше подсказок и помощи. Но мы поощряем людей думать о том, что эти инструменты могут сделать в современном мире. И этот подход, похоже, хорошо работает». Важным элементом этой стратегии, по мнению Рот, является четкое определение того, какие инструменты приносят пользу, а какие нет, и в последнем случае — прекращение исследований. «На начальном этапе мы пробовали всё подряд в течение примерно шести недель. Можно было получить лицензию практически на всё, что угодно, дать возможность своей команде поэкспериментировать с этим, в зависимости от того, в какой сфере вы работаете, — говорит она. — Мы тестировали результаты, и если они были хорошими, мы внедряли это в других командах. А если результаты были плохими, мы прекращали это и двигались дальше. Поэтому я думаю, что стратегия доступа и экспериментирования на раннем этапе действительно важна». Определение надежных сценариев использования в производстве По словам Рот, компании, опережающие конкурентов в области генеративного и агентного ИИ, — это те, кто превращает исследования в сервисы производственного уровня, в то время как отстающие этого не делают. «Успешные фирмы сейчас начинают говорить: „Хорошо, мы выбрали этот инструмент, и мы будем его использовать, и поэтому мы изменим наши бизнес-процессы, чтобы работать по-новому“, и тогда вы начинаете видеть улучшения и экономию», — говорит она, делая важное уточнение: «Однако по-прежнему кажется, что большинство компаний находятся на начальной стадии. Думаю, те, кто преуспевает, очень точно определяют свои сценарии использования». В Thomson Reuters конкретные сценарии использования сосредоточены на пяти ключевых областях: разработка ПО, поддержка и обеспечение успеха клиентов, маркетинг, редакционная и контентная деятельность, а также основные технологические операции. «Конечно, мы хотели бы улучшить работу каждого, и мы сделаем все возможное, — говорит Рот. — Но это пять основных областей, где мы видим наибольший прогресс, и им уделяется наибольшее внимание». Инструменты ИИ для этих областей отыскиваются, тестируются и внедряются, а затем измеряется их эффективность. Сегодня 87% сотрудников Thomson Reuters активно используют инструменты ИИ в своей повседневной работе. Итак, как выглядит успешное внедрение генеративного и агентного ИИ в масштабах всей организации, и как это изменило повседневную практику сотрудников? Рот приводит в пример службы поддержки клиентов и продаж, где сотрудники могут использовать внутреннюю платформу ИИ компании, известную как Open Arena, и передовую модель Claude. Вместо того чтобы тратить часы на сбор информации от торговых представителей и из платформы Salesforce, сотрудники могут использовать утвержденные сервисы ИИ для получения ответов на запросы за считанные секунды. «В этом новом мире вы можете написать запрос в Claude, чтобы получить эту информацию; он может составить вам сводку, понять, каковы ключевые возможности, где могут быть какие-либо риски для данного клиента, или обращался ли он недавно в службу поддержки и был чем-то недоволен, и вы можете гораздо быстрее хорошо подготовится к встрече», — рассказывает она. Сотрудники Thomson Reuters также используют ИИ для исследования рынка, составления документов и отслеживания прибыльности продуктов и услуг. Главное, что усвоила Рот при внедрении ИИ в производство, накопив за последние несколько лет немалый опыт внедрения ИИ в операционную реальность глобального коллектива из 27 тыс. человек, — это то, что бизнес-руководители должны усердно работать над преодолением страхов профессионалов. «Люди не любят перемен. Ключевым моментом на раннем этапе было разъяснение сути ИИ, а затем оставалось лишь дать людям возможность поэкспериментировать и, надеюсь, перестать бояться новых технологий, — говорит она. — Сейчас мы достигли гораздо более зрелого уровня, и, учитывая то, что нам удалось внедрить, я думаю, что направление развития и последовательность действий одинаково важны»]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией на практике, но хорошая новость заключается в том, что специалисты могут его преодолеть, сосредоточившись на тщательных исследованиях и убедительных сценариях использования в производстве, сообщает портал &lltt;/em&ggtt;&lltt;em&ggtt;ZDNet&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно отчету глобальной контентной и технологической компании Thomson Reuters «2026 Future of Professionals Report», до 91% сотрудников заявляют, что их организации не в полной мере используют потенциал ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Исследование, основанное на глобальном опросе 1800 специалистов из различных секторов, показывает растущий разрыв между амбициями в области ИИ и реальностью, что становится все более серьезной проблемой, отмечает Кирсти Рот, операционный директор Thomson Reuters.&lltt;/p&ggtt;
&lltt;p&ggtt;Полтора года назад сотрудники с энтузиазмом экспериментировали с ИИ, а их руководители с готовностью поддерживали эти исследования. Сегодня ситуация изменилась. Специалисты тратят токены на использование ИИ, а их руководители обеспокоены ростом расходов на ИТ. Учитывая, что исследования MIT показывают, что 95% проектов в области ИИ не приносят пользы, неудивительно, что компании начинают сомневаться.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ крайне фрагментирован и раздроблен&lltt;/h3&ggtt;
&lltt;p&ggtt;«Люди начинают понимать, что эти технологии стоят больших денег, и они пока не обязательно видят от них пользу, — говорит Рот. — И поэтому разговор сводится к классическому вопросу управления изменениями: „Хорошо, у нас есть все эти технологии и все эти инструменты, но как мы можем реально изменить наши процессы и способы работы, чтобы быть более эффективными?“».&lltt;/p&ggtt;
&lltt;p&ggtt;Новые развивающиеся технологии, от агентных моделей ИИ до инструментов глубокого исследования, будут продолжать проникать в бизнес. Как считает генеральный директор Boomi Стив Лукас, общее положение дел в области ИИ крайне фрагментировано и раздроблено: «Сейчас профессионалы знакомятся со множеством терминов — передовые модели, частные модели, доменные модели, модели с открытыми весами, агентные структуры, агентные механизмы и агентные циклы — которые не существовали еще несколько месяцев назад, не говоря уже о нескольких годах».&lltt;/p&ggtt;
&lltt;p&ggtt;Рот, опираясь на исследование своей фирмы и личный опыт, предлагает компаниям и их специалистам, получающим выгоду от ИИ, сосредоточиться на двух областях: тщательных исследованиях и надежных сценариях использования в производстве.&lltt;/p&ggtt;
&lltt;h3&ggtt;Поддержка тщательных исследований&lltt;/h3&ggtt;
&lltt;p&ggtt;Профессионалы, принявшие участие в опросе, четко понимают, что должны делать их инструменты ИИ: защищать конфиденциальные данные (96%), обосновывать результаты авторитетным контентом (94%) и предоставлять объяснимые и обоснованные рассуждения (90%). Однако двое из пяти специалистов (41%), использующих ИИ в своей работе, отмечают, что у них нет доступа к высококачественным инструментам.&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно исследованию, даже при наличии ИИ-стратегии ее реализация часто отстает. Чуть более трети (35%) специалистов в компаниях, имеющих четко определенную ИИ-стратегию, говорят, что этот подход не проявляется в их повседневной работе.&lltt;/p&ggtt;
&lltt;p&ggtt;По словам Рот, одно из объяснений — это то, что она называет «инструментальным взрывом» («tool blast»), когда организации навязывают сотрудникам широкий спектр ИИ-сервисов без четкого понимания бизнес-результатов. «Я слышала, как люди говорят: „Мне дали все это. Но что я должен с этим делать?“ Слишком многие компании не понимают, какие инструменты должны использовать сотрудники. Я думаю, что в этом случае очень трудно увидеть рост, за исключением того, что ваши затраты на ПО значительно возрастут», — отмечает она.&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно &lltt;a href="https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure"&ggtt;прогнозу&lltt;/a&ggtt; Gartner, 40% предприятий к 2027 г. сократят использование или выведут из эксплуатации автономных агентов ИИ из-за опасений по поводу их ценности.&lltt;/p&ggtt;
&lltt;p&ggtt;Рот говорит, что вдумчивые бизнес-руководители ищут действенные решения на основе ИИ для сложных задач, предоставляя специалистам возможность изучать новые технологии, не принимая на себя слишком большого риска. Это то, что она делает в Thomson Reuters, где, по ее словам, придерживаются непредвзятого подхода к генеративному ИИ. «Если у вас появляется классный инструмент, и вы работаете в отделах маркетинга, продаж или программирования, и хотите его попробовать, мы позволим вам это сделать», — поясняет она.&lltt;/p&ggtt;
&lltt;p&ggtt;Рот отмечает, что вместо того, чтобы ориентироваться на целевые показатели затрат, компания поощряет людей тестировать инструменты ИИ и искать лучшие способы работы. «Мы говорим людям: „Вот инструменты. Переосмыслите, что вы можете сделать“, — рассказывает она. — Конечно, некоторые показывают себя лучше, чем другие, а некоторым требуется больше подсказок и помощи. Но мы поощряем людей думать о том, что эти инструменты могут сделать в современном мире. И этот подход, похоже, хорошо работает».&lltt;/p&ggtt;
&lltt;p&ggtt;Важным элементом этой стратегии, по мнению Рот, является четкое определение того, какие инструменты приносят пользу, а какие нет, и в последнем случае — прекращение исследований. «На начальном этапе мы пробовали всё подряд в течение примерно шести недель. Можно было получить лицензию практически на всё, что угодно, дать возможность своей команде поэкспериментировать с этим, в зависимости от того, в какой сфере вы работаете, — говорит она. — Мы тестировали результаты, и если они были хорошими, мы внедряли это в других командах. А если результаты были плохими, мы прекращали это и двигались дальше. Поэтому я думаю, что стратегия доступа и экспериментирования на раннем этапе действительно важна».&lltt;/p&ggtt;
&lltt;h3&ggtt;Определение надежных сценариев использования в производстве&lltt;/h3&ggtt;
&lltt;p&ggtt;По словам Рот, компании, опережающие конкурентов в области генеративного и агентного ИИ, — это те, кто превращает исследования в сервисы производственного уровня, в то время как отстающие этого не делают.&lltt;/p&ggtt;
&lltt;p&ggtt;«Успешные фирмы сейчас начинают говорить: „Хорошо, мы выбрали этот инструмент, и мы будем его использовать, и поэтому мы изменим наши бизнес-процессы, чтобы работать по-новому“, и тогда вы начинаете видеть улучшения и экономию», — говорит она, делая важное уточнение: «Однако по-прежнему кажется, что большинство компаний находятся на начальной стадии. Думаю, те, кто преуспевает, очень точно определяют свои сценарии использования».&lltt;/p&ggtt;
&lltt;p&ggtt;В Thomson Reuters конкретные сценарии использования сосредоточены на пяти ключевых областях: разработка ПО, поддержка и обеспечение успеха клиентов, маркетинг, редакционная и контентная деятельность, а также основные технологические операции.&lltt;/p&ggtt;
&lltt;p&ggtt;«Конечно, мы хотели бы улучшить работу каждого, и мы сделаем все возможное, — говорит Рот. — Но это пять основных областей, где мы видим наибольший прогресс, и им уделяется наибольшее внимание». Инструменты ИИ для этих областей отыскиваются, тестируются и внедряются, а затем измеряется их эффективность. Сегодня 87% сотрудников Thomson Reuters активно используют инструменты ИИ в своей повседневной работе.&lltt;/p&ggtt;
&lltt;p&ggtt;Итак, как выглядит успешное внедрение генеративного и агентного ИИ в масштабах всей организации, и как это изменило повседневную практику сотрудников?&lltt;/p&ggtt;
&lltt;p&ggtt;Рот приводит в пример службы поддержки клиентов и продаж, где сотрудники могут использовать внутреннюю платформу ИИ компании, известную как Open Arena, и передовую модель Claude.&lltt;/p&ggtt;
&lltt;p&ggtt;Вместо того чтобы тратить часы на сбор информации от торговых представителей и из платформы Salesforce, сотрудники могут использовать утвержденные сервисы ИИ для получения ответов на запросы за считанные секунды. «В этом новом мире вы можете написать запрос в Claude, чтобы получить эту информацию; он может составить вам сводку, понять, каковы ключевые возможности, где могут быть какие-либо риски для данного клиента, или обращался ли он недавно в службу поддержки и был чем-то недоволен, и вы можете гораздо быстрее хорошо подготовится к встрече», — рассказывает она.&lltt;/p&ggtt;
&lltt;p&ggtt;Сотрудники Thomson Reuters также используют ИИ для исследования рынка, составления документов и отслеживания прибыльности продуктов и услуг.&lltt;/p&ggtt;
&lltt;p&ggtt;Главное, что усвоила Рот при внедрении ИИ в производство, накопив за последние несколько лет немалый опыт внедрения ИИ в операционную реальность глобального коллектива из 27 тыс. человек, — это то, что бизнес-руководители должны усердно работать над преодолением страхов профессионалов.&lltt;/p&ggtt;
&lltt;p&ggtt;«Люди не любят перемен. Ключевым моментом на раннем этапе было разъяснение сути ИИ, а затем оставалось лишь дать людям возможность поэкспериментировать и, надеюсь, перестать бояться новых технологий, — говорит она. — Сейчас мы достигли гораздо более зрелого уровня, и, учитывая то, что нам удалось внедрить, я думаю, что направление развития и последовательность действий одинаково важны».&lltt;/p&ggtt;]]></source>
<adate>02.09.2026</adate>
<dbid>235443</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[SimpleOne выпустила версию ITAM 1.8.0 с поддержкой сканеров штрихкодов и автоматическим расчетом затрат на активы]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235442]]></link>
<description><![CDATA[SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne ITAM. Обновление сокращает время инвентаризации оборудования, позволяет учитывать активы не только по складам, но и по конкретным офисам и кабинетам, а также избавляет финансовые службы от ручных расчетов при работе с затратами в разных валютах. Ключевым нововведением версии 1.8.0 стала возможность подключения сканера штрихкодов при проведении инвентаризации склада. Ранее в системе была реализована инвентаризация с помощью камеры мобильного телефона — теперь к задаче можно подключить внешний сканер, который считывает штрихкод с инвентарным номером актива. Это ускоряет обход крупных складов: сканер считывает метки быстрее и точнее камеры телефона, а данные сразу сверяются со списком активов и попадают в ведомость инвентаризации без ручного переноса. Дополнительно в системе появился новый тип задачи — инвентаризация по расположению. Она позволяет пересчитывать активы не по складам, а по фактическому месту их использования — конкретному офису, этажу или кабинету, даже если по учету оборудование числится за разными складами. Это особенно удобно для компаний с распределенной сетью офисов: можно провести точечную проверку одного подразделения, не запуская инвентаризацию всего склада. В 1.8.0 автоматизирован расчет совокупных затрат на актив с учетом конвертации валют. Раньше, если затраты на актив фиксировались в разных валютах, посчитать реальную стоимость владения оборудованием можно было только вручную, сводя данные в отдельных таблицах. Теперь система автоматически складывает все затраты по активу и автоматически приводит их к единой валюте по актуальному курсу. Финансовые и ИТ-руководители получают точную картину затрат на актив без дополнительных расчетов и могут быстрее принимать решения о ремонте, замене или списании оборудования. «Когда данные о том, где стоит актив и сколько он реально стоит, хранятся в одной системе, ИТ-отдел начинает говорить с финансами на одном языке. Решения о ремонте, замене или списании принимаются на цифрах, а не на ощущениях. Именно так выглядит зрелый подход к управлению ИТ-активами», — отметил Руслан Шарипов, генеральный директор SimpleOne, корпорация ITG. SimpleOne ITAM 1.8.0 уже доступна для действующих клиентов компании. Новые пользователи могут запросить демонстрацию продукта на сайте SimpleOne]]></description>
<source><![CDATA[&lltt;p&ggtt;SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne ITAM. Обновление сокращает время инвентаризации оборудования, позволяет учитывать активы не только по складам, но и по конкретным офисам и кабинетам, а также избавляет финансовые службы от ручных расчетов при работе с затратами в разных валютах.&lltt;/p&ggtt;
&lltt;p&ggtt;Ключевым нововведением версии 1.8.0 стала возможность подключения сканера штрихкодов при проведении инвентаризации склада. Ранее в системе была реализована инвентаризация с помощью камеры мобильного телефона — теперь к задаче можно подключить внешний сканер, который считывает штрихкод с инвентарным номером актива. Это ускоряет обход крупных складов: сканер считывает метки быстрее и точнее камеры телефона, а данные сразу сверяются со списком активов и попадают в ведомость инвентаризации без ручного переноса.&lltt;/p&ggtt;
&lltt;p&ggtt;Дополнительно в системе появился новый тип задачи — инвентаризация по расположению. Она позволяет пересчитывать активы не по складам, а по фактическому месту их использования — конкретному офису, этажу или кабинету, даже если по учету оборудование числится за разными складами. Это особенно удобно для компаний с распределенной сетью офисов: можно провести точечную проверку одного подразделения, не запуская инвентаризацию всего склада.&lltt;/p&ggtt;
&lltt;p&ggtt;В 1.8.0 автоматизирован расчет совокупных затрат на актив с учетом конвертации валют. Раньше, если затраты на актив фиксировались в разных валютах, посчитать реальную стоимость владения оборудованием можно было только вручную, сводя данные в отдельных таблицах. Теперь система автоматически складывает все затраты по активу и автоматически приводит их к единой валюте по актуальному курсу. Финансовые и ИТ-руководители получают точную картину затрат на актив без дополнительных расчетов и могут быстрее принимать решения о ремонте, замене или списании оборудования.&lltt;/p&ggtt;
&lltt;p&ggtt;«Когда данные о том, где стоит актив и сколько он реально стоит, хранятся в одной системе, ИТ-отдел начинает говорить с финансами на одном языке. Решения о ремонте, замене или списании принимаются на цифрах, а не на ощущениях. Именно так выглядит зрелый подход к управлению ИТ-активами», — отметил Руслан Шарипов, генеральный директор SimpleOne, корпорация ITG.&lltt;/p&ggtt;
&lltt;p&ggtt;SimpleOne ITAM 1.8.0 уже доступна для действующих клиентов компании. Новые пользователи могут запросить демонстрацию продукта на сайте SimpleOne.&lltt;/p&ggtt;]]></source>
<adate>01.09.2026</adate>
<dbid>235442</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Обновление OpenStack одной кнопкой: зачем это нужно и почему это сложнее, чем кажется]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235439]]></link>
<description><![CDATA[Российский рынок частных облаков последние несколько лет активно смещается в сторону OpenStack — как альтернативы ушедшим вендорам и как основы для построения отечественных платформ. OpenStack давно перестал быть экзотикой для узкого круга энтузиастов, ведь на нём сегодня строятся частные облака у операторов, банков и промышленных компаний, которым нужен контроль над инфраструктурой без привязки к одному вендору. Но у этого перехода есть обратная сторона, о которой на старте проекта задумываются реже, чем стоило бы: облако на OpenStack нужно не только развернуть, но и потом годами обновлять, своевременно реагируя на выявленные бреши в безопасности, устанавливая новые релизы компонентов и удовлетворяя требования регуляторов. И если сам факт перехода на OpenStack давно перестал быть новостью, то вопрос «а как это облако вообще обновлять, когда придёт время» у большинства эксплуатирующих команд до сих пор упирается в ручной труд, дефицитную экспертизу и риск простоя. То есть проблема не в том, чтобы просто поднять OpenStack, а в том, чтобы удерживать его в рабочем и безопасном состоянии на протяжении всего жизненного цикла. Разберёмся, почему обновление OpenStack остаётся сложной инженерной задачей, какие этапы этого процесса можно автоматизировать и какие ограничения необходимо заложить в механизм обновления, чтобы автоматизация сама не стала источником риска. Проблема, о которую спотыкается почти каждый оператор облака OpenStack принято хвалить за гибкость и открытость, но за кулисами этой гибкости стоит один из самых болезненных процессов в жизненном цикле облачной платформы — обновление. В отличие от монолитных систем, OpenStack — это фреймворк из полутора-двух десятков взаимозависимых сервисов (Keystone, Nova, Neutron, Cinder, Glance, Placement и т. д.), каждый со своей базой данных, своими миграциями схемы, своим порядком запуска и своими требованиями к совместимости версий API. Обновить такую систему не значит «поставить новую версию пакета». Это значит провести десятки взаимосвязанных операций в строго определённой последовательности, не нарушив по пути ни одну зависимость. Именно поэтому в большинстве продуктивных инсталляций OpenStack обновление до сих пор остаётся ручной, экспертной и тревожной процедурой, а не рутинной операцией. Что именно усложняет обновление OpenStack Если разложить проблему на составляющие, получится примерно такой список (и он актуален независимо от того, разворачивается ли OpenStack «руками», через Ansible-плейбуки или через Kubernetes-операторы): 	Порядок и зависимости сервисов. Часть компонентов должна обновляться раньше других — например, Keystone и Placement обычно идут в начале цепочки, а сервисы, зависящие от их API, следом. Ошибка в порядке приводит к рассинхронизации версий API между сервисами и падению запросов. 	Миграции баз данных. Каждое обновление тянет за собой миграции схем в базах Nova, Neutron, Cinder и других сервисов. Некоторые миграции требуют «миграции данных без остановки» ещё на текущей версии — если этот шаг пропущен, обновление может завершиться с повреждением данных. 	Простой сервисов управления и, в худшем случае, сетей и вычислительных ресурсов пользователей. Даже при аккуратном планировании слой управления обычно недоступен часть времени обновления. Плохо спроектированный процесс способен зацепить и вычислительные ресурсы пользователей — то есть повлиять на уже работающие виртуальные машины и пространство пользователей. 	Непредсказуемое поведение при сбое посередине процесса. Полноценный откат обновления OpenStack на предыдущую версию сама по себе нетривиальная и рискованная операция: схемы БД уже частично мигрированы, часть контейнеров и конфигураций уже обновлена, и «просто вернуть как было» технически далеко не всегда возможно. Поэтому куда важнее другое качество процесса — способность вовремя остановиться в момент сбоя, не разрушив кластер, и точно показать администратору, на каком шаге и что пошло не так, вместо того чтобы продолжать обновление вслепую или бросить систему в непонятном промежуточном состоянии. 	Человеческий фактор и разрыв компетенций. Классический процесс обновления — это последовательность команд в CLI, правка YAML-файлов инвентаря и конфигурации, запуск плейбуков с нужными флагами в нужном порядке. Уровень экспертизы, который для этого требуется, есть далеко не в каждой команде эксплуатации, а дефицит сертифицированных OpenStack-инженеров на рынке — известная проблема. 	Долгий цикл патчинга безопасности. Когда обновление — это рискованный процесс и многочасовая процедура, а не «нажал кнопку и забыл», критические обновления безопасности откладываются дольше, чем следовало бы. Разрыв между выходом патча и его применением в продуктиве — это прямой риск для периметра. 	Дрейф конфигурации между средами. В компаниях с несколькими окружениями (dev/test/prod) ручные обновления быстро приводят к тому, что конфигурации расходятся, и то, что сработало на тесте, ломается в проде именно из-за незамеченного отличия. Как эти проблемы решаются (или не решаются) в разных реализациях OpenStack Здесь стоит сразу отметить: экосистема способов развернуть OpenStack довольно широкая, и подход к обновлению принципиально различается в зависимости от выбранного инструментария. 	 Kolla-Ansible (в том числе на связке с Docker или Podman) разворачивает сервисы в контейнерах и обновляет их через Ansible-плейбуки (kolla-ansible upgrade). Классически это CLI-процедура: инженер вручную правит globals.yml, инвентарь, версии тегов образов и запускает плейбук, понимая, что происходит на каждом шаге. Вынос процесса в CI/CD позволяет сделать обновление воспроизводимым и версионируемым, а также сократить количество ручных операций. Но сам по себе CI/CD не снимает требования к квалификации специалиста. Кто-то по-прежнему должен понимать структуру пайплайна, интерпретировать результаты выполнения отдельных стадий и принимать решение при ошибках. Поэтому автоматизация исполнения и автоматизация принятия решений при обновлении — это разные задачи. 	 OpenStack-Ansible (OSA) концептуально близок к Kolla-Ansible, но использует LXC-контейнеры или venv вместо Docker/Podman-образов. Процесс обновления так же построен на плейбуках и так же требует ручного сопровождения и экспертизы. 	 TripleO / director-based установки (классический подход Red Hat OpenStack Platform до недавних версий) добавляют ещё один слой сложности — undercloud и overcloud обновляются отдельно, а сам процесс исторически считался одним из самых трудоёмких в экосистеме. 	 Charmed OpenStack от Canonical на базе Juju ближе всего к идее «графического» управления жизненным циклом: Juju GUI позволяет визуально управлять обновлением charms, что снижает порог входа по сравнению с чистым CLI, хотя полноценной автоматизации «в один клик» с предварительными проверками и остановкой на проблемном шаге это тоже не даёт из коробки. 	MicroStack / Sunbeam (тоже Canonical, snap-based) упрощают обновления до команды snap refresh, но это решение ориентировано на небольшие и edge-инсталляции, а не на полномасштабные продуктивные облака. 	Kubernetes-нативные подходы (OpenStack-Helm, Airship, а также коммерческий Mirantis OpenStack for Kubernetes) выигрывают за счёт того, что опираются на нативные механизмы Kubernetes — поэтапное обновление, readiness/liveness probes, helm rollback. Именно в этом сегменте чаще всего встречаются продукты с полноценным веб-интерфейсом управления обновлениями, потому что Kubernetes-примитивы изначально спроектированы для автоматизации подобных процессов. Общий вывод, к которому подводит этот обзор, хочется сформулировать следующим образом. Проблема «обновление зависит от инженера с CLI» и проблема «обновление недоступно как самообслуживаемая операция» — это два разных уровня, и решаются они не одним и тем же шагом. Вынос процесса в CI/CD (как в случае с GitLab у связки Kolla-Ansible/Podman) решает первую: обновление становится воспроизводимым, версионируемым и не требует ручных команд в терминале. Но оно не решает вторую — запустить и проконтролировать пайплайн по-прежнему может только тот, кто ориентируется в GitLab, а не в продукте, которым он управляет. Поэтому интерфейс с кнопкой запуска сам по себе ещё не делает обновление автоматизированным. Существеннее то, какие проверки выполняются до старта, как система учитывает зависимости компонентов, может ли она остановить процесс при ошибке и насколько подробно сообщает администратору о состоянии инфраструктуры. Именно эти механизмы определяют, можно ли передать часть решений от инженера автоматике. Что должно скрываться за кнопкой автоматического обновления Автоматизация обновления OpenStack не сводится к переносу последовательности команд из CLI в CI/CD. Пайплайн может выполнять подготовленные операции, фиксировать стадии и сохранять результаты их выполнения. Но сам по себе он не определяет, какие действия допустимы в текущем состоянии инфраструктуры, в какой последовательности их выполнять и когда процесс необходимо остановить. Поэтому поверх исполнительного слоя нужна логика, которая учитывает зависимости сервисов OpenStack, совместимость версий, состояние узлов и результаты проверок после каждого этапа. Иначе автоматизируется только запуск команд, а принятие решений по-прежнему остается на инженере. При этом важно разделять два разных процесса: обновление хостовой операционной системы и переход на новую версию самого OpenStack. Внешне они похожи, но предъявляют разные требования к последовательности операций и допустимому уровню параллелизма. Патчинг хостовой ОС: ротация узлов При установке пакетов и обновлений безопасности на контроллерах и гипервизорах можно использовать принцип последовательной ротации. Контроллер выводится в режим обслуживания, получает обновления, при необходимости перезагружается и возвращается в кластер. Только после проверки его состояния процесс переходит к следующему узлу. Пока один контроллер обслуживается, остальные продолжают обрабатывать запросы, что позволяет сохранить доступность управляющего слоя. Для гипервизоров возможна другая схема: обновление по одному узлу или группами в пределах зоны доступности. Размер такой группы должен учитывать доступный запас вычислительных ресурсов. Перед обслуживанием с гипервизора переносятся виртуальные машины, сам узел выводится из эксплуатации, обновляется и после проверки возвращается в строй. Одновременно выводить в обслуживание все гипервизоры одной зоны доступности нельзя. Поэтому механизм автоматизации должен ограничивать уровень параллелизма и учитывать, достаточно ли оставшихся ресурсов для размещения нагрузки. Такая схема особенно важна для установки обновлений безопасности. Ее задача не просто ускорить патчинг, а формализовать операции, которые при ручном выполнении зависят от последовательности действий конкретного инженера: миграцию нагрузки, перевод узла в обслуживание, установку обновлений, перезагрузку и проверку его состояния перед переходом к следующему этапу. Обновление версии OpenStack: почему поэтапность не всегда означает меньший риск При переходе между версиями OpenStack логика сложнее. До начала обновления нужно определить, поддерживается ли переход между исходным и целевым релизами. Для этого может использоваться заранее подготовленная матрица совместимости, учитывающая версии компонентов и допустимые маршруты обновления. Отдельный вопрос — порядок обновления контроллеров. Интуитивно безопасной кажется последовательная схема, при которой узлы переводятся на новую версию один за другим. Однако для конкретной архитектуры такой подход необходимо проверять с учетом совместимости API и компонентов. Если часть сервисов уже работает на новой версии, а часть остается на старой, может возникнуть период, когда управляющий слой работает в несогласованном состоянии. Поэтому последовательность операций должна определяться не универсальным принципом «обновлять по одному», а особенностями конкретного релиза и архитектуры развертывания. Не менее важен контроль состояния системы во время перехода. До старта должны выполняться системные проверки. После критических операций необходимо проверять работоспособность компонентов. Если очередная проверка не пройдена, дальнейшие действия следует остановить и зафиксировать этап, на котором возникла ошибка. Для OpenStack такой сценарий зачастую безопаснее попытки автоматически вернуть всю систему в исходное состояние. Если часть схем баз данных уже мигрирована, а некоторые компоненты обновлены, полноценный откат может оказаться отдельной сложной и рискованной процедурой. Поэтому от механизма автоматизации требуется прежде всего контролируемая остановка и точная диагностика. Очередность обновления контроллеров и гипервизоров также должна учитывать зависимости между управляющим и вычислительным слоями. Переход вычислительных узлов на новую версию следует начинать только после того, как управляющий слой приведен в согласованное состояние. После этого гипервизоры можно обновлять по одному или группами, предварительно освобождая их от пользовательской нагрузки. Что именно нужно автоматизировать При оценке механизма обновления OpenStack важно смотреть не только на инструмент, который исполняет команды. Ansible, CI/CD или Kubernetes позволяют автоматизировать значительную часть технических операций, но сами по себе не определяют, можно ли выполнять конкретное обновление в текущем состоянии инфраструктуры. Более высокий уровень автоматизации появляется там, где формализована логика принятия решений: проверяется допустимость перехода между версиями, учитывается состояние компонентов, контролируется размер одновременно обслуживаемой группы узлов, соблюдается очередность между управляющим и вычислительным слоями, а дальнейшие действия блокируются при возникновении ошибки. Именно поэтому перенос команд из терминала в пайплайн решает только часть задачи. Он делает процесс воспроизводимым и версионируемым, но не заменяет механизм управления жизненным циклом облачной платформы. Что должен видеть администратор Способ запуска обновления вторичен. Это может быть CLI, CI/CD или графический интерфейс. Гораздо важнее, какую информацию получает администратор до начала процесса и во время его выполнения. До старта обновления должны быть понятны текущие версии компонентов, доступный целевой релиз, результаты предварительных проверок и ограничения выбранного сценария. Во время обновления необходимы данные о текущем этапе, состоянии узлов и возникших ошибках. Задача интерфейса в данном случае не в том, чтобы скрыть сложность OpenStack за одной кнопкой. Он должен дать администратору понятную точку управления процессом, тогда как правила последовательности, совместимости и безопасной остановки должны соблюдаться автоматически. От чего зависит длительность обновления Продолжительность обновления нельзя свести к одному нормативному значению. Она зависит от числа узлов, состава компонентов, объема миграций, пользовательской нагрузки и расстояния между исходным и целевым релизами. Последовательный переход между соседними релизами, как правило, требует меньше промежуточных изменений. Если же обновление затрагивает несколько релизов, приходится учитывать больше изменений в компонентах, схемах баз данных и конфигурациях. Отдельно в технологическое окно закладывается время на освобождение гипервизоров от нагрузки, миграцию виртуальных машин, обслуживание узлов и проверки после обновления. Поэтому задача автоматизации состоит не только в сокращении общей продолжительности процедуры. Не менее важно сделать состав операций и их последовательность предсказуемыми, чтобы окно обслуживания можно было планировать заранее. Почему обновление нужно тестировать заранее Автоматизация не отменяет предварительной подготовки обновления. Для каждого поддерживаемого перехода необходимо проверить совместимость компонентов, миграции баз данных, последовательность операций и работу основных сценариев после установки новой версии. Чем больше расстояние между исходным и целевым релизами, тем больше промежуточных изменений приходится учитывать. Поэтому наличие новой версии OpenStack еще не означает, что на нее можно безопасно перейти из любого предыдущего состояния. Для эксплуатации это означает, что маршрут обновления должен быть заранее определен и протестирован. Автоматический механизм затем воспроизводит уже проверенную последовательность, контролируя состояние системы на каждом критическом этапе. Когда обновление OpenStack действительно можно считать автоматизированным Кнопка запуска сама по себе еще не делает обновление автоматическим. За ней может находиться тот же набор команд, который раньше инженер последовательно выполнял вручную. Более зрелый подход начинается с автоматизации не только исполнения, но и части решений. Система проверяет состояние инфраструктуры до старта, учитывает совместимость версий и зависимости компонентов, ограничивает потенциально опасный параллелизм, контролирует результат отдельных операций и прекращает дальнейшие действия, если состояние системы отклоняется от ожидаемого. При этом полностью исключить инженерную экспертизу невозможно. OpenStack остается сложной распределенной системой, а нестандартные ошибки могут требовать ручной диагностики. Задача автоматизации в другом: убрать из регулярного процесса повторяющиеся операции и решения, которые можно формализовать, снизить зависимость результата от ручных действий и оставить специалистам действительно нестандартные ситуации. Поэтому зрелость механизма обновления определяется не количеством операций, сведенных к одному нажатию, а тем, насколько предсказуемо система проходит штатный сценарий и насколько управляемо ведет себя при возникновении ошибки. По мере роста OpenStack-инфраструктуры такая автоматизация становится частью управления ее жизненным циклом, поскольку без нее увеличиваются трудозатраты на эксплуатацию и зависимость от ручных операций. #IMAGE_235440#]]></description>
<source><![CDATA[&lltt;p&ggtt;Российский рынок частных облаков последние несколько лет активно смещается в&nbsp;сторону OpenStack&nbsp;— как альтернативы ушедшим вендорам и&nbsp;как основы для построения отечественных платформ. OpenStack давно перестал быть экзотикой для узкого круга энтузиастов, ведь на&nbsp;нём сегодня строятся частные облака у&nbsp;операторов, банков и&nbsp;промышленных компаний, которым нужен контроль над инфраструктурой без привязки к&nbsp;одному вендору. Но&nbsp;у&nbsp;этого перехода есть обратная сторона, о&nbsp;которой на&nbsp;старте проекта задумываются реже, чем стоило&nbsp;бы: облако на&nbsp;OpenStack нужно не&nbsp;только развернуть, но&nbsp;и&nbsp;потом годами обновлять, своевременно реагируя на&nbsp;выявленные бреши в&nbsp;безопасности, устанавливая новые релизы компонентов и&nbsp;удовлетворяя требования регуляторов. И&nbsp;если сам факт перехода на&nbsp;OpenStack давно перестал быть новостью, то&nbsp;вопрос «а&nbsp;как это облако вообще обновлять, когда придёт время» у&nbsp;большинства эксплуатирующих команд до&nbsp;сих пор упирается в&nbsp;ручной труд, дефицитную экспертизу и&nbsp;риск простоя. То&nbsp;есть проблема не&nbsp;в&nbsp;том, чтобы просто поднять OpenStack, а&nbsp;в&nbsp;том, чтобы удерживать его в&nbsp;рабочем и&nbsp;безопасном состоянии на&nbsp;протяжении всего жизненного цикла. Разберёмся, почему обновление OpenStack остаётся сложной инженерной задачей, какие этапы этого процесса можно автоматизировать и&nbsp;какие ограничения необходимо заложить в&nbsp;механизм обновления, чтобы автоматизация сама не&nbsp;стала источником риска.&lltt;/p&ggtt;
&lltt;h2&ggtt; Проблема, о&nbsp;которую спотыкается почти каждый оператор облака &lltt;/h2&ggtt;
&lltt;p&ggtt;OpenStack принято хвалить за&nbsp;гибкость и&nbsp;открытость, но&nbsp;за&nbsp;кулисами этой гибкости стоит один из&nbsp;самых болезненных процессов в&nbsp;жизненном цикле облачной платформы&nbsp;— обновление. В&nbsp;отличие от&nbsp;монолитных систем, OpenStack&nbsp;— это фреймворк из&nbsp;полутора-двух десятков взаимозависимых сервисов (Keystone, Nova, Neutron, Cinder, Glance, Placement и&nbsp;т.&nbsp;д.), каждый со&nbsp;своей базой данных, своими миграциями схемы, своим порядком запуска и&nbsp;своими требованиями к&nbsp;совместимости версий API. Обновить такую систему не&nbsp;значит «поставить новую версию пакета». Это значит провести десятки взаимосвязанных операций в&nbsp;строго определённой последовательности, не&nbsp;нарушив по&nbsp;пути ни&nbsp;одну зависимость.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому в&nbsp;большинстве продуктивных инсталляций OpenStack обновление до&nbsp;сих пор остаётся ручной, экспертной и&nbsp;тревожной процедурой, а&nbsp;не&nbsp;рутинной операцией.&lltt;/p&ggtt;
&lltt;h2&ggtt;Что именно усложняет обновление OpenStack&lltt;/h2&ggtt;
&lltt;p&ggtt;Если разложить проблему на&nbsp;составляющие, получится примерно такой список (и&nbsp;он&nbsp;актуален независимо от&nbsp;того, разворачивается&nbsp;ли OpenStack «руками», через Ansible-плейбуки или через Kubernetes-операторы):&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Порядок и&nbsp;зависимости сервисов.&lltt;/strong&ggtt; Часть компонентов должна обновляться раньше других&nbsp;— например, Keystone и&nbsp;Placement обычно идут в&nbsp;начале цепочки, а&nbsp;сервисы, зависящие от&nbsp;их&nbsp;API, следом. Ошибка в&nbsp;порядке приводит к&nbsp;рассинхронизации версий API между сервисами и&nbsp;падению запросов.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Миграции баз данных.&lltt;/strong&ggtt; Каждое обновление тянет за&nbsp;собой миграции схем в&nbsp;базах Nova, Neutron, Cinder и&nbsp;других сервисов. Некоторые миграции требуют «миграции данных без остановки» ещё на&nbsp;текущей версии&nbsp;— если этот шаг пропущен, обновление может завершиться с&nbsp;повреждением данных.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Простой сервисов управления&nbsp;и, в&nbsp;худшем случае, сетей и&nbsp;вычислительных ресурсов пользователей.&lltt;/strong&ggtt; Даже при аккуратном планировании слой управления обычно недоступен часть времени обновления. Плохо спроектированный процесс способен зацепить и&nbsp;вычислительные ресурсы пользователей&nbsp;— то&nbsp;есть повлиять на&nbsp;уже работающие виртуальные машины и&nbsp;пространство пользователей.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Непредсказуемое поведение при сбое посередине процесса.&lltt;/strong&ggtt; Полноценный откат обновления OpenStack на&nbsp;предыдущую версию сама по&nbsp;себе нетривиальная и&nbsp;рискованная операция: схемы&nbsp;БД уже частично мигрированы, часть контейнеров и&nbsp;конфигураций уже обновлена, и&nbsp;«просто вернуть как было» технически далеко не&nbsp;всегда возможно. Поэтому куда важнее другое качество процесса&nbsp;— способность вовремя остановиться в&nbsp;момент сбоя, не&nbsp;разрушив кластер, и&nbsp;точно показать администратору, на&nbsp;каком шаге и&nbsp;что пошло не&nbsp;так, вместо того чтобы продолжать обновление вслепую или бросить систему в&nbsp;непонятном промежуточном состоянии.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Человеческий фактор и&nbsp;разрыв компетенций.&lltt;/strong&ggtt; Классический процесс обновления&nbsp;— это последовательность команд в&nbsp;CLI, правка YAML-файлов инвентаря и&nbsp;конфигурации, запуск плейбуков с&nbsp;нужными флагами в&nbsp;нужном порядке. Уровень экспертизы, который для этого требуется, есть далеко не&nbsp;в&nbsp;каждой команде эксплуатации, а&nbsp;дефицит сертифицированных OpenStack-инженеров на&nbsp;рынке&nbsp;— известная проблема.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Долгий цикл патчинга безопасности.&lltt;/strong&ggtt; Когда обновление&nbsp;— это рискованный процесс и&nbsp;многочасовая процедура, а&nbsp;не&nbsp;«нажал кнопку и&nbsp;забыл», критические обновления безопасности откладываются дольше, чем следовало&nbsp;бы. Разрыв между выходом патча и&nbsp;его применением в&nbsp;продуктиве&nbsp;— это прямой риск для периметра.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Дрейф конфигурации между средами.&lltt;/strong&ggtt; В&nbsp;компаниях с&nbsp;несколькими окружениями (dev/test/prod) ручные обновления быстро приводят к&nbsp;тому, что конфигурации расходятся, и&nbsp;то, что сработало на&nbsp;тесте, ломается в&nbsp;проде именно из-за незамеченного отличия.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h2&ggtt;Как эти проблемы решаются (или не&nbsp;решаются) в&nbsp;разных реализациях OpenStack&lltt;/h2&ggtt;
&lltt;p&ggtt;Здесь стоит сразу отметить: экосистема способов развернуть OpenStack довольно широкая, и&nbsp;подход к&nbsp;обновлению принципиально различается в&nbsp;зависимости от&nbsp;выбранного инструментария.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Kolla-Ansible&lltt;/strong&ggtt; (в&nbsp;том числе на&nbsp;связке с&nbsp;Docker или Podman) разворачивает сервисы в&nbsp;контейнерах и&nbsp;обновляет их&nbsp;через Ansible-плейбуки (kolla-ansible upgrade). Классически это &lltt;nobr&ggtt;CLI-процедура:&lltt;/nobr&ggtt; инженер вручную правит globals.yml, инвентарь, версии тегов образов и&nbsp;запускает плейбук, понимая, что происходит на&nbsp;каждом шаге. Вынос процесса в&nbsp;CI/CD позволяет сделать обновление воспроизводимым и&nbsp;версионируемым, а&nbsp;также сократить количество ручных операций. Но&nbsp;сам по&nbsp;себе CI/CD&nbsp;не снимает требования к&nbsp;квалификации специалиста. Кто-то по-прежнему должен понимать структуру пайплайна, интерпретировать результаты выполнения отдельных стадий и&nbsp;принимать решение при ошибках. Поэтому автоматизация исполнения и&nbsp;автоматизация принятия решений при обновлении&nbsp;— это разные задачи.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;OpenStack-Ansible (OSA)&lltt;/strong&ggtt; концептуально близок к&nbsp;Kolla-Ansible, но&nbsp;использует &lltt;nobr&ggtt;LXC-контейнеры&lltt;/nobr&ggtt; или venv вместо Docker/Podman-образов. Процесс обновления так&nbsp;же построен на&nbsp;плейбуках и&nbsp;так&nbsp;же требует ручного сопровождения и&nbsp;экспертизы.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;TripleO&nbsp;/ director-based установки&lltt;/strong&ggtt; (классический подход Red Hat OpenStack Platform до&nbsp;недавних версий) добавляют ещё один слой сложности&nbsp;— undercloud и&nbsp;overcloud обновляются отдельно, а&nbsp;сам процесс исторически считался одним из&nbsp;самых трудоёмких в&nbsp;экосистеме.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;Charmed OpenStack от&nbsp;Canonical&lltt;/strong&ggtt; на&nbsp;базе Juju ближе всего к&nbsp;идее «графического» управления жизненным циклом: Juju GUI позволяет визуально управлять обновлением charms, что снижает порог входа по&nbsp;сравнению с&nbsp;чистым CLI, хотя полноценной автоматизации «в&nbsp;один клик» с&nbsp;предварительными проверками и&nbsp;остановкой на&nbsp;проблемном шаге это тоже не&nbsp;даёт из&nbsp;коробки.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;MicroStack&nbsp;/ Sunbeam&lltt;/strong&ggtt; (тоже Canonical, snap-based) упрощают обновления до&nbsp;команды snap refresh, но&nbsp;это решение ориентировано на&nbsp;небольшие и&nbsp;edge-инсталляции, а&nbsp;не&nbsp;на&nbsp;полномасштабные продуктивные облака.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Kubernetes-нативные подходы&lltt;/strong&ggtt; (OpenStack-Helm, Airship, а&nbsp;также коммерческий Mirantis OpenStack for Kubernetes) выигрывают за&nbsp;счёт того, что опираются на&nbsp;нативные механизмы Kubernetes&nbsp;— поэтапное обновление, readiness/liveness probes, helm rollback. Именно в&nbsp;этом сегменте чаще всего встречаются продукты с&nbsp;полноценным веб-интерфейсом управления обновлениями, потому что Kubernetes-примитивы изначально спроектированы для автоматизации подобных процессов.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Общий вывод, к&nbsp;которому подводит этот обзор, хочется сформулировать следующим образом. Проблема «обновление зависит от&nbsp;инженера с&nbsp;CLI» и&nbsp;проблема «обновление недоступно как самообслуживаемая операция»&nbsp;— это два разных уровня, и&nbsp;решаются они не&nbsp;одним и&nbsp;тем&nbsp;же шагом. Вынос процесса в&nbsp;CI/CD (как в&nbsp;случае с&nbsp;GitLab у&nbsp;связки Kolla-Ansible/Podman) решает первую: обновление становится воспроизводимым, версионируемым и&nbsp;не&nbsp;требует ручных команд в&nbsp;терминале. Но&nbsp;оно не&nbsp;решает вторую&nbsp;— запустить и&nbsp;проконтролировать пайплайн по-прежнему может только тот, кто ориентируется в&nbsp;GitLab, а&nbsp;не&nbsp;в&nbsp;продукте, которым он&nbsp;управляет. Поэтому интерфейс с&nbsp;кнопкой запуска сам по&nbsp;себе ещё не&nbsp;делает обновление автоматизированным. Существеннее&nbsp;то, какие проверки выполняются до&nbsp;старта, как система учитывает зависимости компонентов, может&nbsp;ли она остановить процесс при ошибке и&nbsp;насколько подробно сообщает администратору о&nbsp;состоянии инфраструктуры. Именно эти механизмы определяют, можно&nbsp;ли передать часть решений от&nbsp;инженера автоматике.&lltt;/p&ggtt;
&lltt;h2&ggtt;Что должно скрываться за&nbsp;кнопкой автоматического обновления&lltt;/h2&ggtt;
&lltt;p&ggtt;Автоматизация обновления OpenStack не&nbsp;сводится к&nbsp;переносу последовательности команд из&nbsp;CLI&nbsp;в CI/CD. Пайплайн может выполнять подготовленные операции, фиксировать стадии и&nbsp;сохранять результаты их&nbsp;выполнения. Но&nbsp;сам по&nbsp;себе он&nbsp;не&nbsp;определяет, какие действия допустимы в&nbsp;текущем состоянии инфраструктуры, в&nbsp;какой последовательности их&nbsp;выполнять и&nbsp;когда процесс необходимо остановить.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому поверх исполнительного слоя нужна логика, которая учитывает зависимости сервисов OpenStack, совместимость версий, состояние узлов и&nbsp;результаты проверок после каждого этапа. Иначе автоматизируется только запуск команд, а&nbsp;принятие решений по-прежнему остается на&nbsp;инженере.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом важно разделять два разных процесса: обновление хостовой операционной системы и&nbsp;переход на&nbsp;новую версию самого OpenStack. Внешне они похожи, но&nbsp;предъявляют разные требования к&nbsp;последовательности операций и&nbsp;допустимому уровню параллелизма.&lltt;/p&ggtt;
&lltt;h3&ggtt;Патчинг хостовой&nbsp;ОС: ротация узлов&lltt;/h3&ggtt;
&lltt;p&ggtt;При установке пакетов и&nbsp;обновлений безопасности на&nbsp;контроллерах и&nbsp;гипервизорах можно использовать принцип последовательной ротации.&lltt;/p&ggtt;
&lltt;p&ggtt;Контроллер выводится в&nbsp;режим обслуживания, получает обновления, при необходимости перезагружается и&nbsp;возвращается в&nbsp;кластер. Только после проверки его состояния процесс переходит к&nbsp;следующему узлу. Пока один контроллер обслуживается, остальные продолжают обрабатывать запросы, что позволяет сохранить доступность управляющего слоя.&lltt;/p&ggtt;
&lltt;p&ggtt;Для гипервизоров возможна другая схема: обновление по&nbsp;одному узлу или группами в&nbsp;пределах зоны доступности. Размер такой группы должен учитывать доступный запас вычислительных ресурсов. Перед обслуживанием с&nbsp;гипервизора переносятся виртуальные машины, сам узел выводится из&nbsp;эксплуатации, обновляется и&nbsp;после проверки возвращается в&nbsp;строй.&lltt;/p&ggtt;
&lltt;p&ggtt;Одновременно выводить в&nbsp;обслуживание все гипервизоры одной зоны доступности нельзя. Поэтому механизм автоматизации должен ограничивать уровень параллелизма и&nbsp;учитывать, достаточно&nbsp;ли оставшихся ресурсов для размещения нагрузки.&lltt;/p&ggtt;
&lltt;p&ggtt;Такая схема особенно важна для установки обновлений безопасности. Ее&nbsp;задача не&nbsp;просто ускорить патчинг, а&nbsp;формализовать операции, которые при ручном выполнении зависят от&nbsp;последовательности действий конкретного инженера: миграцию нагрузки, перевод узла в&nbsp;обслуживание, установку обновлений, перезагрузку и&nbsp;проверку его состояния перед переходом к&nbsp;следующему этапу.&lltt;/p&ggtt;
&lltt;h3&ggtt;Обновление версии OpenStack: почему поэтапность не&nbsp;всегда означает меньший риск&lltt;/h3&ggtt;
&lltt;p&ggtt;При переходе между версиями OpenStack логика сложнее. До&nbsp;начала обновления нужно определить, поддерживается&nbsp;ли переход между исходным и&nbsp;целевым релизами. Для этого может использоваться заранее подготовленная матрица совместимости, учитывающая версии компонентов и&nbsp;допустимые маршруты обновления.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельный вопрос&nbsp;— порядок обновления контроллеров. Интуитивно безопасной кажется последовательная схема, при которой узлы переводятся на&nbsp;новую версию один за&nbsp;другим. Однако для конкретной архитектуры такой подход необходимо проверять с&nbsp;учетом совместимости API и&nbsp;компонентов. Если часть сервисов уже работает на&nbsp;новой версии, а&nbsp;часть остается на&nbsp;старой, может возникнуть период, когда управляющий слой работает в&nbsp;несогласованном состоянии.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому последовательность операций должна определяться не&nbsp;универсальным принципом «обновлять по&nbsp;одному», а&nbsp;особенностями конкретного релиза и&nbsp;архитектуры развертывания.&lltt;/p&ggtt;
&lltt;p&ggtt;Не&nbsp;менее важен контроль состояния системы во&nbsp;время перехода. До&nbsp;старта должны выполняться системные проверки. После критических операций необходимо проверять работоспособность компонентов. Если очередная проверка не&nbsp;пройдена, дальнейшие действия следует остановить и&nbsp;зафиксировать этап, на&nbsp;котором возникла ошибка.&lltt;/p&ggtt;
&lltt;p&ggtt;Для OpenStack такой сценарий зачастую безопаснее попытки автоматически вернуть всю систему в&nbsp;исходное состояние. Если часть схем баз данных уже мигрирована, а&nbsp;некоторые компоненты обновлены, полноценный откат может оказаться отдельной сложной и&nbsp;рискованной процедурой. Поэтому от&nbsp;механизма автоматизации требуется прежде всего контролируемая остановка и&nbsp;точная диагностика.&lltt;/p&ggtt;
&lltt;p&ggtt;Очередность обновления контроллеров и&nbsp;гипервизоров также должна учитывать зависимости между управляющим и&nbsp;вычислительным слоями. Переход вычислительных узлов на&nbsp;новую версию следует начинать только после того, как управляющий слой приведен в&nbsp;согласованное состояние. После этого гипервизоры можно обновлять по&nbsp;одному или группами, предварительно освобождая их&nbsp;от&nbsp;пользовательской нагрузки.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что именно нужно автоматизировать&lltt;/h3&ggtt;
&lltt;p&ggtt;При оценке механизма обновления OpenStack важно смотреть не&nbsp;только на&nbsp;инструмент, который исполняет команды. Ansible, CI/CD или Kubernetes позволяют автоматизировать значительную часть технических операций, но&nbsp;сами по&nbsp;себе не&nbsp;определяют, можно&nbsp;ли выполнять конкретное обновление в&nbsp;текущем состоянии инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Более высокий уровень автоматизации появляется там, где формализована логика принятия решений: проверяется допустимость перехода между версиями, учитывается состояние компонентов, контролируется размер одновременно обслуживаемой группы узлов, соблюдается очередность между управляющим и&nbsp;вычислительным слоями, а&nbsp;дальнейшие действия блокируются при возникновении ошибки.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому перенос команд из&nbsp;терминала в&nbsp;пайплайн решает только часть задачи. Он&nbsp;делает процесс воспроизводимым и&nbsp;версионируемым, но&nbsp;не&nbsp;заменяет механизм управления жизненным циклом облачной платформы.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что должен видеть администратор&lltt;/h3&ggtt;
&lltt;p&ggtt;Способ запуска обновления вторичен. Это может быть CLI, CI/CD или графический интерфейс. Гораздо важнее, какую информацию получает администратор до&nbsp;начала процесса и&nbsp;во&nbsp;время его выполнения.&lltt;/p&ggtt;
&lltt;p&ggtt;До&nbsp;старта обновления должны быть понятны текущие версии компонентов, доступный целевой релиз, результаты предварительных проверок и&nbsp;ограничения выбранного сценария. Во&nbsp;время обновления необходимы данные о&nbsp;текущем этапе, состоянии узлов и&nbsp;возникших ошибках.&lltt;/p&ggtt;
&lltt;p&ggtt;Задача интерфейса в&nbsp;данном случае не&nbsp;в&nbsp;том, чтобы скрыть сложность OpenStack за&nbsp;одной кнопкой. Он&nbsp;должен дать администратору понятную точку управления процессом, тогда как правила последовательности, совместимости и&nbsp;безопасной остановки должны соблюдаться автоматически.&lltt;/p&ggtt;
&lltt;h3&ggtt;От&nbsp;чего зависит длительность обновления&lltt;/h3&ggtt;
&lltt;p&ggtt;Продолжительность обновления нельзя свести к&nbsp;одному нормативному значению. Она зависит от&nbsp;числа узлов, состава компонентов, объема миграций, пользовательской нагрузки и&nbsp;расстояния между исходным и&nbsp;целевым релизами.&lltt;/p&ggtt;
&lltt;p&ggtt;Последовательный переход между соседними релизами, как правило, требует меньше промежуточных изменений. Если&nbsp;же обновление затрагивает несколько релизов, приходится учитывать больше изменений в&nbsp;компонентах, схемах баз данных и&nbsp;конфигурациях.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельно в&nbsp;технологическое окно закладывается время на&nbsp;освобождение гипервизоров от&nbsp;нагрузки, миграцию виртуальных машин, обслуживание узлов и&nbsp;проверки после обновления. Поэтому задача автоматизации состоит не&nbsp;только в&nbsp;сокращении общей продолжительности процедуры. Не&nbsp;менее важно сделать состав операций и&nbsp;их&nbsp;последовательность предсказуемыми, чтобы окно обслуживания можно было планировать заранее.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему обновление нужно тестировать заранее&lltt;/h3&ggtt;
&lltt;p&ggtt;Автоматизация не&nbsp;отменяет предварительной подготовки обновления. Для каждого поддерживаемого перехода необходимо проверить совместимость компонентов, миграции баз данных, последовательность операций и&nbsp;работу основных сценариев после установки новой версии.&lltt;/p&ggtt;
&lltt;p&ggtt;Чем больше расстояние между исходным и&nbsp;целевым релизами, тем больше промежуточных изменений приходится учитывать. Поэтому наличие новой версии OpenStack еще не&nbsp;означает, что на&nbsp;нее можно безопасно перейти из&nbsp;любого предыдущего состояния.&lltt;/p&ggtt;
&lltt;p&ggtt;Для эксплуатации это означает, что маршрут обновления должен быть заранее определен и&nbsp;протестирован. Автоматический механизм затем воспроизводит уже проверенную последовательность, контролируя состояние системы на&nbsp;каждом критическом этапе.&lltt;/p&ggtt;
&lltt;h2&ggtt;Когда обновление OpenStack действительно можно считать автоматизированным&lltt;/h2&ggtt;
&lltt;p&ggtt;Кнопка запуска сама по&nbsp;себе еще не&nbsp;делает обновление автоматическим. За&nbsp;ней может находиться тот&nbsp;же набор команд, который раньше инженер последовательно выполнял вручную.&lltt;/p&ggtt;
&lltt;p&ggtt;Более зрелый подход начинается с&nbsp;автоматизации не&nbsp;только исполнения, но&nbsp;и&nbsp;части решений. Система проверяет состояние инфраструктуры до&nbsp;старта, учитывает совместимость версий и&nbsp;зависимости компонентов, ограничивает потенциально опасный параллелизм, контролирует результат отдельных операций и&nbsp;прекращает дальнейшие действия, если состояние системы отклоняется от&nbsp;ожидаемого.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом полностью исключить инженерную экспертизу невозможно. OpenStack остается сложной распределенной системой, а&nbsp;нестандартные ошибки могут требовать ручной диагностики. Задача автоматизации в&nbsp;другом: убрать из&nbsp;регулярного процесса повторяющиеся операции и&nbsp;решения, которые можно формализовать, снизить зависимость результата от&nbsp;ручных действий и&nbsp;оставить специалистам действительно нестандартные ситуации.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому зрелость механизма обновления определяется не&nbsp;количеством операций, сведенных к&nbsp;одному нажатию, а&nbsp;тем, насколько предсказуемо система проходит штатный сценарий и&nbsp;насколько управляемо ведет себя при возникновении ошибки. По&nbsp;мере роста OpenStack-инфраструктуры такая автоматизация становится частью управления ее&nbsp;жизненным циклом, поскольку без нее увеличиваются трудозатраты на&nbsp;эксплуатацию и&nbsp;зависимость от&nbsp;ручных операций.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235440#&lltt;/p&ggtt;]]></source>
<adate>01.09.2026</adate>
<dbid>235439</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/265/9qfielbjpax7ei82fariipww3zlb68wj.jpg]]>
</images>
<imagesname><![CDATA[;;Кирилл Острогожский, архитектор компании ITKey   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Руцентр: готовность администраторов к обязательной идентификации доменов через &#8220;Госуслуги&#8221; приближается к 50%]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235441]]></link>
<description><![CDATA[С 1 сентября вступает в силу норма об идентификации администраторов доменов в зонах .ru, .рф и .su через портал «Госуслуги» (ЕСИА). Однако в крупнейшем корпоративном регистраторе Руцентре по состоянию на 27 августа процедуру прошли лишь 42,2% администраторов, а в самом массовом регистраторе Рег.ру — 25,7% пользователей. Юридические лица могут пройти идентификацию только у одного регистратора в России — Руцентра. Компания по управлению онлайн-активами Руцентр провела исследование безопасности доменной инфраструктуры российских компаний. Одной из ключевых тем стал уровень готовности к идентификации через ЕСИА, которая вводится с 1 сентября 2026 года согласно Федеральному закону от 29.12.2025 № 569-ФЗ. В крупнейших игроках рынка идентификацию прошли меньше половины пользователей — в Руцентре 43% администраторов, а в Рег.ру лишь 26,7%. Ежедневно эти цифры прирастают на несколько процентных пунктов. Совокупно эти два регистратора занимают долю в 68% Рунета. Основные сложности связаны с несовпадением данных — многие домены оформлены на устаревшие данные, вымышленные имена, бывших сотрудников и фрилансеров. Ключевым барьером для прохождения идентификации остается многолетняя практика регистрации корпоративных доменов на физические лица. В 2026 году в зоне .ru на долю физических лиц приходится 72,7% доменов, в зоне .рф — 82,9%. При этом среди топ-5000 полезных для пользователей сайтов Рунета на физлица зарегистрировано 32% ресурсов. В случае увольнения администратора или его недоступности компания рискует остаться без возможности продлить или перенести критически важный онлайн-актив. Важно отметить, что нормативно-правовые акты, разъясняющие формат применения новой нормы закона, еще не приняты. Закон устанавливает новый порядок регистрации, при котором регистрировать домены смогут только регистраторы из специального перечня. Порядок включения регистраторов в перечень будет определен Правительством Российской Федерации в ближайшее время. Координационный центр доменов .RU/.РФ уведомил регистраторов, что работа аккредитованных регистраторов продолжится по действующим правилам до включения в перечень, либо до 18 января 2027 года. Это означает, что ограничения на операции с доменными именами для администраторов, еще не прошедших идентификацию, с 1 сентября пока применяться не будут. Наряду с регуляторными изменениями эксперты Руцентра зафиксировали рост внешних киберугроз, связанных с брендовым фишингом. 38,5% компаний столкнулись с появлением сайтов-имитаторов, еще 35,9% — со сканированием доменной инфраструктуры и попытками перехвата управления. Это подтверждается и ростом объема Whois-запросов к доменам почти вдвое — до 95 млн. за полугодие, из которых 83 млн. пришлись именно на корпоративные домены. Чаще всего мишенями атак становятся крупные онлайн-площадки. Злоумышленники целенаправленно собирают данные о владельцах ресурсов для последующего фишинга или перехвата управления. В то же время защита учетных записей администраторов остается слабым звеном. Доля пользователей с включенной двухфакторной аутентификацией составляет лишь 15-16%. Дополнительным системным риском стал массовый отзыв иностранных SSL/TLS-сертификатов. С июня по август 2026 года удостоверяющие центры отозвали 6 997 сертификата, из которых 4677 — от GlobalSign. Причина — введение санкционных проверок клиентов по требованию международного консорциума CA/Browser Forum. Доля российских сертификатов в зоне .ru составляет менее 1%, как и доля устройств с установленными отечественными корневыми сертификатами. После отзывов активные сертификаты Национального удостоверяющего центра выросли на 7,7% за неделю, а Технического центра Интернет — в 4,5 раза с начала июня 2026 года. Руцентр провел исследование безопасности доменной инфраструктуры российских компаний уже во второй раз. Предыдущее исследование было выпущено в сентябре 2025 года. В 2026 году к созданию исследования присоединилась компания Технический центр Интернет, технический оператор российской национальной доменной зоны верхнего уровня, которая предоставила дополнительные данные о ситуации на рынке SSL/TLS-сертификатов. Как и в прошлый раз исследование содержит две части, включающие количественный и качественный анализ. Методология построена на анализе системных метрик и операционных показателей, отражающих состояние защищенности онлайн-активов на уровне всего доменного рынка в Российской Федерации. В опросе принимали участие представители ИТ- и ИБ-подразделений компаний, преимущественно из сегмента крупного бизнеса, — почти 40% компаний с численностью свыше 1000 сотрудников. Сбор и обработка данных проводились экспертами Руцентра в августе 2026 года]]></description>
<source><![CDATA[&lltt;p&ggtt;С&nbsp;1&nbsp;сентября вступает в&nbsp;силу норма об&nbsp;идентификации администраторов доменов в&nbsp;зонах .ru, .рф и .su через портал «Госуслуги» (ЕСИА). Однако в&nbsp;крупнейшем корпоративном регистраторе Руцентре по&nbsp;состоянию на&nbsp;27&nbsp;августа процедуру прошли лишь 42,2% администраторов, а&nbsp;в&nbsp;самом массовом регистраторе Рег.ру&nbsp;— 25,7% пользователей. Юридические лица могут пройти идентификацию только у&nbsp;одного регистратора в&nbsp;России&nbsp;— Руцентра.&lltt;/p&ggtt;
&lltt;p&ggtt;Компания по&nbsp;управлению онлайн-активами Руцентр провела исследование безопасности доменной инфраструктуры российских компаний. Одной из&nbsp;ключевых тем стал уровень готовности к&nbsp;идентификации через ЕСИА, которая вводится с&nbsp;1&nbsp;сентября 2026 года согласно Федеральному закону от&nbsp;29.12.2025 №&nbsp;&lltt;nobr&ggtt;569-ФЗ.&lltt;/nobr&ggtt; В&nbsp;крупнейших игроках рынка идентификацию прошли меньше половины пользователей&nbsp;— в&nbsp;Руцентре&nbsp;43% администраторов, а&nbsp;в&nbsp;Рег.ру лишь 26,7%. Ежедневно эти цифры прирастают на&nbsp;несколько процентных пунктов. Совокупно эти два регистратора занимают долю в&nbsp;68% Рунета. Основные сложности связаны с&nbsp;несовпадением данных&nbsp;— многие домены оформлены на&nbsp;устаревшие данные, вымышленные имена, бывших сотрудников и&nbsp;фрилансеров. &lltt;/p&ggtt;
&lltt;p&ggtt;Ключевым барьером для прохождения идентификации остается многолетняя практика регистрации корпоративных доменов на&nbsp;физические лица. В&nbsp;2026 году в&nbsp;зоне .ru на&nbsp;долю физических лиц приходится 72,7% доменов, в&nbsp;зоне .рф&nbsp;— 82,9%. При этом среди топ-5000 полезных для пользователей сайтов Рунета на&nbsp;физлица зарегистрировано&nbsp;32% ресурсов. В&nbsp;случае увольнения администратора или его недоступности компания рискует остаться без возможности продлить или перенести критически важный онлайн-актив. &lltt;/p&ggtt;
&lltt;p&ggtt;Важно отметить, что нормативно-правовые акты, разъясняющие формат применения новой нормы закона, еще не&nbsp;приняты. Закон устанавливает новый порядок регистрации, при котором регистрировать домены смогут только регистраторы из&nbsp;специального перечня. Порядок включения регистраторов в&nbsp;перечень будет определен Правительством Российской Федерации в&nbsp;ближайшее время. Координационный центр доменов .RU/.РФ уведомил регистраторов, что работа аккредитованных регистраторов продолжится по&nbsp;действующим правилам до&nbsp;включения в&nbsp;перечень, либо до&nbsp;18&nbsp;января 2027&nbsp;года. Это означает, что ограничения на&nbsp;операции с&nbsp;доменными именами для администраторов, еще не&nbsp;прошедших идентификацию, с&nbsp;1&nbsp;сентября пока применяться не&nbsp;будут.&lltt;/p&ggtt;
&lltt;p&ggtt;Наряду с&nbsp;регуляторными изменениями эксперты Руцентра зафиксировали рост внешних киберугроз, связанных с&nbsp;брендовым фишингом.&nbsp;38,5% компаний столкнулись с&nbsp;появлением сайтов-имитаторов, еще 35,9%&nbsp;— со&nbsp;сканированием доменной инфраструктуры и&nbsp;попытками перехвата управления. Это подтверждается и&nbsp;ростом объема Whois-запросов к&nbsp;доменам почти вдвое&nbsp;— до&nbsp;95&nbsp;млн.&nbsp;за&nbsp;полугодие, из&nbsp;которых 83&nbsp;млн. пришлись именно на&nbsp;корпоративные домены. Чаще всего мишенями атак становятся крупные онлайн-площадки. Злоумышленники целенаправленно собирают данные о&nbsp;владельцах ресурсов для последующего фишинга или перехвата управления. В&nbsp;то&nbsp;же время защита учетных записей администраторов остается слабым звеном. Доля пользователей с&nbsp;включенной двухфакторной аутентификацией составляет лишь &lltt;nobr&ggtt;15-16%.&lltt;/nobr&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Дополнительным системным риском стал массовый отзыв иностранных SSL/TLS-сертификатов. С&nbsp;июня по&nbsp;август 2026 года удостоверяющие центры отозвали 6&nbsp;997&nbsp;сертификата, из&nbsp;которых 4677&nbsp;— от&nbsp;GlobalSign. Причина&nbsp;— введение санкционных проверок клиентов по&nbsp;требованию международного консорциума CA/Browser Forum. Доля российских сертификатов в&nbsp;зоне .ru составляет менее&nbsp;1%, как и&nbsp;доля устройств с&nbsp;установленными отечественными корневыми сертификатами. После отзывов активные сертификаты Национального удостоверяющего центра выросли на&nbsp;7,7% за&nbsp;неделю, а&nbsp;Технического центра Интернет&nbsp;— в&nbsp;4,5 раза с&nbsp;начала июня 2026&nbsp;года.&lltt;/p&ggtt;
&lltt;p&ggtt;Руцентр провел исследование безопасности доменной инфраструктуры российских компаний уже во&nbsp;второй раз. Предыдущее исследование было выпущено в&nbsp;сентябре 2025&nbsp;года. В&nbsp;2026 году к&nbsp;созданию исследования присоединилась компания Технический центр Интернет, технический оператор российской национальной доменной зоны верхнего уровня, которая предоставила дополнительные данные о&nbsp;ситуации на&nbsp;рынке SSL/TLS-сертификатов. Как и&nbsp;в&nbsp;прошлый раз исследование содержит две части, включающие количественный и&nbsp;качественный анализ. Методология построена на&nbsp;анализе системных метрик и&nbsp;операционных показателей, отражающих состояние защищенности онлайн-активов на&nbsp;уровне всего доменного рынка в&nbsp;Российской Федерации. В&nbsp;опросе принимали участие представители ИТ- и&nbsp;ИБ-подразделений компаний, преимущественно из&nbsp;сегмента крупного бизнеса,&nbsp;— почти&nbsp;40% компаний с&nbsp;численностью свыше 1000&nbsp;сотрудников. Сбор и&nbsp;обработка данных проводились экспертами Руцентра в&nbsp;августе 2026&nbsp;года.&lltt;/p&ggtt;]]></source>
<adate>01.09.2026</adate>
<dbid>235441</dbid>
<rubric>8</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Как конвейеры телеметрии помогают контролировать расходы на ИИ-агентов]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235438]]></link>
<description><![CDATA[Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку объем телеметрических данных в ближайшие два года вырастет на порядок, конвейеры наблюдаемости становятся контрольным звеном, сообщает портал The New Stack. По мере того как компании переходят от экспериментов с ИИ к запуску автономных агентов в производственной среде, возникает проблема, связанная с инфраструктурой: растущие расходы на телеметрию. Недетерминированные, итеративные агенты, способные генерировать данные со скоростью машин, гораздо сложнее поддаются мониторингу, а расходы на них спрогнозировать гораздо сложнее, чем в случае с обычными приложениями. Многие компании испытывают трудности с выделением и обоснованием расходов на телеметрию. Согласно опросу более 300 руководителей в сфере корпоративных ИТ в Северной Америке и Западной Европе, проведенному Omdia/Informa TechTarget по заказу Apica, 59% организаций уже прекратили или отложили внедрение ИИ-агентов из-за расходов на мониторинг. Чаще всего это происходит при внедрении ИИ-агентов в критически важных областях: например, в сферах кибербезопасности, соблюдения нормативных требований и выявления мошенничества. По мере роста расходов на мониторинг, проекты по внедрению ИИ-агентов далеко не всегда закрываются по инициативе инженерных команд. Чаще всего их закрывает финансовый отдел. Энди Манн, директор по продуктам и технологиям Apica, недавно стал свидетелем того, как это произошло в одном крупном банке. Организация не смогла точно определить свои затраты на программы ИИ. «Они поняли, что не могут позволить себе продолжать в том же духе, поэтому у них не было другого выбора, кроме как отменить некоторые программы ИИ, — рассказывает он. — Я уже сталкивался с такими вещами, потому что ИИ-проекты легко съедают типичные бюджеты». Последствия огромны. По мере того, как люди, финансирование и ресурсы мониторинга перенаправляются на новые рабочие нагрузки ИИ, другие подразделения бизнеса начинают страдать. Манн говорит, что он видит перебои в работе, простои и атаки с проникновением, а средства защиты от DDoS-атак конкурируют за одни и те же ресурсы. Исследование Apica также выявило эту проблему. Только за последний год на большинстве предприятий (54%) объем телеметрии утроился, причем 43% этого роста приходится на рабочие нагрузки ИИ/машинного обучения, что, безусловно, является основным фактором. Предприятия вынуждены бороться с этим кризисом, поскольку их расходы на наблюдаемость растут. Они сообщают, что тратят в среднем 3,17 млн. долл. на обеспечение наблюдаемости, причем эта цифра растет на 28% в годовом исчислении и предела этому росту не видно. Неудивительно, что 83% опрошенных считают ИИ-наблюдаемость главным приоритетом на ближайший год. Грядущая волна может оказаться катастрофической При появлении нового облачного сервиса, базы данных или приложения нагрузка на систему мониторинга и объем телеметрических данных обычно увеличиваются на относительно предсказуемую величину. Но сейчас компании прогнозируют, что в течение двух лет объем телеметрических данных вырастет в среднем в 9,5 раза. Около 44% организаций ожидают, что объем телеметрических данных вырастет в 6-100 раз. «Представьте, что ваш счет по кредитной карте или чек из супермаркета выросли почти на порядок. Это уже не просто увеличение. Это не плавный рост, а стремительный взлет, и это вызывает панику», — говорит Манн. Причина в том, что работа агента — это не то же самое, что отдельный запрос к приложению. Задача службы поддержки может включать в себя трассировку верхнего уровня, несколько вызовов модели, операции извлечения данных, вызовы инструментов, повторные попытки и циклы. Но если агент делегирует работу другому агенту, это добавляет в трассировку еще одну ветвь. Каждая модель может генерировать данные о токенах, задержках, затратах и поставщиках, а каждый вызов инструмента создает собственные записи об аргументах, результатах, статусе и последующих действиях. Идентификаторы, такие как tool_name, agent_id и trace_id, также создают избыточность данных, из-за чего их сложнее агрегировать и дороже индексировать, и затраты растут на каждом этапе. Это создает ощутимый разрыв между амбициями в области ИИ и готовностью инфраструктуры. Несмотря на то, что 35% компаний заявляют о широком внедрении агентного ИИ, эксплуатация и управление такими системами сильно отличаются от того, что было раньше. Почти две трети компаний лишь в некоторой степени готовы к таким изменениям. В отличие от обычных приложений, агенты могут вызывать множество моделей и инструментов, повторно выполнять задачи или расширять рабочий процесс непредсказуемым образом, из-за чего сложно спрогнозировать затраты на обеспечение производительности и мониторинг. От огромных затрат на телеметрию до уровня контроля на входе По словам Манна, решение заключается в том, чтобы вмешаться на более ранних этапах. «Нельзя бесконечно отправлять практически бесполезные данные на дорогостоящую центральную аналитическую платформу или платформу хранения данных, потому что нет смысла анализировать данные, которые говорят о том, что все в порядке, — говорит он. — Как можно раньше подключите конвейер к сборщикам данных и управляйте ими на уровне источника». Традиционные платформы наблюдаемости ориентированы на сбор данных, их прием, хранение и индексацию, а затем анализ. Такая модель подходила для рабочих процессов, управляемых людьми и анализируемых с помощью дашбордов, но для агентного ИИ необходимо принимать решения до того, как телеметрия дойдет до наиболее затратных частей стека. Архитектура, ориентированная на конвейер, позволяет отбирать повторяющиеся успешные события, сохраняя при этом данные о сбоях, повторных попытках, нарушениях политик и аномально медленных трассировках. Она позволяет дополнять записи данными об агенте, сеансе, модели, инструменте, токене и предполагаемой стоимости, удалять конфиденциальные запросы и идентификаторы, а также агрегировать метрики и долгосрочные записи и отправлять их в места назначения с разными профилями затрат и хранения. Компактная метрика или выборка могут отражать обычный успешный вызов инструмента, в то время как при неудачном вызове сохраняется родительская трассировка, сведения об ошибке, история повторных попыток и контекст безопасности. Цель состоит в том, чтобы сохранить информацию, необходимую для объяснения поведения агента, сократив при этом объем избыточных данных и ограничив объем индексируемой информации. Агентам также необходим контекст на уровне миллисекунд для принятия автономных решений. Обработка телеметрии в непосредственной близости от источника позволяет организациям быстро выявлять ситуации, когда происходит слишком много повторных попыток, чрезмерное количество циклов использования инструментов или аномально высокий расход токенов, не дожидаясь, пока данные будут собраны и проиндексированы централизованно. Без контроля на уровне источника компании рискуют передавать фрагментированные и ненужные телеметрические данные на платформы, которые взимают плату за каждый дополнительный гигабайт, индекс и сохраненную запись. Архитектура, которая отделяет победителей от проигравших Трудно не заметить, насколько выгоден подход, при котором переосмысливается конвейер сбора телеметрических данных. Использующие его компании на 50% лучше подготовлены к росту объемов данных, связанному с агентным ИИ. Именно внедрение такого подхода выделяет зрелые организации, использующие агентный ИИ, на фоне конкурентов: такие организации на 80% реже сталкиваются с проблемами, связанными с операционными расходами, которые мешают их конкурентам. Решение заключается в том, чтобы перенести аналитические функции на более ранние этапы. Вместо того чтобы рассматривать платформу наблюдаемости как универсальный инструмент, компании могут принимать решения о том, какие телеметрические данные использовать, еще до того, как они попадут на платформу, — отфильтровывая ненужную информацию, выделяя то, что действительно важно, и маршрутизируя данные в соответствии с их ценностью и назначением. Это означает, что в дорогостоящие системы хранения и анализа будет поступать меньше данных, а та информация, которая все же попадет в эти системы, будет более полезной и доступной в режиме реального времени. Важно отметить, что речь не идет о полном отказе от платформ наблюдаемости, на которые уже полагаются компании. Речь идет о том, чтобы создать перед ними более интеллектуальный контрольный слой, который будет решать, какие данные заслуживают обработки, куда их следует направлять и сколько это будет стоить. Существующие платформы наблюдаемости по-прежнему играют важную роль. «Конвейер не может делать все, но он может взять на себя первичную обработку данных, — говорит Манн. — Вы по-прежнему работаете с крупными аналитическими платформами, но при этом экономите деньги, снижаете риски и повышаете эффективность соблюдения нормативных требований». Согласно исследованию Apica, контрольный конвейер, базовые метрики и сервисы подготовки данных позволяют снизить совокупную стоимость владения на 40% по сравнению с унаследованными платформами наблюдаемости. Разумеется, фактическая экономия будет зависеть от объемов телеметрии, политики хранения данных, правил выборки, решений по маршрутизации, действующих контрактов и доли данных, которые можно обработать до приема в систему. Сейчас самое время пересмотреть архитектуру. Около 68% компаний планируют в течение следующих шести месяцев оценить изменения в своей системе наблюдаемости, а почти четверть из них заявляют, что существующие отношения с поставщиками не будут играть существенной роли при принятии этих решений. Следующий этап развития системы наблюдаемости будет связан с умением справляться с тем, что ИИ будет «выбрасывать» в инфраструктуру. Это означает, что конвейер больше нельзя рассматривать как систему, которая просто перемещает телеметрические данные из пункта А в пункт Б. Он становится управляющим слоем для все более автономной и требовательной к данным среды. Организации, которые создадут инфраструктуру, готовую к работе с агентным ИИ, смогут снизить затраты на наблюдаемость и повысить эффективность управления рисками. Манн не считает, что у платформенных инженеров и SRE-команд есть большой выбор. «Это уже становится решением на уровне совета директоров, — говорит он. — В конечном счете, это выбор того, насколько разумно вы можете позволить себе вести свой бизнес»]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку объем телеметрических данных в ближайшие два года вырастет на порядок, конвейеры наблюдаемости становятся контрольным звеном, сообщает портал &lltt;/em&ggtt;&lltt;em&ggtt;The&lltt;/em&ggtt; &lltt;em&ggtt;New&lltt;/em&ggtt; &lltt;em&ggtt;Stack&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;По мере того как компании переходят от экспериментов с ИИ к запуску автономных агентов в производственной среде, возникает проблема, связанная с инфраструктурой: растущие расходы на телеметрию. Недетерминированные, итеративные агенты, способные генерировать данные со скоростью машин, гораздо сложнее поддаются мониторингу, а расходы на них спрогнозировать гораздо сложнее, чем в случае с обычными приложениями.&lltt;/p&ggtt;
&lltt;p&ggtt;Многие компании испытывают трудности с выделением и обоснованием расходов на телеметрию. Согласно &lltt;a href="https://www.prnewswire.com/news-releases/new-apica-research-agentic-ai-poised-to-trigger-9-5x-telemetry-data-explosion-leaving-most-enterprises-exposed-302789312.html"&ggtt;опросу&lltt;/a&ggtt; более 300 руководителей в сфере корпоративных ИТ в Северной Америке и Западной Европе, проведенному Omdia/Informa TechTarget по заказу Apica, 59% организаций уже прекратили или отложили внедрение ИИ-агентов из-за расходов на мониторинг.&lltt;/p&ggtt;
&lltt;p&ggtt;Чаще всего это происходит при внедрении ИИ-агентов в критически важных областях: например, в сферах кибербезопасности, соблюдения нормативных требований и выявления мошенничества. По мере роста расходов на мониторинг, проекты по внедрению ИИ-агентов далеко не всегда закрываются по инициативе инженерных команд. Чаще всего их закрывает финансовый отдел.&lltt;/p&ggtt;
&lltt;p&ggtt;Энди Манн, директор по продуктам и технологиям Apica, недавно стал свидетелем того, как это произошло в одном крупном банке. Организация не смогла точно определить свои затраты на программы ИИ. «Они поняли, что не могут позволить себе продолжать в том же духе, поэтому у них не было другого выбора, кроме как отменить некоторые программы ИИ, — рассказывает он. — Я уже сталкивался с такими вещами, потому что ИИ-проекты легко съедают типичные бюджеты».&lltt;/p&ggtt;
&lltt;p&ggtt;Последствия огромны. По мере того, как люди, финансирование и ресурсы мониторинга перенаправляются на новые рабочие нагрузки ИИ, другие подразделения бизнеса начинают страдать. Манн говорит, что он видит перебои в работе, простои и атаки с проникновением, а средства защиты от DDoS-атак конкурируют за одни и те же ресурсы.&lltt;/p&ggtt;
&lltt;p&ggtt;Исследование Apica также выявило эту проблему. Только за последний год на большинстве предприятий (54%) объем телеметрии утроился, причем 43% этого роста приходится на рабочие нагрузки ИИ/машинного обучения, что, безусловно, является основным фактором. Предприятия вынуждены бороться с этим кризисом, поскольку их расходы на наблюдаемость растут. Они сообщают, что тратят в среднем 3,17 млн. долл. на обеспечение наблюдаемости, причем эта цифра растет на 28% в годовом исчислении и предела этому росту не видно. Неудивительно, что 83% опрошенных считают ИИ-наблюдаемость главным приоритетом на ближайший год.&lltt;/p&ggtt;
&lltt;h3&ggtt;Грядущая волна может оказаться катастрофической&lltt;/h3&ggtt;
&lltt;p&ggtt;При появлении нового облачного сервиса, базы данных или приложения нагрузка на систему мониторинга и объем телеметрических данных обычно увеличиваются на относительно предсказуемую величину. Но сейчас компании прогнозируют, что в течение двух лет объем телеметрических данных вырастет в среднем в 9,5 раза. Около 44% организаций ожидают, что объем телеметрических данных вырастет в &lltt;nobr&ggtt;6-100 раз.&lltt;/nobr&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;«Представьте, что ваш счет по кредитной карте или чек из супермаркета выросли почти на порядок. Это уже не просто увеличение. Это не плавный рост, а стремительный взлет, и это вызывает панику», — говорит Манн.&lltt;/p&ggtt;
&lltt;p&ggtt;Причина в том, что работа агента — это не то же самое, что отдельный запрос к приложению. Задача службы поддержки может включать в себя трассировку верхнего уровня, несколько вызовов модели, операции извлечения данных, вызовы инструментов, повторные попытки и циклы. Но если агент делегирует работу другому агенту, это добавляет в трассировку еще одну ветвь.&lltt;/p&ggtt;
&lltt;p&ggtt;Каждая модель может генерировать данные о токенах, задержках, затратах и поставщиках, а каждый вызов инструмента создает собственные записи об аргументах, результатах, статусе и последующих действиях. Идентификаторы, такие как &lltt;em&ggtt;tool_name&lltt;/em&ggtt;, &lltt;em&ggtt;agent_id&lltt;/em&ggtt; и &lltt;em&ggtt;trace_id&lltt;/em&ggtt;, также создают избыточность данных, из-за чего их сложнее агрегировать и дороже индексировать, и затраты растут на каждом этапе.&lltt;/p&ggtt;
&lltt;p&ggtt;Это создает ощутимый разрыв между амбициями в области ИИ и готовностью инфраструктуры. Несмотря на то, что 35% компаний заявляют о широком внедрении агентного ИИ, эксплуатация и управление такими системами сильно отличаются от того, что было раньше. Почти две трети компаний лишь в некоторой степени готовы к таким изменениям. В отличие от обычных приложений, агенты могут вызывать множество моделей и инструментов, повторно выполнять задачи или расширять рабочий процесс непредсказуемым образом, из-за чего сложно спрогнозировать затраты на обеспечение производительности и мониторинг.&lltt;/p&ggtt;
&lltt;h3&ggtt;От огромных затрат на телеметрию до уровня контроля на входе&lltt;/h3&ggtt;
&lltt;p&ggtt;По словам Манна, решение заключается в том, чтобы вмешаться на более ранних этапах. «Нельзя бесконечно отправлять практически бесполезные данные на дорогостоящую центральную аналитическую платформу или платформу хранения данных, потому что нет смысла анализировать данные, которые говорят о том, что все в порядке, — говорит он. — Как можно раньше подключите конвейер к сборщикам данных и управляйте ими на уровне источника».&lltt;/p&ggtt;
&lltt;p&ggtt;Традиционные платформы наблюдаемости ориентированы на сбор данных, их прием, хранение и индексацию, а затем анализ. Такая модель подходила для рабочих процессов, управляемых людьми и анализируемых с помощью дашбордов, но для агентного ИИ необходимо принимать решения до того, как телеметрия дойдет до наиболее затратных частей стека.&lltt;/p&ggtt;
&lltt;p&ggtt;Архитектура, ориентированная на конвейер, позволяет отбирать повторяющиеся успешные события, сохраняя при этом данные о сбоях, повторных попытках, нарушениях политик и аномально медленных трассировках. Она позволяет дополнять записи данными об агенте, сеансе, модели, инструменте, токене и предполагаемой стоимости, удалять конфиденциальные запросы и идентификаторы, а также агрегировать метрики и долгосрочные записи и отправлять их в места назначения с разными профилями затрат и хранения.&lltt;/p&ggtt;
&lltt;p&ggtt;Компактная метрика или выборка могут отражать обычный успешный вызов инструмента, в то время как при неудачном вызове сохраняется родительская трассировка, сведения об ошибке, история повторных попыток и контекст безопасности. Цель состоит в том, чтобы сохранить информацию, необходимую для объяснения поведения агента, сократив при этом объем избыточных данных и ограничив объем индексируемой информации.&lltt;/p&ggtt;
&lltt;p&ggtt;Агентам также необходим контекст на уровне миллисекунд для принятия автономных решений. Обработка телеметрии в непосредственной близости от источника позволяет организациям быстро выявлять ситуации, когда происходит слишком много повторных попыток, чрезмерное количество циклов использования инструментов или аномально высокий расход токенов, не дожидаясь, пока данные будут собраны и проиндексированы централизованно.&lltt;/p&ggtt;
&lltt;p&ggtt;Без контроля на уровне источника компании рискуют передавать фрагментированные и ненужные телеметрические данные на платформы, которые взимают плату за каждый дополнительный гигабайт, индекс и сохраненную запись.&lltt;/p&ggtt;
&lltt;h3&ggtt;Архитектура, которая отделяет победителей от проигравших&lltt;/h3&ggtt;
&lltt;p&ggtt;Трудно не заметить, насколько выгоден подход, при котором переосмысливается конвейер сбора телеметрических данных. Использующие его компании на 50% лучше подготовлены к росту объемов данных, связанному с агентным ИИ. Именно внедрение такого подхода выделяет зрелые организации, использующие агентный ИИ, на фоне конкурентов: такие организации на 80% реже сталкиваются с проблемами, связанными с операционными расходами, которые мешают их конкурентам.&lltt;/p&ggtt;
&lltt;p&ggtt;Решение заключается в том, чтобы перенести аналитические функции на более ранние этапы. Вместо того чтобы рассматривать платформу наблюдаемости как универсальный инструмент, компании могут принимать решения о том, какие телеметрические данные использовать, еще до того, как они попадут на платформу, — отфильтровывая ненужную информацию, выделяя то, что действительно важно, и маршрутизируя данные в соответствии с их ценностью и назначением. Это означает, что в дорогостоящие системы хранения и анализа будет поступать меньше данных, а та информация, которая все же попадет в эти системы, будет более полезной и доступной в режиме реального времени.&lltt;/p&ggtt;
&lltt;p&ggtt;Важно отметить, что речь не идет о полном отказе от платформ наблюдаемости, на которые уже полагаются компании. Речь идет о том, чтобы создать перед ними более интеллектуальный контрольный слой, который будет решать, какие данные заслуживают обработки, куда их следует направлять и сколько это будет стоить.&lltt;/p&ggtt;
&lltt;p&ggtt;Существующие платформы наблюдаемости по-прежнему играют важную роль. «Конвейер не может делать все, но он может взять на себя первичную обработку данных, — говорит Манн. — Вы по-прежнему работаете с крупными аналитическими платформами, но при этом экономите деньги, снижаете риски и повышаете эффективность соблюдения нормативных требований».&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно исследованию Apica, контрольный конвейер, базовые метрики и сервисы подготовки данных позволяют снизить совокупную стоимость владения на 40% по сравнению с унаследованными платформами наблюдаемости. Разумеется, фактическая экономия будет зависеть от объемов телеметрии, политики хранения данных, правил выборки, решений по маршрутизации, действующих контрактов и доли данных, которые можно обработать до приема в систему.&lltt;/p&ggtt;
&lltt;p&ggtt;Сейчас самое время пересмотреть архитектуру. Около 68% компаний планируют в течение следующих шести месяцев оценить изменения в своей системе наблюдаемости, а почти четверть из них заявляют, что существующие отношения с поставщиками не будут играть существенной роли при принятии этих решений. Следующий этап развития системы наблюдаемости будет связан с умением справляться с тем, что ИИ будет «выбрасывать» в инфраструктуру.&lltt;/p&ggtt;
&lltt;p&ggtt;Это означает, что конвейер больше нельзя рассматривать как систему, которая просто перемещает телеметрические данные из пункта А в пункт Б. Он становится управляющим слоем для все более автономной и требовательной к данным среды.&lltt;/p&ggtt;
&lltt;p&ggtt;Организации, которые создадут инфраструктуру, готовую к работе с агентным ИИ, смогут снизить затраты на наблюдаемость и повысить эффективность управления рисками. Манн не считает, что у платформенных инженеров и SRE-команд есть большой выбор. «Это уже становится решением на уровне совета директоров, — говорит он. — В конечном счете, это выбор того, насколько разумно вы можете позволить себе вести свой бизнес».&lltt;/p&ggtt;]]></source>
<adate>01.09.2026</adate>
<dbid>235438</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[STAQ: платформенные решения сократили незапланированные простои на производстве на 28%, а сроки исполнения заявок в ритейле на 30%]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235436]]></link>
<description><![CDATA[Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное на выявление наиболее востребованных направлений использования платформенных решений в ключевых отраслях России в 1 полугодии 2026 года. Данные были получены по итогам анализа проектной практики STAQ за 1 полугодие 2026 года. По данным анализа проектов и клиентских запросов STAQ за январь-июнь 2026 года наиболее активно платформенные решения применялись в трёх ключевых отраслях: промышленное производство, розничная торговля и транспорт. Помимо этих индустрий, можно выделить строительство и управление инфраструктурными объектами, добывающую промышленность, телекоммуникации, агропромышленный комплекс и финансовый сектор. В этих сегментах платформы востребованы прежде всего для управления заявками и инцидентами, контроля эксплуатации оборудования, координации выездных сотрудников и соблюдения SLA. Существуют важные причины востребованности платформ в данных отраслях. Первая причина — высокая стоимость простоев и операционных ошибок. Остановка производственной линии, кассового оборудования, склада или транспортного узла быстро приводит к прямым финансовым потерям, нарушению графиков и снижению качества обслуживания. Вторая причина — большое число распределенных процессов. Предприятиям нужно одновременно управлять оборудованием, заявками, сотрудниками, выездными бригадами и подрядчиками на сотнях объектов. Третья причина — переход от разрозненной автоматизации к единому цифровому контуру. Компании стремятся связать существующие ERP, WMS, POS, MES, SCADA, IoT-системы и внутренние базы данных без полной перестройки ИТ-ландшафта. На промышленных предприятиях платформенные решения чаще всего использовались по следующим направлениям: управление производственными заданиями и сменной отчетностью, техническое обслуживание и ремонт оборудования, мониторинг технологических параметров с использованием IoT и SCADA, управление качеством, инцидентами и отклонениями. Отдельное направление — задачи, которые традиционно относят к контуру MES: сменные задания, отчётность по выпуску, регистрация отклонений и контроль исполнения на уровне цеха. По данным аналитиков STAQ, в среднем по проектам, применение платформ на производственных предприятиях в 1 полугодии 2026 года позволило в сравнении с показателями до внедрения: сократить затраты на внеплановые ремонты на 21%, уменьшить количество незапланированных простоев на 28%, ускорить реакцию на выявленные дефекты на 16%. Данные начали использоваться не только для отчетности. Система автоматически формирует задачу при обнаружении отклонения, назначает ответственного, контролирует срок выполнения и сохраняет результат. Основными направлениями использования платформ в розничной торговле стали: централизация заявок от магазинов и других торговых объектов, обслуживание касс, холодильников, торговых автоматов и инженерных систем, управление мерчандайзерами, техническими специалистами и подрядчиками, контроль SLA, наличия товаров и качества обслуживания торговых точек. Вместо обращений по телефону, электронной почте и в мессенджерах торговая сеть получает единую точку входа. Заявки автоматически распределяются по региону, типу проблемы, приоритету и компетенции исполнителя. В одном из проектов STAQ была централизована обработка заявок более чем из 300 магазинов. В сравнении с периодом до внедрения сроки исполнения заявок сократились на 30%, количество случаев отсутствия товара из-за отказов оборудования уменьшилось на 50%, более 20% заявок стали обрабатываться без участия человека, а среднее число заявок, закрываемых одним диспетчером за смену, выросло на 60%. В транспортно-логистической отрасли платформы применялись для управления техническим состоянием транспорта и инфраструктуры, планирования ТОиР и внеплановых ремонтов, диспетчеризации и контроля исполнения рейсов, обработки ИТ- и инфраструктурных инцидентов, управления подрядными перевозчиками и соблюдения SLA. В одном из проектов STAQ для крупной логистической компании количество инцидентов, влияющих на операционные процессы, сократилось на 47%, выполнение SLA по критичным системам достигло 94%, а простои стоек регистрации уменьшились на 62%. Интеграция с ERP также позволила ускорить закупку запасных частей на два дня. Основной результат использования платформ для транспортно-логистической отрасли — сокращение незапланированных остановок и переход от ручной диспетчеризации к управлению на основании данных. Во 2 полугодии 2026 года STAQ ожидает сохранения спроса на платформенные решения со стороны промышленности, ритейла и логистики, но при более консервативном отношении к ИТ-бюджетам: в приоритете будут проекты с измеримой и быстрой окупаемостью, а повестка сместится с роста выручки на сокращение операционных затрат. Изменится характер проектов: компании будут чаще переходить от автоматизации отдельного процесса к тиражированию решений на несколько площадок. Основными направлениями развития станут: предиктивное обслуживание оборудования на основе IoT-данных, применение ИИ для классификации заявок, выявления отклонений и поддержки диспетчеров, объединение производственных, эксплуатационных и сервисных процессов на одной платформе. Кроме того, компании осуществят более глубокую интеграцию с ERP, WMS, POS, MES и SCADA. «В 1 полугодии 2026 года платформенный подход вышел за рамки простой замены бумажных процессов цифровыми. Компании используют платформы как операционный контур, который связывает оборудование, сотрудников, подрядчиков и управленческую аналитику. Мы видим, что ожидания от предиктивной аналитики и ИИ сегодня опережают готовность данных: пока не выстроен учёт оборудования, заявок и истории ремонтов, модели не на чем обучать. Поэтому ближайший этап для большинства компаний — не новые технологии, а качество эксплуатационных данных», — отметил Евгений Гусев, генеральный директор STAQ]]></description>
<source><![CDATA[&lltt;p&ggtt;Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное на выявление наиболее востребованных направлений использования платформенных решений в ключевых отраслях России в 1 полугодии 2026 года. Данные были получены по итогам анализа проектной практики STAQ за 1 полугодие 2026 года.&lltt;/p&ggtt;
&lltt;p&ggtt;По данным анализа проектов и клиентских запросов STAQ за январь-июнь 2026 года наиболее активно платформенные решения применялись в трёх ключевых отраслях: промышленное производство, розничная торговля и транспорт. Помимо этих индустрий, можно выделить строительство и управление инфраструктурными объектами, добывающую промышленность, телекоммуникации, агропромышленный комплекс и финансовый сектор. В этих сегментах платформы востребованы прежде всего для управления заявками и инцидентами, контроля эксплуатации оборудования, координации выездных сотрудников и соблюдения SLA. &lltt;/p&ggtt;
&lltt;p&ggtt;Существуют важные причины востребованности платформ в данных отраслях. Первая причина — высокая стоимость простоев и операционных ошибок. Остановка производственной линии, кассового оборудования, склада или транспортного узла быстро приводит к прямым финансовым потерям, нарушению графиков и снижению качества обслуживания. Вторая причина — большое число распределенных процессов. Предприятиям нужно одновременно управлять оборудованием, заявками, сотрудниками, выездными бригадами и подрядчиками на сотнях объектов. Третья причина — переход от разрозненной автоматизации к единому цифровому контуру. Компании стремятся связать существующие ERP, WMS, POS, MES, SCADA, IoT-системы и внутренние базы данных без полной перестройки ИТ-ландшафта.&lltt;/p&ggtt;
&lltt;p&ggtt;На промышленных предприятиях платформенные решения чаще всего использовались по следующим направлениям: управление производственными заданиями и сменной отчетностью, техническое обслуживание и ремонт оборудования, мониторинг технологических параметров с использованием IoT и SCADA, управление качеством, инцидентами и отклонениями. Отдельное направление — задачи, которые традиционно относят к контуру MES: сменные задания, отчётность по выпуску, регистрация отклонений и контроль исполнения на уровне цеха. &lltt;/p&ggtt;
&lltt;p&ggtt;По данным аналитиков STAQ, в среднем по проектам, применение платформ на производственных предприятиях в 1 полугодии 2026 года позволило в сравнении с показателями до внедрения: сократить затраты на внеплановые ремонты на 21%, уменьшить количество незапланированных простоев на 28%, ускорить реакцию на выявленные дефекты на 16%. Данные начали использоваться не только для отчетности. Система автоматически формирует задачу при обнаружении отклонения, назначает ответственного, контролирует срок выполнения и сохраняет результат.&lltt;/p&ggtt;
&lltt;p&ggtt;Основными направлениями использования платформ в розничной торговле стали: централизация заявок от магазинов и других торговых объектов, обслуживание касс, холодильников, торговых автоматов и инженерных систем, управление мерчандайзерами, техническими специалистами и подрядчиками, контроль SLA, наличия товаров и качества обслуживания торговых точек. Вместо обращений по телефону, электронной почте и в мессенджерах торговая сеть получает единую точку входа. Заявки автоматически распределяются по региону, типу проблемы, приоритету и компетенции исполнителя. В одном из проектов STAQ была централизована обработка заявок более чем из 300 магазинов. В сравнении с периодом до внедрения сроки исполнения заявок сократились на 30%, количество случаев отсутствия товара из-за отказов оборудования уменьшилось на 50%, более 20% заявок стали обрабатываться без участия человека, а среднее число заявок, закрываемых одним диспетчером за смену, выросло на 60%.&lltt;/p&ggtt;
&lltt;p&ggtt;В транспортно-логистической отрасли платформы применялись для управления техническим состоянием транспорта и инфраструктуры, планирования ТОиР и внеплановых ремонтов, диспетчеризации и контроля исполнения рейсов, обработки ИТ- и инфраструктурных инцидентов, управления подрядными перевозчиками и соблюдения SLA. В одном из проектов STAQ для крупной логистической компании количество инцидентов, влияющих на операционные процессы, сократилось на 47%, выполнение SLA по критичным системам достигло 94%, а простои стоек регистрации уменьшились на 62%. Интеграция с ERP также позволила ускорить закупку запасных частей на два дня. Основной результат использования платформ для транспортно-логистической отрасли — сокращение незапланированных остановок и переход от ручной диспетчеризации к управлению на основании данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Во 2 полугодии 2026 года STAQ ожидает сохранения спроса на платформенные решения со стороны промышленности, ритейла и логистики, но при более консервативном отношении к ИТ-бюджетам: в приоритете будут проекты с измеримой и быстрой окупаемостью, а повестка сместится с роста выручки на сокращение операционных затрат. Изменится характер проектов: компании будут чаще переходить от автоматизации отдельного процесса к тиражированию решений на несколько площадок. Основными направлениями развития станут: предиктивное обслуживание оборудования на основе IoT-данных, применение ИИ для классификации заявок, выявления отклонений и поддержки диспетчеров, объединение производственных, эксплуатационных и сервисных процессов на одной платформе. Кроме того, компании осуществят более глубокую интеграцию с ERP, WMS, POS, MES и SCADA. &lltt;/p&ggtt;
&lltt;p&ggtt;«В 1 полугодии 2026 года платформенный подход вышел за рамки простой замены бумажных процессов цифровыми. Компании используют платформы как операционный контур, который связывает оборудование, сотрудников, подрядчиков и управленческую аналитику. Мы видим, что ожидания от предиктивной аналитики и ИИ сегодня опережают готовность данных: пока не выстроен учёт оборудования, заявок и истории ремонтов, модели не на чем обучать. Поэтому ближайший этап для большинства компаний — не новые технологии, а качество эксплуатационных данных», — отметил Евгений Гусев, генеральный директор STAQ.&lltt;/p&ggtt;]]></source>
<adate>31.08.2026</adate>
<dbid>235436</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Цифровая трансформация]]></tag>
</item>
<item>
<title><![CDATA[7 из 10 компаний, реализующих BYOD, делают это с ошибками]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235435]]></link>
<description><![CDATA[Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась в российской корпоративной практике. По оценке экспертов «Кросстеха», до 90% сотрудников организаций используют личные устройства для решения рабочих задач. Внедрение BYOD или отдельных элементов концепции выгодно бизнесу, так как позволяет сократить расходы на оборудование и создать более комфортные условия работы для сотрудников. При этом зачастую внедрение происходит без должной подготовки, что потенциально может привести к серьезным инцидентам информационной безопасности. Около 70% организаций внедряют этот подход с ошибками, создавая дополнительные киберриски, которые могут приводить к утечкам данных и другим инцидентам информационной безопасности безопасности Главная ошибка — попытка управлять чужой техникой через крайности. Первая крайность — полная вседозволенность. Когда компания не задает правил, менеджер скачивает договор на личный смартфон, чтобы доработать его вечером дома. Если этот телефон потеряется в такси или попадет в руки ребенку, который случайно установит вредоносную игру, корпоративная тайна мгновенно станет публичной. Вторая крайность — тотальная слежка и гиперопека. Когда отдел безопасности требует установить на личный ПК программы, которые отслеживают все действия пользователя, сотрудники воспринимают это как вторжение в личную жизнь. В ответ возникает «Теневое ИТ»: вместо разрешенных каналов специалисты начинают тихо пересылать рабочие документы в личные мессенджеры и сторонние хранилища, полностью скрывая эти процессы от компании. «Адекватный путь внедрения BYOD строится не на полном контроле устройства, а на понятном разделении личного и рабочего пространства. Главный принцип — компании должно быть важно только то, как обрабатываются ее данные, а не то, чем занимается человек в свое свободное время на своем устройстве», — говорит Егор Норкин, архитектор ИБ компании «Кросстех». Наиболее эффективный подход к BYOD строится на трех ключевых мерах: изоляции рабочего контура на личных устройствах, разграничении доступа к критичным системам и прозрачных правилах взаимодействия. На смартфонах рабочая среда прячется в зашифрованный контейнер, исключающий утечки и позволяющий точечно удалить данные компании при увольнении. Для домашних ПК организуется защищенный доступ через выделенные рабочие столы без прямой связи с внутренней сетью, а все требования к технике, компенсации и технической поддержке фиксируются в понятном регламенте. «ИБ сегодня — это баланс между сохранностью данных, бизнес-целями и комфортом людей. Бизнес всегда в приоритете, но рабочие процессы должны быть устроены так, чтобы они не были уязвимы. BYOD — отличная концепция, если решить это уравнение правильно. Сделать личную технику сотрудников безопасной абсолютно реально: достаточно грамотно оценить риски, разграничить корпоративный контур и уходить в крайности», — отметил Егор Норкин]]></description>
<source><![CDATA[&lltt;p&ggtt;Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась в российской корпоративной практике. По оценке экспертов «Кросстеха», до 90% сотрудников организаций используют личные устройства для решения рабочих задач. Внедрение BYOD или отдельных элементов концепции выгодно бизнесу, так как позволяет сократить расходы на оборудование и создать более комфортные условия работы для сотрудников. При этом зачастую внедрение происходит без должной подготовки, что потенциально может привести к серьезным инцидентам информационной безопасности. Около 70% организаций внедряют этот подход с ошибками, создавая дополнительные киберриски, которые могут приводить к утечкам данных и другим инцидентам информационной безопасности безопасности&lltt;/p&ggtt;
&lltt;p&ggtt;Главная ошибка — попытка управлять чужой техникой через крайности. Первая крайность — полная вседозволенность. Когда компания не задает правил, менеджер скачивает договор на личный смартфон, чтобы доработать его вечером дома. Если этот телефон потеряется в такси или попадет в руки ребенку, который случайно установит вредоносную игру, корпоративная тайна мгновенно станет публичной. &lltt;/p&ggtt;
&lltt;p&ggtt;Вторая крайность — тотальная слежка и гиперопека. Когда отдел безопасности требует установить на личный ПК программы, которые отслеживают все действия пользователя, сотрудники воспринимают это как вторжение в личную жизнь. В ответ возникает «Теневое ИТ»: вместо разрешенных каналов специалисты начинают тихо пересылать рабочие документы в личные мессенджеры и сторонние хранилища, полностью скрывая эти процессы от компании.&lltt;/p&ggtt;
&lltt;p&ggtt;«Адекватный путь внедрения BYOD строится не на полном контроле устройства, а на понятном разделении личного и рабочего пространства. Главный принцип — компании должно быть важно только то, как обрабатываются ее данные, а не то, чем занимается человек в свое свободное время на своем устройстве», — говорит Егор Норкин, архитектор ИБ компании «Кросстех».&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее эффективный подход к BYOD строится на трех ключевых мерах: изоляции рабочего контура на личных устройствах, разграничении доступа к критичным системам и прозрачных правилах взаимодействия. На смартфонах рабочая среда прячется в зашифрованный контейнер, исключающий утечки и позволяющий точечно удалить данные компании при увольнении. Для домашних ПК организуется защищенный доступ через выделенные рабочие столы без прямой связи с внутренней сетью, а все требования к технике, компенсации и технической поддержке фиксируются в понятном регламенте. &lltt;/p&ggtt;
&lltt;p&ggtt;«ИБ сегодня — это баланс между сохранностью данных, бизнес-целями и комфортом людей. Бизнес всегда в приоритете, но рабочие процессы должны быть устроены так, чтобы они не были уязвимы. BYOD — отличная концепция, если решить это уравнение правильно. Сделать личную технику сотрудников безопасной абсолютно реально: достаточно грамотно оценить риски, разграничить корпоративный контур и уходить в крайности», — отметил Егор Норкин.&lltt;/p&ggtt;]]></source>
<adate>31.08.2026</adate>
<dbid>235435</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[РЕД СОФТ выпустила обновление РЕД ОС 8.0.3 для архитектуры ARM]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235434]]></link>
<description><![CDATA[Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM. Система адаптирована для широкой линейки ARM-оборудования — от российских процессоров «Байкал» до популярных одноплатных компьютеров. РЕД ОС под ARM может применяться при создании встраиваемых систем, IoT-устройств, учебных стендов и серверных решений, требующих энергоэффективности. Использование единой операционной системы на всех типах устройств позволяет унифицировать ИТ-инфраструктуру предприятия, упростить администрирование и сократить расходы на поддержку. Образы РЕД ОС 8.0.3 для ARM доступны для скачивания на официальном сайте РЕД ОС. Совместимость РЕД ОС с архитектурой ARM продолжает расширяться. В новом релизе дополнен перечень поддерживаемых одноплатных компьютеров, востребованных на рынке. Функциональность образов РЕД ОС 8.0.3 полностью идентична версии для архитектуры x86_64. Полный список изменений и нововведений, вошедших в релиз РЕД ОС 8.0.3, доступен на сайте РЕД ОС. Важным отличием от предыдущего релиза является то, что теперь в одном образе объединена поддержка сразу нескольких ARM-устройств. На этапе установки можно выбрать требуемое устройство, и система будет установлена с соответствующим устройству ядром Linux. «Из коробки» поддерживаются следующие устройства: 	платформы на базе процессоров Huawei Kunpeng и Ampere Altra; 	устройства от «Элпитех» на базе процессоров Байкал-М, а также Байкал-S; 	устройства от ГК «Аквариус» на базе процессора Байкал-М; 	устройства от «Гравитон» на базе процессора Байкал-М. Расширена поддержка популярных одноплатных платформ, широко используемых в образовании, робототехнике, промышленной автоматизации и IoT-проектах. В список поддерживаемых РЕД ОС устройств добавлены новые модели: Raspberry Pi 3+ и Orange Pi Zero 3. Кроме того, обновлены образы для уже поддерживаемых платформ: Raspberry Pi 4/5, ROCKPro64, Orange Pi Zero 2W, Orange Pi 3 LTS и Repka Pi 4 Optimal. Пользователям доступен выбор из нескольких вариантов окружения рабочего стола: KDE Plasma, MATE или GNOME. Также доступна минимальная конфигурация без графики. РЕД ОС 8 под ARM была сертифицирована ФСТЭК России в декабре 2025 года. Сертифицированная РЕД ОС 8 под ARM поддерживает платформы на базе процессоров Huawei Kunpeng и Ampere Altra и ряд устройств на процессоре Байкал-М. Ведется работа над расширением поддерживаемых устройств на архитектуре ARM в Сертифицированной редакции РЕД ОС 8. «РЕД ОС 8.0.3 для ARM — это качественное обновление продукта для распространенных в России ARM-устройств. Все образы полностью сохраняют функциональность, идентичную версии для x86_64, что открывает ещё больше сценариев использования. В дальнейшем мы продолжим расширять перечень поддерживаемых устройств и совершенствовать механизмы развёртывания, чтобы каждый пользователь мог найти оптимальное решение для своих задач», — отметил Рустам Рустамов, заместитель генерального директора РЕД СОФТ]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM. Система адаптирована для широкой линейки ARM-оборудования — от российских процессоров «Байкал» до популярных одноплатных компьютеров.&lltt;/p&ggtt;
&lltt;p&ggtt;РЕД ОС под ARM может применяться при создании встраиваемых систем, IoT-устройств, учебных стендов и серверных решений, требующих энергоэффективности. Использование единой операционной системы на всех типах устройств позволяет унифицировать ИТ-инфраструктуру предприятия, упростить администрирование и сократить расходы на поддержку.&lltt;/p&ggtt;
&lltt;p&ggtt;Образы РЕД ОС 8.0.3 для ARM доступны для скачивания на официальном сайте РЕД ОС.&lltt;/p&ggtt;
&lltt;p&ggtt;Совместимость РЕД ОС с архитектурой ARM продолжает расширяться. В новом релизе дополнен перечень поддерживаемых одноплатных компьютеров, востребованных на рынке.&lltt;/p&ggtt;
&lltt;p&ggtt;Функциональность образов РЕД ОС 8.0.3 полностью идентична версии для архитектуры x86_64. Полный список изменений и нововведений, вошедших в релиз РЕД ОС 8.0.3, доступен на сайте РЕД ОС.&lltt;/p&ggtt;
&lltt;p&ggtt;Важным отличием от предыдущего релиза является то, что теперь в одном образе объединена поддержка сразу нескольких ARM-устройств. На этапе установки можно выбрать требуемое устройство, и система будет установлена с соответствующим устройству ядром Linux. «Из коробки» поддерживаются следующие устройства:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;платформы на базе процессоров Huawei Kunpeng и Ampere Altra;&lltt;/li&ggtt;
	&lltt;li&ggtt;устройства от «Элпитех» на базе процессоров Байкал-М, а также Байкал-S;&lltt;/li&ggtt;
	&lltt;li&ggtt;устройства от ГК «Аквариус» на базе процессора Байкал-М;&lltt;/li&ggtt;
	&lltt;li&ggtt;устройства от «Гравитон» на базе процессора Байкал-М.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Расширена поддержка популярных одноплатных платформ, широко используемых в образовании, робототехнике, промышленной автоматизации и IoT-проектах. В список поддерживаемых РЕД ОС устройств добавлены новые модели: Raspberry Pi 3+ и Orange Pi Zero 3. Кроме того, обновлены образы для уже поддерживаемых платформ: Raspberry Pi 4/5, ROCKPro64, Orange Pi Zero 2W, Orange Pi 3 LTS и Repka Pi 4 Optimal. &lltt;/p&ggtt;
&lltt;p&ggtt;Пользователям доступен выбор из нескольких вариантов окружения рабочего стола: KDE Plasma, MATE или GNOME. Также доступна минимальная конфигурация без графики.&lltt;/p&ggtt;
&lltt;p&ggtt;РЕД ОС 8 под ARM была сертифицирована ФСТЭК России в декабре 2025 года. Сертифицированная РЕД ОС 8 под ARM поддерживает платформы на базе процессоров Huawei Kunpeng и Ampere Altra и ряд устройств на процессоре Байкал-М. Ведется работа над расширением поддерживаемых устройств на архитектуре ARM в Сертифицированной редакции РЕД ОС 8.&lltt;/p&ggtt;
&lltt;p&ggtt;«РЕД ОС 8.0.3 для ARM — это качественное обновление продукта для распространенных в России ARM-устройств. Все образы полностью сохраняют функциональность, идентичную версии для x86_64, что открывает ещё больше сценариев использования. В дальнейшем мы продолжим расширять перечень поддерживаемых устройств и совершенствовать механизмы развёртывания, чтобы каждый пользователь мог найти оптимальное решение для своих задач», — отметил Рустам Рустамов, заместитель генерального директора РЕД СОФТ.&lltt;/p&ggtt;]]></source>
<adate>31.08.2026</adate>
<dbid>235434</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Сети/Серверы/СХД/ЦОД]]></tag>
</item>
<item>
<title><![CDATA[Исследование Axiom JDK выявило незакрытую потребность российских компаний в сопровождении Spring]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235433]]></link>
<description><![CDATA[Компания Axiom JDK (АО «Аксиом») представила исследование о том, как российские компании управляют версиями Spring Boot, планируют миграцию и оценивают риски после окончания публичной поддержки. Сегодня международная поддержка Spring недоступна российским заказчикам на стандартных условиях. При этом 55,8% Java-разработчиков не определили срок эксплуатации Spring без публичных обновлений, 61,2% отметили практическую ценность расширенной поддержки, но только 26,9% уже используют или готовы рассматривать её. В опросе приняли участие более 300 специалистов в области Java-разработки, 87,8% из которых регулярно используют Spring — самый распространённый фреймворк для разработки Java-приложений в России. Исследование отражает прежде всего ситуацию в крупном бизнесе и финансовой отрасли: 71,1% участников работают в организациях численностью более 1000 сотрудников, 56,1% представляют финтех. Таким образом, риски окончания поддержки Spring затрагивают не только команды разработки, но и Java-приложения, обеспечивающие ключевые процессы банков, крупных компаний и цифровых сервисов. Наиболее распространённым поколением остаётся Spring Boot 3.x: его используют 83,7% участников. Spring Boot 2.x продолжает применять 21,2%, Spring Boot 4.x — 26%. Близкую картину показывает исследование State of Java 2026 компании JUG Ru Group: версии 2.x используют 20,4% опрошенных пользователей Spring, 3.x — 73,1%, 4.x — 24,7%. Публичные обновления версий Spring Boot выпускаются ограниченное время — для промежуточных веток около 13 месяцев. После завершения этого периода компании должны перейти на новую версию, сопровождать используемую ветку самостоятельно или использовать коммерческую поддержку. В июне 2026 года завершился выпуск публичных обновлений для Spring Boot 3.5 — наиболее распространённого поколения среди участников исследования. Международная коммерческая поддержка Spring российским заказчикам на стандартных условиях недоступна после прекращения VMware и Broadcom продаж и сопровождения в России. Поэтому компаниям необходимо самостоятельно обеспечить источник исправлений и план перехода. Однако исследование показывает, что такой сценарий сформирован не везде. 53,5% участников не знали дату окончания поддержки Spring Boot 3.5, а 55,8% не определили допустимый срок эксплуатации версии без публичных обновлений, включая исправления безопасности. 18,9 % участников сообщили, что работы по переходу на Spring Boot 4 уже выполняются или завершено, для 41% переход пока остается планом. 23,7 % респондентов не приняли решение. При этом 32,7% участников одновременно используют несколько поколений Spring Boot. Новые приложения могут уже работать на актуальной версии, тогда как действующие системы продолжают использовать 2.x и 3.x. Это увеличивает объём работ по контролю уязвимостей, совместимости и обновлений и не позволяет завершить миграцию одномоментно. Требования информационной безопасности назвали причиной обновления Java и связанных фреймворков 57,7% участников. Однако инициаторами изменений чаще становятся разработчики (63,5%), тогда как подразделения ИБ и AppSec указали 36,5%. Риск возникает, когда между выявлением уязвимости и внедрением исправления не назначен единый владелец процесса, не установлен срок реакции и не определён источник обновлений. Результаты согласуются с данными State of Java 2026 по поддержке Spring Boot. По оценке JUG Ru Group, 61,5% разработчиков самостоятельно обновляют зависимости, 34,9% проверяют совместимость, 27% анализируют уязвимости, 23,4% контролируют версии и сроки поддержки, 21,5% исправляют дефекты. Отказ от внешней поддержки не устраняет эти задачи — они переходят внутренним командам и конкурируют за ресурсы с развитием продуктов. Только 26,9% участников исследования Axiom JDK уже используют или готовы рассматривать коммерческую поддержку Spring Boot. При этом 61,2% отметили хотя бы одну её практическую ценность. Наиболее востребованы исправления безопасности после окончания публичной поддержки — 29,8%, сопровождение необходимых версий и помощь с миграцией — по 23,4%, закреплённые сроки реакции (SLA) — 20,5%, экспертные консультации — 20,2%. Даже среди участников, которые не рассматривают комплексную коммерческую поддержку, 43,4% готовы использовать ее под конкретные задачи, например, чтобы облегчить работу по поиску исправлений и миграции. «Spring лежит в основе большого числа приложений крупного бизнеса и финансового сектора. Окончание публичной поддержки становится проблемой в момент появления уязвимости, когда компании срочно требуется проверенное исправление. Если источник обновлений и ответственный за процесс не определены заранее, риски переходят из технической плоскости на уровень реальной работы бизнеса, информационной безопасности и бюджетов — растут затраты и нагрузка на команды разработки. Для каждой промышленной системы необходимо заранее установить срок эксплуатации версии, план миграции и порядок получения исправлений», — отметил Илья Сазонов, директор по продукту Axiom JDK (АО «Аксиом»]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;span&ggtt;Компания&lltt;/span&ggtt;&lltt;span&ggtt; Axiom JDK (АО&lltt;/span&ggtt; &lltt;span&ggtt;«Аксиом») представила исследование о&lltt;/span&ggtt; &lltt;span&ggtt;том, как российские компании управляют версиями Spring Boot, планируют миграцию и&lltt;/span&ggtt; &lltt;span&ggtt;оценивают риски после окончания публичной поддержки. Сегодня международная поддержка Spring недоступна российским заказчикам на&lltt;/span&ggtt; &lltt;span&ggtt;стандартных условиях. При этом 55,8% Java-разработчиков не&lltt;/span&ggtt; &lltt;span&ggtt;определили срок эксплуатации Spring без публичных обновлений, 61,2% отметили практическую ценность расширенной поддержки, но&lltt;/span&ggtt; &lltt;span&ggtt;только 26,9% уже используют или готовы рассматривать&lltt;/span&ggtt; &lltt;span&ggtt;её. В&lltt;/span&ggtt; &lltt;span&ggtt;опросе приняли участие более 300 специалистов в&lltt;/span&ggtt; &lltt;span&ggtt;области Java-разработки, 87,8% из&lltt;/span&ggtt; &lltt;span&ggtt;которых регулярно используют Spring&lltt;/span&ggtt; &lltt;span&ggtt;— самый распространённый фреймворк для разработки Java-приложений в&lltt;/span&ggtt; &lltt;span&ggtt;России.&lltt;/span&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Исследование отражает прежде всего ситуацию в крупном бизнесе и финансовой отрасли: 71,1% участников работают в организациях численностью более 1000 сотрудников, 56,1% представляют финтех. Таким образом, риски окончания поддержки Spring затрагивают не только команды разработки, но и Java-приложения, обеспечивающие ключевые процессы банков, крупных компаний и цифровых сервисов.&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее распространённым поколением остаётся Spring Boot 3.x: его используют 83,7% участников. Spring Boot 2.x продолжает применять 21,2%, Spring Boot 4.x — 26%. Близкую картину показывает исследование State of Java 2026 компании JUG Ru Group: версии 2.x используют 20,4% опрошенных пользователей Spring, 3.x — 73,1%, 4.x — 24,7%.&lltt;/p&ggtt;
&lltt;p&ggtt;Публичные обновления версий Spring Boot выпускаются ограниченное время — для промежуточных веток около 13 месяцев. После завершения этого периода компании должны перейти на новую версию, сопровождать используемую ветку самостоятельно или использовать коммерческую поддержку.&lltt;/p&ggtt;
&lltt;p&ggtt;В июне 2026 года завершился выпуск публичных обновлений для Spring Boot 3.5 — наиболее распространённого поколения среди участников исследования. Международная коммерческая поддержка Spring российским заказчикам на стандартных условиях недоступна после прекращения VMware и Broadcom продаж и сопровождения в России. Поэтому компаниям необходимо самостоятельно обеспечить источник исправлений и план перехода.&lltt;/p&ggtt;
&lltt;p&ggtt;Однако исследование показывает, что такой сценарий сформирован не везде. 53,5% участников не знали дату окончания поддержки Spring Boot 3.5, а 55,8% не определили допустимый срок эксплуатации версии без публичных обновлений, включая исправления безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;18,9 % участников сообщили, что работы по переходу на Spring Boot 4 уже выполняются или завершено, для 41% переход пока остается планом. 23,7 % респондентов не приняли решение. &lltt;/p&ggtt;
&lltt;p&ggtt;При этом 32,7% участников одновременно используют несколько поколений Spring Boot. Новые приложения могут уже работать на актуальной версии, тогда как действующие системы продолжают использовать 2.x и 3.x. Это увеличивает объём работ по контролю уязвимостей, совместимости и обновлений и не позволяет завершить миграцию одномоментно.&lltt;/p&ggtt;
&lltt;p&ggtt;Требования информационной безопасности назвали причиной обновления Java и связанных фреймворков 57,7% участников. Однако инициаторами изменений чаще становятся разработчики (63,5%), тогда как подразделения ИБ и AppSec указали 36,5%. Риск возникает, когда между выявлением уязвимости и внедрением исправления не назначен единый владелец процесса, не установлен срок реакции и не определён источник обновлений.&lltt;/p&ggtt;
&lltt;p&ggtt;Результаты согласуются с данными State of Java 2026 по поддержке Spring Boot. По оценке JUG Ru Group, 61,5% разработчиков самостоятельно обновляют зависимости, 34,9% проверяют совместимость, 27% анализируют уязвимости, 23,4% контролируют версии и сроки поддержки, 21,5% исправляют дефекты. Отказ от внешней поддержки не устраняет эти задачи — они переходят внутренним командам и конкурируют за ресурсы с развитием продуктов.&lltt;/p&ggtt;
&lltt;p&ggtt;Только 26,9% участников исследования Axiom JDK уже используют или готовы рассматривать коммерческую поддержку Spring Boot. При этом 61,2% отметили хотя бы одну её практическую ценность. Наиболее востребованы исправления безопасности после окончания публичной поддержки — 29,8%, сопровождение необходимых версий и помощь с миграцией — по 23,4%, закреплённые сроки реакции (SLA) — 20,5%, экспертные консультации — 20,2%. Даже среди участников, которые не рассматривают комплексную коммерческую поддержку, 43,4% готовы использовать ее под конкретные задачи, например, чтобы облегчить работу по поиску исправлений и миграции. &lltt;/p&ggtt;
&lltt;p&ggtt;«Spring лежит в основе большого числа приложений крупного бизнеса и финансового сектора. Окончание публичной поддержки становится проблемой в момент появления уязвимости, когда компании срочно требуется проверенное исправление. Если источник обновлений и ответственный за процесс не определены заранее, риски переходят из технической плоскости на уровень реальной работы бизнеса, информационной безопасности и бюджетов — растут затраты и нагрузка на команды разработки. Для каждой промышленной системы необходимо заранее установить срок эксплуатации версии, план миграции и порядок получения исправлений», — отметил Илья Сазонов, директор по продукту Axiom JDK (АО «Аксиом»)&lltt;/p&ggtt;]]></source>
<adate>31.08.2026</adate>
<dbid>235433</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[GreenData расширила инструменты аналитики и автоматизации отчетности]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235432]]></link>
<description><![CDATA[Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы с данными: от анализа и корректировки показателей до автоматического формирования табличных отчетов. В новой версии low-code-платформы появилась возможность редактировать данные прямо в OLAP, а также настраивать итоговые строки и столбцы в OLAP-представлениях. Дополнительно были расширены возможности по работе с новыми электронными таблицами: стало возможно осуществить экспорт сразу при выполнении серверной процедуры в рамках выполнения алгоритма. Так, пользователи теперь могут не только анализировать данные, но и редактировать их непосредственно в представлении OLAP. Бизнес-администратор сам определяет сценарий работы: разрешить только открытие карточек объектов, только редактирование значений в таблице или использовать оба режима одновременно. Все необходимые настройки выполняются в карточке куба, позволяя вносить изменения без постоянного перехода из аналитического представления в карточки объектов и обратно. Также в OLAP-представлениях появилась настройка отображения итоговых строк и столбцов. Пользователь может выбрать необходимые вычисления для строк или столбцов — например, сумму, среднее, минимальное или другое значение. После применения настроек итоги сразу отображаются в таблице. Новый механизм помогает быстрее получать сводные показатели и анализировать данные без дополнительной обработки или экспорта информации во внешние инструменты. Еще одно изменение касается электронных таблиц. Теперь их можно автоматически экспортировать в формат XLSX прямо из алгоритмов. Для этого в платформе появились новые функции, которые позволяют сформировать файл, сохранить его в системе или использовать для дальнейшей автоматизированной обработки. Такой сценарий может применяться для регулярной отчетности, обмена данными с внешними системами и подготовки табличных документов по заданным правилам. «Новые возможности помогают сократить количество ручных операций при работе с аналитикой и отчетностью. Пользователь может получить сводные показатели непосредственно в OLAP-представлении, при необходимости скорректировать данные, а затем автоматически сформировать XLSX-файл. В результате весь процесс, от анализа информации до подготовки отчета, выполняется в рамках единого рабочего сценария», — отметила Ксения Золотарева, директор по продукту GreenData]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы с данными: от анализа и корректировки показателей до автоматического формирования табличных отчетов. В новой версии low-code-платформы появилась возможность редактировать данные прямо в OLAP, а также настраивать итоговые строки и столбцы в OLAP-представлениях. Дополнительно были расширены возможности по работе с новыми электронными таблицами: стало возможно осуществить экспорт сразу при выполнении серверной процедуры в рамках выполнения алгоритма.&lltt;/p&ggtt;
&lltt;p&ggtt;Так, пользователи теперь могут не только анализировать данные, но и редактировать их непосредственно в представлении OLAP. Бизнес-администратор сам определяет сценарий работы: разрешить только открытие карточек объектов, только редактирование значений в таблице или использовать оба режима одновременно. Все необходимые настройки выполняются в карточке куба, позволяя вносить изменения без постоянного перехода из аналитического представления в карточки объектов и обратно.&lltt;/p&ggtt;
&lltt;p&ggtt;Также в OLAP-представлениях появилась настройка отображения итоговых строк и столбцов. Пользователь может выбрать необходимые вычисления для строк или столбцов — например, сумму, среднее, минимальное или другое значение. После применения настроек итоги сразу отображаются в таблице. Новый механизм помогает быстрее получать сводные показатели и анализировать данные без дополнительной обработки или экспорта информации во внешние инструменты.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще одно изменение касается электронных таблиц. Теперь их можно автоматически экспортировать в формат XLSX прямо из алгоритмов. Для этого в платформе появились новые функции, которые позволяют сформировать файл, сохранить его в системе или использовать для дальнейшей автоматизированной обработки. Такой сценарий может применяться для регулярной отчетности, обмена данными с внешними системами и подготовки табличных документов по заданным правилам.&lltt;/p&ggtt;
&lltt;p&ggtt;«Новые возможности помогают сократить количество ручных операций при работе с аналитикой и отчетностью. Пользователь может получить сводные показатели непосредственно в OLAP-представлении, при необходимости скорректировать данные, а затем автоматически сформировать XLSX-файл. В результате весь процесс, от анализа информации до подготовки отчета, выполняется в рамках единого рабочего сценария», — отметила Ксения Золотарева, директор по продукту GreenData.&lltt;/p&ggtt;]]></source>
<adate>31.08.2026</adate>
<dbid>235432</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Big Data/Аналитика]]></tag>
</item>
<item>
<title><![CDATA[Очереди на PostgreSQL: от надёжности к масштабированию]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235430]]></link>
<description><![CDATA[Далеко не каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих backend-продуктов очередь на базе PostgreSQL проще и надежнее в эксплуатации. Используя FOR UPDATE SKIP LOCKED, advisory locks, transactional outbox и корректную модель повторной обработки, можно связать изменение бизнес-данных и постановку фоновой задачи в одной транзакции. В статье разбираю реализацию пула обработчиков на Go, конкуренцию между потребителями и нарастающую задержку перед повтором. Показываю, как работать с очередью необработанных сообщений, корректной остановкой и очисткой накопившихся записей. А ещё определяю границу, после которой очередь поверх Postgres перестаёт быть прагматичным решением и проигрывает специализированному брокеру сообщений — по пропускной способности, времени отклика и управляемости. Проблема двух систем Почти в каждом backend-продукте пользователь оформляет заказ. Системе нужно отправить письмо, сформировать отчёт и вызвать внешние API. Выполнять такую задачу прямо в HTTP-запросе не всегда разумно. Увеличивается время ответа, а пользовательский сценарий становится зависимым от внешних сервисов. Команда обычно пользуется привычным набором: Kafka, RabbitMQ или Redis. Появляется риск рассинхронизации. Заказ уже сохранён в базе, но сообщение в брокер не отправлено. Процесс завершился между двумя операциями. Или обратная ситуация: задача стала доступна воркеру до того, как связанные с ней данные были зафиксированы в базе. Это частный случай проблемы двойной записи. Изменение бизнес-данных и постановка фоновой задачи происходят в разных системах и не образуют одну транзакцию. Классическим ответом на эту проблему является использование паттерна «transactional outbox». Приложение в одной транзакции меняет бизнес-данные и пишет строку в служебную таблицу исходящих сообщений, а отдельный процесс читает её и доставляет сообщение в брокер. Атомарность восстановлена, свойства Kafka или RabbitMQ сохранены. Но в системе появляется ещё один компонент, который нужно писать, разворачивать и мониторить, а брокер по-прежнему остаётся в эксплуатации. Получается, что таблица в PostgreSQL всё равно нужна — вопрос лишь в том, служит она перевалочным пунктом или самой очередью. Можно пойти дальше и убрать брокер совсем. Если очередь живёт в том же PostgreSQL, что и бизнес-данные, то изменение заказа и постановка фоновой задачи — одна атомарная операция. В рамках операции либо произошло и то, и другое, либо ничего. Никакого зазора, в который может провалиться работа. Одна строчка SQL вместо брокера Вся конструкция опирается на обычную таблицу — назовём её «jobs». В ней хранится минимум: тип задачи, полезная нагрузка в JSON, статус, время, раньше которого задачу запускать не нужно, а также счётчик попыток. Постановка задачи — это простой INSERT (его можно выполнить в той же транзакции, что и изменение бизнес-данных). Такой процесс закрывает проблему двух систем из предыдущего раздела. Однако остается вопрос, как несколько параллельных Go-воркеров будут разбирать задачи, не выстраиваясь в очередь друг за другом? Ответ — конструкция FOR UPDATE SKIP LOCKED, появившаяся в PostgreSQL ещё в версии 9.5: SELECT id FROM jobs WHERE status = ’ready’ AND run_at &#60;= now() ORDER BY run_at LIMIT 10 FOR UPDATE SKIP LOCKED; Запрос выбирает готовые к запуску задачи и временно блокирует выбранные строки. Если другую задачу уже обрабатывает параллельный воркер, SKIP LOCKED не ждёт освобождения блокировки, а пропускает эту строку и переходит к следующей. Благодаря этому несколько воркеров могут работать одновременно, при этом они не забирают задачу дважды и не создают общую очередь ожидания. Далее воркер в короткой транзакции переводит задачи в статус обработки и фиксирует изменение. Затем он уже выполняет основную работу. Поэтому длительные операции не удерживают блокировки в базе и не мешают другим воркерам получать новые задачи. Правила работы с очередью Таблица задач и механизм SKIP LOCKED позволяют нескольким воркерам безопасно забирать работу без дублирования. Чтобы такую очередь можно было использовать в продакшене, нужно предусмотреть обработку сбоев. Если задача завершилась ошибкой, её не стоит сразу удалять. Обычно её возвращают в очередь с задержкой, увеличивая интервал между попытками. Это снижает нагрузку на временно недоступный внешний сервис. После заданного числа неудачных попыток задачу переводят в отдельный статус или хранилище для ручного разбора. Также необходимо учитывать и сбои самих воркеров. Если процесс получил задачу и завершился до окончания работы, она не должна остаться в статусе обработки навсегда. Для этого задаче дают ограниченное время обработки: когда оно истекает, другой воркер может взять её повторно. При штатной остановке воркер, наоборот, перестаёт брать новые задачи и завершает уже начатые. При такой модели возможны повторные запуски одной и той же задачи. Например, внешний API мог получить запрос, а воркер — завершиться до сохранения результата. Поэтому обработчики должны корректно переносить повторное выполнение. Например, не отправлять пуш-сообщение дважды или не создавать повторный платёж. Готовые библиотеки избавляют от необходимости реализовывать эти механизмы с нуля. Для Go можно рассмотреть библиотеки River, gue и другие решения поверх PostgreSQL. Выбор зависит от требований к автоматическим повторам и планированию задач, а также наблюдаемости и модели обработки. Работает и на серьёзном масштабе Очередь в PostgreSQL не ограничивается небольшими сервисами. Ее используют и высоконагруженные системы, если очередь проектируют и обслуживают как отдельный компонент. Например, для конкурентного получения задач в Я.Диске используется механизм FOR UPDATE SKIP LOCKED. Масштаб: десятки тысяч задач в секунду и сотни типов задач. Один из крупнейших сервисов рунета выбрал SQL-очередь, при том, что Kafka в компании тоже есть и используется там, где её свойства подходят лучше. Второй кейс — компания 37signals, создатели фреймворка Ruby on Rails, Basecamp и почтового сервиса HEY. В HEY отказались от Redis и перевели фоновые системы на очередь Solid Queue. Она обрабатывает около 20 млн. задач в сутки. Для этого используются 800 воркеров, четыре диспетчера и два планировщика на 74 виртуальных машинах. Очередь работает в отдельной базе данных, для которой выделены 32 CPU, 64 Гб памяти и 350 Гб диска. Solid Queue стал очередью по умолчанию в Ruby on Rails 8, а подход официально признан стандартом целой экосистемы. Где начинаются проблемы Очередь в PostgreSQL удобна, пока нагрузка на неё остаётся умеренной и предсказуемой. Но у подхода есть особенности, которые нужно учесть до запуска в продакшен. Первая особенность связана с частым изменением записей. Задача обычно создаётся, затем меняет статус, а после выполнения удаляется или архивируется. В PostgreSQL старые версии строк не исчезают сразу, их очищает механизм vacuum. Если он не успевает за потоком обновлений, таблица и индексы разрастаются, а запросы к очереди начинают работать медленнее. Поэтому для таблицы задач обычно настраивают отдельные параметры autovacuum, следят за размером таблицы и не хранят завершённые задачи. Вторая особенность касается механизма LISTEN/NOTIFY. Его суть в мгновенных уведомлениях, которыми удобно будить воркеров вместо периодического опроса таблицы. Компания Recall.ai в марте 2025 года получила из-за него три простоя: уведомления выполнялись в транзакциях, а на этапе COMMIT возникала конкуренция за глобальную блокировку, из-за чего коммиты фактически выстраивались в очередь. В PostgreSQL 19 обещают внедрить улучшения, которые уменьшают лишние пробуждения backend-процессов при NOTIFY, но это не отменит необходимости измерять поведение конкретной системы под нагрузкой. Где проходит граница очередей Интуитивно хочется провести границу и разделить применение очередей по реальной нагрузке. Но с большим опытом приходит понимание, что универсального порога по нагрузке нет. На практике значение имеют размер задач, число воркеров, индексы, частота повторных попыток и ресурсы самой базы. Гораздо важнее оценивать стоимость эксплуатации. Очередь на PostgreSQL удобна, пока использует существующую базу: те же бэкапы, мониторинг, инструменты диагностики и компетенции команды. Для многих прикладных задач этого достаточно — особенно, если очередь обслуживает фоновые операции одного приложения. Очереди «Яндекс Диска» и 37signals показывают, что PostgreSQL способен обрабатывать очень большой поток задач, но для этого очереди выделяют собственную базу, ресурсы, настройки обслуживания, мониторинг и т. д. У Диска очередь работает на шардированной базе с отдельной обвязкой, а в 37signals для Solid Queue используется выделенная база данных. Не менее важна семантика. Очередь в PostgreSQL — когда одному приложению нужно выполнить фоновую задачу. Если же одно событие должны независимо получать несколько сервисов, а историю нужно хранить и перечитывать — лучше подходит Kafka. Она рассчитана на хранение потока событий и независимое чтение разными группами потребителей. RabbitMQ уместнее, когда нужны готовые механизмы маршрутизации, подтверждения обработки и управления потоком сообщений. Эти возможности можно частично реализовать поверх таблицы в PostgreSQL, но тогда очередь постепенно превращается в собственный брокер, который нужно проектировать и сопровождать. RabbitMQ же предоставляет подтверждения обработки сообщений как встроенный механизм. Очередь на PostgreSQL не заменяет Kafka или RabbitMQ, но хорошо подходит для фоновых задач. Главный критерий выбора — не популярность или абстрактный предел по числу задач. В приоритете — какие свойства требуются системе и сколько будет стоить их эксплуатация. #IMAGE_235431#]]></description>
<source><![CDATA[&lltt;p&ggtt;Далеко не&nbsp;каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих backend-продуктов очередь на&nbsp;базе PostgreSQL проще и&nbsp;надежнее в&nbsp;эксплуатации. Используя FOR UPDATE SKIP LOCKED, advisory locks, transactional outbox и&nbsp;корректную модель повторной обработки, можно связать изменение бизнес-данных и&nbsp;постановку фоновой задачи в&nbsp;одной транзакции.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;статье разбираю реализацию пула обработчиков на&nbsp;Go, конкуренцию между потребителями и&nbsp;нарастающую задержку перед повтором. Показываю, как работать с&nbsp;очередью необработанных сообщений, корректной остановкой и&nbsp;очисткой накопившихся записей. А&nbsp;ещё определяю границу, после которой очередь поверх Postgres перестаёт быть прагматичным решением и&nbsp;проигрывает специализированному брокеру сообщений&nbsp;— по&nbsp;пропускной способности, времени отклика и&nbsp;управляемости.&lltt;/p&ggtt;
&lltt;h3&ggtt;Проблема двух систем&lltt;/h3&ggtt;
&lltt;p&ggtt;Почти в&nbsp;каждом backend-продукте пользователь оформляет заказ. Системе нужно отправить письмо, сформировать отчёт и&nbsp;вызвать внешние API. Выполнять такую задачу прямо в&nbsp;HTTP-запросе не&nbsp;всегда разумно. Увеличивается время ответа, а&nbsp;пользовательский сценарий становится зависимым от&nbsp;внешних сервисов. Команда обычно пользуется привычным набором: Kafka, RabbitMQ или Redis.&lltt;/p&ggtt;
&lltt;p&ggtt;Появляется риск рассинхронизации. Заказ уже сохранён в&nbsp;базе, но&nbsp;сообщение в&nbsp;брокер не&nbsp;отправлено. Процесс завершился между двумя операциями. Или обратная ситуация: задача стала доступна воркеру до&nbsp;того, как связанные с&nbsp;ней данные были зафиксированы в&nbsp;базе. Это частный случай проблемы двойной записи. Изменение бизнес-данных и&nbsp;постановка фоновой задачи происходят в&nbsp;разных системах и&nbsp;не&nbsp;образуют одну транзакцию.&lltt;/p&ggtt;
&lltt;p&ggtt;Классическим ответом на&nbsp;эту проблему является использование паттерна «transactional outbox». Приложение в&nbsp;одной транзакции меняет бизнес-данные и&nbsp;пишет строку в&nbsp;служебную таблицу исходящих сообщений, а&nbsp;отдельный процесс читает её&nbsp;и&nbsp;доставляет сообщение в&nbsp;брокер. Атомарность восстановлена, свойства Kafka или RabbitMQ сохранены. Но&nbsp;в&nbsp;системе появляется ещё один компонент, который нужно писать, разворачивать и&nbsp;мониторить, а&nbsp;брокер по-прежнему остаётся в&nbsp;эксплуатации. Получается, что таблица в&nbsp;PostgreSQL всё равно нужна&nbsp;— вопрос лишь в&nbsp;том, служит она перевалочным пунктом или самой очередью.&lltt;/p&ggtt;
&lltt;p&ggtt;Можно пойти дальше и&nbsp;убрать брокер совсем. Если очередь живёт в&nbsp;том&nbsp;же PostgreSQL, что и&nbsp;бизнес-данные, то&nbsp;изменение заказа и&nbsp;постановка фоновой задачи&nbsp;— одна атомарная операция. В&nbsp;рамках операции либо произошло и&nbsp;то, и&nbsp;другое, либо ничего. Никакого зазора, в&nbsp;который может провалиться работа.&lltt;/p&ggtt;
&lltt;h3&ggtt;Одна строчка SQL вместо брокера&lltt;/h3&ggtt;
&lltt;p&ggtt;Вся конструкция опирается на&nbsp;обычную таблицу&nbsp;— назовём её&nbsp;«jobs». В&nbsp;ней хранится минимум: тип задачи, полезная нагрузка в&nbsp;JSON, статус, время, раньше которого задачу запускать не&nbsp;нужно, а&nbsp;также счётчик попыток. Постановка задачи&nbsp;— это простой INSERT (его можно выполнить в&nbsp;той&nbsp;же транзакции, что и&nbsp;изменение бизнес-данных). Такой процесс закрывает проблему двух систем из&nbsp;предыдущего раздела.&lltt;/p&ggtt;
&lltt;p&ggtt;Однако остается вопрос, как несколько параллельных Go-воркеров будут разбирать задачи, не&nbsp;выстраиваясь в&nbsp;очередь друг за&nbsp;другом? Ответ&nbsp;— конструкция &lltt;strong&ggtt;FOR UPDATE SKIP LOCKED&lltt;/strong&ggtt;, появившаяся в&nbsp;PostgreSQL ещё в&nbsp;версии 9.5:&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;em&ggtt;SELECT id&nbsp;FROM jobs&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;em&ggtt;WHERE status = ’ready’ AND run_at &lt;= now()&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;em&ggtt;ORDER BY&nbsp;run_at&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;em&ggtt;LIMIT 10&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;em&ggtt;FOR UPDATE SKIP LOCKED;&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Запрос выбирает готовые к&nbsp;запуску задачи и&nbsp;временно блокирует выбранные строки. Если другую задачу уже обрабатывает параллельный воркер, SKIP LOCKED&nbsp;не ждёт освобождения блокировки, а&nbsp;пропускает эту строку и&nbsp;переходит к&nbsp;следующей. Благодаря этому несколько воркеров могут работать одновременно, при этом они не&nbsp;забирают задачу дважды и&nbsp;не&nbsp;создают общую очередь ожидания.&lltt;/p&ggtt;
&lltt;p&ggtt;Далее воркер в&nbsp;короткой транзакции переводит задачи в&nbsp;статус обработки и&nbsp;фиксирует изменение. Затем он&nbsp;уже выполняет основную работу. Поэтому длительные операции не&nbsp;удерживают блокировки в&nbsp;базе и&nbsp;не&nbsp;мешают другим воркерам получать новые задачи.&lltt;/p&ggtt;
&lltt;h3&ggtt;Правила работы с&nbsp;очередью&lltt;/h3&ggtt;
&lltt;p&ggtt;Таблица задач и&nbsp;механизм SKIP LOCKED позволяют нескольким воркерам безопасно забирать работу без дублирования. Чтобы такую очередь можно было использовать в&nbsp;продакшене, нужно предусмотреть обработку сбоев. Если задача завершилась ошибкой, её&nbsp;не&nbsp;стоит сразу удалять. Обычно её&nbsp;возвращают в&nbsp;очередь с&nbsp;задержкой, увеличивая интервал между попытками. Это снижает нагрузку на&nbsp;временно недоступный внешний сервис. После заданного числа неудачных попыток задачу переводят в&nbsp;отдельный статус или хранилище для ручного разбора.&lltt;/p&ggtt;
&lltt;p&ggtt;Также необходимо учитывать и&nbsp;сбои самих воркеров. Если процесс получил задачу и&nbsp;завершился до&nbsp;окончания работы, она не&nbsp;должна остаться в&nbsp;статусе обработки навсегда. Для этого задаче дают ограниченное время обработки: когда оно истекает, другой воркер может взять её&nbsp;повторно. При штатной остановке воркер, наоборот, перестаёт брать новые задачи и&nbsp;завершает уже начатые.&lltt;/p&ggtt;
&lltt;p&ggtt;При такой модели возможны повторные запуски одной и&nbsp;той&nbsp;же задачи. Например, внешний API мог получить запрос, а&nbsp;воркер&nbsp;— завершиться до&nbsp;сохранения результата. Поэтому обработчики должны корректно переносить повторное выполнение. Например, не&nbsp;отправлять пуш-сообщение дважды или не&nbsp;создавать повторный платёж.&lltt;/p&ggtt;
&lltt;p&ggtt;Готовые библиотеки избавляют от&nbsp;необходимости реализовывать эти механизмы с&nbsp;нуля. Для Go&nbsp;можно рассмотреть библиотеки River, gue и&nbsp;другие решения поверх PostgreSQL. Выбор зависит от&nbsp;требований к&nbsp;автоматическим повторам и&nbsp;планированию задач, а&nbsp;также наблюдаемости и&nbsp;модели обработки.&lltt;/p&ggtt;
&lltt;h3&ggtt;Работает и&nbsp;на&nbsp;серьёзном масштабе&lltt;/h3&ggtt;
&lltt;p&ggtt;Очередь в&nbsp;PostgreSQL&nbsp;не ограничивается небольшими сервисами. Ее&nbsp;используют и&nbsp;высоконагруженные системы, если очередь проектируют и&nbsp;обслуживают как отдельный компонент.&lltt;/p&ggtt;
&lltt;p&ggtt;Например, для конкурентного получения задач в&nbsp;Я.Диске используется механизм FOR UPDATE SKIP LOCKED. Масштаб: десятки тысяч задач в&nbsp;секунду и&nbsp;сотни типов задач. Один из&nbsp;крупнейших сервисов рунета выбрал SQL-очередь, при том, что Kafka в&nbsp;компании тоже есть и&nbsp;используется там, где её&nbsp;свойства подходят лучше.&lltt;/p&ggtt;
&lltt;p&ggtt;Второй кейс&nbsp;— компания 37signals, создатели фреймворка Ruby on&nbsp;Rails, Basecamp и&nbsp;почтового сервиса HEY. В&nbsp;HEY отказались от&nbsp;Redis и&nbsp;перевели фоновые системы на&nbsp;очередь Solid Queue. Она обрабатывает около 20&nbsp;млн. задач в&nbsp;сутки. Для этого используются 800&nbsp;воркеров, четыре диспетчера и&nbsp;два планировщика на&nbsp;74&nbsp;виртуальных машинах. Очередь работает в&nbsp;отдельной базе данных, для которой выделены 32&nbsp;CPU, 64&nbsp;Гб памяти и&nbsp;350&nbsp;Гб диска. Solid Queue стал очередью по&nbsp;умолчанию в&nbsp;Ruby on&nbsp;Rails&nbsp;8, а&nbsp;подход официально признан стандартом целой экосистемы.&lltt;/p&ggtt;
&lltt;h3&ggtt;Где начинаются проблемы&lltt;/h3&ggtt;
&lltt;p&ggtt;Очередь в&nbsp;PostgreSQL&nbsp;удобна, пока нагрузка на&nbsp;неё остаётся умеренной и&nbsp;предсказуемой. Но&nbsp;у&nbsp;подхода есть особенности, которые нужно учесть до&nbsp;запуска в&nbsp;продакшен.&lltt;/p&ggtt;
&lltt;p&ggtt;Первая особенность связана с&nbsp;частым изменением записей. Задача обычно создаётся, затем меняет статус, а&nbsp;после выполнения удаляется или архивируется. В&nbsp;PostgreSQL старые версии строк не&nbsp;исчезают сразу, их&nbsp;очищает механизм vacuum. Если он&nbsp;не&nbsp;успевает за&nbsp;потоком обновлений, таблица и&nbsp;индексы разрастаются, а&nbsp;запросы к&nbsp;очереди начинают работать медленнее. Поэтому для таблицы задач обычно настраивают отдельные параметры autovacuum, следят за&nbsp;размером таблицы и&nbsp;не&nbsp;хранят завершённые задачи.&lltt;/p&ggtt;
&lltt;p&ggtt;Вторая особенность касается механизма LISTEN/NOTIFY. Его суть в&nbsp;мгновенных уведомлениях, которыми удобно будить воркеров вместо периодического опроса таблицы. Компания Recall.ai в&nbsp;марте 2025 года получила из-за него три простоя: уведомления выполнялись в&nbsp;транзакциях, а&nbsp;на&nbsp;этапе COMMIT возникала конкуренция за&nbsp;глобальную блокировку, из-за чего коммиты фактически выстраивались в&nbsp;очередь. В&nbsp;PostgreSQL 19&nbsp;обещают внедрить улучшения, которые уменьшают лишние пробуждения backend-процессов при NOTIFY, но&nbsp;это не&nbsp;отменит необходимости измерять поведение конкретной системы под нагрузкой.&lltt;/p&ggtt;
&lltt;h3&ggtt;Где проходит граница очередей&lltt;/h3&ggtt;
&lltt;p&ggtt;Интуитивно хочется провести границу и&nbsp;разделить применение очередей по&nbsp;реальной нагрузке. Но&nbsp;с&nbsp;большим опытом приходит понимание, что универсального порога по&nbsp;нагрузке нет. На&nbsp;практике значение имеют размер задач, число воркеров, индексы, частота повторных попыток и&nbsp;ресурсы самой базы.&lltt;/p&ggtt;
&lltt;p&ggtt;Гораздо важнее оценивать стоимость эксплуатации. Очередь на&nbsp;PostgreSQL&nbsp;удобна, пока использует существующую базу: те&nbsp;же бэкапы, мониторинг, инструменты диагностики и&nbsp;компетенции команды. Для многих прикладных задач этого достаточно&nbsp;— особенно, если очередь обслуживает фоновые операции одного приложения.&lltt;/p&ggtt;
&lltt;p&ggtt;Очереди «Яндекс Диска» и&nbsp;37signals показывают, что PostgreSQL способен обрабатывать очень большой поток задач, но&nbsp;для этого очереди выделяют собственную базу, ресурсы, настройки обслуживания, мониторинг и&nbsp;т.&nbsp;д. У&nbsp;Диска очередь работает на&nbsp;шардированной базе с&nbsp;отдельной обвязкой, а&nbsp;в&nbsp;37signals для Solid Queue используется выделенная база данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Не&nbsp;менее важна семантика. Очередь в&nbsp;PostgreSQL&nbsp;— когда одному приложению нужно выполнить фоновую задачу. Если&nbsp;же одно событие должны независимо получать несколько сервисов, а&nbsp;историю нужно хранить и&nbsp;перечитывать&nbsp;— лучше подходит Kafka. Она рассчитана на&nbsp;хранение потока событий и&nbsp;независимое чтение разными группами потребителей.&lltt;/p&ggtt;
&lltt;p&ggtt;RabbitMQ уместнее, когда нужны готовые механизмы маршрутизации, подтверждения обработки и&nbsp;управления потоком сообщений. Эти возможности можно частично реализовать поверх таблицы в&nbsp;PostgreSQL, но&nbsp;тогда очередь постепенно превращается в&nbsp;собственный брокер, который нужно проектировать и&nbsp;сопровождать. RabbitMQ&nbsp;же предоставляет подтверждения обработки сообщений как встроенный механизм.&lltt;/p&ggtt;
&lltt;p&ggtt;Очередь на&nbsp;PostgreSQL&nbsp;не заменяет Kafka или RabbitMQ, но&nbsp;хорошо подходит для фоновых задач. Главный критерий выбора&nbsp;— не&nbsp;популярность или абстрактный предел по&nbsp;числу задач. В&nbsp;приоритете&nbsp;— какие свойства требуются системе и&nbsp;сколько будет стоить их&nbsp;эксплуатация.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235431#&lltt;/p&ggtt;]]></source>
<adate>31.08.2026</adate>
<dbid>235430</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/49e/vbgzf7g7m1a22s8fu7hw74idj45nd6wi.jpg]]>
</images>
<imagesname><![CDATA[;;Роман Муковнин, старший инженер-программист WildBerries   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Как выбраться из трясины бюджетирования ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235429]]></link>
<description><![CDATA[Опрошенные порталом InformationWeek эксперты рассказывают о том, как CIO могут помочь своим компаниям справиться с растущими и непредсказуемыми расходами на искусственный интеллект и сформировать бюджет, который будет приносить прибыль. Предприятиям не обойтись без расходов на ИИ. Но просто вкладывать деньги в эту технологию недостаточно для того, чтобы раскрыть ее потенциал в качестве инструмента повышения эффективности и роста доходов. Выделение бюджета на ИИ, который приносит реальную выгоду, является непростой задачей, поскольку CIO приходится учитывать расходы, которые не всегда очевидны. Исследование KPMG «Q2 2026 Global AI Pulse» показало, что только 35% организаций имеют полное представление о своих операционных расходах, связанных с ИИ. Эти организации в пять раз чаще сообщают о подтверждённой окупаемости инвестиций, чем те, у кого такой информации нет. Почему расходы на ИИ сложно спрогнозировать У предприятий нет чёткой схемы бюджетирования ИИ. Руководители компаний выясняют всё на ходу, а это значит, что неожиданностей и ошибок не избежать. «Очень легко столкнуться с непредвиденными расходами. И очень, очень сложно обеспечить структурированность и предсказуемость при масштабировании возможностей ИИ в крупной организации», — говорит Пол Блоуэрс, CIO компании Plante Moran, занимающейся аудитом, налогообложением, консалтингом и управлением активами. Расходы на ИИ не ограничиваются покупкой платформы или инструмента. Чтобы ИИ приносил пользу, ему нужна правильная основа, а для создания такой основы требуются инвестиции. «Вам нужен уровень данных, вам нужен уровень контекста, вам нужен уровень перевода. Кроме того, у вас будут уровень ИИ и уровень активации», — говорит Кристин Парк, директор по трансформации компании Branch, занимающейся мобильной аналитикой и диплинкингом. К этим базовым требованиям добавляются вопросы безопасности и управления, которые крайне важны. По словам Парк, в ее компании создание такой основы потребовало затрат на очистку баз данных и знаний. Кроме того, она наняла пару инженеров по автоматизации на основе ИИ, чтобы они помогали с рабочими процессами. Затраты на внедрение ИИ не ограничиваются инструментами При планировании бюджета на ИИ необходимо учитывать затраты на изменение методов работы сотрудников и способов выполнения самой работы. «Если вы закладываете в бюджет только стоимость инструмента, то, на мой взгляд, вас ждут проблемы, потому что нужно закладывать средства и на трансформацию, — говорит Парк. — Инструмент — это доступ, а трансформация — это переосмысление вашей работы». Переосмысление методов работы команд требует времени и денег. По словам Парк, это «сложный проект», который включает в себя изменения в реализации, конфигурации и рабочих процессах. «ИИ не решает всех проблем. ИИ — это инструмент», — отмечает она. Затраты на использование ИИ сложно предсказать Потребление по-прежнему является сложной частью головоломки бюджетирования ИИ. Цены на токены упали, но их использование резко возросло. «Каждый раз, когда выходит новая модель или новый сценарий использования внедряется в производственный процесс, потребление этих токенов растет все быстрее и быстрее, — говорит Блоуэрс. — Мы, CIO, сейчас становимся специалистами в области моделирования и ведения переговоров по токенам, но ситуация в этой сфере пока далека от стабильности». Он ожидает, что модели ценообразования на токены будут продолжать развиваться, а поставщики будут предлагать разные подходы. ИИ увеличивает расходы Предприятиям приходится не только самостоятельно решать вопрос с расходами на ИИ, но и учитывать, как инвестиции поставщиков в ИИ влияют на их затраты. Провайдеры SaaS-решений ищут способы встроить ИИ в свои продукты и монетизировать его, что приводит к росту цен. «Большинство ведущих поставщиков SaaS существенно повышают цены, чтобы реализовать свои планы по внедрению ИИ, — говорит Блоуэрс. — И можно с уверенностью сказать, что многие, если не большинство CIO, согласятся с тем, что эти цены растут еще до того, как будут внедрены зрелые функции ИИ, или до того, как мы сможем спрогнозировать, как будет выглядеть потребление внутри этих SaaS-инструментов и платформ». Как бюджетируют ИИ Учитывая, что затраты на ИИ так трудно предсказать, CIO начинают переосмысливать бюджетирование этой технологии. Для Парк это означает, что расходы на ИИ рассматриваются не как постоянная статья расходов, а как переменные затраты. «Это модель, основанная на потреблении. Это не фиксированная стоимость, как у SaaS», — поясняет она. Для компаний, которые не приложили достаточных усилий для создания прочной основы для инструментов и рабочих процессов ИИ, обсуждение бюджета может начаться с оценки затрат на создание всего с нуля. Эта основа очень важна. Опрос PwC «2026 Global CEO survey», в котором приняли участие 4454 топ-руководителя, показал, что организации с прочными основами, которые описываются как «ответственные платформы и технологические среды ИИ, обеспечивающие интеграцию в масштабах всего предприятия», имеют в три раза больше шансов получить «значимую финансовую отдачу». При планировании затрат на трансформацию предприятиям необходимо четко представлять, что означает интеграция ИИ для бизнеса. Парк утверждает, что чрезмерное внимание к показателям эффективности является ошибкой. «Мы действительно рассматриваем это как ключевой аспект исследований и разработок, потому что я не думаю, что ИИ должен быть инструментом повышения эффективности, — говорит она. — Я не считаю, что ИИ следует рассматривать как способ сокращения затрат на персонал. Я думаю, это неправильная формула». Независимо от того, какой путь выберут компании — повышения эффективности или внедрения инноваций, — им необходимо заложить в бюджет расходы на внедрение и использование ИИ. Дело не ограничивается покупкой ИИ-инструмента или платформы и требованием к сотрудникам их использовать. «Предоставить людям доступ — это еще не значит внедрить технологию», — говорит Парк. Конечно, по мере внедрения ИИ его использование — и затраты — могут расти. И бюджеты на ИИ должны учитывать этот рост. Блоуэрс вместе с другими руководителями работает над формированием бюджета своей компании на повседневное использование ИИ, в том числе инструментов для повышения производительности. «Мы планируем развивать этот подход по аналогии с FinOps: стимулировать внедрение, предоставлять сотрудникам возможность контролировать расходы, вводить ежемесячные лимиты с некоторыми поведенческими стимулами, — отмечает он. — Обучение само по себе является ключевым инструментом контроля затрат, а не просто способом ограничить потребление токенов». Они также занимаются определением сценариев использования ИИ для масштабирования. «Масштабирование немного проще контролировать с точки зрения затрат, планировать и прогнозировать, потому что мы централизуем процессы и они проходят через наши обычные бизнес-процессы и этапы жизненного цикла разработки ПО», — говорит Блоуэрс. ИИ, встроенный в SaaS-продукты, — это третья статья расходов, которой занимаются Блоуэрс и его коллеги. Это значит, что нужно обсуждать с поставщиками, как ИИ встраивается в уже имеющиеся у компании инструменты и как это влияет на цены при продлении контрактов. «Чтобы справиться с этой проблемой, мы настаиваем на том, чтобы наши партнеры-поставщики соглашались на наши условия, разрабатывали проактивные дорожные карты и оценивали влияние на наши прибыль и убытки, прежде чем соглашаться на предлагаемое ими ценообразование токенов», — говорит Блоуэрс. В компании Парк консолидация инструментов стала частью подхода к бюджетированию. «Вам нужно начать консолидировать инструменты, чтобы получить экономию», — говорит она. Роль CIO в бюджетировании ИИ CIO играет ключевую роль во внедрении и бюджетировании ИИ, но для этого ему необходимо взаимодействовать с другими руководителями высшего звена и членами совета директоров, чтобы определить, какую ценность они ожидают получить от ИИ и сколько готовы на это потратить. Поэтому особенно важным партнером является финансовый директор. «Нужно тесно сотрудничать с финансовыми директорами, — говорит Блоуэрс. — Честно говоря, здоровая критика в этом вопросе полезна. Финансовый директор выступает за тщательный контроль бюджета, связанного с ИИ». Давление на CIO не ограничивается контролем расходов. Генеральные директора и члены совета директоров также ожидают, что их ИТ-руководители будут управлять рисками, связанными с ИИ, и при этом не отставать от конкурентов. «Мы сталкиваемся с огромным сопротивлением в вопросах затрат, огромным сопротивлением в вопросах рисков и огромным давлением, требующим действовать быстрее и делать больше, чтобы не отставать, — отмечает Блоуэрс. — Роль CIO заключается в том, чтобы увязать все эти опасения в рамках нашей ИИ-стратегии и помочь найти баланс в этом вопросе»]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Опрошенные порталом &lltt;/em&ggtt;&lltt;em&ggtt;InformationWeek&lltt;/em&ggtt; &lltt;em&ggtt;эксперты рассказывают о том, как &lltt;/em&ggtt;&lltt;em&ggtt;CIO&lltt;/em&ggtt; &lltt;em&ggtt;могут помочь своим компаниям справиться с растущими и непредсказуемыми расходами на искусственный интеллект и сформировать бюджет, который будет приносить прибыль.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Предприятиям не обойтись без расходов на ИИ. Но просто вкладывать деньги в эту технологию недостаточно для того, чтобы раскрыть ее потенциал в качестве инструмента повышения эффективности и роста доходов. Выделение бюджета на ИИ, который приносит реальную выгоду, является непростой задачей, поскольку CIO приходится учитывать расходы, которые не всегда очевидны.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;a href="https://assets.kpmg.com/content/dam/kpmgsites/xx/pdf/2026/06/global-ai-pulse-q2.pdf"&ggtt;Исследование&lltt;/a&ggtt; KPMG «Q2 2026 Global AI Pulse» показало, что только 35% организаций имеют полное представление о своих операционных расходах, связанных с ИИ. Эти организации в пять раз чаще сообщают о подтверждённой окупаемости инвестиций, чем те, у кого такой информации нет.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему расходы на ИИ сложно спрогнозировать&lltt;/h3&ggtt;
&lltt;p&ggtt;У предприятий нет чёткой схемы бюджетирования ИИ. Руководители компаний выясняют всё на ходу, а это значит, что неожиданностей и ошибок не избежать.&lltt;/p&ggtt;
&lltt;p&ggtt;«Очень легко столкнуться с непредвиденными расходами. И очень, очень сложно обеспечить структурированность и предсказуемость при масштабировании возможностей ИИ в крупной организации», — говорит Пол Блоуэрс, CIO компании Plante Moran, занимающейся аудитом, налогообложением, консалтингом и управлением активами.&lltt;/p&ggtt;
&lltt;p&ggtt;Расходы на ИИ не ограничиваются покупкой платформы или инструмента. Чтобы ИИ приносил пользу, ему нужна правильная основа, а для создания такой основы требуются инвестиции.&lltt;/p&ggtt;
&lltt;p&ggtt;«Вам нужен уровень данных, вам нужен уровень контекста, вам нужен уровень перевода. Кроме того, у вас будут уровень ИИ и уровень активации», — говорит Кристин Парк, директор по трансформации компании Branch, занимающейся мобильной аналитикой и диплинкингом. К этим базовым требованиям добавляются вопросы безопасности и управления, которые крайне важны.&lltt;/p&ggtt;
&lltt;p&ggtt;По словам Парк, в ее компании создание такой основы потребовало затрат на очистку баз данных и знаний. Кроме того, она наняла пару инженеров по автоматизации на основе ИИ, чтобы они помогали с рабочими процессами.&lltt;/p&ggtt;
&lltt;h3&ggtt;Затраты на внедрение ИИ не ограничиваются инструментами&lltt;/h3&ggtt;
&lltt;p&ggtt;При планировании бюджета на ИИ необходимо учитывать затраты на изменение методов работы сотрудников и способов выполнения самой работы.&lltt;/p&ggtt;
&lltt;p&ggtt;«Если вы закладываете в бюджет только стоимость инструмента, то, на мой взгляд, вас ждут проблемы, потому что нужно закладывать средства и на трансформацию, — говорит Парк. — Инструмент — это доступ, а трансформация — это переосмысление вашей работы».&lltt;/p&ggtt;
&lltt;p&ggtt;Переосмысление методов работы команд требует времени и денег. По словам Парк, это «сложный проект», который включает в себя изменения в реализации, конфигурации и рабочих процессах. «ИИ не решает всех проблем. ИИ — это инструмент», — отмечает она.&lltt;/p&ggtt;
&lltt;h3&ggtt;Затраты на использование ИИ сложно предсказать&lltt;/h3&ggtt;
&lltt;p&ggtt;Потребление по-прежнему является сложной частью головоломки бюджетирования ИИ. Цены на токены упали, но их использование резко возросло.&lltt;/p&ggtt;
&lltt;p&ggtt;«Каждый раз, когда выходит новая модель или новый сценарий использования внедряется в производственный процесс, потребление этих токенов растет все быстрее и быстрее, — говорит Блоуэрс. — Мы, CIO, сейчас становимся специалистами в области моделирования и ведения переговоров по токенам, но ситуация в этой сфере пока далека от стабильности».&lltt;/p&ggtt;
&lltt;p&ggtt;Он ожидает, что модели ценообразования на токены будут продолжать развиваться, а поставщики будут предлагать разные подходы.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ увеличивает расходы&lltt;/h3&ggtt;
&lltt;p&ggtt;Предприятиям приходится не только самостоятельно решать вопрос с расходами на ИИ, но и учитывать, как инвестиции поставщиков в ИИ влияют на их затраты. Провайдеры SaaS-решений ищут способы встроить ИИ в свои продукты и монетизировать его, что приводит к росту цен.&lltt;/p&ggtt;
&lltt;p&ggtt;«Большинство ведущих поставщиков SaaS существенно повышают цены, чтобы реализовать свои планы по внедрению ИИ, — говорит Блоуэрс. — И можно с уверенностью сказать, что многие, если не большинство CIO, согласятся с тем, что эти цены растут еще до того, как будут внедрены зрелые функции ИИ, или до того, как мы сможем спрогнозировать, как будет выглядеть потребление внутри этих SaaS-инструментов и платформ».&lltt;/p&ggtt;
&lltt;h3&ggtt;Как бюджетируют ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Учитывая, что затраты на ИИ так трудно предсказать, CIO начинают переосмысливать бюджетирование этой технологии. Для Парк это означает, что расходы на ИИ рассматриваются не как постоянная статья расходов, а как переменные затраты. «Это модель, основанная на потреблении. Это не фиксированная стоимость, как у SaaS», — поясняет она.&lltt;/p&ggtt;
&lltt;p&ggtt;Для компаний, которые не приложили достаточных усилий для создания прочной основы для инструментов и рабочих процессов ИИ, обсуждение бюджета может начаться с оценки затрат на создание всего с нуля. Эта основа очень важна. Опрос PwC «2026 Global CEO survey», в котором приняли участие 4454 топ-руководителя, показал, что организации с прочными основами, которые описываются как «ответственные платформы и технологические среды ИИ, обеспечивающие интеграцию в масштабах всего предприятия», имеют в три раза больше шансов получить «значимую финансовую отдачу».&lltt;/p&ggtt;
&lltt;p&ggtt;При планировании затрат на трансформацию предприятиям необходимо четко представлять, что означает интеграция ИИ для бизнеса. Парк утверждает, что чрезмерное внимание к показателям эффективности является ошибкой. «Мы действительно рассматриваем это как ключевой аспект исследований и разработок, потому что я не думаю, что ИИ должен быть инструментом повышения эффективности, — говорит она. — Я не считаю, что ИИ следует рассматривать как способ сокращения затрат на персонал. Я думаю, это неправильная формула».&lltt;/p&ggtt;
&lltt;p&ggtt;Независимо от того, какой путь выберут компании — повышения эффективности или внедрения инноваций, — им необходимо заложить в бюджет расходы на внедрение и использование ИИ. Дело не ограничивается покупкой ИИ-инструмента или платформы и требованием к сотрудникам их использовать. «Предоставить людям доступ — это еще не значит внедрить технологию», — говорит Парк.&lltt;/p&ggtt;
&lltt;p&ggtt;Конечно, по мере внедрения ИИ его использование — и затраты — могут расти. И бюджеты на ИИ должны учитывать этот рост.&lltt;/p&ggtt;
&lltt;p&ggtt;Блоуэрс вместе с другими руководителями работает над формированием бюджета своей компании на повседневное использование ИИ, в том числе инструментов для повышения производительности. «Мы планируем развивать этот подход по аналогии с FinOps: стимулировать внедрение, предоставлять сотрудникам возможность контролировать расходы, вводить ежемесячные лимиты с некоторыми поведенческими стимулами, — отмечает он. — Обучение само по себе является ключевым инструментом контроля затрат, а не просто способом ограничить потребление токенов».&lltt;/p&ggtt;
&lltt;p&ggtt;Они также занимаются определением сценариев использования ИИ для масштабирования. «Масштабирование немного проще контролировать с точки зрения затрат, планировать и прогнозировать, потому что мы централизуем процессы и они проходят через наши обычные бизнес-процессы и этапы жизненного цикла разработки ПО», — говорит Блоуэрс.&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ, встроенный в SaaS-продукты, — это третья статья расходов, которой занимаются Блоуэрс и его коллеги. Это значит, что нужно обсуждать с поставщиками, как ИИ встраивается в уже имеющиеся у компании инструменты и как это влияет на цены при продлении контрактов.&lltt;/p&ggtt;
&lltt;p&ggtt;«Чтобы справиться с этой проблемой, мы настаиваем на том, чтобы наши партнеры-поставщики соглашались на наши условия, разрабатывали проактивные дорожные карты и оценивали влияние на наши прибыль и убытки, прежде чем соглашаться на предлагаемое ими ценообразование токенов», — говорит Блоуэрс.&lltt;/p&ggtt;
&lltt;p&ggtt;В компании Парк консолидация инструментов стала частью подхода к бюджетированию. «Вам нужно начать консолидировать инструменты, чтобы получить экономию», — говорит она.&lltt;/p&ggtt;
&lltt;h3&ggtt;Роль CIO в бюджетировании ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;CIO играет ключевую роль во внедрении и бюджетировании ИИ, но для этого ему необходимо взаимодействовать с другими руководителями высшего звена и членами совета директоров, чтобы определить, какую ценность они ожидают получить от ИИ и сколько готовы на это потратить.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому особенно важным партнером является финансовый директор. «Нужно тесно сотрудничать с финансовыми директорами, — говорит Блоуэрс. — Честно говоря, здоровая критика в этом вопросе полезна. Финансовый директор выступает за тщательный контроль бюджета, связанного с ИИ».&lltt;/p&ggtt;
&lltt;p&ggtt;Давление на CIO не ограничивается контролем расходов. Генеральные директора и члены совета директоров также ожидают, что их ИТ-руководители будут управлять рисками, связанными с ИИ, и при этом не отставать от конкурентов.&lltt;/p&ggtt;
&lltt;p&ggtt;«Мы сталкиваемся с огромным сопротивлением в вопросах затрат, огромным сопротивлением в вопросах рисков и огромным давлением, требующим действовать быстрее и делать больше, чтобы не отставать, — отмечает Блоуэрс. — Роль CIO заключается в том, чтобы увязать все эти опасения в рамках нашей ИИ-стратегии и помочь найти баланс в этом вопросе».&lltt;/p&ggtt;]]></source>
<adate>31.08.2026</adate>
<dbid>235429</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Невидимая инфраструктура: почему DNS в России стал вопросом устойчивости бизнеса]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235408]]></link>
<description><![CDATA[DNS (Domain Name System, система доменных имен) редко попадает в поле зрения пользователей и даже менеджмента компаний: пока сайт открывается, о ней почти не вспоминают. Но чем сильнее бизнес зависит от онлайн-каналов, тем важнее становится этот невидимый слой интернета. От DNS зависит, откроется ли сайт, сработает ли приложение, пройдет ли запрос к API и продолжит ли компания общаться с клиентами через цифровые сервисы. Рассмотрим, почему DNS в России становится вопросом устойчивости бизнеса. Раньше DNS воспринималась скорее как техническая настройка: пока сайт открывался, бизнес редко задумывался, как именно работает маршрутизация трафика. Однако за последние несколько лет ситуация изменилась. Для компаний DNS постепенно становится вопросом не только производительности, но и устойчивости, управляемости и контроля над критическими сервисами. Причин здесь несколько. Бизнес всё сильнее зависит от цифровых каналов: сайт, приложение, API (Application Programming Interface, интерфейс для обмена данными и командами между разными программами и цифровыми системами), почта, личный кабинет — всё это начинается с DNS. Одновременно растут требования к доступности сервисов и предсказуемости инфраструктуры. В этих условиях рынок постепенно переходит от классической модели DNS к более распределенным архитектурам, в первую очередь — к Anycast. Что такое DNS и почему это важно для бизнеса DNS — базовый механизм маршрутизации интернет-трафика, который связывает доменное имя с сервером, где расположен сервис. Когда пользователь вводит адрес сайта, открывает мобильное приложение или обращается к API, именно DNS определяет, куда должен быть направлен запрос и насколько быстро он дойдет до нужного ресурса. Этот процесс остается незаметным для пользователя, но напрямую влияет на доступность цифрового сервиса. От DNS зависят: 	 скорость первого отклика сайта или приложения; 	 стабильность пользовательского доступа; 	 корректная работа почты и цифровых сервисов; 	 возможность быстро управлять инфраструктурой; 	 устойчивость сервисов при нагрузках и сбоях. Через DNS компании настраивают почтовую инфраструктуру, подтверждают права на домены для внешних сервисов, подключают аналитические и облачные платформы, управляют маршрутизацией трафика. Поэтому DNS постепенно становится связующим слоем между доменом, инфраструктурой и пользователем. Если DNS работает медленно или нестабильно, пользователь может не попасть к сервису даже в том случае, если сама инфраструктура продолжает работать корректно. В цифровой экономике отказ DNS — это уже прямой операционный риск. Почему DNS переходит к распределенной модели Традиционно DNS строилась по модели Unicast: один IP-адрес соответствует одному конкретному серверу. Пользовательский запрос всегда направляется в заранее определенную точку. Если сервер находится далеко или испытывает высокую нагрузку, растет задержка ответа, а при сбое страдает доступность сервиса. Модель Anycast работает иначе. Один и тот же IP-адрес одновременно используется на нескольких географически распределенных узлах, а запрос автоматически направляется к ближайшей или наиболее доступной точке. За счет этого сервис не зависит от одного узла: если одна точка перегружена или недоступна, запросы могут обслуживаться через другие узлы сети. Для бизнеса это дает сразу несколько эффектов: 	 снижение задержки и более быстрый отклик сервисов; 	 распределение нагрузки между несколькими узлами; 	 более высокую устойчивость к сбоям; 	 возможность масштабировать инфраструктуру без остановки сервисов. Именно поэтому Anycast давно используется крупными глобальными DNS-провайдерами и сетями серверов для быстрой доставки контента пользователям (CDN-платформами) как базовая архитектура для сервисов с высокими требованиями к доступности. По сути, DNS проходит ту же трансформацию, которую раньше прошли облачные платформы и сети доставки контента: из вспомогательной настройки она превращается в отдельный инфраструктурный слой со своими требованиями к производительности и отказоустойчивости. При этом Anycast не отменяет необходимости правильно управлять DNS-зонами: контролировать записи, доступы, сроки действия доменов, изменения конфигурации и резервные сценарии. Технология повышает устойчивость, но не заменяет операционную дисциплину. Почему тема DNS стала особенно актуальной сейчас Переход к Anycast — это естественный этап развития DNS-инфраструктуры, который уже стал стандартной практикой для высоконагруженных сервисов. В России этот подход сегодня получает более широкое распространение — во многом под влиянием изменений в технологической и регуляторной среде последних лет. После 2022 года компании начали учитывать не только технические характеристики сервисов, но и устойчивость инфраструктуры к внешним ограничениям: доступность поддержки, стабильность расчетов, зависимость от зарубежной юрисдикции. Даже в случаях, когда зарубежные сервисы продолжают работать, бизнес всё чаще оценивает риски, связанные с критической зависимостью от внешних платформ. Для DNS этот вопрос особенно чувствителен, если доменная инфраструктура становится недоступной или плохо управляемой, последствия могут затронуть не один сервис, а весь цифровой контур компании. Параллельно усилился тренд на «заземление» инфраструктуры — размещение и обслуживание ключевых элементов цифрового контура в России. Этому способствует как регулирование, так и сама логика управления рисками. Речь не только о физическом размещении отдельных сервисов, но и о более понятной юрисдикции, доступной поддержке, прозрачных правилах обслуживания и возможности быстрее реагировать на инциденты. Закон о персональных данных требует хранить и обрабатывать данные граждан РФ с использованием баз данных на территории страны, а регулирование в сфере критической информационной инфраструктуры и устойчивости Рунета задает общий вектор на контролируемость и отказоустойчивость цифровых сервисов. DNS напрямую не является базой персональных данных, но она находится в том же контуре операционной устойчивости: без нее не работают сайт, почта, личный кабинет, API и другие сервисы, через которые бизнес взаимодействует с клиентами. В последние годы этот подход начал усиливаться и на практике: регуляторы рекомендуют использовать российские хостинг- и CDN-площадки в случаях, когда от инфраструктуры зависит стабильность сервисов. Для бизнеса это означает, что вопрос «где расположена DNS» постепенно становится таким же важным, как вопрос «где находятся данные», и компании начинают смотреть на него шире — кто управляет DNS, где находятся ключевые точки инфраструктуры, как быстро можно получить поддержку и какие резервные сценарии предусмотрены на случай сбоя. Как меняется рынок DNS в России Исторически компании часто выбирали DNS по остаточному принципу: либо использовали базовые сервисы регистратора, либо подключали зарубежные решения, если требовались высокая производительность и гибкость управления. Сегодня требования изменились. Бизнесу важны: 	 скорость отклика; 	 отказоустойчивость; 	 прозрачное управление инфраструктурой; 	 масштабируемость; 	 понятная юрисдикция и доступная поддержка. На этом фоне в России начали активнее развиваться распределенные DNS-модели. В первую очередь они становятся востребованы у компаний, для которых онлайн-каналы напрямую связаны с выручкой, клиентским опытом и непрерывностью процессов: e-commerce, медиа, финансовых сервисов, SaaS-платформ, образовательных проектов и крупных корпоративных сайтов. Anycast DNS как часть новой операционной устойчивости Для бизнеса внедрение Anycast выходит за рамки технического обновления DNS и представляет собой стратегический пересмотр архитектуры сетевой инфраструктуры: компании начинают воспринимать цифровые сервисы как непрерывный операционный контур, где отказ даже одного элемента может влиять на выручку, клиентский опыт и стабильность процессов. В этой логике DNS перестает быть «фоновой настройкой», о которой вспоминают только при регистрации домена. Сегодня от нее зависит, насколько быстро пользователь получит доступ к сервису, как инфраструктура переживает пиковые нагрузки и насколько устойчиво работает цифровой контур в случае сбоев или внешних ограничений. Именно поэтому распределенные модели вроде Anycast постепенно становятся новой инфраструктурной нормой для цифровых сервисов. #IMAGE_235409#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;DNS &lltt;/em&ggtt;&lltt;em&ggtt;(Domain Name System&lltt;/em&ggtt;&lltt;em&ggtt;,&lltt;/em&ggtt;&lltt;em&ggtt; система доменных имен)&lltt;/em&ggtt; &lltt;em&ggtt;редко попадает в&nbsp;поле зрения пользователей и&nbsp;даже менеджмента компаний: пока сайт открывается, о&nbsp;не&lltt;/em&ggtt;&lltt;em&ggtt;й&lltt;/em&ggtt;&lltt;em&ggtt; почти не&nbsp;вспоминают. Но&nbsp;чем сильнее бизнес зависит от&nbsp;онлайн-каналов, тем важнее становится этот невидимый слой интернета. От&nbsp;DNS зависит, откроется&nbsp;ли сайт, сработает&nbsp;ли приложение, пройдет&nbsp;ли запрос к&nbsp;API и&nbsp;продолжит&nbsp;ли компания общаться с&nbsp;клиентами через цифровые сервисы. &lltt;/em&ggtt;&lltt;em&ggtt;Рассмотрим&lltt;/em&ggtt;&lltt;em&ggtt;, почему DNS в&nbsp;России становится вопросом устойчивости бизнеса.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Раньше DNS воспринималась скорее как техническая настройка: пока сайт открывался, бизнес редко задумывался, как именно работает маршрутизация трафика. Однако за&nbsp;последние несколько лет ситуация изменилась. Для компаний DNS постепенно становится вопросом не&nbsp;только производительности, но&nbsp;и&nbsp;устойчивости, управляемости и&nbsp;контроля над критическими сервисами.&lltt;/p&ggtt;
&lltt;p&ggtt;Причин здесь несколько. Бизнес всё сильнее зависит от&nbsp;цифровых каналов: сайт, приложение, API (Application Programming Interface, интерфейс для обмена данными и&nbsp;командами между разными программами и&nbsp;цифровыми системами), почта, личный кабинет&nbsp;— всё это начинается с&nbsp;DNS. Одновременно растут требования к&nbsp;доступности сервисов и&nbsp;предсказуемости инфраструктуры. В&nbsp;этих условиях рынок постепенно переходит от&nbsp;классической модели DNS к&nbsp;более распределенным архитектурам, в&nbsp;первую очередь&nbsp;— к&nbsp;Anycast.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что такое DNS и&nbsp;почему это важно для бизнеса&lltt;/h3&ggtt;
&lltt;p&ggtt;DNS&nbsp;— базовый механизм маршрутизации интернет-трафика, который связывает доменное имя с&nbsp;сервером, где расположен сервис.&lltt;/p&ggtt;
&lltt;p&ggtt;Когда пользователь вводит адрес сайта, открывает мобильное приложение или обращается к&nbsp;API, именно DNS определяет, куда должен быть направлен запрос и&nbsp;насколько быстро он&nbsp;дойдет до&nbsp;нужного ресурса. Этот процесс остается незаметным для пользователя, но&nbsp;напрямую влияет на&nbsp;доступность цифрового сервиса.&lltt;/p&ggtt;
&lltt;p&ggtt;От&nbsp;DNS зависят:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; скорость первого отклика сайта или приложения;&lltt;/li&ggtt;
	&lltt;li&ggtt; стабильность пользовательского доступа;&lltt;/li&ggtt;
	&lltt;li&ggtt; корректная работа почты и&nbsp;цифровых сервисов;&lltt;/li&ggtt;
	&lltt;li&ggtt; возможность быстро управлять инфраструктурой;&lltt;/li&ggtt;
	&lltt;li&ggtt; устойчивость сервисов при нагрузках и&nbsp;сбоях.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Через DNS компании настраивают почтовую инфраструктуру, подтверждают права на&nbsp;домены для внешних сервисов, подключают аналитические и&nbsp;облачные платформы, управляют маршрутизацией трафика. Поэтому DNS постепенно становится связующим слоем между доменом, инфраструктурой и&nbsp;пользователем.&lltt;/p&ggtt;
&lltt;p&ggtt;Если DNS работает медленно или нестабильно, пользователь может не&nbsp;попасть к&nbsp;сервису даже в&nbsp;том случае, если сама инфраструктура продолжает работать корректно. В&nbsp;цифровой экономике отказ DNS&nbsp;— это уже прямой операционный риск.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему DNS переходит к&nbsp;распределенной модели&lltt;/h3&ggtt;
&lltt;p&ggtt;Традиционно DNS строилась по&nbsp;модели Unicast: один IP-адрес соответствует одному конкретному серверу. Пользовательский запрос всегда направляется в&nbsp;заранее определенную точку. Если сервер находится далеко или испытывает высокую нагрузку, растет задержка ответа, а&nbsp;при сбое страдает доступность сервиса.&lltt;/p&ggtt;
&lltt;p&ggtt;Модель Anycast работает иначе. Один и&nbsp;тот&nbsp;же IP-адрес одновременно используется на&nbsp;нескольких географически распределенных узлах, а&nbsp;запрос автоматически направляется к&nbsp;ближайшей или наиболее доступной точке. За&nbsp;счет этого сервис не&nbsp;зависит от&nbsp;одного узла: если одна точка перегружена или недоступна, запросы могут обслуживаться через другие узлы сети.&lltt;/p&ggtt;
&lltt;p&ggtt;Для бизнеса это дает сразу несколько эффектов:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; снижение задержки и&nbsp;более быстрый отклик сервисов;&lltt;/li&ggtt;
	&lltt;li&ggtt; распределение нагрузки между несколькими узлами;&lltt;/li&ggtt;
	&lltt;li&ggtt; более высокую устойчивость к&nbsp;сбоям;&lltt;/li&ggtt;
	&lltt;li&ggtt; возможность масштабировать инфраструктуру без остановки сервисов.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Именно поэтому Anycast давно используется крупными глобальными DNS-провайдерами и&nbsp;сетями серверов для быстрой доставки контента пользователям (CDN-платформами) как базовая архитектура для сервисов с&nbsp;высокими требованиями к&nbsp;доступности.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;сути, DNS проходит ту&nbsp;же трансформацию, которую раньше прошли облачные платформы и&nbsp;сети доставки контента: из&nbsp;вспомогательной настройки она превращается в&nbsp;отдельный инфраструктурный слой со&nbsp;своими требованиями к&nbsp;производительности и&nbsp;отказоустойчивости. При этом Anycast не&nbsp;отменяет необходимости правильно управлять DNS-зонами: контролировать записи, доступы, сроки действия доменов, изменения конфигурации и&nbsp;резервные сценарии. Технология повышает устойчивость, но&nbsp;не&nbsp;заменяет операционную дисциплину.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему тема DNS стала особенно актуальной сейчас&lltt;/h3&ggtt;
&lltt;p&ggtt;Переход к&nbsp;Anycast&nbsp;— это естественный этап развития DNS-инфраструктуры, который уже стал стандартной практикой для высоконагруженных сервисов. В&nbsp;России этот подход сегодня получает более широкое распространение&nbsp;— во&nbsp;многом под влиянием изменений в&nbsp;технологической и&nbsp;регуляторной среде последних лет.&lltt;/p&ggtt;
&lltt;p&ggtt;После 2022 года компании начали учитывать не&nbsp;только технические характеристики сервисов, но&nbsp;и&nbsp;устойчивость инфраструктуры к&nbsp;внешним ограничениям: доступность поддержки, стабильность расчетов, зависимость от&nbsp;зарубежной юрисдикции. Даже в&nbsp;случаях, когда зарубежные сервисы продолжают работать, бизнес всё чаще оценивает риски, связанные с&nbsp;критической зависимостью от&nbsp;внешних платформ. Для DNS этот вопрос особенно чувствителен, если доменная инфраструктура становится недоступной или плохо управляемой, последствия могут затронуть не&nbsp;один сервис, а&nbsp;весь цифровой контур компании.&lltt;/p&ggtt;
&lltt;p&ggtt;Параллельно усилился тренд на&nbsp;«заземление» инфраструктуры&nbsp;— размещение и&nbsp;обслуживание ключевых элементов цифрового контура в&nbsp;России. Этому способствует как регулирование, так и&nbsp;сама логика управления рисками. Речь не&nbsp;только о&nbsp;физическом размещении отдельных сервисов, но&nbsp;и&nbsp;о&nbsp;более понятной юрисдикции, доступной поддержке, прозрачных правилах обслуживания и&nbsp;возможности быстрее реагировать на&nbsp;инциденты.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;a href="https://www.consultant.ru/document/cons_doc_LAW_61801/?utm_source=chatgpt.com"&ggtt;Закон о&nbsp;персональных данных&lltt;/a&ggtt; требует хранить и&nbsp;обрабатывать данные граждан&nbsp;РФ с&nbsp;использованием баз данных на&nbsp;территории страны, а&nbsp;регулирование в&nbsp;сфере &lltt;a href="https://www.consultant.ru/document/cons_doc_LAW_220885/?utm_source=chatgpt.com"&ggtt;критической информационной инфраструктуры&lltt;/a&ggtt; и&nbsp;&lltt;a href="https://www.consultant.ru/document/cons_doc_LAW_323815/?utm_source=chatgpt.com"&ggtt;устойчивости&lltt;/a&ggtt; Рунета задает общий вектор на&nbsp;контролируемость и&nbsp;отказоустойчивость цифровых сервисов. DNS напрямую не&nbsp;является базой персональных данных, но&nbsp;она находится в&nbsp;том&nbsp;же контуре операционной устойчивости: без нее не&nbsp;работают сайт, почта, личный кабинет, API и&nbsp;другие сервисы, через которые бизнес взаимодействует с&nbsp;клиентами.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;последние годы этот подход начал усиливаться и&nbsp;на&nbsp;практике: регуляторы &lltt;a href="https://www.interfax.ru/digital/1017951"&ggtt;рекомендуют&lltt;/a&ggtt; использовать российские хостинг- и&nbsp;CDN-площадки в&nbsp;случаях, когда от&nbsp;инфраструктуры зависит стабильность сервисов.&lltt;/p&ggtt;
&lltt;p&ggtt;Для бизнеса это означает, что вопрос «где расположена DNS» постепенно становится таким&nbsp;же важным, как вопрос «где находятся данные», и&nbsp;компании начинают смотреть на&nbsp;него шире&nbsp;— кто управляет DNS, где находятся ключевые точки инфраструктуры, как быстро можно получить поддержку и&nbsp;какие резервные сценарии предусмотрены на&nbsp;случай сбоя.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как меняется рынок DNS в&nbsp;России&lltt;/h3&ggtt;
&lltt;p&ggtt;Исторически компании часто выбирали DNS по&nbsp;остаточному принципу: либо использовали базовые сервисы регистратора, либо подключали зарубежные решения, если требовались высокая производительность и&nbsp;гибкость управления.&lltt;/p&ggtt;
&lltt;p&ggtt;Сегодня требования изменились. Бизнесу важны:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; скорость отклика;&lltt;/li&ggtt;
	&lltt;li&ggtt; отказоустойчивость;&lltt;/li&ggtt;
	&lltt;li&ggtt; прозрачное управление инфраструктурой;&lltt;/li&ggtt;
	&lltt;li&ggtt; масштабируемость;&lltt;/li&ggtt;
	&lltt;li&ggtt; понятная юрисдикция и&nbsp;доступная поддержка.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;На&nbsp;этом фоне в&nbsp;России начали активнее развиваться распределенные DNS-модели. В&nbsp;первую очередь они становятся востребованы у&nbsp;компаний, для которых онлайн-каналы напрямую связаны с&nbsp;выручкой, клиентским опытом и&nbsp;непрерывностью процессов: e-commerce, медиа, финансовых сервисов, SaaS-платформ, образовательных проектов и&nbsp;крупных корпоративных сайтов.&lltt;/p&ggtt;
&lltt;h3&ggtt;Anycast DNS как часть новой операционной устойчивости&lltt;/h3&ggtt;
&lltt;p&ggtt;Для бизнеса внедрение Anycast выходит за&nbsp;рамки технического обновления DNS и&nbsp;представляет собой стратегический пересмотр архитектуры сетевой инфраструктуры: компании начинают воспринимать цифровые сервисы как непрерывный операционный контур, где отказ даже одного элемента может влиять на&nbsp;выручку, клиентский опыт и&nbsp;стабильность процессов.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;этой логике DNS перестает быть «фоновой настройкой», о&nbsp;которой вспоминают только при регистрации домена. Сегодня от&nbsp;нее зависит, насколько быстро пользователь получит доступ к&nbsp;сервису, как инфраструктура переживает пиковые нагрузки и&nbsp;насколько устойчиво работает цифровой контур в&nbsp;случае сбоев или внешних ограничений. Именно поэтому распределенные модели вроде Anycast постепенно становятся новой инфраструктурной нормой для цифровых сервисов.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235409#&lltt;/p&ggtt;]]></source>
<adate>28.08.2026</adate>
<dbid>235408</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/711/1vg3km3zq36hkxidrfv8ak7equy9p6i6.jpg]]>
</images>
<imagesname><![CDATA[;;Георгий Казаров, руководитель отдела доменов Руцентра   ]]></imagesname>
<tag><![CDATA[Сети/Серверы/СХД/ЦОД]]></tag>
</item>
<item>
<title><![CDATA[Спрос на DevSecOps вырос более чем на 20% на фоне роста собственной разработки в российских компаниях]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235423]]></link>
<description><![CDATA[Спрос на услуги и решения класса DevSecOps в российских компаниях вырос примерно на 20-22% с начала 2026 года по сравнению с аналогичным периодом 2025 года. Эксперты «Кросстеха» связывают эту динамику с развитием процессов внутренней разработки в российских компаниях, где безопасность становится неотъемлемой частью процесса создания продукта. Специалисты отмечают, что в начале 2020-х собственная разработка была в основном распространена в финансовом секторе и телекоме — компании из этих отраслей традиционно используют широкий стек ПО как для внутренних процессов, так и для взаимодействия с клиентами. В середине 2026 года внутренние команды разработки становятся обыденностью. Так, по данным «Кросстеха», лидерами по запросам на проекты, связанные с DevSecOps, в первой половине 2026 года стали промышленность и ритейл. Среди основных причин популяризации собственной разработки среди российских компаний — желание бизнеса контролировать технологии, которые используются в его инфраструктуре, и отсутствие решений, которые удовлетворяют потребности бизнеса. Еще одна причина — снижение стоимости разработки за счет развития искусственного интеллекта, которые забирает на себя значительную часть процесса создания IT-решений. Расширение числа проектов, связанных с разработкой собственных решений, ведет к необходимости внедрять безопасную разработку, благодаря чему с начала 2026 года растет спрос на DevSecOps. Наиболее востребованным остается внедрение инструментов тестирования кода (SAST, DAST, SCA), пентест приложений и API, а также консалтинг по DevSecOps и построение процесса безопасной разработки внутри компании. «Компании, которые еще недавно интегрировали готовые продукты, сегодня оказались в роли разработчиков — и далеко не всегда с соответствующей культурой безопасной разработки. Уязвимость может попасть в продукт не через код, который написала команда, а через внешнюю библиотеку или контейнерный образ, о котором никто не задумывался. Именно поэтому спрос смещается не просто на инструменты, а на выстраивание процесса — от анализа зависимостей до безопасности на каждом этапе CI/CD», — прокомментировал Антон Редько, руководитель группы «Безопасная разработка» «Кросстеха»]]></description>
<source><![CDATA[&lltt;p&ggtt;Спрос на услуги и решения класса DevSecOps в российских компаниях вырос примерно на &lltt;nobr&ggtt;20-22%&lltt;/nobr&ggtt; с начала 2026 года по сравнению с аналогичным периодом 2025 года. Эксперты «Кросстеха» связывают эту динамику с развитием процессов внутренней разработки в российских компаниях, где безопасность становится неотъемлемой частью процесса создания продукта.&lltt;/p&ggtt;
&lltt;p&ggtt;Специалисты отмечают, что в начале &lltt;nobr&ggtt;2020-х&lltt;/nobr&ggtt; собственная разработка была в основном распространена в финансовом секторе и телекоме — компании из этих отраслей традиционно используют широкий стек ПО как для внутренних процессов, так и для взаимодействия с клиентами. В середине 2026 года внутренние команды разработки становятся обыденностью. Так, по данным «Кросстеха», лидерами по запросам на проекты, связанные с DevSecOps, в первой половине 2026 года стали промышленность и ритейл.&lltt;/p&ggtt;
&lltt;p&ggtt;Среди основных причин популяризации собственной разработки среди российских компаний — желание бизнеса контролировать технологии, которые используются в его инфраструктуре, и отсутствие решений, которые удовлетворяют потребности бизнеса. Еще одна причина — снижение стоимости разработки за счет развития искусственного интеллекта, которые забирает на себя значительную часть процесса создания IT-решений.&lltt;/p&ggtt;
&lltt;p&ggtt;Расширение числа проектов, связанных с разработкой собственных решений, ведет к необходимости внедрять безопасную разработку, благодаря чему с начала 2026 года растет спрос на DevSecOps. Наиболее востребованным остается внедрение инструментов тестирования кода (SAST, DAST, SCA), пентест приложений и API, а также консалтинг по DevSecOps и построение процесса безопасной разработки внутри компании.&lltt;/p&ggtt;
&lltt;p&ggtt;«Компании, которые еще недавно интегрировали готовые продукты, сегодня оказались в роли разработчиков — и далеко не всегда с соответствующей культурой безопасной разработки. Уязвимость может попасть в продукт не через код, который написала команда, а через внешнюю библиотеку или контейнерный образ, о котором никто не задумывался. Именно поэтому спрос смещается не просто на инструменты, а на выстраивание процесса — от анализа зависимостей до безопасности на каждом этапе CI/CD», — прокомментировал Антон Редько, руководитель группы «Безопасная разработка» «Кросстеха».&lltt;/p&ggtt;]]></source>
<adate>27.08.2026</adate>
<dbid>235423</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[M1Cloud: как законы об ИИ определяют архитектуру облачной инфраструктуры в 2026 году]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235424]]></link>
<description><![CDATA[В 2026 году два крупнейших регулятора — Евросоюз с AI Act (Regulation (EU) 2024/1689) и Россия с 243-ФЗ — впервые массово перенесли ответственность за ИИ-системы с разработчика модели на всю цепочку, включая провайдера вычислительной среды. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что теперь географическое расположение GPU, юрисдикция дата-центра и архитектура логирования превращаются в переменные, которые определяют легальность ИИ-модели. AI Act — это первый в мире комплексный подход к регулированию ИИ на уровне целого союза. Он вводит регулирование поэтапно. С февраля 2025 года начали действовать запреты на системы с неприемлемым риском, в том числе запрещены отдельные практики (социальный скоринг, биометрическая идентификация в реальном времени в чувствительных контекстах), и нормы ИИ-грамотности. С августа 2025-го вступили в силу обязательства для поставщиков моделей общего назначения (general-purpose AI или GPAI). С августа 2026-го начал применяться основной массив обязанностей к системам высокого риска. С августа 2027-го начнут действовать дополнительные требования к высокорисковым системам. Именно эта последняя волна бьет по инфраструктуре сильнее всего. На уровне ЕС созданы Управление по ИИ (AI Office) при Еврокомиссии и Европейский совет по ИИ — они координируют правоприменение. AI Office с августа 2025-го имеют инспекционные полномочия и может запрашивать техническую документацию, включая сведения о среде, в которой обучалась и работает модель. Для инфраструктурного провайдера это означает конкретный набор обязательств. Провайдер GPAI-модели обязан вести и актуализировать техническую документацию, описывающую модель, процессы ее обучения и тестирования, результаты оценки; раскрывать пользователям информацию о возможностях и ограничениях модели; соблюдать политику авторских прав; публиковать детальную сводку по обучающим данным по шаблону AI Office. Для моделей, создающих системный риск, добавляются расширенные обязанности — подробные стратегии оценки и внутреннего тестирования. Без технической реализации этих требований в облаке заказчик просто не пройдет аудит — даже если его собственная модель полностью корректна. 26 июля 2026 года подписан 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации», основная часть вступает в силу с 1 сентября 2026 года. Закон регулирует узкий, но емкий сегмент — большие фундаментальные модели с числом параметров от 1 миллиарда. Для них устанавливаются пять базовых требований. Разработчиком модели должно быть российское юридическое лицо, и оно же должно отвечать за изменение характеристик модели. Компания-разработчик обязана обеспечить полную техническую и технологическую воспроизводимость всего цикла разработки, включая обучение. Подготовка ответов на запросы пользователей и хранение данных должны производиться в ЦОДах на территории России, принадлежащих российским юрлицам. Используемые зарубежные компоненты должны распространяться на условиях открытой лицензии. С 1 марта 2027 года добавляется требование о подтверждении соответствия модели российскому законодательству и традиционным духовно-нравственным ценностям. Важная деталь: закон не запрещает трансграничное использование ИИ-компонентов и не обязывает обучать модель только на российских данных. Это снимает главный страх рынка и одновременно переводит фокус с расположения данных на локализацию оборудования. И вот тут инфраструктура выходит на первый план. Локализация данных и вычислений по 243-ФЗ требует российской юрисдикции ЦОД и российского юрлица-провайдера. Без гео-распределенных площадок и входа в реестр отечественного ПО это правило не выполнить. Контроль доступа к GPU-среде предполагает изоляцию dev-, research- и prod-контуров и минимизацию круга лиц с правами. На уровне собственного сервера это дорого и хрупко; на уровне провайдера — стандартная функция приватных кластеров с ролевой моделью на гипервизоре. Мониторинг инференса требует понимать, что генерирует модель в проде. Реализуется через inline-модули аудита, которые интегрируются с системами защиты вроде СЗИИ и работают на стороне облака, а не на стороне разработчика модели. Отчетность по вычислениям — требование, которое на горизонте 2-3 лет станет обязательным: считать, сколько ресурсов ушло на обучение и инференс. Здесь критичны телеметрия GPU, биллинг с разбивкой по задачам и прозрачные SLA — то, что у зрелого провайдера уже реализовано. Для заказчика реализация таких требований самостоятельно довольно сложная задача: для этого нужна либо собственная инженерная команда по инфраструктуре, либо опытный сервис-провайдер. Раньше комплаенс лежал на заказчике. Сейчас без провайдера, который технически обеспечивает локализацию, логирование и изоляцию, выполнить 243-ФЗ практически невозможно. Соответственно, на первый план будет выходить регуляторно-совместимый контур для ИИ с прецедентами в финсекторе или госсекторе. Подтверждает этот сдвиг и динамика рынка. По прогнозу Gartner, мировые расходы на ИИ-оптимизацию IaaS в 2026 году вырастут на 96% и достигнут 42 млрд долларов. IDC оценивает общие траты на ИИ-инфраструктуру в $497 млрд за 2026 год, причем в первом квартале 2026 рынок уже преодолел отметку $89,7 млрд (+33% год к году). Фокус на инфраструктуру, которая умеет работать с ИИ-нагрузкой: с GPU, с телеметрией, с изолированными контурами. Сервис-провайдер M1Cloud один из первых предложил безопасность ИИ, обеспечение прослеживаемости и соответствия требованиям регуляторов на уровне инфраструктуры, благодаря партнерству с ООО СЗИИ («Системы защиты искусственного интеллекта») и интеграции в облачную инфраструктуру решения для специализированной защиты ИИ-моделей от современных киберугроз]]></description>
<source><![CDATA[&lltt;p&ggtt;В 2026 году два крупнейших регулятора — Евросоюз с AI Act (Regulation (EU) 2024/1689) и Россия с &lltt;nobr&ggtt;243-ФЗ —&lltt;/nobr&ggtt; впервые массово перенесли ответственность за ИИ-системы с разработчика модели на всю цепочку, включая провайдера вычислительной среды. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что теперь географическое расположение GPU, юрисдикция дата-центра и архитектура логирования превращаются в переменные, которые определяют легальность ИИ-модели.&lltt;/p&ggtt;
&lltt;p&ggtt;AI Act — это первый в мире комплексный подход к регулированию ИИ на уровне целого союза. Он вводит регулирование поэтапно. С февраля 2025 года начали действовать запреты на системы с неприемлемым риском, в том числе запрещены отдельные практики (социальный скоринг, биометрическая идентификация в реальном времени в чувствительных контекстах), и нормы ИИ-грамотности. С августа &lltt;nobr&ggtt;2025-го&lltt;/nobr&ggtt; вступили в силу обязательства для поставщиков моделей общего назначения (general-purpose AI или GPAI). С августа &lltt;nobr&ggtt;2026-го&lltt;/nobr&ggtt; начал применяться основной массив обязанностей к системам высокого риска. С августа &lltt;nobr&ggtt;2027-го&lltt;/nobr&ggtt; начнут действовать дополнительные требования к высокорисковым системам. Именно эта последняя волна бьет по инфраструктуре сильнее всего.&lltt;/p&ggtt;
&lltt;p&ggtt;На уровне ЕС созданы Управление по ИИ (AI Office) при Еврокомиссии и Европейский совет по ИИ — они координируют правоприменение. AI Office с августа &lltt;nobr&ggtt;2025-го&lltt;/nobr&ggtt; имеют инспекционные полномочия и может запрашивать техническую документацию, включая сведения о среде, в которой обучалась и работает модель.&lltt;/p&ggtt;
&lltt;p&ggtt;Для инфраструктурного провайдера это означает конкретный набор обязательств. Провайдер GPAI-модели обязан вести и актуализировать техническую документацию, описывающую модель, процессы ее обучения и тестирования, результаты оценки; раскрывать пользователям информацию о возможностях и ограничениях модели; соблюдать политику авторских прав; публиковать детальную сводку по обучающим данным по шаблону AI Office. Для моделей, создающих системный риск, добавляются расширенные обязанности — подробные стратегии оценки и внутреннего тестирования. Без технической реализации этих требований в облаке заказчик просто не пройдет аудит — даже если его собственная модель полностью корректна.&lltt;/p&ggtt;
&lltt;p&ggtt;26 июля 2026 года подписан &lltt;nobr&ggtt;243-ФЗ&lltt;/nobr&ggtt; «О поддержке развития технологий искусственного интеллекта в Российской Федерации», основная часть вступает в силу с 1 сентября 2026 года. Закон регулирует узкий, но емкий сегмент — большие фундаментальные модели с числом параметров от 1 миллиарда. Для них устанавливаются пять базовых требований. Разработчиком модели должно быть российское юридическое лицо, и оно же должно отвечать за изменение характеристик модели. Компания-разработчик обязана обеспечить полную техническую и технологическую воспроизводимость всего цикла разработки, включая обучение. Подготовка ответов на запросы пользователей и хранение данных должны производиться в ЦОДах на территории России, принадлежащих российским юрлицам. Используемые зарубежные компоненты должны распространяться на условиях открытой лицензии. С 1 марта 2027 года добавляется требование о подтверждении соответствия модели российскому законодательству и традиционным духовно-нравственным ценностям.&lltt;/p&ggtt;
&lltt;p&ggtt;Важная деталь: закон не запрещает трансграничное использование ИИ-компонентов и не обязывает обучать модель только на российских данных. Это снимает главный страх рынка и одновременно переводит фокус с расположения данных на локализацию оборудования. И вот тут инфраструктура выходит на первый план.&lltt;/p&ggtt;
&lltt;p&ggtt;Локализация данных и вычислений по &lltt;nobr&ggtt;243-ФЗ&lltt;/nobr&ggtt; требует российской юрисдикции ЦОД и российского юрлица-провайдера. Без гео-распределенных площадок и входа в реестр отечественного ПО это правило не выполнить.&lltt;/p&ggtt;
&lltt;p&ggtt;Контроль доступа к GPU-среде предполагает изоляцию dev-, research- и prod-контуров и минимизацию круга лиц с правами. На уровне собственного сервера это дорого и хрупко; на уровне провайдера — стандартная функция приватных кластеров с ролевой моделью на гипервизоре.&lltt;/p&ggtt;
&lltt;p&ggtt;Мониторинг инференса требует понимать, что генерирует модель в проде. Реализуется через inline-модули аудита, которые интегрируются с системами защиты вроде СЗИИ и работают на стороне облака, а не на стороне разработчика модели.&lltt;/p&ggtt;
&lltt;p&ggtt;Отчетность по вычислениям — требование, которое на горизонте &lltt;nobr&ggtt;2-3&lltt;/nobr&ggtt; лет станет обязательным: считать, сколько ресурсов ушло на обучение и инференс. Здесь критичны телеметрия GPU, биллинг с разбивкой по задачам и прозрачные SLA — то, что у зрелого провайдера уже реализовано.&lltt;/p&ggtt;
&lltt;p&ggtt;Для заказчика реализация таких требований самостоятельно довольно сложная задача: для этого нужна либо собственная инженерная команда по инфраструктуре, либо опытный сервис-провайдер.&lltt;/p&ggtt;
&lltt;p&ggtt;Раньше комплаенс лежал на заказчике. Сейчас без провайдера, который технически обеспечивает локализацию, логирование и изоляцию, выполнить &lltt;nobr&ggtt;243-ФЗ&lltt;/nobr&ggtt; практически невозможно. Соответственно, на первый план будет выходить регуляторно-совместимый контур для ИИ с прецедентами в финсекторе или госсекторе.&lltt;/p&ggtt;
&lltt;p&ggtt;Подтверждает этот сдвиг и динамика рынка. По прогнозу Gartner, мировые расходы на ИИ-оптимизацию IaaS в 2026 году вырастут на 96% и достигнут 42 млрд долларов. IDC оценивает общие траты на ИИ-инфраструктуру в $497 млрд за 2026 год, причем в первом квартале 2026 рынок уже преодолел отметку $89,7 млрд (+33% год к году). Фокус на инфраструктуру, которая умеет работать с ИИ-нагрузкой: с GPU, с телеметрией, с изолированными контурами.&lltt;/p&ggtt;
&lltt;p&ggtt;Сервис-провайдер M1Cloud один из первых предложил безопасность ИИ, обеспечение прослеживаемости и соответствия требованиям регуляторов на уровне инфраструктуры, благодаря партнерству с ООО СЗИИ («Системы защиты искусственного интеллекта») и интеграции в облачную инфраструктуру решения для специализированной защиты ИИ-моделей от современных киберугроз.&lltt;/p&ggtt;]]></source>
<adate>27.08.2026</adate>
<dbid>235424</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[datagarden представит на российском рынке систему хранения данных vitiscale для ресурсоемких и критических задач]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235425]]></link>
<description><![CDATA[В сентябре 2026 года компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представит заказчикам vitiscale — собственную горизонтально масштабируемую СХД, спроектированную для самых требовательных задач. vitiscale обеспечивает десятки миллионов IOPS и сотни тысяч RPS в секунду при минимальном времени отклика и гарантирует производительность, необходимую для эффективной работы AI/ML-решений, аналитики больших массивов данных, высоконагруженных ферм СУБД и быстрого восстановления данных. «vitiscale — это полностью оригинальная разработка, а не производное от существующего решения на основе open-source, — рассказал Филипп Комиссаров, технический директор datagarden. — Мы сознательно пошли на то, чтобы переписать программную архитектуру системы хранения практически с нуля: только так можно было извлечь из оборудования максимум и устранить те узкие места, с которыми мы годами сталкивались в ходе эксплуатации хранилищ такого класса. Для заказчика это выражается во вполне практичных вещах: та же задача решается кратно меньшим числом узлов, требует значительно меньше энергии и места в стойках, а производительность и емкость растут линейно и без остановки сервисов. Мы строили vitiscale, ориентируясь на нагрузки эпохи искусственного интеллекта и аналитики больших данных, где одинаково важны и высочайшая производительность, и минимальный отклик». Программная архитектура vitiscale построена на принципах множественного параллельного ввода-вывода и прямого доступа к данным. Это означает, что каждый узел системы обслуживает запросы напрямую — без промежуточных контроллеров метаданных или избыточных шлюзов. Благодаря этому даже при внушительных нагрузках vitiscale требует значительно меньше оборудования, чем классические СХД и open-source-кластеры. vitiscale предоставляет блочный доступ (NVMe over Fabrics (TCP, RDMA, Fibre Channel), а также iSCSI и FC) и объектное хранилище с S3 API. Кластер масштабируется от 3 до 512 узлов с шагом в один узел и без остановки сервисов. Производительность и емкость растут линейно — до десятков петабайт в одной системе. Система совместима с отечественными ОС, включая Astra Linux SE, AltLinux, РОСА и РЕД ОС. Продукт включен в реестр российского ПО Минцифры (№ 23346), программно-аппаратный комплекс на серийной платформе datagarden — в реестр ПАК (№ 28285). Горизонтально масштабируемую СХД vitiscale команда datagarden разрабатывает с 2022 года. Ключевая цель проекта — максимально эффективно использовать аппаратные ресурсы системы. Над продуктом работает команда инженеров, которые в течение многих лет эксплуатировали хранилища данного класса и знают их узкие места изнутри. Компания datagarden разрабатывает и производит в России централизованные и распределенные системы хранения данных. Архитектура и алгоритмы хранения в основе продуктов datagarden соответствуют современным профилям нагрузок — от виртуализации и СУБД до искусственного интеллекта — и рассчитаны на непрерывную эксплуатацию и рост объемов данных]]></description>
<source><![CDATA[&lltt;p&ggtt;В сентябре 2026 года компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представит заказчикам vitiscale — собственную горизонтально масштабируемую СХД, спроектированную для самых требовательных задач. vitiscale обеспечивает десятки миллионов IOPS и сотни тысяч RPS в секунду при минимальном времени отклика и гарантирует производительность, необходимую для эффективной работы AI/ML-решений, аналитики больших массивов данных, высоконагруженных ферм СУБД и быстрого восстановления данных.&lltt;/p&ggtt;
&lltt;p&ggtt;«vitiscale — это полностью оригинальная разработка, а не производное от существующего решения на основе open-source, — рассказал Филипп Комиссаров, технический директор datagarden. — Мы сознательно пошли на то, чтобы переписать программную архитектуру системы хранения практически с нуля: только так можно было извлечь из оборудования максимум и устранить те узкие места, с которыми мы годами сталкивались в ходе эксплуатации хранилищ такого класса. Для заказчика это выражается во вполне практичных вещах: та же задача решается кратно меньшим числом узлов, требует значительно меньше энергии и места в стойках, а производительность и емкость растут линейно и без остановки сервисов. Мы строили vitiscale, ориентируясь на нагрузки эпохи искусственного интеллекта и аналитики больших данных, где одинаково важны и высочайшая производительность, и минимальный отклик».&lltt;/p&ggtt;
&lltt;p&ggtt;Программная архитектура vitiscale построена на принципах множественного параллельного ввода-вывода и прямого доступа к данным. Это означает, что каждый узел системы обслуживает запросы напрямую — без промежуточных контроллеров метаданных или избыточных шлюзов. Благодаря этому даже при внушительных нагрузках vitiscale требует значительно меньше оборудования, чем классические СХД и open-source-кластеры. vitiscale предоставляет блочный доступ (NVMe over Fabrics (TCP, RDMA, Fibre Channel), а также iSCSI и FC) и объектное хранилище с S3 API. Кластер масштабируется от 3 до 512 узлов с шагом в один узел и без остановки сервисов. Производительность и емкость растут линейно — до десятков петабайт в одной системе. Система совместима с отечественными ОС, включая Astra Linux SE, AltLinux, РОСА и РЕД ОС. Продукт включен в реестр российского ПО Минцифры (№ 23346), программно-аппаратный комплекс на серийной платформе datagarden — в реестр ПАК (№ 28285).&lltt;/p&ggtt;
&lltt;p&ggtt;Горизонтально масштабируемую СХД vitiscale команда datagarden разрабатывает с 2022 года. Ключевая цель проекта — максимально эффективно использовать аппаратные ресурсы системы. Над продуктом работает команда инженеров, которые в течение многих лет эксплуатировали хранилища данного класса и знают их узкие места изнутри.&lltt;/p&ggtt;
&lltt;p&ggtt;Компания datagarden разрабатывает и производит в России централизованные и распределенные системы хранения данных. Архитектура и алгоритмы хранения в основе продуктов datagarden соответствуют современным профилям нагрузок — от виртуализации и СУБД до искусственного интеллекта — и рассчитаны на непрерывную эксплуатацию и рост объемов данных.&lltt;/p&ggtt;]]></source>
<adate>27.08.2026</adate>
<dbid>235425</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Сети/Серверы/СХД/ЦОД]]></tag>
</item>
<item>
<title><![CDATA[Как не потерять сайт после введения обязательной идентификации через &#8220;Госуслуги&#8221;]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235426]]></link>
<description><![CDATA[С 1 сентября в России вступают в силу изменения в законодательстве, которые затронут всех владельцев доменов в зонах .RU, .SU и .РФ. Согласно Федеральному закону № 569-ФЗ, регистрация и дальнейшее управление доменными именами будут возможны только после идентификации администратора через ЕСИА («Госуслуги»). При этом подзаконные акты, которые должны определить порядок применения новых требований, пока находятся в стадии разработки. Рассмотрим, какие риски это создает для бизнеса и что предпринимателям стоит сделать уже сейчас. Идея обязательной идентификации направлена на снижение количества анонимных регистраций и мошенничества с доменными именами. После внедрения механизма каждый администратор домена будет подтверждать свою личность через «Госуслуги» — ЕСИА, что, по замыслу авторов нововведения, должно повысить прозрачность российского доменного пространства. Рынок уже начал готовиться к изменениям. Наблюдается заметный рост количества обращений клиентов к регистраторам по вопросам переоформления доменов и актуализации регистрационных данных. Серьезной нагрузки на службы поддержки пока нет, окончательные правила регистрации будут утверждены до 1 сентября. И у регистраторов остается время на полноценное тестирование новых процессов и интеграцию с государственными информационными системами. Какие риски влекут новые правила Главный риск для компаний связан не со штрафами — их закон не предусматривает, — но с потерей возможности управлять собственным доменом. Если администратор не сможет пройти идентификацию через ЕСИА, он так же не сможет зарегистрировать новый домен в зонах .RU, .SU и .РФ, продлить срок его действия, изменить регистрационные данные или перенести домен к другому регистратору. В перспективе это может привести к утрате самого доменного имени. Нововведения касаются именно кантри-кодов .RU, .SU и .РФ — или страновых доменов, которые в отличии от доменов общего пользования, таких как, например, .РУС, могут иметь отдельные требования и правила регистрации. Еще один риск — потеря доступа к корпоративной почте и связанным с ней онлайн-сервисам. Если почта работает на домене компании (name@company.ru), а компания потеряла возможность управлять им, могут возникнуть проблемы с почтовыми настройками: станет невозможно изменить MX-записи, которые указывают, где находится почта, или подтвердить права на домен для почтовых сервисов, могут также возникнуть перебои в доставке писем. Компании, которые используют корпоративную почту или домен для авторизации, восстановления доступа или подтверждения владения системами аналитики, рекламными кабинетами, облачными сервисами, CRM, сервисами для рассылок и прочими онлайн-сервисами, потеряют доступ к этим ресурсам. Как подготовиться к новой процедуре идентификации Особенно внимательно стоит проверить старые корпоративные сайты. Нередко оказывается, что домен зарегистрирован не на владельца бизнеса, а на бывшего директора, системного администратора, разработчика сайта или даже на юридическое лицо, которое уже ликвидировано. Такая ситуация часто остается незамеченной, так как при повседневной работе сайта компании обычно не требуется взаимодействовать с администратором домена. Компания пользуется сайтом и считает его своим, потому что у нее есть доступ к CMS, хостингу, контенту, есть возможность менять страницы. В результате бизнес может не знать, что права на управление доменным именем оформлены на человека, который больше не связан с компанией. Но после введения идентификации через ЕСИА именно такая ситуация может стать причиной потери доступа к домену. Соответственно, если домен оформлен на бывшего руководителя или сотрудника, предпринимателю следует заранее установить с ним контакт и провести смену администратора. Сменить администратора после вступления новых правил в силу может оказаться значительно сложнее. Аналогичный подход рекомендуется и компаниям, чьи домены зарегистрированы на организации без подтвержденной учетной записи на «Госуслугах». В этом случае разумно либо заранее создать такую учетную запись, либо переоформить домен на администратора, который сможет пройти необходимую процедуру идентификации через ЕСИА, например, на собственника бизнеса или действующего директора. Владельцам сайтов не стоит ожидать существенного роста расходов. Интеграция с ЕСИА потребует значительных инвестиций от доменных регистраторов, но для конечных пользователей удорожание регистрации и продления доменов составит всего несколько сотен рублей в год. Для бизнеса такие затраты не сопоставимы с рисками потери уже раскрученного сайта, восстановление которого потребует значительно больше времени и средств. Что делать, если сохранить текущий домен не получится Если компания понимает, что сохранить существующий домен не удастся, подготовиться к переезду на новый сайт лучше заранее. Для сайтов, уже имеющих поисковый трафик, смена домена без предварительной подготовки может привести к потере позиций в поисковой выдаче, поэтому перенос необходимо планировать заблаговременно, используя инструменты поисковых систем для корректной смены адреса сайта. До появления окончательных правил регистрации стоит провести «ревизию» доменного портфеля: проверить, кто указан администратором каждого домена, актуальны ли регистрационные данные и сможет ли этот человек или организация пройти идентификацию через ЕСИА после вступления новых требований в силу. Именно такая подготовка сегодня остается самым эффективным способом избежать потери доступа к корпоративному сайту. #IMAGE_235427#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;С&nbsp;1&nbsp;сентября в&nbsp;России вступают в&nbsp;силу изменения в&nbsp;законодательстве, которые затронут всех владельцев доменов в&nbsp;зонах &lltt;/em&ggtt;&lltt;em&ggtt;.RU, .SU и .РФ. Согласно Федеральному закону №&nbsp;&lltt;nobr&ggtt;569-ФЗ,&lltt;/nobr&ggtt; регистрация и&nbsp;дальнейшее управление доменными именами будут возможны только после идентификации администратора через ЕСИА («Госуслуги&lltt;/em&ggtt;&lltt;em&ggtt;»)&lltt;/em&ggtt;&lltt;em&ggtt;. При этом подзаконные акты, которые должны определить порядок применения новых требований, пока находятся в&nbsp;стадии разработки. &lltt;/em&ggtt;&lltt;em&ggtt;Рассмотрим&lltt;/em&ggtt;&lltt;em&ggtt;, какие риски это создает для бизнеса и&nbsp;что предпринимателям стоит сделать уже сейчас.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Идея обязательной идентификации направлена на&nbsp;снижение количества анонимных регистраций и&nbsp;мошенничества с&nbsp;доменными именами. После внедрения механизма каждый администратор домена будет подтверждать свою личность через «Госуслуги»&nbsp;— ЕСИА, что, по&nbsp;замыслу авторов нововведения, должно повысить прозрачность российского доменного пространства.&lltt;/p&ggtt;
&lltt;p&ggtt;Рынок уже начал готовиться к&nbsp;изменениям. Наблюдается заметный рост количества обращений клиентов к&nbsp;регистраторам по&nbsp;вопросам переоформления доменов и&nbsp;актуализации регистрационных данных. Серьезной нагрузки на&nbsp;службы поддержки пока нет, окончательные правила регистрации будут утверждены до&nbsp;1&nbsp;сентября. И&nbsp;у&nbsp;регистраторов остается время на&nbsp;полноценное тестирование новых процессов и&nbsp;интеграцию с&nbsp;государственными информационными системами.&lltt;/p&ggtt;
&lltt;h3&ggtt;Какие риски влекут новые правила&lltt;/h3&ggtt;
&lltt;p&ggtt;Главный риск для компаний связан не&nbsp;со&nbsp;штрафами&nbsp;— их&nbsp;закон не&nbsp;предусматривает,&nbsp;— но&nbsp;с&nbsp;потерей возможности управлять собственным доменом. Если администратор не&nbsp;сможет пройти идентификацию через ЕСИА, он&nbsp;так&nbsp;же не&nbsp;сможет зарегистрировать новый домен в&nbsp;зонах .RU, .SU и .РФ, продлить срок его действия, изменить регистрационные данные или перенести домен к&nbsp;другому регистратору. В&nbsp;перспективе это может привести к&nbsp;утрате самого доменного имени. Нововведения касаются именно кантри-кодов .RU, .SU и .РФ&nbsp;— или страновых доменов, которые в&nbsp;отличии от&nbsp;доменов общего пользования, таких как, например, .РУС, могут иметь отдельные требования и&nbsp;правила регистрации.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще один риск&nbsp;— потеря доступа к&nbsp;корпоративной почте и&nbsp;связанным с&nbsp;ней онлайн-сервисам. Если почта работает на&nbsp;домене компании (name@company.ru), а&nbsp;компания потеряла возможность управлять&nbsp;им, могут возникнуть проблемы с&nbsp;почтовыми настройками: станет невозможно изменить &lltt;nobr&ggtt;MX-записи,&lltt;/nobr&ggtt; которые указывают, где находится почта, или подтвердить права на&nbsp;домен для почтовых сервисов, могут также возникнуть перебои в&nbsp;доставке писем. Компании, которые используют корпоративную почту или домен для авторизации, восстановления доступа или подтверждения владения системами аналитики, рекламными кабинетами, облачными сервисами, CRM, сервисами для рассылок и&nbsp;прочими онлайн-сервисами, потеряют доступ к&nbsp;этим ресурсам.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как подготовиться к&nbsp;новой процедуре идентификации&lltt;/h3&ggtt;
&lltt;p&ggtt;Особенно внимательно стоит проверить старые корпоративные сайты. Нередко оказывается, что домен зарегистрирован не&nbsp;на&nbsp;владельца бизнеса, а&nbsp;на&nbsp;бывшего директора, системного администратора, разработчика сайта или даже на&nbsp;юридическое лицо, которое уже ликвидировано.&lltt;/p&ggtt;
&lltt;p&ggtt;Такая ситуация часто остается незамеченной, так как при повседневной работе сайта компании обычно не&nbsp;требуется взаимодействовать с&nbsp;администратором домена. Компания пользуется сайтом и&nbsp;считает его своим, потому что у&nbsp;нее есть доступ к&nbsp;CMS, хостингу, контенту, есть возможность менять страницы.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;результате бизнес может не&nbsp;знать, что права на&nbsp;управление доменным именем оформлены на&nbsp;человека, который больше не&nbsp;связан с&nbsp;компанией. Но&nbsp;после введения идентификации через ЕСИА именно такая ситуация может стать причиной потери доступа к&nbsp;домену.&lltt;/p&ggtt;
&lltt;p&ggtt;Соответственно, если домен оформлен на&nbsp;бывшего руководителя или сотрудника, предпринимателю следует заранее установить с&nbsp;ним контакт и&nbsp;провести смену администратора. Сменить администратора после вступления новых правил в&nbsp;силу может оказаться значительно сложнее.&lltt;/p&ggtt;
&lltt;p&ggtt;Аналогичный подход рекомендуется и&nbsp;компаниям, чьи домены зарегистрированы на&nbsp;организации без подтвержденной учетной записи на&nbsp;«Госуслугах». В&nbsp;этом случае разумно либо заранее создать такую учетную запись, либо переоформить домен на&nbsp;администратора, который сможет пройти необходимую процедуру идентификации через ЕСИА, например, на&nbsp;собственника бизнеса или действующего директора.&lltt;/p&ggtt;
&lltt;p&ggtt;Владельцам сайтов не&nbsp;стоит ожидать существенного роста расходов. Интеграция с&nbsp;ЕСИА потребует значительных инвестиций от&nbsp;доменных регистраторов, но&nbsp;для конечных пользователей удорожание регистрации и&nbsp;продления доменов составит всего несколько сотен рублей в&nbsp;год. Для бизнеса такие затраты не&nbsp;сопоставимы с&nbsp;рисками потери уже раскрученного сайта, восстановление которого потребует значительно больше времени и&nbsp;средств.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что делать, если сохранить текущий домен не&nbsp;получится&lltt;/h3&ggtt;
&lltt;p&ggtt;Если компания понимает, что сохранить существующий домен не&nbsp;удастся, подготовиться к&nbsp;переезду на&nbsp;новый сайт лучше заранее. Для сайтов, уже имеющих поисковый трафик, смена домена без предварительной подготовки может привести к&nbsp;потере позиций в&nbsp;поисковой выдаче, поэтому перенос необходимо планировать заблаговременно, используя инструменты поисковых систем для корректной смены адреса сайта.&lltt;/p&ggtt;
&lltt;p&ggtt;До&nbsp;появления окончательных правил регистрации стоит провести «ревизию» доменного портфеля: проверить, кто указан администратором каждого домена, актуальны&nbsp;ли регистрационные данные и&nbsp;сможет&nbsp;ли этот человек или организация пройти идентификацию через ЕСИА после вступления новых требований в&nbsp;силу. Именно такая подготовка сегодня остается самым эффективным способом избежать потери доступа к&nbsp;корпоративному сайту.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235427#&lltt;/p&ggtt;]]></source>
<adate>28.08.2026</adate>
<dbid>235426</dbid>
<rubric>8</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/819/6qac3eq2kyacjp293oei5af8pz9321um.jpg]]>
</images>
<imagesname><![CDATA[;;Алексей Созонов, заместитель директора доменного регистратора Webnames.ru   ]]></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Истинная сила ИИ: трансформация рабочих процессов, а не только отдельных задач]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235422]]></link>
<description><![CDATA[Искусственный интеллект — это нечто гораздо большее, чем просто повышение индивидуальной эффективности. Организациям следует задуматься о том, как автоматизация межкомандных процессов может способствовать стратегическому росту и снижению операционного сопротивления, пишет на портале InformationWeek Мэтт Лайтесон, CIO IBM по технологическим платформам. Сегодня слишком много разговоров об ИИ сосредоточено на индивидуальной продуктивности и рутинных задачах, а также на развитии набора навыков. Это важные темы, но бизнес-лидеры упускают из виду ключевой момент. Ценность корпоративного ИИ заключается не в том, чтобы повысить скорость выполнения задач или превзойти человека в креативности, а в чем-то гораздо более значимом: в обеспечении обмена информацией, аналитикой и знаниями в масштабах всей организации и раскрытии потенциала талантов, который сдерживается организационным сопротивлением. Вполне естественно сосредоточиться на том, как ИИ может помочь людям быстрее выполнять задачи, будь то создание рецептов и составление маршрутов для путешествий в домашних условиях или реферирование PDF-файлов и анализ массивов данных на работе. Но компании — это не просто здания, в которых работают «индивидуалисты». Это интегрированные и организованные системы, протоколы, ноу-хау, технологии и многое другое, что позволяет им масштабироваться и постоянно добиваться большего с меньшими затратами. Масштабирование ИИ за пределы индивидуального уровня Организационное сопротивление — это не второстепенная проблема. Совокупность внутренней бюрократии, избыточных процессов и других препятствий может существенно замедлить работу команды. По данным исследования, проведенного компанией McKinsey в ноябре 2025 г., 57% рабочего времени в США можно автоматизировать с помощью доступных сегодня технологий. Рассмотрим пример: аналитик по закупкам сверяет заказы на поставку со счетами-фактурами. В настоящее время эти сотрудники тратят много времени на сопоставление позиций, проверку условий договоров с поставщиками и устранение расхождений в данных из разных систем. Это малоэффективная работа, которая отнимает время, силы и возможности для более глубокой и целенаправленной деятельности. А теперь представьте, что весь процесс в значительной степени автоматизирован. Аналитик загружает счет-фактуру или отмечает заказ на поставку. ИИ берет на себя заполнение сметы расходов, сопоставление позиций и предоставляет администраторам инсайты, чтобы они могли быстрее принимать решения и исправлять ошибки. После сверки данные автоматически обновляются во всех финансовых системах. Нет необходимости вводить данные повторно, нет необходимости в ручном контроле, нет напрасной траты времени. Вот когда можно ощутить реальный эффект от внедрения автоматизации. Время экономит не только один аналитик. Благодаря автоматизированной сверке данных отделы закупок, финансов и комплаенса могут направить свои усилия на более важные задачи. Это оптимизирует то, что делается для сокращения операционных расходов, ускорения роста выручки за счет повышения скорости и повышения качества внутренних процессов и управления рисками за счет обеспечения соответствия каждого этапа рабочего процесса политикам, разрешениям и принципам управления. Благодаря этим трем направлениям — оптимизации затрат, ускорению роста и управлению рисками — корпоративный ИИ приносит прибыль, которая намного превышает эффект от прироста производительности отдельных сотрудников. Создание основы Для эффективного масштабирования ИИ на предприятии требуется нечто большее, чем просто использование нового инструмента отдельным человеком. Для этого требуется стек ИИ корпоративного уровня, который позволяет пользователям находить нужных агентов, получать доступ к корпоративной информации и генерировать инсайты, которые поддерживают стратегию команды. В сочетании с изменениями в организационной культуре эти возможности на уровне рабочих процессов позволяют по-настоящему получить выгоду от ИИ. Это больше, чем просто автоматизация задач; это оркестрация рабочего процесса. ИИ, работающий на основе упорядоченных данных, четких разрешений и эффективного управления, способен выполнять роль связующей ткани организации, управляя задачами в различных приложениях. В случае с нашим аналитиком по закупкам это означает понимание того, кто уполномочен просматривать данные и утверждать действия, и соответствующее перемещение информации с портала запросов в систему учета расходов. Чистые, интегрированные системы ИИ позволяют аналитику быстро находить нужных агентов или получать доступ к любому из них через единый портал. Когда он обдумывает новый проект, интерактивный ИИ-помощник может ответить на любые его вопросы, предоставив достоверные данные в соответствии с уровнем доступа, и направить ход его мыслей в нужное русло. Если ему нужно связаться с разными членами команды, ИИ-помощник может составить персонализированные сообщения с учетом индивидуальных особенностей, принадлежности к команде, географического положения и других факторов. Использование ИИ позволяет сотрудникам быстро и продуктивно способствовать стратегическому развитию бизнеса. От работы с ИИ к ИИ как рабочей силе Это не просто технологическая трансформация. После внедрения ИИ на предприятии компаниям придется пересмотреть свои процессы и корпоративную культуру, чтобы адаптировать их к новым реалиям. Результатом станут не только быстрые ответы на электронные письма и генерация контента. Мы увидим более активный обмен информацией, креативность, стратегическое планирование и критически важную работу, которую сотрудники смогут выполнять, не отвлекаясь на то, что у них получается хуже всего. Ставки высоки: по оценкам McKinsey, ИИ может принести компаниям прибыль в размере 4,4 трлн. долл. Мы уже видим это на примере IBM: мы уже сэкономили 4,5 млрд. долл., несмотря на то, что ИИ только начинает проникать в нашу деятельность. Внедрив методы управления организационными изменениями, предприятия могут оптимизировать рабочие процессы, чтобы сократить расходы, ускорить рост доходов и снизить риски. Сейчас самое время подготовиться к этой возможности и воспользоваться ею. После внедрения отдельных ИИ-инструментов компаниям необходимо сосредоточиться на корпоративных рабочих процессах, которые созрели для агентной трансформации. Им следует развернуть единую платформу, которая позволит создавать, повторно использовать, масштабировать и контролировать ИИ на всех уровнях предприятия — и при этом обеспечивать безопасность. По мере внедрения корпоративного ИИ компаниям необходимо вовлекать в этот процесс сотрудников, подталкивать их не только к использованию новых инструментов, но и к переосмыслению рабочих процессов. В совокупности эти шаги запустят «маховик» ИИ, откроют возможности для непрерывных инноваций и в конечном итоге обеспечат значимую бизнес-ценность]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Искусственный интеллект — это нечто гораздо большее, чем просто повышение индивидуальной эффективности. Организациям следует задуматься о том, как автоматизация межкомандных процессов может способствовать стратегическому росту и снижению операционного сопротивления, пишет на портале &lltt;/em&ggtt;&lltt;em&ggtt;InformationWeek&lltt;/em&ggtt; &lltt;em&ggtt;Мэтт Лайтесон, &lltt;/em&ggtt;&lltt;em&ggtt;CIO&lltt;/em&ggtt; &lltt;em&ggtt;IBM по технологическим платформам.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Сегодня слишком много разговоров об ИИ сосредоточено на индивидуальной продуктивности и рутинных задачах, а также на развитии набора навыков. Это важные темы, но бизнес-лидеры упускают из виду ключевой момент.&lltt;/p&ggtt;
&lltt;p&ggtt;Ценность корпоративного ИИ заключается не в том, чтобы повысить скорость выполнения задач или превзойти человека в креативности, а в чем-то гораздо более значимом: в обеспечении обмена информацией, аналитикой и знаниями в масштабах всей организации и раскрытии потенциала талантов, который сдерживается организационным сопротивлением.&lltt;/p&ggtt;
&lltt;p&ggtt;Вполне естественно сосредоточиться на том, как ИИ может помочь людям быстрее выполнять задачи, будь то создание рецептов и составление маршрутов для путешествий в домашних условиях или реферирование PDF-файлов и анализ массивов данных на работе. Но компании — это не просто здания, в которых работают «индивидуалисты». Это интегрированные и организованные системы, протоколы, ноу-хау, технологии и многое другое, что позволяет им масштабироваться и постоянно добиваться большего с меньшими затратами.&lltt;/p&ggtt;
&lltt;h3&ggtt; Масштабирование ИИ за пределы индивидуального уровня&lltt;/h3&ggtt;
&lltt;p&ggtt;Организационное сопротивление — это не второстепенная проблема. Совокупность внутренней бюрократии, избыточных процессов и других препятствий может существенно замедлить работу команды. По данным исследования, проведенного компанией McKinsey в ноябре 2025 г., 57% рабочего времени в США можно автоматизировать с помощью доступных сегодня технологий.&lltt;/p&ggtt;
&lltt;p&ggtt;Рассмотрим пример: аналитик по закупкам сверяет заказы на поставку со счетами-фактурами. В настоящее время эти сотрудники тратят много времени на сопоставление позиций, проверку условий договоров с поставщиками и устранение расхождений в данных из разных систем. Это малоэффективная работа, которая отнимает время, силы и возможности для более глубокой и целенаправленной деятельности.&lltt;/p&ggtt;
&lltt;p&ggtt;А теперь представьте, что весь процесс в значительной степени автоматизирован. Аналитик загружает счет-фактуру или отмечает заказ на поставку. ИИ берет на себя заполнение сметы расходов, сопоставление позиций и предоставляет администраторам инсайты, чтобы они могли быстрее принимать решения и исправлять ошибки. После сверки данные автоматически обновляются во всех финансовых системах. Нет необходимости вводить данные повторно, нет необходимости в ручном контроле, нет напрасной траты времени.&lltt;/p&ggtt;
&lltt;p&ggtt;Вот когда можно ощутить реальный эффект от внедрения автоматизации. Время экономит не только один аналитик. Благодаря автоматизированной сверке данных отделы закупок, финансов и комплаенса могут направить свои усилия на более важные задачи. Это оптимизирует то, что делается для сокращения операционных расходов, ускорения роста выручки за счет повышения скорости и повышения качества внутренних процессов и управления рисками за счет обеспечения соответствия каждого этапа рабочего процесса политикам, разрешениям и принципам управления. Благодаря этим трем направлениям — оптимизации затрат, ускорению роста и управлению рисками — корпоративный ИИ приносит прибыль, которая намного превышает эффект от прироста производительности отдельных сотрудников.&lltt;/p&ggtt;
&lltt;h3&ggtt;Создание основы&lltt;/h3&ggtt;
&lltt;p&ggtt;Для эффективного масштабирования ИИ на предприятии требуется нечто большее, чем просто использование нового инструмента отдельным человеком. Для этого требуется стек ИИ корпоративного уровня, который позволяет пользователям находить нужных агентов, получать доступ к корпоративной информации и генерировать инсайты, которые поддерживают стратегию команды. В сочетании с изменениями в организационной культуре эти возможности на уровне рабочих процессов позволяют по-настоящему получить выгоду от ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Это больше, чем просто автоматизация задач; это оркестрация рабочего процесса. ИИ, работающий на основе упорядоченных данных, четких разрешений и эффективного управления, способен выполнять роль связующей ткани организации, управляя задачами в различных приложениях.&lltt;/p&ggtt;
&lltt;p&ggtt;В случае с нашим аналитиком по закупкам это означает понимание того, кто уполномочен просматривать данные и утверждать действия, и соответствующее перемещение информации с портала запросов в систему учета расходов. Чистые, интегрированные системы ИИ позволяют аналитику быстро находить нужных агентов или получать доступ к любому из них через единый портал.&lltt;/p&ggtt;
&lltt;p&ggtt;Когда он обдумывает новый проект, интерактивный ИИ-помощник может ответить на любые его вопросы, предоставив достоверные данные в соответствии с уровнем доступа, и направить ход его мыслей в нужное русло. Если ему нужно связаться с разными членами команды, ИИ-помощник может составить персонализированные сообщения с учетом индивидуальных особенностей, принадлежности к команде, географического положения и других факторов. Использование ИИ позволяет сотрудникам быстро и продуктивно способствовать стратегическому развитию бизнеса.&lltt;/p&ggtt;
&lltt;h3&ggtt;От работы с ИИ к ИИ как рабочей силе&lltt;/h3&ggtt;
&lltt;p&ggtt;Это не просто технологическая трансформация. После внедрения ИИ на предприятии компаниям придется пересмотреть свои процессы и корпоративную культуру, чтобы адаптировать их к новым реалиям. Результатом станут не только быстрые ответы на электронные письма и генерация контента. Мы увидим более активный обмен информацией, креативность, стратегическое планирование и критически важную работу, которую сотрудники смогут выполнять, не отвлекаясь на то, что у них получается хуже всего.&lltt;/p&ggtt;
&lltt;p&ggtt;Ставки высоки: по оценкам McKinsey, ИИ может принести компаниям прибыль в размере 4,4 трлн. долл. Мы уже видим это на примере IBM: мы уже сэкономили 4,5 млрд. долл., несмотря на то, что ИИ только начинает проникать в нашу деятельность. Внедрив методы управления организационными изменениями, предприятия могут оптимизировать рабочие процессы, чтобы сократить расходы, ускорить рост доходов и снизить риски.&lltt;/p&ggtt;
&lltt;p&ggtt;Сейчас самое время подготовиться к этой возможности и воспользоваться ею. После внедрения отдельных ИИ-инструментов компаниям необходимо сосредоточиться на корпоративных рабочих процессах, которые созрели для агентной трансформации. Им следует развернуть единую платформу, которая позволит создавать, повторно использовать, масштабировать и контролировать ИИ на всех уровнях предприятия — и при этом обеспечивать безопасность. По мере внедрения корпоративного ИИ компаниям необходимо вовлекать в этот процесс сотрудников, подталкивать их не только к использованию новых инструментов, но и к переосмыслению рабочих процессов. В совокупности эти шаги запустят «маховик» ИИ, откроют возможности для непрерывных инноваций и в конечном итоге обеспечат значимую бизнес-ценность.&lltt;/p&ggtt;]]></source>
<adate>28.08.2026</adate>
<dbid>235422</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[ИИ ставит перед аналитическими командами новые задачи]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235421]]></link>
<description><![CDATA[Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале BigDataWire Сохам Мазумдар, соучредитель и генеральный директор WisdomAI. На протяжении многих лет аналитические команды помогали организациям разобраться в своих данных. Они создавали дашборды. Они создавали отчеты. Они создавали конвейеры обработки данных. Они разрабатывали определения, документировали метрики и помогали руководителям отвечать на вопросы о том, что происходит внутри компании. Теперь сотрудники компаний все чаще обращаются к ChatGPT, Claude, Copilot и другим системам на основе ИИ вместо того, чтобы напрямую открывать дашборды. Вместо того, чтобы самостоятельно работать с инструментами отчетности, они задают вопрос и ждут ответа. Когда сотрудник запрашивает информацию с дашборда, тот выдает ему метрику. Когда сотрудник обращается к ИИ-помощнику, тот интерпретирует информацию, объединяет данные из нескольких систем, применяет логику и выдает заключение. Но кто-то все равно должен определить, верен ли ответ, и эта ответственность все чаще ложится на аналитические команды. Традиционное управление решало другие задачи На протяжении большей части современной эпохи работы с данными управление было сосредоточено на вопросах доступа, происхождения данных, определений и доверия. Организациям нужно было знать, кто имеет доступ к данным, откуда поступает информация, как определяются метрики и на какие отчеты можно полагаться при принятии решений. Для решения этих проблем появились каталоги данных, инструменты отслеживания происхождения данных, платформы для документирования и системы управления. Они помогли организациям обеспечить согласованность во все более сложных средах обработки данных и повысили уверенность сотрудников в информации, которой они пользовались каждый день. Эта система работала, потому что окончательное решение оставалось за людьми. Аналитики и бизнес-руководители отвечали за интерпретацию информации, учет контекста и определение того, как данные должны влиять на принятие решений. Система управления была создана для того, чтобы обеспечить людям доступ к достоверной информации. Она не была предназначена для оценки того, как ПО обрабатывает эту информацию. Агенты создают новую проблему в сфере управления Одно из самых распространенных заблуждений в сфере корпоративного ИИ заключается в том, что управление — это в первую очередь проблема доступа. Логика кажется разумной: если у агента есть доступ к нужным системам и данным, он должен быть в состоянии выдать правильный ответ. К сожалению, доступ и точность — это не одно и то же. В отличие от традиционных аналитических инструментов, агенты не просто извлекают информацию. Они интерпретируют ее, объединяют сигналы из нескольких систем, применяют бизнес-логику и генерируют рекомендации, которые все больше влияют на решения и действия. Это значит, что агент может получить доступ к абсолютно достоверной информации и все равно прийти к неверному выводу. Данные о клиенте могут быть точными. Прогноз продаж может быть актуальным. Финансовые показатели могут быть корректно определены. Тем не менее, агент может неправильно комбинировать эти входные данные, неправильно понимать контекст, в котором они используются, или непоследовательно применять бизнес-логику. Многие организации полагают, что управление заканчивается, как только будут установлены необходимые разрешения и подключены нужные источники данных. На самом деле эти элементы управления определяют только то, к какой информации агент может получить доступ. Они не определяют, правильно ли агент интерпретирует эту информацию. Традиционные системы управления никогда не были разработаны для решения этой проблемы. Разрешения не предотвращают неправильного толкования, отслеживание происхождения не гарантирует разумного обоснования, а документация не обеспечивает последовательного выполнения. Поскольку организации внедряют агентов во все большее число рабочих процессов, им нужен способ оценить не только то, что может видеть система ИИ, но и то, можно ли доверять выводам, которые она делает. Аналитические группы становятся ИИ-рецензентами Кто-то должен выявлять повторяющиеся сбои, сопоставлять результаты с реальностью и определять, повышается или снижается надежность с течением времени. Эта работа, естественно, ложится на плечи аналитиков. Они уже понимают, что лежит в основе данных, как определяются показатели, откуда берется бизнес-логика и как информация перемещается по организации. Не менее важно, что они понимают, как должен выглядеть правильный ответ и где наиболее вероятно возникновение ошибок. По мере того как ИИ становится все более важной частью доступа сотрудников к информации, аналитические группы берут на себя обязанности, которые все больше напоминают обеспечение качества. Они проверяют результаты, оценивают надежность, расследуют сбои, отслеживают согласованность и выявляют условия, которые заставляют агентов выдавать неверные результаты. Исторически сложилось так, что аналитические группы отвечали за то, чтобы дашборды и отчеты точно отражали бизнес. ИИ расширяет зону их ответственности. Тем же командам теперь предлагается оценить, дают ли агенты, вторые пилоты и аналитические системы на базе ИИ ответы, заслуживающие такого же уровня доверия. Управление выходит за рамки данных Большинство программ управления были построены вокруг контроля доступа к информации. Цель состояла в том, чтобы обеспечить сотрудникам доступ к необходимым им данным, сохраняя при этом согласованность, безопасность и доверие во всей организации. ИИ ставит перед ними другую задачу. Агент может иметь доступ к нужным системам, нужным данным и нужным разрешениям, но при этом выдавать неполный, противоречивый или просто неправильный ответ. Это смещает фокус управления за пределы контроля доступа и управления данными. Организациям необходимо иметь представление о том, как ведут себя агенты, насколько последовательно они применяют бизнес-логику и остаются ли результаты, которые они генерируют, надежными с течением времени. Организация, которая не может доверять выводам, сделанным ее системами ИИ, не решила проблему управления просто потому, что базовые данные хорошо управляются. По мере того как агенты все глубже интегрируются в бизнес-процессы, надежность, валидация и контроль становятся не менее важными, чем прослеживаемость происхождения, права доступа и документация. Переход от управления данными к управлению ИИ Профессия аналитика уже претерпела несколько серьезных трансформаций: от отчетности и бизнес-аналитики к самообслуживанию в аналитике и современным платформам данных. ИИ порождает еще одну трансформацию. По мере того как агенты все активнее участвуют в предоставлении сотрудникам доступа к информации, организациям становятся нужны люди, которые смогут оценивать надежность, расследовать сбои и определять, заслуживают ли доверия результаты работы ИИ. Аналитические команды хорошо подходят для выполнения этой задачи, поскольку они уже разбираются в данных, бизнес-логике и операционном контексте, лежащих в основе ответов, которые выдают эти системы. На протяжении многих лет их роль заключалась в том, чтобы помогать людям принимать более взвешенные решения на основе данных. Теперь они все чаще отвечают за то, чтобы системы ИИ могли делать то же самое]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале &lltt;/em&ggtt;&lltt;em&ggtt;BigDataWire&lltt;/em&ggtt; &lltt;em&ggtt;Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;На протяжении многих лет аналитические команды помогали организациям разобраться в своих данных. Они создавали дашборды. Они создавали отчеты. Они создавали конвейеры обработки данных. Они разрабатывали определения, документировали метрики и помогали руководителям отвечать на вопросы о том, что происходит внутри компании.&lltt;/p&ggtt;
&lltt;p&ggtt;Теперь сотрудники компаний все чаще обращаются к ChatGPT, Claude, Copilot и другим системам на основе ИИ вместо того, чтобы напрямую открывать дашборды. Вместо того, чтобы самостоятельно работать с инструментами отчетности, они задают вопрос и ждут ответа.&lltt;/p&ggtt;
&lltt;p&ggtt;Когда сотрудник запрашивает информацию с дашборда, тот выдает ему метрику. Когда сотрудник обращается к ИИ-помощнику, тот интерпретирует информацию, объединяет данные из нескольких систем, применяет логику и выдает заключение.&lltt;/p&ggtt;
&lltt;p&ggtt;Но кто-то все равно должен определить, верен ли ответ, и эта ответственность все чаще ложится на аналитические команды.&lltt;/p&ggtt;
&lltt;h3&ggtt;Традиционное управление решало другие задачи&lltt;/h3&ggtt;
&lltt;p&ggtt;На протяжении большей части современной эпохи работы с данными управление было сосредоточено на вопросах доступа, происхождения данных, определений и доверия. Организациям нужно было знать, кто имеет доступ к данным, откуда поступает информация, как определяются метрики и на какие отчеты можно полагаться при принятии решений.&lltt;/p&ggtt;
&lltt;p&ggtt;Для решения этих проблем появились каталоги данных, инструменты отслеживания происхождения данных, платформы для документирования и системы управления. Они помогли организациям обеспечить согласованность во все более сложных средах обработки данных и повысили уверенность сотрудников в информации, которой они пользовались каждый день.&lltt;/p&ggtt;
&lltt;p&ggtt;Эта система работала, потому что окончательное решение оставалось за людьми. Аналитики и бизнес-руководители отвечали за интерпретацию информации, учет контекста и определение того, как данные должны влиять на принятие решений. Система управления была создана для того, чтобы обеспечить людям доступ к достоверной информации. Она не была предназначена для оценки того, как ПО обрабатывает эту информацию.&lltt;/p&ggtt;
&lltt;h3&ggtt;Агенты создают новую проблему в сфере управления&lltt;/h3&ggtt;
&lltt;p&ggtt;Одно из самых распространенных заблуждений в сфере корпоративного ИИ заключается в том, что управление — это в первую очередь проблема доступа. Логика кажется разумной: если у агента есть доступ к нужным системам и данным, он должен быть в состоянии выдать правильный ответ.&lltt;/p&ggtt;
&lltt;p&ggtt;К сожалению, доступ и точность — это не одно и то же.&lltt;/p&ggtt;
&lltt;p&ggtt;В отличие от традиционных аналитических инструментов, агенты не просто извлекают информацию. Они интерпретируют ее, объединяют сигналы из нескольких систем, применяют бизнес-логику и генерируют рекомендации, которые все больше влияют на решения и действия.&lltt;/p&ggtt;
&lltt;p&ggtt;Это значит, что агент может получить доступ к абсолютно достоверной информации и все равно прийти к неверному выводу.&lltt;/p&ggtt;
&lltt;p&ggtt;Данные о клиенте могут быть точными. Прогноз продаж может быть актуальным. Финансовые показатели могут быть корректно определены. Тем не менее, агент может неправильно комбинировать эти входные данные, неправильно понимать контекст, в котором они используются, или непоследовательно применять бизнес-логику.&lltt;/p&ggtt;
&lltt;p&ggtt;Многие организации полагают, что управление заканчивается, как только будут установлены необходимые разрешения и подключены нужные источники данных. На самом деле эти элементы управления определяют только то, к какой информации агент может получить доступ. Они не определяют, правильно ли агент интерпретирует эту информацию.&lltt;/p&ggtt;
&lltt;p&ggtt;Традиционные системы управления никогда не были разработаны для решения этой проблемы. Разрешения не предотвращают неправильного толкования, отслеживание происхождения не гарантирует разумного обоснования, а документация не обеспечивает последовательного выполнения.&lltt;/p&ggtt;
&lltt;p&ggtt;Поскольку организации внедряют агентов во все большее число рабочих процессов, им нужен способ оценить не только то, что может видеть система ИИ, но и то, можно ли доверять выводам, которые она делает.&lltt;/p&ggtt;
&lltt;h3&ggtt;Аналитические группы становятся ИИ-рецензентами&lltt;/h3&ggtt;
&lltt;p&ggtt;Кто-то должен выявлять повторяющиеся сбои, сопоставлять результаты с реальностью и определять, повышается или снижается надежность с течением времени.&lltt;/p&ggtt;
&lltt;p&ggtt;Эта работа, естественно, ложится на плечи аналитиков.&lltt;/p&ggtt;
&lltt;p&ggtt;Они уже понимают, что лежит в основе данных, как определяются показатели, откуда берется бизнес-логика и как информация перемещается по организации. Не менее важно, что они понимают, как должен выглядеть правильный ответ и где наиболее вероятно возникновение ошибок.&lltt;/p&ggtt;
&lltt;p&ggtt;По мере того как ИИ становится все более важной частью доступа сотрудников к информации, аналитические группы берут на себя обязанности, которые все больше напоминают обеспечение качества. Они проверяют результаты, оценивают надежность, расследуют сбои, отслеживают согласованность и выявляют условия, которые заставляют агентов выдавать неверные результаты.&lltt;/p&ggtt;
&lltt;p&ggtt;Исторически сложилось так, что аналитические группы отвечали за то, чтобы дашборды и отчеты точно отражали бизнес. ИИ расширяет зону их ответственности. Тем же командам теперь предлагается оценить, дают ли агенты, вторые пилоты и аналитические системы на базе ИИ ответы, заслуживающие такого же уровня доверия.&lltt;/p&ggtt;
&lltt;h3&ggtt;Управление выходит за рамки данных&lltt;/h3&ggtt;
&lltt;p&ggtt;Большинство программ управления были построены вокруг контроля доступа к информации. Цель состояла в том, чтобы обеспечить сотрудникам доступ к необходимым им данным, сохраняя при этом согласованность, безопасность и доверие во всей организации.&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ ставит перед ними другую задачу. Агент может иметь доступ к нужным системам, нужным данным и нужным разрешениям, но при этом выдавать неполный, противоречивый или просто неправильный ответ.&lltt;/p&ggtt;
&lltt;p&ggtt;Это смещает фокус управления за пределы контроля доступа и управления данными. Организациям необходимо иметь представление о том, как ведут себя агенты, насколько последовательно они применяют бизнес-логику и остаются ли результаты, которые они генерируют, надежными с течением времени.&lltt;/p&ggtt;
&lltt;p&ggtt;Организация, которая не может доверять выводам, сделанным ее системами ИИ, не решила проблему управления просто потому, что базовые данные хорошо управляются. По мере того как агенты все глубже интегрируются в бизнес-процессы, надежность, валидация и контроль становятся не менее важными, чем прослеживаемость происхождения, права доступа и документация.&lltt;/p&ggtt;
&lltt;h3&ggtt;Переход от управления данными к управлению ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Профессия аналитика уже претерпела несколько серьезных трансформаций: от отчетности и бизнес-аналитики к самообслуживанию в аналитике и современным платформам данных. ИИ порождает еще одну трансформацию.&lltt;/p&ggtt;
&lltt;p&ggtt;По мере того как агенты все активнее участвуют в предоставлении сотрудникам доступа к информации, организациям становятся нужны люди, которые смогут оценивать надежность, расследовать сбои и определять, заслуживают ли доверия результаты работы ИИ. Аналитические команды хорошо подходят для выполнения этой задачи, поскольку они уже разбираются в данных, бизнес-логике и операционном контексте, лежащих в основе ответов, которые выдают эти системы.&lltt;/p&ggtt;
&lltt;p&ggtt;На протяжении многих лет их роль заключалась в том, чтобы помогать людям принимать более взвешенные решения на основе данных. Теперь они все чаще отвечают за то, чтобы системы ИИ могли делать то же самое.&lltt;/p&ggtt;]]></source>
<adate>27.08.2026</adate>
<dbid>235421</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент;;Big Data/Аналитика]]></tag>
</item>
<item>
<title><![CDATA[ИИ в доставке: почему искусственный интеллект перестает быть конкурентным преимуществом]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235419]]></link>
<description><![CDATA[Сегодня ИИ, а точнее машинное обучение (ML), все глубже встраивается в управление доставкой, помогая прогнозировать спрос и опоздания, рассчитывать сроки и оптимизировать процессы. Разбираемся, какие задачи последней мили уже можно передать алгоритмам и почему главным преимуществом логистических платформ становится не сам искусственный интеллект, а качество накопленных данных и возможности прогнозирования. От автоматизации к планированию и прогнозу Переход от простой автоматизации к прогнозному управлению доставкой происходил постепенно. По мере накопления данных и развития технологий логистические системы стали решать все более сложные задачи. Условно этот процесс можно разделить на два этапа. Цифровизация доставки. Этот этап связан прежде всего с автоматизацией рутинных операций. Системы научились распределять заказы между курьерами, строить маршруты, рассчитывать предполагаемое время доставки (ETA), объединять несколько заказов в одну цепочку и пересчитывать параметры при изменении ситуации. Это позволило сократить объем ручной работы и снизить зависимость процессов от диспетчера. Прогнозное управление. Здесь системы начинают не только обрабатывать текущую ситуацию, но и прогнозировать дальнейшее развитие событий. Например, модели машинного обучения анализируют историю заказов и оценивают будущий спрос в конкретной зоне и временном интервале. Это позволяет бизнесу заранее планировать количество курьеров и адаптировать ресурсы к ожидаемой нагрузке, что особенно важно для доставки последней мили, где спрос распределяется неравномерно. Количество заказов в пятницу вечером и утром буднего дня может отличаться в несколько раз. Если курьеров недостаточно, увеличивается нагрузка и растет риск опозданий. Если их слишком много, появляются простои, а стоимость выполнения одного заказа увеличивается. И ценность ML заключается не в самом прогнозе, а в возможности использовать его для принятия операционных решений. В частности, чем точнее компания понимает будущую нагрузку, тем эффективнее может распределять ресурсы и поддерживать баланс между стоимостью доставки и качеством сервиса. При этом прогнозирование дает бизнесу еще одну возможность: проверять решения до их внедрения. На основе накопленных данных можно моделировать различные сценарии работы доставки и смотреть, как изменение отдельных параметров повлияет на результат. Например, при расширении зоны доставки можно рассчитать необходимое количество курьеров, изменение их загрузки и возможное влияние нового радиуса на стоимость заказа и сроки. Такие тесты позволяют проверять гипотезы на виртуальной модели, не экспериментируя сразу на реальных заказах и клиентах. В результате управление доставкой постепенно переходит от реактивного подхода, когда бизнес исправляет уже возникшую проблему, к проактивному, когда последствия решения можно оценить заранее. Динамическая маршрутизация Еще одна важная задача в управлении последней милей связана с построением маршрутов. Здесь важно уточнить, что сама маршрутизация не является задачей искусственного интеллекта. В ее основе лежат алгоритмы оптимизации, а модели машинного обучения могут использоваться для более точного прогнозирования отдельных параметров, которые учитываются при расчетах. Современная система должна учитывать не только расстояние между точками, но и временные интервалы доставки, доступность и загрузку курьеров, зоны обслуживания, приоритеты заказов и другие ограничения. При этом исходные условия постоянно меняются. Поступают новые заказы, один курьер задерживается, другой освобождается раньше, меняется время готовности заказа. Поэтому маршрут не формируется один раз на всю смену. Система пересчитывает его по мере поступления новых данных и помогает перераспределять заказы между исполнителями. ML-модели могут дополнять этот процесс, например повышая точность расчета ожидаемого времени доставки (ETA). Для бизнеса результат такой оптимизации выражается в конкретных показателях, таких как сокращение простоев и лишнего пробега, более равномерная загрузка курьеров и соблюдение заявленных сроков доставки. Опоздания под контролем Еще одно направление, где машинное обучение может быть полезно, связано с прогнозированием опозданий. В традиционной модели проблема становится очевидной, когда курьер уже выбился из графика или клиент не получил заказ в обещанное время. ML-модели позволяют оценить риск задержки заранее, анализируя накопленные данные и текущие параметры доставки. Причины при этом могут быть совершенно разными. Одни возникают внутри самого процесса, когда, например, заказ поздно собрали, задержали на упаковке или не успели передать исполнителю. Другие возникают из-за форс мажорных обстоятельств и их невозможно полностью исключить организационными мерами. Например, на движение курьера могут повлиять авария, перекрытие дороги, проверка сотрудниками полиции и т. д. Задача алгоритмов в такой ситуации не в том, чтобы исключить все форс-мажоры, а в том, чтобы как можно раньше увидеть отклонение и минимизировать его последствия. Если система получает актуальные данные о ходе доставки, она может пересчитать ETA, изменить последовательность выполнения заказов или перераспределить часть нагрузки между исполнителями. В результате бизнес получает возможность управлять отклонением «на лету», еще до того, как оно превратится в опоздание для клиента. И чем раньше будет обнаружен риск, тем больше вариантов остается для корректировки ситуации и сохранения заявленного уровня сервиса. Где заканчивается работа алгоритма По мере развития технологий все больше операционных задач можно автоматизировать. Система способна распределять заказы между курьерами, пересчитывать маршруты, рассчитывать ETA и выявлять риск отклонения от заданных сроков. Однако это не означает, что управление доставкой можно полностью передать алгоритмам. Ключевые правила по-прежнему определяет бизнес. Компания решает, какие зоны обслуживать, какие временные интервалы предлагать клиентам, какие заказы считать приоритетными и какой уровень сервиса поддерживать. Алгоритмы работают внутри этих ограничений и помогают находить оптимальное решение в конкретной ситуации. При этом автоматизация постепенно освобождает сотрудников от значительной части рутинных операций. Им уже не нужно вручную распределять каждый заказ, постоянно перестраивать маршруты или отслеживать движение каждого курьера. Эти задачи система может выполнять самостоятельно в рамках заданных правил. В результате роль человека не сокращается, а меняется. Чем больше типовых операций берет на себя технология, тем больше внимания сотрудник может уделять задачам более высокого уровня, анализировать показатели, искать причины отклонений, проверять гипотезы, менять правила работы системы и продумывать новые сценарии. Алгоритмы в этом смысле не заменяют специалиста, а позволяют ему перейти от ручного управления процессом к работе с решениями и развитием доставки. Качество и полнота данных выходят на первый план Когда набор технологических возможностей у логистических платформ становится сопоставимым, различия начинают формироваться на уровне данных. Одна и та же модель может показывать разную точность в зависимости от того, на какой информации она обучалась и с какими сценариями сталкивалась раньше. При этом большой объем данных сам по себе не гарантирует хороший результат. Важны их качество, полнота, актуальность и разнообразие. Чем лучше данные отражают реальные процессы доставки и возможные отклонения, тем надежнее модель работает в новых ситуациях. Особенно заметно это при моделировании сценариев. Чтобы оценить последствия изменения зоны доставки, нагрузки или доступного курьерского ресурса, недостаточно знать только среднее количество заказов. Чем полнее система видит историю операций и взаимосвязь разных параметров, тем ближе результаты виртуального теста к тому, что произойдет в реальных условиях. И в отличие от отдельных технологий, накопленную историю операций невозможно быстро скопировать или приобрести. Она формируется со временем, поэтому именно данные постепенно становятся одним из ключевых активов логистических платформ и определяют качество работы ML-моделей. Что дальше Следующий этап развития технологий управления доставкой будет связан не столько с расширением функционала, сколько с повышением точности уже существующих решений. По мере накопления данных модели смогут лучше учитывать особенности спроса, загрузку и поведение курьеров, а также отклонения, возникающие в разных сценариях доставки. При этом полностью автономное управление последней милей пока остается скорее перспективой, ведь слишком многое здесь зависит от нестандартных ситуаций, которые требуют оценки и вмешательства человека. Поэтому задача технологий — не исключить его из процесса, а взять на себя расчеты и значительную часть операционных решений, сохранив за специалистом контроль в ситуациях, где алгоритма недостаточно. В результате развитие ML в логистике будет определяться не количеством новых функций с маркировкой ИИ, а тем, насколько точно технологии работают с реальными процессами и улучшают конечный результат. И ценность таких решений будет измеряться конкретными показателями, насколько они помогают сокращать опоздания и простои, поддерживать качество сервиса и снижать стоимость доставки. #IMAGE_235420#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Сегодня&nbsp;ИИ, а&nbsp;точнее машинное обучение (ML), все глубже встраивается в&nbsp;управление доставкой, помогая прогнозировать спрос и&nbsp;опоздания, рассчитывать сроки и&nbsp;оптимизировать процессы. Разбираемся, какие задачи последней мили уже можно передать алгоритмам и&nbsp;почему главным преимуществом логистических платформ становится не&nbsp;сам искусственный интеллект, а&nbsp;качество накопленных данных и&nbsp;возможности прогнозирования.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;От&nbsp;автоматизации к&nbsp;планированию и&nbsp;прогнозу&lltt;/h3&ggtt;
&lltt;p&ggtt;Переход от&nbsp;простой автоматизации к&nbsp;прогнозному управлению доставкой происходил постепенно. По&nbsp;мере накопления данных и&nbsp;развития технологий логистические системы стали решать все более сложные задачи. Условно этот процесс можно разделить на&nbsp;два этапа.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Цифровизация доставки.&lltt;/strong&ggtt; Этот этап связан прежде всего с&nbsp;автоматизацией рутинных операций. Системы научились распределять заказы между курьерами, строить маршруты, рассчитывать предполагаемое время доставки (ETA), объединять несколько заказов в&nbsp;одну цепочку и&nbsp;пересчитывать параметры при изменении ситуации. Это позволило сократить объем ручной работы и&nbsp;снизить зависимость процессов от&nbsp;диспетчера.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Прогнозное управление. &lltt;/strong&ggtt;Здесь системы начинают не&nbsp;только обрабатывать текущую ситуацию, но&nbsp;и&nbsp;прогнозировать дальнейшее развитие событий. Например, модели машинного обучения анализируют историю заказов и&nbsp;оценивают будущий спрос в&nbsp;конкретной зоне и&nbsp;временном интервале. Это позволяет бизнесу заранее планировать количество курьеров и&nbsp;адаптировать ресурсы к&nbsp;ожидаемой нагрузке, что особенно важно для доставки последней мили, где спрос распределяется неравномерно. Количество заказов в&nbsp;пятницу вечером и&nbsp;утром буднего дня может отличаться в&nbsp;несколько раз. Если курьеров недостаточно, увеличивается нагрузка и&nbsp;растет риск опозданий. Если их&nbsp;слишком много, появляются простои, а&nbsp;стоимость выполнения одного заказа увеличивается.&lltt;/p&ggtt;
&lltt;p&ggtt;И&nbsp;ценность&nbsp;ML заключается не&nbsp;в&nbsp;самом прогнозе, а&nbsp;в&nbsp;возможности использовать его для принятия операционных решений. В&nbsp;частности, чем точнее компания понимает будущую нагрузку, тем эффективнее может распределять ресурсы и&nbsp;поддерживать баланс между стоимостью доставки и&nbsp;качеством сервиса.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом прогнозирование дает бизнесу еще одну возможность: проверять решения до&nbsp;их&nbsp;внедрения. На&nbsp;основе накопленных данных можно моделировать различные сценарии работы доставки и&nbsp;смотреть, как изменение отдельных параметров повлияет на&nbsp;результат. Например, при расширении зоны доставки можно рассчитать необходимое количество курьеров, изменение их&nbsp;загрузки и&nbsp;возможное влияние нового радиуса на&nbsp;стоимость заказа и&nbsp;сроки.&lltt;/p&ggtt;
&lltt;p&ggtt;Такие тесты позволяют проверять гипотезы на&nbsp;виртуальной модели, не&nbsp;экспериментируя сразу на&nbsp;реальных заказах и&nbsp;клиентах. В&nbsp;результате управление доставкой постепенно переходит от&nbsp;реактивного подхода, когда бизнес исправляет уже возникшую проблему, к&nbsp;проактивному, когда последствия решения можно оценить заранее.&lltt;/p&ggtt;
&lltt;h3&ggtt;Динамическая маршрутизация&lltt;/h3&ggtt;
&lltt;p&ggtt;Еще одна важная задача в&nbsp;управлении последней милей связана с&nbsp;построением маршрутов. Здесь важно уточнить, что сама маршрутизация не&nbsp;является задачей искусственного интеллекта. В&nbsp;ее&nbsp;основе лежат алгоритмы оптимизации, а&nbsp;модели машинного обучения могут использоваться для более точного прогнозирования отдельных параметров, которые учитываются при расчетах.&lltt;/p&ggtt;
&lltt;p&ggtt;Современная система должна учитывать не&nbsp;только расстояние между точками, но&nbsp;и&nbsp;временные интервалы доставки, доступность и&nbsp;загрузку курьеров, зоны обслуживания, приоритеты заказов и&nbsp;другие ограничения. При этом исходные условия постоянно меняются. Поступают новые заказы, один курьер задерживается, другой освобождается раньше, меняется время готовности заказа.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому маршрут не&nbsp;формируется один раз на&nbsp;всю смену. Система пересчитывает его по&nbsp;мере поступления новых данных и&nbsp;помогает перераспределять заказы между исполнителями. &lltt;nobr&ggtt;ML-модели&lltt;/nobr&ggtt; могут дополнять этот процесс, например повышая точность расчета ожидаемого времени доставки (ETA).&lltt;/p&ggtt;
&lltt;p&ggtt;Для бизнеса результат такой оптимизации выражается в&nbsp;конкретных показателях, таких как сокращение простоев и&nbsp;лишнего пробега, более равномерная загрузка курьеров и&nbsp;соблюдение заявленных сроков доставки.&lltt;/p&ggtt;
&lltt;h3&ggtt;Опоздания под контролем&lltt;/h3&ggtt;
&lltt;p&ggtt;Еще одно направление, где машинное обучение может быть полезно, связано с&nbsp;прогнозированием опозданий. В&nbsp;традиционной модели проблема становится очевидной, когда курьер уже выбился из&nbsp;графика или клиент не&nbsp;получил заказ в&nbsp;обещанное время. &lltt;nobr&ggtt;ML-модели&lltt;/nobr&ggtt; позволяют оценить риск задержки заранее, анализируя накопленные данные и&nbsp;текущие параметры доставки. Причины при этом могут быть совершенно разными. Одни возникают внутри самого процесса, когда, например, заказ поздно собрали, задержали на&nbsp;упаковке или не&nbsp;успели передать исполнителю. Другие возникают из-за форс мажорных обстоятельств и&nbsp;их&nbsp;невозможно полностью исключить организационными мерами. Например, на&nbsp;движение курьера могут повлиять авария, перекрытие дороги, проверка сотрудниками полиции и&nbsp;т.&nbsp;д.&lltt;/p&ggtt;
&lltt;p&ggtt;Задача алгоритмов в&nbsp;такой ситуации не&nbsp;в&nbsp;том, чтобы исключить все форс-мажоры, а&nbsp;в&nbsp;том, чтобы как можно раньше увидеть отклонение и&nbsp;минимизировать его последствия. Если система получает актуальные данные о&nbsp;ходе доставки, она может пересчитать ETA, изменить последовательность выполнения заказов или перераспределить часть нагрузки между исполнителями.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;результате бизнес получает возможность управлять отклонением «на&nbsp;лету», еще до&nbsp;того, как оно превратится в&nbsp;опоздание для клиента. И&nbsp;чем раньше будет обнаружен риск, тем больше вариантов остается для корректировки ситуации и&nbsp;сохранения заявленного уровня сервиса.&lltt;/p&ggtt;
&lltt;h3&ggtt;Где заканчивается работа алгоритма&lltt;/h3&ggtt;
&lltt;p&ggtt;По&nbsp;мере развития технологий все больше операционных задач можно автоматизировать. Система способна распределять заказы между курьерами, пересчитывать маршруты, рассчитывать ETA и&nbsp;выявлять риск отклонения от&nbsp;заданных сроков. Однако это не&nbsp;означает, что управление доставкой можно полностью передать алгоритмам.&lltt;/p&ggtt;
&lltt;p&ggtt;Ключевые правила по-прежнему определяет бизнес. Компания решает, какие зоны обслуживать, какие временные интервалы предлагать клиентам, какие заказы считать приоритетными и&nbsp;какой уровень сервиса поддерживать. Алгоритмы работают внутри этих ограничений и&nbsp;помогают находить оптимальное решение в&nbsp;конкретной ситуации.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом автоматизация постепенно освобождает сотрудников от&nbsp;значительной части рутинных операций. Им&nbsp;уже не&nbsp;нужно вручную распределять каждый заказ, постоянно перестраивать маршруты или отслеживать движение каждого курьера. Эти задачи система может выполнять самостоятельно в&nbsp;рамках заданных правил.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;результате роль человека не&nbsp;сокращается, а&nbsp;меняется. Чем больше типовых операций берет на&nbsp;себя технология, тем больше внимания сотрудник может уделять задачам более высокого уровня, анализировать показатели, искать причины отклонений, проверять гипотезы, менять правила работы системы и&nbsp;продумывать новые сценарии. Алгоритмы в&nbsp;этом смысле не&nbsp;заменяют специалиста, а&nbsp;позволяют ему перейти от&nbsp;ручного управления процессом к&nbsp;работе с&nbsp;решениями и&nbsp;развитием доставки.&lltt;/p&ggtt;
&lltt;h3&ggtt;Качество и&nbsp;полнота данных выходят на&nbsp;первый план&lltt;/h3&ggtt;
&lltt;p&ggtt;Когда набор технологических возможностей у&nbsp;логистических платформ становится сопоставимым, различия начинают формироваться на&nbsp;уровне данных. Одна и&nbsp;та&nbsp;же модель может показывать разную точность в&nbsp;зависимости от&nbsp;того, на&nbsp;какой информации она обучалась и&nbsp;с&nbsp;какими сценариями сталкивалась раньше.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом большой объем данных сам по&nbsp;себе не&nbsp;гарантирует хороший результат. Важны их&nbsp;качество, полнота, актуальность и&nbsp;разнообразие. Чем лучше данные отражают реальные процессы доставки и&nbsp;возможные отклонения, тем надежнее модель работает в&nbsp;новых ситуациях.&lltt;/p&ggtt;
&lltt;p&ggtt;Особенно заметно это при моделировании сценариев. Чтобы оценить последствия изменения зоны доставки, нагрузки или доступного курьерского ресурса, недостаточно знать только среднее количество заказов. Чем полнее система видит историю операций и&nbsp;взаимосвязь разных параметров, тем ближе результаты виртуального теста к&nbsp;тому, что произойдет в&nbsp;реальных условиях.&lltt;/p&ggtt;
&lltt;p&ggtt;И&nbsp;в&nbsp;отличие от&nbsp;отдельных технологий, накопленную историю операций невозможно быстро скопировать или приобрести. Она формируется со&nbsp;временем, поэтому именно данные постепенно становятся одним из&nbsp;ключевых активов логистических платформ и&nbsp;определяют качество работы &lltt;nobr&ggtt;ML-моделей.&lltt;/nobr&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;Что дальше&lltt;/h3&ggtt;
&lltt;p&ggtt;Следующий этап развития технологий управления доставкой будет связан не&nbsp;столько с&nbsp;расширением функционала, сколько с&nbsp;повышением точности уже существующих решений. По&nbsp;мере накопления данных модели смогут лучше учитывать особенности спроса, загрузку и&nbsp;поведение курьеров, а&nbsp;также отклонения, возникающие в&nbsp;разных сценариях доставки.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом полностью автономное управление последней милей пока остается скорее перспективой, ведь слишком многое здесь зависит от&nbsp;нестандартных ситуаций, которые требуют оценки и&nbsp;вмешательства человека. Поэтому задача технологий&nbsp;— не&nbsp;исключить его из&nbsp;процесса, а&nbsp;взять на&nbsp;себя расчеты и&nbsp;значительную часть операционных решений, сохранив за&nbsp;специалистом контроль в&nbsp;ситуациях, где алгоритма недостаточно.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;результате развитие ML&nbsp;в логистике будет определяться не&nbsp;количеством новых функций с&nbsp;маркировкой&nbsp;ИИ, а&nbsp;тем, насколько точно технологии работают с&nbsp;реальными процессами и&nbsp;улучшают конечный результат. И&nbsp;ценность таких решений будет измеряться конкретными показателями, насколько они помогают сокращать опоздания и&nbsp;простои, поддерживать качество сервиса и&nbsp;снижать стоимость доставки.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235420#&lltt;/p&ggtt;]]></source>
<adate>27.08.2026</adate>
<dbid>235419</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/dbb/6o6tdkuz6shv5exuljhw59772tq4a8kv.jpg]]>
</images>
<imagesname><![CDATA[;;Денис Сокольников, технический директор компании &#8220;Мастер Деливери&#8221;   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Ошибки при цифровизации бизнеса, которые обходятся компаниям в миллионы]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235401]]></link>
<description><![CDATA[Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих интеграций, доработок, миграции данных и поддержки. Разбираем, где компании чаще всего ошибаются и что стоит проверить до старта проекта. Российский бизнес продолжает вкладывать в цифровизацию все больше денег. По предварительной оценке ИСИЭЗ НИУ ВШЭ, затраты на развитие цифровой экономики в России в 2025 году составили 7,1 трлн. рублей, это на 6,5% больше, чем годом ранее. Только внутренние затраты организаций на создание, распространение и использование цифровых технологий оцениваются в 4,5 трлн. рублей. За пять лет эта сумма выросла примерно вдвое. Причем 87,5% расходов крупных и средних организаций на цифровые технологии в 2024 году финансировались из собственных средств. В 2026 году расходы продолжают расти. В исследовании Apple Hills Digital, Selectel, Cloud.ru и VK Tech 65% опрошенных российских компаний сообщили, что увеличили ИТ-бюджеты: 48% подняли их в пределах 15%, еще 17% более чем на 15%. Исследование охватило 419 компаний из разных отраслей и 27 глубинных интервью с ИТ-руководителями. То есть вопрос уже не столько в том, готов ли российский бизнес тратить деньги на цифровизацию. Готов. Другой вопрос: сколько из этих денег действительно должно было быть потрачено. Компания может согласовать систему за 20 млн. рублей, успешно провести тендер и даже уложиться в смету. А потом обнаружить, что отдельно нужны интеграции, миграция данных, переделка нескольких внутренних сервисов, обучение сотрудников, дополнительная инфраструктура и команда, которая будет развивать продукт после запуска. Иногда проблема обнаруживается еще позже: система работает, но не дает эффекта, ради которого ее создавали. Это не редкий сценарий. Оператор ИТ-решений ОБИТ в 2025 году проанализировал более 100 входящих запросов от компаний среднего и крупного бизнеса с оборотом от 2 млрд. рублей. В выборку вошли промышленность, ритейл, ИТ и телеком, логистика. Почти в каждом втором случае компании приходили с запросом на повторный проект или доработку после предыдущего неудачного внедрения. Самыми частыми причинами стали недооценка стоимости владения, проблемы интеграции и неправильный выбор решения. Разберем ошибки, из-за которых цифровизация становится дороже, чем могла бы быть. Ошибка 1. Цифровизировать компанию отдельными проектами У компании появляется CRM. Потом ERP. Отдельно развивается мобильное приложение. Маркетинг подключает систему лояльности, HR работает в своей системе, финансы в своей. Где-то появляется BI, затем AI-сервис. Каждый проект можно защитить отдельно. У каждого есть заказчик, задача, бюджет. Иногда все они даже работают нормально. Через несколько лет обнаруживается другая проблема: весь этот набор плохо работает как единая система. Одни и те же данные хранятся в нескольких местах. У одного клиента разные ID. Часть информации синхронизируется автоматически, часть переносится вручную. Новая функция в мобильном приложении требует изменений в трех внутренних системах. Замена CRM неожиданно затрагивает продажи, приложение, аналитику и программу лояльности. Так появляется тот самый зоопарк ИТ-систем. В III Всероссийском опросе по цифровой трансформации Comindware, Artezio и РУССОФТ 60% участников сообщили, что проводят отдельные проекты цифровизации, но не имеют общей стратегии. Еще 18% сказали, что такой стратегии нет вообще. 80% компаний используют разрозненные интеграции между информационными системами, а в единой цифровой среде работают только 12%. У этой проблемы уже вполне материальные последствия. К2Тех опросил более 300 руководителей и ИТ-специалистов средних и крупных российских компаний. 68% респондентов сообщили, что из-за зоопарка решений не могут получить целостную картину данных. 47% сталкиваются с высокими скрытыми затратами на поддержку разрозненных систем, еще 33% говорят о техническом долге, который мешает развитию. Проблема тут не в количестве программ. У крупной компании их и не может быть две или три. Вопрос в том, как устроены связи между ними и понимает ли компания, каким должен быть ее ИТ-ландшафт через несколько лет. Допустим, отделу продаж действительно нужна новая система. Помимо вопроса «Решает ли она нашу задачу?» стоит задать еще один: «Что произойдет со всей инфраструктурой после ее появления?». Новая система может дать локальный эффект сейчас, но заметно увеличить стоимость любых изменений потом. Что проверить до следующего внедрения? Нужно хотя бы на верхнем уровне понимать: 	 какие системы новый продукт заменяет, а какие дополняет; 	 какие данные он будет получать и передавать; 	 где будет храниться мастер-версия данных; 	 сколько новых интеграций появится; 	 не придется ли хранить еще одну копию уже существующей информации; 	 от каких систем и подрядчиков новый продукт будет зависеть; 	 можно ли будет заменить его через несколько лет без перестройки половины ИТ-ландшафта. Здесь полезна архитектурная схема не только текущего состояния, но и целевого. Иначе цифровой контур формируется не потому, что его кто-то таким спроектировал, а потому что проекты запускались один за другим. Ошибка 2. Не решить заранее, какой результат должен дать проект «Запустить CRM до декабря» звучит как цель. «Разработать приложение» тоже. Как и «автоматизировать оформление заказа», «внедрить AI» или «перевести сотрудников в новую систему». Только все это цели проекта, а не бизнеса. Русская школа управления в 2025 году опросила руководителей и HR-специалистов российских компаний. 55% назвали одним из главных барьеров цифровизации высокую стоимость внедрения. Но на втором месте оказался гораздо более интересный ответ: 35% не понимают эффекта от цифровых решений. Еще 29% назвали сопротивление сотрудников, 27% недостаток компетенций у руководителей, 26% сложности ИТ-инфраструктуры. Проблема становится заметна после релиза. Проект завершили. Система работает. Как понять, что несколько миллионов были потрачены не зря? Если до начала работы компания не измеряла текущий процесс, ответа может и не быть. Например, смысл нового личного кабинета может быть не в самом факте его появления, а в том, чтобы больше клиентов решали свои вопросы без обращения в поддержку. У автоматизации документооборота задача может состоять в сокращении срока согласования с пяти дней до одного. У нового внутреннего сервиса — в том, чтобы операция, которая занимала у сотрудника 20 минут, выполнялась за пять. А у мобильного приложения — не обязательно в росте установок. Возможно, важнее доля пользователей, дошедших до покупки или снижение нагрузки на офлайн-канал. Поэтому еще до разработки хорошо зафиксировать три вещи: что происходит сейчас. Например, обработка одной заявки занимает 40 минут. Что хотим получить. Например, 15 минут. Как и когда будем это измерять. Без первой точки сравнения можно получить красивый продукт, хорошие отзывы внутри команды и ни одного доказательства, что бизнес стал работать лучше. Еще хуже, когда KPI цифровизации выбирается из технических показателей. Количество функций, число релизов или процент готовности проекта мало говорят о результате для компании. Система может быть написана без критических ошибок, запущена в срок и полностью соответствовать техническому заданию. И одновременно быть неудачным бизнес-проектом. Ошибка 3. Считать бюджет внедрения, а не реальную стоимость владения Это одна из самых приземленных ошибок, потому что ее легко увидеть в деньгах. В исследовании ОБИТ 61% проблемных проектов были связаны с недооценкой стоимости владения ИТ-решением. Компании не полностью учитывали стоимость интеграции, дальнейшего обслуживания и обучения сотрудников. В 48% случаев возникали сложности интеграции с существующей инфраструктурой, в 35% выбранное решение не соответствовало фактическим требованиям бизнеса. По оценке ОБИТ, доработки и исправления после неудачного внедрения могут потребовать еще 10-30% от первоначального бюджета. В отдельных случаях перезапуск проекта требует вложений, сопоставимых с первоначальными или даже вдвое большими. Если компания говорит, что внедрение стоит 15 млн. рублей, стоит уточнить, что именно входит в эти 15 млн.: 	Только разработка? 	Разработка и лицензии? 	А интеграции? 	Миграция данных? 	Изменения в действующих системах? 	Инфраструктура? 	Информационная безопасность? 	Переходный период, когда старое и новое решение работают параллельно? 	 Обучение? 	Поддержка? 	Развитие продукта через год? 	Стоимость сотрудников заказчика, которые будут участвовать в проекте? Цифровой продукт редко заканчивает потреблять деньги в день релиза. Поэтому сравнивать варианты только по стоимости разработки не очень полезно. Условный проект может выглядеть так: 	15 млн. рублей стоит разработка и внедрение; 	еще 2 млн. потребовали доработки интеграций; 	1,5 млн. ушли на подготовку и миграцию данных из смежных ИС; 	1 млн. на переход и обучение; 	2,5 млн. на поддержку и доработки первого года. Мы получили уже 22 млн. вместо 15 млн. Это не среднерыночный расчет и не прогноз для любого проекта, а просто иллюстрация того, насколько по-разному могут выглядеть «стоимость разработки» и «сколько бизнес реально потратил на изменение». Поэтому разумнее считать совокупную стоимость владения (ТСО) хотя бы на несколько лет. Иногда более дорогой продукт на этапе покупки оказывается дешевле в эксплуатации. А иногда дешевое коробочное решение через два года обрастает таким количеством доработок, что стоимость его поддержки становится отдельной строкой бюджета. Ошибка 4. Сначала выбрать технологию, а потом искать ей задачу Еще несколько лет назад бизнес хотел блокчейн. Сейчас хочет AI. Между ними были супераппы, low-code, микросервисы и много чего еще. Фраза «нам нужно внедрить AI» сама по себе ничего не говорит о том, что компании нужно сделать. То же относится к CRM, ERP, мобильному приложению или отечественной замене зарубежной системы. В анализе ОБИТ 35% проблемных внедрений были связаны с тем, что выбранное решение не соответствовало фактическим бизнес-требованиям. В числе причин компания называет недостаточное тестирование продукта до внедрения и незрелость самого решения. Отдельно эта проблема проявилась во время импортозамещения. Т1 и РУССОФТ исследовали 78 российских компаний с фокусом на крупный бизнес. Среди серьезных препятствий при переходе на отечественные системы компании называли высокую стоимость новых продуктов, проблемы совместимости с текущей инфраструктурой и недостаточную функциональную зрелость части российских аналогов. Одновременно 54% респондентов уже включают миграцию на российские технологии в стратегию развития собственных информационных систем. Только 14% рассматривают импортозамещение исключительно как вынужденную реакцию на внешние обстоятельства. В исследовании РБК и Ростелекома среди 308 руководителей российских компаний 36,7% назвали одной из проблем импортозамещения интеграцию отечественных решений с существующими системами, 32,5% долгие сроки внедрения. То есть задача «заменим зарубежную систему на российскую» сама по себе тоже может оказаться слишком узкой. Если компания все равно вынуждена менять критичный кусок ИТ-ландшафта, логично сначала посмотреть, нужен ли ей точный цифровой аналог старого процесса. Возможно, за годы работы изменился сам бизнес, появились лишние этапы, а некоторые функции старого продукта уже никому не нужны. Поэтому порядок лучше разворачивать следующим образом: сначала проблема → затем целевой процесс → требования → ограничения текущей архитектуры → возможные решения → выбор между готовым продуктом, доработкой и собственной разработкой Не обязательно каждый раз писать новую систему. И не обязательно сразу раскатывать выбранное решение на всю компанию. Если технология новая, интеграций много, а процессы критичные, пилот часто дешевле большого запуска. На ограниченной группе пользователей можно проверить реальные сценарии, производительность, интеграции и ограничения продукта. Это намного лучше, чем обнаружить их после миграции нескольких тысяч сотрудников. После анализа проблемных проектов ОБИТ тоже рекомендует предварительное тестирование и пилотирование, а миграцию критичных систем проводить поэтапно. Ошибка 5. Автоматизировать старый процесс, не задаваясь вопросом, нужен ли он таким вообще Когда компания готовит требования к новой системе, самый простой способ их получить — описать текущую работу. Есть пять этапов согласования? Переносим пять этапов в систему. Сотрудник четыре раза вводит одни и те же данные? Сделаем ему четыре красивые формы. Раньше документ отправляли на почту руководителю? Теперь будет кнопка «Отправить руководителю». Формально это цифровизация. Но процесс остался прежним. Здесь есть показательный пример из финансового сектора. В исследовании Ассоциации ФинТех при участии К2Тех 70% компаний сообщили, что в ходе трансформации ИТ-архитектуры провели аудит и пересмотр значимой части бизнес-процессов. Более 80% организаций отметили положительные эффекты такой перестройки: повышение эффективности, большую гибкость, создание задела для развития и работу с накопленным техническим долгом. Конечно, финансовый сектор нельзя автоматически переносить на весь российский бизнес. Но сам подход показателен: смена технологий становится поводом пересмотреть процесс, а не просто перенести его в новую систему. · До автоматизации полезно буквально нарисовать процесс как есть: что сейчас делает клиент, сотрудник и система. Затем нарисовать должно быть. И к каждому действию задать неприятный вопрос: 	А зачем оно вообще существует? 	 Почему заявка должна пройти три согласования? 	 Почему данные повторно вводятся руками? 	 Почему менеджер переносит информацию из одной программы в другую? 	 Почему человек принимает решение, которое полностью определяется набором формальных правил? 	 Почему клиент должен заполнять то, что компания уже о нем знает? 	 Какие этапы после цифровизации должны не ускориться, а исчезнуть? 	 Если раньше сотрудник заполнял Excel, а теперь заполняет новую корпоративную систему и на всякий случай продолжает вести тот же Excel, то бизнес не очень много выиграл. Ошибка 6. Недооценить интеграции, данные, безопасность и аварийные сценарии На презентации новый продукт обычно выглядит отдельно. Есть красивые экраны приложения, новый личный кабинет, CRM или внутренняя платформа. В реальной ИТ-инфраструктуре ничего отдельно не существует. Мобильному приложению нужно получить пользователя из одной системы, остаток из другой, цены из третьей, историю заказов из четвертой, принять платеж через внешнего провайдера и вернуть результат в ERP. И здесь начинается та часть проекта, которую бизнес не всегда видит на старте. У ОБИТ сложности интеграции были причиной проблем в 48% проанализированных проектов. Компания отмечает, что они приводили не только к дополнительным затратам, но и к рискам простоев бизнес-процессов. У Comindware 80% участников исследования работают с разрозненными интеграциями. У К2Тех 74% опрошенных видят решение проблемы несогласованных данных в сквозной интеграции систем и создании единого контура управления данными. Интересно, что бизнес не обязательно хочет выбрасывать существующий ИТ-ландшафт: 46% компаний называют приоритетом оптимизацию текущих систем без масштабных инвестиций. То есть еще до интерфейсов полезно нарисовать карту интеграций и данных: 	Откуда приходит каждый тип информации? 	 Какая система считается источником истины? 	 Кому разрешено менять данные? 	 Как часто они синхронизируются? 	 Что происходит, если две системы содержат разные значения? 	 Что будет, если внешнее API не отвечает? 	 А если запрос был отправлен дважды? 	 Как система восстановит операцию после сбоя? 	 Кто увидит ошибку и кто будет ее разбирать? 	 Вот эти вопросы часто влияют на стоимость проекта сильнее, чем количество экранов. Отдельно стоит проверить, что будет при сбоях. Цифровизация делает бизнес быстрее, но заодно сильнее связывает операции с технологиями. Если раньше недоступность одного сервиса мешала части сотрудников, после автоматизации сбой может остановить всю цепочку. КРОК в исследовании 70 ИТ-руководителей крупных и крупнейших российских компаний отметил, что в 2025 году заметно вырос фокус на резервировании и отказоустойчивости. Среди инфраструктурных проблем 36% респондентов называли отсутствие резервного ЦОДа, необходимость зеркалировать резервные копии, дублировать сети и сервисы. Поэтому до запуска стоит проверять не только happy path, где все работает как задумано. 	Что произойдет, если платежный сервис недоступен два часа? 	 Если упала CRM? 	 Если внешняя система отвечает десять секунд вместо одной? 	 Если в Black Friday нагрузка выросла в несколько раз? 	 Если мобильное приложение работает, а один из внутренних сервисов нет? Хорошая архитектура предусматривает не только полную работоспособность, но и управляемую деградацию. Пользователь по возможности должен сохранить хотя бы часть сценариев, а бизнес понимать, как система вернется в штатный режим. И безопасность нельзя добавлять последним пунктом перед релизом. Исследования показали, что крупные российские компании назвали соответствие высоким требованиям информационной безопасности главным критерием выбора ИТ-партнера, а кибербезопасность остается одним из основных направлений ИТ-инвестиций российского бизнеса. Но безопасность влияет не только на выбор подрядчика. Она может заметно поменять архитектуру, способ хранения данных, процессы авторизации, интеграции, инфраструктуру и стоимость разработки. Если требования ИБ появляются после того, как продукт уже почти готов, часть работы иногда приходится делать заново. Ошибка 7. Решить, что legacy обязательно нужно переписать Старому коду легко назначить виноватого. Если релизы идут медленно, разработчики жалуются на монолит, документации мало и вокруг системы накопилось много странных решений, появляется естественное желание: давайте перепишем все нормально. Иногда это правда правильный вариант. Но возраст системы сам по себе еще не бизнес-проблема. Опираясь на данные вышеуказанных исследований, 78% российских компаний, использующих облачные технологии, сохраняют legacy-системы. У 14% legacy составляет больше половины ИТ-портфеля. 46% участников называют одним из главных приоритетов оптимизацию существующих систем без масштабных инвестиций. В исследовании КРОК более 30% респондентов говорили о необходимости обновления оборудования и работы с legacy. Тут нет противоречия. Потому что legacy можно модернизировать по-разному. Допустим, старое ядро работает стабильно, содержит критическую бизнес-логику и справляется с нагрузкой. Но у него плохие интеграции. Тогда иногда разумнее оставить ядро и построить нормальный API-слой. Если тормозит один модуль, можно вынести его. Если система мешает независимым релизам, разделить наиболее проблемные компоненты. Если высокая стоимость поддержки связана с конкретной частью кода, провести рефакторинг именно там. Полная замена тоже возможна, но тогда бизнесу стоит понимать, что именно он покупает за стоимость переписывания: 	Будут быстрее запускаться функции? 	 Снизится стоимость поддержки? 	 Уйдут ограничения по нагрузке? 	 Станет проще находить разработчиков? 	 Исчезнут риски безопасности? 	 Можно будет подключать новые продукты? 	 Если на эти вопросы нет ответа, то проект под названием «перепишем все с нуля» легко превращается в очень дорогой способ получить почти то же самое. Особенно рискован big bang, когда старая система выключается, а новая должна одномоментно заменить все функции. Чем критичнее продукт, тем разумнее рассматривать поэтапную миграцию, когда часть функций или пользователей переводится последовательно и у команды остается возможность проверить систему на реальной работе. Иногда хороший результат технического аудита звучит не как «вам нужно 30 млн. рублей на новый продукт», а как «эту часть вообще не трогаем». Ошибка 8. Сначала внедрить AI, а потом разбираться с данными С AI проблема качества данных стала гораздо заметнее. Можно купить хороший инструмент прогнозирования, подключить BI, внедрить AI-ассистента или модель для автоматического принятия решений. Но если клиент хранится в трех системах под разными идентификаторами, справочники не совпадают, часть данных вводится вручную, а происхождение цифры в отчете никто не может объяснить, новая технология это не исправит. Она будет работать с тем, что ей дали. 51% компаний сохраняют внедрение AI среди ключевых приоритетов. Одновременно 68% респондентов говорят, что не получают целостной картины данных из-за разрозненного ИТ-ландшафта. В исследовании КРОК качество входных данных и отсутствие формальных регламентов названы среди факторов, которые мешают масштабированию технологических инициатив. Отдельно Strategy Partners исследовала работу с данными на российских промышленных предприятиях. В 56% компаний ручной ввод остается распространенным способом сбора данных. Только у четверти есть отдельное подразделение для работы с данными, еще у 36% выделен специалист по аналитике. Среди основных барьеров компании называют нехватку людей, компетенций и технических ресурсов. Это особенно важный момент для AI-проектов, потому что там качество исходной информации напрямую связано с качеством результата. До запуска стоит разобраться: 	 где хранится мастер-версия данных; 	 кто является их владельцем; 	 кто отвечает за качество; 	 есть ли дубли; 	 насколько информация полная и свежая; 	 как изменяются справочники; 	 можно ли понять происхождение конкретного значения; 	 какие данные вообще нельзя использовать в выбранном сценарии; 	 кто отвечает за ошибку, если автоматическая система приняла неправильное решение. Если у компании три разных значения одного показателя в трех системах, AI не создаст магическим образом правильное. Есть риск, что появится просто четвертый вариант. Ошибка 9. Считать, что цифровизация закончилась в день релиза Команда несколько месяцев или лет делает систему. Проходит приемка. Проект закрывают. На презентации появляется зеленый статус «внедрено». А сотрудники продолжают пользоваться Excel. Или переносят часть данных вручную. Или нашли способ обходить новый процесс, потому что старый быстрее. Или система используется, но время выполнения операции не уменьшилось. Технический запуск еще не означает, что произошло изменение бизнеса. В исследовании Т1 и РУССОФТ сопротивление сотрудников новым системам отметили 79,5% представителей крупных компаний. В исследовании Русской школы управления эту проблему отметили 29% респондентов. Разница в цифрах большая, потому что исследования изучали разные выборки и сценарии. Т1 и РУССОФТ рассматривали крупный бизнес и переход на отечественные системы, РШУ шире спрашивала о цифровизации управленческих процессов. Но обе работы показывают, что технология сама по себе не заставляет людей изменить способ работы. И здесь легко дать неправильный совет: «нужно лучше обучать сотрудников». Обучение нужно, но сначала стоит проверить сам продукт. Если раньше сотрудник выполнял пять действий, а после внедрения системы делает восемь, сопротивление не обязательно связано с консерватизмом. Если новая программа работает медленнее старой, человек будет искать обходной путь. Если данные нужно вводить и в старую, и в новую систему, он продолжит вести Excel. Если продукт не учитывает реальные исключения из процесса, сотрудники быстро построят вокруг него собственный параллельный процесс в почте и мессенджерах. Поэтому после релиза важно измерять не только технические показатели. Да, нужны uptime, количество ошибок и SLA. Но параллельно стоит смотреть: 	 какая доля сотрудников действительно работает в новой системе; 	 какую часть процесса они проходят в ней полностью; 	 сколько ручных операций осталось; 	 сколько времени занимает задача; 	 изменилась ли частота ошибок; 	 не продолжают ли сотрудники вести параллельные таблицы; 	 как часто им приходится обходить систему; 	 изменился ли бизнес-показатель, ради которого все начиналось. Цифровизация заканчивается тогда, когда изменился процесс и появился измеримый результат для бизнеса. Именно поэтому сложный цифровой продукт почти никогда нельзя воспринимать как объект, который один раз разработали и забыли. Меняется бизнес, появляются новые требования, интеграции, регуляторика, нагрузка. Продукту приходится меняться вместе с ними. Что проверить до того, как утвердить бюджет Ошибки из этой статьи могут выглядеть очень разными, но большинство можно обнаружить до начала большой разработки. Перед запуском проекта полезно честно ответить хотя бы на несколько групп вопросов. Бизнес: 	Какую проблему мы решаем? 	 Сколько она стоит компании сейчас? 	 Какой показатель должен измениться после запуска? 	 Знаем ли мы его текущее значение? 	 Как поймем через полгода, что проект сработал? Процесс: 	Нужно ли вообще автоматизировать процесс в его нынешнем виде? 	 Какие этапы можно убрать? 	 Какие действия должен перестать делать человек? 	 Не создаем ли мы цифровую копию старой бюрократии? ИТ-ландшафт: 	Какие системы затронет новый продукт? 	 Сколько интеграций потребуется? 	 Где находится источник истины для каждого типа данных? 	 Что придется доработать в существующих системах? 	 Что будет, если одна из интеграций перестанет работать? Деньги: 	Посчитана стоимость разработки или полная стоимость владения? 	 Учтены ли миграция данных, инфраструктура, интеграции и обучение? 	 Как будет финансироваться поддержка? 	 Кто будет развивать систему после первого релиза? 	 Сколько решение будет стоить компании через три года? Технология: 	Почему выбран именно этот класс решений? 	 Смотрели ли мы альтернативы? 	 Нужна ли собственная разработка? 	 Можно ли доработать существующий продукт? 	 Нужно ли действительно полностью переписывать legacy? 	 Можно ли сначала проверить гипотезу на пилоте? Риски: 	Что произойдет при пиковой нагрузке? 	 Как работает система при частичной недоступности сервисов? 	 Есть ли план поэтапной миграции и возможность отката? 	 Учтены ли требования информационной безопасности в архитектуре, а не только перед релизом? 	 Какие данные система получает и можно ли им доверять? Пользователи: 	Участвовали ли реальные сотрудники или клиенты в проверке сценариев? 	 Станет ли им проще выполнять задачу? 	 Не придется ли пользоваться старой и новой системой одновременно? 	 Как мы измерим реальное использование продукта после запуска? Если на значительную часть этих вопросов пока нет ответа, возможно, компании еще рано проводить тендер на разработку. Иногда первым этапом должен стать не дизайн приложения и не оценка программистами количества часов, а обследование: разбор процессов, архитектуры, интеграций, данных, технического долга, требований безопасности и экономики будущего решения. Такой этап тоже стоит денег. Но его задача как раз в том, чтобы не выяснять самые дорогие особенности проекта тогда, когда контракт уже подписан, команда работает, а половина бюджета потрачена. Цифровизация обходится дорого не только тогда, когда разработчики ошибаются в коде. Гораздо больше денег можно потерять раньше: выбрать не ту задачу, не посчитать владение, добавить еще одну систему в уже сложный ландшафт или автоматизировать процесс, который стоило сначала переделать. И чем крупнее проект, тем дороже становится вопрос, который бизнес не задал себе на старте. #IMAGE_235402#]]></description>
<source><![CDATA[&lltt;p&ggtt;Цифровизация должна сокращать издержки и&nbsp;ускорять бизнес, но&nbsp;иногда происходит наоборот: новая система требует дорогих интеграций, доработок, миграции данных и&nbsp;поддержки. Разбираем, где компании чаще всего ошибаются и&nbsp;что стоит проверить до&nbsp;старта проекта.&lltt;/p&ggtt;
&lltt;p&ggtt;Российский бизнес продолжает вкладывать в&nbsp;цифровизацию все больше денег. По&nbsp;предварительной &lltt;a href="http://issek.hse.ru/mirror/pubs/share/1132489160.pdf"&ggtt;оценке&lltt;/a&ggtt; ИСИЭЗ НИУ ВШЭ, затраты на&nbsp;развитие цифровой экономики в&nbsp;России в&nbsp;2025 году составили 7,1&nbsp;трлн. рублей, это на&nbsp;6,5% больше, чем годом ранее. Только внутренние затраты организаций на&nbsp;создание, распространение и&nbsp;использование цифровых технологий оцениваются в&nbsp;4,5&nbsp;трлн. рублей. За&nbsp;пять лет эта сумма выросла примерно вдвое. Причем&nbsp;87,5% расходов крупных и&nbsp;средних организаций на&nbsp;цифровые технологии в&nbsp;2024 году финансировались из&nbsp;собственных средств.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;2026 году расходы продолжают расти. В&nbsp;исследовании Apple Hills Digital, Selectel, Cloud.ru и&nbsp;VK&nbsp;Tech&nbsp;65% опрошенных российских компаний &lltt;a href="https://apple-hills.com/ru/reports/cloud-consumption-trends-2025"&ggtt;сообщили&lltt;/a&ggtt;, что увеличили ИТ-бюджеты: 48% подняли их&nbsp;в&nbsp;пределах&nbsp;15%, еще&nbsp;17% более чем на&nbsp;15%. Исследование охватило 419 компаний из&nbsp;разных отраслей и&nbsp;27&nbsp;глубинных интервью с&nbsp;ИТ-руководителями.&lltt;/p&ggtt;
&lltt;p&ggtt;То&nbsp;есть вопрос уже не&nbsp;столько в&nbsp;том, готов&nbsp;ли российский бизнес тратить деньги на&nbsp;цифровизацию. Готов. Другой вопрос: сколько из&nbsp;этих денег действительно должно было быть потрачено.&lltt;/p&ggtt;
&lltt;p&ggtt;Компания может согласовать систему за&nbsp;20&nbsp;млн. рублей, успешно провести тендер и&nbsp;даже уложиться в&nbsp;смету. А&nbsp;потом обнаружить, что отдельно нужны интеграции, миграция данных, переделка нескольких внутренних сервисов, обучение сотрудников, дополнительная инфраструктура и&nbsp;команда, которая будет развивать продукт после запуска.&lltt;/p&ggtt;
&lltt;p&ggtt;Иногда проблема обнаруживается еще позже: система работает, но&nbsp;не&nbsp;дает эффекта, ради которого ее&nbsp;создавали.&lltt;/p&ggtt;
&lltt;p&ggtt;Это не&nbsp;редкий сценарий. Оператор ИТ-решений ОБИТ в&nbsp;2025 году &lltt;a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/"&ggtt;проанализировал&lltt;/a&ggtt; более 100 входящих запросов от&nbsp;компаний среднего и&nbsp;крупного бизнеса с&nbsp;оборотом от&nbsp;2&nbsp;млрд. рублей. В&nbsp;выборку вошли промышленность, ритейл, ИТ&nbsp;и&nbsp;телеком, логистика. Почти в&nbsp;каждом втором случае компании приходили с&nbsp;запросом на&nbsp;повторный проект или доработку после предыдущего неудачного внедрения. Самыми частыми причинами стали недооценка стоимости владения, проблемы интеграции и&nbsp;неправильный выбор решения.&lltt;/p&ggtt;
&lltt;p&ggtt;Разберем ошибки, из-за которых цифровизация становится дороже, чем могла&nbsp;бы быть.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;1. Цифровизировать компанию отдельными проектами&lltt;/h2&ggtt;
&lltt;p&ggtt;У&nbsp;компании появляется CRM. Потом ERP. Отдельно развивается мобильное приложение. Маркетинг подключает систему лояльности, HR&nbsp;работает в&nbsp;своей системе, финансы в&nbsp;своей. Где-то появляется&nbsp;BI, затем AI-сервис. Каждый проект можно защитить отдельно. У&nbsp;каждого есть заказчик, задача, бюджет. Иногда все они даже работают нормально.&lltt;/p&ggtt;
&lltt;p&ggtt;Через несколько лет обнаруживается другая проблема: весь этот набор плохо работает как единая система. Одни и&nbsp;те&nbsp;же данные хранятся в&nbsp;нескольких местах. У&nbsp;одного клиента разные ID. Часть информации синхронизируется автоматически, часть переносится вручную. Новая функция в&nbsp;мобильном приложении требует изменений в&nbsp;трех внутренних системах. Замена CRM неожиданно затрагивает продажи, приложение, аналитику и&nbsp;программу лояльности. Так появляется тот самый зоопарк ИТ-систем.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;III Всероссийском опросе по&nbsp;цифровой трансформации Comindware, Artezio и&nbsp;РУССОФТ&nbsp;60% участников &lltt;a href="https://www.comindware.ru/blog/investitsii-v-tsifrovizatsiyu-v-rossii-vyrosli-v-poltora-raza/amp/"&ggtt;сообщили&lltt;/a&ggtt;, что проводят отдельные проекты цифровизации, но&nbsp;не&nbsp;имеют общей стратегии. Еще&nbsp;18% сказали, что такой стратегии нет вообще.&nbsp;80% компаний используют разрозненные интеграции между информационными системами, а&nbsp;в&nbsp;единой цифровой среде работают только 12%.&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;этой проблемы уже вполне материальные последствия. К2Тех &lltt;a href="https://k2.tech/press_releases/opros-k2teh-68-kompanij-ne-vidyat-czelostnuyu-kartinu-biznesa-iz-za-zooparka-it-sistem/"&ggtt;опросил&lltt;/a&ggtt; более 300 руководителей и&nbsp;ИТ-специалистов средних и&nbsp;крупных российских компаний.&nbsp;68% респондентов сообщили, что из-за зоопарка решений не&nbsp;могут получить целостную картину данных.&nbsp;47% сталкиваются с&nbsp;высокими скрытыми затратами на&nbsp;поддержку разрозненных систем, еще&nbsp;33% говорят о&nbsp;техническом долге, который мешает развитию.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема тут не&nbsp;в&nbsp;количестве программ. У&nbsp;крупной компании их&nbsp;и&nbsp;не&nbsp;может быть две или три. Вопрос в&nbsp;том, как устроены связи между ними и&nbsp;понимает&nbsp;ли компания, каким должен быть ее&nbsp;ИТ-ландшафт через несколько лет.&lltt;/p&ggtt;
&lltt;p&ggtt;Допустим, отделу продаж действительно нужна новая система. Помимо вопроса «Решает&nbsp;ли она нашу задачу?» стоит задать еще один: «Что произойдет со&nbsp;всей инфраструктурой после ее&nbsp;появления?». Новая система может дать локальный эффект сейчас, но&nbsp;заметно увеличить стоимость любых изменений потом.&lltt;/p&ggtt;
&lltt;p&ggtt;Что проверить до&nbsp;следующего внедрения? Нужно хотя&nbsp;бы на&nbsp;верхнем уровне понимать:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; какие системы новый продукт заменяет, а&nbsp;какие дополняет;&lltt;/li&ggtt;
	&lltt;li&ggtt; какие данные он&nbsp;будет получать и&nbsp;передавать;&lltt;/li&ggtt;
	&lltt;li&ggtt; где будет храниться мастер-версия данных;&lltt;/li&ggtt;
	&lltt;li&ggtt; сколько новых интеграций появится;&lltt;/li&ggtt;
	&lltt;li&ggtt; не&nbsp;придется&nbsp;ли хранить еще одну копию уже существующей информации;&lltt;/li&ggtt;
	&lltt;li&ggtt; от&nbsp;каких систем и&nbsp;подрядчиков новый продукт будет зависеть;&lltt;/li&ggtt;
	&lltt;li&ggtt; можно&nbsp;ли будет заменить его через несколько лет без перестройки половины ИТ-ландшафта.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Здесь полезна архитектурная схема не&nbsp;только текущего состояния, но&nbsp;и&nbsp;целевого. Иначе цифровой контур формируется не&nbsp;потому, что его кто-то таким спроектировал, а&nbsp;потому что проекты запускались один за&nbsp;другим.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;2. Не&nbsp;решить заранее, какой результат должен дать проект&lltt;/h2&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;«&lltt;/strong&ggtt;Запустить CRM до&nbsp;декабря» звучит как цель. «Разработать приложение» тоже. Как и&nbsp;«автоматизировать оформление заказа», «внедрить&nbsp;AI» или «перевести сотрудников в&nbsp;новую систему». Только все это цели проекта, а&nbsp;не&nbsp;бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;Русская школа управления в&nbsp;2025 году &lltt;a href="https://uprav.ru/blog/55-rukovoditeley-nazyvayut-vysokuyu-stoimost-glavnym-barerom-tsifrovizatsii-biznesa/"&ggtt;опросила&lltt;/a&ggtt; руководителей и&nbsp;HR-специалистов российских компаний.&nbsp;55% назвали одним из&nbsp;главных барьеров цифровизации высокую стоимость внедрения. Но&nbsp;на&nbsp;втором месте оказался гораздо более интересный ответ: &lltt;em&ggtt;35% не&nbsp;понимают эффекта от&nbsp;цифровых решений&lltt;/em&ggtt;. Еще&nbsp;29% назвали сопротивление сотрудников, 27% недостаток компетенций у&nbsp;руководителей, 26% сложности ИТ-инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема становится заметна после релиза. Проект завершили. Система работает. Как понять, что несколько миллионов были потрачены не&nbsp;зря? &lltt;br/&ggtt;
Если до&nbsp;начала работы компания не&nbsp;измеряла текущий процесс, ответа может и&nbsp;не&nbsp;быть. 
&lltt;/p&ggtt;
&lltt;p&ggtt;Например, смысл нового личного кабинета может быть не&nbsp;в&nbsp;самом факте его появления, а&nbsp;в&nbsp;том, чтобы больше клиентов решали свои вопросы без обращения в&nbsp;поддержку.&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;автоматизации документооборота задача может состоять в&nbsp;сокращении срока согласования с&nbsp;пяти дней до&nbsp;одного. У&nbsp;нового внутреннего сервиса&nbsp;— в&nbsp;том, чтобы операция, которая занимала у&nbsp;сотрудника 20&nbsp;минут, выполнялась за&nbsp;пять. А&nbsp;у&nbsp;мобильного приложения&nbsp;— не&nbsp;обязательно в&nbsp;росте установок. Возможно, важнее доля пользователей, дошедших до&nbsp;покупки или снижение нагрузки на&nbsp;офлайн-канал.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому еще до&nbsp;разработки хорошо зафиксировать три вещи: что происходит сейчас. Например, обработка одной заявки занимает 40&nbsp;минут. Что хотим получить. Например, 15&nbsp;минут. Как и&nbsp;когда будем это измерять.&lltt;/p&ggtt;
&lltt;p&ggtt;Без первой точки сравнения можно получить красивый продукт, хорошие отзывы внутри команды и&nbsp;ни&nbsp;одного доказательства, что бизнес стал работать лучше. Еще хуже, когда KPI цифровизации выбирается из&nbsp;технических показателей. Количество функций, число релизов или процент готовности проекта мало говорят о&nbsp;результате для компании. Система может быть написана без критических ошибок, запущена в&nbsp;срок и&nbsp;полностью соответствовать техническому заданию. И&nbsp;одновременно быть неудачным бизнес-проектом.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;3. Считать бюджет внедрения, а&nbsp;не&nbsp;реальную стоимость владения&lltt;/h2&ggtt;
&lltt;p&ggtt;Это одна из&nbsp;самых приземленных ошибок, потому что ее&nbsp;легко увидеть в&nbsp;деньгах. В&nbsp;&lltt;a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/"&ggtt;исследовании&lltt;/a&ggtt; ОБИТ&nbsp;61% проблемных проектов были связаны с&nbsp;недооценкой стоимости владения ИТ-решением. Компании не&nbsp;полностью учитывали стоимость интеграции, дальнейшего обслуживания и&nbsp;обучения сотрудников. В&nbsp;48% случаев возникали сложности интеграции с&nbsp;существующей инфраструктурой, в&nbsp;35% выбранное решение не&nbsp;соответствовало фактическим требованиям бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;оценке ОБИТ, доработки и&nbsp;исправления после неудачного внедрения могут потребовать еще &lltt;nobr&ggtt;10-30%&lltt;/nobr&ggtt; от&nbsp;первоначального бюджета. В&nbsp;отдельных случаях перезапуск проекта требует вложений, сопоставимых с&nbsp;первоначальными или даже вдвое большими.&lltt;/p&ggtt;
&lltt;p&ggtt;Если компания говорит, что внедрение стоит 15&nbsp;млн. рублей, стоит уточнить, что именно входит в&nbsp;эти 15&nbsp;млн.:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Только разработка? &lltt;/li&ggtt;
	&lltt;li&ggtt;Разработка и&nbsp;лицензии? &lltt;/li&ggtt;
	&lltt;li&ggtt;А&nbsp;интеграции? &lltt;/li&ggtt;
	&lltt;li&ggtt;Миграция данных? &lltt;/li&ggtt;
	&lltt;li&ggtt;Изменения в&nbsp;действующих системах? &lltt;/li&ggtt;
	&lltt;li&ggtt;Инфраструктура? &lltt;/li&ggtt;
	&lltt;li&ggtt;Информационная безопасность? &lltt;/li&ggtt;
	&lltt;li&ggtt;Переходный период, когда старое и&nbsp;новое решение работают параллельно?&lltt;/li&ggtt;
	&lltt;li&ggtt; Обучение? &lltt;/li&ggtt;
	&lltt;li&ggtt;Поддержка? &lltt;/li&ggtt;
	&lltt;li&ggtt;Развитие продукта через год? &lltt;/li&ggtt;
	&lltt;li&ggtt;Стоимость сотрудников заказчика, которые будут участвовать в&nbsp;проекте?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Цифровой продукт редко заканчивает потреблять деньги в&nbsp;день релиза. Поэтому сравнивать варианты только по&nbsp;стоимости разработки не&nbsp;очень полезно.&lltt;/p&ggtt;
&lltt;p&ggtt;Условный проект может выглядеть так:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;15&nbsp;млн. рублей стоит разработка и&nbsp;внедрение;&lltt;/li&ggtt;
	&lltt;li&ggtt;еще 2&nbsp;млн. потребовали доработки интеграций; &lltt;/li&ggtt;
	&lltt;li&ggtt;1,5&nbsp;млн. ушли на&nbsp;подготовку и&nbsp;миграцию данных из&nbsp;смежных ИС; &lltt;/li&ggtt;
	&lltt;li&ggtt;1&nbsp;млн.&nbsp;на&nbsp;переход и&nbsp;обучение;&lltt;/li&ggtt;
	&lltt;li&ggtt;2,5&nbsp;млн.&nbsp;на&nbsp;поддержку и&nbsp;доработки первого года.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Мы&nbsp;получили уже 22&nbsp;млн. вместо 15&nbsp;млн. Это не&nbsp;среднерыночный расчет и&nbsp;не&nbsp;прогноз для любого проекта, а&nbsp;просто иллюстрация того, насколько по-разному могут выглядеть «стоимость разработки» и&nbsp;«сколько бизнес реально потратил на&nbsp;изменение». Поэтому разумнее считать совокупную стоимость владения (ТСО) хотя&nbsp;бы на&nbsp;несколько лет.&lltt;/p&ggtt;
&lltt;p&ggtt;Иногда более дорогой продукт на&nbsp;этапе покупки оказывается дешевле в&nbsp;эксплуатации. А&nbsp;иногда дешевое коробочное решение через два года обрастает таким количеством доработок, что стоимость его поддержки становится отдельной строкой бюджета.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;4. Сначала выбрать технологию, а&nbsp;потом искать ей&nbsp;задачу&lltt;/h2&ggtt;
&lltt;p&ggtt;Еще несколько лет назад бизнес хотел блокчейн. Сейчас хочет AI. Между ними были супераппы, low-code, микросервисы и&nbsp;много чего еще. Фраза «нам нужно внедрить&nbsp;AI» сама по&nbsp;себе ничего не&nbsp;говорит о&nbsp;том, что компании нужно сделать. То&nbsp;же относится к&nbsp;CRM, ERP, мобильному приложению или отечественной замене зарубежной системы.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;анализе ОБИТ&nbsp;35% проблемных внедрений были связаны с&nbsp;тем, что выбранное решение не&nbsp;соответствовало фактическим бизнес-требованиям. В&nbsp;числе причин компания называет недостаточное тестирование продукта до&nbsp;внедрения и&nbsp;незрелость самого решения. Отдельно эта проблема проявилась во&nbsp;время импортозамещения.&lltt;/p&ggtt;
&lltt;p&ggtt;Т1&nbsp;и&nbsp;РУССОФТ &lltt;a href="https://t1.ru/media/news/issledovanie-it-kholdinga-t1-i-russoft-spros-na-rossiyskie-it-resheniya-opredelyaetsya-strategiey-ra"&ggtt;исследовали&lltt;/a&ggtt; 78&nbsp;российских компаний с&nbsp;фокусом на&nbsp;крупный бизнес. Среди серьезных препятствий при переходе на&nbsp;отечественные системы компании называли высокую стоимость новых продуктов, проблемы совместимости с&nbsp;текущей инфраструктурой и&nbsp;недостаточную функциональную зрелость части российских аналогов.&lltt;/p&ggtt;
&lltt;p&ggtt;Одновременно&nbsp;54% респондентов уже включают миграцию на&nbsp;российские технологии в&nbsp;стратегию развития собственных информационных систем. Только&nbsp;14% рассматривают импортозамещение исключительно как вынужденную реакцию на&nbsp;внешние обстоятельства.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;исследовании РБК и&nbsp;Ростелекома среди 308 руководителей российских компаний 36,7% &lltt;a href="https://rtkit.rbc.ru/"&ggtt;назвали&lltt;/a&ggtt; одной из&nbsp;проблем импортозамещения интеграцию отечественных решений с&nbsp;существующими системами, 32,5% долгие сроки внедрения.&lltt;/p&ggtt;
&lltt;p&ggtt;То&nbsp;есть задача «заменим зарубежную систему на&nbsp;российскую» сама по&nbsp;себе тоже может оказаться слишком узкой. Если компания все равно вынуждена менять критичный кусок ИТ-ландшафта, логично сначала посмотреть, нужен&nbsp;ли ей&nbsp;точный цифровой аналог старого процесса. Возможно, за&nbsp;годы работы изменился сам бизнес, появились лишние этапы, а&nbsp;некоторые функции старого продукта уже никому не&nbsp;нужны.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому порядок лучше разворачивать следующим образом: сначала проблема → затем целевой процесс → требования → ограничения текущей архитектуры → возможные решения → выбор между готовым продуктом, доработкой и&nbsp;собственной разработкой&lltt;/p&ggtt;
&lltt;p&ggtt;Не&nbsp;обязательно каждый раз писать новую систему. И&nbsp;не&nbsp;обязательно сразу раскатывать выбранное решение на&nbsp;всю компанию. Если технология новая, интеграций много, а&nbsp;процессы критичные, пилот часто дешевле большого запуска. На&nbsp;ограниченной группе пользователей можно проверить реальные сценарии, производительность, интеграции и&nbsp;ограничения продукта. Это намного лучше, чем обнаружить их&nbsp;после миграции нескольких тысяч сотрудников.&lltt;/p&ggtt;
&lltt;p&ggtt;После анализа проблемных проектов ОБИТ тоже рекомендует предварительное тестирование и&nbsp;пилотирование, а&nbsp;миграцию критичных систем проводить поэтапно.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;5. Автоматизировать старый процесс, не&nbsp;задаваясь вопросом, нужен&nbsp;ли он&nbsp;таким вообще&lltt;/h2&ggtt;
&lltt;p&ggtt;Когда компания готовит требования к&nbsp;новой системе, самый простой способ их&nbsp;получить&nbsp;— описать текущую работу. Есть пять этапов согласования? Переносим пять этапов в&nbsp;систему. Сотрудник четыре раза вводит одни и&nbsp;те&nbsp;же данные? Сделаем ему четыре красивые формы. Раньше документ отправляли на&nbsp;почту руководителю? Теперь будет кнопка «Отправить руководителю». Формально это цифровизация. Но&nbsp;процесс остался прежним.&lltt;/p&ggtt;
&lltt;p&ggtt;Здесь есть показательный пример из&nbsp;финансового сектора. В&nbsp;исследовании Ассоциации ФинТех при участии К2Тех&nbsp;70% компаний &lltt;a href="https://k2.tech/press_releases/67-finansovyh-kompanij-rf-vklyuchili-perehod-na-rossijskie-resheniya-v-svoi-strategii-razvitiya/"&ggtt;сообщили&lltt;/a&ggtt;, что в&nbsp;ходе трансформации ИТ-архитектуры провели аудит и&nbsp;пересмотр значимой части бизнес-процессов. Более&nbsp;80% организаций отметили положительные эффекты такой перестройки: повышение эффективности, большую гибкость, создание задела для развития и&nbsp;работу с&nbsp;накопленным техническим долгом.&lltt;/p&ggtt;
&lltt;p&ggtt;Конечно, финансовый сектор нельзя автоматически переносить на&nbsp;весь российский бизнес. Но&nbsp;сам подход показателен: смена технологий становится поводом пересмотреть процесс, а&nbsp;не&nbsp;просто перенести его в&nbsp;новую систему.&lltt;/p&ggtt;
&lltt;p&ggtt;· До&nbsp;автоматизации полезно буквально нарисовать процесс как есть: что сейчас делает клиент, сотрудник и&nbsp;система. Затем нарисовать должно быть. И&nbsp;к&nbsp;каждому действию задать неприятный вопрос: &lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;А&nbsp;зачем оно вообще существует? &lltt;/li&ggtt;
	&lltt;li&ggtt; Почему заявка должна пройти три согласования? &lltt;/li&ggtt;
	&lltt;li&ggtt; Почему данные повторно вводятся руками? &lltt;/li&ggtt;
	&lltt;li&ggtt; Почему менеджер переносит информацию из&nbsp;одной программы в&nbsp;другую? &lltt;/li&ggtt;
	&lltt;li&ggtt; Почему человек принимает решение, которое полностью определяется набором формальных правил?&lltt;/li&ggtt;
	&lltt;li&ggtt; Почему клиент должен заполнять&nbsp;то, что компания уже о&nbsp;нем знает?&lltt;/li&ggtt;
	&lltt;li&ggtt; Какие этапы после цифровизации должны не&nbsp;ускориться, а&nbsp;исчезнуть?&lltt;/li&ggtt;
	&lltt;li&ggtt; Если раньше сотрудник заполнял Excel, а&nbsp;теперь заполняет новую корпоративную систему и&nbsp;на&nbsp;всякий случай продолжает вести тот&nbsp;же Excel, то&nbsp;бизнес не&nbsp;очень много выиграл.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;6. Недооценить интеграции, данные, безопасность и&nbsp;аварийные сценарии&lltt;/h2&ggtt;
&lltt;p&ggtt;На&nbsp;презентации новый продукт обычно выглядит отдельно. Есть красивые экраны приложения, новый личный кабинет, CRM или внутренняя платформа. В&nbsp;реальной ИТ-инфраструктуре ничего отдельно не&nbsp;существует.&lltt;/p&ggtt;
&lltt;p&ggtt;Мобильному приложению нужно получить пользователя из&nbsp;одной системы, остаток из&nbsp;другой, цены из&nbsp;третьей, историю заказов из&nbsp;четвертой, принять платеж через внешнего провайдера и&nbsp;вернуть результат в&nbsp;ERP. &lltt;br/&ggtt;
И&nbsp;здесь начинается та&nbsp;часть проекта, которую бизнес не&nbsp;всегда видит на&nbsp;старте. 
&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;ОБИТ сложности интеграции были причиной проблем в&nbsp;48% проанализированных проектов. Компания отмечает, что они приводили не&nbsp;только к&nbsp;дополнительным затратам, но&nbsp;и&nbsp;к&nbsp;рискам простоев бизнес-процессов.&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;Comindware&nbsp;80% участников исследования работают с&nbsp;разрозненными интеграциями.&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;К2Тех&nbsp;74% опрошенных видят решение проблемы несогласованных данных в&nbsp;сквозной интеграции систем и&nbsp;создании единого контура управления данными. Интересно, что бизнес не&nbsp;обязательно хочет выбрасывать существующий ИТ-ландшафт: 46% компаний называют приоритетом оптимизацию текущих систем без масштабных инвестиций.&lltt;/p&ggtt;
&lltt;p&ggtt;То&nbsp;есть еще до&nbsp;интерфейсов полезно нарисовать карту интеграций и&nbsp;данных:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Откуда приходит каждый тип информации?&lltt;/li&ggtt;
	&lltt;li&ggtt; Какая система считается источником истины?&lltt;/li&ggtt;
	&lltt;li&ggtt; Кому разрешено менять данные?&lltt;/li&ggtt;
	&lltt;li&ggtt; Как часто они синхронизируются? &lltt;/li&ggtt;
	&lltt;li&ggtt; Что происходит, если две системы содержат разные значения?&lltt;/li&ggtt;
	&lltt;li&ggtt; Что будет, если внешнее API&nbsp;не отвечает?&lltt;/li&ggtt;
	&lltt;li&ggtt; А&nbsp;если запрос был отправлен дважды?&lltt;/li&ggtt;
	&lltt;li&ggtt; Как система восстановит операцию после сбоя?&lltt;/li&ggtt;
	&lltt;li&ggtt; Кто увидит ошибку и&nbsp;кто будет ее&nbsp;разбирать?&lltt;/li&ggtt;
	&lltt;li&ggtt; Вот эти вопросы часто влияют на&nbsp;стоимость проекта сильнее, чем количество экранов.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;strong&ggtt;Отдельно стоит проверить, что будет при сбоях.&lltt;/strong&ggtt; 
&lltt;p&ggtt;Цифровизация делает бизнес быстрее, но&nbsp;заодно сильнее связывает операции с&nbsp;технологиями. Если раньше недоступность одного сервиса мешала части сотрудников, после автоматизации сбой может остановить всю цепочку.&lltt;/p&ggtt;
&lltt;p&ggtt;КРОК в&nbsp;исследовании 70&nbsp;ИТ-руководителей крупных и&nbsp;крупнейших российских компаний &lltt;a href="https://www.croc.ru/press_releases/issledovanie-krok-90-kompanij-apk-i-52-ritejlerov-stali-bolshe-tratit-na-it-v-2025-godu/"&ggtt;отметил&lltt;/a&ggtt;, что в&nbsp;2025 году заметно вырос фокус на&nbsp;резервировании и&nbsp;отказоустойчивости. Среди инфраструктурных проблем&nbsp;36% респондентов называли отсутствие резервного ЦОДа, необходимость зеркалировать резервные копии, дублировать сети и&nbsp;сервисы. Поэтому до&nbsp;запуска стоит проверять не&nbsp;только happy path, где все работает как задумано.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Что произойдет, если платежный сервис недоступен два часа?&lltt;/li&ggtt;
	&lltt;li&ggtt; Если упала CRM?&lltt;/li&ggtt;
	&lltt;li&ggtt; Если внешняя система отвечает десять секунд вместо одной?&lltt;/li&ggtt;
	&lltt;li&ggtt; Если в&nbsp;Black Friday нагрузка выросла в&nbsp;несколько раз?&lltt;/li&ggtt;
	&lltt;li&ggtt; Если мобильное приложение работает, а&nbsp;один из&nbsp;внутренних сервисов нет?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Хорошая архитектура предусматривает не&nbsp;только полную работоспособность, но&nbsp;и&nbsp;управляемую деградацию. Пользователь по&nbsp;возможности должен сохранить хотя&nbsp;бы часть сценариев, а&nbsp;бизнес понимать, как система вернется в&nbsp;штатный режим.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;И&nbsp;безопасность нельзя добавлять последним пунктом перед релизом. &lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Исследования показали, что крупные российские компании назвали соответствие высоким требованиям информационной безопасности главным критерием выбора ИТ-партнера, а&nbsp;кибербезопасность остается одним из&nbsp;основных направлений ИТ-инвестиций российского бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;безопасность влияет не&nbsp;только на&nbsp;выбор подрядчика. Она может заметно поменять архитектуру, способ хранения данных, процессы авторизации, интеграции, инфраструктуру и&nbsp;стоимость разработки. Если требования&nbsp;ИБ появляются после того, как продукт уже почти готов, часть работы иногда приходится делать заново.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;7. Решить, что legacy обязательно нужно переписать&lltt;/h2&ggtt;
&lltt;p&ggtt;Старому коду легко назначить виноватого. Если релизы идут медленно, разработчики жалуются на&nbsp;монолит, документации мало и&nbsp;вокруг системы накопилось много странных решений, появляется естественное желание: давайте перепишем все нормально. Иногда это правда правильный вариант. Но&nbsp;возраст системы сам по&nbsp;себе еще не&nbsp;бизнес-проблема.&lltt;/p&ggtt;
&lltt;p&ggtt;Опираясь на&nbsp;данные вышеуказанных исследований, 78% российских компаний, использующих облачные технологии, сохраняют legacy-системы. У&nbsp;14% legacy составляет больше половины ИТ-портфеля.&nbsp;46% участников называют одним из&nbsp;главных приоритетов оптимизацию существующих систем без масштабных инвестиций. В&nbsp;исследовании КРОК более&nbsp;30% респондентов говорили о&nbsp;необходимости обновления оборудования и&nbsp;работы с&nbsp;legacy. Тут нет противоречия. Потому что legacy можно модернизировать по-разному.&lltt;/p&ggtt;
&lltt;p&ggtt;Допустим, старое ядро работает стабильно, содержит критическую бизнес-логику и&nbsp;справляется с&nbsp;нагрузкой. Но&nbsp;у&nbsp;него плохие интеграции. Тогда иногда разумнее оставить ядро и&nbsp;построить нормальный API-слой.&lltt;/p&ggtt;
&lltt;p&ggtt;Если тормозит один модуль, можно вынести его. Если система мешает независимым релизам, разделить наиболее проблемные компоненты. Если высокая стоимость поддержки связана с&nbsp;конкретной частью кода, провести рефакторинг именно там.&lltt;/p&ggtt;
&lltt;p&ggtt;Полная замена тоже возможна, но&nbsp;тогда бизнесу стоит понимать, что именно он&nbsp;покупает за&nbsp;стоимость переписывания:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Будут быстрее запускаться функции?&lltt;/li&ggtt;
	&lltt;li&ggtt; Снизится стоимость поддержки?&lltt;/li&ggtt;
	&lltt;li&ggtt; Уйдут ограничения по&nbsp;нагрузке?&lltt;/li&ggtt;
	&lltt;li&ggtt; Станет проще находить разработчиков?&lltt;/li&ggtt;
	&lltt;li&ggtt; Исчезнут риски безопасности?&lltt;/li&ggtt;
	&lltt;li&ggtt; Можно будет подключать новые продукты?&lltt;/li&ggtt;
	&lltt;li&ggtt; Если на&nbsp;эти вопросы нет ответа, то&nbsp;проект под названием «перепишем все с&nbsp;нуля» легко превращается в&nbsp;очень дорогой способ получить почти то&nbsp;же самое.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Особенно рискован big bang, когда старая система выключается, а&nbsp;новая должна одномоментно заменить все функции. Чем критичнее продукт, тем разумнее рассматривать поэтапную миграцию, когда часть функций или пользователей переводится последовательно и&nbsp;у&nbsp;команды остается возможность проверить систему на&nbsp;реальной работе.&lltt;/p&ggtt;
&lltt;p&ggtt;Иногда хороший результат технического аудита звучит не&nbsp;как «вам нужно 30&nbsp;млн. рублей на&nbsp;новый продукт», а&nbsp;как «эту часть вообще не&nbsp;трогаем».&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;8. Сначала внедрить&nbsp;AI, а&nbsp;потом разбираться с&nbsp;данными&lltt;/h2&ggtt;
&lltt;p&ggtt;С&nbsp;AI&nbsp;проблема качества данных стала гораздо заметнее. Можно купить хороший инструмент прогнозирования, подключить&nbsp;BI, внедрить AI-ассистента или модель для автоматического принятия решений. Но&nbsp;если клиент хранится в&nbsp;трех системах под разными идентификаторами, справочники не&nbsp;совпадают, часть данных вводится вручную, а&nbsp;происхождение цифры в&nbsp;отчете никто не&nbsp;может объяснить, новая технология это не&nbsp;исправит. Она будет работать с&nbsp;тем, что ей&nbsp;дали.&lltt;/p&ggtt;
&lltt;p&ggtt;51% компаний сохраняют внедрение&nbsp;AI среди ключевых приоритетов. Одновременно&nbsp;68% респондентов говорят, что не&nbsp;получают целостной картины данных из-за разрозненного ИТ-ландшафта.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;исследовании КРОК качество входных данных и&nbsp;отсутствие формальных регламентов названы среди факторов, которые мешают масштабированию технологических инициатив.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельно Strategy Partners &lltt;a href="https://strategy.ru/research/research/polovina-promyshlennyh-predpriyatij-ispytyvaet-deficit-chelovecheskih-resursov-i-kompetencij-dlya-raboty-s-dannymi/"&ggtt;исследовала&lltt;/a&ggtt; работу с&nbsp;данными на&nbsp;российских промышленных предприятиях. В&nbsp;56% компаний ручной ввод остается распространенным способом сбора данных. Только у&nbsp;четверти есть отдельное подразделение для работы с&nbsp;данными, еще у&nbsp;36% выделен специалист по&nbsp;аналитике. Среди основных барьеров компании называют нехватку людей, компетенций и&nbsp;технических ресурсов.&lltt;/p&ggtt;
&lltt;p&ggtt;Это особенно важный момент для AI-проектов, потому что там качество исходной информации напрямую связано с&nbsp;качеством результата.&lltt;/p&ggtt;
&lltt;p&ggtt;До&nbsp;запуска стоит разобраться:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; где хранится мастер-версия данных;&lltt;/li&ggtt;
	&lltt;li&ggtt; кто является их&nbsp;владельцем;&lltt;/li&ggtt;
	&lltt;li&ggtt; кто отвечает за&nbsp;качество;&lltt;/li&ggtt;
	&lltt;li&ggtt; есть&nbsp;ли дубли;&lltt;/li&ggtt;
	&lltt;li&ggtt; насколько информация полная и&nbsp;свежая;&lltt;/li&ggtt;
	&lltt;li&ggtt; как изменяются справочники;&lltt;/li&ggtt;
	&lltt;li&ggtt; можно&nbsp;ли понять происхождение конкретного значения;&lltt;/li&ggtt;
	&lltt;li&ggtt; какие данные вообще нельзя использовать в&nbsp;выбранном сценарии;&lltt;/li&ggtt;
	&lltt;li&ggtt; кто отвечает за&nbsp;ошибку, если автоматическая система приняла неправильное решение.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Если у&nbsp;компании три разных значения одного показателя в&nbsp;трех системах, AI&nbsp;не создаст магическим образом правильное. Есть риск, что появится просто четвертый вариант.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ошибка&nbsp;9. Считать, что цифровизация закончилась в&nbsp;день релиза&lltt;/h2&ggtt;
&lltt;p&ggtt;Команда несколько месяцев или лет делает систему. Проходит приемка. Проект закрывают. На&nbsp;презентации появляется зеленый статус «внедрено». А&nbsp;сотрудники продолжают пользоваться Excel. Или переносят часть данных вручную. Или нашли способ обходить новый процесс, потому что старый быстрее. Или система используется, но&nbsp;время выполнения операции не&nbsp;уменьшилось.&lltt;/p&ggtt;
&lltt;p&ggtt;Технический запуск еще не&nbsp;означает, что произошло изменение бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;исследовании Т1&nbsp;и&nbsp;РУССОФТ сопротивление сотрудников новым системам отметили 79,5% представителей крупных компаний. В&nbsp;исследовании Русской школы управления эту проблему отметили&nbsp;29% респондентов.&lltt;/p&ggtt;
&lltt;p&ggtt;Разница в&nbsp;цифрах большая, потому что исследования изучали разные выборки и&nbsp;сценарии. Т1&nbsp;и&nbsp;РУССОФТ рассматривали крупный бизнес и&nbsp;переход на&nbsp;отечественные системы, РШУ шире спрашивала о&nbsp;цифровизации управленческих процессов. Но&nbsp;обе работы показывают, что технология сама по&nbsp;себе не&nbsp;заставляет людей изменить способ работы.&lltt;/p&ggtt;
&lltt;p&ggtt;И&nbsp;здесь легко дать неправильный совет: «нужно лучше обучать сотрудников». Обучение нужно, но&nbsp;сначала стоит проверить сам продукт. Если раньше сотрудник выполнял пять действий, а&nbsp;после внедрения системы делает восемь, сопротивление не&nbsp;обязательно связано с&nbsp;консерватизмом. Если новая программа работает медленнее старой, человек будет искать обходной путь. Если данные нужно вводить и&nbsp;в&nbsp;старую, и&nbsp;в&nbsp;новую систему, он&nbsp;продолжит вести Excel. Если продукт не&nbsp;учитывает реальные исключения из&nbsp;процесса, сотрудники быстро построят вокруг него собственный параллельный процесс в&nbsp;почте и&nbsp;мессенджерах.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому после релиза важно измерять не&nbsp;только технические показатели. Да, нужны uptime, количество ошибок и&nbsp;SLA. Но&nbsp;параллельно стоит смотреть:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; какая доля сотрудников действительно работает в&nbsp;новой системе;&lltt;/li&ggtt;
	&lltt;li&ggtt; какую часть процесса они проходят в&nbsp;ней полностью;&lltt;/li&ggtt;
	&lltt;li&ggtt; сколько ручных операций осталось;&lltt;/li&ggtt;
	&lltt;li&ggtt; сколько времени занимает задача;&lltt;/li&ggtt;
	&lltt;li&ggtt; изменилась&nbsp;ли частота ошибок;&lltt;/li&ggtt;
	&lltt;li&ggtt; не&nbsp;продолжают&nbsp;ли сотрудники вести параллельные таблицы;&lltt;/li&ggtt;
	&lltt;li&ggtt; как часто им&nbsp;приходится обходить систему;&lltt;/li&ggtt;
	&lltt;li&ggtt; изменился&nbsp;ли бизнес-показатель, ради которого все начиналось.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Цифровизация заканчивается тогда, когда изменился процесс и&nbsp;появился измеримый результат для бизнеса.&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому сложный цифровой продукт почти никогда нельзя воспринимать как объект, который один раз разработали и&nbsp;забыли. Меняется бизнес, появляются новые требования, интеграции, регуляторика, нагрузка. Продукту приходится меняться вместе с&nbsp;ними.&lltt;/p&ggtt;
&lltt;h2&ggtt;Что проверить до&nbsp;того, как утвердить бюджет&lltt;/h2&ggtt;
&lltt;p&ggtt;Ошибки из&nbsp;этой статьи могут выглядеть очень разными, но&nbsp;большинство можно обнаружить до&nbsp;начала большой разработки. Перед запуском проекта полезно честно ответить хотя&nbsp;бы на&nbsp;несколько групп вопросов.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Бизнес&lltt;/strong&ggtt;&lltt;strong&ggtt;:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Какую проблему мы&nbsp;решаем?&lltt;/li&ggtt;
	&lltt;li&ggtt; Сколько она стоит компании сейчас? &lltt;/li&ggtt;
	&lltt;li&ggtt; Какой показатель должен измениться после запуска?&lltt;/li&ggtt;
	&lltt;li&ggtt; Знаем&nbsp;ли мы&nbsp;его текущее значение?&lltt;/li&ggtt;
	&lltt;li&ggtt; Как поймем через полгода, что проект сработал?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Процесс&lltt;/strong&ggtt;&lltt;strong&ggtt;:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Нужно&nbsp;ли вообще автоматизировать процесс в&nbsp;его нынешнем виде?&lltt;/li&ggtt;
	&lltt;li&ggtt; Какие этапы можно убрать?&lltt;/li&ggtt;
	&lltt;li&ggtt; Какие действия должен перестать делать человек?&lltt;/li&ggtt;
	&lltt;li&ggtt; Не&nbsp;создаем&nbsp;ли мы&nbsp;цифровую копию старой бюрократии?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;ИТ-ландшафт&lltt;/strong&ggtt;&lltt;strong&ggtt;:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Какие системы затронет новый продукт?&lltt;/li&ggtt;
	&lltt;li&ggtt; Сколько интеграций потребуется?&lltt;/li&ggtt;
	&lltt;li&ggtt; Где находится источник истины для каждого типа данных?&lltt;/li&ggtt;
	&lltt;li&ggtt; Что придется доработать в&nbsp;существующих системах?&lltt;/li&ggtt;
	&lltt;li&ggtt; Что будет, если одна из&nbsp;интеграций перестанет работать?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Деньги&lltt;/strong&ggtt;&lltt;strong&ggtt;:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Посчитана стоимость разработки или полная стоимость владения?&lltt;/li&ggtt;
	&lltt;li&ggtt; Учтены&nbsp;ли миграция данных, инфраструктура, интеграции и&nbsp;обучение?&lltt;/li&ggtt;
	&lltt;li&ggtt; Как будет финансироваться поддержка?&lltt;/li&ggtt;
	&lltt;li&ggtt; Кто будет развивать систему после первого релиза?&lltt;/li&ggtt;
	&lltt;li&ggtt; Сколько решение будет стоить компании через три года?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Технология&lltt;/strong&ggtt;&lltt;strong&ggtt;:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Почему выбран именно этот класс решений?&lltt;/li&ggtt;
	&lltt;li&ggtt; Смотрели&nbsp;ли мы&nbsp;альтернативы?&lltt;/li&ggtt;
	&lltt;li&ggtt; Нужна&nbsp;ли собственная разработка?&lltt;/li&ggtt;
	&lltt;li&ggtt; Можно&nbsp;ли доработать существующий продукт?&lltt;/li&ggtt;
	&lltt;li&ggtt; Нужно&nbsp;ли действительно полностью переписывать legacy?&lltt;/li&ggtt;
	&lltt;li&ggtt; Можно&nbsp;ли сначала проверить гипотезу на&nbsp;пилоте?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Риски&lltt;/strong&ggtt;&lltt;strong&ggtt;:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Что произойдет при пиковой нагрузке?&lltt;/li&ggtt;
	&lltt;li&ggtt; Как работает система при частичной недоступности сервисов?&lltt;/li&ggtt;
	&lltt;li&ggtt; Есть&nbsp;ли план поэтапной миграции и&nbsp;возможность отката?&lltt;/li&ggtt;
	&lltt;li&ggtt; Учтены&nbsp;ли требования информационной безопасности в&nbsp;архитектуре, а&nbsp;не&nbsp;только перед релизом?&lltt;/li&ggtt;
	&lltt;li&ggtt; Какие данные система получает и&nbsp;можно&nbsp;ли им&nbsp;доверять?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Пользователи&lltt;/strong&ggtt;&lltt;strong&ggtt;:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Участвовали&nbsp;ли реальные сотрудники или клиенты в&nbsp;проверке сценариев?&lltt;/li&ggtt;
	&lltt;li&ggtt; Станет&nbsp;ли им&nbsp;проще выполнять задачу?&lltt;/li&ggtt;
	&lltt;li&ggtt; Не&nbsp;придется&nbsp;ли пользоваться старой и&nbsp;новой системой одновременно?&lltt;/li&ggtt;
	&lltt;li&ggtt; Как мы&nbsp;измерим реальное использование продукта после запуска?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Если на&nbsp;значительную часть этих вопросов пока нет ответа, возможно, компании еще рано проводить тендер на&nbsp;разработку.&lltt;/p&ggtt;
&lltt;p&ggtt;Иногда первым этапом должен стать не&nbsp;дизайн приложения и&nbsp;не&nbsp;оценка программистами количества часов, а&nbsp;обследование: разбор процессов, архитектуры, интеграций, данных, технического долга, требований безопасности и&nbsp;экономики будущего решения.&lltt;/p&ggtt;
&lltt;p&ggtt;Такой этап тоже стоит денег. Но&nbsp;его задача как раз в&nbsp;том, чтобы не&nbsp;выяснять самые дорогие особенности проекта тогда, когда контракт уже подписан, команда работает, а&nbsp;половина бюджета потрачена.&lltt;/p&ggtt;
&lltt;p&ggtt;Цифровизация обходится дорого не&nbsp;только тогда, когда разработчики ошибаются в&nbsp;коде. Гораздо больше денег можно потерять раньше: выбрать не&nbsp;ту&nbsp;задачу, не&nbsp;посчитать владение, добавить еще одну систему в&nbsp;уже сложный ландшафт или автоматизировать процесс, который стоило сначала переделать.&lltt;/p&ggtt;
&lltt;p&ggtt;И&nbsp;чем крупнее проект, тем дороже становится вопрос, который бизнес не&nbsp;задал себе на&nbsp;старте.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235402#&lltt;/p&ggtt;]]></source>
<adate>27.08.2026</adate>
<dbid>235401</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/3ce/6z2ftbnw01vnjvlevfjf79l64u25sm1s.jpg]]>
</images>
<imagesname><![CDATA[;;Владимир Белозеров, заместитель коммерческого директора компании KODE   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Цифровая трансформация]]></tag>
</item>
<item>
<title><![CDATA[Как безопасно перейти с Atlassian на российские платформы]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235417]]></link>
<description><![CDATA[Глобальная стратегия Atlassian по переходу в облако делает миграцию из этой экосистемы все более актуальной задачей для российских компаний. Рассмотрим, как при переходе сохранить бизнес-логику, минимизировать риски и правильно организовать процесс. Почему пришло время мигрировать c Atlassian Решениями Atlassian еще пользуются в российских компаниях, но все больше факторов подталкивают бизнес к переходу на альтернативные платформы. 15 февраля 2024 года вендор прекратил официальную поддержку, выпуск обновлений и исправлений для продуктов линейки Server. Формально эти системы можно продолжать использовать в закрытом контуре, принимая на себя риски. 30 марта 2026 года закрылись продажи продуктов линейки Data Center новым клиентам, а с 30 марта 2028 года обладатели действующих подписок не смогут покупать новые лицензии, расширения и приложения из Atlassian Marketplace. 28 марта 2029 года жизненный цикл локальных решений окончательно подойдет к концу: сроки действия подписок Data Center завершатся, а системы, связанные с приложениями из Marketplace, перейдут в режим только для чтения. На смену этим решениям в экосистеме вендора приходит линейка Cloud. Это часть стратегии перевода в облако, которую Atlassian последовательно реализует уже несколько лет. Однако российскому бизнесу Cloud подходит не на 100%, поскольку не в полной мере отвечает требованиям информационной безопасности, не поддерживает работу в закрытом контуре и сложную кастомизацию. К тому же многие отечественные компании не могут выносить данные в зарубежный облачный сервис. В этих условиях раннее планирование миграции с Atlassian выглядит оптимальным вариантом. Оно позволит избежать рисков, связанных с продолжением эксплуатации устаревших продуктов без официальной поддержки. Во-первых, даже закрытый контур не делает систему «бессмертной». Чем дольше она работает без обновлений безопасности, тем выше становятся накопленные риски. Во-вторых, по мере модернизации остальной ИТ-инфраструктуры может ухудшаться ее совместимость с лишенными поддержки решениями Atlassian. В-третьих, через два-три года может быть сложнее найти сотрудников, хорошо знакомых со старой версией системы, старыми плагинами и кастомизациями. В-четвертых, бизнес-процессы постепенно перестраиваются, а вместе с ними должна дорабатываться платформа. Такие изменения лучше вносить сразу в новую систему, чем в старую, от которой вероятно придется отказаться. Что перенести на новую платформу При миграции с Atlassian в первую очередь следует перенести управление задачами, проектами и статусами, а главное — жизненными циклами, ведь именно на них опираются реальные бизнес-процессы. Важно переместить не просто карточки, а соответствующие им операции, иначе система не будет работать и превратится в обычный архив. Второй слой миграции — структура данных: настраиваемые поля и схемы распределения прав доступа. Они кажутся незначительными элементами, но именно на их основе строятся отчетность, маршрутизация, фильтры и SLA (соглашения об уровне услуг). Главное — не копировать все поля и права без изменений, а заново собрать модель таким образом, чтобы она была безопасной и актуальной. Третий слой — аналитика: дашборды, отчеты и настроенные фильтры. Основная ценность системы для руководителей часто заключается не в управлении задачами, а именно в этих инструментах. Без них даже переход на более мощную платформу может вызвать негативную реакцию менеджмента. В связи с этим следует тщательно продумать перенос аналитики и заранее включить его в план проекта. Четвертый слой — базы знаний из Confluence и сопутствующие вложения из Jira. При миграции важно оценить, какие из них лучше перенести в активный контур, какие — архивировать, а какие — удалить. Переход на новую платформу станет удачным моментом для такой оптимизации. Следующий слой — экосистема: внешние интеграции и установленные плагины, которых в крупной компании может накопиться очень много. Для их правильного переноса следует перед миграцией составить архитектурную схему, на которой будет указано, какие интеграции и плагины используются, зачем они нужны и насколько они критичны для бизнеса. Это поможет спланировать, что предстоит актуализировать, что — собрать заново, а что — заменить. Пошаговый план миграции Чтобы переход на новую платформу прошел успешно, важно использовать системный подход к подготовке и осуществлению миграции. Эту работу можно разделить на шесть шагов. Шаг 1. Инвентаризация данных и аудит процессов. Сначала необходимо проанализировать набор используемых продуктов Atlassian, проверить их версии и сроки окончания поддержки. Следует оценить связанные с платформой риски на горизонте двух-трех лет, а также определить, требуется ли ее дорабатывать в ближайшее время. Работа в условиях закрытого контура не снимает вопросы технической поддержки, информационной безопасности, обновлений, совместимости и планирования выхода из экосистемы — их все равно нужно прояснить заранее. Также следует составить карту процессов, разделяя их по сценариям и выделяя критически важные для бизнеса операции. Это поможет сделать обоснованный выбор, на какую систему или гибридное решение переходить. Главным критерием должна стать возможность воспроизвести текущие процессы на новой платформе. Шаг 2. Проектирование целевой модели в новой системе. После инвентаризации следует спроектировать целевую модель с описанием того, как процессы будут функционировать после перехода. Необходимо определить, какие операции перейдут в новую систему, что произойдет с архивом, где потребуются интеграции и как они будут работать, а также каким образом будет организован переход пользователей. Отдельного внимания требуют правила переноса исторических данных и нефункциональные требования. Необходимо описать, как должна работать система, задать требования к отказоустойчивости и информационной безопасности. Шаг 3. Первичная настройка и кастомизация платформы. На этом этапе нужно настроить выбранную платформу или связку платформ: создать процессы, формы, роли и другие элементы, необходимые для работы решений, а также настроить права доступа, аналитику, уведомления, интеграции и маршруты согласования — все то, что обеспечивает функционирование ПО в рамках реальных рабочих процессов. Важно не стремиться к точному копированию старой системы, иначе есть риск перенести накопившиеся в ней проблемы в новый интерфейс; устаревшие процессы целесообразно собрать заново, проведя их аудит и оптимизацию. Шаг 4. Тестовый перенос ограниченного объема данных. В его рамках следует проверить, как в новую систему перемещаются задачи, поля, статусы и другие элементы. Особое внимание стоит уделить тому, что не перенеслось автоматически: как правило эта информация наиболее полезна для доработки процесса. В автоматическом режиме обычно переносятся задачи, описания и другие элементы, поддающиеся прямому сопоставлению. Однако корректность такого переноса напрямую зависит от точности карты соответствия полей между системами, особенно если платформы различаются по структуре данных. При этом важно четко определить назначение каждого элемента: без правильной интерпретации значений старых полей и статусов автоматизированный перенос данных может пройти некорректно. По итогам этого шага необходимо проанализировать миграционный отчет, однако не менее важна сама практика тестового переноса. Шаг 5. Проверка реальных пользовательских сценариев. На этом этапе в первую очередь тестируют пользовательский опыт: насколько удобно создавать заявки, согласовывать их и назначать исполнителей, работают ли переназначение по процессу, SLA и аналитика, закрываются ли обращения и насколько удовлетворены пользователи. Если все эти сценарии выполняются корректно, миграция становится не просто технически успешной, но и полезной для бизнеса. Шаг 6. Итоговая промышленная миграция. Финальный этап — промышленная миграция, сопровождаемая волнами коммуникации с командами. Она должна стать не резким отключением старой системы, а плавным управляемым переходом, о котором заранее знают все участники и в рамках которого четко определены роли и зоны ответственности. Это исключает ситуации, в которых сотрудники месяцами дублируют работу в двух системах одновременно, и позволяет сервисным менеджерам бесшовно перейти на новую платформу. Основные риски миграции Если неправильно спланировать переход на новую платформу, можно нарушить уникальную бизнес-логику, зафиксированную в глубоких кастомизациях решений Atlassian. Это более серьезный риск, чем потерять данные. Даже если успешно перенести все задачи, комментарии и вложения, но упустить из виду правила согласования или автоматическое переназначение, бизнес-процесс не будет работать. Другой важный риск — сложности и ошибки при переносе исторических данных. Если таких записей накопилось много, перемещать весь массив может быть дорого, долго и нецелесообразно. Однако вовсе не перенести исторические данные — опасно для бизнеса. Разумным выбором станет категоризация элементов с учетом ценности и применения в рабочих процессах. Третий риск при миграции — неполный или некорректный перенос прав доступа и ролевых моделей. Следует отдельно планировать распределение прав на новой платформе: если они выйдут за нужные рамки, возникнут проблемы безопасности, а если слишком сильно ограничить доступ, пользователи не смогут нормально работать. Это особенно критично для сервисных процессов, HR-заявок, защиты данных, финансовых согласований, проектной документации и базы знаний. Четвертый риск — жесткая зависимость от приложений из Marketplace, у которых нет прямых аналогов. На старых версиях Atlassian одни и те же плагины могли работать годами. В таких случаях при миграции возникают вопросы, какую логику они используют, кто ее поддерживает, можно ли отказаться от этих приложений и есть ли у них аналоги. Иногда небольшой плагин оказывается самым критичным элементом всего бизнес-процесса, поэтому миграцию надо начинать с аудита, а не с выбора новой платформы. Наконец, главная ошибка — попытка перенести систему как есть, без предварительной оптимизации. При таком подходе вместе с полезными составляющими можно скопировать источники хаоса. Задача миграции не сохранить все плюсы и минусы старой системы, а обеспечить корректную работу процессов, убрать лишнее и выстроить эффективную архитектуру. Безопасный переход Сделать миграцию максимально комфортной и безопасной поможет в первую очередь отказ от переноса всех составляющих старой системы. Активные элементы можно добавить в рабочий контур, важные исторические данные — сохранить в архиве, а ненужные записи — удалить. Еще одним обязательным условием успеха станет тестовый перенос. Пилотная часть проекта поможет проверить критически важные узлы архитектуры и оценить реальную картину. Для компании, которая рассматривает миграцию с Atlassian, на первом плане должен быть не вопрос, работает ли платформа сегодня, а возможность безопасно выстраивать процессы на ее базе в перспективе. Если слишком долго откладывать переход на новую систему, можно оказаться в ситуации, когда поддерживать старые решения слишком дорого, а отказаться от них слишком сложно. В связи с этим лучше заранее выстроить на основе отечественного ПО новую жизнеспособную архитектуру, которая будет получать официальную поддержку и эволюционировать вместе с бизнес-процессами компании. #IMAGE_235418#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Глобальная стратегия Atlassian по&nbsp;переходу в&nbsp;облако делает миграцию из&nbsp;этой экосистемы все более актуальной задачей для российских компаний. Рассмотрим, как при переходе сохранить бизнес-логику, минимизировать риски и&nbsp;правильно организовать процесс.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему пришло время мигрировать c&nbsp;Atlassian&lltt;/h3&ggtt;
&lltt;p&ggtt;Решениями Atlassian еще пользуются в&nbsp;российских компаниях, но&nbsp;все больше факторов подталкивают бизнес к&nbsp;переходу на&nbsp;альтернативные платформы.&nbsp;15&nbsp;февраля 2024 года вендор прекратил официальную поддержку, выпуск обновлений и&nbsp;исправлений для продуктов линейки Server. Формально эти системы можно продолжать использовать в&nbsp;закрытом контуре, принимая на&nbsp;себя риски.&lltt;/p&ggtt;
&lltt;p&ggtt;30&nbsp;марта 2026 года закрылись продажи продуктов линейки Data Center новым клиентам, а&nbsp;с&nbsp;30&nbsp;марта 2028 года обладатели действующих подписок не&nbsp;смогут покупать новые лицензии, расширения и&nbsp;приложения из&nbsp;Atlassian Marketplace.&nbsp;28&nbsp;марта 2029 года жизненный цикл локальных решений окончательно подойдет к&nbsp;концу: сроки действия подписок Data Center завершатся, а&nbsp;системы, связанные с&nbsp;приложениями из&nbsp;Marketplace, перейдут в&nbsp;режим только для чтения.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;смену этим решениям в&nbsp;экосистеме вендора приходит линейка Cloud. Это часть стратегии перевода в&nbsp;облако, которую Atlassian последовательно реализует уже несколько лет. Однако российскому бизнесу Cloud подходит не&nbsp;на&nbsp;100%, поскольку не&nbsp;в&nbsp;полной мере отвечает требованиям информационной безопасности, не&nbsp;поддерживает работу в&nbsp;закрытом контуре и&nbsp;сложную кастомизацию. К&nbsp;тому&nbsp;же многие отечественные компании не&nbsp;могут выносить данные в&nbsp;зарубежный облачный сервис.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;этих условиях раннее планирование миграции с&nbsp;Atlassian выглядит оптимальным вариантом. Оно позволит избежать рисков, связанных с&nbsp;продолжением эксплуатации устаревших продуктов без официальной поддержки.&lltt;/p&ggtt;
&lltt;p&ggtt;Во-первых, даже закрытый контур не&nbsp;делает систему «бессмертной». Чем дольше она работает без обновлений безопасности, тем выше становятся накопленные риски. Во-вторых, по&nbsp;мере модернизации остальной ИТ-инфраструктуры может ухудшаться ее&nbsp;совместимость с&nbsp;лишенными поддержки решениями Atlassian. В-третьих, через два-три года может быть сложнее найти сотрудников, хорошо знакомых со&nbsp;старой версией системы, старыми плагинами и&nbsp;кастомизациями. В-четвертых, бизнес-процессы постепенно перестраиваются, а&nbsp;вместе с&nbsp;ними должна дорабатываться платформа. Такие изменения лучше вносить сразу в&nbsp;новую систему, чем в&nbsp;старую, от&nbsp;которой вероятно придется отказаться.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что перенести на&nbsp;новую платформу&lltt;/h3&ggtt;
&lltt;p&ggtt;При миграции с&nbsp;Atlassian в&nbsp;первую очередь следует перенести управление задачами, проектами и&nbsp;статусами, а&nbsp;главное&nbsp;— жизненными циклами, ведь именно на&nbsp;них опираются реальные бизнес-процессы. Важно переместить не&nbsp;просто карточки, а&nbsp;соответствующие им&nbsp;операции, иначе система не&nbsp;будет работать и&nbsp;превратится в&nbsp;обычный архив.&lltt;/p&ggtt;
&lltt;p&ggtt;Второй слой миграции&nbsp;— структура данных: настраиваемые поля и&nbsp;схемы распределения прав доступа. Они кажутся незначительными элементами, но&nbsp;именно на&nbsp;их&nbsp;основе строятся отчетность, маршрутизация, фильтры и&nbsp;SLA (соглашения об&nbsp;уровне услуг). Главное&nbsp;— не&nbsp;копировать все поля и&nbsp;права без изменений, а&nbsp;заново собрать модель таким образом, чтобы она была безопасной и&nbsp;актуальной.&lltt;/p&ggtt;
&lltt;p&ggtt;Третий слой&nbsp;— аналитика: дашборды, отчеты и&nbsp;настроенные фильтры. Основная ценность системы для руководителей часто заключается не&nbsp;в&nbsp;управлении задачами, а&nbsp;именно в&nbsp;этих инструментах. Без них даже переход на&nbsp;более мощную платформу может вызвать негативную реакцию менеджмента. В&nbsp;связи с&nbsp;этим следует тщательно продумать перенос аналитики и&nbsp;заранее включить его в&nbsp;план проекта.&lltt;/p&ggtt;
&lltt;p&ggtt;Четвертый слой&nbsp;— базы знаний из&nbsp;Confluence и&nbsp;сопутствующие вложения из&nbsp;Jira. При миграции важно оценить, какие из&nbsp;них лучше перенести в&nbsp;активный контур, какие&nbsp;— архивировать, а&nbsp;какие&nbsp;— удалить. Переход на&nbsp;новую платформу станет удачным моментом для такой оптимизации.&lltt;/p&ggtt;
&lltt;p&ggtt;Следующий слой&nbsp;— экосистема: внешние интеграции и&nbsp;установленные плагины, которых в&nbsp;крупной компании может накопиться очень много. Для их&nbsp;правильного переноса следует перед миграцией составить архитектурную схему, на&nbsp;которой будет указано, какие интеграции и&nbsp;плагины используются, зачем они нужны и&nbsp;насколько они критичны для бизнеса. Это поможет спланировать, что предстоит актуализировать, что&nbsp;— собрать заново, а&nbsp;что&nbsp;— заменить.&lltt;/p&ggtt;
&lltt;h3&ggtt;Пошаговый план миграции&lltt;/h3&ggtt;
&lltt;p&ggtt;Чтобы переход на&nbsp;новую платформу прошел успешно, важно использовать системный подход к&nbsp;подготовке и&nbsp;осуществлению миграции. Эту работу можно разделить на&nbsp;шесть шагов.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Шаг&nbsp;1. Инвентаризация данных и&nbsp;аудит процессов. &lltt;/strong&ggtt;Сначала необходимо проанализировать набор используемых продуктов Atlassian, проверить их&nbsp;версии и&nbsp;сроки окончания поддержки. Следует оценить связанные с&nbsp;платформой риски на&nbsp;горизонте двух-трех лет, а&nbsp;также определить, требуется&nbsp;ли ее&nbsp;дорабатывать в&nbsp;ближайшее время. Работа в&nbsp;условиях закрытого контура не&nbsp;снимает вопросы технической поддержки, информационной безопасности, обновлений, совместимости и&nbsp;планирования выхода из&nbsp;экосистемы&nbsp;— их&nbsp;все равно нужно прояснить заранее. Также следует составить карту процессов, разделяя их&nbsp;по&nbsp;сценариям и&nbsp;выделяя критически важные для бизнеса операции. Это поможет сделать обоснованный выбор, на&nbsp;какую систему или гибридное решение переходить. Главным критерием должна стать возможность воспроизвести текущие процессы на&nbsp;новой платформе.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Шаг&nbsp;2. Проектирование целевой модели в&nbsp;новой системе. &lltt;/strong&ggtt;После инвентаризации следует спроектировать целевую модель с&nbsp;описанием того, как процессы будут функционировать после перехода. Необходимо определить, какие операции перейдут в&nbsp;новую систему, что произойдет с&nbsp;архивом, где потребуются интеграции и&nbsp;как они будут работать, а&nbsp;также каким образом будет организован переход пользователей. Отдельного внимания требуют правила переноса исторических данных и&nbsp;нефункциональные требования. Необходимо описать, как должна работать система, задать требования к&nbsp;отказоустойчивости и&nbsp;информационной безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Шаг&nbsp;3. Первичная настройка и&nbsp;кастомизация платформы. &lltt;/strong&ggtt;На&nbsp;этом этапе нужно настроить выбранную платформу или связку платформ: создать процессы, формы, роли и&nbsp;другие элементы, необходимые для работы решений, а&nbsp;также настроить права доступа, аналитику, уведомления, интеграции и&nbsp;маршруты согласования&nbsp;— все&nbsp;то, что обеспечивает функционирование&nbsp;ПО в&nbsp;рамках реальных рабочих процессов. Важно не&nbsp;стремиться к&nbsp;точному копированию старой системы, иначе есть риск перенести накопившиеся в&nbsp;ней проблемы в&nbsp;новый интерфейс; устаревшие процессы целесообразно собрать заново, проведя их&nbsp;аудит и&nbsp;оптимизацию.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Шаг&nbsp;4. Тестовый перенос ограниченного объема данных. &lltt;/strong&ggtt;В&nbsp;его рамках следует проверить, как в&nbsp;новую систему перемещаются задачи, поля, статусы и&nbsp;другие элементы. Особое внимание стоит уделить тому, что не&nbsp;перенеслось автоматически: как правило эта информация наиболее полезна для доработки процесса. В&nbsp;автоматическом режиме обычно переносятся задачи, описания и&nbsp;другие элементы, поддающиеся прямому сопоставлению. Однако корректность такого переноса напрямую зависит от&nbsp;точности карты соответствия полей между системами, особенно если платформы различаются по&nbsp;структуре данных. При этом важно четко определить назначение каждого элемента: без правильной интерпретации значений старых полей и&nbsp;статусов автоматизированный перенос данных может пройти некорректно. По&nbsp;итогам этого шага необходимо проанализировать миграционный отчет, однако не&nbsp;менее важна сама практика тестового переноса.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Шаг&nbsp;5. Проверка реальных пользовательских сценариев. &lltt;/strong&ggtt;На&nbsp;этом этапе в&nbsp;первую очередь тестируют пользовательский опыт: насколько удобно создавать заявки, согласовывать их&nbsp;и&nbsp;назначать исполнителей, работают&nbsp;ли переназначение по&nbsp;процессу, SLA и&nbsp;аналитика, закрываются&nbsp;ли обращения и&nbsp;насколько удовлетворены пользователи. Если все эти сценарии выполняются корректно, миграция становится не&nbsp;просто технически успешной, но&nbsp;и&nbsp;полезной для бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Шаг&nbsp;6. Итоговая промышленная миграция. &lltt;/strong&ggtt;Финальный этап&nbsp;— промышленная миграция, сопровождаемая волнами коммуникации с&nbsp;командами. Она должна стать не&nbsp;резким отключением старой системы, а&nbsp;плавным управляемым переходом, о&nbsp;котором заранее знают все участники и&nbsp;в&nbsp;рамках которого четко определены роли и&nbsp;зоны ответственности. Это исключает ситуации, в&nbsp;которых сотрудники месяцами дублируют работу в&nbsp;двух системах одновременно, и&nbsp;позволяет сервисным менеджерам бесшовно перейти на&nbsp;новую платформу.&lltt;/p&ggtt;
&lltt;h3&ggtt;Основные риски миграции&lltt;/h3&ggtt;
&lltt;p&ggtt;Если неправильно спланировать переход на&nbsp;новую платформу, можно нарушить уникальную бизнес-логику, зафиксированную в&nbsp;глубоких кастомизациях решений Atlassian. Это более серьезный риск, чем потерять данные. Даже если успешно перенести все задачи, комментарии и&nbsp;вложения, но&nbsp;упустить из&nbsp;виду правила согласования или автоматическое переназначение, бизнес-процесс не&nbsp;будет работать.&lltt;/p&ggtt;
&lltt;p&ggtt;Другой важный риск&nbsp;— сложности и&nbsp;ошибки при переносе исторических данных. Если таких записей накопилось много, перемещать весь массив может быть дорого, долго и&nbsp;нецелесообразно. Однако вовсе не&nbsp;перенести исторические данные&nbsp;— опасно для бизнеса. Разумным выбором станет категоризация элементов с&nbsp;учетом ценности и&nbsp;применения в&nbsp;рабочих процессах.&lltt;/p&ggtt;
&lltt;p&ggtt;Третий риск при миграции&nbsp;— неполный или некорректный перенос прав доступа и&nbsp;ролевых моделей. Следует отдельно планировать распределение прав на&nbsp;новой платформе: если они выйдут за&nbsp;нужные рамки, возникнут проблемы безопасности, а&nbsp;если слишком сильно ограничить доступ, пользователи не&nbsp;смогут нормально работать. Это особенно критично для сервисных процессов, HR-заявок, защиты данных, финансовых согласований, проектной документации и&nbsp;базы знаний.&lltt;/p&ggtt;
&lltt;p&ggtt;Четвертый риск&nbsp;— жесткая зависимость от&nbsp;приложений из&nbsp;Marketplace, у&nbsp;которых нет прямых аналогов. На&nbsp;старых версиях Atlassian одни и&nbsp;те&nbsp;же плагины могли работать годами. В&nbsp;таких случаях при миграции возникают вопросы, какую логику они используют, кто ее&nbsp;поддерживает, можно&nbsp;ли отказаться от&nbsp;этих приложений и&nbsp;есть&nbsp;ли у&nbsp;них аналоги. Иногда небольшой плагин оказывается самым критичным элементом всего бизнес-процесса, поэтому миграцию надо начинать с&nbsp;аудита, а&nbsp;не&nbsp;с&nbsp;выбора новой платформы.&lltt;/p&ggtt;
&lltt;p&ggtt;Наконец, главная ошибка&nbsp;— попытка перенести систему как есть, без предварительной оптимизации. При таком подходе вместе с&nbsp;полезными составляющими можно скопировать источники хаоса. Задача миграции не&nbsp;сохранить все плюсы и&nbsp;минусы старой системы, а&nbsp;обеспечить корректную работу процессов, убрать лишнее и&nbsp;выстроить эффективную архитектуру.&lltt;/p&ggtt;
&lltt;h3&ggtt;Безопасный переход&lltt;/h3&ggtt;
&lltt;p&ggtt;Сделать миграцию максимально комфортной и&nbsp;безопасной поможет в&nbsp;первую очередь отказ от&nbsp;переноса всех составляющих старой системы. Активные элементы можно добавить в&nbsp;рабочий контур, важные исторические данные&nbsp;— сохранить в&nbsp;архиве, а&nbsp;ненужные записи&nbsp;— удалить. Еще одним обязательным условием успеха станет тестовый перенос. Пилотная часть проекта поможет проверить критически важные узлы архитектуры и&nbsp;оценить реальную картину.&lltt;/p&ggtt;
&lltt;p&ggtt;Для компании, которая рассматривает миграцию с&nbsp;Atlassian, на&nbsp;первом плане должен быть не&nbsp;вопрос, работает&nbsp;ли платформа сегодня, а&nbsp;возможность безопасно выстраивать процессы на&nbsp;ее&nbsp;базе в&nbsp;перспективе. Если слишком долго откладывать переход на&nbsp;новую систему, можно оказаться в&nbsp;ситуации, когда поддерживать старые решения слишком дорого, а&nbsp;отказаться от&nbsp;них слишком сложно. В&nbsp;связи с&nbsp;этим лучше заранее выстроить на&nbsp;основе отечественного&nbsp;ПО новую жизнеспособную архитектуру, которая будет получать официальную поддержку и&nbsp;эволюционировать вместе с&nbsp;бизнес-процессами компании.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235418#&lltt;/p&ggtt;]]></source>
<adate>28.08.2026</adate>
<dbid>235417</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/f44/dsk8077h87jy61fb6vlagjk8rco6c1ta.jpg]]>
</images>
<imagesname><![CDATA[;;Константин Преображенский, начальник отдела аналитики и проектов IBS   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Обновление платформы SimpleOne 1.35.0 сокращает объём ручной настройки SLA и рабочих процессов]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235416]]></link>
<description><![CDATA[SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI платформы. Обновление позволяет снизить нагрузку на администраторов системы и сократить количество ручных действий за счет гибкой настройки индикаторов SLA и копирования блоков рабочих процессов, а также упрощает работу с записями в связанных списках благодаря добавлению поддержки массового редактирования. Ключевое изменение версии 1.35.0 — более гибкая настройка индикаторов SLA. Теперь параметры расчёта индикации — момент запуска отсчёта, момент превышения срока, рабочее расписание и часовой пояс — можно определять не только вручную, но и на основании данных из связанных с обращением записей. Такая функциональность полезна в территориально распределённых компаниях. Например, сроки по заявке нужно считать по графику той площадки, которая обслуживает сотрудника: у сотрудника указан город, у города — обслуживающая площадка, у площадки — свой рабочий календарь и часовой пояс. Раньше под каждый календарь приходилось заводить отдельный индикатор, клиенты компании сообщали о 10–15 копиях одного и того же SLA. Теперь достаточно одного индикатора: он проходит по цепочке связей и охватывает нужные параметры сам. Календарь — только один из параметров, по тому же механизму задаются часовой пояс и обе временны́е точки. При этом источником служит любая связанная с обращением запись, то есть под контекст подстраивается не отдельный сценарий, а расчёт SLA целиком. Второе значимое улучшение — добавление возможности копирования блоков в редакторе рабочих процессов. Администраторы теперь могут копировать блок действий в текущие процессы, а также другие рабочие процессы, сохранив все параметры настройки. Новая функциональность заметно ускоряет настройку процессов и сокращает количество ошибок при настройке. Дополнительно были расширены возможности массового редактирования: теперь редактирование поддерживается не только в основных списках записей, но и в связанных списках. Администраторы и агенты поддержки могут быстро вносить одинаковые изменения сразу в несколько записей, без необходимости переходить в отдельное представление списка. «Мы сознательно сосредоточились на участках, где у администраторов больше всего рутины: гибкие SLA и переиспользование блоков рабочих процессов. Для нас стоимость владения системой — отдельное направление развития в каждом релизе. Мы считаем, что платформа должна дешеветь в сопровождении по мере роста конфигурации, не наоборот. Ведь именно от нагрузки, связанной с поддержкой системы, зависит, сколько времени и ресурсов команда клиента сможет потратить на ее развитие», — прокомментировал Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG. Помимо новой функциональности, в версии 1.35.0 устранён ряд дефектов, включая проблемы с контейнерами, уязвимости безопасности и ошибки в работе индикаций]]></description>
<source><![CDATA[&lltt;p&ggtt;SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI&nbsp;платформы. Обновление позволяет снизить нагрузку на&nbsp;администраторов системы и&nbsp;сократить количество ручных действий за&nbsp;счет гибкой настройки индикаторов SLA и&nbsp;копирования блоков рабочих процессов, а&nbsp;также упрощает работу с&nbsp;записями в&nbsp;связанных списках благодаря добавлению поддержки массового редактирования.&lltt;/p&ggtt;
&lltt;p&ggtt;Ключевое изменение версии 1.35.0&nbsp;— более гибкая настройка индикаторов SLA. Теперь параметры расчёта индикации&nbsp;— момент запуска отсчёта, момент превышения срока, рабочее расписание и&nbsp;часовой пояс&nbsp;— можно определять не&nbsp;только вручную, но&nbsp;и&nbsp;на&nbsp;основании данных из&nbsp;связанных с&nbsp;обращением записей. &lltt;/p&ggtt;
&lltt;p&ggtt;Такая функциональность полезна в&nbsp;территориально распределённых компаниях. Например, сроки по&nbsp;заявке нужно считать по&nbsp;графику той площадки, которая обслуживает сотрудника: у&nbsp;сотрудника указан город, у&nbsp;города&nbsp;— обслуживающая площадка, у&nbsp;площадки&nbsp;— свой рабочий календарь и&nbsp;часовой пояс. Раньше под каждый календарь приходилось заводить отдельный индикатор, клиенты компании сообщали о&nbsp;&lltt;nobr&ggtt;10–15&lltt;/nobr&ggtt; копиях одного и&nbsp;того&nbsp;же SLA. Теперь достаточно одного индикатора: он&nbsp;проходит по&nbsp;цепочке связей и&nbsp;охватывает нужные параметры сам. Календарь&nbsp;— только один из&nbsp;параметров, по&nbsp;тому&nbsp;же механизму задаются часовой пояс и&nbsp;обе временны́е точки. При этом источником служит любая связанная с&nbsp;обращением запись, то&nbsp;есть под контекст подстраивается не&nbsp;отдельный сценарий, а&nbsp;расчёт SLA целиком.&lltt;/p&ggtt;
&lltt;p&ggtt;Второе значимое улучшение&nbsp;— добавление возможности копирования блоков в&nbsp;редакторе рабочих процессов. Администраторы теперь могут копировать блок действий в&nbsp;текущие процессы, а&nbsp;также другие рабочие процессы, сохранив все параметры настройки. Новая функциональность заметно ускоряет настройку процессов и&nbsp;сокращает количество ошибок при настройке.&lltt;/p&ggtt;
&lltt;p&ggtt;Дополнительно были расширены возможности массового редактирования: теперь редактирование поддерживается не&nbsp;только в&nbsp;основных списках записей, но&nbsp;и&nbsp;в&nbsp;связанных списках. Администраторы и&nbsp;агенты поддержки могут быстро вносить одинаковые изменения сразу в&nbsp;несколько записей, без необходимости переходить в&nbsp;отдельное представление списка.&lltt;/p&ggtt;
&lltt;p&ggtt;«Мы&nbsp;сознательно сосредоточились на&nbsp;участках, где у&nbsp;администраторов больше всего рутины: гибкие SLA и&nbsp;переиспользование блоков рабочих процессов. Для нас стоимость владения системой&nbsp;— отдельное направление развития в&nbsp;каждом релизе. Мы&nbsp;считаем, что платформа должна дешеветь в&nbsp;сопровождении по&nbsp;мере роста конфигурации, не&nbsp;наоборот. Ведь именно от&nbsp;нагрузки, связанной с&nbsp;поддержкой системы, зависит, сколько времени и&nbsp;ресурсов команда клиента сможет потратить на&nbsp;ее&nbsp;развитие»,&nbsp;— прокомментировал Илья Радченко, директор по&nbsp;платформенным продуктам SimpleOne, корпорация ITG.&lltt;/p&ggtt;
&lltt;p&ggtt;Помимо новой функциональности, в&nbsp;версии 1.35.0 устранён ряд дефектов, включая проблемы с&nbsp;контейнерами, уязвимости безопасности и&nbsp;ошибки в&nbsp;работе индикаций. &lltt;/p&ggtt;]]></source>
<adate>26.08.2026</adate>
<dbid>235416</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[ИСИЭЗ НИУ ВШЭ: трансформация профессиональных компетенций под влиянием ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235414]]></link>
<description><![CDATA[Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие решения на базе ИИ: постоянное взаимодействие с технологией дает им комплексное представление о ее возможностях, ограничениях и влиянии на рынок труда. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил прогнозные оценки более 500 таких организаций, полученные в рамках Мониторинга разработки и применения технологий искусственного интеллекта и цифровой трансформации бизнеса. В работе с информацией направление изменений зависит от характера выполняемых задач. Спрос на базовые навыки, связанные с вводом данных и подготовкой документации, будет в целом снижаться (сокращение прогнозируют 45% организаций, рост — 25%), а на аналитические компетенции — расти (36% против 27% прогнозирующих снижение). ИИ автоматизирует рутинные операции, однако постановка задач, интерпретация выводов и принятие решений сохранятся за специалистами. Для ИТ-навыков оценки влияния ИИ оказались неоднозначными. Снижение спроса на навыки программирования прогнозируют 30% организаций, рост — 29%, стабильность — 34%. Автоматизация части работы с кодом может сдерживать найм, однако усложнение программных продуктов и интеграция ИИ-моделей одновременно повышают потребность в технической экспертизе. Востребованность навыков установки и защиты компьютерных систем оценивается более определенно: роста спроса ожидают 38% респондентов, снижения — лишь 11%. Вероятно, увеличение объема генерируемого ИИ кода и применение технологии для кибератак повышают потребность в квалифицированном контроле, настройке и защите систем. В менеджменте центр тяжести будет смещаться от администрирования к стратегии и лидерству. Снижение управленческих рутин прогнозируют 35% организаций, рост — 26%. При этом повышения востребованности стратегического мышления и навыков управления процессами ожидают 41% респондентов, лидерства и мотивации — 36%; снижение спроса на эти навыки предполагают лишь 6 и 4% соответственно. Документооборот, календарное планирование и контроль отчетности поддаются автоматизации, тогда как выбор приоритетов, разрешение конфликтов, мотивация команды и формирование среды доверия остаются за руководителями. Для рабочих профессий уязвимость перед ИИ зависит прежде всего от степени стандартизации операций и разнообразия условий труда. В обследовании сопоставлялись навыки разного уровня квалификации — от вождения и обслуживания оборудования до сортировки, погрузки, сборки и строительства. Наиболее высок риск снижения спроса на сортировку и упаковку: сокращение прогнозируют 29% организаций, рост — 16%. Значительно устойчивее монтаж и ремонт оборудования (снижение ожидают только 6%, рост — 24%) и строительство (снижение — 8%; две трети респондентов предполагают сохранение или рост спроса). В отношении вождения оценки разделились: 21% ожидают сокращения востребованности, 22% — повышения. Повторяющиеся операции в стабильных условиях легче передать роботизированным системам, тогда как работа в изменчивой среде пока требует человеческой адаптивности. В долгосрочной перспективе развитие робототехники и автономных систем будет расширять границы автоматизации. Высокой устойчивостью к ИИ-автоматизации обладают человекоориентированные компетенции: уход за людьми, оказание медицинских услуг, коммуникации, сотрудничество, консультирование, креативность. Наименее уязвимы навыки, основанные на командной работе, общении, доверии и физическом присутствии: снижение спроса на них прогнозируют лишь 9–13%. Более неоднозначно оценивается креативность: роста ее востребованности ожидают 28% респондентов, снижения — 23%. С одной стороны, ИИ уже способен генерировать тексты и изображения, с другой — снижает порог входа в креативную деятельность, беря на себя технические задачи и тем самым создавая возможности для новых замыслов и подходов. Изменения профессиональных компетенций затронут большинство профессий. Риски и возможности, которые несет ИИ, определяются не статусом профессии или уровнем квалификации работников, а содержанием выполняемых задач. Повторяющиеся стандартизированные задачи, которые можно описать с помощью инструкций и алгоритмов, в перспективе будут переданы ИИ, а необходимые для их выполнения навыки потеряют ценность. Одновременно увеличится спрос на компетенции более высокого порядка, связанные с принятием решений в условиях неопределенности, лидерством, командной работой, обеспечением безопасности. Итоговый баланс оценок подтверждает этот сдвиг: верхние позиции заняли стратегическое управление, лидерство и мотивация, установка и защита компьютерных систем, нижние — документирование информации, сортировка и упаковка, простые административные задачи]]></description>
<source><![CDATA[&lltt;p&ggtt;Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие решения на базе ИИ: постоянное взаимодействие с технологией дает им комплексное представление о ее возможностях, ограничениях и влиянии на рынок труда. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил прогнозные оценки более 500 таких организаций, полученные в рамках Мониторинга разработки и применения технологий искусственного интеллекта и цифровой трансформации бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;В работе с информацией направление изменений зависит от характера выполняемых задач. Спрос на базовые навыки, связанные с вводом данных и подготовкой документации, будет в целом снижаться (сокращение прогнозируют 45% организаций, рост — 25%), а на аналитические компетенции — расти (36% против 27% прогнозирующих снижение). ИИ автоматизирует рутинные операции, однако постановка задач, интерпретация выводов и принятие решений сохранятся за специалистами.&lltt;/p&ggtt;
&lltt;p&ggtt;Для ИТ-навыков оценки влияния ИИ оказались неоднозначными. Снижение спроса на навыки программирования прогнозируют 30% организаций, рост — 29%, стабильность — 34%. Автоматизация части работы с кодом может сдерживать найм, однако усложнение программных продуктов и интеграция ИИ-моделей одновременно повышают потребность в технической экспертизе. Востребованность навыков установки и защиты компьютерных систем оценивается более определенно: роста спроса ожидают 38% респондентов, снижения — лишь 11%. Вероятно, увеличение объема генерируемого ИИ кода и применение технологии для кибератак повышают потребность в квалифицированном контроле, настройке и защите систем.&lltt;/p&ggtt;
&lltt;p&ggtt;В менеджменте центр тяжести будет смещаться от администрирования к стратегии и лидерству. Снижение управленческих рутин прогнозируют 35% организаций, рост — 26%. При этом повышения востребованности стратегического мышления и навыков управления процессами ожидают 41% респондентов, лидерства и мотивации — 36%; снижение спроса на эти навыки предполагают лишь 6 и 4% соответственно. Документооборот, календарное планирование и контроль отчетности поддаются автоматизации, тогда как выбор приоритетов, разрешение конфликтов, мотивация команды и формирование среды доверия остаются за руководителями.&lltt;/p&ggtt;
&lltt;p&ggtt;Для рабочих профессий уязвимость перед ИИ зависит прежде всего от степени стандартизации операций и разнообразия условий труда. В обследовании сопоставлялись навыки разного уровня квалификации — от вождения и обслуживания оборудования до сортировки, погрузки, сборки и строительства. Наиболее высок риск снижения спроса на сортировку и упаковку: сокращение прогнозируют 29% организаций, рост — 16%. Значительно устойчивее монтаж и ремонт оборудования (снижение ожидают только 6%, рост — 24%) и строительство (снижение — 8%; две трети респондентов предполагают сохранение или рост спроса). В отношении вождения оценки разделились: 21% ожидают сокращения востребованности, 22% — повышения. Повторяющиеся операции в стабильных условиях легче передать роботизированным системам, тогда как работа в изменчивой среде пока требует человеческой адаптивности. В долгосрочной перспективе развитие робототехники и автономных систем будет расширять границы автоматизации.&lltt;/p&ggtt;
&lltt;p&ggtt;Высокой устойчивостью к ИИ-автоматизации обладают человекоориентированные компетенции: уход за людьми, оказание медицинских услуг, коммуникации, сотрудничество, консультирование, креативность. Наименее уязвимы навыки, основанные на командной работе, общении, доверии и физическом присутствии: снижение спроса на них прогнозируют лишь &lltt;nobr&ggtt;9–13%.&lltt;/nobr&ggtt; Более неоднозначно оценивается креативность: роста ее востребованности ожидают 28% респондентов, снижения — 23%. С одной стороны, ИИ уже способен генерировать тексты и изображения, с другой — снижает порог входа в креативную деятельность, беря на себя технические задачи и тем самым создавая возможности для новых замыслов и подходов.&lltt;/p&ggtt;
&lltt;p&ggtt;Изменения профессиональных компетенций затронут большинство профессий. Риски и возможности, которые несет ИИ, определяются не статусом профессии или уровнем квалификации работников, а содержанием выполняемых задач. Повторяющиеся стандартизированные задачи, которые можно описать с помощью инструкций и алгоритмов, в перспективе будут переданы ИИ, а необходимые для их выполнения навыки потеряют ценность. Одновременно увеличится спрос на компетенции более высокого порядка, связанные с принятием решений в условиях неопределенности, лидерством, командной работой, обеспечением безопасности. Итоговый баланс оценок подтверждает этот сдвиг: верхние позиции заняли стратегическое управление, лидерство и мотивация, установка и защита компьютерных систем, нижние — документирование информации, сортировка и упаковка, простые административные задачи.&lltt;/p&ggtt;]]></source>
<adate>26.08.2026</adate>
<dbid>235414</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[В России создали новую методологию GenAI-driven разработки дата-продуктов]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235415]]></link>
<description><![CDATA[Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное, безопасное и системное использование инструментов генеративного ИИ для проектов по интеграции данных и разработке дата-продуктов. Новый подход призван перевести корпоративные ИИ-эксперименты из режима точечного применения в управляемый процесс с прозрачными расчетами, которые опираются на отслеживаемые данные и дают контролируемый результат. Методология предназначена для компаний, которые уже используют или планируют использовать LLM-инструменты и ИИ-агентов в разработке решений по управлению данными. В ее основе лежит концепция Data Governance, переосмысленная с учетом современных возможностей генеративного ИИ. Дата-продукты являются разновидностью программного обеспечения, однако обладают целым рядом особенностей, требующих отдельной методики разработки. В традиционной разработке основной фокус сосредоточен на функциях продукта: интерфейсе, бизнес-логике, пользовательских сценариях, фронтенде и бэкенде. В случае с дата-продуктами он направлен преимущественно на сами данные — их происхождение, определения, взаимосвязи, контекст и правила интерпретации. Ключевая задача методологии — сделать так, чтобы данным можно было верить. В корпоративной среде недостаточно получить цифру, которая выглядит правдоподобно. Важно понимать, из каких источников она получена, по каким правилам рассчитана, какие исходные данные использовались, кто отвечает за определения, можно ли воспроизвести расчет и т.п. Качество данных особенно важно для бизнес-аналитики, управленческой и регуляторной отчетности. Ошибка в одном показателе или неоднозначность в трактовке данных может привести к неверным руководящим решениям, в том числе стратегическим, а также к претензиям со стороны надзорных органов. Предложенный подход включает ряд ключевых этапов: 	оценку текущей зрелости компании в работе с данными и ИИ-инструментами; 	адаптацию методологии к конкретным бизнес-реалиям и ИТ-ландшафту; 	определение функциональной архитектуры будущей системы; 	анализ уже существующих инструментов Data Governance, каталогов, глоссариев и средств контроля качества данных; 	выявление недостающих элементов; 	выбор инструментов для поддержки целевого процесса; 	запуск пилотного проекта по созданию дата-продукта по новой методике; 	формирование контекстного и семантического слоя для уже существующих источников. Методология вводит понятие опорного слоя и придает ему особое значение. Опорный слой включает в себя онтологию и семантику, а также так называемый контур доверия. Без него невозможно обеспечить единое понимание бизнес-понятий, метрик и правил интерпретации данных на уровне всей компании. Именно опорный слой должен стать связующим элементом между бизнес-смыслом, источниками данных, методиками расчета показателей и ИИ-инструментами, которые участвуют в разработке, а в дальнейшем, и потреблении данных. Методология также предполагает бережное отношение к уже сделанным компанией инвестициям. Если у нее есть каталоги данных, бизнес-глоссарии, инструменты контроля качества или другие элементы Data Governance, их не нужно заменять автоматически. В них уже накоплены метаданные, определения и управленческий контекст. Задача состоит в том, чтобы встроить существующие активы в новую архитектуру, определить недостающие элементы и обеспечить совместимость старого и нового подходов. «Есть иллюзия, что с помощью ИИ можно в считанные минуты сгенерировать нужное приложение, имея только бизнес-идею. На самом деле это не так просто, особенно в отношении дата-продуктов. Крайне важно определить для ИИ „смысл“ данных компании, погрузить его в контекст. В противном случае есть серьезный риск получить „черный ящик“, корректность и безопасность работы которого невозможно проверить. Наша методология объясняет, как сформировать грамотную среду управления данными и построить взаимодействие с ИИ так, чтобы дата-продукты были предсказуемыми, прозрачными и воспроизводимыми и как результат, давали корректную аналитику», — прокомментировала Лариса Малькова, управляющий директор практики «Данные и прикладной ИИ» Axenix]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное, безопасное и системное использование инструментов генеративного ИИ для проектов по интеграции данных и разработке дата-продуктов. Новый подход призван перевести корпоративные ИИ-эксперименты из режима точечного применения в управляемый процесс с прозрачными расчетами, которые опираются на отслеживаемые данные и дают контролируемый результат. &lltt;/p&ggtt;
&lltt;p&ggtt;Методология предназначена для компаний, которые уже используют или планируют использовать &lltt;nobr&ggtt;LLM-инструменты&lltt;/nobr&ggtt; и ИИ-агентов в разработке решений по управлению данными. &lltt;/p&ggtt;
&lltt;p&ggtt;В ее основе лежит концепция Data Governance, переосмысленная с учетом современных возможностей генеративного ИИ. Дата-продукты являются разновидностью программного обеспечения, однако обладают целым рядом особенностей, требующих отдельной методики разработки. В традиционной разработке основной фокус сосредоточен на функциях продукта: интерфейсе, бизнес-логике, пользовательских сценариях, фронтенде и бэкенде. В случае с дата-продуктами он направлен преимущественно на сами данные — их происхождение, определения, взаимосвязи, контекст и правила интерпретации. &lltt;/p&ggtt;
&lltt;p&ggtt;Ключевая задача методологии — сделать так, чтобы данным можно было верить. В корпоративной среде недостаточно получить цифру, которая выглядит правдоподобно. Важно понимать, из каких источников она получена, по каким правилам рассчитана, какие исходные данные использовались, кто отвечает за определения, можно ли воспроизвести расчет и т.п. Качество данных особенно важно для бизнес-аналитики, управленческой и регуляторной отчетности.&lltt;/p&ggtt;
&lltt;p&ggtt;Ошибка в одном показателе или неоднозначность в трактовке данных может привести к неверным руководящим решениям, в том числе стратегическим, а также к претензиям со стороны надзорных органов.&lltt;/p&ggtt;
&lltt;p&ggtt;Предложенный подход включает ряд ключевых этапов:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;оценку текущей зрелости компании в работе с данными и ИИ-инструментами;&lltt;/li&ggtt;
	&lltt;li&ggtt;адаптацию методологии к конкретным бизнес-реалиям и ИТ-ландшафту;&lltt;/li&ggtt;
	&lltt;li&ggtt;определение функциональной архитектуры будущей системы;&lltt;/li&ggtt;
	&lltt;li&ggtt;анализ уже существующих инструментов Data Governance, каталогов, глоссариев и средств контроля качества данных;&lltt;/li&ggtt;
	&lltt;li&ggtt;выявление недостающих элементов;&lltt;/li&ggtt;
	&lltt;li&ggtt;выбор инструментов для поддержки целевого процесса;&lltt;/li&ggtt;
	&lltt;li&ggtt;запуск пилотного проекта по созданию дата-продукта по новой методике;&lltt;/li&ggtt;
	&lltt;li&ggtt;формирование контекстного и семантического слоя для уже существующих источников.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Методология вводит понятие опорного слоя и придает ему особое значение. Опорный слой включает в себя онтологию и семантику, а также так называемый контур доверия. Без него невозможно обеспечить единое понимание бизнес-понятий, метрик и правил интерпретации данных на уровне всей компании. Именно опорный слой должен стать связующим элементом между бизнес-смыслом, источниками данных, методиками расчета показателей и ИИ-инструментами, которые участвуют в разработке, а в дальнейшем, и потреблении данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Методология также предполагает бережное отношение к уже сделанным компанией инвестициям. Если у нее есть каталоги данных, бизнес-глоссарии, инструменты контроля качества или другие элементы Data Governance, их не нужно заменять автоматически. В них уже накоплены метаданные, определения и управленческий контекст. Задача состоит в том, чтобы встроить существующие активы в новую архитектуру, определить недостающие элементы и обеспечить совместимость старого и нового подходов.&lltt;/p&ggtt;
&lltt;p&ggtt;«Есть иллюзия, что с помощью ИИ можно в считанные минуты сгенерировать нужное приложение, имея только бизнес-идею. На самом деле это не так просто, особенно в отношении дата-продуктов. Крайне важно определить для ИИ „смысл“ данных компании, погрузить его в контекст. В противном случае есть серьезный риск получить „черный ящик“, корректность и безопасность работы которого невозможно проверить. Наша методология объясняет, как сформировать грамотную среду управления данными и построить взаимодействие с ИИ так, чтобы дата-продукты были предсказуемыми, прозрачными и воспроизводимыми и как результат, давали корректную аналитику», — прокомментировала Лариса Малькова, управляющий директор практики «Данные и прикладной ИИ» Axenix.&lltt;/p&ggtt;]]></source>
<adate>26.08.2026</adate>
<dbid>235415</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[РУССОФТ: инвестиционная активность в софтверной индустрии в 2025 году предсказуемо снизилась]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235413]]></link>
<description><![CDATA[Рост инвестиций в развитие российских софтверных компаний, который достигал примерно 30-35% в 2024 году, в 2025 году сменился их сокращением на 37%. Абсолютная величина совокупных инвестиций уменьшилась с ₽575 млрд. до ₽360 млрд. В условиях отсутствия других полноценных источников инвестиций почти вся прибыль предприятий, специализирующихся на разработке ПО, направляется на развитие, поэтому увеличение налоговой нагрузки неизбежно привело к сокращению инвестиционной активности. Напомним, что с 1 января 2025 года был введен НДС для малых компаний, использующих УСН, а вместо нулевого налога на прибыль для аккредитованных ИТ-компаний введена ставка в размере 5%. Математически само по себе увеличение отчислений в бюджет могло дать сокращение только на 5-10%. На увеличение налоговой нагрузки наложилось снижение темпов роста спроса из-за высокой ставки ЦБ РФ и ряда других факторов. В результате продажи компаний-разработчиков ПО росли медленнее их затрат, а это привело к снижению рентабельности софтверного бизнеса. Основные показатели, характеризующие инвестиционную активность в софтверной индустрии в 2024-2026 годах 	 		 			 			 				2024 г. 			 			 				2025 г. 			 			 				2026 г. (прогноз) 			 		 		 			 				Отношение совокупных инвестиций к совокупному обороту софтверных компаний 			 			 				23,5% 			 			 				12,8% 			 			 				13,0% 			 		 		 			 				Объем инвестиций 			 			 				₽575 млрд 			 			 				₽360 млрд 			 			 				₽425 млрд 			 		 		 			 				Доля опрошенных компаний, сообщивших о привлечении инвестиций 			 			 				47,2% 			 			 				38,0% 			 			 				35,3% 			 		 		 			 				Доля внешнего финансирования в общем объеме инвестиций 				 			 			 				19,3% 			 			 				17,7% 			 			 				19,0% 			 		 		 			 				Доля опрошенных компаний, сообщивших о наличии внешних инвестиций 			 			 				27,4% 			 			 				25,5% 			 			 				25,1% 			 		 		 			 				Общий объем внешних инвестиций 			 			 				₽110 млрд 			 			 				₽64 млрд 			 			 				₽81 млрд 			 		 	 Ассоциация РУССОФТ проводила в 2025 году экспресс-опросы софтверных компаний с целью моделирования изменения ряда показателей финансового состояния бизнеса при сохранении всех льгот и при частичном лишении налоговых послаблений. Результаты этих опросов показали, что увеличение налоговой нагрузки негативно отразится прежде всего на объеме инвестиций. При нынешних условиях в софтверной индустрии существует прямая корреляция совокупной прибыли софтверных компаний и совокупных вложений в их развитие. Поскольку совокупная чистая прибыль по итогам 2025 года сократилась примерно на треть, то и почти аналогично снизился объем инвестиций в софтверной индустрии. С 1 января 2026 года было введено еще одно изменение в налоговой политике — страховые взносы для аккредитованных ИТ-компаний увеличились примерно вдвое (с 7,6% до 15%). С учетом того, что 60-80% затрат софтверных компаний приходится на фонд оплаты труда, дополнительные отчисления существенно сокращают прибыль при прочих равных условиях. Тем не менее, результаты опроса показывают сдержанный оптимизм. Расчеты на основании планов опрошенных компаний на 2026 год дают рост совокупных инвестиций на 18%. Предположительно выручка увеличится на 17%, чуть возрастет доля внешнего финансирования (с 17,7% до 19,0%), а дополнительные отчисления в пенсионный и социальные фонды частично компенсирует снижение темпов роста средней зарплаты. Прибавка на 18% отражает скорее самый оптимистический сценарий. Реалистичный же предполагает меньший прирост. При этом нельзя исключить и сокращение инвестиций. Показатель удовлетворенности респондентов имеющимся объемом инвестиций, как правило, очень низкий. Опрашиваемые компании в течение нескольких лет видели перспективы окупаемости при вложениях, которые должны были быть в 2-3 раза больше фактических. Произошедший в 2021 году инвестиционный бум привел к тому, что потребность в инвестициях в индустрию была удовлетворена намного лучше, чем в предыдущие годы — на 58%. В 2022 году произошел рост показателя удовлетворенности респондентами объемами финансовых вложений до 63%, но этот год был особенным: из-за высокой степени неопределенности не столько выросли вложения, сколько снизилась в них потребность. В 2023 году показатель удовлетворенности снизился до 51%, а в 2024 году — до 42%. Уменьшение этого показателя при росте объема инвестиций говорит о том, что потребность в инвестициях росла быстрее, чем объем инвестиций в развитие софтверных компаний, что было объяснимо на фоне активной реализации процесса импортозамещения ПО. По итогам 2025 года показатель удовлетворенности в инвестициях уменьшился еще больше. По всем опрошенным компаниям фактические вложения составили менее четверти от требуемых (23,5%). Если опираться на ожидания опрошенных компаний, то в 2026 году этот показатель должен повыситься, но все же останется очень низким — 27,2%. Удовлетворенность в объеме инвестиций ниже у продуктовых компаний в сравнении с сервисными, что объясняется их потребностью в разработке собственного программного продукта, что занимает длительное время. Распределение стабильно По итогам 2024 года доля собственных инвестиций софтверных компаний составила 77,3%. В 2025 году изменение этого показателя оказалось незначительным. В 2026 году имеются надежды на небольшое увеличение внешнего финансирования (прежде всего, государственного), но структура инвестиций в целом ожидается неизменной при допущении незначительных колебаний. Распределение объема инвестиций в индустрию программного обеспечения по источникам финансирования (по итогам 2024-2026 годов) 	 		 			 			 				2024 г. 			 			 				2025 г. 			 			 				2026 г. (прогноз) 			 		 		 			 				Собственные вложения (реинвестиции из прибыли) 			 			 				77,3% 			 			 				76,8% 			 			 				74,8% 			 		 		 			 				Дополнительные вложения учредителей 			 			 				3,5% 			 			 				5,6% 			 			 				6,2% 			 		 		 			 				Полученные от заказчиков/клиентов средства, которые пошли на развитие (создание новых тиражируемых решений или новых версий уже существующих решений) 			 			 				15,7% 			 			 				13,85% 			 			 				14,4% 			 		 		 			 				Государственное финансирование (без участия частных инвесторов), включая гранты и субсидирование льготного кредитования 			 			 				1,9% 			 			 				1,6% 			 			 				4,3% 			 		 		 			 				Вложения сторонних частных инвесторов (в т. ч. фондовый рынок, венчурные фонды, включая созданные с участием государства) 			 			 				0,4% 			 			 				2,15% 			 			 				0,3% 			 		 		 			 				Другие источники 			 			 				1,2% 			 			 				— 			 			 				— 			 		 	 Если при анализе данных по распределению инвестиций между собственными и привлеченными средствами по итогам 2025 года к собственным средствам добавить инвестиции со стороны учредителей, то эта доля увеличится до 82,4%. Следовательно, на все источники внешнего финансирования приходится 17,6%. Годом ранее этот показатель был равен 19,2%. Вложения сторонних частных инвесторов обеспечивают 2,15% общего объема инвестиций, а годом ранее они составляли 0,4%. Однако делать вывод о каком-то росте активности частных инвесторов пока преждевременно. При единичных случаях привлечения внешних инвесторов очень велико влияние случайных факторов. Рост до 2,15% в 2025 году обеспечила одна компания, участвовавшая в опросе. Без учета ее данных такого роста не будет. К тому же, в 2026 году ожидается возвращение участия внешних источников инвестиций к прежнему уровню. Самые привлекательные При делении компаний на категории выяснилось, что у компаний с выручкой менее ₽375 млн. в 2025 году имелась бОльшая доля внешних инвестиций в общем объеме вложений, чем у компаний большего размера. Аналогичное преимущество имелось у небольших предприятий по итогам 2024 года. Соотношение общего объема вложений к обороту у них также выше, чем у компаний с выручкой более ₽375 млн. Продуктовая модель предполагает бОльшую инвестиционную привлекательность в сравнении с сервисной. Однако доля внешнего финансирования в общем объеме инвестиций в 2024-2025 годах была выше именно у сервисных компаний. Это, скорее всего, связано с меньшими рисками для внешних инвесторов из-за более коротких сроков окупаемости, и с более низкой рентабельностью, а значит меньшим объемом наличия у них собственных средств для инвестиций. Если по итогам 2024 года соотношение объема инвестиций в развитие относительно оборота были выше у компаний, которые работают только в России в сравнении с предприятиями, имеющими продажи за рубежом, то по итогам 2025 года произошло выравнивание показателей у этих двух категорий компаний. Данные об инвестициях по категориям опрошенных компаний по итогам 2025 года 	 		 			 			 				Объем инвестиций по отношению к обороту 				 			 			 				Сообщили о наличии инвестиций в 2025 г.,% опрошенных компаний 				 			 			 				Доля внешнего финансирования во всём объеме инвестиций 			 			 				Сообщили о наличии внешнего финансирования в 2025 г.,% опрошенных компаний 				 			 		 		 			 				Все опрошенные компании 			 			 				13,8% 			 			 				38,0% 			 			 				9,9% 			 			 				25,5% 			 		 		 			 				Размер компаний 			 		 		 			 				Оборот менее ₽375 млн 				 			 			 				24,2% 			 			 				35,7% 			 			 				19,4% 			 			 				24,2% 			 		 		 			 				Оборот более ₽375 млн 				 			 			 				13,1% 			 			 				43,8% 			 			 				8,9% 			 			 				28,8% 			 		 		 			 				Модель бизнеса 			 		 		 			 				Продуктовая 			 			 				15,0% 			 			 				42,6% 			 			 				8,6% 			 			 				23,6% 			 		 		 			 				Сервисная 			 			 				6,8% 			 			 				31,8% 			 			 				22,4% 			 			 				28,0% 			 		 		 			 				Наличие экспортных доходов 			 		 		 			 				Не присутствовали за рубежом в 2025 г. 				 			 			 				14,8% 			 			 				33,9% 			 			 				11,5% 			 			 				26,3% 			 		 		 			 				Присутствовали за рубежом в 2025 г. 				 			 			 				12,5% 			 			 				39,5% 			 			 				9,8% 			 			 				18,6% 			 		 		 			 				Местоположение головного офиса 			 		 		 			 				Москва 			 			 				14,3% 			 			 				39,7% 			 			 				17,2% 			 			 				23,8% 			 		 		 			 				Петербург 			 			 				13,2% 			 			 				38,8% 			 			 				10,8% 			 			 				24,5% 			 		 		 			 				Другие города 			 			 				13,6% 			 			 				37,1% 			 			 				7,1% 			 			 				26,6% 			 		 	 ]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Рост инвестиций в&nbsp;развитие российских софтверных компаний, который достигал примерно &lltt;nobr&ggtt;30-35%&lltt;/nobr&ggtt; в&nbsp;2024&nbsp;году, в&nbsp;2025 году сменился их&nbsp;сокращением на&nbsp;37%. Абсолютная величина совокупных инвестиций уменьшилась с ₽575&nbsp;млрд.&nbsp;до ₽360&nbsp;млрд.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;условиях отсутствия других полноценных источников инвестиций почти вся прибыль предприятий, специализирующихся на&nbsp;разработке&nbsp;ПО, направляется на&nbsp;развитие, поэтому увеличение налоговой нагрузки неизбежно привело к&nbsp;сокращению инвестиционной активности. Напомним, что с&nbsp;1&nbsp;января 2025 года был введен НДС для малых компаний, использующих УСН, а&nbsp;вместо нулевого налога на&nbsp;прибыль для аккредитованных ИТ-компаний введена ставка в&nbsp;размере 5%.&lltt;/p&ggtt;
&lltt;p&ggtt;Математически само по&nbsp;себе увеличение отчислений в&nbsp;бюджет могло дать сокращение только на&nbsp;&lltt;nobr&ggtt;5-10%.&lltt;/nobr&ggtt; На&nbsp;увеличение налоговой нагрузки наложилось снижение темпов роста спроса из-за высокой ставки ЦБ&nbsp;РФ&nbsp;и&nbsp;ряда других факторов. В&nbsp;результате продажи компаний-разработчиков ПО&nbsp;росли медленнее их&nbsp;затрат, а&nbsp;это привело к&nbsp;снижению рентабельности софтверного бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Основные показатели, характеризующие инвестиционную активность в&nbsp;софтверной индустрии в&nbsp;&lltt;nobr&ggtt;2024-2026&lltt;/nobr&ggtt; годах&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; &lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2024&nbsp;г.&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2025&nbsp;г.&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2026&nbsp;г. (прогноз)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Отношение совокупных инвестиций к&nbsp;совокупному обороту софтверных компаний&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;23,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;12,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;13,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Объем инвестиций&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;₽575 млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;₽360 млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;₽425 млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Доля опрошенных компаний, сообщивших о&nbsp;привлечении инвестиций&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;47,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;38,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;35,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Доля внешнего финансирования &lltt;br/&ggtt;
в&nbsp;общем объеме инвестиций 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;19,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;17,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;19,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Доля опрошенных компаний, сообщивших о&nbsp;наличии внешних инвестиций&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;27,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;25,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;25,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Общий объем внешних инвестиций&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;₽110 млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;₽64 млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;₽81 млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;Ассоциация РУССОФТ проводила в&nbsp;2025 году экспресс-опросы софтверных компаний с&nbsp;целью моделирования изменения ряда показателей финансового состояния бизнеса при сохранении всех льгот и&nbsp;при частичном лишении налоговых послаблений. Результаты этих опросов показали, что увеличение налоговой нагрузки негативно отразится прежде всего на&nbsp;объеме инвестиций. При нынешних условиях в&nbsp;софтверной индустрии существует прямая корреляция совокупной прибыли софтверных компаний и&nbsp;совокупных вложений в&nbsp;их&nbsp;развитие. Поскольку совокупная чистая прибыль по&nbsp;итогам 2025 года сократилась примерно на&nbsp;треть, то&nbsp;и&nbsp;почти аналогично снизился объем инвестиций в&nbsp;софтверной индустрии.&lltt;/p&ggtt;
&lltt;p&ggtt;С&nbsp;1&nbsp;января 2026 года было введено еще одно изменение в&nbsp;налоговой политике&nbsp;— страховые взносы для аккредитованных ИТ-компаний увеличились примерно вдвое (с&nbsp;7,6% до&nbsp;15%). С&nbsp;учетом того, что &lltt;nobr&ggtt;60-80%&lltt;/nobr&ggtt; затрат софтверных компаний приходится на&nbsp;фонд оплаты труда, дополнительные отчисления существенно сокращают прибыль при прочих равных условиях. Тем не&nbsp;менее, результаты опроса показывают сдержанный оптимизм.&lltt;/p&ggtt;
&lltt;p&ggtt;Расчеты на&nbsp;основании планов опрошенных компаний на&nbsp;2026 год дают рост совокупных инвестиций на&nbsp;18%. Предположительно выручка увеличится на&nbsp;17%, чуть возрастет доля внешнего финансирования (с&nbsp;17,7% до&nbsp;19,0%), а&nbsp;дополнительные отчисления в&nbsp;пенсионный и&nbsp;социальные фонды частично компенсирует снижение темпов роста средней зарплаты. Прибавка на&nbsp;18% отражает скорее самый оптимистический сценарий. Реалистичный&nbsp;же предполагает меньший прирост. При этом нельзя исключить и&nbsp;сокращение инвестиций.&lltt;/p&ggtt;
&lltt;p&ggtt;Показатель удовлетворенности респондентов имеющимся объемом инвестиций, как правило, очень низкий. Опрашиваемые компании в&nbsp;течение нескольких лет видели перспективы окупаемости при вложениях, которые должны были быть в&nbsp;&lltt;nobr&ggtt;2-3&lltt;/nobr&ggtt; раза больше фактических. Произошедший в&nbsp;2021 году инвестиционный бум привел к&nbsp;тому, что потребность в&nbsp;инвестициях в&nbsp;индустрию была удовлетворена намного лучше, чем в&nbsp;предыдущие годы&nbsp;— на&nbsp;58%. В&nbsp;2022 году произошел рост показателя удовлетворенности респондентами объемами финансовых вложений до&nbsp;63%, но&nbsp;этот год был особенным: из-за высокой степени неопределенности не&nbsp;столько выросли вложения, сколько снизилась в&nbsp;них потребность. В&nbsp;2023 году показатель удовлетворенности снизился до&nbsp;51%, а&nbsp;в&nbsp;2024 году&nbsp;— до&nbsp;42%. Уменьшение этого показателя при росте объема инвестиций говорит о&nbsp;том, что потребность в&nbsp;инвестициях росла быстрее, чем объем инвестиций в&nbsp;развитие софтверных компаний, что было объяснимо на&nbsp;фоне активной реализации процесса импортозамещения ПО.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;итогам 2025 года показатель удовлетворенности в&nbsp;инвестициях уменьшился еще больше. По&nbsp;всем опрошенным компаниям фактические вложения составили менее четверти от&nbsp;требуемых (23,5%). Если опираться на&nbsp;ожидания опрошенных компаний, то&nbsp;в&nbsp;2026 году этот показатель должен повыситься, но&nbsp;все&nbsp;же останется очень низким&nbsp;— 27,2%.&lltt;/p&ggtt;
&lltt;p&ggtt;Удовлетворенность в&nbsp;объеме инвестиций ниже у&nbsp;продуктовых компаний в&nbsp;сравнении с&nbsp;сервисными, что объясняется их&nbsp;потребностью в&nbsp;разработке собственного программного продукта, что занимает длительное время.&lltt;/p&ggtt;
&lltt;h3&ggtt;Распределение стабильно&lltt;/h3&ggtt;
&lltt;p&ggtt;По&nbsp;итогам 2024 года доля собственных инвестиций софтверных компаний составила 77,3%. В&nbsp;2025 году изменение этого показателя оказалось незначительным. В&nbsp;2026 году имеются надежды на&nbsp;небольшое увеличение внешнего финансирования (прежде всего, государственного), но&nbsp;структура инвестиций в&nbsp;целом ожидается неизменной при допущении незначительных колебаний.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Распределение объема инвестиций в&nbsp;индустрию программного обеспечения по&nbsp;источникам финансирования (по&nbsp;итогам &lltt;nobr&ggtt;2024-2026 годов)&lltt;/nobr&ggtt;&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; &lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2024&nbsp;г.&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2025&nbsp;г.&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2026&nbsp;г. (прогноз)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Собственные вложения (реинвестиции из&nbsp;прибыли)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;77,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;76,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;74,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Дополнительные вложения учредителей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;5,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Полученные от&nbsp;заказчиков/клиентов средства, которые пошли на&nbsp;развитие (создание новых тиражируемых решений или новых версий уже существующих решений)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;15,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;13,85%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;14,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Государственное финансирование (без участия частных инвесторов), включая гранты и&nbsp;субсидирование льготного кредитования&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1,9%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;4,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Вложения сторонних частных инвесторов (в&nbsp;т.&nbsp;ч. фондовый рынок, венчурные фонды, включая созданные с&nbsp;участием государства)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;0,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,15%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;0,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Другие источники&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;—&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;—&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;Если при анализе данных по&nbsp;распределению инвестиций между собственными и&nbsp;привлеченными средствами по&nbsp;итогам 2025 года к&nbsp;собственным средствам добавить инвестиции со&nbsp;стороны учредителей, то&nbsp;эта доля увеличится до&nbsp;82,4%. Следовательно, на&nbsp;все источники внешнего финансирования приходится 17,6%. Годом ранее этот показатель был равен 19,2%.&lltt;/p&ggtt;
&lltt;p&ggtt;Вложения сторонних частных инвесторов обеспечивают 2,15% общего объема инвестиций, а&nbsp;годом ранее они составляли 0,4%. Однако делать вывод о&nbsp;каком-то росте активности частных инвесторов пока преждевременно. При единичных случаях привлечения внешних инвесторов очень велико влияние случайных факторов. Рост до&nbsp;2,15% в&nbsp;2025 году обеспечила одна компания, участвовавшая в&nbsp;опросе. Без учета ее&nbsp;данных такого роста не&nbsp;будет. К&nbsp;тому&nbsp;же, в&nbsp;2026 году ожидается возвращение участия внешних источников инвестиций к&nbsp;прежнему уровню.&lltt;/p&ggtt;
&lltt;h3&ggtt;Самые привлекательные&lltt;/h3&ggtt;
&lltt;p&ggtt;При делении компаний на&nbsp;категории выяснилось, что у&nbsp;компаний с&nbsp;выручкой менее ₽375&nbsp;млн.&nbsp;в&nbsp;2025 году имелась бОльшая доля внешних инвестиций в&nbsp;общем объеме вложений, чем у&nbsp;компаний большего размера. Аналогичное преимущество имелось у&nbsp;небольших предприятий по&nbsp;итогам 2024&nbsp;года. Соотношение общего объема вложений к&nbsp;обороту у&nbsp;них также выше, чем у&nbsp;компаний с&nbsp;выручкой более ₽375&nbsp;млн.&lltt;/p&ggtt;
&lltt;p&ggtt;Продуктовая модель предполагает бОльшую инвестиционную привлекательность в&nbsp;сравнении с&nbsp;сервисной. Однако доля внешнего финансирования в&nbsp;общем объеме инвестиций в&nbsp;&lltt;nobr&ggtt;2024-2025&lltt;/nobr&ggtt; годах была выше именно у&nbsp;сервисных компаний. Это, скорее всего, связано с&nbsp;меньшими рисками для внешних инвесторов из-за более коротких сроков окупаемости, и&nbsp;с&nbsp;более низкой рентабельностью, а&nbsp;значит меньшим объемом наличия у&nbsp;них собственных средств для инвестиций.&lltt;/p&ggtt;
&lltt;p&ggtt;Если по&nbsp;итогам 2024 года соотношение объема инвестиций в&nbsp;развитие относительно оборота были выше у&nbsp;компаний, которые работают только в&nbsp;России в&nbsp;сравнении с&nbsp;предприятиями, имеющими продажи за&nbsp;рубежом, то&nbsp;по&nbsp;итогам 2025 года произошло выравнивание показателей у&nbsp;этих двух категорий компаний.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Данные об&nbsp;инвестициях по&nbsp;категориям опрошенных компаний по&nbsp;итогам 2025 года&lltt;/strong&ggtt; &lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; &lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Объем инвестиций &lltt;br/&ggtt;
по&nbsp;отношению к&nbsp;обороту 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Сообщили &lltt;br/&ggtt;
о&nbsp;наличии инвестиций &lltt;br/&ggtt;
в&nbsp;2025&nbsp;г.,% опрошенных компаний 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Доля внешнего финансирования во&nbsp;всём объеме инвестиций&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Сообщили &lltt;br/&ggtt;
о&nbsp;наличии внешнего финансирования в&nbsp;2025&nbsp;г.,% опрошенных компаний 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Все опрошенные компании&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;13,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;38,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;9,9%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;25,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td colspan="5"&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Размер компаний&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Оборот &lltt;br/&ggtt;
менее ₽375 млн 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;24,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;35,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;19,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;24,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Оборот &lltt;br/&ggtt;
более ₽375 млн 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;13,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;43,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8,9%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;28,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td colspan="5"&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Модель бизнеса&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Продуктовая&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;15,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;42,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;23,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Сервисная&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;31,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;22,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;28,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td colspan="5"&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Наличие экспортных доходов&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Не&nbsp;присутствовали &lltt;br/&ggtt;
за&nbsp;рубежом в&nbsp;2025&nbsp;г. 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;14,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;33,9%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;11,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;26,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Присутствовали &lltt;br/&ggtt;
за&nbsp;рубежом в&nbsp;2025&nbsp;г. 
				&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;12,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;39,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;9,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;18,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td colspan="5"&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Местоположение головного офиса&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Москва&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;14,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;39,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;17,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;23,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Петербург&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;13,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;38,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;10,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;24,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Другие города&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;13,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;37,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;7,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;26,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;]]></source>
<adate>26.08.2026</adate>
<dbid>235413</dbid>
<rubric>8</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Электронная транспортная накладная с сентября станет обязательной. Как успеть подготовить SAP и «1С»]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235405]]></link>
<description><![CDATA[С 1 сентября 2026 года бумажная товарно-транспортная накладная (ТТН) практически уйдет в прошлое. Электронные перевозочные документы становятся обязательными для большинства участников грузоперевозок. Эксперты IBS рассказали, что меняется, какие риски появляются и как бизнесу успеть подготовить ИТ-системы. Что изменится С 2020 года отдельные компании тестировали обмен электронными документами в рамках пилотного проекта Минтранса. С сентября 2022-го электронная транспортная накладная (ЭТрН) стала добровольной опцией, которая помогала ускорить и удешевить документооборот. С сентября 2026-го бумажная ТТН перестает быть основным юридически значимым документом. Ключевые изменения: 	 Обмен данными между участниками цепочки (грузоотправитель — перевозчик — грузополучатель и др.) идет через операторов электронных перевозочных документов (ЭПД) и единую государственную информационную систему (ГИС ЭПД). 	 Подписание — исключительно усиленной квалифицированной электронной подписью (УКЭП). 	 Хранение электронных документов — три — пять лет в зависимости от ситуации. Сама ЭТрН включает минимум четыре независимых файла (титула): 	 Т1 — формирует и подписывает грузоотправитель на этапе отгрузки; 	 Т2 — перевозчик подтверждает прием груза; 	 Т3 — грузополучатель фиксирует получение; 	 Т4 — перевозчик/водитель завершает процесс. Есть и дополнительные титулы на особые случаи: например, смена адреса, перевозчика, изменение стоимости. Риски в случае бездействия Рынок пока реагирует неоднозначно: далеко не все активно готовятся к изменениям. Однако вариантов переждать или уклониться практически нет. 	«Речь идет не о том, что появляется новая форма печатного документа. Фундаментально меняются процессы в перевозках. Неисполнение обязанностей чревато сбоями в отгрузках и поставках. Контрагенты, особенно если это большие крупные сети, просто не примут документы на бумаге. Налоговая тоже больше не будет считать „бумагу“ подтверждающим документом», — предупреждает Денис Боднар, начальник отдела эксплуатации бизнес-приложений IBS. Хорошая новость: до 1 марта 2027 года штрафы назначаться не будут, возможны только устные предупреждения. Плохая — операционные и налоговые риски никуда не денутся, а отсутствие регистрации в ГИС ЭПД может стать триггером для дополнительных проверок. Косвенные риски — потеря юридической силы прежних документов и уход контрагентов. #IMAGE_235406# Что стоит сделать прямо сейчас Минимальный набор действий одинаков для всех: 	 выбрать аккредитованного оператора ЭПД (их уже больше десяти); 	 заключить договор и зарегистрироваться в ГИС ЭПД, прямого доступа участников к ней нет — только через операторов ЭПД; 	 получить усиленные квалифицированные электронные подписи и машиночитаемые доверенности (МЧД); 	 актуализировать договоры с партнерами, добавив возможность электронного обмена; 	 узнать, через каких операторов работают контрагенты, и при необходимости настроить роуминг; 	 встроить новый процесс в информационные системы компании. Как подготовить SAP В стандарте SAP решения для ЭТрН нет, однако возможны альтернативные варианты. Можно работать вручную в личном кабинете оператора — быстро и доступно, но только если отгрузок немного (5–15 операций в день). При серьезных объемах — это путь к ошибкам и двойному учету в параллельных системах. Можно использовать собственную разработку. 	«Решение учтет особенности конкретного бизнеса, но его создание потребует значительных ресурсов и времени — до нескольких месяцев, — отмечает Денис Боднар. — В итоге можно получить уникальную разработку, которую нужно будет поддерживать только для себя». Есть и готовые продукты. Модули для ЭТрН предлагают операторы ЭПД. Такой подход обеспечивает ускоренное внедрение по сравнению с разработкой, но формирует привязку к одному оператору. Более гибкие альтернативы — комплексные продукты, например, от IBS. Решение IBS встраивается непосредственно в SAP. Пользователи продолжают работать в привычном интерфейсе, документы рождаются из логистических цепочек и автоматически уходят операторам. Есть коннекторы к разным операторам, онлайн-мониторинг статусов и возможность перейти из электронного титула в обычный документ SAP и обратно. На что обратить внимание при выборе или разработке любого решения: 	 корректное формирование структурированных XML по форматам ФНС, включая упрощенные варианты операторов; 	 полный обмен всеми основными и дополнительными титулами; 	 сквозная интеграция с несколькими операторами и гибкая маршрутизация; 	 онлайн-мониторинг статусов и цепочки титулов; 	 связка логистических документов SAP с электронными; 	 справочники транспортных средств, особенно если нет SAP TM; 	 гибкость настроек под разных партнеров и маршруты. Как подготовить «1С» В «1С» переход на ЭТрН обеспечивается через подсистему «Библиотека электронных документов», которая встроена в большинство типовых конфигураций. 	«Самый очевидный и предпочтительный вариант — полное обновление конфигурации, — говорит руководитель группы ERP в IBS Вячеслав Кирьяков. — Если система не сильно кастомизирована, больших сложностей быть не должно, но, если доработок много или версия старая, задача становится сложной, особенно с учетом технологических окон». В условиях дефицита времени можно обновить только подсистему «Библиотека электронных документов», а для самописных конфигураций — внедрить ее отдельно. Есть и запасной путь — «база-мост». В этом случае используется копия продуктивной базы или отдельная конфигурация, которая обменивается данными с основной системой через механизмы интеграции. Так можно начать работать с ЭТрН уже сейчас, а полное обновление делать параллельно. Времени осталось немного, поэтому важно как можно скорее определиться с оператором и сценарием внедрения, особенно в случае SAP или сильно доработанной «1С». Своевременная подготовка позволит не только избежать рисков, но и сохранить или даже повысить уровень автоматизации логистических процессов. IBS предлагает пройти экспресс-анализ и оценить возможности быстрого внедрения ЭТрН в процессы компании]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;С&nbsp;1&nbsp;сентября 2026 года бумажная товарно-транспортная накладная (ТТН) практически уйдет в&nbsp;прошлое. Электронные перевозочные документы становятся обязательными для большинства участников грузоперевозок. Эксперты IBS рассказали, что меняется, какие риски появляются и&nbsp;как бизнесу успеть подготовить ИТ-системы.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;Что изменится&lltt;/h3&ggtt;
&lltt;p&ggtt;С&nbsp;2020 года отдельные компании тестировали обмен электронными документами в&nbsp;рамках пилотного проекта Минтранса. С&nbsp;сентября &lltt;nobr&ggtt;2022-го&lltt;/nobr&ggtt; электронная транспортная накладная (ЭТрН) стала добровольной опцией, которая помогала ускорить и&nbsp;удешевить документооборот. С&nbsp;сентября &lltt;nobr&ggtt;2026-го&lltt;/nobr&ggtt; бумажная ТТН перестает быть основным юридически значимым документом.&lltt;/p&ggtt;
&lltt;p&ggtt;Ключевые изменения:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; Обмен данными между участниками цепочки (грузоотправитель&nbsp;— перевозчик&nbsp;— грузополучатель и&nbsp;др.) идет через операторов электронных перевозочных документов (ЭПД) и&nbsp;единую государственную информационную систему (ГИС ЭПД).&lltt;/li&ggtt;
	&lltt;li&ggtt; Подписание&nbsp;— исключительно усиленной квалифицированной электронной подписью (УКЭП).&lltt;/li&ggtt;
	&lltt;li&ggtt; Хранение электронных документов&nbsp;— три&nbsp;— пять лет в&nbsp;зависимости от&nbsp;ситуации.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Сама ЭТрН включает минимум четыре независимых файла (титула):&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; Т1&nbsp;— формирует и&nbsp;подписывает грузоотправитель на&nbsp;этапе отгрузки;&lltt;/li&ggtt;
	&lltt;li&ggtt; Т2&nbsp;— перевозчик подтверждает прием груза;&lltt;/li&ggtt;
	&lltt;li&ggtt; Т3&nbsp;— грузополучатель фиксирует получение;&lltt;/li&ggtt;
	&lltt;li&ggtt; Т4&nbsp;— перевозчик/водитель завершает процесс.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Есть и&nbsp;дополнительные титулы на&nbsp;особые случаи: например, смена адреса, перевозчика, изменение стоимости.&lltt;/p&ggtt;
&lltt;h3&ggtt;Риски в&nbsp;случае бездействия&lltt;/h3&ggtt;
&lltt;p&ggtt;Рынок пока реагирует неоднозначно: далеко не&nbsp;все активно готовятся к&nbsp;изменениям. Однако вариантов переждать или уклониться практически нет.&lltt;/p&ggtt;
&lltt;blockquote&ggtt; 
	&lltt;p&ggtt;«Речь идет не&nbsp;о&nbsp;том, что появляется новая форма печатного документа. Фундаментально меняются процессы в&nbsp;перевозках. Неисполнение обязанностей чревато сбоями в&nbsp;отгрузках и&nbsp;поставках. Контрагенты, особенно если это большие крупные сети, просто не&nbsp;примут документы на&nbsp;бумаге. Налоговая тоже больше не&nbsp;будет считать „бумагу“ подтверждающим документом»,&nbsp;— предупреждает Денис Боднар, начальник отдела эксплуатации бизнес-приложений IBS.&lltt;/p&ggtt;
&lltt;/blockquote&ggtt;
&lltt;p&ggtt;Хорошая новость: до&nbsp;1&nbsp;марта 2027 года штрафы назначаться не&nbsp;будут, возможны только устные предупреждения. Плохая&nbsp;— операционные и&nbsp;налоговые риски никуда не&nbsp;денутся, а&nbsp;отсутствие регистрации в&nbsp;ГИС ЭПД может стать триггером для дополнительных проверок. Косвенные риски&nbsp;— потеря юридической силы прежних документов и&nbsp;уход контрагентов.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235406#&lltt;/p&ggtt;
&lltt;h3&ggtt;Что стоит сделать прямо сейчас&lltt;/h3&ggtt;
&lltt;p&ggtt;Минимальный набор действий одинаков для всех:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; выбрать аккредитованного оператора ЭПД (их&nbsp;уже больше десяти);&lltt;/li&ggtt;
	&lltt;li&ggtt; заключить договор и&nbsp;зарегистрироваться в&nbsp;ГИС ЭПД, прямого доступа участников к&nbsp;ней нет&nbsp;— только через операторов ЭПД;&lltt;/li&ggtt;
	&lltt;li&ggtt; получить усиленные квалифицированные электронные подписи и&nbsp;машиночитаемые доверенности (МЧД);&lltt;/li&ggtt;
	&lltt;li&ggtt; актуализировать договоры с&nbsp;партнерами, добавив возможность электронного обмена;&lltt;/li&ggtt;
	&lltt;li&ggtt; узнать, через каких операторов работают контрагенты, и&nbsp;при необходимости настроить роуминг;&lltt;/li&ggtt;
	&lltt;li&ggtt; встроить новый процесс в&nbsp;информационные системы компании.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Как подготовить SAP&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;стандарте SAP решения для ЭТрН нет, однако возможны альтернативные варианты.&lltt;/p&ggtt;
&lltt;p&ggtt;Можно работать вручную в&nbsp;личном кабинете оператора&nbsp;— быстро и&nbsp;доступно, но&nbsp;только если отгрузок немного &lltt;nobr&ggtt;(5–15&lltt;/nobr&ggtt; операций в&nbsp;день). При серьезных объемах&nbsp;— это путь к&nbsp;ошибкам и&nbsp;двойному учету в&nbsp;параллельных системах. Можно использовать собственную разработку. &lltt;/p&ggtt;
&lltt;blockquote&ggtt; 
	&lltt;p&ggtt;«Решение учтет особенности конкретного бизнеса, но&nbsp;его создание потребует значительных ресурсов и&nbsp;времени&nbsp;— до&nbsp;нескольких месяцев,&nbsp;— отмечает Денис Боднар. —&nbsp;В&nbsp;итоге можно получить уникальную разработку, которую нужно будет поддерживать только для себя».&lltt;/p&ggtt;
&lltt;/blockquote&ggtt;
&lltt;p&ggtt;Есть и&nbsp;готовые продукты. Модули для ЭТрН предлагают операторы ЭПД. Такой подход обеспечивает ускоренное внедрение по&nbsp;сравнению с&nbsp;разработкой, но&nbsp;формирует привязку к&nbsp;одному оператору. Более гибкие альтернативы&nbsp;— комплексные продукты, например, от&nbsp;IBS.&lltt;/p&ggtt;
&lltt;p&ggtt;Решение IBS встраивается непосредственно в&nbsp;SAP. Пользователи продолжают работать в&nbsp;привычном интерфейсе, документы рождаются из&nbsp;логистических цепочек и&nbsp;автоматически уходят операторам. Есть коннекторы к&nbsp;разным операторам, онлайн-мониторинг статусов и&nbsp;возможность перейти из&nbsp;электронного титула в&nbsp;обычный документ SAP и&nbsp;обратно.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;что обратить внимание при выборе или разработке любого решения:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; корректное формирование структурированных XML по&nbsp;форматам ФНС, включая упрощенные варианты операторов;&lltt;/li&ggtt;
	&lltt;li&ggtt; полный обмен всеми основными и&nbsp;дополнительными титулами;&lltt;/li&ggtt;
	&lltt;li&ggtt; сквозная интеграция с&nbsp;несколькими операторами и&nbsp;гибкая маршрутизация;&lltt;/li&ggtt;
	&lltt;li&ggtt; онлайн-мониторинг статусов и&nbsp;цепочки титулов;&lltt;/li&ggtt;
	&lltt;li&ggtt; связка логистических документов SAP с&nbsp;электронными;&lltt;/li&ggtt;
	&lltt;li&ggtt; справочники транспортных средств, особенно если нет SAP TM;&lltt;/li&ggtt;
	&lltt;li&ggtt; гибкость настроек под разных партнеров и&nbsp;маршруты.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Как подготовить «1С»&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;«1С» переход на&nbsp;ЭТрН обеспечивается через подсистему «Библиотека электронных документов», которая встроена в&nbsp;большинство типовых конфигураций.&lltt;/p&ggtt;
&lltt;blockquote&ggtt; 
	&lltt;p&ggtt;«Самый очевидный и&nbsp;предпочтительный вариант&nbsp;— полное обновление конфигурации,&nbsp;— говорит руководитель группы ERP в&nbsp;IBS Вячеслав Кирьяков. —&nbsp;Если система не&nbsp;сильно кастомизирована, больших сложностей быть не&nbsp;должно, но, если доработок много или версия старая, задача становится сложной, особенно с&nbsp;учетом технологических окон».&lltt;/p&ggtt;
&lltt;/blockquote&ggtt;
&lltt;p&ggtt;В&nbsp;условиях дефицита времени можно обновить только подсистему «Библиотека электронных документов», а&nbsp;для самописных конфигураций&nbsp;— внедрить ее&nbsp;отдельно.&lltt;/p&ggtt;
&lltt;p&ggtt;Есть и&nbsp;запасной путь&nbsp;— «база-мост». В&nbsp;этом случае используется копия продуктивной базы или отдельная конфигурация, которая обменивается данными с&nbsp;основной системой через механизмы интеграции. Так можно начать работать с&nbsp;ЭТрН уже сейчас, а&nbsp;полное обновление делать параллельно.&lltt;/p&ggtt;
&lltt;p&ggtt;Времени осталось немного, поэтому важно как можно скорее определиться с&nbsp;оператором и&nbsp;сценарием внедрения, особенно в&nbsp;случае SAP или сильно доработанной «1С». Своевременная подготовка позволит не&nbsp;только избежать рисков, но&nbsp;и&nbsp;сохранить или даже повысить уровень автоматизации логистических процессов.&lltt;/p&ggtt;
&lltt;p&ggtt;IBS предлагает пройти &lltt;a href="/ad/rd/ibs-43.php" target="_blank"&ggtt;экспресс-анализ&lltt;/a&ggtt; и&nbsp;оценить возможности быстрого внедрения ЭТрН в&nbsp;процессы компании.&lltt;/p&ggtt;]]></source>
<adate>26.08.2026</adate>
<dbid>235405</dbid>
<rubric>1</rubric>
<orubric>135315</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/219/ydrg0grjim565dxhtyk71oxz7wj6cq88.jpg]]>
</images>
<imagesname><![CDATA[;; ]]></imagesname>
<tag><![CDATA[Идеи и практики автоматизации]]></tag>
</item>
<item>
<title><![CDATA[ИСИЭЗ НИУ ВШЭ: использование цифровых технологий организациями в 2025 году]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235404]]></link>
<description><![CDATA[Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата проанализировал уровень использования цифровых технологий в крупных и средних организациях (без учета субъектов малого предпринимательства) в 2025 г. В 2025 г. цифровые технологии использовали порядка 84% крупных и средних организаций — больше, чем годом ранее. Базовым условием распространения цифровых технологий является доступ к интернету. Фиксированным подключением пользуются почти четыре из пяти организаций (78%), мобильным интернетом — почти две из пяти (39%). Информационно-коммуникационную инфраструктуру наряду с доступом к интернету характеризуют использование операционных систем с открытым исходным кодом (например, Linux) и наличие серверов. В 2025 г. такие операционные системы применяли 24% крупных и средних организаций, серверы имели 37%. Среди цифровых технологий наиболее востребованы цифровые платформы и облачные сервисы, за ними следуют геоинформационные системы. Каждая десятая из обследованных организаций внедрила RFID-технологии; чуть меньше — Интернет вещей и технологии сбора, обработки и анализа больших данных. Каждая двадцатая применяла технологии искусственного интеллекта для решения производственных задач. Промышленные роботы, аддитивные технологии и цифровые двойники в силу своей специфики распространены меньше — в 1–2% крупных и средних организаций. Ключевым барьером для использования передовых цифровых технологий — решений для сбора, обработки и анализа больших данных, искусственного интеллекта и Интернета вещей — как и в предыдущие годы, остаются высокие затраты: их отмечает каждая вторая организация. Каждая третья указывает на отсутствие массивов данных и недостаточное развитие ИКТ-инфраструктуры; в среднем каждая четвертая — на нехватку средств для привлечения квалифицированных кадров, обладающих навыками работы с такими технологиями. Наряду с ресурсными ограничениями ряд организаций сообщили об отсутствии потребности в этих технологиях. Это свидетельствует о том, что темпы внедрения зависят не только от объема необходимых вложений, но и от готовности организаций пересматривать бизнес-процессы. Поэтому такие решения распространяются постепенно и прежде всего там, где дают измеримый эффект]]></description>
<source><![CDATA[&lltt;p&ggtt;Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата проанализировал уровень использования цифровых технологий в крупных и средних организациях (без учета субъектов малого предпринимательства) в 2025 г.&lltt;/p&ggtt;
&lltt;p&ggtt;В 2025 г. цифровые технологии использовали порядка 84% крупных и средних организаций — больше, чем годом ранее.&lltt;/p&ggtt;
&lltt;p&ggtt;Базовым условием распространения цифровых технологий является доступ к интернету. Фиксированным подключением пользуются почти четыре из пяти организаций (78%), мобильным интернетом — почти две из пяти (39%).&lltt;/p&ggtt;
&lltt;p&ggtt;Информационно-коммуникационную инфраструктуру наряду с доступом к интернету характеризуют использование операционных систем с открытым исходным кодом (например, Linux) и наличие серверов. В 2025 г. такие операционные системы применяли 24% крупных и средних организаций, серверы имели 37%.&lltt;/p&ggtt;
&lltt;p&ggtt;Среди цифровых технологий наиболее востребованы цифровые платформы и облачные сервисы, за ними следуют геоинформационные системы. Каждая десятая из обследованных организаций внедрила RFID-технологии; чуть меньше — Интернет вещей и технологии сбора, обработки и анализа больших данных. Каждая двадцатая применяла технологии искусственного интеллекта для решения производственных задач. Промышленные роботы, аддитивные технологии и цифровые двойники в силу своей специфики распространены меньше — в &lltt;nobr&ggtt;1–2%&lltt;/nobr&ggtt; крупных и средних организаций.&lltt;/p&ggtt;
&lltt;p&ggtt;Ключевым барьером для использования передовых цифровых технологий — решений для сбора, обработки и анализа больших данных, искусственного интеллекта и Интернета вещей — как и в предыдущие годы, остаются высокие затраты: их отмечает каждая вторая организация. Каждая третья указывает на отсутствие массивов данных и недостаточное развитие ИКТ-инфраструктуры; в среднем каждая четвертая — на нехватку средств для привлечения квалифицированных кадров, обладающих навыками работы с такими технологиями.&lltt;/p&ggtt;
&lltt;p&ggtt;Наряду с ресурсными ограничениями ряд организаций сообщили об отсутствии потребности в этих технологиях. Это свидетельствует о том, что темпы внедрения зависят не только от объема необходимых вложений, но и от готовности организаций пересматривать бизнес-процессы. Поэтому такие решения распространяются постепенно и прежде всего там, где дают измеримый эффект.&lltt;/p&ggtt;]]></source>
<adate>25.08.2026</adate>
<dbid>235404</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Цифровая трансформация]]></tag>
</item>
<item>
<title><![CDATA[Nodul: российские LLM подешевели до 67%, но зарубежные модели сопоставимого класса стоят до 10 раз дешевле]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235403]]></link>
<description><![CDATA[Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если сравнивать их с зарубежными решениями того класса, с которыми российские разработчики сами сопоставляют свои LLM, российские модели по-прежнему могут стоить существенно дороже. Российские разработчики заметно снизили стоимость использования языковых моделей по сравнению с октябрем 2025 года. Наиболее сильное снижение произошло у GigaChat. Стоимость GigaChat Lite снизилась с 0,20 до 0,065 рубля за 1 тыс. токенов — на 67,5%. В линейке GigaChat Pro цена сократилась с 1,50 до 0,50 рубля — на 66,7%. В линейке Яндекса снижение было меньше. YandexGPT Pro стоила 1,20 рубля за 1 тыс. токенов, модель старшего поколения YandexGPT Pro 5.1 — 0,80 рубля, то есть на 33% меньше. Стоимость YandexGPT Lite не изменилась и составляет 0,20 рубля. В 2026 году российские разработчики также расширили линейки более доступными моделями. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за 1 тыс. генерируемых токенов. В коммерческой линейке GigaChat стоимость Lite-модели составляет 0,065 рубля за 1 тыс. токенов. Снижение цен можно объяснить тем, что российские разработчики постепенно сокращают прежнюю ценовую премию и приближают тарифы к мировому рынку. На это косвенно указывает стоимость доступа к одним и тем же зарубежным моделям через российские облачные платформы. Так, DeepSeek V4 Flash напрямую стоит 0,0375 рубля за 1 тыс. входных и 0,112 рубля за 1 тыс. генерируемых токенов. Через Yandex AI Studio — 0,30 и 0,50 рубля соответственно, то есть в 8 и 4,5 раза дороже. У Cloud.ru разрыв меньше: DeepSeek V4 Pro стоит напрямую 0,112 рубля за 1 тыс. входных и 0,337 рубля за выходные токены, через Cloud.ru — 0,183 и 0,732 рубля, или примерно в 1,6 и 2,2 раза дороже. Эти показатели не позволяют рассчитать реальную маржинальность провайдеров. Публичные тарифы не раскрывают себестоимость инфраструктуры, условия развертывания моделей и коммерческие расходы. Однако они показывают, насколько различается ценовая премия за доступ к одной и той же модели через разных поставщиков инфраструктуры. Снижение тарифов само по себе не означает, что российские LLM стали самыми доступными. Для оценки их ценовой конкурентоспособности российские модели сравнили не с наиболее новыми и дорогими frontier-решениями, а с зарубежными моделями, которые сами разработчики выбирали в качестве ориентиров для своих релизов. При запуске YandexGPT 5.1 Pro Яндекс сравнивал ее с GPT-4.1. Сейчас YandexGPT 5.1 Pro стоит 0,80 рубля за 1 тыс. входных и генерируемых токенов, тогда как GPT-4.1 — около 0,17 рубля за входные и 0,68 рубля за генерируемые. В результате YandexGPT 5.1 Pro обходится примерно в 4,7 раза дороже GPT-4.1 по входным токенам и примерно на 17% дороже по выходным. Еще заметнее разница у Alice AI LLM, которую разработчик сопоставляет с DeepSeek V3.1. Alice AI LLM стоит 0,50 рубля за 1 тыс. входных и 1,20 рубля за 1 тыс. генерируемых токенов. DeepSeek V3.1 по официальному тарифу стоила около 0,048 и 0,143 рубля соответственно. Таким образом, российская модель обходится примерно в 10,5 раза дороже по входным и в 8,4 раза — по исходным токенам. Alice AI LLM Flash позволяет провести еще одно такое сравнение. Яндекс сопоставляет ее с GPT-5.4 mini. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за генерируемые токены, GPT-5.4 mini — около 0,064 и 0,383 рубля соответственно. То есть Alice AI LLM Flash примерно в 1,6 раза дороже по входным токенам, но почти в два раза дешевле по выходным. Это показывает, что конечная экономика зависит не только от модели, но и от структуры конкретной задачи — соотношения объема входного контекста и генерации. Сравнение актуальных тарифов показывает, что наиболее низкую цену на мировом рынке по-прежнему в значительной степени задают китайские модели. DeepSeek V4 Flash стоит около 0,0375 рубля за 1 тыс. входных и 0,112 рубля за выходные токены, DeepSeek V4 Pro — 0,112 и 0,337 рубля соответственно. GLM-5 стоит 0,08 и 0,27 рубля, Qwen 3.8 Max — 0,17 и 0,511 рубля. В этом же нижнем ценовом диапазоне находятся европейский Mistral Large 3 — 0,04 рубля за входные и 0,13 рубля за выходные токены, а также GPT-5.4 mini — около 0,064 и 0,383 рубля. Из российских решений ближе всего к нижней части диапазона находятся GigaChat Lite с ценой 0,065 рубля за 1 тыс. токенов и Alice AI LLM Flash с тарифами 0,10 рубля за вход и 0,20 рубля за выход. Старшие российские модели стоят заметно дороже: GigaChat Pro — 0,50 рубля за 1 тыс. токенов, GigaChat 2 Max — 0,65 рубля, YandexGPT Pro 5.1 — 0,80 рубля. Alice AI LLM стоит 0,50 рубля за входные и 1,20 рубля за выходные токены. Высокая стоимость больше не является обязательным признаком frontier-модели. В верхней части диапазона остаются Claude Fable 5 с ценой около 0,80 рубля за 1 тыс. входных и 4 рубля за генерируемые токены, а также GPT-5.6 Terra — около 0,34 и 1,53 рубля соответственно. Однако на рынке США появляются более дешевые альтернативы сопоставимого высокого класса. Один из показательных примеров Grok с заметно более низкой стоимостью, чем у ряда решений OpenAI и Anthropic. Ценовое давление на наиболее дорогие LLM идет уже не только со стороны китайских разработчиков. Конкуренция усиливается и внутри американского сегмента. Новые игроки предлагают сопоставимый уровень возможностей в сложных логических задачах, программировании и агентных сценариях при более низкой стоимости инференса]]></description>
<source><![CDATA[&lltt;p&ggtt;Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если сравнивать их с зарубежными решениями того класса, с которыми российские разработчики сами сопоставляют свои LLM, российские модели по-прежнему могут стоить существенно дороже.&lltt;/p&ggtt;
&lltt;p&ggtt;Российские разработчики заметно снизили стоимость использования языковых моделей по сравнению с октябрем 2025 года.&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее сильное снижение произошло у GigaChat. Стоимость GigaChat Lite снизилась с 0,20 до 0,065 рубля за 1 тыс. токенов — на 67,5%. В линейке GigaChat Pro цена сократилась с 1,50 до 0,50 рубля — на 66,7%.&lltt;/p&ggtt;
&lltt;p&ggtt;В линейке Яндекса снижение было меньше. YandexGPT Pro стоила 1,20 рубля за 1 тыс. токенов, модель старшего поколения YandexGPT Pro 5.1 — 0,80 рубля, то есть на 33% меньше. Стоимость YandexGPT Lite не изменилась и составляет 0,20 рубля.&lltt;/p&ggtt;
&lltt;p&ggtt;В 2026 году российские разработчики также расширили линейки более доступными моделями. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за 1 тыс. генерируемых токенов. В коммерческой линейке GigaChat стоимость Lite-модели составляет 0,065 рубля за 1 тыс. токенов.&lltt;/p&ggtt;
&lltt;p&ggtt;Снижение цен можно объяснить тем, что российские разработчики постепенно сокращают прежнюю ценовую премию и приближают тарифы к мировому рынку. На это косвенно указывает стоимость доступа к одним и тем же зарубежным моделям через российские облачные платформы.&lltt;/p&ggtt;
&lltt;p&ggtt;Так, DeepSeek V4 Flash напрямую стоит 0,0375 рубля за 1 тыс. входных и 0,112 рубля за 1 тыс. генерируемых токенов. Через Yandex AI Studio — 0,30 и 0,50 рубля соответственно, то есть в 8 и 4,5 раза дороже.&lltt;/p&ggtt;
&lltt;p&ggtt;У Cloud.ru разрыв меньше: DeepSeek V4 Pro стоит напрямую 0,112 рубля за 1 тыс. входных и 0,337 рубля за выходные токены, через Cloud.ru — 0,183 и 0,732 рубля, или примерно в 1,6 и 2,2 раза дороже.&lltt;/p&ggtt;
&lltt;p&ggtt;Эти показатели не позволяют рассчитать реальную маржинальность провайдеров. Публичные тарифы не раскрывают себестоимость инфраструктуры, условия развертывания моделей и коммерческие расходы. Однако они показывают, насколько различается ценовая премия за доступ к одной и той же модели через разных поставщиков инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Снижение тарифов само по себе не означает, что российские LLM стали самыми доступными. Для оценки их ценовой конкурентоспособности российские модели сравнили не с наиболее новыми и дорогими frontier-решениями, а с зарубежными моделями, которые сами разработчики выбирали в качестве ориентиров для своих релизов.&lltt;/p&ggtt;
&lltt;p&ggtt;При запуске YandexGPT 5.1 Pro Яндекс сравнивал ее с GPT-4.1. Сейчас YandexGPT 5.1 Pro стоит 0,80 рубля за 1 тыс. входных и генерируемых токенов, тогда как GPT-4.1 — около 0,17 рубля за входные и 0,68 рубля за генерируемые.&lltt;/p&ggtt;
&lltt;p&ggtt;В результате YandexGPT 5.1 Pro обходится примерно в 4,7 раза дороже GPT-4.1 по входным токенам и примерно на 17% дороже по выходным.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще заметнее разница у Alice AI LLM, которую разработчик сопоставляет с DeepSeek V3.1. Alice AI LLM стоит 0,50 рубля за 1 тыс. входных и 1,20 рубля за 1 тыс. генерируемых токенов. DeepSeek V3.1 по официальному тарифу стоила около 0,048 и 0,143 рубля соответственно. Таким образом, российская модель обходится примерно в 10,5 раза дороже по входным и в 8,4 раза — по исходным токенам.&lltt;/p&ggtt;
&lltt;p&ggtt;Alice AI LLM Flash позволяет провести еще одно такое сравнение. Яндекс сопоставляет ее с GPT-5.4 mini. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за генерируемые токены, GPT-5.4 mini — около 0,064 и 0,383 рубля соответственно.&lltt;/p&ggtt;
&lltt;p&ggtt;То есть Alice AI LLM Flash примерно в 1,6 раза дороже по входным токенам, но почти в два раза дешевле по выходным. Это показывает, что конечная экономика зависит не только от модели, но и от структуры конкретной задачи — соотношения объема входного контекста и генерации.&lltt;/p&ggtt;
&lltt;p&ggtt;Сравнение актуальных тарифов показывает, что наиболее низкую цену на мировом рынке по-прежнему в значительной степени задают китайские модели.&lltt;/p&ggtt;
&lltt;p&ggtt;DeepSeek V4 Flash стоит около 0,0375 рубля за 1 тыс. входных и 0,112 рубля за выходные токены, DeepSeek V4 Pro — 0,112 и 0,337 рубля соответственно. GLM-5 стоит 0,08 и 0,27 рубля, Qwen 3.8 Max — 0,17 и 0,511 рубля.&lltt;/p&ggtt;
&lltt;p&ggtt;В этом же нижнем ценовом диапазоне находятся европейский Mistral Large 3 — 0,04 рубля за входные и 0,13 рубля за выходные токены, а также GPT-5.4 mini — около 0,064 и 0,383 рубля.&lltt;/p&ggtt;
&lltt;p&ggtt;Из российских решений ближе всего к нижней части диапазона находятся GigaChat Lite с ценой 0,065 рубля за 1 тыс. токенов и Alice AI LLM Flash с тарифами 0,10 рубля за вход и 0,20 рубля за выход.&lltt;/p&ggtt;
&lltt;p&ggtt;Старшие российские модели стоят заметно дороже: GigaChat Pro — 0,50 рубля за 1 тыс. токенов, GigaChat 2 Max — 0,65 рубля, YandexGPT Pro 5.1 — 0,80 рубля. Alice AI LLM стоит 0,50 рубля за входные и 1,20 рубля за выходные токены.&lltt;/p&ggtt;
&lltt;p&ggtt;Высокая стоимость больше не является обязательным признаком frontier-модели.&lltt;/p&ggtt;
&lltt;p&ggtt;В верхней части диапазона остаются Claude Fable 5 с ценой около 0,80 рубля за 1 тыс. входных и 4 рубля за генерируемые токены, а также GPT-5.6 Terra — около 0,34 и 1,53 рубля соответственно.&lltt;/p&ggtt;
&lltt;p&ggtt;Однако на рынке США появляются более дешевые альтернативы сопоставимого высокого класса. Один из показательных примеров Grok с заметно более низкой стоимостью, чем у ряда решений OpenAI и Anthropic.&lltt;/p&ggtt;
&lltt;p&ggtt;Ценовое давление на наиболее дорогие LLM идет уже не только со стороны китайских разработчиков. Конкуренция усиливается и внутри американского сегмента. Новые игроки предлагают сопоставимый уровень возможностей в сложных логических задачах, программировании и агентных сценариях при более низкой стоимости инференса.&lltt;/p&ggtt;]]></source>
<adate>25.08.2026</adate>
<dbid>235403</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Как избежать проблем с интеграцией при использовании мультиоблачного ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235407]]></link>
<description><![CDATA[Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки мультиоблачного искусственного интеллекта, считают опрошенные порталом InformationWeek эксперты. Диверсификация поставщиков облачных услуг для поддержки стратегии ИИ может принести свои плоды, но если CIO и CTO не сохранят контроль, они рискуют сделать данные неуправляемыми. По мере того, как рабочие нагрузки ИИ распространяются по все более разнообразной технологической экосистеме, конфиденциальные данные и операционный контекст перемещаются вместе с ними, отмечает Брайан Груттадауриа, CTO по гибридным облакам Hewlett Packard Enterprise. «Реальная цена разрастания поставщиков заключается не только в дополнительной сложности; это фрагментация данных, контекста, управления и контроля именно в тот момент, когда ИИ больше всего от них зависит», — говорит он. Диверсификация поставщиков в рамках мультиоблачной стратегии требует распределения рабочих нагрузок между несколькими облачными провайдерами. Она в основном используется для минимизации зависимости от поставщика, повышения отказоустойчивости и резервирования, а также оптимизации затрат и производительности. К сожалению, в сочетании с ИИ диверсификация поставщиков может внезапно превратиться в настоящий ад. Признаки неправильной диагностики проблемы Слишком многие организации рассматривают мультиоблачный ИИ как архитектурную проблему, тогда как на самом деле это организационная и финансовая проблема, считает Джесси Дин, CIO компании TDI Security, занимающейся управлением кибербезопасностью. «Из-за страха перед привязкой к поставщику и слабого управления компании разбрасывают данные и модели по нескольким облакам», — отмечает он. Это может привести к размыванию инженерного кадрового потенциала и увеличению долгосрочных затрат. ИТ-руководителям необходимо все тщательно продумать, чтобы устранить фундаментальные недостатки. «Приоритизация единой стратегии стандартизации данных и приверженность основной облачной среде для размещения данных являются ключом к снижению технической сложности и затрат», — полагает Дин. По словам Ха Хоанг, CIO компании Commvault, риск заключается не в том, что организации полагаются на несколько облаков, поскольку у многих из них есть веские причины для этого. «Риск заключается в том, что каждое облако превращается в собственную экосистему ИИ с различными моделями, конвейерами данных, политиками управления и инструментами для разработчиков», — предупреждает она. Как и многие ИТ-руководители, Хоанг считает, что ИИ принесет наибольшую пользу, когда сможет безопасно получать доступ к надежным корпоративным данным и работать согласованно в масштабе всего бизнеса. Если данные фрагментированы, а политики безопасности различаются в каждом облаке, организации могут получить разрозненных агентов, дублирование инвестиций и непоследовательные бизнес-результаты. «Мультиоблачная среда должна быть обдуманным архитектурным решением, а не случайным результатом независимого выбора технологий», — говорит она. Наиболее явным признаком чрезмерной диверсификации поставщиков является то, что данные и рабочие нагрузки больше не являются последовательно видимыми или управляемыми в разных средах, отмечает Груттадауриа. «Если ИТ-служба не может видеть и контролировать актив, независимо от того, где он находится — в облаке, локально или на периферии, — это признак того, что архитектура переросла возможности управления», — предупреждает он. Поиск пути выхода из ловушки мультиоблачного ИИ Ответ на вопрос о том, как избежать ловушки мультиоблачного ИИ, заключается в создании единой ткани данных, охватывающей облако, локальные системы и периферию, формируя единое операционное пространство имен вместо набора разрозненных хранилищ данных, считает Юрий Губин, технический директор компании DataArt, занимающейся разработкой ПО и ИТ-консалтингом. «Когда данные, рабочие нагрузки и ИИ используют общую основу, они остаются видимыми, управляемыми и переносимыми независимо от того, где они работают», — говорит он. Это позволяет организациям внедрять инновации от разных поставщиков, не беря на себя бремя мультивендорной сложности. Начните с управления, а не с технологий, советует Хоанг: «Определите небольшое количество утвержденных платформ ИИ, установите общие стандарты безопасности и идентификации и рассматривайте корпоративные данные как общий актив, а не как нечто, принадлежащее отдельным облакам или бизнес-подразделениям». ИТ-руководители также должны проектировать решения с учетом переносимости там, где это имеет смысл с точки зрения бизнеса. «Это не означает, что каждая рабочая нагрузка должна свободно перемещаться между облаками, но это означает избегание ненужной привязки по основным возможностям ИИ», — поясняет она. Это обеспечит гибкость, которая может создать конкурентное преимущество. Не забывайте о бизнес-целях Лучшая профилактика — это создание корпоративной операционной модели ИИ до того, как внедрение ИИ начнет масштабироваться, полагает Хоанг. «Каждая новая платформа ИИ должна соответствовать общим стандартам безопасности, доступа к данным, наблюдаемости, управления и контроля затрат», — говорит она. Также важно обеспечить, чтобы каждая инвестиция в ИИ была связана с измеримым бизнес-результатом. Цель состоит не в том, чтобы поддерживать каждую модель или каждого облачного провайдера; цель состоит в том, чтобы обеспечить бизнес-результаты с наименьшей операционной сложностью]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки мультиоблачного искусственного интеллекта, считают опрошенные порталом &lltt;/em&ggtt;&lltt;em&ggtt;InformationWeek&lltt;/em&ggtt; &lltt;em&ggtt;эксперты.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Диверсификация поставщиков облачных услуг для поддержки стратегии ИИ может принести свои плоды, но если CIO и CTO не сохранят контроль, они рискуют сделать данные неуправляемыми.&lltt;/p&ggtt;
&lltt;p&ggtt;По мере того, как рабочие нагрузки ИИ распространяются по все более разнообразной технологической экосистеме, конфиденциальные данные и операционный контекст перемещаются вместе с ними, отмечает Брайан Груттадауриа, CTO по гибридным облакам Hewlett Packard Enterprise. «Реальная цена разрастания поставщиков заключается не только в дополнительной сложности; это фрагментация данных, контекста, управления и контроля именно в тот момент, когда ИИ больше всего от них зависит», — говорит он.&lltt;/p&ggtt;
&lltt;p&ggtt;Диверсификация поставщиков в рамках мультиоблачной стратегии требует распределения рабочих нагрузок между несколькими облачными провайдерами. Она в основном используется для минимизации зависимости от поставщика, повышения отказоустойчивости и резервирования, а также оптимизации затрат и производительности. К сожалению, в сочетании с ИИ диверсификация поставщиков может внезапно превратиться в настоящий ад.&lltt;/p&ggtt;
&lltt;h3&ggtt;Признаки неправильной диагностики проблемы&lltt;/h3&ggtt;
&lltt;p&ggtt;Слишком многие организации рассматривают мультиоблачный ИИ как архитектурную проблему, тогда как на самом деле это организационная и финансовая проблема, считает Джесси Дин, CIO компании TDI Security, занимающейся управлением кибербезопасностью. «Из-за страха перед привязкой к поставщику и слабого управления компании разбрасывают данные и модели по нескольким облакам», — отмечает он. Это может привести к размыванию инженерного кадрового потенциала и увеличению долгосрочных затрат. ИТ-руководителям необходимо все тщательно продумать, чтобы устранить фундаментальные недостатки. «Приоритизация единой стратегии стандартизации данных и приверженность основной облачной среде для размещения данных являются ключом к снижению технической сложности и затрат», — полагает Дин.&lltt;/p&ggtt;
&lltt;p&ggtt;По словам Ха Хоанг, CIO компании Commvault, риск заключается не в том, что организации полагаются на несколько облаков, поскольку у многих из них есть веские причины для этого. «Риск заключается в том, что каждое облако превращается в собственную экосистему ИИ с различными моделями, конвейерами данных, политиками управления и инструментами для разработчиков», — предупреждает она.&lltt;/p&ggtt;
&lltt;p&ggtt;Как и многие ИТ-руководители, Хоанг считает, что ИИ принесет наибольшую пользу, когда сможет безопасно получать доступ к надежным корпоративным данным и работать согласованно в масштабе всего бизнеса. Если данные фрагментированы, а политики безопасности различаются в каждом облаке, организации могут получить разрозненных агентов, дублирование инвестиций и непоследовательные бизнес-результаты. «Мультиоблачная среда должна быть обдуманным архитектурным решением, а не случайным результатом независимого выбора технологий», — говорит она.&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее явным признаком чрезмерной диверсификации поставщиков является то, что данные и рабочие нагрузки больше не являются последовательно видимыми или управляемыми в разных средах, отмечает Груттадауриа. «Если ИТ-служба не может видеть и контролировать актив, независимо от того, где он находится — в облаке, локально или на периферии, — это признак того, что архитектура переросла возможности управления», — предупреждает он.&lltt;/p&ggtt;
&lltt;h3&ggtt;Поиск пути выхода из ловушки мультиоблачного ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Ответ на вопрос о том, как избежать ловушки мультиоблачного ИИ, заключается в создании единой ткани данных, охватывающей облако, локальные системы и периферию, формируя единое операционное пространство имен вместо набора разрозненных хранилищ данных, считает Юрий Губин, технический директор компании DataArt, занимающейся разработкой ПО и ИТ-консалтингом. «Когда данные, рабочие нагрузки и ИИ используют общую основу, они остаются видимыми, управляемыми и переносимыми независимо от того, где они работают», — говорит он. Это позволяет организациям внедрять инновации от разных поставщиков, не беря на себя бремя мультивендорной сложности.&lltt;/p&ggtt;
&lltt;p&ggtt;Начните с управления, а не с технологий, советует Хоанг: «Определите небольшое количество утвержденных платформ ИИ, установите общие стандарты безопасности и идентификации и рассматривайте корпоративные данные как общий актив, а не как нечто, принадлежащее отдельным облакам или бизнес-подразделениям». ИТ-руководители также должны проектировать решения с учетом переносимости там, где это имеет смысл с точки зрения бизнеса. «Это не означает, что каждая рабочая нагрузка должна свободно перемещаться между облаками, но это означает избегание ненужной привязки по основным возможностям ИИ», — поясняет она. Это обеспечит гибкость, которая может создать конкурентное преимущество.&lltt;/p&ggtt;
&lltt;h3&ggtt;Не забывайте о бизнес-целях&lltt;/h3&ggtt;
&lltt;p&ggtt;Лучшая профилактика — это создание корпоративной операционной модели ИИ до того, как внедрение ИИ начнет масштабироваться, полагает Хоанг. «Каждая новая платформа ИИ должна соответствовать общим стандартам безопасности, доступа к данным, наблюдаемости, управления и контроля затрат», — говорит она. Также важно обеспечить, чтобы каждая инвестиция в ИИ была связана с измеримым бизнес-результатом. Цель состоит не в том, чтобы поддерживать каждую модель или каждого облачного провайдера; цель состоит в том, чтобы обеспечить бизнес-результаты с наименьшей операционной сложностью.&lltt;/p&ggtt;]]></source>
<adate>26.08.2026</adate>
<dbid>235407</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект;;Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[Цифровые сотрудники без должностей: как меняется логика работы с ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235399]]></link>
<description><![CDATA[ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если система получает доступ к корпоративным данным, выполняет действия и запускает процессы, ей действительно нужны права, ограничения и понятная зона ответственности. Так появляются ИИ-аналитики, ИИ-юристы, ИИ-рекрутеры, ИИ-разработчики. Проблемы возникают, когда саму ИИ-систему начинают выстраивать по принципам привычной оргструктуры. Такой подход понятен, потому что проще встроить нового исполнителя в уже сложившуюся модель работы, чем сразу пересматривать способ ее организации. Но по мере роста числа агентов становится заметно, что фиксированные цифровые роли подходят не для всех задач. И здесь возникает вопрос — а действительно ли ИИ нужна собственная «должность»? Почему ролевая модель плохо масштабируется Ролевая модель хорошо работает, пока задачи выполняют люди. У каждого сотрудника есть свой набор компетенций, полномочий и доступов, который формируется под конкретную функцию. Поэтому знания и ответственность естественно закрепляются за отдельными ролями. С ИИ эта логика работает иначе. Ему не обязательно задавать только одну специализацию и ограничивать круг задач. Где-то системе могут понадобиться договоры, юридические правила и история взаимодействия с клиентом, где-то — техническая документация, финансовые показатели и данные из нескольких корпоративных систем. Нужный контекст и инструменты можно подключать непосредственно под задачу. Когда эту возможность не учитывают, количество цифровых ролей начинает расти. Под отдельные функции создаются самостоятельные агенты, хотя на практике несколько из них могут работать с одними данными, обращаться к тем же системам и частично дублировать друг друга. Различаться при этом они будут инструкциями. В одном из наблюдаемых нами кейсов на первом этапе ИИ-трансформации компания создавала узкоспециализированных агентов под отдельные роли. По мере их роста стало заметно, что функции начинают пересекаться, а часть агентов фактически дублирует друг друга. Тогда в систему добавили мастер-агента, который анализировал существующую структуру, менял инструкции, перераспределял задачи и проектировал новые роли. После одного из аудитов он объединил дублирующиеся функции и существенно сократил количество агентов. Этот пример хорошо показывает ограничение ролевого подхода: отдельная специализация оправдана там, где действительно нужны свои полномочия, инструменты или правила работы. Но создавать постоянную цифровую «должность» под каждую новую функцию необязательно. От должности — к задаче Альтернативный подход — строить работу вокруг конкретной задачи. Под нее система получает нужный набор контекста: инструкции, данные, правила, корпоративные знания и инструменты. Для следующей задачи этот набор может быть другим. Меняется и вопрос, который задает бизнес. Не «какого цифрового сотрудника нам создать?», а «какой результат нужно получить и что потребуется системе для его достижения?». Такая логика меняет и работу с корпоративными знаниями. Если у каждого агента собственные инструкции и правила, по мере роста системы становится сложнее следить за их актуальностью и полнотой. Одно изменение может затронуть сразу несколько цифровых ролей. В едином контуре знания не закрепляются за конкретным агентом: нужные правила, инструкции, данные и инструменты подключаются в зависимости от задачи. Но корпоративный контекст — это не только регламенты и базы знаний. Такие документы описывают установленный порядок работы, тогда как на практике он может отличаться. Представим, что по регламенту счет на оплату должен пройти проверку, согласование и затем уйти в бухгалтерию. В реальности часть счетов возвращается из-за ошибок, для крупных сумм требуется дополнительное согласование, а некоторые документы проходят по другому маршруту. Различаться может и выполнение отдельных операций внутри одного процесса. Один сотрудник сразу сверяет данные в учетной системе, другой сначала ищет договор, затем проверяет карточку контрагента и только после этого возвращается к счету. Результат один, но последовательность действий и трудозатраты разные. Для ИИ эти нюансы особенно важны. Если фактический порядок работы отличается от формального описания, система рискует опираться на неполную модель процесса и автоматизировать сценарий, который не учитывает часть реальной работы. Поэтому такие расхождения нужно сначала выявить. Для этого используют аналитику бизнес-операций (Task Mining) и аналитику бизнес-процессов (Process Mining). Task Mining показывает, как сотрудники выполняют отдельные операции на компьютере: какие действия совершают и в какой последовательности работают с системами. Process Mining позволяет увидеть реальные маршруты процесса, задержки, возвраты и отклонения между этапами. Для ИИ эти данные могут стать важнейшим источником контекста наряду с классическими регламентами, правилами и корпоративными знаниями. ИИ должен менять процесс Когда понятно, как выполняется процесс на самом деле, возникает следующий вопрос — нужно ли автоматизировать его в существующем виде? Представим процесс, который проходит через пять подразделений. Один сотрудник анализирует обращение, второй проверяет документы, третий оценивает риски, четвертый готовит решение, пятый формирует ответ. Можно создать столько же ИИ-агентов и автоматизировать операции на каждом этапе. Работа ускорится, но сам процесс останется прежним. Между этапами сохранятся передачи, повторные проверки, согласования и ожидание. ИИ будет быстрее выполнять существующую схему вместе с действиями, которые могли появиться из-за прежнего распределения функций между людьми. Поэтому перед автоматизацией важно посмотреть на процесс целиком и определить, какие этапы действительно нужны для получения результата. Часть проверок можно объединить, часть передач убрать, а некоторые действия могут вообще потерять смысл. При наличии необходимых доступов и интеграций ИИ может сам собрать данные, провести стандартные проверки, подготовить результат и подключить человека там, где требуется экспертное решение или ответственность. В таком случае эффект дает не столько скорость выполнения отдельных операций, сколько изменение самого процесса. Сокращается количество передач, ручных действий и промежуточных этапов, которые раньше были необходимы из-за устройства работы. Именно здесь появляется потенциал для существенного роста производительности с учетом возможностей ИИ. Управлять нужно результатом Если работа строится вокруг задачи, количество агентов само по себе мало о чем говорит. Сто цифровых сотрудников не делают компанию автоматически эффективнее десяти. Иногда большое количество ролей означает лишь то, что существующую оргструктуру почти без изменений воспроизвели в ИИ-системе. Поэтому смотреть стоит на результат: сколько времени теперь занимает процесс, как изменилась стоимость выполнения задачи, какую часть операций система закрывает самостоятельно и где по-прежнему требуется участие человека. Сама оргструктура при этом остается. Она нужна, чтобы закреплять ответственность и полномочия между людьми. Но логика работы ИИ не обязана повторять эту схему: задача может проходить через систему без искусственного деления на цифровые должности и передаваться сотруднику только в тех точках, где его участие действительно необходимо. Для руководителя меняется и объект контроля. Важно понимать, как распределена работа между человеком и ИИ, по каким правилам действует система, где проходят границы ее самостоятельности и какой результат это дает бизнесу. #IMAGE_235400#]]></description>
<source><![CDATA[&lltt;p&ggtt;ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если &lltt;a href="https://www.itweek.ru/themes/detail.php?ID=235254"&ggtt;система получает доступ к корпоративным данным&lltt;/a&ggtt;, выполняет действия и запускает процессы, ей действительно нужны права, ограничения и понятная зона ответственности. Так появляются ИИ-аналитики, ИИ-юристы, ИИ-рекрутеры, ИИ-разработчики.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблемы возникают, когда саму &lltt;a href="https://www.itweek.ru/ai/article/detail.php?ID=235377"&ggtt;ИИ-систему&lltt;/a&ggtt; начинают выстраивать по принципам привычной оргструктуры. Такой подход понятен, потому что проще встроить нового исполнителя в уже сложившуюся модель работы, чем сразу пересматривать способ ее организации. Но по мере роста числа агентов становится заметно, что фиксированные цифровые роли подходят не для всех задач. И здесь возникает вопрос — а действительно ли ИИ нужна собственная «должность»?&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему ролевая модель плохо масштабируется&lltt;/h3&ggtt;
&lltt;p&ggtt;Ролевая модель хорошо работает, пока задачи выполняют люди. У каждого сотрудника есть свой набор компетенций, полномочий и доступов, который формируется под конкретную функцию. Поэтому знания и ответственность естественно закрепляются за отдельными ролями.&lltt;/p&ggtt;
&lltt;p&ggtt;С ИИ эта логика работает иначе. Ему не обязательно задавать только одну специализацию и ограничивать круг задач. Где-то системе могут понадобиться договоры, юридические правила и история взаимодействия с клиентом, где-то — техническая документация, финансовые показатели и данные из нескольких корпоративных систем. Нужный контекст и инструменты можно подключать непосредственно под задачу.&lltt;/p&ggtt;
&lltt;p&ggtt;Когда эту возможность не учитывают, количество цифровых ролей начинает расти. Под отдельные функции создаются самостоятельные агенты, хотя на практике несколько из них могут работать с одними данными, обращаться к тем же системам и частично дублировать друг друга. Различаться при этом они будут инструкциями.&lltt;/p&ggtt;
&lltt;p&ggtt;В одном из наблюдаемых нами кейсов на первом этапе ИИ-трансформации компания создавала узкоспециализированных агентов под отдельные роли. По мере их роста стало заметно, что функции начинают пересекаться, а часть агентов фактически дублирует друг друга. Тогда в систему добавили мастер-агента, который анализировал существующую структуру, менял инструкции, перераспределял задачи и проектировал новые роли. После одного из аудитов он объединил дублирующиеся функции и существенно сократил количество агентов.&lltt;/p&ggtt;
&lltt;p&ggtt;Этот пример хорошо показывает ограничение ролевого подхода: отдельная специализация оправдана там, где действительно нужны свои полномочия, инструменты или правила работы. Но создавать постоянную цифровую «должность» под каждую новую функцию необязательно.&lltt;/p&ggtt;
&lltt;h3&ggtt;От должности — к задаче&lltt;/h3&ggtt;
&lltt;p&ggtt;Альтернативный подход — строить работу вокруг конкретной задачи. Под нее система получает нужный набор контекста: инструкции, данные, правила, корпоративные знания и инструменты. Для следующей задачи этот набор может быть другим.&lltt;/p&ggtt;
&lltt;p&ggtt;Меняется и вопрос, который задает бизнес. Не «какого цифрового сотрудника нам создать?», а «какой результат нужно получить и что потребуется системе для его достижения?».&lltt;/p&ggtt;
&lltt;p&ggtt;Такая логика меняет и работу с корпоративными знаниями. Если у каждого агента собственные инструкции и правила, по мере роста системы становится сложнее следить за их актуальностью и полнотой. Одно изменение может затронуть сразу несколько цифровых ролей. В едином контуре знания не закрепляются за конкретным агентом: нужные правила, инструкции, данные и инструменты подключаются в зависимости от задачи.&lltt;/p&ggtt;
&lltt;p&ggtt;Но корпоративный контекст — это не только регламенты и базы знаний. Такие документы описывают установленный порядок работы, тогда как на практике он может отличаться. Представим, что по регламенту счет на оплату должен пройти проверку, согласование и затем уйти в бухгалтерию. В реальности часть счетов возвращается из-за ошибок, для крупных сумм требуется дополнительное согласование, а некоторые документы проходят по другому маршруту.&lltt;/p&ggtt;
&lltt;p&ggtt;Различаться может и выполнение отдельных операций внутри одного процесса. Один сотрудник сразу сверяет данные в учетной системе, другой сначала ищет договор, затем проверяет карточку контрагента и только после этого возвращается к счету. Результат один, но последовательность действий и трудозатраты разные.&lltt;/p&ggtt;
&lltt;p&ggtt;Для ИИ эти нюансы особенно важны. Если фактический порядок работы отличается от формального описания, система рискует опираться на неполную модель процесса и автоматизировать сценарий, который не учитывает часть реальной работы. Поэтому такие расхождения нужно сначала выявить.&lltt;/p&ggtt;
&lltt;p&ggtt;Для этого используют аналитику бизнес-операций (Task Mining) и аналитику бизнес-процессов (Process Mining). Task Mining показывает, как сотрудники выполняют отдельные операции на компьютере: какие действия совершают и в какой последовательности работают с системами. Process Mining позволяет увидеть реальные маршруты процесса, задержки, возвраты и отклонения между этапами. Для ИИ эти данные могут стать важнейшим источником контекста наряду с классическими регламентами, правилами и корпоративными знаниями.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ должен менять процесс&lltt;/h3&ggtt;
&lltt;p&ggtt;Когда понятно, как выполняется процесс на самом деле, возникает следующий вопрос — нужно ли автоматизировать его в существующем виде?&lltt;/p&ggtt;
&lltt;p&ggtt;Представим процесс, который проходит через пять подразделений. Один сотрудник анализирует обращение, второй проверяет документы, третий оценивает риски, четвертый готовит решение, пятый формирует ответ. Можно создать столько же ИИ-агентов и автоматизировать операции на каждом этапе.&lltt;/p&ggtt;
&lltt;p&ggtt;Работа ускорится, но сам процесс останется прежним. Между этапами сохранятся передачи, повторные проверки, согласования и ожидание. ИИ будет быстрее выполнять существующую схему вместе с действиями, которые могли появиться из-за прежнего распределения функций между людьми.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому перед автоматизацией важно посмотреть на процесс целиком и определить, какие этапы действительно нужны для получения результата. Часть проверок можно объединить, часть передач убрать, а некоторые действия могут вообще потерять смысл. При наличии необходимых доступов и интеграций ИИ может сам собрать данные, провести стандартные проверки, подготовить результат и подключить человека там, где требуется экспертное решение или ответственность.&lltt;/p&ggtt;
&lltt;p&ggtt;В таком случае эффект дает не столько скорость выполнения отдельных операций, сколько изменение самого процесса. Сокращается количество передач, ручных действий и промежуточных этапов, которые раньше были необходимы из-за устройства работы.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно здесь появляется потенциал для существенного роста производительности с учетом возможностей ИИ.&lltt;/p&ggtt;
&lltt;h3&ggtt;Управлять нужно результатом&lltt;/h3&ggtt;
&lltt;p&ggtt;Если работа строится вокруг задачи, количество агентов само по себе мало о чем говорит. Сто цифровых сотрудников не делают компанию автоматически эффективнее десяти. Иногда большое количество ролей означает лишь то, что существующую оргструктуру почти без изменений воспроизвели в ИИ-системе.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому смотреть стоит на результат: сколько времени теперь занимает процесс, как изменилась стоимость выполнения задачи, какую часть операций система закрывает самостоятельно и где по-прежнему требуется участие человека.&lltt;/p&ggtt;
&lltt;p&ggtt;Сама оргструктура при этом остается. Она нужна, чтобы закреплять ответственность и полномочия между людьми. Но логика работы ИИ не обязана повторять эту схему: задача может проходить через систему без искусственного деления на цифровые должности и передаваться сотруднику только в тех точках, где его участие действительно необходимо.&lltt;/p&ggtt;
&lltt;p&ggtt;Для руководителя меняется и объект контроля. Важно понимать, как распределена работа между человеком и ИИ, по каким правилам действует система, где проходят границы ее самостоятельности и какой результат это дает бизнесу.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235400#&lltt;/p&ggtt;]]></source>
<adate>26.08.2026</adate>
<dbid>235399</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/79e/13m7jyxlz8bfce5zuw54z09dklbibzob.jpg]]>
</images>
<imagesname><![CDATA[;;Александр Бочкин, генеральный директор &#8220;Инфомаксимум&#8221;   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Быстро не значит верно: кто отвечает за решение, принятое вместе с нейросетью]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235394]]></link>
<description><![CDATA[Скорость работы за последний год выросла у всех, кто подключил к процессам ИИ-инструменты. Вместе со скоростью выросла и вероятность того, что ошибка уйдет в производство незамеченной: проверять результат стало некогда, а иногда некому. Рассмотрим, как бизнесу выстроить систему верификации и почему ответственность за решение остается на человеке при любой степени автоматизации. 60% компаний работают с нейросетями без регламента Требование повышать эффективность сегодня стоит перед большинством компаний, и ИИ-инструменты выглядят самым доступным способом это требование выполнить. Там, где раньше задача занимала день, после подключения нейросети уходит несколько часов. Поэтому внедрение идет в десятки процессов одновременно, при этом, часто без предварительной перестройки процессов. Побочный эффект такого темпа уже заметен. Проверка результата занимает время, которое как раз и хотели сэкономить, поэтому часть шагов начинает выпадать: цифры не сверяются с источником, формулировки принимаются в том виде, в каком их выдала модель, спорные места дорабатываются реже. Углы срезаются постепенно и почти незаметно для самой команды. Безопаснее всего ускоряться там, где ошибка обходится сравнительно дешево. Такой подход сохраняет выигрыш в скорости и снимает основной риск, поэтому имеет смысл закрепить его как процедуру. Пока что такая процедура есть у меньшинства: около 60% организаций не имеют формализованных правил работы с нейросетями, при том что 26% сотрудников используют их регулярно и еще 35% периодически. Сотрудник в такой ситуации сам решает, какой сервис выбрать, какие данные туда отправить и насколько тщательно нужно проверять ответ. Отсутствие правил само по себе не создает проблему, пока результат работы модели остается корректным. Но когда модель ошибается, а ошибка выглядит достоверно и уходит дальше по цепочке без проверки, бизнес сталкивается с серьезными рисками. Именно такие случаи сейчас доходят до публичных разбирательств и показывают, во что обходится компании непроверенный ответ. Модель выдумывает ссылки, компания платит штраф Ярче всего проблема ИИ-галлюцинаций проявилась в юридической сфере. Причина в том, что каждая ссылка в документе проверяется второй стороной и судом, поэтому выдуманная норма обнаруживается почти всегда. Модель выдает ее с точной формулировкой и номером дела, но при проверке выясняется, что документа не существует. В базе таких случаев к июлю 2026 года накопилось 1725 дел из 35 стран с 5169 некорректными ссылками. История дошла и до российских судов: весной 2026 года арбитражный суд оштрафовал компанию на 50 тысяч рублей за ссылки на несуществующую судебную практику, квалифицировав это как обман суда. Принципиальная деталь этого решения касается любого бизнеса. Суд не выяснял, придумал ссылки человек или модель, поскольку ответственность за поданный документ несет тот, кто его подписал. Инструмент, с помощью которого документ готовился, на распределение ответственности не влияет. В работе с нейросетями важно помнить, что модель подстраивается под задачу пользователя и стремится дать ответ, который выглядит подходящим, поэтому недостающие детали достраиваются правдоподобно. Скорость развития моделей на эту особенность влияет слабо: случаи с выдуманными ссылками продолжают накапливаться быстрее, чем годом раньше. Проверка результата поэтому переходит из разряда желательных процедур в обязательные. Ответственность нельзя разделить с инструментом Подпись под решением всегда ставит человек, и это единственная точка, где ответственность фиксируется юридически. Вина при разборе распределяется между сотрудником, который принес решение, и руководителем, который его согласовал. Модель в этой схеме места не занимает ни при каком раскладе. По этой причине, если специалист согласовал решение, не разобравшись в предметной области, проблема лежит исключительно в его экспертизе. Ответственность за результат остается ровно там же, где была до появления нейросетей, поэтому требования к пониманию сути задачи растут вместе со скоростью ее выполнения. Как посчитать цену ошибки в своей компании Почти ни у одной компании сейчас нет понимания, во сколько ей обходится конкретная ошибка. Однако ее стоит посчитать в потраченных часах, деньгах, потерянных клиентах и репутационных издержках, чтобы оценивать риски трезво. Так, три дня неудачного эксперимента укладываются в допустимую потерю, поскольку компания теряет только время команды, а ошибка в клиентских данных, в расчете себестоимости или в юридическом документе стоит несопоставимо дороже. Шкала собирается из трех шагов. Сначала все процессы раскладываются по уровню критичности, от свободных экспериментов до задач, где ошибка стоит компании контракта. Затем на каждый уровень назначается лимит эксперимента в днях и деньгах, а для самых критичных задач вводится обязательная проверка вторым человеком. Отдельным списком фиксируются задачи, результат которых вообще не принимается без ревью. Такая шкала позволяет компании ускоряться с пониманием всей ответственности. Там, где ошибка обходится дешево, команда может работать на полной скорости и учиться на неудачных попытках. Там, где ошибка стоит дорого, часть скорости сознательно отдается за контроль, причем решение об этом принимается заранее и не зависит от загрузки конкретного дня. К работе руководителя добавилась проверка результата Раньше от руководителя требовались экспертиза и накопленный опыт. Теперь к ним добавилась обязательная верификация того, что принес сотрудник вместе с инструментом. Задача эта постоянная, поскольку объем проходящих через руководителя решений вырос вместе с общей скоростью работы. Чтобы проверять, руководитель обязан понимать принцип работы модели и знать конкретные места, где она может допустить ошибку: выдуманные ссылки и цитаты, подгонка ответа под ожидание, потеря контекста в длинных задачах. Рядовому сотруднику допустимо этого не знать, но руководителю такой пробел непозволителен, поскольку именно он ставит подпись. По уровням это разворачивается в понятную схему. Линейный менеджер отвечает за верификацию на своем участке, руководитель департамента — за корректность процессов внутри направления, топ-менеджмент определяет зоны, где риск неприемлем, на уровне всей компании. С чего начать внедрение нейросетей в бизнес-процессы Все перечисленное сводится к нескольким процедурам, которые компания способна завести своими силами за месяц. Порядок здесь имеет значение: сначала описывается организационная часть процессов, потому что без нее непонятно, что и с какой тщательностью проверять, и затем детализируется техническая. Организационная часть: 	 Разложить процессы по уровню критичности и зафиксировать, во сколько компании обходится ошибка на каждом из них. 	 Назначить ответственного за проверку на каждом уровне, от линейного руководителя до топ-менеджмента. 	 Ввести правило обязательной проверки фактов, цифр и ссылок в документах, которые уходят за пределы компании. 	 Установить лимит эксперимента в днях и деньгах для задач с низкой критичностью. 	 Составить список задач, результат которых не принимается без проверки человеком. Техническая часть: 	 Собрать базу скиллов, тулов и плагинов с правилами работы ИИ-агента для разных этапов процесса. Каждый этап работы получает свой набор инструкций, который определяет, на какие данные агент опирается, какой результат считается корректным и какие действия недопустимы. 	 Настроить процесс ревью, при котором решения, выданные агентом, проверяет другой агент. 	 Запустить рефлексию по итогам ревью: агент разбирает собственные ошибки и определяет, на каком шаге и почему инструкция сработала неверно. 	 Скорректировать работу агента по результатам ревью, чтобы та же ошибка не воспроизводилась на следующих задачах. Разумеется, скорость работы остается конкурентным преимуществом, и компании, которые откажутся от нее из осторожности, проиграют тем, кто научился работать быстро. Смысл шкалы критичности в том, что она показывает, где можно двигаться на полной скорости без оглядки и где стоит потратить лишний час на проверку. Без такой разметки команда либо тормозит везде одинаково, либо везде одинаково рискует. Технология при этом развивается быстрее, чем компании успевают выстраивать вокруг нее процессы. Верификация становится постоянной частью работы руководителя, благодаря которой ускорение всех процессов возможно. Компании, которые отстраивают эти процессы, получают возможность внедрять новые инструменты без пауз и рисков, которые несут незамеченные ошибки. #IMAGE_235395#]]></description>
<source><![CDATA[&lltt;p&ggtt;Скорость работы за&nbsp;последний год выросла у&nbsp;всех, кто подключил к&nbsp;процессам ИИ-инструменты. Вместе со&nbsp;скоростью выросла и&nbsp;вероятность того, что ошибка уйдет в&nbsp;производство незамеченной: проверять результат стало некогда, а&nbsp;иногда некому.&lltt;/p&ggtt;
&lltt;p&ggtt;Рассмотрим, как бизнесу выстроить систему верификации и&nbsp;почему ответственность за&nbsp;решение остается на&nbsp;человеке при любой степени автоматизации.&lltt;/p&ggtt;
&lltt;h3&ggtt;60% компаний работают с&nbsp;нейросетями без регламента&lltt;/h3&ggtt;
&lltt;p&ggtt;Требование повышать эффективность сегодня стоит перед большинством компаний, и&nbsp;ИИ-инструменты выглядят самым доступным способом это требование выполнить. Там, где раньше задача занимала день, после подключения нейросети уходит несколько часов. Поэтому внедрение идет в&nbsp;десятки процессов одновременно, при этом, часто без предварительной перестройки процессов.&lltt;/p&ggtt;
&lltt;p&ggtt;Побочный эффект такого темпа уже заметен. Проверка результата занимает время, которое как раз и&nbsp;хотели сэкономить, поэтому часть шагов начинает выпадать: цифры не&nbsp;сверяются с&nbsp;источником, формулировки принимаются в&nbsp;том виде, в&nbsp;каком их&nbsp;выдала модель, спорные места дорабатываются реже. Углы срезаются постепенно и&nbsp;почти незаметно для самой команды.&lltt;/p&ggtt;
&lltt;p&ggtt;Безопаснее всего ускоряться там, где ошибка обходится сравнительно дешево. Такой подход сохраняет выигрыш в&nbsp;скорости и&nbsp;снимает основной риск, поэтому имеет смысл закрепить его как процедуру. Пока что такая процедура есть у&nbsp;меньшинства: около&nbsp;60% организаций &lltt;a href="https://pohodu.media/tenevoj-ii-kak-bezopasno-rabotat-s-nejrosetjami-v-kompanii/"&ggtt;не&nbsp;имеют&lltt;/a&ggtt; формализованных правил работы с&nbsp;нейросетями, при том что&nbsp;26% сотрудников используют их&nbsp;регулярно и&nbsp;еще&nbsp;35% периодически. Сотрудник в&nbsp;такой ситуации сам решает, какой сервис выбрать, какие данные туда отправить и&nbsp;насколько тщательно нужно проверять ответ.&lltt;/p&ggtt;
&lltt;p&ggtt;Отсутствие правил само по&nbsp;себе не&nbsp;создает проблему, пока результат работы модели остается корректным. Но&nbsp;когда модель ошибается, а&nbsp;ошибка выглядит достоверно и&nbsp;уходит дальше по&nbsp;цепочке без проверки, бизнес сталкивается с&nbsp;серьезными рисками. Именно такие случаи сейчас доходят до&nbsp;публичных разбирательств и&nbsp;показывают, во&nbsp;что обходится компании непроверенный ответ.&lltt;/p&ggtt;
&lltt;h3&ggtt;Модель выдумывает ссылки, компания платит штраф&lltt;/h3&ggtt;
&lltt;p&ggtt;Ярче всего проблема ИИ-галлюцинаций проявилась в&nbsp;юридической сфере. Причина в&nbsp;том, что каждая ссылка в&nbsp;документе проверяется второй стороной и&nbsp;судом, поэтому выдуманная норма обнаруживается почти всегда. Модель выдает ее&nbsp;с&nbsp;точной формулировкой и&nbsp;номером дела, но&nbsp;при проверке выясняется, что документа не&nbsp;существует.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;базе таких случаев к&nbsp;июлю 2026 года &lltt;a href="https://www.kommersant.ru/doc/8799829"&ggtt;накопилось&lltt;/a&ggtt; 1725 дел из&nbsp;35&nbsp;стран с&nbsp;5169 некорректными ссылками. История дошла и&nbsp;до&nbsp;российских судов: весной 2026 года арбитражный суд &lltt;a href="https://ziam.moscow/publikatsii/sud-oshtrafoval-kompaniyu-za-ispolzovanie-ii-pri-podgotovke-kassatsionnoy-zhaloby/"&ggtt;оштрафовал&lltt;/a&ggtt; компанию на&nbsp;50&nbsp;тысяч рублей за&nbsp;ссылки на&nbsp;несуществующую судебную практику, квалифицировав это как обман суда.&lltt;/p&ggtt;
&lltt;p&ggtt;Принципиальная деталь этого решения касается любого бизнеса. Суд не&nbsp;выяснял, придумал ссылки человек или модель, поскольку ответственность за&nbsp;поданный документ несет тот, кто его подписал. Инструмент, с&nbsp;помощью которого документ готовился, на&nbsp;распределение ответственности не&nbsp;влияет.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;работе с&nbsp;нейросетями важно помнить, что модель подстраивается под задачу пользователя и&nbsp;стремится дать ответ, который выглядит подходящим, поэтому недостающие детали достраиваются правдоподобно. Скорость развития моделей на&nbsp;эту особенность влияет слабо: случаи с&nbsp;выдуманными ссылками продолжают накапливаться быстрее, чем годом раньше. Проверка результата поэтому переходит из&nbsp;разряда желательных процедур в&nbsp;обязательные.&lltt;/p&ggtt;
&lltt;h3&ggtt;Ответственность нельзя разделить с&nbsp;инструментом&lltt;/h3&ggtt;
&lltt;p&ggtt;Подпись под решением всегда ставит человек, и&nbsp;это единственная точка, где ответственность фиксируется юридически. Вина при разборе распределяется между сотрудником, который принес решение, и&nbsp;руководителем, который его согласовал. Модель в&nbsp;этой схеме места не&nbsp;занимает ни&nbsp;при каком раскладе.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;этой причине, если специалист согласовал решение, не&nbsp;разобравшись в&nbsp;предметной области, проблема лежит исключительно в&nbsp;его экспертизе. Ответственность за&nbsp;результат остается ровно там&nbsp;же, где была до&nbsp;появления нейросетей, поэтому требования к&nbsp;пониманию сути задачи растут вместе со&nbsp;скоростью ее&nbsp;выполнения.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как посчитать цену ошибки в&nbsp;своей компании&lltt;/h3&ggtt;
&lltt;p&ggtt;Почти ни&nbsp;у&nbsp;одной компании сейчас нет понимания, во&nbsp;сколько ей&nbsp;обходится конкретная ошибка. Однако ее&nbsp;стоит посчитать в&nbsp;потраченных часах, деньгах, потерянных клиентах и&nbsp;репутационных издержках, чтобы оценивать риски трезво. Так, три дня неудачного эксперимента укладываются в&nbsp;допустимую потерю, поскольку компания теряет только время команды, а&nbsp;ошибка в&nbsp;клиентских данных, в&nbsp;расчете себестоимости или в&nbsp;юридическом документе стоит несопоставимо дороже.&lltt;/p&ggtt;
&lltt;p&ggtt;Шкала собирается из&nbsp;трех шагов. Сначала все процессы раскладываются по&nbsp;уровню критичности, от&nbsp;свободных экспериментов до&nbsp;задач, где ошибка стоит компании контракта. Затем на&nbsp;каждый уровень назначается лимит эксперимента в&nbsp;днях и&nbsp;деньгах, а&nbsp;для самых критичных задач вводится обязательная проверка вторым человеком. Отдельным списком фиксируются задачи, результат которых вообще не&nbsp;принимается без ревью.&lltt;/p&ggtt;
&lltt;p&ggtt;Такая шкала позволяет компании ускоряться с&nbsp;пониманием всей ответственности. Там, где ошибка обходится дешево, команда может работать на&nbsp;полной скорости и&nbsp;учиться на&nbsp;неудачных попытках. Там, где ошибка стоит дорого, часть скорости сознательно отдается за&nbsp;контроль, причем решение об&nbsp;этом принимается заранее и&nbsp;не&nbsp;зависит от&nbsp;загрузки конкретного дня.&lltt;/p&ggtt;
&lltt;h3&ggtt;К&nbsp;работе руководителя добавилась проверка результата&lltt;/h3&ggtt;
&lltt;p&ggtt;Раньше от&nbsp;руководителя требовались экспертиза и&nbsp;накопленный опыт. Теперь к&nbsp;ним добавилась обязательная верификация того, что принес сотрудник вместе с&nbsp;инструментом. Задача эта постоянная, поскольку объем проходящих через руководителя решений вырос вместе с&nbsp;общей скоростью работы.&lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы проверять, руководитель обязан понимать принцип работы модели и&nbsp;знать конкретные места, где она может допустить ошибку: выдуманные ссылки и&nbsp;цитаты, подгонка ответа под ожидание, потеря контекста в&nbsp;длинных задачах. Рядовому сотруднику допустимо этого не&nbsp;знать, но&nbsp;руководителю такой пробел непозволителен, поскольку именно он&nbsp;ставит подпись.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;уровням это разворачивается в&nbsp;понятную схему. Линейный менеджер отвечает за&nbsp;верификацию на&nbsp;своем участке, руководитель департамента&nbsp;— за&nbsp;корректность процессов внутри направления, топ-менеджмент определяет зоны, где риск неприемлем, на&nbsp;уровне всей компании.&lltt;/p&ggtt;
&lltt;h3&ggtt;С&nbsp;чего начать внедрение нейросетей в&nbsp;бизнес-процессы&lltt;/h3&ggtt;
&lltt;p&ggtt;Все перечисленное сводится к&nbsp;нескольким процедурам, которые компания способна завести своими силами за&nbsp;месяц. Порядок здесь имеет значение: сначала описывается организационная часть процессов, потому что без нее непонятно, что и&nbsp;с&nbsp;какой тщательностью проверять, и&nbsp;затем детализируется техническая.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Организационная часть:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; Разложить процессы по&nbsp;уровню критичности и&nbsp;зафиксировать, во&nbsp;сколько компании обходится ошибка на&nbsp;каждом из&nbsp;них.&lltt;/li&ggtt;
	&lltt;li&ggtt; Назначить ответственного за&nbsp;проверку на&nbsp;каждом уровне, от&nbsp;линейного руководителя до&nbsp;топ-менеджмента.&lltt;/li&ggtt;
	&lltt;li&ggtt; Ввести правило обязательной проверки фактов, цифр и&nbsp;ссылок в&nbsp;документах, которые уходят за&nbsp;пределы компании.&lltt;/li&ggtt;
	&lltt;li&ggtt; Установить лимит эксперимента в&nbsp;днях и&nbsp;деньгах для задач с&nbsp;низкой критичностью.&lltt;/li&ggtt;
	&lltt;li&ggtt; Составить список задач, результат которых не&nbsp;принимается без проверки человеком.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Техническая часть:&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; Собрать базу скиллов, тулов и&nbsp;плагинов с&nbsp;правилами работы ИИ-агента для разных этапов процесса. Каждый этап работы получает свой набор инструкций, который определяет, на&nbsp;какие данные агент опирается, какой результат считается корректным и&nbsp;какие действия недопустимы.&lltt;/li&ggtt;
	&lltt;li&ggtt; Настроить процесс ревью, при котором решения, выданные агентом, проверяет другой агент.&lltt;/li&ggtt;
	&lltt;li&ggtt; Запустить рефлексию по&nbsp;итогам ревью: агент разбирает собственные ошибки и&nbsp;определяет, на&nbsp;каком шаге и&nbsp;почему инструкция сработала неверно.&lltt;/li&ggtt;
	&lltt;li&ggtt; Скорректировать работу агента по&nbsp;результатам ревью, чтобы та&nbsp;же ошибка не&nbsp;воспроизводилась на&nbsp;следующих задачах.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Разумеется, скорость работы остается конкурентным преимуществом, и&nbsp;компании, которые откажутся от&nbsp;нее из&nbsp;осторожности, проиграют тем, кто научился работать быстро. Смысл шкалы критичности в&nbsp;том, что она показывает, где можно двигаться на&nbsp;полной скорости без оглядки и&nbsp;где стоит потратить лишний час на&nbsp;проверку. Без такой разметки команда либо тормозит везде одинаково, либо везде одинаково рискует.&lltt;/p&ggtt;
&lltt;p&ggtt;Технология при этом развивается быстрее, чем компании успевают выстраивать вокруг нее процессы. Верификация становится постоянной частью работы руководителя, благодаря которой ускорение всех процессов возможно. Компании, которые отстраивают эти процессы, получают возможность внедрять новые инструменты без пауз и&nbsp;рисков, которые несут незамеченные ошибки.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235395#&lltt;/p&ggtt;]]></source>
<adate>25.08.2026</adate>
<dbid>235394</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/c0d/wlf555cpd4jsc08rck2vdtg9u7k32ovr.jpg]]>
</images>
<imagesname><![CDATA[;;Олег Строкатый, руководитель направления контроля качества &#34;Битрикс24&#34;   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Forrester предлагает модель для оценки влияния ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235396]]></link>
<description><![CDATA[Угроза «SaaS-апокалипсиса» упускает из виду более широкую картину. Хотя большинство комментариев сосредоточены на снижении доходов от модели, основанной на использовании рабочих мест (прогнозируя, что агенты искусственного интеллекта положат конец лицензиям на ПО), это лишь один из девяти критически важных факторов, способствующих кардинальным изменениям, пишут в корпоративном блоге вице-президенты и главные аналитики Forrester Крейг Ле Клер и Тед Шадлер. Будучи глобальной исследовательской компанией, оценивающей весь технологический ландшафт, Forrester создала AI Disruption Model — модель анализа влияния ИИ на основе данных. Эта модель, построенная на исследованиях Forrester и общедоступной информации, отсеивает лишнюю информацию, обеспечивая прозрачность рыночных изменений и всеобъемлющую основу для прогнозирования будущего. Forrester AI Disruption Model оценивает 17 категорий технологий и услуг, охватывающих более 200 рынков. Данная модель анализирует структурную динамику рынка по девяти ключевым факторам, включая взаимозаменяемость ИИ, трудоемкость, коммерческую модель, поддержку агентных рабочих нагрузок, затраты на переход и регуляторные барьеры. Главный вывод очевиден: влияние ИИ не будет распределено равномерно. В то время как некоторые рынки и поставщики сталкиваются с серьезными трудностями, другие готовы к историческому ускорению. #IMAGE_235397# Мы разделили рынки на четыре категории: подверженные дестабилизации (disrupted), нейтрально реагирующие (neutral), подверженные балансу факторов (contested) и обеспечивающие ускорение (accelerated): 	 Рынки, подверженные дестабилизации — здесь ИИ воспроизводит свою основную ценность. Если ИИ может сделать что-то, что может сделать человек или существующий программный продукт, он это сделает. Поставщики и сервис-провайдеры в этой категории сталкиваются с ценовым давлением, сокращением рабочих мест и коммодитизацией своих основных возможностей или наборов функций. Наиболее серьезно дестабилизирующие факторы, связанные с ИИ, затрагивают трудоемкие сегменты, такие как внедрение технологий, разработка ПО на заказ, креативные услуги и корпоративное обучение. Эти рынки находятся под огромным давлением, поскольку ИИ берет на себя функции, ранее выполнявшиеся экспертами-людьми. 	 Нейтрально реагирующие рынки — здесь ценность не является преимущественно информационной. Если поставщики и сервис-провайдеры предлагают физические возможности, ориентированные на регулируемые рынки или защищенные высокими затратами на смену поставщика, они менее подвержены влиянию перехода на ИИ. Эти факторы сдерживают прогресс ИИ и обеспечивают стабильность ценности. 	 Рынки, подверженные балансу факторов — готовые к ускоренному развитию. Поставщики и сервис-провадеры на таких рынках видят баланс обеспечивающих нейтральное реагирование и ускорение факторов, позволяющий перейти к ускоренному развитию. Они не будут сидеть сложа руки и ждать, пока их вытеснят, а перенаправят инвестиционный капитал и НИОКР на поддержку агентных рабочих нагрузок, данных, доверия и суверенитета. Поставщики в этой категории могут позитивно внедрять ИИ в свои платформы, но сталкиваются с проблемами реализации, капитала и трудовых ресурсов. 	 Рынки, обеспечивающие ускорение — здесь продают все, что требуется для работы с ИИ. Поставщики инфраструктуры, данных, моделей, интеграции или возможностей обеспечения доверия являются основой агентных рабочих процессов — и будущими опорами бизнеса, основанного на ИИ. Спрос на их предложения напрямую зависит от уровня внедрения ИИ: чем больше специализированных ИИ-агентов и целевых агентных систем развертывают предприятия, тем больше технологий продают эти поставщики. Задача для покупателей корпоративных технологий, поставщиков и сервисных компаний — понять, как ИИ меняет рынки. Независимо от того, являетесь ли вы покупателем, стремящимся оптимизировать свой технологический портфель, или поставщиком, защищающим свою долю рынка и будущее, Forrester AI Disruption Model предлагает схему, необходимую для понимания этого сдвига. Покупатели корпоративных технологий могут использовать эту модель с целью защиты инвестиций при закупках, изолируя устаревшие, обремененные долгами инструменты, чтобы направить инвестиции масштабируемым, готовым к использованию агентных систем поставщикам. Для поставщиков технологий и сервис-провайдеров модель предлагает действенную дорожную карту, позволяющую оценить риски, защитить основной доход и переориентироваться на долгосрочный рост, прежде чем устаревшие модели исчерпают себя]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Угроза «SaaS-апокалипсиса» упускает из&nbsp;виду более широкую картину. Хотя большинство комментариев сосредоточены на&nbsp;снижении доходов от&nbsp;модели, основанной на&nbsp;использовании рабочих мест (прогнозируя, что агенты искусственного интеллекта положат конец лицензиям на&nbsp;ПО), это лишь один из&nbsp;девяти критически важных факторов, способствующих кардинальным изменениям, пишут в&nbsp;корпоративном блоге вице-президенты и&nbsp;главные аналитики &lltt;/em&ggtt;&lltt;em&ggtt;Forrester&lltt;/em&ggtt; &lltt;em&ggtt;Крейг Ле&nbsp;Клер и&nbsp;Тед Шадлер.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Будучи глобальной исследовательской компанией, оценивающей весь технологический ландшафт, Forrester создала AI&nbsp;Disruption Model&nbsp;— модель анализа влияния&nbsp;ИИ на&nbsp;основе данных. Эта модель, построенная на&nbsp;исследованиях Forrester и&nbsp;общедоступной информации, отсеивает лишнюю информацию, обеспечивая прозрачность рыночных изменений и&nbsp;всеобъемлющую основу для прогнозирования будущего.&lltt;/p&ggtt;
&lltt;p&ggtt;Forrester AI&nbsp;Disruption Model оценивает 17&nbsp;категорий технологий и&nbsp;услуг, охватывающих более 200&nbsp;рынков. Данная модель анализирует структурную динамику рынка по&nbsp;девяти ключевым факторам, включая взаимозаменяемость&nbsp;ИИ, трудоемкость, коммерческую модель, поддержку агентных рабочих нагрузок, затраты на&nbsp;переход и&nbsp;регуляторные барьеры. Главный вывод очевиден: влияние&nbsp;ИИ не&nbsp;будет распределено равномерно. В&nbsp;то&nbsp;время как некоторые рынки и&nbsp;поставщики сталкиваются с&nbsp;серьезными трудностями, другие готовы к&nbsp;историческому ускорению.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235397#&lltt;/p&ggtt;
&lltt;p&ggtt;Мы&nbsp;разделили рынки на&nbsp;четыре категории: подверженные дестабилизации (disrupted), нейтрально реагирующие (neutral), подверженные балансу факторов (contested) и&nbsp;обеспечивающие ускорение (accelerated):&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; Рынки, подверженные дестабилизации&nbsp;— здесь&nbsp;ИИ воспроизводит свою основную ценность. Если ИИ&nbsp;может сделать что-то, что может сделать человек или существующий программный продукт, он&nbsp;это сделает. Поставщики и&nbsp;сервис-провайдеры в&nbsp;этой категории сталкиваются с&nbsp;ценовым давлением, сокращением рабочих мест и&nbsp;коммодитизацией своих основных возможностей или наборов функций. Наиболее серьезно дестабилизирующие факторы, связанные с&nbsp;ИИ, затрагивают трудоемкие сегменты, такие как внедрение технологий, разработка&nbsp;ПО на&nbsp;заказ, креативные услуги и&nbsp;корпоративное обучение. Эти рынки находятся под огромным давлением, поскольку&nbsp;ИИ берет на&nbsp;себя функции, ранее выполнявшиеся экспертами-людьми.&lltt;/li&ggtt;
	&lltt;li&ggtt; Нейтрально реагирующие рынки&nbsp;— здесь ценность не&nbsp;является преимущественно информационной. Если поставщики и&nbsp;сервис-провайдеры предлагают физические возможности, ориентированные на&nbsp;регулируемые рынки или защищенные высокими затратами на&nbsp;смену поставщика, они менее подвержены влиянию перехода на&nbsp;ИИ. Эти факторы сдерживают прогресс&nbsp;ИИ и&nbsp;обеспечивают стабильность ценности.&lltt;/li&ggtt;
	&lltt;li&ggtt; Рынки, подверженные балансу факторов&nbsp;— готовые к&nbsp;ускоренному развитию. Поставщики и&nbsp;сервис-провадеры на&nbsp;таких рынках видят баланс обеспечивающих нейтральное реагирование и&nbsp;ускорение факторов, позволяющий перейти к&nbsp;ускоренному развитию. Они не&nbsp;будут сидеть сложа руки и&nbsp;ждать, пока их&nbsp;вытеснят, а&nbsp;перенаправят инвестиционный капитал и&nbsp;НИОКР на&nbsp;поддержку агентных рабочих нагрузок, данных, доверия и&nbsp;суверенитета. Поставщики в&nbsp;этой категории могут позитивно внедрять&nbsp;ИИ в&nbsp;свои платформы, но&nbsp;сталкиваются с&nbsp;проблемами реализации, капитала и&nbsp;трудовых ресурсов.&lltt;/li&ggtt;
	&lltt;li&ggtt; Рынки, обеспечивающие ускорение&nbsp;— здесь продают все, что требуется для работы с&nbsp;ИИ. Поставщики инфраструктуры, данных, моделей, интеграции или возможностей обеспечения доверия являются основой агентных рабочих процессов&nbsp;— и&nbsp;будущими опорами бизнеса, основанного на&nbsp;ИИ. Спрос на&nbsp;их&nbsp;предложения напрямую зависит от&nbsp;уровня внедрения&nbsp;ИИ: чем больше специализированных ИИ-агентов и&nbsp;целевых агентных систем развертывают предприятия, тем больше технологий продают эти поставщики.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Задача для покупателей корпоративных технологий, поставщиков и&nbsp;сервисных компаний&nbsp;— понять, как&nbsp;ИИ меняет рынки. Независимо от&nbsp;того, являетесь&nbsp;ли вы&nbsp;покупателем, стремящимся оптимизировать свой технологический портфель, или поставщиком, защищающим свою долю рынка и&nbsp;будущее, Forrester AI&nbsp;Disruption Model предлагает схему, необходимую для понимания этого сдвига.&lltt;/p&ggtt;
&lltt;p&ggtt;Покупатели корпоративных технологий могут использовать эту модель с&nbsp;целью защиты инвестиций при закупках, изолируя устаревшие, обремененные долгами инструменты, чтобы направить инвестиции масштабируемым, готовым к&nbsp;использованию агентных систем поставщикам. Для поставщиков технологий и&nbsp;сервис-провайдеров модель предлагает действенную дорожную карту, позволяющую оценить риски, защитить основной доход и&nbsp;переориентироваться на&nbsp;долгосрочный рост, прежде чем устаревшие модели исчерпают себя.&lltt;/p&ggtt;]]></source>
<adate>25.08.2026</adate>
<dbid>235396</dbid>
<rubric>8</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/a33/97bhrb74mq5ocnwo5jvccmn734i3y2l4.jpg]]>
</images>
<imagesname><![CDATA[;;Источник: Forrester   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-индустрия;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[IT SAILING DAY 2026: эксперты назвали ключевые рычаги экономии для enterprise‑бизнеса — как сократить ИТ‑бюджет без потери эффективности]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235398]]></link>
<description><![CDATA[13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия, посвященная поиску баланса между сокращением затрат и поддержанием эффективности в крупных компаниях. Мероприятие прошло в седьмой раз подряд и было организовано системным интегратором и разработчиком ИТ‑решений DCLogic. В дискуссии также приняли участие ведущие эксперты ИТ‑рынка — представители ИТ‑вендоров и дистрибьюторов, а также руководители и специалисты крупного бизнеса, которые поделились практическими кейсами и отраслевыми наблюдениями. Модератором сессии выступил Сергей Козырь, генеральный директор Digital Advisers, который структурировал обсуждение и помог раскрыть ключевые аспекты темы. Эксперты обозначили конкретные инструменты, позволяющие enterprise‑компаниям оптимизировать ИТ‑расходы: переход на гибкие модели оплаты (включая подписочные сервисы), запуск пилотных проектов для быстрой проверки гипотез и масштабирования только доказавших эффективность решений. Особый акцент был сделан на измеримости ценности — внедрение технологий, теперь обосновывают через четкие метрики и экономический эффект, что помогает исключить нецелевые траты. Также выделили ключевые векторы применения ИИ в enterprise‑сегменте: компании делают ставку на интеграцию генеративного ИИ в существующие ИТ‑контуры для сокращения рутинных операций при сохранении безопасности данных, активно развивают внутренние компетенции по созданию ИИ‑агентов, чтобы снизить зависимость от дорогостоящих внешних разработок, и при этом также привязывают внедрение ИИ технологий к измеримым бизнес‑результатам. Важной частью дискуссии стали экспертные оценки. Сергей Козырь отметил: «С одной стороны, сегодня бизнес сталкивается с серьезными вызовами: у многих компаний наблюдается невыполнение планов. С другой — происходит сокращение бюджетов и доступных возможностей. При этом объем задач для ИТ‑подразделений не уменьшается, а зачастую даже растет — особенно в условиях оптимизации». Евгений Шелестюк, генеральный директор DCLogic, добавил: «За последние два месяца мы заметили резкий сдвиг в запросах клиентов. Если раньше компании стремились наращивать капитал и повышать стоимость бизнеса, то сейчас главный тренд — переход на подписочную модель, чтобы снизить единовременные затраты. Клиенты хотят платить меньше „в моменте“ и получать решения в формате сервиса: аренда серверов, доступ к облачным ресурсам, помесячная оплата — фактически это аналог рассрочки». Участники также выделили важность системного подхода: аудит ИТ‑инфраструктуры, прозрачное бюджетирование и дорожные карты позволяют выявлять избыточные процессы и выбирать оптимальные решения. Дополнительным рычагом экономии стало применение готовых интеграционных инструментов (коннекторов, типовых решений), сокращающих стоимость и сроки проектов. Отдельно эксперты рассмотрели эволюцию рисков — от классической ИБ к комплексному подходу, включающему и физическую защиту объектов, и корректную работу с данными. Представленные на дискуссии практики дают рынку готовые ориентиры: компании могут применять описанные механизмы для снижения издержек, ускорения окупаемости ИТ‑проектов и формирования устойчивой стратегии развития. Такой подход позволяет не просто сокращать бюджет, а перераспределять ресурсы на наиболее результативные направления, сохраняя конкурентоспособность в меняющихся условиях]]></description>
<source><![CDATA[&lltt;p&ggtt;13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия, посвященная поиску баланса между сокращением затрат и поддержанием эффективности в крупных компаниях. Мероприятие прошло в седьмой раз подряд и было организовано системным интегратором и разработчиком ИТ‑решений DCLogic.&lltt;/p&ggtt;
&lltt;p&ggtt;В дискуссии также приняли участие ведущие эксперты ИТ‑рынка — представители ИТ‑вендоров и дистрибьюторов, а также руководители и специалисты крупного бизнеса, которые поделились практическими кейсами и отраслевыми наблюдениями. Модератором сессии выступил Сергей Козырь, генеральный директор Digital Advisers, который структурировал обсуждение и помог раскрыть ключевые аспекты темы.&lltt;/p&ggtt;
&lltt;p&ggtt;Эксперты обозначили конкретные инструменты, позволяющие enterprise‑компаниям оптимизировать ИТ‑расходы: переход на гибкие модели оплаты (включая подписочные сервисы), запуск пилотных проектов для быстрой проверки гипотез и масштабирования только доказавших эффективность решений. Особый акцент был сделан на измеримости ценности — внедрение технологий, теперь обосновывают через четкие метрики и экономический эффект, что помогает исключить нецелевые траты.&lltt;/p&ggtt;
&lltt;p&ggtt;Также выделили ключевые векторы применения ИИ в enterprise‑сегменте: компании делают ставку на интеграцию генеративного ИИ в существующие ИТ‑контуры для сокращения рутинных операций при сохранении безопасности данных, активно развивают внутренние компетенции по созданию ИИ‑агентов, чтобы снизить зависимость от дорогостоящих внешних разработок, и при этом также привязывают внедрение ИИ технологий к измеримым бизнес‑результатам.&lltt;/p&ggtt;
&lltt;p&ggtt;Важной частью дискуссии стали экспертные оценки. Сергей Козырь отметил: «С одной стороны, сегодня бизнес сталкивается с серьезными вызовами: у многих компаний наблюдается невыполнение планов. С другой — происходит сокращение бюджетов и доступных возможностей. При этом объем задач для ИТ‑подразделений не уменьшается, а зачастую даже растет — особенно в условиях оптимизации».&lltt;/p&ggtt;
&lltt;p&ggtt;Евгений Шелестюк, генеральный директор DCLogic, добавил: «За последние два месяца мы заметили резкий сдвиг в запросах клиентов. Если раньше компании стремились наращивать капитал и повышать стоимость бизнеса, то сейчас главный тренд — переход на подписочную модель, чтобы снизить единовременные затраты.&lltt;/p&ggtt;
&lltt;p&ggtt;Клиенты хотят платить меньше „в моменте“ и получать решения в формате сервиса: аренда серверов, доступ к облачным ресурсам, помесячная оплата — фактически это аналог рассрочки».&lltt;/p&ggtt;
&lltt;p&ggtt;Участники также выделили важность системного подхода: аудит ИТ‑инфраструктуры, прозрачное бюджетирование и дорожные карты позволяют выявлять избыточные процессы и выбирать оптимальные решения. Дополнительным рычагом экономии стало применение готовых интеграционных инструментов (коннекторов, типовых решений), сокращающих стоимость и сроки проектов. Отдельно эксперты рассмотрели эволюцию рисков — от классической ИБ к комплексному подходу, включающему и физическую защиту объектов, и корректную работу с данными.&lltt;/p&ggtt;
&lltt;p&ggtt;Представленные на дискуссии практики дают рынку готовые ориентиры: компании могут применять описанные механизмы для снижения издержек, ускорения окупаемости ИТ‑проектов и формирования устойчивой стратегии развития. Такой подход позволяет не просто сокращать бюджет, а перераспределять ресурсы на наиболее результативные направления, сохраняя конкурентоспособность в меняющихся условиях.&lltt;/p&ggtt;]]></source>
<adate>25.08.2026</adate>
<dbid>235398</dbid>
<rubric>8</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Доля supply-chain-атак выросла на 15% за полгода]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235393]]></link>
<description><![CDATA[По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО среди значимых облачных инцидентов выросла на 15 процентных пунктов — с 10% до 25%. За полгода доля выросла в 2,5 раза, при этом абсолютное число значимых инцидентов, связанных с цепочками поставок, более чем удвоилось. Рост связан с тем, что современная разработка опирается на большое число внешних компонентов и автоматизированных процессов, которым компания вынуждена доверять. Даже относительно небольшой корпоративный продукт зависит от внешних библиотек, пакетов, расширений среды разработки, систем сборки и репозиториев. Каждый такой компонент связан с учетными записями сопровождающих, токенами доступа и автоматизированными процессами публикации. Компрометация одного аккаунта сопровождающего, токена публикации или элемента CI/CD может дать злоумышленнику штатный канал доставки вредоносного кода в корпоративную сборку. Вредоносный пакет устанавливается штатным менеджером зависимостей, измененный компонент попадает в сборку, а похищенный токен используется в легитимном CI/CD-процессе. Для средств сетевого контроля установка пакета, обращение CI/CD к репозиторию или публикация артефакта часто выглядят как обычная работа команды разработки. В первой половине 2026 года подобные кампании затрагивали сразу несколько экосистем, включая npm, PyPI, Composer, расширения Visual Studio Code, плагины Jenkins и AUR. В одном из эпизодов компрометация единственной учетной записи разработчика позволила внедрить вредоносные изменения более чем в 140 пакетов. В других случаях атакующие получали контроль над аккаунтами сопровождающих и публиковали измененные версии сразу сотен компонентов. Масштаб такой операции зависит от числа организаций, которые автоматически получают обновления скомпрометированного проекта через привычный процесс установки зависимостей. Отдельную роль играет кража секретов разработчиков. Вредоносный пакет может использоваться как средство первоначального доступа, после чего атакующие извлекают персональные токены GitHub, ключи облачных платформ, учетные данные реестров пакетов или переменные окружения из систем сборки. Эти данные могут открыть доступ к следующему уровню инфраструктуры: приватным репозиториям, облачным ресурсам, контейнерным реестрам или системам сборки. В исследованных кампаниях украденные токены применялись повторно через несколько недель после первоначальной компрометации, причем часть такой активности, по оценкам исследователей, могла относиться уже к другим группам. В одном из эпизодов злоумышленники заявляли о доступе примерно к четырем тысячам частных репозиториев. Такой сценарий требует не только удалить вредоносный пакет, но и отозвать или заменить учетные данные, которые могли быть похищены во время его выполнения. Структура атак через цепочки поставок в 2026 году складывается из нескольких связанных сценариев. Первый строится вокруг компрометации открытого пакета или аккаунта его сопровождающего. Второй затрагивает CI/CD и позволяет менять сборки, кэши либо workflow без прямого доступа к конечному приложению. Еще один распространенный путь проходит через учетные данные разработчиков, когда первоначальное заражение используется для перехода в облачную инфраструктуру или внутренние репозитории. Отдельно развиваются атаки через плагины и расширения инструментов разработки. Такие инструменты особенно ценны для злоумышленника, если они имеют доступ к секретам, сборке или корпоративным сервисам. Расширение IDE работает внутри среды, где разработчик уже авторизован в корпоративных сервисах, а Jenkins-плагин или компонент сборочного конвейера может взаимодействовать с инфраструктурой от имени сервисной учетной записи. В результате граница между компрометацией поставщика и атакой на конечную компанию становится менее очевидной. Организация может не иметь уязвимого публичного сервиса и при этом получить вредоносный код через обновление зависимости. Другой сценарий начинается за пределами ее инфраструктуры, когда атакующий похищает токен сотрудника у разработчика стороннего продукта, а затем использует этот доступ уже против облачных ресурсов клиента. Для бизнеса последствия такого проникновения выходят за рамки заражения отдельной рабочей станции. При наличии широких прав у сервисных аккаунтов атакующий получает возможность читать секреты, менять содержимое репозиториев, воздействовать на процессы сборки и переходить к другим облачным проектам. При оценке отраслевого распределения инцидентов, связанных с цепочками поставок, наиболее высокая доля приходится на технологические компании и разработчиков ПО — около 34% случаев. Финансовый сектор формирует еще 21%, интернет-ритейл и другие цифровые торговые площадки — 16%, промышленность — 14%, компании из сферы профессиональных и корпоративных услуг — около 9%. На остальные отрасли приходится порядка 6%. Такая структура связана прежде всего с интенсивностью использования сторонних компонентов. У технологических компаний больше открытых зависимостей, репозиториев и автоматизированных сборочных процессов, финансовые организации активно используют внешние программные продукты и интеграции, а в ритейле и промышленности риск дополнительно расширяют многочисленные подрядчики, облачные сервисы и специализированное ПО. В этих условиях компрометация одного поставщика может затронуть сразу несколько организаций, которые используют общий пакет, плагин или компонент сборочной инфраструктуры. Риск усиливается, когда управление зависимостями отделено от управления доступом и секретами. Команда может проверять уязвимости библиотек, но не отслеживать, кому разрешена их публикация и какие права имеет CI/CD после установки нового компонента. В другой организации защищен репозиторий исходного кода, однако сервисный токен сборочной системы имеет административные полномочия в облаке. Именно через такие связи атака выходит за пределы исходной точки: один похищенный секрет может дать доступ к следующему сервису, а затем — к другим учетным данным и системам. Один похищенный секрет превращается в доступ к следующему сервису, а оттуда к другим учетным данным и системам. Для снижения риска компаниям следует контролировать всю цепочку доверия от исходного кода и зависимостей до CI/CD и развертывания в продуктивной среде. Новые зависимости имеет смысл проверять до включения в сборку, а недавно опубликованные версии не устанавливать автоматически без дополнительной верификации. Для критичных проектов оправдан период задержки перед использованием новой версии пакета, поскольку часть вредоносных публикаций удаляется вскоре после обнаружения. Доступ CI/CD следует ограничивать минимально необходимыми действиями, долгоживущие токены заменять короткоживущими учетными данными, а секреты разработчиков регулярно проверять на утечки и аномальное применение. Отдельного контроля требуют изменения владельцев пакетов, публикация новых версий, отключение защиты веток и действия сервисных аккаунтов за пределами обычного профиля. Практический приоритет — ограничить последствия компрометации одного элемента цепочки. Организация должна исходить из того, что популярная зависимость, аккаунт сопровождающего или токен разработчика могут быть скомпрометированы, и заранее ограничивать их возможности. Чем меньше полномочий получает такой компонент после попадания внутрь процесса разработки, тем ниже вероятность того, что одна вредоносная публикация даст атакующему доступ сразу к репозиториям, облачным ресурсам и корпоративным данным]]></description>
<source><![CDATA[&lltt;p&ggtt;По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО среди значимых облачных инцидентов выросла на 15 процентных пунктов — с 10% до 25%. За полгода доля выросла в 2,5 раза, при этом абсолютное число значимых инцидентов, связанных с цепочками поставок, более чем удвоилось.&lltt;/p&ggtt;
&lltt;p&ggtt;Рост связан с тем, что современная разработка опирается на большое число внешних компонентов и автоматизированных процессов, которым компания вынуждена доверять. Даже относительно небольшой корпоративный продукт зависит от внешних библиотек, пакетов, расширений среды разработки, систем сборки и репозиториев. Каждый такой компонент связан с учетными записями сопровождающих, токенами доступа и автоматизированными процессами публикации. Компрометация одного аккаунта сопровождающего, токена публикации или элемента CI/CD может дать злоумышленнику штатный канал доставки вредоносного кода в корпоративную сборку. Вредоносный пакет устанавливается штатным менеджером зависимостей, измененный компонент попадает в сборку, а похищенный токен используется в легитимном CI/CD-процессе. Для средств сетевого контроля установка пакета, обращение CI/CD к репозиторию или публикация артефакта часто выглядят как обычная работа команды разработки.&lltt;/p&ggtt;
&lltt;p&ggtt;В первой половине 2026 года подобные кампании затрагивали сразу несколько экосистем, включая npm, PyPI, Composer, расширения Visual Studio Code, плагины Jenkins и AUR. В одном из эпизодов компрометация единственной учетной записи разработчика позволила внедрить вредоносные изменения более чем в 140 пакетов. В других случаях атакующие получали контроль над аккаунтами сопровождающих и публиковали измененные версии сразу сотен компонентов. Масштаб такой операции зависит от числа организаций, которые автоматически получают обновления скомпрометированного проекта через привычный процесс установки зависимостей.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельную роль играет кража секретов разработчиков. Вредоносный пакет может использоваться как средство первоначального доступа, после чего атакующие извлекают персональные токены GitHub, ключи облачных платформ, учетные данные реестров пакетов или переменные окружения из систем сборки. Эти данные могут открыть доступ к следующему уровню инфраструктуры: приватным репозиториям, облачным ресурсам, контейнерным реестрам или системам сборки. В исследованных кампаниях украденные токены применялись повторно через несколько недель после первоначальной компрометации, причем часть такой активности, по оценкам исследователей, могла относиться уже к другим группам. В одном из эпизодов злоумышленники заявляли о доступе примерно к четырем тысячам частных репозиториев. Такой сценарий требует не только удалить вредоносный пакет, но и отозвать или заменить учетные данные, которые могли быть похищены во время его выполнения.&lltt;/p&ggtt;
&lltt;p&ggtt;Структура атак через цепочки поставок в 2026 году складывается из нескольких связанных сценариев. Первый строится вокруг компрометации открытого пакета или аккаунта его сопровождающего. Второй затрагивает CI/CD и позволяет менять сборки, кэши либо workflow без прямого доступа к конечному приложению. Еще один распространенный путь проходит через учетные данные разработчиков, когда первоначальное заражение используется для перехода в облачную инфраструктуру или внутренние репозитории. Отдельно развиваются атаки через плагины и расширения инструментов разработки. Такие инструменты особенно ценны для злоумышленника, если они имеют доступ к секретам, сборке или корпоративным сервисам. Расширение IDE работает внутри среды, где разработчик уже авторизован в корпоративных сервисах, а Jenkins-плагин или компонент сборочного конвейера может взаимодействовать с инфраструктурой от имени сервисной учетной записи.&lltt;/p&ggtt;
&lltt;p&ggtt;В результате граница между компрометацией поставщика и атакой на конечную компанию становится менее очевидной. Организация может не иметь уязвимого публичного сервиса и при этом получить вредоносный код через обновление зависимости. Другой сценарий начинается за пределами ее инфраструктуры, когда атакующий похищает токен сотрудника у разработчика стороннего продукта, а затем использует этот доступ уже против облачных ресурсов клиента. Для бизнеса последствия такого проникновения выходят за рамки заражения отдельной рабочей станции. При наличии широких прав у сервисных аккаунтов атакующий получает возможность читать секреты, менять содержимое репозиториев, воздействовать на процессы сборки и переходить к другим облачным проектам.&lltt;/p&ggtt;
&lltt;p&ggtt;При оценке отраслевого распределения инцидентов, связанных с цепочками поставок, наиболее высокая доля приходится на технологические компании и разработчиков ПО — около 34% случаев. Финансовый сектор формирует еще 21%, интернет-ритейл и другие цифровые торговые площадки — 16%, промышленность — 14%, компании из сферы профессиональных и корпоративных услуг — около 9%. На остальные отрасли приходится порядка 6%. Такая структура связана прежде всего с интенсивностью использования сторонних компонентов. У технологических компаний больше открытых зависимостей, репозиториев и автоматизированных сборочных процессов, финансовые организации активно используют внешние программные продукты и интеграции, а в ритейле и промышленности риск дополнительно расширяют многочисленные подрядчики, облачные сервисы и специализированное ПО. В этих условиях компрометация одного поставщика может затронуть сразу несколько организаций, которые используют общий пакет, плагин или компонент сборочной инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Риск усиливается, когда управление зависимостями отделено от управления доступом и секретами. Команда может проверять уязвимости библиотек, но не отслеживать, кому разрешена их публикация и какие права имеет CI/CD после установки нового компонента. В другой организации защищен репозиторий исходного кода, однако сервисный токен сборочной системы имеет административные полномочия в облаке. Именно через такие связи атака выходит за пределы исходной точки: один похищенный секрет может дать доступ к следующему сервису, а затем — к другим учетным данным и системам. Один похищенный секрет превращается в доступ к следующему сервису, а оттуда к другим учетным данным и системам.&lltt;/p&ggtt;
&lltt;p&ggtt;Для снижения риска компаниям следует контролировать всю цепочку доверия от исходного кода и зависимостей до CI/CD и развертывания в продуктивной среде. Новые зависимости имеет смысл проверять до включения в сборку, а недавно опубликованные версии не устанавливать автоматически без дополнительной верификации. Для критичных проектов оправдан период задержки перед использованием новой версии пакета, поскольку часть вредоносных публикаций удаляется вскоре после обнаружения. Доступ CI/CD следует ограничивать минимально необходимыми действиями, долгоживущие токены заменять короткоживущими учетными данными, а секреты разработчиков регулярно проверять на утечки и аномальное применение. Отдельного контроля требуют изменения владельцев пакетов, публикация новых версий, отключение защиты веток и действия сервисных аккаунтов за пределами обычного профиля.&lltt;/p&ggtt;
&lltt;p&ggtt;Практический приоритет — ограничить последствия компрометации одного элемента цепочки. Организация должна исходить из того, что популярная зависимость, аккаунт сопровождающего или токен разработчика могут быть скомпрометированы, и заранее ограничивать их возможности. Чем меньше полномочий получает такой компонент после попадания внутрь процесса разработки, тем ниже вероятность того, что одна вредоносная публикация даст атакующему доступ сразу к репозиториям, облачным ресурсам и корпоративным данным.&lltt;/p&ggtt;]]></source>
<adate>24.08.2026</adate>
<dbid>235393</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Вышел Space VDI 6.2.0 с расширенными возможностями администрирования VDI-среды]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235392]]></link>
<description><![CDATA[Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для корпоративной инфраструктуры. Ключевыми направлениями развития релиза стали разграничения прав доступа администраторов, совместимость со SpaceVM 7, а также совершенствование инструментов администрирования, поддержки многоуровневой PKI и сценариев управления VDI-средой. В состав релиза вошли Space Dispatcher 6.2.0, Space Gateway 1.8.1, Space Client 3.8.1 для Linux и Space Client 3.8.2 для Windows. Space VDI 6.2.0 совместима с платформами виртуализации SpaceVM 6.5.9 и SpaceVM 7.0.2. В Space VDI 6.2.0 реализована балансировка пользовательских подключений в мультишлюзе Space Gateway. Решение позволяет объединить несколько шлюзов в единый контур удалённого доступа и распределять нагрузку между ними при подключении пользователей. Мультишлюз Space Gateway предназначен для инфраструктур с большим числом удалённых пользователей. Балансировка подключений между шлюзами помогает масштабировать контур удалённого доступа и эффективнее использовать вычислительные и сетевые ресурсы. Space Dispatcher — управляющий компонент платформы получил существенное развитие в новом релизе Space VDI. В версии 6.2.0 реализована поддержка многоуровневой инфраструктуры открытых ключей, а инструменты работы с сертификатами получили дальнейшее развитие в интерфейсе и административных сценариях платформы. Это расширяет возможности интеграции Space VDI с корпоративной PKI и делает управление сертификатами более удобным в рамках единого контура администрирования. В новой версии также добавлены инструменты для разграничения прав доступа администраторов для управления на уровне пулов с помощью пользовательской роли «Модератор», развиты механизмы обновления компонентов, расширены административные сценарии и усовершенствована работа со службами каталогов, событиями и параметрами безопасности. В совокупности эти изменения повышают гибкость управления средой виртуальных рабочих мест и делают эксплуатацию платформы более предсказуемой в инфраструктурах с высокими требованиями к надёжности и управляемости. Отдельное внимание в релизе уделено развитию сценариев предоставления корпоративных приложений. В документации Space VDI появился новый раздел с рекомендациями по работе с пулами приложений, которые позволяют предоставлять пользователям доступ к отдельным приложениям без развёртывания полноценного виртуального рабочего стола. Такой подход помогает точнее настраивать пользовательские сценарии и более гибко организовывать доступ к прикладным системам. «Space VDI изначально создавалась как отечественная платформа с собственной технологической базой и глубокой интеграцией компонентов экосистемы Space. Такой подход позволяет нам обеспечивать предсказуемое развитие продукта, стабильную совместимость между компонентами и долгосрочную поддержку заказчиков в проектах импортозамещения. Мы видим высокий спрос на VDI со стороны коммерческих компаний и государственных организаций, поэтому продолжаем последовательно развивать инструменты администрирования и безопасности платформы. Новые возможности Space VDI 6.2.0 помогают заказчикам проще масштабировать инфраструктуру виртуальных рабочих мест, сохраняя высокий уровень управляемости среды и удобство её эксплуатации», — отметил Руслан Белов, директор по продукту Space VDI компании «ДАКОМ М». Для заказчиков в открытой документации продукта подготовлены рекомендации по обновлению и миграции компонентов Space Dispatcher с учетом особенностей используемой инфраструктуры. При переходе на Space VDI 6.2.0 необходимо соблюдать матрицу совместимости компонентов экосистемы Space и выполнять обновление в рекомендованной последовательности]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для корпоративной инфраструктуры. Ключевыми направлениями развития релиза стали разграничения прав доступа администраторов, совместимость со SpaceVM 7, а также совершенствование инструментов администрирования, поддержки многоуровневой PKI и сценариев управления &lltt;nobr&ggtt;VDI-средой.&lltt;/nobr&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;В состав релиза вошли Space Dispatcher 6.2.0, Space Gateway 1.8.1, Space Client 3.8.1 для Linux и Space Client 3.8.2 для Windows. Space VDI 6.2.0 совместима с платформами виртуализации SpaceVM 6.5.9 и SpaceVM 7.0.2.&lltt;/p&ggtt;
&lltt;p&ggtt;В Space VDI 6.2.0 реализована балансировка пользовательских подключений в мультишлюзе Space Gateway. Решение позволяет объединить несколько шлюзов в единый контур удалённого доступа и распределять нагрузку между ними при подключении пользователей.&lltt;/p&ggtt;
&lltt;p&ggtt;Мультишлюз Space Gateway предназначен для инфраструктур с большим числом удалённых пользователей. Балансировка подключений между шлюзами помогает масштабировать контур удалённого доступа и эффективнее использовать вычислительные и сетевые ресурсы.&lltt;/p&ggtt;
&lltt;p&ggtt;Space Dispatcher — управляющий компонент платформы получил существенное развитие в новом релизе Space VDI. В версии 6.2.0 реализована поддержка многоуровневой инфраструктуры открытых ключей, а инструменты работы с сертификатами получили дальнейшее развитие в интерфейсе и административных сценариях платформы. Это расширяет возможности интеграции Space VDI с корпоративной PKI и делает управление сертификатами более удобным в рамках единого контура администрирования.&lltt;/p&ggtt;
&lltt;p&ggtt;В новой версии также добавлены инструменты для разграничения прав доступа администраторов для управления на уровне пулов с помощью пользовательской роли «Модератор», развиты механизмы обновления компонентов, расширены административные сценарии и усовершенствована работа со службами каталогов, событиями и параметрами безопасности. В совокупности эти изменения повышают гибкость управления средой виртуальных рабочих мест и делают эксплуатацию платформы более предсказуемой в инфраструктурах с высокими требованиями к надёжности и управляемости.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельное внимание в релизе уделено развитию сценариев предоставления корпоративных приложений. В документации Space VDI появился новый раздел с рекомендациями по работе с пулами приложений, которые позволяют предоставлять пользователям доступ к отдельным приложениям без развёртывания полноценного виртуального рабочего стола. Такой подход помогает точнее настраивать пользовательские сценарии и более гибко организовывать доступ к прикладным системам.&lltt;/p&ggtt;
&lltt;p&ggtt;«Space VDI изначально создавалась как отечественная платформа с собственной технологической базой и глубокой интеграцией компонентов экосистемы Space. Такой подход позволяет нам обеспечивать предсказуемое развитие продукта, стабильную совместимость между компонентами и долгосрочную поддержку заказчиков в проектах импортозамещения. Мы видим высокий спрос на VDI со стороны коммерческих компаний и государственных организаций, поэтому продолжаем последовательно развивать инструменты администрирования и безопасности платформы. Новые возможности Space VDI 6.2.0 помогают заказчикам проще масштабировать инфраструктуру виртуальных рабочих мест, сохраняя высокий уровень управляемости среды и удобство её эксплуатации», — отметил Руслан Белов, директор по продукту Space VDI компании «ДАКОМ М». &lltt;/p&ggtt;
&lltt;p&ggtt;Для заказчиков в открытой документации продукта подготовлены рекомендации по обновлению и миграции компонентов Space Dispatcher с учетом особенностей используемой инфраструктуры. При переходе на Space VDI 6.2.0 необходимо соблюдать матрицу совместимости компонентов экосистемы Space и выполнять обновление в рекомендованной последовательности.&lltt;/p&ggtt;]]></source>
<adate>24.08.2026</adate>
<dbid>235392</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Сети/Серверы/СХД/ЦОД]]></tag>
</item>
<item>
<title><![CDATA[«Навикон» разработал ИИ-платформу NaviCortex для работы с корпоративными данными]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235391]]></link>
<description><![CDATA[Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет искать ответы в корпоративных документах, а также выполнять аналитические задачи. Платформа рассчитана в первую очередь на крупные и средние компании с повышенными требованиями к информационной безопасности и суверенитету данных. В крупных компаниях информация, необходимая для принятия решений, как правило распределена между разными источниками. Документы и регламенты хранятся в корпоративных порталах и СЭД, данные о клиентах — в CRM, финансовые показатели — в учетных системах, а часть информации остается в файлах и у отдельных экспертов. Чтобы получить аргументированный ответ на вопрос, сотрудникам приходится тратить время на длительный поиск, переключаться между системами, вручную сводить данные из разных систем. NaviCortex объединяет корпоративные источники в единое рабочее пространство и позволяет взаимодействовать с ними в едином интерфейсе. В отличие от классических систем интеллектуального поиска, которые работают по схеме «запрос — поиск по документам — ответ», новое решение «Навикон» построено на агентной архитектуре. Получив задачу, ИИ-агент самостоятельно разбивает ее на этапы, определяет необходимые источники, обращается к корпоративным системам, выполняет расчеты и проверяет результат. При сложных запросах отдельные части задачи могут передаваться специализированным агентам, а дополнительная проверка позволяет сверять числа, периоды и другие необходимые данные. Например, на вопрос о текущей задолженности клиента и возможности продолжать отгрузки платформа может одновременно получить сумму задолженности из ERP, проверить финансовую политику компании в базе знаний и уточнить статус клиента в CRM. В результате пользователь получает единый ответ, а не набор ссылок на три разные системы. По тому же принципу платформа сопоставляет показатели из разрозненных источников, готовит аналитические справки, проверяет требования регламентов или собирает информацию для управленческой отчетности. Платформа не только находит информацию и отвечает на вопросы, но и выполняет работу по запросу пользователя. Агент пишет и запускает код в изолированной песочнице, рассчитывает показатели, строит таблицы и графики — а результат формирует в виде готового документа, таблицы или презентации. Для загрузки собственных файлов и дальнейшей работы с ними пользователям доступно персональное защищенное пространство. NaviCortex можно интегрировать с ERP, CRM, WMS, СЭД, корпоративными порталами, базами данных и другими системами через API. Заказчики, в свою очередь, могут специализированных агентов для отдельных сотрудников, подразделений и сценариев без переработки всей системы. Отдельное внимание разрабочик уделил вопросам корпоративной безопасности. Платформа учитывает права конкретного пользователя при обращении к документам и информационным системам, контролирует входящие запросы и ответы, фиксирует действия в журнале аудита и изолирует пользовательские песочницы. Решение может быть развернуто внутри закрытого контура компании, работать по гибридной модели или размещаться в облаке российского провайдера. При локальном развертывании данные и генерацию ответов можно оставить в инфраструктуре заказчика. «Сейчас корпоративный ИИ часто сводится к чат-боту, который умеет искать информацию в базе документов. Но реальные вопросы бизнеса устроены сложнее: для ответа нужно взять данные из нескольких систем, сопоставить их с внутренними правилами, что-то рассчитать, проверить результат, а иногда — сразу подготовить документ. Именно под такие задачи мы создавали NaviCortex. Наша цель — дать сотруднику ИИ-инструмент, который понимает контекст бизнеса компании и способен самостоятельно пройти путь от вопроса до готового результата», — прокомментировал Илья Народицкий, директор по стратегическим инновациям компании «Навикон». Продукт оптимизирован для работы на русском языке и поддерживает модели с открытым исходным кодом, которые можно размещать в инфраструктуре заказчика. Клиент получает доступ к исходному коду платформы и может развивать и кастомизировать решение самостоятельно или с поддержкой «Навикон». Платформа подойдет компаниям с большим объемом внутренней информации и разветвленным ИТ-ландшафтом. В частности, организациям из регулируемых сфер — финсектора, фармацевтики, пищевой промышленности и ритейла]]></description>
<source><![CDATA[&lltt;p&ggtt;Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет искать ответы в корпоративных документах, а также выполнять аналитические задачи. Платформа рассчитана в первую очередь на крупные и средние компании с повышенными требованиями к информационной безопасности и суверенитету данных.&lltt;/p&ggtt;
&lltt;p&ggtt;В крупных компаниях информация, необходимая для принятия решений, как правило распределена между разными источниками. Документы и регламенты хранятся в корпоративных порталах и СЭД, данные о клиентах — в CRM, финансовые показатели — в учетных системах, а часть информации остается в файлах и у отдельных экспертов. &lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы получить аргументированный ответ на вопрос, сотрудникам приходится тратить время на длительный поиск, переключаться между системами, вручную сводить данные из разных систем. NaviCortex объединяет корпоративные источники в единое рабочее пространство и позволяет взаимодействовать с ними в едином интерфейсе.&lltt;/p&ggtt;
&lltt;p&ggtt;В отличие от классических систем интеллектуального поиска, которые работают по схеме «запрос — поиск по документам — ответ», новое решение «Навикон» построено на агентной архитектуре. Получив задачу, ИИ-агент самостоятельно разбивает ее на этапы, определяет необходимые источники, обращается к корпоративным системам, выполняет расчеты и проверяет результат. При сложных запросах отдельные части задачи могут передаваться специализированным агентам, а дополнительная проверка позволяет сверять числа, периоды и другие необходимые данные. &lltt;/p&ggtt;
&lltt;p&ggtt;Например, на вопрос о текущей задолженности клиента и возможности продолжать отгрузки платформа может одновременно получить сумму задолженности из ERP, проверить финансовую политику компании в базе знаний и уточнить статус клиента в CRM. В результате пользователь получает единый ответ, а не набор ссылок на три разные системы. По тому же принципу платформа сопоставляет показатели из разрозненных источников, готовит аналитические справки, проверяет требования регламентов или собирает информацию для управленческой отчетности.&lltt;/p&ggtt;
&lltt;p&ggtt;Платформа не только находит информацию и отвечает на вопросы, но и выполняет работу по запросу пользователя. Агент пишет и запускает код в изолированной песочнице, рассчитывает показатели, строит таблицы и графики — а результат формирует в виде готового документа, таблицы или презентации. Для загрузки собственных файлов и дальнейшей работы с ними пользователям доступно персональное защищенное пространство.&lltt;/p&ggtt;
&lltt;p&ggtt;NaviCortex можно интегрировать с ERP, CRM, WMS, СЭД, корпоративными порталами, базами данных и другими системами через API. Заказчики, в свою очередь, могут специализированных агентов для отдельных сотрудников, подразделений и сценариев без переработки всей системы.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельное внимание разрабочик уделил вопросам корпоративной безопасности. Платформа учитывает права конкретного пользователя при обращении к документам и информационным системам, контролирует входящие запросы и ответы, фиксирует действия в журнале аудита и изолирует пользовательские песочницы. Решение может быть развернуто внутри закрытого контура компании, работать по гибридной модели или размещаться в облаке российского провайдера. При локальном развертывании данные и генерацию ответов можно оставить в инфраструктуре заказчика.&lltt;/p&ggtt;
&lltt;p&ggtt;«Сейчас корпоративный ИИ часто сводится к чат-боту, который умеет искать информацию в базе документов. Но реальные вопросы бизнеса устроены сложнее: для ответа нужно взять данные из нескольких систем, сопоставить их с внутренними правилами, что-то рассчитать, проверить результат, а иногда — сразу подготовить документ. Именно под такие задачи мы создавали NaviCortex. Наша цель — дать сотруднику ИИ-инструмент, который понимает контекст бизнеса компании и способен самостоятельно пройти путь от вопроса до готового результата», — прокомментировал Илья Народицкий, директор по стратегическим инновациям компании «Навикон».&lltt;/p&ggtt;
&lltt;p&ggtt;Продукт оптимизирован для работы на русском языке и поддерживает модели с открытым исходным кодом, которые можно размещать в инфраструктуре заказчика. Клиент получает доступ к исходному коду платформы и может развивать и кастомизировать решение самостоятельно или с поддержкой «Навикон». &lltt;/p&ggtt;
&lltt;p&ggtt;Платформа подойдет компаниям с большим объемом внутренней информации и разветвленным ИТ-ландшафтом. В частности, организациям из регулируемых сфер — финсектора, фармацевтики, пищевой промышленности и ритейла.&lltt;/p&ggtt;]]></source>
<adate>24.08.2026</adate>
<dbid>235391</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Почему разработка ПО не выигрывает от ускорения кодирования]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235390]]></link>
<description><![CDATA[Инструменты кодирования с использованием искусственного интеллекта ускоряют работу отдельных специалистов, но большие запросы на слияние (pull requests, PR), слабые методы измерения и устаревшие процессы сдерживают производительность и уверенность инженеров, отмечают опрошенные порталом The New Stack эксперты. ИИ отлично справляется с тем, чтобы ускорить работу отдельных людей, но окружающие системы затем снова всё замедляют. Этот результат — или, скорее, его отсутствие — усиливается размером компании и размером PR. До такой степени, что, хотя инвестиции в ИИ в большинстве компаний увеличились в 28 раз, показатели скорости разработки остаются на прежнем уровне и даже снижаются. Таковы результаты недавно опубликованного исследования DX «State of AI Impact in Engineering», в котором оцениваются инженерные организации по таким параметрам, как скорость, эффективность, качество и влияние. «Это вызывает беспокойство, потому что, когда затраты выросли в 28 раз — и стали буквально единственным экспоненциально выросшим показателем — а скорость не растет экспоненциально, мы не выпускаем экспоненциально больше ПО», — сетует Джастин Реок, заместитель технического директора DX. В то время как расходы на ИИ продолжают стремительно расти, коэффициент инноваций — соотношение усилий инженеров, затрачиваемых на разработку новых функций, с затратами на техническое обслуживание, рутинную работу и операционные издержки — остается неизменным. Это означает, что, согласно отчету DX, ИИ не освобождает время инженеров для разработки интересных бизнес-решений. Почему же индустрия тратит так много денег на агентные и ​​ИИ-инструменты для разработчиков, одновременно проводя сокращения штата, и все это безрезультатно? Имеет ли место тенденция к ухудшению опыта разработчиков? «Возможно, мы все еще находимся в переломном моменте, когда большая часть сэкономленного времени по-прежнему тратится на технический долг, на задачи из бэклога, которые не обязательно помечены как новые функции», — говорит Реок, который все еще надеется, что разрыв между затратами и выгодами от ИИ — это всего лишь проблемы роста. «Но с точки зрения опыта разработчиков меня также беспокоит выявленное в отчете конкретное противоречие между поддерживаемостью кода и уверенностью в изменениях», — добавляет он. Эти два фактора составляют основу индекса опыта разработчиков (Developer Experience Index, DXI): 	 Поддерживаемость кода: я чувствую себя комфортно, внося изменения в код; я понимаю код, который передо мной. 	 Уверенность в изменениях: я уверен, что, выпустив код в продакшн, я ничего не сломаю. Традиционно, как объясняет Реок, поддерживаемость кода и уверенность в изменениях положительно коррелируют, поскольку первая делает инженеров более уверенными в выпуске кода в продакшн. «ИИ упрощает понимание того, что перед вами, и даже внесение в это изменений. Но уверенность в изменениях сейчас находится в отрицательной зоне, — говорит он. — Мы стали больше бояться выпускать код. Мы можем легче понимать, поддерживать, просматривать код и вносить в него изменения. Но мы меньше доверяем тому, что выпускаем». Это обходится еще дороже. По словам Реока, за каждый пункт улучшения DXI приходится платить десятью часами работы каждого инженера в год. Это впервые, когда в масштабах всей отрасли наблюдается снижение этого показателя на два пункта. Является ли ИИ неподходящим инструментом для крупных организаций? Как показывает исследование DX, небольшие организации тратят больше средств на ИИ и получают от него больше пользы, в то время как традиционные софтверные компании с трудом получают какую-либо отдачу от инвестиций. Мартин Дэвидсон, технический директор микроконсалтинговой компании a2bic.ai, и его соучредитель, обладающие в общей сложности 80-летним опытом, доводят ситуацию до крайности: они могут управлять командами ИИ-агентов, выполняющих работу 100 инженеров начального и среднего уровня. «Небольшим организациям не приходится платить издержки нелинейной координации и коммуникации, которые увеличиваются с ростом размера организации. Вспомните мифический человеко-месяц: каналы связи растут как n(n−1)/2, поэтому у команды из 10 человек 45 каналов накладных расходов, — объясняет Дэвидсон. — Трое из этих людей фактически нужны только для согласования действий. Но как только остаётся один или два человека, затраты на коммуникации исчезают. По мере сокращения среднего звена управления отпадает необходимость в ежемесячных общих собраниях на всех уровнях организации». По его словам, в средних и крупных организациях пытаются внедрить — или «впихнуть» — ИИ в существующие системы, охватывающие людей, процессы и технологии. Но ИИ — это фундаментальный технологический и операционный сдвиг парадигмы. Это то, что он называет проблемой обновления, когда некоторые из этих структур больше не соответствуют своему назначению. «Это нельзя переделать. У нас есть процессы и структуры, которые были разработаны, когда написание кода было дорогостоящим делом. Сейчас это уже не так — написание кода по сути бесплатно, но мы всё ещё цепляемся за старые структуры. А они недешевы, — продолжает Дэвидсон. — Структуры компании похожи на здания — в какой-то момент вы понимаете, что они больше не соответствуют своему назначению, и их нужно снести и выстроить заново». Конечно, это не новая проблема. Это та же самая логика, которая удерживала подавляющее большинство предприятий от полного перехода в облако. «Возможно, победителями станут не те компании, которые успешно трансформируются. Возможно, победителями станут те, кто начнет все с чистого листа, без каких-либо ограничений. Это трудно сделать, если вы работаете в устаревшей организации. И, вероятно, еще более трудно, если вы ею управляете», — отмечает Дэвисон. К счастью, ИИ очень хорошо распознает закономерности, что делает его очень полезным для разгадывания тайн унаследованных систем, их миграции в облако и переписывания. ИИ усугубляет разрастание кода Конечно, многие команды и их промпты игнорируют общепринятые шаблоны достижения успеха, в том числе тот факт, что уменьшение размера пакета способствует более стабильным релизам. В отчете DX говорится, что в июле 2025 г. средний размер PR составлял 42 строки кода, а годом позже — 72 строки. Кроме того, из всех показателей DXI, измеренных за последний квартал, больше всего пострадал показатель поэтапной разработки — когда инженеры работают над небольшими, поэтапными изменениями. «Такая разработка дает множество преимуществ в дальнейшем: откат изменений, меньше проверок, более понятная документация, улучшенные модульные тесты и так далее», — отмечает Реок. Не только DX выявляет эти тревожные тенденции. В новом отчете LinearB о разрыве в производительности ИИ-разработки 253 организации ранжированы по использованию ИИ на четыре категории. Исследование показывает, что меньший размер PR напрямую связан с более успешным внедрением ИИ. У «элитных организаций», входящих в 10% лучших, средний размер PR — менее 100 строк кода, в то время как у организаций из нижней части списка — им «недостает фокуса» — PR составляют более 228 строк кода. Можно ли улучшить то, что не измеряется? Исследования DX и LinearB по измерению количественного и качественного опыта разработчиков основаны на собственных данных, полученных от организаций, использующих их продукты, поэтому ни один из этих результатов не отражает полной картины. На самом деле, ситуация в остальной части отрасли может быть гораздо хуже. Согласно отчету LeadDev «AI Impact Report 2026», только 31% опрошенных команд вообще измеряют влияние ИИ. Исследователи определили эти измерения следующим образом: 	 реальное повышение производительности; 	 риск безопасности; 	 сохранение основных инженерных навыков; 	 управление агентным ИИ; 	 реструктуризация команды; 	 наем и обучение младших специалистов. Среди организаций, которые фактически начали внедрять инструменты для разработчиков на основе ИИ, согласно отчету LeadDev, 70% теперь описывают себя как внедрившие их «широко или полностью», и только 26% сообщают, что ИИ повысил производительность инженеров более чем на 25%. Эти 26%, как уточняет Майкл Хилл, управляющий редактор LeadDev и автор отчета, включают в себя респондентов, полагающихся на интуицию, а не только на подтвержденные данные. «Оптимизм в отношении производительности (26% отмечают значительный рост) и разрыв в измерениях (только 31% фактически отслеживает его) — это два отдельных результата, полученные на основе ответов на два разных вопроса», — отмечает он, а это значит, что «большинство людей, сообщающих о росте, не могут это доказать». Как известно, нельзя улучшить то, что не измеряешь. Но даже у тех, кто проводит измерения, результаты вызывают беспокойство]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Инструменты кодирования с&nbsp;использованием искусственного интеллекта ускоряют работу отдельных специалистов, но&nbsp;большие запросы на&nbsp;слияние (pull requests, &lltt;/em&ggtt;&lltt;em&ggtt;PR&lltt;/em&ggtt;&lltt;em&ggtt;), слабые методы измерения и&nbsp;устаревшие процессы сдерживают производительность и&nbsp;уверенность инженеров, отмечают опрошенные порталом &lltt;/em&ggtt;&lltt;em&ggtt;The&lltt;/em&ggtt; &lltt;em&ggtt;New&lltt;/em&ggtt; &lltt;em&ggtt;Stack&lltt;/em&ggtt; &lltt;em&ggtt;эксперты.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ&nbsp;отлично справляется с&nbsp;тем, чтобы ускорить работу отдельных людей, но&nbsp;окружающие системы затем снова всё замедляют. Этот результат&nbsp;— или, скорее, его отсутствие&nbsp;— усиливается размером компании и&nbsp;размером PR. До&nbsp;такой степени, что, хотя инвестиции в&nbsp;ИИ в&nbsp;большинстве компаний увеличились в&nbsp;28&nbsp;раз, показатели скорости разработки остаются на&nbsp;прежнем уровне и&nbsp;даже снижаются. Таковы результаты недавно опубликованного исследования DX&nbsp;«State of&nbsp;AI&nbsp;Impact in&nbsp;Engineering», в&nbsp;котором оцениваются инженерные организации по&nbsp;таким параметрам, как скорость, эффективность, качество и&nbsp;влияние.&lltt;/p&ggtt;
&lltt;p&ggtt;«Это вызывает беспокойство, потому что, когда затраты выросли в&nbsp;28&nbsp;раз&nbsp;— и&nbsp;стали буквально единственным экспоненциально выросшим показателем&nbsp;— а&nbsp;скорость не&nbsp;растет экспоненциально, мы&nbsp;не&nbsp;выпускаем экспоненциально больше ПО»,&nbsp;— сетует Джастин Реок, заместитель технического директора DX.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;то&nbsp;время как расходы на&nbsp;ИИ продолжают стремительно расти, коэффициент инноваций&nbsp;— соотношение усилий инженеров, затрачиваемых на&nbsp;разработку новых функций, с&nbsp;затратами на&nbsp;техническое обслуживание, рутинную работу и&nbsp;операционные издержки&nbsp;— остается неизменным. Это означает, что, согласно отчету DX, ИИ&nbsp;не&nbsp;освобождает время инженеров для разработки интересных бизнес-решений.&lltt;/p&ggtt;
&lltt;p&ggtt;Почему&nbsp;же индустрия тратит так много денег на&nbsp;агентные и ​​ИИ-инструменты для разработчиков, одновременно проводя сокращения штата, и&nbsp;все это безрезультатно?&lltt;/p&ggtt;
&lltt;h3&ggtt;Имеет&nbsp;ли место тенденция к&nbsp;ухудшению опыта разработчиков?&lltt;/h3&ggtt;
&lltt;p&ggtt;«Возможно, мы&nbsp;все еще находимся в&nbsp;переломном моменте, когда большая часть сэкономленного времени по-прежнему тратится на&nbsp;технический долг, на&nbsp;задачи из&nbsp;бэклога, которые не&nbsp;обязательно помечены как новые функции»,&nbsp;— говорит Реок, который все еще надеется, что разрыв между затратами и&nbsp;выгодами от&nbsp;ИИ&nbsp;— это всего лишь проблемы роста. «Но&nbsp;с&nbsp;точки зрения опыта разработчиков меня также беспокоит выявленное в&nbsp;отчете конкретное противоречие между поддерживаемостью кода и&nbsp;уверенностью в&nbsp;изменениях»,&nbsp;— добавляет&nbsp;он.&lltt;/p&ggtt;
&lltt;p&ggtt;Эти два фактора составляют основу индекса опыта разработчиков (Developer Experience Index, DXI):&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt; Поддерживаемость кода:&lltt;/strong&ggtt; я&nbsp;чувствую себя комфортно, внося изменения в&nbsp;код; я&nbsp;понимаю код, который передо мной.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Уверенность в&nbsp;изменениях:&lltt;/strong&ggtt; я&nbsp;уверен, что, выпустив код в&nbsp;продакшн, я&nbsp;ничего не&nbsp;сломаю.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Традиционно, как объясняет Реок, поддерживаемость кода и&nbsp;уверенность в&nbsp;изменениях положительно коррелируют, поскольку первая делает инженеров более уверенными в&nbsp;выпуске кода в&nbsp;продакшн. «ИИ&nbsp;упрощает понимание того, что перед вами, и&nbsp;даже внесение в&nbsp;это изменений. Но&nbsp;уверенность в&nbsp;изменениях сейчас находится в&nbsp;отрицательной зоне,&nbsp;— говорит&nbsp;он. —&nbsp;Мы&nbsp;стали больше бояться выпускать код. Мы&nbsp;можем легче понимать, поддерживать, просматривать код и&nbsp;вносить в&nbsp;него изменения. Но&nbsp;мы&nbsp;меньше доверяем тому, что выпускаем».&lltt;/p&ggtt;
&lltt;p&ggtt;Это обходится еще дороже. По&nbsp;словам Реока, за&nbsp;каждый пункт улучшения DXI приходится платить десятью часами работы каждого инженера в&nbsp;год. Это впервые, когда в&nbsp;масштабах всей отрасли наблюдается снижение этого показателя на&nbsp;два пункта.&lltt;/p&ggtt;
&lltt;h3&ggtt;Является&nbsp;ли ИИ&nbsp;неподходящим инструментом для крупных организаций?&lltt;/h3&ggtt;
&lltt;p&ggtt;Как показывает исследование&nbsp;DX, небольшие организации тратят больше средств на&nbsp;ИИ и&nbsp;получают от&nbsp;него больше пользы, в&nbsp;то&nbsp;время как традиционные софтверные компании с&nbsp;трудом получают какую-либо отдачу от&nbsp;инвестиций.&lltt;/p&ggtt;
&lltt;p&ggtt;Мартин Дэвидсон, технический директор микроконсалтинговой компании a2bic.ai, и&nbsp;его соучредитель, обладающие в&nbsp;общей сложности &lltt;nobr&ggtt;80-летним&lltt;/nobr&ggtt; опытом, доводят ситуацию до&nbsp;крайности: они могут управлять командами ИИ-агентов, выполняющих работу 100 инженеров начального и&nbsp;среднего уровня. «Небольшим организациям не&nbsp;приходится платить издержки нелинейной координации и&nbsp;коммуникации, которые увеличиваются с&nbsp;ростом размера организации. Вспомните мифический человеко-месяц: каналы связи растут как n(n−1)/2, поэтому у&nbsp;команды из&nbsp;10&nbsp;человек 45&nbsp;каналов накладных расходов,&nbsp;— объясняет Дэвидсон. —&nbsp;Трое из&nbsp;этих людей фактически нужны только для согласования действий. Но&nbsp;как только остаётся один или два человека, затраты на&nbsp;коммуникации исчезают. По&nbsp;мере сокращения среднего звена управления отпадает необходимость в&nbsp;ежемесячных общих собраниях на&nbsp;всех уровнях организации».&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;его словам, в&nbsp;средних и&nbsp;крупных организациях пытаются внедрить&nbsp;— или «впихнуть»&nbsp;— ИИ&nbsp;в&nbsp;существующие системы, охватывающие людей, процессы и&nbsp;технологии. Но&nbsp;ИИ&nbsp;— это фундаментальный технологический и&nbsp;операционный сдвиг парадигмы. Это&nbsp;то, что он&nbsp;называет проблемой обновления, когда некоторые из&nbsp;этих структур больше не&nbsp;соответствуют своему назначению.&lltt;/p&ggtt;
&lltt;p&ggtt;«Это нельзя переделать. У&nbsp;нас есть процессы и&nbsp;структуры, которые были разработаны, когда написание кода было дорогостоящим делом. Сейчас это уже не&nbsp;так&nbsp;— написание кода по&nbsp;сути бесплатно, но&nbsp;мы&nbsp;всё ещё цепляемся за&nbsp;старые структуры. А&nbsp;они недешевы,&nbsp;— продолжает Дэвидсон. —&nbsp;Структуры компании похожи на&nbsp;здания&nbsp;— в&nbsp;какой-то момент вы&nbsp;понимаете, что они больше не&nbsp;соответствуют своему назначению, и&nbsp;их&nbsp;нужно снести и&nbsp;выстроить заново».&lltt;/p&ggtt;
&lltt;p&ggtt;Конечно, это не&nbsp;новая проблема. Это та&nbsp;же самая логика, которая удерживала подавляющее большинство предприятий от&nbsp;полного перехода в&nbsp;облако.&lltt;/p&ggtt;
&lltt;p&ggtt;«Возможно, победителями станут не&nbsp;те&nbsp;компании, которые успешно трансформируются. Возможно, победителями станут&nbsp;те, кто начнет все с&nbsp;чистого листа, без каких-либо ограничений. Это трудно сделать, если вы&nbsp;работаете в&nbsp;устаревшей организации. И, вероятно, еще более трудно, если вы&nbsp;ею&nbsp;управляете»,&nbsp;— отмечает Дэвисон.&lltt;/p&ggtt;
&lltt;p&ggtt;К&nbsp;счастью, ИИ&nbsp;очень хорошо распознает закономерности, что делает его очень полезным для разгадывания тайн унаследованных систем, их&nbsp;миграции в&nbsp;облако и&nbsp;переписывания.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ&nbsp;усугубляет разрастание кода&lltt;/h3&ggtt;
&lltt;p&ggtt;Конечно, многие команды и&nbsp;их&nbsp;промпты игнорируют общепринятые шаблоны достижения успеха, в&nbsp;том числе тот факт, что уменьшение размера пакета способствует более стабильным релизам. В&nbsp;отчете DX&nbsp;говорится, что в&nbsp;июле 2025&nbsp;г. средний размер&nbsp;PR составлял 42&nbsp;строки кода, а&nbsp;годом позже&nbsp;— 72&nbsp;строки.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме того, из&nbsp;всех показателей DXI, измеренных за&nbsp;последний квартал, больше всего пострадал показатель поэтапной разработки&nbsp;— когда инженеры работают над небольшими, поэтапными изменениями. «Такая разработка дает множество преимуществ в&nbsp;дальнейшем: откат изменений, меньше проверок, более понятная документация, улучшенные модульные тесты и&nbsp;так далее»,&nbsp;— отмечает Реок.&lltt;/p&ggtt;
&lltt;p&ggtt;Не&nbsp;только&nbsp;DX выявляет эти тревожные тенденции. В&nbsp;новом отчете LinearB о&nbsp;разрыве в&nbsp;производительности ИИ-разработки 253 организации ранжированы по&nbsp;использованию&nbsp;ИИ на&nbsp;четыре категории. Исследование показывает, что меньший размер&nbsp;PR напрямую связан с&nbsp;более успешным внедрением ИИ. У&nbsp;«элитных организаций», входящих в&nbsp;10% лучших, средний размер PR&nbsp;— менее 100 строк кода, в&nbsp;то&nbsp;время как у&nbsp;организаций из&nbsp;нижней части списка&nbsp;— им&nbsp;«недостает фокуса»&nbsp;— PR&nbsp;составляют более 228 строк кода.&lltt;/p&ggtt;
&lltt;h3&ggtt;Можно&nbsp;ли улучшить&nbsp;то, что не&nbsp;измеряется?&lltt;/h3&ggtt;
&lltt;p&ggtt;Исследования DX&nbsp;и&nbsp;LinearB по&nbsp;измерению количественного и&nbsp;качественного опыта разработчиков основаны на&nbsp;собственных данных, полученных от&nbsp;организаций, использующих их&nbsp;продукты, поэтому ни&nbsp;один из&nbsp;этих результатов не&nbsp;отражает полной картины. На&nbsp;самом деле, ситуация в&nbsp;остальной части отрасли может быть гораздо хуже.&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно отчету LeadDev «AI&nbsp;Impact Report 2026», только&nbsp;31% опрошенных команд вообще измеряют влияние ИИ. Исследователи определили эти измерения следующим образом:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; реальное повышение производительности;&lltt;/li&ggtt;
	&lltt;li&ggtt; риск безопасности;&lltt;/li&ggtt;
	&lltt;li&ggtt; сохранение основных инженерных навыков;&lltt;/li&ggtt;
	&lltt;li&ggtt; управление агентным ИИ;&lltt;/li&ggtt;
	&lltt;li&ggtt; реструктуризация команды;&lltt;/li&ggtt;
	&lltt;li&ggtt; наем и&nbsp;обучение младших специалистов.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Среди организаций, которые фактически начали внедрять инструменты для разработчиков на&nbsp;основе&nbsp;ИИ, согласно отчету LeadDev, 70% теперь описывают себя как внедрившие их&nbsp;«широко или полностью», и&nbsp;только&nbsp;26% сообщают, что&nbsp;ИИ повысил производительность инженеров более чем на&nbsp;25%. Эти&nbsp;26%, как уточняет Майкл Хилл, управляющий редактор LeadDev и&nbsp;автор отчета, включают в&nbsp;себя респондентов, полагающихся на&nbsp;интуицию, а&nbsp;не&nbsp;только на&nbsp;подтвержденные данные.&lltt;/p&ggtt;
&lltt;p&ggtt;«Оптимизм в&nbsp;отношении производительности (26% отмечают значительный рост) и&nbsp;разрыв в&nbsp;измерениях (только&nbsp;31% фактически отслеживает его)&nbsp;— это два отдельных результата, полученные на&nbsp;основе ответов на&nbsp;два разных вопроса»,&nbsp;— отмечает&nbsp;он, а&nbsp;это значит, что «большинство людей, сообщающих о&nbsp;росте, не&nbsp;могут это доказать».&lltt;/p&ggtt;
&lltt;p&ggtt;Как известно, нельзя улучшить&nbsp;то, что не&nbsp;измеряешь. Но&nbsp;даже у&nbsp;тех, кто проводит измерения, результаты вызывают беспокойство.&lltt;/p&ggtt;]]></source>
<adate>24.08.2026</adate>
<dbid>235390</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Подготовка данных для корпоративного ИИ: решение проблемы &#8220;первой мили&#8221;]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235389]]></link>
<description><![CDATA[В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как улучшить результаты и снизить затраты на ИИ-инициативы, одновременно защитив корпоративный бренд? В конце концов, высшее руководство все чаще называет внедрение ИИ основным поводом для сокращения штата на 20% и более. Советы директоров и инвесторы компаний оказывают сильное давление на исполнительных руководителей, требуя показать финансовые и ощутимые выгоды от масштабных инвестиций в ИИ, которые обходятся крупным предприятиям более чем в 10 млн. долл. в год, пишет на портале BigDataWire Кумар Гошвами, соучредитель и генеральный директор Komprise. В целом, пока сложно продемонстрировать окупаемость инвестиций в ИИ. Исследование MIT Research показало, что 95% пилотных проектов генеративного ИИ не приносят измеримой финансовой отдачи, а Gartner прогнозирует, что более 40% проектов агентного ИИ будут отменены к концу 2027 г. Хотя существует множество факторов, объясняющих низкую рентабельность инвестиций и высокий уровень неудач, качество данных является постоянным препятствием, на которое указывают аналитики. Индустрия ИИ до сих пор фокусировалась на уровне рассуждений, в то время как уровню подготовки данных уделялось сравнительно меньше внимания. Более того, подготовка данных часто обсуждается в терминах «последней мили»: разбить документы на фрагменты, сгенерировать вложения, загрузить векторную базу данных, построить конвейер поиска. Это предполагает, что к моменту попадания в конвейер данные чистые, классифицированные, управляемые и релевантные, но это в значительной степени не соответствует действительности. Исследования снова и снова показывают, что организации сталкиваются с проблемами, связанными с разрозненностью, управлением и общим качеством данных. Опрос Databricks показал, что только 37% руководителей считают свои приложения генеративного ИИ готовыми к внедрению в производство. Этот разрыв — проблема «первой мили» ИИ: поиск данных, их понимание, классификация и определение того, что вообще не должно попадать в модель. Проблема неструктурированных данных для ИИ Если вы спросите поставщика облачных услуг или платформы LLM, как использовать неструктурированные данные, они почти всегда начнут с того, что посоветуют вам загрузить файлы в хранилище S3 или в озеро-хранилище (lakehouse) данных. Однако этот подход быстро меняется, поскольку объем файловых и объектных данных неуклонно растет, а затраты и риски безопасности для ИИ увеличиваются. Неструктурированные данные, которые составляют от 80 до 90% новых корпоративных данных, растут примерно в три раза быстрее, чем структурированные данные, и теперь являются исходным материалом, необходимым для каждой корпоративной ИИ-инициативы. Тем не менее, большинство ИТ-команд по-прежнему не могут сказать вам, где все это хранится, каково его содержимое или как безопасно использовать это в ИИ. Проблема обработки больших объемов неструктурированных данных многогранна, она охватывает следующее: 	 файловые хранилища NAS, накопленные за многие годы, и объектные хранилища, распределенные по облачным провайдерам; 	 миллиарды разнообразных файлов: документы, отсканированные PDF-файлы, чертежи САПР, архивы электронной почты, мультимедийные файлы, данные приборов и многое другое; 	 широко распространены дубликаты, «осиротевшие», тривиальные и «зомби», или «мертвые» данные, засоряющие хранилище и ухудшающие видимость; 	 несогласованная структура папок и отсутствие структуры, контекста и богатых метаданных, что затрудняет обнаружение и организацию неструктурированных данных; 	 большая часть этих данных трудно поддается запросам, поскольку они не хранятся в базе данных, разбросаны по разрозненным хранилищам и имеют мало идентифицирующих характеристик. Объяснение проблемы «первой мили» Для подготовки данных к использованию в ИИ необходимо выполнить несколько критически важных этапов предварительной обработки: индексирование в хранилищах разных производителей, обнаружение, очистка и удаление дубликатов, классификация путем обогащения и извлечения метаданных, обнаружение конфиденциальных данных и включение политик управления и безопасности в рабочие процессы обработки данных для ИИ. Эта проблема выявлена ​​в исследовании Komprise «2026 State of Unstructured Data Management», согласно которому классификацию и маркировку неструктурированных данных назвали своей главной проблемой при подготовке данных для ИИ 56% директоров по ИТ-инфраструктуре, по сравнению с 41% годом ранее. Управление и безопасность заняли второе место с 46%. Причина этой проблемы «первой мили» заключается в том, что ИИ эволюционировал от массовых потребительских чат-ботов до стратегических, крупномасштабных корпоративных инициатив с использованием корпоративных данных. 	Миф об «песочнице» ИИ. До недавнего времени большинство корпоративных ИИ-проектов представляли собой изолированные эксперименты или небольшие проверки концепций. При обработке 500 корпоративных документов их можно вручную выбрать, загрузить в хранилище данных и запустить конвейер RAG. Однако с расширением применения ИИ на более крупные задачи это не масштабируется для рабочих нагрузок, которые могут включать 100 000 или более файлов, с неизвестным процентом файлов, не подходящих для данной задачи. 	Миф о векторной фильтрации. Существует устойчивое предположение, что векторная база данных автоматически отфильтрует избыточный или устаревший контент. На практике, если у компании есть десяток версий одних и тех же устаревших документов, разбросанных по различным системам хранения, поиск пользователя выдаст несколько противоречащих друг другу версий в одном и том же запросе. ИИ-инженеры не учитывают, что подача огромного количества устаревших, избыточных или низкокачественных данных в модель ИИ приводит к сильным иллюзиям, медленному времени ответа на запросы и раздуванию счетов за токены. 	Отсутствие инструментов управления на уровне файлов. Традиционные инструменты хранения данных были созданы для администраторов хранилищ и предназначены для резервного копирования, многоуровневого хранения и архивирования, а не для развертывания рабочих процессов обработки данных для специалистов в области науки о данных. Не хватает инструментов для безопасной и эффективной доставки чистых, организованных файлов из устаревших корпоративных файловых хранилищ в конвейеры обработки данных. В эти рабочие процессы необходимо интегрировать средства управления соответствием нормативным требованиям в отношении использования данных путем выявления конфиденциальных и регулируемых данных и принятия соответствующих мер при необходимости. 	Экономика владения. Бизнес-приложения, такие как CRM, ERP и системы взаимодействия с клиентами, влияющие на выручку, имеют финансовую историю и поддержку руководства, поэтому они бюджетируются. Неструктурированные данные в основном находятся в другой бюджетной строке: ИТ-инфраструктура и системы хранения, центр затрат без влияния на доходы. Поиск дубликатов, устаревших или регулируемых файлов, по общему мнению, является более сложной инженерной задачей, но у нее нет бизнес-спонсора в отличие от новой функции CRM. Однако ИТ-команды сейчас понимают, что ИИ зависит от высококачественных, управляемых данных, а подготовка данных требует значительных бюджетных затрат. Lakehouse не решает проблему ИИ повысил важность озера-хранилища данных — архитектуры, сочетающей в себе недорогое хранение в озере данных с управлением уровня хранилища данных. Тем не менее, у lakehouse есть ограничения, когда речь идет о курировании неструктурированных данных для ИИ. Во-первых, lakehouse по-прежнему требует размещения необработанных данных где-то, прежде чем уровень управления сможет с ними работать. Большинство реализаций следуют поэтапной схеме, часто называемой «медальонной архитектурой», размещая необработанные данные в «бронзовом» слое, прежде чем они будут очищены и структурированы. Для строк, извлеченных из CRM, этот шаг обходится недорого. Для петабайтов файловых данных, распределенных по локальным NAS-серверам, нескольким облачным хранилищам и периферийным точкам, это не так, а большие объемы уже являются нормой. Во-вторых, инструменты, созданные для перемещения данных на платформы, такие как ETL и ELT, не были разработаны для больших наборов неструктурированных данных, распределенных по разрозненным хранилищам. Это обосновывает подход «нулевого перемещения»: индексировать и классифицировать данные там, где они хранятся, отфильтровывать избыточные, устаревшие, тривиальные (ROT) данные до их перемещения и перемещать только управляемое подмножество, необходимое для рабочей нагрузки. Lakehouse — прекрасное место назначения. Но требует предварительного решения о том, что там должно находиться. Переход к нулевой фазе Финансовые затраты на перемещение всего — это только половина проблемы. Другая половина проявляется в том, что производит система ИИ: ввод в модель низкокачественного или дублирующегося контента, как правило, приводит к заведомо неверному ответу. Существуют также затраты на управление. Контроль доступа на уровне файлов существует не просто так, и когда необработанные данные копируются целиком в новую среду, эти средства контроля не всегда переносятся вместе с ними. Разбивка на фрагменты, синтаксический анализ и векторные вложения по-прежнему необходимы, но они относятся к концу процесса. Нам нужен нулевой этап перед ними: найти, какие данные существуют и где, классифицировать их по содержимому и конфиденциальности, отфильтровать нерелевантные данные и обеспечить соблюдение правил управления и доступа до того, как какие-либо данные будут перемещены в модель или озеро-хранилище данных. Вот как развиваются рабочий процесс и набор инструментов для конвейеров обработки данных ИИ: 	 инструменты обнаружения и классификации для поиска контента в разрозненных хранилищах; 	 платформы управления неструктурированными данными для метаданных, политик и перемещения; 	 уровни управления и контроля доступа для обеспечения безопасности и отслеживания происхождения данных; 	 инструменты синтаксического анализа, оптического распознавания символов и обогащения для преобразования файлов в пригодный для использования контент; 	 уровни поиска и векторного представления для обслуживания рабочей нагрузки ИИ. В дальнейшем ИТ- и дата-командам необходимо рассматривать индексирование, поиск и классификацию данных как инфраструктуру, а не как второстепенный аспект. Это позволит организациям эффективно отсеивать дубликаты файлов, неавторитетные и нерелевантные данные, одновременно учитывая специфические требования к данным, которые не подпадают под действие нормативных требований и правил безопасности. Предприятия, которые преодолеют барьер «первой мили», в конечном итоге будут передавать меньше данных в ИИ, экономя на токенах, хранении, вычислительных ресурсах и затратах на передачу данных, обеспечивая при этом доступность только необходимых для конкретного сценария использования данных. Предприятиям, которые хотят, чтобы ИИ работал в масштабе с достижимой окупаемостью инвестиций, в первую очередь необходимо ответить на вопрос: «Где хранятся наши неструктурированные данные, что в них содержится и как мы можем обеспечить их доставку с соблюдением принципов управления?», а не «Какую модель встраивания нам следует использовать?»]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;В&nbsp;мире корпоративного искусственного интеллекта назревает проблема, и&nbsp;ИТ-руководители сталкиваются с&nbsp;дилеммой. Как улучшить результаты и&nbsp;снизить затраты на&nbsp;ИИ-инициативы, одновременно защитив корпоративный бренд? В&nbsp;конце концов, высшее руководство все чаще называет внедрение&nbsp;ИИ основным поводом для сокращения штата на&nbsp;20% и&nbsp;более. Советы директоров и&nbsp;инвесторы компаний оказывают сильное давление на&nbsp;исполнительных руководителей, требуя показать финансовые и&nbsp;ощутимые выгоды от&nbsp;масштабных инвестиций в&nbsp;ИИ, которые обходятся крупным предприятиям более чем в&nbsp;10&nbsp;млн. долл.&nbsp;в&nbsp;год, пишет на&nbsp;портале &lltt;/em&ggtt;&lltt;em&ggtt;BigDataWire&lltt;/em&ggtt; &lltt;em&ggtt;Кумар Гошвами, соучредитель и&nbsp;генеральный директор Komprise.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;целом, пока сложно продемонстрировать окупаемость инвестиций в&nbsp;ИИ. Исследование MIT Research показало, что&nbsp;95% пилотных проектов генеративного&nbsp;ИИ не&nbsp;приносят измеримой финансовой отдачи, а&nbsp;Gartner прогнозирует, что более&nbsp;40% проектов агентного&nbsp;ИИ будут отменены к&nbsp;концу 2027&nbsp;г.&lltt;/p&ggtt;
&lltt;p&ggtt;Хотя существует множество факторов, объясняющих низкую рентабельность инвестиций и&nbsp;высокий уровень неудач, качество данных является постоянным препятствием, на&nbsp;которое указывают аналитики. Индустрия ИИ&nbsp;до&nbsp;сих пор фокусировалась на&nbsp;уровне рассуждений, в&nbsp;то&nbsp;время как уровню подготовки данных уделялось сравнительно меньше внимания.&lltt;/p&ggtt;
&lltt;p&ggtt;Более того, подготовка данных часто обсуждается в&nbsp;терминах «последней мили»: разбить документы на&nbsp;фрагменты, сгенерировать вложения, загрузить векторную базу данных, построить конвейер поиска. Это предполагает, что к&nbsp;моменту попадания в&nbsp;конвейер данные чистые, классифицированные, управляемые и&nbsp;релевантные, но&nbsp;это в&nbsp;значительной степени не&nbsp;соответствует действительности. Исследования снова и&nbsp;снова показывают, что организации сталкиваются с&nbsp;проблемами, связанными с&nbsp;разрозненностью, управлением и&nbsp;общим качеством данных. Опрос Databricks показал, что только&nbsp;37% руководителей считают свои приложения генеративного&nbsp;ИИ готовыми к&nbsp;внедрению в&nbsp;производство.&lltt;/p&ggtt;
&lltt;p&ggtt;Этот разрыв&nbsp;— проблема «первой мили» ИИ: поиск данных, их&nbsp;понимание, классификация и&nbsp;определение того, что вообще не&nbsp;должно попадать в&nbsp;модель.&lltt;/p&ggtt;
&lltt;h3&ggtt;Проблема неструктурированных данных для ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Если вы&nbsp;спросите поставщика облачных услуг или платформы LLM, как использовать неструктурированные данные, они почти всегда начнут с&nbsp;того, что посоветуют вам загрузить файлы в&nbsp;хранилище S3&nbsp;или в&nbsp;озеро-хранилище (lakehouse) данных. Однако этот подход быстро меняется, поскольку объем файловых и&nbsp;объектных данных неуклонно растет, а&nbsp;затраты и&nbsp;риски безопасности для&nbsp;ИИ увеличиваются.&lltt;/p&ggtt;
&lltt;p&ggtt;Неструктурированные данные, которые составляют от&nbsp;80&nbsp;до&nbsp;90% новых корпоративных данных, растут примерно в&nbsp;три раза быстрее, чем структурированные данные, и&nbsp;теперь являются исходным материалом, необходимым для каждой корпоративной ИИ-инициативы. Тем не&nbsp;менее, большинство ИТ-команд по-прежнему не&nbsp;могут сказать вам, где все это хранится, каково его содержимое или как безопасно использовать это в&nbsp;ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема обработки больших объемов неструктурированных данных многогранна, она охватывает следующее:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; файловые хранилища NAS, накопленные за&nbsp;многие годы, и&nbsp;объектные хранилища, распределенные по&nbsp;облачным провайдерам;&lltt;/li&ggtt;
	&lltt;li&ggtt; миллиарды разнообразных файлов: документы, отсканированные PDF-файлы, чертежи САПР, архивы электронной почты, мультимедийные файлы, данные приборов и&nbsp;многое другое;&lltt;/li&ggtt;
	&lltt;li&ggtt; широко распространены дубликаты, «осиротевшие», тривиальные и&nbsp;«зомби», или «мертвые» данные, засоряющие хранилище и&nbsp;ухудшающие видимость;&lltt;/li&ggtt;
	&lltt;li&ggtt; несогласованная структура папок и&nbsp;отсутствие структуры, контекста и&nbsp;богатых метаданных, что затрудняет обнаружение и&nbsp;организацию неструктурированных данных;&lltt;/li&ggtt;
	&lltt;li&ggtt; большая часть этих данных трудно поддается запросам, поскольку они не&nbsp;хранятся в&nbsp;базе данных, разбросаны по&nbsp;разрозненным хранилищам и&nbsp;имеют мало идентифицирующих характеристик.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Объяснение проблемы «первой мили»&lltt;/h3&ggtt;
&lltt;p&ggtt;Для подготовки данных к&nbsp;использованию в&nbsp;ИИ необходимо выполнить несколько критически важных этапов предварительной обработки: индексирование в&nbsp;хранилищах разных производителей, обнаружение, очистка и&nbsp;удаление дубликатов, классификация путем обогащения и&nbsp;извлечения метаданных, обнаружение конфиденциальных данных и&nbsp;включение политик управления и&nbsp;безопасности в&nbsp;рабочие процессы обработки данных для ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Эта проблема выявлена ​​в исследовании Komprise «2026 State of&nbsp;Unstructured Data Management», согласно которому классификацию и&nbsp;маркировку неструктурированных данных назвали своей главной проблемой при подготовке данных для ИИ&nbsp;56% директоров по&nbsp;ИТ-инфраструктуре, по&nbsp;сравнению с&nbsp;41% годом ранее. Управление и&nbsp;безопасность заняли второе место с&nbsp;46%.&lltt;/p&ggtt;
&lltt;p&ggtt;Причина этой проблемы «первой мили» заключается в&nbsp;том, что&nbsp;ИИ эволюционировал от&nbsp;массовых потребительских чат-ботов до&nbsp;стратегических, крупномасштабных корпоративных инициатив с&nbsp;использованием корпоративных данных.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Миф об&nbsp;«песочнице» ИИ.&lltt;/strong&ggtt; До&nbsp;недавнего времени большинство корпоративных ИИ-проектов представляли собой изолированные эксперименты или небольшие проверки концепций. При обработке 500 корпоративных документов их&nbsp;можно вручную выбрать, загрузить в&nbsp;хранилище данных и&nbsp;запустить конвейер RAG. Однако с&nbsp;расширением применения&nbsp;ИИ на&nbsp;более крупные задачи это не&nbsp;масштабируется для рабочих нагрузок, которые могут включать 100&nbsp;000 или более файлов, с&nbsp;неизвестным процентом файлов, не&nbsp;подходящих для данной задачи.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Миф о&nbsp;векторной фильтрации.&lltt;/strong&ggtt; Существует устойчивое предположение, что векторная база данных автоматически отфильтрует избыточный или устаревший контент. На&nbsp;практике, если у&nbsp;компании есть десяток версий одних и&nbsp;тех&nbsp;же устаревших документов, разбросанных по&nbsp;различным системам хранения, поиск пользователя выдаст несколько противоречащих друг другу версий в&nbsp;одном и&nbsp;том&nbsp;же запросе. ИИ-инженеры не&nbsp;учитывают, что подача огромного количества устаревших, избыточных или низкокачественных данных в&nbsp;модель&nbsp;ИИ приводит к&nbsp;сильным иллюзиям, медленному времени ответа на&nbsp;запросы и&nbsp;раздуванию счетов за&nbsp;токены.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Отсутствие инструментов управления на&nbsp;уровне файлов.&lltt;/strong&ggtt; Традиционные инструменты хранения данных были созданы для администраторов хранилищ и&nbsp;предназначены для резервного копирования, многоуровневого хранения и&nbsp;архивирования, а&nbsp;не&nbsp;для развертывания рабочих процессов обработки данных для специалистов в&nbsp;области науки о&nbsp;данных. Не&nbsp;хватает инструментов для безопасной и&nbsp;эффективной доставки чистых, организованных файлов из&nbsp;устаревших корпоративных файловых хранилищ в&nbsp;конвейеры обработки данных. В&nbsp;эти рабочие процессы необходимо интегрировать средства управления соответствием нормативным требованиям в&nbsp;отношении использования данных путем выявления конфиденциальных и&nbsp;регулируемых данных и&nbsp;принятия соответствующих мер при необходимости.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Экономика владения.&lltt;/strong&ggtt; Бизнес-приложения, такие как CRM, ERP и&nbsp;системы взаимодействия с&nbsp;клиентами, влияющие на&nbsp;выручку, имеют финансовую историю и&nbsp;поддержку руководства, поэтому они бюджетируются. Неструктурированные данные в&nbsp;основном находятся в&nbsp;другой бюджетной строке: ИТ-инфраструктура и&nbsp;системы хранения, центр затрат без влияния на&nbsp;доходы. Поиск дубликатов, устаревших или регулируемых файлов, по&nbsp;общему мнению, является более сложной инженерной задачей, но&nbsp;у&nbsp;нее нет бизнес-спонсора в&nbsp;отличие от&nbsp;новой функции CRM. Однако ИТ-команды сейчас понимают, что&nbsp;ИИ зависит от&nbsp;высококачественных, управляемых данных, а&nbsp;подготовка данных требует значительных бюджетных затрат.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Lakehouse не&nbsp;решает проблему&lltt;/h3&ggtt;
&lltt;p&ggtt;ИИ&nbsp;повысил важность озера-хранилища данных&nbsp;— архитектуры, сочетающей в&nbsp;себе недорогое хранение в&nbsp;озере данных с&nbsp;управлением уровня хранилища данных. Тем не&nbsp;менее, у&nbsp;lakehouse есть ограничения, когда речь идет о&nbsp;курировании неструктурированных данных для ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Во-первых, lakehouse по-прежнему требует размещения необработанных данных где-то, прежде чем уровень управления сможет с&nbsp;ними работать. Большинство реализаций следуют поэтапной схеме, часто называемой «медальонной архитектурой», размещая необработанные данные в&nbsp;«бронзовом» слое, прежде чем они будут очищены и&nbsp;структурированы. Для строк, извлеченных из&nbsp;CRM, этот шаг обходится недорого. Для петабайтов файловых данных, распределенных по&nbsp;локальным NAS-серверам, нескольким облачным хранилищам и&nbsp;периферийным точкам, это не&nbsp;так, а&nbsp;большие объемы уже являются нормой.&lltt;/p&ggtt;
&lltt;p&ggtt;Во-вторых, инструменты, созданные для перемещения данных на&nbsp;платформы, такие как ETL и&nbsp;ELT, не&nbsp;были разработаны для больших наборов неструктурированных данных, распределенных по&nbsp;разрозненным хранилищам.&lltt;/p&ggtt;
&lltt;p&ggtt;Это обосновывает подход «нулевого перемещения»: индексировать и&nbsp;классифицировать данные там, где они хранятся, отфильтровывать избыточные, устаревшие, тривиальные (ROT) данные до&nbsp;их&nbsp;перемещения и&nbsp;перемещать только управляемое подмножество, необходимое для рабочей нагрузки. Lakehouse&nbsp;— прекрасное место назначения. Но&nbsp;требует предварительного решения о&nbsp;том, что там должно находиться.&lltt;/p&ggtt;
&lltt;h3&ggtt;Переход к&nbsp;нулевой фазе&lltt;/h3&ggtt;
&lltt;p&ggtt;Финансовые затраты на&nbsp;перемещение всего&nbsp;— это только половина проблемы. Другая половина проявляется в&nbsp;том, что производит система&nbsp;ИИ: ввод в&nbsp;модель низкокачественного или дублирующегося контента, как правило, приводит к&nbsp;заведомо неверному ответу. Существуют также затраты на&nbsp;управление. Контроль доступа на&nbsp;уровне файлов существует не&nbsp;просто так, и&nbsp;когда необработанные данные копируются целиком в&nbsp;новую среду, эти средства контроля не&nbsp;всегда переносятся вместе с&nbsp;ними.&lltt;/p&ggtt;
&lltt;p&ggtt;Разбивка на&nbsp;фрагменты, синтаксический анализ и&nbsp;векторные вложения по-прежнему необходимы, но&nbsp;они относятся к&nbsp;концу процесса. Нам нужен нулевой этап перед ними: найти, какие данные существуют и&nbsp;где, классифицировать их&nbsp;по&nbsp;содержимому и&nbsp;конфиденциальности, отфильтровать нерелевантные данные и&nbsp;обеспечить соблюдение правил управления и&nbsp;доступа до&nbsp;того, как какие-либо данные будут перемещены в&nbsp;модель или озеро-хранилище данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Вот как развиваются рабочий процесс и&nbsp;набор инструментов для конвейеров обработки данных ИИ:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; инструменты обнаружения и&nbsp;классификации для поиска контента в&nbsp;разрозненных хранилищах;&lltt;/li&ggtt;
	&lltt;li&ggtt; платформы управления неструктурированными данными для метаданных, политик и&nbsp;перемещения;&lltt;/li&ggtt;
	&lltt;li&ggtt; уровни управления и&nbsp;контроля доступа для обеспечения безопасности и&nbsp;отслеживания происхождения данных;&lltt;/li&ggtt;
	&lltt;li&ggtt; инструменты синтаксического анализа, оптического распознавания символов и&nbsp;обогащения для преобразования файлов в&nbsp;пригодный для использования контент;&lltt;/li&ggtt;
	&lltt;li&ggtt; уровни поиска и&nbsp;векторного представления для обслуживания рабочей нагрузки ИИ.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;В&nbsp;дальнейшем ИТ- и&nbsp;дата-командам необходимо рассматривать индексирование, поиск и&nbsp;классификацию данных как инфраструктуру, а&nbsp;не&nbsp;как второстепенный аспект. Это позволит организациям эффективно отсеивать дубликаты файлов, неавторитетные и&nbsp;нерелевантные данные, одновременно учитывая специфические требования к&nbsp;данным, которые не&nbsp;подпадают под действие нормативных требований и&nbsp;правил безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;Предприятия, которые преодолеют барьер «первой мили», в&nbsp;конечном итоге будут передавать меньше данных в&nbsp;ИИ, экономя на&nbsp;токенах, хранении, вычислительных ресурсах и&nbsp;затратах на&nbsp;передачу данных, обеспечивая при этом доступность только необходимых для конкретного сценария использования данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Предприятиям, которые хотят, чтобы&nbsp;ИИ работал в&nbsp;масштабе с&nbsp;достижимой окупаемостью инвестиций, в&nbsp;первую очередь необходимо ответить на&nbsp;вопрос: «Где хранятся наши неструктурированные данные, что в&nbsp;них содержится и&nbsp;как мы&nbsp;можем обеспечить их&nbsp;доставку с&nbsp;соблюдением принципов управления?», а&nbsp;не&nbsp;«Какую модель встраивания нам следует использовать?».&lltt;/p&ggtt;]]></source>
<adate>24.08.2026</adate>
<dbid>235389</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Big Data/Аналитика;;Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[ИСИЭЗ НИУ ВШЭ: затраты организаций на внедрение и использование цифровых технологий в 2025 году]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235388]]></link>
<description><![CDATA[Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата анализирует динамику и структуру затрат крупных и средних организаций (без учета субъектов малого предпринимательства) на внедрение и использование цифровых технологий в 2025 г. В 2025 г. организации направили на внедрение и использование цифровых технологий почти 5,9 трлн руб., что в текущих ценах на 11,8% выше показателя 2024 г. Основные статьи расходов — ПО (лицензии, SaaS, разработка, доработка, адаптация), на которое пришлось 37% анализируемых затрат, и ИКТ-оборудование (приобретение, аренда, обслуживание, модернизация, ремонт) с долей 27%. Расходы на ПО выросли на 13,7%, во многом за счет увеличения заказной разработки. Общий объем затрат на оборудование практически сохранился на уровне 2024 г. (-0,9%), при этом расходы на приобретение ИКТ-оборудования снизились (-10,2%), прежде всего в сегменте вычислительной техники, что объясняется как высокой базой 2024 г. (годом ранее отмечался рост затрат на четверть), так и сложностями с импортом, в том числе из-за возникшего в 2025 г. дефицита серверов и оперативной памяти на мировом рынке. Одновременно в 1,5 раза вырос объем затрат на аренду вычислительных мощностей (IaaS). Наиболее высокими темпами росли расходы на базы данных и цифровой контент: при доле всего 3,3% в структуре затрат за год они увеличились в 1,7 раза. Более половины анализируемых затрат приходится на сферу ИТ и связи (36%) и финансовый сектор (23,1%). В 2025 г. вложения выросли как в этих, так и в большинстве других отраслей— всего в 16 из 18. Расходы в госуправлении, здравоохранении, оптовой и розничной торговле увеличились на 20–22%, в ИТ и связи, финансовом секторе, обрабатывающей промышленности, профессиональной и научно-технической деятельности, на транспорте — на 11–14%. Основную часть затрат на цифровые технологии организации покрыли за счет собственных средств (86,6%). Доля бюджетных составила 12,3%, заемных и прочих привлеченных средств — немногим более 1%]]></description>
<source><![CDATA[&lltt;p&ggtt;Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата анализирует динамику и структуру затрат крупных и средних организаций (без учета субъектов малого предпринимательства) на внедрение и использование цифровых технологий в 2025 г.&lltt;/p&ggtt;
&lltt;p&ggtt;В 2025 г. организации направили на внедрение и использование цифровых технологий почти 5,9 трлн руб., что в текущих ценах на 11,8% выше показателя 2024 г.&lltt;/p&ggtt;
&lltt;p&ggtt;Основные статьи расходов — ПО (лицензии, SaaS, разработка, доработка, адаптация), на которое пришлось 37% анализируемых затрат, и ИКТ-оборудование (приобретение, аренда, обслуживание, модернизация, ремонт) с долей 27%.&lltt;/p&ggtt;
&lltt;p&ggtt;Расходы на ПО выросли на 13,7%, во многом за счет увеличения заказной разработки.&lltt;/p&ggtt;
&lltt;p&ggtt;Общий объем затрат на оборудование практически сохранился на уровне 2024 г. (-0,9%), при этом расходы на приобретение ИКТ-оборудования снизились (-10,2%), прежде всего в сегменте вычислительной техники, что объясняется как высокой базой 2024 г. (годом ранее отмечался рост затрат на четверть), так и сложностями с импортом, в том числе из-за возникшего в 2025 г. дефицита серверов и оперативной памяти на мировом рынке. Одновременно в 1,5 раза вырос объем затрат на аренду вычислительных мощностей (IaaS).&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее высокими темпами росли расходы на базы данных и цифровой контент: при доле всего 3,3% в структуре затрат за год они увеличились в 1,7 раза.&lltt;/p&ggtt;
&lltt;p&ggtt;Более половины анализируемых затрат приходится на сферу ИТ и связи (36%) и финансовый сектор (23,1%). В 2025 г. вложения выросли как в этих, так и в большинстве других отраслей— всего в 16 из 18. Расходы в госуправлении, здравоохранении, оптовой и розничной торговле увеличились на &lltt;nobr&ggtt;20–22%,&lltt;/nobr&ggtt; в ИТ и связи, финансовом секторе, обрабатывающей промышленности, профессиональной и научно-технической деятельности, на транспорте — на &lltt;nobr&ggtt;11–14%.&lltt;/nobr&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Основную часть затрат на цифровые технологии организации покрыли за счет собственных средств (86,6%). Доля бюджетных составила 12,3%, заемных и прочих привлеченных средств — немногим более 1%.&lltt;/p&ggtt;]]></source>
<adate>21.08.2026</adate>
<dbid>235388</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Цифровая трансформация]]></tag>
</item>
<item>
<title><![CDATA[MULTIDIRECTORY 3.2.0: отказоустойчивость, LDAP-структура в GPO и поддержка Astra Linux с МРД]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235387]]></link>
<description><![CDATA[Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0. Обновление фокусируется на улучшении управляемости групповыми политиками, расширении поддержки отечественных операционных систем с мандатно-ролевым доступом и повышении отказоустойчивости распределённых инфраструктур. Одним из центральных улучшений стало отображение LDAP-структуры непосредственно в интерфейс управления групповыми политиками. Теперь администраторы видят полную иерархию организационных подразделений с привязанными и наследуемыми политиками в режиме реального времени. Это упрощает навигацию по каталогу и позволяет назначать групповые политики напрямую на нужное подразделение без дополнительных переходов между модулями. Всё это ускоряет работу администратора и снижает риск ошибок при настройке. В схему LDAP-каталога добавлены новые классы объектов и атрибуты, необходимые для работы с мандатно-ролевым доступом (МРД) в Astra Linux Special Edition (релизы «Смоленск» и «Воронеж»). Благодаря этому MULTIDIRECTORY теперь полностью совместима с требованиями по защите информации, предъявляемыми к системам в государственных и регулируемых отраслях. Обновление позволяет централизованно управлять учётными записями и политиками безопасности в инфраструктурах, где используются сертифицированные версии Astra Linux с МРД. Для распределённых и высоконагруженных инфраструктур реализована динамическая балансировка запросов между контроллерами домена в отказоустойчивой конфигурации. Система учитывает состояние healthcheck каждого контроллера и автоматически перенаправляет запросы на доступные узлы. Это позволяет разворачивать MULTIDIRECTORY в отказоустойчивом кластере, обеспечивая бесперебойную работу инфраструктуры даже при выходе отдельных компонентов из строя. В новой версии устранён ряд критических ошибок, влияющих на стабильность и совместимость системы. Исправлены BER-обёртка для LDAP Controls, логика определения namingContexts в rootDSE и обработка удаления атрибутов в Modify Request — теперь операция не чувствительна к регистру. Устранены ошибки в генерации файлов init.sls в результирующих политиках, очистке тома Salt Master от устаревших политик и ожидании готовности сервисов Kerberos. Обновление MULTIDIRECTORY 3.2.0 превращает службу каталогов в отказоустойчивое решение для распределённых инфраструктур, которое обеспечивает соответствие регуляторным требованиям и стабильность работы в сертифицированных контурах защиты информации]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0. Обновление фокусируется на улучшении управляемости групповыми политиками, расширении поддержки отечественных операционных систем с мандатно-ролевым доступом и повышении отказоустойчивости распределённых инфраструктур.&lltt;/p&ggtt;
&lltt;p&ggtt;Одним из центральных улучшений стало отображение LDAP-структуры непосредственно в интерфейс управления групповыми политиками. Теперь администраторы видят полную иерархию организационных подразделений с привязанными и наследуемыми политиками в режиме реального времени. Это упрощает навигацию по каталогу и позволяет назначать групповые политики напрямую на нужное подразделение без дополнительных переходов между модулями. Всё это ускоряет работу администратора и снижает риск ошибок при настройке.&lltt;/p&ggtt;
&lltt;p&ggtt;В схему LDAP-каталога добавлены новые классы объектов и атрибуты, необходимые для работы с мандатно-ролевым доступом (МРД) в Astra Linux Special Edition (релизы «Смоленск» и «Воронеж»). Благодаря этому MULTIDIRECTORY теперь полностью совместима с требованиями по защите информации, предъявляемыми к системам в государственных и регулируемых отраслях. Обновление позволяет централизованно управлять учётными записями и политиками безопасности в инфраструктурах, где используются сертифицированные версии Astra Linux с МРД.&lltt;/p&ggtt;
&lltt;p&ggtt;Для распределённых и высоконагруженных инфраструктур реализована динамическая балансировка запросов между контроллерами домена в отказоустойчивой конфигурации. Система учитывает состояние healthcheck каждого контроллера и автоматически перенаправляет запросы на доступные узлы. Это позволяет разворачивать MULTIDIRECTORY в отказоустойчивом кластере, обеспечивая бесперебойную работу инфраструктуры даже при выходе отдельных компонентов из строя.&lltt;/p&ggtt;
&lltt;p&ggtt;В новой версии устранён ряд критических ошибок, влияющих на стабильность и совместимость системы. Исправлены BER-обёртка для LDAP Controls, логика определения namingContexts в rootDSE и обработка удаления атрибутов в Modify Request — теперь операция не чувствительна к регистру. Устранены ошибки в генерации файлов init.sls в результирующих политиках, очистке тома Salt Master от устаревших политик и ожидании готовности сервисов Kerberos.&lltt;/p&ggtt;
&lltt;p&ggtt;Обновление MULTIDIRECTORY 3.2.0 превращает службу каталогов в отказоустойчивое решение для распределённых инфраструктур, которое обеспечивает соответствие регуляторным требованиям и стабильность работы в сертифицированных контурах защиты информации.&lltt;/p&ggtt;]]></source>
<adate>21.08.2026</adate>
<dbid>235387</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[4% мирового ИТ-рынка к 2030 году: как российскому бизнесу строить стратегию кибербезопасности после ухода &#8220;большой четверки&#8221;]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235382]]></link>
<description><![CDATA[Зарубежные аудиторы ушли из России, но потребность в зрелой стратегии информационной безопасности никуда не исчезла. Теперь российским компаниям приходится одновременно развивать собственные команды, обращаться к локальным консультантам и превращать ИИ-агентов в персональных экспертов по кибербезопасности. После ухода из России крупнейших международных аудиторских компаний рынок информационной безопасности лишился не просто известных брендов. Вместе с ними ушел доступ к огромному массиву практического опыта, который формировался благодаря работе с компаниями из разных стран, отраслей и регуляторных сред. Российский рынок составляет около 2% мирового рынка ИТ и информационной безопасности. Поэтому локальные специалисты и консультанты объективно работают с меньшим количеством сценариев, бизнес-моделей и инцидентов. Именно клиентское покрытие давало зарубежным аудиторам ключевое преимущество: они могли переносить в проекты процессы и подходы, проверенные на международном уровне. Рост доли России с 2 до 4% мирового ИТ-рынка к 2030 году можно рассматривать не как прогноз, а как ориентир для отрасли. Однако для такого роста недостаточно увеличивать число технологий и специалистов. Российскому бизнесу нужны зрелые процессы, в том числе в информационной безопасности. После ухода международных аудиторов готового доступа к таким практикам стало меньше, поэтому компаниям приходится фактически заново собирать эту экспертизу — внутри собственных команд, с помощью российских консультантов и ИИ-агентов. Сегодня перед российским средним и крупным бизнесом стоит сложный вопрос: откуда брать зрелую экспертизу и на чем строить стратегию информационной безопасности, если прежние источники знаний стали недоступны? Единственного решения здесь нет. Компании могут использовать три подхода — внедрять ИИ-агентов, развивать собственные команды и привлекать российских аудиторов. Но по-настоящему жизнеспособная стратегия возникает только тогда, когда бизнес совмещает все три направления. ИИ-агент может стать экспертом по кибербезопасности — но на его обучение потребуется время Современный ИИ — это уже не просто приложение, в которое пользователь вводит запрос через браузер. Бизнес может приобрести специализированный сервис, подключенный через API к крупным языковым моделям и способный самостоятельно выбирать источники и инструменты для решения конкретной задачи. На основе такой системы можно создать персонального ИИ-эксперта по информационной безопасности. Для этого агенту необходимо предоставить максимально полную базу знаний: российскую и зарубежную профессиональную литературу, нормативные документы, методологии, отраслевые исследования, описания угроз и практические материалы. Чем больше релевантной информации получает система, тем точнее становятся ее рекомендации. При последовательном обучении через год такой агент сможет превратиться в полноценного помощника для команды информационной безопасности. Он сможет обращаться в том числе к источникам, находящимся за пределами России, анализировать международные практики и сопоставлять их с задачами конкретного бизнеса. ИИ-агент способен помочь компании определить основные риски, понять, какой аудит необходимо провести, какие данные собрать и какой информации не хватает для принятия решений. Он также может использоваться при подготовке рекомендаций и формировании первоначальной карты информационной безопасности. При этом ИИ не должен работать бесконтрольно. Вместе с агентами компании необходимо внедрять системы проверки их действий, результатов и доступа к корпоративной информации. Одного универсального специалиста недостаточно: стратегия ИБ требует целой команды Второй путь — развитие собственной экспертизы. Это наиболее устойчивый, но одновременно самый дорогой вариант. Построить стратегию информационной безопасности силами одного универсального специалиста невозможно. Для полноценной оценки рисков нужны сотрудники с разными компетенциями: специалисты по ИТ и информационной безопасности, финансисты, представители бизнеса и другие эксперты. Каждый из них отвечает за отдельную часть задачи. Технические специалисты оценивают инфраструктуру и средства защиты. Финансисты помогают рассчитать возможный ущерб и стоимость мероприятий. Представители бизнеса определяют, какие процессы и данные действительно критичны для компании. Формирование полноценной стратегической карты может занимать не менее трех лет. После этого ее необходимо ежегодно пересматривать и актуализировать с учетом изменений бизнеса, инфраструктуры и угроз. Для компании это означает необходимость постоянно содержать команду специалистов либо заново привлекать экспертов при каждом обновлении стратегии. Поэтому собственная экспертиза дает бизнесу независимость, но требует долгосрочных инвестиций в найм, обучение и сохранение команды. Российские аудиторы остаются необходимы, хотя их опыт пока уступает международному Третий вариант — обращаться к компаниям, которые продолжают работать в России. У локальных аудиторов меньше международного опыта, готовых сценариев и накопленных отраслевых практик, чем было у крупнейших зарубежных компаний. Кроме того, на российском рынке пока не так много организаций, готовых заказывать комплексную разработку стратегии информационной безопасности: такие проекты стоят дорого и требуют участия руководства. Тем не менее полностью отказаться от внешней экспертизы бизнес не может. Независимые консультанты позволяют посмотреть на инфраструктуру и процессы со стороны, выявить риски, которые внутренняя команда может не замечать, и проверить обоснованность уже принятых решений. Российские аудиторы становятся важной частью системы, но их работа должна дополняться внутренней экспертизой компании и возможностями ИИ. Стратегия ИБ показывает не только как защищаться, но и сколько это будет стоить Стратегия информационной безопасности строится вокруг трех базовых принципов: целостности, доступности и достоверности информации. Ее задача — определить, в каких областях компания подвержена рискам и к каким последствиям они могут привести. Например, бизнесу необходимо обеспечить доступность стратегически важных документов. Но эта доступность может быть нарушена по разным причинам: из-за отключения электроэнергии, отказа сервера, действий злоумышленников или порчи документов сотрудником. Стратегия позволяет последовательно ответить на несколько вопросов: какие сценарии возможны, насколько они вероятны, какой ущерб могут причинить и какие меры помогут их предотвратить. На основе этого компания определяет, сколько денег необходимо потратить на минимизацию каждого риска. При этом стратегия не предполагает, что бизнес должен закрыть абсолютно все угрозы. Некоторые риски можно принять, если стоимость защиты окажется выше потенциального ущерба. Поэтому стратегия отвечает не только на вопрос, как закрыть риск, но и нужно ли вообще это делать. В отдельных случаях эффективнее не покупать дополнительную систему защиты, а пересмотреть сам бизнес-процесс. Бесплатное или корпоративное решение: выбор должен зависеть от задачи Стратегия также помогает определить, какие специалисты требуются компании и в каком количестве. Для минимизации каждого риска нужен свой набор компетенций, причем эти специалисты необязательно должны работать в штате. Одновременно бизнес решает, какие системы целесообразно разработать самостоятельно, а какие — приобрести у внешнего поставщика. Особенно активно сейчас обсуждается выбор между бесплатными решениями с открытым исходным кодом и платными корпоративными продуктами. Однако сама по себе стоимость лицензии не должна становиться главным аргументом. Решение необходимо выбирать исходя из задачи, масштаба внедрения, количества пользователей и условий эксплуатации. Бесплатный продукт может оказаться подходящим для одного сценария, но потребовать значительных затрат на настройку, поддержку и контроль в другом. Стратегия информационной безопасности позволяет связать технологический выбор с реальными потребностями бизнеса, а не с модой или формальным требованием внедрить определенный класс решений. Трехлетняя карта заранее показывает, что делать и какой бюджет закладывать Результатом стратегической работы становится дорожная карта. Она определяет, какие мероприятия компания должна выполнить в первый, второй и последующие годы. Благодаря этому бизнес может заранее распределить бюджет, запланировать внедрение систем, обучение сотрудников, аудит процессов и привлечение внешних специалистов. Такая карта не является неизменным документом. Если компания выходит в новый сегмент, запускает продукты, перестраивает инфраструктуру или меняет бизнес-модель, стратегию информационной безопасности необходимо актуализировать. Защита должна развиваться вместе с бизнесом. Иначе даже качественно подготовленный документ через несколько лет перестанет соответствовать реальным процессам и угрозам. В одиночку не сработает: российскому бизнесу придется объединить все три подхода В текущих условиях российским компаниям не стоит выбирать между собственной командой, ИИ и внешними аудиторами. Все три подхода необходимо использовать одновременно. Бизнесу нужно развивать внутреннюю экспертизу, инвестировать в обучение специалистов и сохранять целостность команды. Параллельно следует внедрять ИИ-агентов, обучать их на российских и зарубежных источниках и создавать механизмы контроля за их действиями. Кроме того, компаниям необходимо пользоваться услугами российских аудиторов, которые могут независимо оценить процессы, инфраструктуру и принятые решения. Отдельное внимание следует уделять системам, предотвращающим утечки персональных данных, поскольку развитие ИИ и расширение цифровой инфраструктуры создают дополнительные риски для корпоративной информации. Уход международных аудиторов лишил российский рынок части накопленной экспертизы, но не сделал построение зрелой системы информационной безопасности невозможным. Совмещение внутренней команды, внешнего аудита и возможностей ИИ позволяет создать стратегию, которая будет учитывать реальные бизнес-риски, доступные ресурсы и долгосрочные цели компании. #IMAGE_235383#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Зарубежные аудиторы ушли из&nbsp;России, но&nbsp;потребность в&nbsp;зрелой стратегии информационной безопасности никуда не&nbsp;исчезла. Теперь российским компаниям приходится одновременно развивать собственные команды, обращаться к&nbsp;локальным консультантам и&nbsp;превращать ИИ-агентов в&nbsp;персональных экспертов по&nbsp;кибербезопасности.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;После ухода из&nbsp;России крупнейших международных аудиторских компаний рынок информационной безопасности лишился не&nbsp;просто известных брендов. Вместе с&nbsp;ними ушел доступ к&nbsp;огромному массиву практического опыта, который формировался благодаря работе с&nbsp;компаниями из&nbsp;разных стран, отраслей и&nbsp;регуляторных сред.&lltt;/p&ggtt;
&lltt;p&ggtt;Российский рынок составляет около&nbsp;2% мирового рынка&nbsp;ИТ и&nbsp;информационной безопасности. Поэтому локальные специалисты и&nbsp;консультанты объективно работают с&nbsp;меньшим количеством сценариев, бизнес-моделей и&nbsp;инцидентов. Именно клиентское покрытие давало зарубежным аудиторам ключевое преимущество: они могли переносить в&nbsp;проекты процессы и&nbsp;подходы, проверенные на&nbsp;международном уровне.&lltt;/p&ggtt;
&lltt;p&ggtt;Рост доли России с&nbsp;2&nbsp;до&nbsp;4% мирового ИТ-рынка к&nbsp;2030 году можно рассматривать не&nbsp;как прогноз, а&nbsp;как ориентир для отрасли. Однако для такого роста недостаточно увеличивать число технологий и&nbsp;специалистов. Российскому бизнесу нужны зрелые процессы, в&nbsp;том числе в&nbsp;информационной безопасности. После ухода международных аудиторов готового доступа к&nbsp;таким практикам стало меньше, поэтому компаниям приходится фактически заново собирать эту экспертизу&nbsp;— внутри собственных команд, с&nbsp;помощью российских консультантов и&nbsp;ИИ-агентов.&lltt;/p&ggtt;
&lltt;p&ggtt;Сегодня перед российским средним и&nbsp;крупным бизнесом стоит сложный вопрос: откуда брать зрелую экспертизу и&nbsp;на&nbsp;чем строить стратегию информационной безопасности, если прежние источники знаний стали недоступны?&lltt;/p&ggtt;
&lltt;p&ggtt;Единственного решения здесь нет. Компании могут использовать три подхода&nbsp;— внедрять ИИ-агентов, развивать собственные команды и&nbsp;привлекать российских аудиторов. Но&nbsp;по-настоящему жизнеспособная стратегия возникает только тогда, когда бизнес совмещает все три направления.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ-агент может стать экспертом по&nbsp;кибербезопасности&nbsp;— но&nbsp;на&nbsp;его обучение потребуется время&lltt;/h3&ggtt;
&lltt;p&ggtt;Современный ИИ&nbsp;— это уже не&nbsp;просто приложение, в&nbsp;которое пользователь вводит запрос через браузер. Бизнес может приобрести специализированный сервис, подключенный через API&nbsp;к крупным языковым моделям и&nbsp;способный самостоятельно выбирать источники и&nbsp;инструменты для решения конкретной задачи.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;основе такой системы можно создать персонального ИИ-эксперта по&nbsp;информационной безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;Для этого агенту необходимо предоставить максимально полную базу знаний: российскую и&nbsp;зарубежную профессиональную литературу, нормативные документы, методологии, отраслевые исследования, описания угроз и&nbsp;практические материалы. Чем больше релевантной информации получает система, тем точнее становятся ее&nbsp;рекомендации.&lltt;/p&ggtt;
&lltt;p&ggtt;При последовательном обучении через год такой агент сможет превратиться в&nbsp;полноценного помощника для команды информационной безопасности. Он&nbsp;сможет обращаться в&nbsp;том числе к&nbsp;источникам, находящимся за&nbsp;пределами России, анализировать международные практики и&nbsp;сопоставлять их&nbsp;с&nbsp;задачами конкретного бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ-агент способен помочь компании определить основные риски, понять, какой аудит необходимо провести, какие данные собрать и&nbsp;какой информации не&nbsp;хватает для принятия решений. Он&nbsp;также может использоваться при подготовке рекомендаций и&nbsp;формировании первоначальной карты информационной безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом&nbsp;ИИ не&nbsp;должен работать бесконтрольно. Вместе с&nbsp;агентами компании необходимо внедрять системы проверки их&nbsp;действий, результатов и&nbsp;доступа к&nbsp;корпоративной информации.&lltt;/p&ggtt;
&lltt;h3&ggtt;Одного универсального специалиста недостаточно: стратегия&nbsp;ИБ требует целой команды&lltt;/h3&ggtt;
&lltt;p&ggtt;Второй путь&nbsp;— развитие собственной экспертизы. Это наиболее устойчивый, но&nbsp;одновременно самый дорогой вариант.&lltt;/p&ggtt;
&lltt;p&ggtt;Построить стратегию информационной безопасности силами одного универсального специалиста невозможно. Для полноценной оценки рисков нужны сотрудники с&nbsp;разными компетенциями: специалисты по&nbsp;ИТ и&nbsp;информационной безопасности, финансисты, представители бизнеса и&nbsp;другие эксперты.&lltt;/p&ggtt;
&lltt;p&ggtt;Каждый из&nbsp;них отвечает за&nbsp;отдельную часть задачи. Технические специалисты оценивают инфраструктуру и&nbsp;средства защиты. Финансисты помогают рассчитать возможный ущерб и&nbsp;стоимость мероприятий. Представители бизнеса определяют, какие процессы и&nbsp;данные действительно критичны для компании.&lltt;/p&ggtt;
&lltt;p&ggtt;Формирование полноценной стратегической карты может занимать не&nbsp;менее трех лет. После этого ее&nbsp;необходимо ежегодно пересматривать и&nbsp;актуализировать с&nbsp;учетом изменений бизнеса, инфраструктуры и&nbsp;угроз.&lltt;/p&ggtt;
&lltt;p&ggtt;Для компании это означает необходимость постоянно содержать команду специалистов либо заново привлекать экспертов при каждом обновлении стратегии. Поэтому собственная экспертиза дает бизнесу независимость, но&nbsp;требует долгосрочных инвестиций в&nbsp;найм, обучение и&nbsp;сохранение команды.&lltt;/p&ggtt;
&lltt;h3&ggtt;Российские аудиторы остаются необходимы, хотя их&nbsp;опыт пока уступает международному&lltt;/h3&ggtt;
&lltt;p&ggtt;Третий вариант&nbsp;— обращаться к&nbsp;компаниям, которые продолжают работать в&nbsp;России.&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;локальных аудиторов меньше международного опыта, готовых сценариев и&nbsp;накопленных отраслевых практик, чем было у&nbsp;крупнейших зарубежных компаний. Кроме того, на&nbsp;российском рынке пока не&nbsp;так много организаций, готовых заказывать комплексную разработку стратегии информационной безопасности: такие проекты стоят дорого и&nbsp;требуют участия руководства.&lltt;/p&ggtt;
&lltt;p&ggtt;Тем не&nbsp;менее полностью отказаться от&nbsp;внешней экспертизы бизнес не&nbsp;может. Независимые консультанты позволяют посмотреть на&nbsp;инфраструктуру и&nbsp;процессы со&nbsp;стороны, выявить риски, которые внутренняя команда может не&nbsp;замечать, и&nbsp;проверить обоснованность уже принятых решений.&lltt;/p&ggtt;
&lltt;p&ggtt;Российские аудиторы становятся важной частью системы, но&nbsp;их&nbsp;работа должна дополняться внутренней экспертизой компании и&nbsp;возможностями ИИ.&lltt;/p&ggtt;
&lltt;h3&ggtt;Стратегия ИБ&nbsp;показывает не&nbsp;только как защищаться, но&nbsp;и&nbsp;сколько это будет стоить&lltt;/h3&ggtt;
&lltt;p&ggtt;Стратегия информационной безопасности строится вокруг трех базовых принципов: целостности, доступности и&nbsp;достоверности информации.&lltt;/p&ggtt;
&lltt;p&ggtt;Ее&nbsp;задача&nbsp;— определить, в&nbsp;каких областях компания подвержена рискам и&nbsp;к&nbsp;каким последствиям они могут привести.&lltt;/p&ggtt;
&lltt;p&ggtt;Например, бизнесу необходимо обеспечить доступность стратегически важных документов. Но&nbsp;эта доступность может быть нарушена по&nbsp;разным причинам: из-за отключения электроэнергии, отказа сервера, действий злоумышленников или порчи документов сотрудником.&lltt;/p&ggtt;
&lltt;p&ggtt;Стратегия позволяет последовательно ответить на&nbsp;несколько вопросов: какие сценарии возможны, насколько они вероятны, какой ущерб могут причинить и&nbsp;какие меры помогут их&nbsp;предотвратить.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;основе этого компания определяет, сколько денег необходимо потратить на&nbsp;минимизацию каждого риска. При этом стратегия не&nbsp;предполагает, что бизнес должен закрыть абсолютно все угрозы. Некоторые риски можно принять, если стоимость защиты окажется выше потенциального ущерба.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому стратегия отвечает не&nbsp;только на&nbsp;вопрос, как закрыть риск, но&nbsp;и&nbsp;нужно&nbsp;ли вообще это делать. В&nbsp;отдельных случаях эффективнее не&nbsp;покупать дополнительную систему защиты, а&nbsp;пересмотреть сам бизнес-процесс.&lltt;/p&ggtt;
&lltt;h3&ggtt;Бесплатное или корпоративное решение: выбор должен зависеть от&nbsp;задачи&lltt;/h3&ggtt;
&lltt;p&ggtt;Стратегия также помогает определить, какие специалисты требуются компании и&nbsp;в&nbsp;каком количестве. Для минимизации каждого риска нужен свой набор компетенций, причем эти специалисты необязательно должны работать в&nbsp;штате.&lltt;/p&ggtt;
&lltt;p&ggtt;Одновременно бизнес решает, какие системы целесообразно разработать самостоятельно, а&nbsp;какие&nbsp;— приобрести у&nbsp;внешнего поставщика.&lltt;/p&ggtt;
&lltt;p&ggtt;Особенно активно сейчас обсуждается выбор между бесплатными решениями с&nbsp;открытым исходным кодом и&nbsp;платными корпоративными продуктами. Однако сама по&nbsp;себе стоимость лицензии не&nbsp;должна становиться главным аргументом.&lltt;/p&ggtt;
&lltt;p&ggtt;Решение необходимо выбирать исходя из&nbsp;задачи, масштаба внедрения, количества пользователей и&nbsp;условий эксплуатации. Бесплатный продукт может оказаться подходящим для одного сценария, но&nbsp;потребовать значительных затрат на&nbsp;настройку, поддержку и&nbsp;контроль в&nbsp;другом.&lltt;/p&ggtt;
&lltt;p&ggtt;Стратегия информационной безопасности позволяет связать технологический выбор с&nbsp;реальными потребностями бизнеса, а&nbsp;не&nbsp;с&nbsp;модой или формальным требованием внедрить определенный класс решений.&lltt;/p&ggtt;
&lltt;h3&ggtt;Трехлетняя карта заранее показывает, что делать и&nbsp;какой бюджет закладывать&lltt;/h3&ggtt;
&lltt;p&ggtt;Результатом стратегической работы становится дорожная карта. Она определяет, какие мероприятия компания должна выполнить в&nbsp;первый, второй и&nbsp;последующие годы.&lltt;/p&ggtt;
&lltt;p&ggtt;Благодаря этому бизнес может заранее распределить бюджет, запланировать внедрение систем, обучение сотрудников, аудит процессов и&nbsp;привлечение внешних специалистов.&lltt;/p&ggtt;
&lltt;p&ggtt;Такая карта не&nbsp;является неизменным документом. Если компания выходит в&nbsp;новый сегмент, запускает продукты, перестраивает инфраструктуру или меняет бизнес-модель, стратегию информационной безопасности необходимо актуализировать.&lltt;/p&ggtt;
&lltt;p&ggtt;Защита должна развиваться вместе с&nbsp;бизнесом. Иначе даже качественно подготовленный документ через несколько лет перестанет соответствовать реальным процессам и&nbsp;угрозам.&lltt;/p&ggtt;
&lltt;h3&ggtt;В&nbsp;одиночку не&nbsp;сработает: российскому бизнесу придется объединить все три подхода&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;текущих условиях российским компаниям не&nbsp;стоит выбирать между собственной командой, ИИ&nbsp;и&nbsp;внешними аудиторами. Все три подхода необходимо использовать одновременно.&lltt;/p&ggtt;
&lltt;p&ggtt;Бизнесу нужно развивать внутреннюю экспертизу, инвестировать в&nbsp;обучение специалистов и&nbsp;сохранять целостность команды. Параллельно следует внедрять ИИ-агентов, обучать их&nbsp;на&nbsp;российских и&nbsp;зарубежных источниках и&nbsp;создавать механизмы контроля за&nbsp;их&nbsp;действиями.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме того, компаниям необходимо пользоваться услугами российских аудиторов, которые могут независимо оценить процессы, инфраструктуру и&nbsp;принятые решения.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельное внимание следует уделять системам, предотвращающим утечки персональных данных, поскольку развитие&nbsp;ИИ и&nbsp;расширение цифровой инфраструктуры создают дополнительные риски для корпоративной информации.&lltt;/p&ggtt;
&lltt;p&ggtt;Уход международных аудиторов лишил российский рынок части накопленной экспертизы, но&nbsp;не&nbsp;сделал построение зрелой системы информационной безопасности невозможным. Совмещение внутренней команды, внешнего аудита и&nbsp;возможностей&nbsp;ИИ позволяет создать стратегию, которая будет учитывать реальные бизнес-риски, доступные ресурсы и&nbsp;долгосрочные цели компании.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235383#&lltt;/p&ggtt;]]></source>
<adate>21.08.2026</adate>
<dbid>235382</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/fd3/9k6b65t29wg277p9c05jml4lc3vnytfq.jpg]]>
</images>
<imagesname><![CDATA[;;Сергей Крюков, генеральный директор exploitDog (НИР)   ]]></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[MIT: агентный ИИ потерпит неудачу без прочного фундамента данных]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235384]]></link>
<description><![CDATA[Новое исследование «Scaling AI agents with trustworthy data» от MIT Technology Review и Google Cloud подтверждает, что эффективное внедрение искусственного интеллекта начинается с надежного фундамента данных и современных методов управления данными. Отчет основан на опросе 300 директоров по данным и аналитике, CIO, CTO, директоров по ИИ, а также руководителей отделов продуктов, ИТ, данных и ИИ в различных отраслях. #IMAGE_235385# Основные выводы из исследования: 	Большинство организаций (83%) сообщили об использовании агентного ИИ, при этом 73% используют его для ограниченного числа сценариев. Только каждая десятая организация использует его широко. 	 Хотя 100% респондентов заявили, что планируют использовать агентный ИИ в течение следующих двух лет, только около половины респондентов доверяют точности и релевантности результатов работы агентов ИИ. 	 Исследование также показало, что в среднем инструментам агентного ИИ доступны около 45% данных компании, при этом избранная группа респондентов, называемая «лидерами в области данных», предоставляет ИИ доступ к более чем 70% своих данных. Другие сообщают о предоставлении доступа к 30% или менее своих данных. 	 В отчете успех и доверие лидеров в области данных к агентному ИИ объясняются прочным фундаментом данных, в то время как другие организации сообщают о проблемах, связанных с устаревшими системами. «Мы должны предоставлять агентам доступ к данным безопасным и надежным способом, чтобы люди могли максимально эффективно использовать данные, зная, что они полностью надежны», — считает Раджприт Баджва, вице-президент Shopify по инженерии и инфраструктуре данных. В отчете упоминается группа компаний, которую называют «лидерами в области данных». Эти компании сообщают о большем успехе в использовании агентного ИИ и меньшем количестве ограничений данных со стороны устаревших систем. Хотя только около 50% респондентов доверяют своим агентам ИИ, 100% лидеров в области данных сообщили о доверии к точности и решениям своих агентов ИИ. В отчете говорится, что это «сильный показатель того, что надежный ИИ требует надежного фундамента данных». За пределами группы лидеров в области данных 66% респондентов заявили, что устаревшие системы ограничивают их возможности масштабирования агентного ИИ, а 68% заявили, что устаревшие системы замедляют скорость работы агентов. Среди других проблем — недостаток контекста и унификации данных (40% респондентов опроса Teradata/Wakefield «Why Agentic AI Stalls Enterprise» сообщили об тех же проблемах, несмотря на наличие надежных моделей ИИ). «Организации стремительно переходят к операционной модели, в основе которой лежит ИИ. Теперь ИИ учитывается при принятии каждого бизнес-решения, в каждом рабочем процессе и при любых инвестициях. Без четкой приверженности ИИ на уровне всего предприятия организациям будет сложно в полной мере реализовать его потенциал в масштабе предприятия», — говорит Карли Идоин, вице-президент-аналитик Gartner]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Новое исследование «&lltt;/em&ggtt;&lltt;em&ggtt;Scaling&lltt;/em&ggtt; &lltt;em&ggtt;AI&lltt;/em&ggtt;&nbsp;&lltt;em&ggtt;agents&lltt;/em&ggtt; &lltt;em&ggtt;with&lltt;/em&ggtt; &lltt;em&ggtt;trustworthy&lltt;/em&ggtt; &lltt;em&ggtt;data&lltt;/em&ggtt;&lltt;em&ggtt;» от&nbsp;MIT Technology Review и&nbsp;Google Cloud подтверждает, что эффективное внедрение искусственного интеллекта начинается с&nbsp;надежного фундамента данных и&nbsp;современных методов управления данными.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Отчет основан на&nbsp;опросе 300 директоров по&nbsp;данным и&nbsp;аналитике, CIO, CTO, директоров по&nbsp;ИИ, а&nbsp;также руководителей отделов продуктов, ИТ, данных и&nbsp;ИИ в&nbsp;различных отраслях.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235385#&lltt;/p&ggtt;
&lltt;p&ggtt;Основные выводы из&nbsp;исследования:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;Большинство организаций (83%) сообщили об&nbsp;использовании агентного&nbsp;ИИ, при этом&nbsp;73% используют его для ограниченного числа сценариев. Только каждая десятая организация использует его широко.&lltt;/li&ggtt;
	&lltt;li&ggtt; Хотя 100% респондентов заявили, что планируют использовать агентный&nbsp;ИИ в&nbsp;течение следующих двух лет, только около половины респондентов доверяют точности и&nbsp;релевантности результатов работы агентов ИИ.&lltt;/li&ggtt;
	&lltt;li&ggtt; Исследование также показало, что в&nbsp;среднем инструментам агентного&nbsp;ИИ доступны около&nbsp;45% данных компании, при этом избранная группа респондентов, называемая «лидерами в&nbsp;области данных», предоставляет&nbsp;ИИ доступ к&nbsp;более чем&nbsp;70% своих данных. Другие сообщают о&nbsp;предоставлении доступа к&nbsp;30% или менее своих данных.&lltt;/li&ggtt;
	&lltt;li&ggtt; В&nbsp;отчете успех и&nbsp;доверие лидеров в&nbsp;области данных к&nbsp;агентному&nbsp;ИИ объясняются прочным фундаментом данных, в&nbsp;то&nbsp;время как другие организации сообщают о&nbsp;проблемах, связанных с&nbsp;устаревшими системами.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;«Мы&nbsp;должны предоставлять агентам доступ к&nbsp;данным безопасным и&nbsp;надежным способом, чтобы люди могли максимально эффективно использовать данные, зная, что они полностью надежны»,&nbsp;— считает Раджприт Баджва, вице-президент Shopify по&nbsp;инженерии и&nbsp;инфраструктуре данных.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;отчете упоминается группа компаний, которую называют «лидерами в&nbsp;области данных». Эти компании сообщают о&nbsp;большем успехе в&nbsp;использовании агентного&nbsp;ИИ и&nbsp;меньшем количестве ограничений данных со&nbsp;стороны устаревших систем. Хотя только около&nbsp;50% респондентов доверяют своим агентам ИИ, 100% лидеров в&nbsp;области данных сообщили о&nbsp;доверии к&nbsp;точности и&nbsp;решениям своих агентов ИИ. В&nbsp;отчете говорится, что это «сильный показатель того, что надежный&nbsp;ИИ требует надежного фундамента данных».&lltt;/p&ggtt;
&lltt;p&ggtt;За&nbsp;пределами группы лидеров в&nbsp;области данных&nbsp;66% респондентов заявили, что устаревшие системы ограничивают их&nbsp;возможности масштабирования агентного&nbsp;ИИ, а&nbsp;68% заявили, что устаревшие системы замедляют скорость работы агентов. Среди других проблем&nbsp;— недостаток контекста и&nbsp;унификации данных (40% респондентов опроса Teradata/Wakefield «Why Agentic AI&nbsp;Stalls Enterprise» сообщили об&nbsp;тех&nbsp;же проблемах, несмотря на&nbsp;наличие надежных моделей ИИ).&lltt;/p&ggtt;
&lltt;p&ggtt;«Организации стремительно переходят к&nbsp;операционной модели, в&nbsp;основе которой лежит ИИ. Теперь ИИ&nbsp;учитывается при принятии каждого бизнес-решения, в&nbsp;каждом рабочем процессе и&nbsp;при любых инвестициях. Без четкой приверженности&nbsp;ИИ на&nbsp;уровне всего предприятия организациям будет сложно в&nbsp;полной мере реализовать его потенциал в&nbsp;масштабе предприятия»,&nbsp;— говорит Карли Идоин, вице-президент-аналитик Gartner.&lltt;/p&ggtt;]]></source>
<adate>21.08.2026</adate>
<dbid>235384</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/964/2762o9gqugl9w9r9fy1l1g20o0oxkn5k.jpg]]>
</images>
<imagesname><![CDATA[;;MIT: агентный ИИ потерпит неудачу без прочного фундамента данных   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[M1Cloud: от генеративного к агентному ИИ — смена архитектуры облачной инфраструктуры в 2026 году]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235386]]></link>
<description><![CDATA[В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов. Рынок совершает переход от систем, которые отвечают на запросы, к системам, которые действуют самостоятельно — от генеративного к агентному ИИ. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, как трансформируется облачная инфраструктура для использования ИИ-агентов. Глобальный рынок агентного ИИ, по оценкам Stratistics MRC, в этом году достигнет $10,3 млрд и будет расти до $207,6 млрд к 2034 году при среднегодовом темпе роста 45,6%. По данным PwC, 88% руководителей планируют увеличить бюджеты на ИИ именно ради агентных сценариев, а Gartner прогнозирует, что к концу 2026 года 40% корпоративных приложений будут оснащены специализированными ИИ-агентами (против менее 5% в 2025 году). Агентный ИИ — это принципиально иная парадигма. Автономные агенты планируют действия, обращаются к корпоративным API, делегируют задачи другим ИИ-системам и выполняют многошаговые сценарии с минимальным участием человека. Человек смещается из позиции исполнителя в позицию супервайзера. За взрывным ростом внедрения ИИ-агентов скрывается фундаментальная проблема: корпоративная инфраструктура к этому не готова. По данным Google Cloud, 83% организаций заявляют о необходимости срочной модернизации мощностей для поддержки промышленного агентного ИИ. Запрос, который раньше генерировал один ответ, теперь запускает каскад из сотен действий. В отличие от пакетной обработки — чтение баз данных, межсервисное взаимодействие, координацию агентов. Каждое действие потребляет токены, генерирует сетевой трафик и требует ресурсов для логирования. Агентам нужна память о контексте и прогрессе. Каждый лишний шаг в цепочке вызовов умножает задержку, что требует от провайдера высочайшей скорости интерконнекта и оптимизированных сетей. Возникает феномен «инференс-налога» (inference tax) — скрытых затрат на вывод данных и разрастание хранилищ, с которыми уже столкнулись 62% технических руководителей (по данным Google Cloud). Российский рынок следует глобальному тренду, но со своей спецификой. Совместное исследование Apple Hills Digital, VK Tech, Cloud.ru и Selectel показывает, что 46% отечественных компаний уже используют или тестируют ИИ в облаке, а 27% клиентов провайдеров уже применяют облачных ИИ-агентов. Бюджеты на ИИ увеличили 35% компаний, опередив по темпам роста даже кибербезопасность. Если при классическом обучении моделей затраты относительно предсказуемы, то агентный ИИ генерирует расходы экспоненциально. Без автоматического мониторинга и управления каскадными вызовами компании рискуют столкнуться с тем, что до трети (а в случае с агентами — и больше) облачного бюджета будет сожжено впустую на неоптимальные маршруты агентов и простаивающие stateful-контейнеры. В новых реалиях облачный провайдер перестает быть просто поставщиком вычислительных мощностей и становится стратегическим партнером. Только облако способно обеспечить экономически обоснованную эластичность под непредсказуемые пиковые нагрузки агентных систем, избавляя бизнес от необходимости покупать дорогостоящее железо, которое устаревает за полтора года. Помимо этого, облако становится единой платформой для управления и безопасности: когда сотни автономных агентов получают доступ к корпоративным данным, централизованный аудит, управление правами и MLOps. Зрелый провайдер берет на себя роль FinOps-консультанта, помогая оптимизировать «инференс-налог»: распределяя нагрузку между CPU (для оркестрации), GPU (для тяжелого инференса) и специализированными ускорителями, а также настраивая автоматическое масштабирование stateful-сред]]></description>
<source><![CDATA[&lltt;p&ggtt;В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов. Рынок совершает переход от систем, которые отвечают на запросы, к системам, которые действуют самостоятельно — от генеративного к агентному ИИ. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, как трансформируется облачная инфраструктура для использования ИИ-агентов.&lltt;/p&ggtt;
&lltt;p&ggtt;Глобальный рынок агентного ИИ, по оценкам Stratistics MRC, в этом году достигнет $10,3 млрд и будет расти до $207,6 млрд к 2034 году при среднегодовом темпе роста 45,6%. По данным PwC, 88% руководителей планируют увеличить бюджеты на ИИ именно ради агентных сценариев, а Gartner прогнозирует, что к концу 2026 года 40% корпоративных приложений будут оснащены специализированными ИИ-агентами (против менее 5% в 2025 году). Агентный ИИ — это принципиально иная парадигма. Автономные агенты планируют действия, обращаются к корпоративным API, делегируют задачи другим ИИ-системам и выполняют многошаговые сценарии с минимальным участием человека. Человек смещается из позиции исполнителя в позицию супервайзера.&lltt;/p&ggtt;
&lltt;p&ggtt;За взрывным ростом внедрения ИИ-агентов скрывается фундаментальная проблема: корпоративная инфраструктура к этому не готова. По данным Google Cloud, 83% организаций заявляют о необходимости срочной модернизации мощностей для поддержки промышленного агентного ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Запрос, который раньше генерировал один ответ, теперь запускает каскад из сотен действий. В отличие от пакетной обработки — чтение баз данных, межсервисное взаимодействие, координацию агентов. Каждое действие потребляет токены, генерирует сетевой трафик и требует ресурсов для логирования. Агентам нужна память о контексте и прогрессе. Каждый лишний шаг в цепочке вызовов умножает задержку, что требует от провайдера высочайшей скорости интерконнекта и оптимизированных сетей. Возникает феномен «инференс-налога» (inference tax) — скрытых затрат на вывод данных и разрастание хранилищ, с которыми уже столкнулись 62% технических руководителей (по данным Google Cloud).&lltt;/p&ggtt;
&lltt;p&ggtt;Российский рынок следует глобальному тренду, но со своей спецификой. Совместное исследование Apple Hills Digital, VK Tech, Cloud.ru и Selectel показывает, что 46% отечественных компаний уже используют или тестируют ИИ в облаке, а 27% клиентов провайдеров уже применяют облачных ИИ-агентов. Бюджеты на ИИ увеличили 35% компаний, опередив по темпам роста даже кибербезопасность. Если при классическом обучении моделей затраты относительно предсказуемы, то агентный ИИ генерирует расходы экспоненциально. Без автоматического мониторинга и управления каскадными вызовами компании рискуют столкнуться с тем, что до трети (а в случае с агентами — и больше) облачного бюджета будет сожжено впустую на неоптимальные маршруты агентов и простаивающие stateful-контейнеры.&lltt;/p&ggtt;
&lltt;p&ggtt;В новых реалиях облачный провайдер перестает быть просто поставщиком вычислительных мощностей и становится стратегическим партнером. Только облако способно обеспечить экономически обоснованную эластичность под непредсказуемые пиковые нагрузки агентных систем, избавляя бизнес от необходимости покупать дорогостоящее железо, которое устаревает за полтора года. Помимо этого, облако становится единой платформой для управления и безопасности: когда сотни автономных агентов получают доступ к корпоративным данным, централизованный аудит, управление правами и MLOps. Зрелый провайдер берет на себя роль FinOps-консультанта, помогая оптимизировать «инференс-налог»: распределяя нагрузку между CPU (для оркестрации), GPU (для тяжелого инференса) и специализированными ускорителями, а также настраивая автоматическое масштабирование stateful-сред.&lltt;/p&ggtt;]]></source>
<adate>20.08.2026</adate>
<dbid>235386</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[В заложниках у модных трендов: как микросервисы увеличивают время выхода продукта на рынок и порождают вечный технический долг]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235380]]></link>
<description><![CDATA[Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и скорость. Сначала — через сервис-ориентированную архитектуру (SOA), затем — через «серебряную пулю» микросервисов. Это обещание звучало заманчиво: распилите монолит на крошечные независимые сервисы, общающиеся по вебу, и вы будете выкатывать функционал бизнесу за пару дней силами изолированных команд. Маркетинговый хайп победил инженерный рассудок. Сегодня за ширмой «современного стека» скрывается суровая реальность: тотальный паралич Time-To-Market (TTM), астрономический технический долг и кратные финансовые потери. Архитектурные заблуждения и подмена понятий: ООП наизнанку В чём фундаментальный просчет концепции микросервисов в их массовом исполнении? В том, что базовые принципы проектирования программного обеспечения — инкапсуляцию, слабую связность и объектно-ориентированный подход — попытались насильно перенести на уровень сети. Архитекторы «новой волны» решили, что микросервис — это изолированный объект, а сетевой HTTP/REST-запрос — это просто вызов метода. Индустрия проигнорировала законы физики. Если вызов метода в едином адресном пространстве оперативной памяти (In-Memory Call) занимает наносекунды и абсолютно надежен, то сетевой вызов между мелкогранулированными компонентами занимает уже миллисекунды. А сама сеть к тому же по определению ненадежна. Ирония судьбы — в том, что в эпоху расцвета классической SOA те же промышленные платформы, от enterprise-решений ведущих вендоров до систем с открытым исходным кодом на .NET, Java или Python, технически предоставляли абсолютно те же преимущества, которые сегодня приписывают исключительно микросервисам. Архитектурные возможности изначально позволяли объединить отдельные прикладные компоненты и интеграционные адаптеры в изолированные крупногранулированные сервисы в соответствии с границами доменной области. Внутри этого домена компоненты взаимодействовали в едином адресном пространстве оперативной памяти (In-Memory), а платформы великолепно масштабировались горизонтально за счет логических экземпляров среды выполнения в составе одной или нескольких операционных систем. В какой-то момент в индустрии перестали соблюдать базовые принципы SOA-архитектуры, забыв, что микросервисы — это не более чем подмножество SOA. Вместо того чтобы наводить порядок в границах доменной области, разработчики объявили проверенные подходы «тяжелыми» и ушли в микросервисный веб. Они упустили из виду, что этот самый веб — про переносимость, и вся его прелесть проявляется тогда, когда речь идет об интеграции разнородных систем, развернутых на принципиально разных платформах, когда речь идет об интероперабельности. Физическая изоляция (сеть и контейнеризация) стала защитой от низкой культуры и дисциплины разработки. Если вы не умеете инкапсулировать код в логические модули, сеть заставит вас сделать это силой. Но цена такого принуждения оказалась непомерной для бизнеса. Подмена понятий: из песочницы разработки в промышленную эксплуатацию Чтобы понять, как мы оказались в этой точке, нужно вспомнить историю развития технологий разработки. Весь этот технологический стек — контейнеризация, платформы оркестрации и автоматизированные CI/CD-пайплайны — изначально задумывался исключительно как инструментарий для высвобождения рабочего времени разработчика. В частности, изоляция сред в контейнерах была введена в процесс разработки как ответ на вечное проклятие: «на моей машине всё работало». Она была нужна, чтобы программист мог мгновенно развернуть готовое локальное окружение. Платформы оркестрации контейнеров создавались в недрах технологических гигантов для утилизации пустующих серверов дата-центров и быстрой подготовки эфемерных тестовых сред под нужды команд автоматизации. Эти инструменты создавались для «песочниц», прототипирования и автоматизации рутины. Никто не проектировал их под высоконагруженные транзакционные контуры, требующие промышленной надежности. Трагедия современной ИТ-индустрии в том, что инструмент быстрой лепки временных сред ошибочно приняли за стандарт. Архитекторы перенесли логику «песочницы» на боевые контуры транзакционных систем финансового и промышленного секторов. В результате бизнес получил хрупкую распределенную систему, где стабильность решения принесена в жертву сиюминутному удобству локального написания кода. Великое заблуждение: архитектура системного ПО в транзакционном бизнесе Микросервисная архитектура родилась не на предприятиях непрерывного цикла и не в банках с их высокоинтенсивными рабочими нагрузками. Она появилась в недрах цифровых гигантов (Netflix, Amazon, SoundCloud), у которых вообще не было чужих систем и разных поставщиков. Они контролировали 100% своего стека и писали всё с нуля. В этих условиях все сервисы изначально взаимодействовали на одном «языке» (JSON/REST), и трансформировать форматы данных было просто не нужно. Внедрение сложных интеграционных шин в такую однородную среду принесло бы только лишние накладные расходы. Но главное — характер их работы. Микросервисы в их каноническом виде — это архитектура уровня системного ПО управления ресурсами. Условная транзакция в облачном провайдере или стриминговом сервисе запускает длительный, асинхронный процесс. Например, развертывание виртуальной машины из ISO-образа. Этот процесс занимает десятки секунд или минуты. Пользователь готов ждать. На этом фоне 10 миллисекунд сетевых задержек, возникающих при взаимодействии между мелкогранулированными системными сервисами (один выделяет диск, другой вешает IP), — это не более чем математическая погрешность. Там действительно не нужна интеграционная транзакционная «молотилка». Но когда, например, в вакансиях «инновационного финтеха» для Core-системы со строгой OLTP-нагрузкой фигурируют микросервисы и оркестраторы — это признак тотального непонимания физики процессов. Финтех-операция должна выполняться синхронно, атомарно и за миллисекунды. И здесь 15 миллисекунд сетевых издержек на каждый шаг цепочки (запрос в сервис баланса, запрос в антифрод, запрос в лимиты) — это архитектурный приговор. Система тратит время не на полезную работу (изменение пары байт в СУБД), а на ожидание ответов по сети, обработку HTTP-заголовков и обеспечение консистентности данных (Eventual Consistency), которая в транзакционных системах недопустима по определению. Иллюзия Time-To-Market: быстро на старте, паралич на финише Главный аргумент в пользу микросервисов — это ускорение TTM. И на этапе разработки системы с нуля эта иллюзия действительно работает. Написать один мелкий сервис, который выполняет одну конкретную функцию, можно за пару дней. Руководство и бизнес-заказчик аплодируют стоя. Проблемы начинаются, когда система разрастается до сотен мелкогранулированных ИТ-сервисов, общающихся преимущественно по Web/HTTP. Бизнес же мыслит сквозными ценностями, а не микрофункциями. И когда для реализации одной новой бизнес-функциональности (например, внедрения нового типа лояльности) требуется одновременно изменить контракты в 5-7 разных микросервисах, начинается ад: 	 Паралич взаимодействия команд: нужно согласовать изменения API с пятью независимыми командами. Продуктовый TTM падает до нуля, утопая в бесконечных созвонах, а также в согласованиях контрактов в спецификациях и задачах. 	Интеграционный тупик: вместо релиза одной кнопкой компания получает сложнейшие распределенные релизные циклы. Архитектура превращается в распределенный монолит — худшее из обоих миров, выпуск релиза которого происходит дольше и болезненнее, чем в крупногранулированной SOA-архитектуре двадцать лет назад. Облачный грабеж и трехкратный «инфраструктурный налог» Когда ИТ-директора обосновывали переход на микросервисы, главным экономическим аргументом был отказ от «вендорской иглы» — коммерческих лицензий за процессорные ядра или вычислительные узлы, выделенные под прикладное решение. Обещание звучало как финансовое освобождение: «Мы уйдем на свободное программное обеспечение (Open Source), перенесем всё в облако и будем платить только за реальное потребление». Но на серьезных нагрузках микросервисная архитектура дает 2-3-кратный рост расходов бюджета. Этот «финансовый пылесос» состоит из трех главных составляющих: 	 Память и процессоры. В микросервисах каждому крошечному сервису нужно выделить сотни мегабайт оперативной памяти просто на прогрев его собственного изолированного окружения. Транзакция превращается в каскад из 10-15 сетевых вызовов, где до 40-60% мощности процессора тратится на постоянную сериализацию и десериализацию JSON, шифрование TLS и перекладывание байтов по сетевым стекам. Чтобы переварить ту же нагрузку, приходится покупать в 2,5 раза больше вычислительных ядер (vCPU). Умножьте это на сотни сервисов и на зоны доступности. Как итог: бизнес платит за гигабайты памяти и процессорное время, которые вообще не используются для выполнения прикладной логики. В то же время транзакция в крупногранулированном сервисе — это просто передача ссылки на объект в памяти, не требующая выделения дополнительной памяти и процессорного времени на сериализацию и десериализацию. 	 Скрытый «убийца» — сетевой трафик. Чтобы обеспечить высокую доступность, экземпляры микросервисов размазываются по разным дата-центрам (зонам доступности). Облачные провайдеры жестко тарифицируют каждый гигабайт трафика между зонами доступности (Inter-AZ). В рамках единого крупногранулированного сервиса этот трафик был бесплатным (внутри хоста); в микросервисах счета за внутриоблачную сеть часто превышают стоимость самих процессоров. 	 Инфраструктурные надстройки как величайший обман. Пытаясь уйти от концепции интеграционных шин, ИТ-архитекторы заявили, что связь теперь «бесплатная». Но когда сетью стало невозможно управлять, индустрия придумала концепцию Service Mesh. Вместо одной центральной шины компания получила тысячи микрошин в виде прокси-приложений (sidecar) для каждого контейнера. Эксплуатация таких решений в крупных проектах показывает, что эти прокси съедают от 20 до 50% всей оперативной памяти и до 30% CPU всего вычислительного кластера. Бизнес просто перенаправил миллионы из одного кармана в другой — в пользу облачных провайдеров. Практика против моды: опыт технологических лидеров Для тех, кто считает эти расчеты «теоретическим ретроградством», индустрия приготовила серию сокрушительных прецедентов от компаний, чьи масштабы нагрузок не подлежат сомнению. Amazon Prime Video: отрезвление изнутри Самый громкий удар по микросервисной религии нанесла сама компания Amazon — создатель главной облачной инфраструктуры планеты. Инженеры команды Amazon Prime Video, спроектировав распределенную систему мониторинга качества видеопотоков по «модному учебнику», столкнулись с финансовой катастрофой при попытке масштабирования. Изначальная архитектура опиралась на оркестрацию через AWS Step Functions и бессерверные вычисления AWS Lambda. Архитектурный просчет заключался в том, что компоненты пайплайна (медиаконвертер и детектор дефектов) обменивались терабайтами тяжелых сырых видеокадров, постоянно сохраняя и скачивая их через промежуточное дисковое хранилище Amazon S3. В результате система уперлась в потолок производительности всего на 5% от целевой мощности: компания моментально уперлась в лимиты AWS Step Functions по количеству переходов между состояниями (state transitions) в секунду, а счета за Tier-1 API-запросы к S3 и сетевую сериализацию кратно превысили стоимость самого компюта. Инженеры Amazon полностью переписали архитектуру, объединив все три распределенных компонента в единое монолитное приложение, развернутое в контейнерах Amazon ECS. Вместо пересылки тяжелых фреймов по сети через S3, этапы конвейера стали обмениваться данными напрямую в оперативной памяти (In-Memory) в рамках одного процесса. Результат: затраты на инфраструктуру снизились на 90%, а ограничения масштабируемости исчезли. Shopify: битва за скорость «выкатки фич» Гигант мировой интернет-торговли Shopify, обрабатывающий миллионы транзакций, вовремя остановил тотальное дробление систем. Архитекторы обнаружили, что мелкогранулированность и распределенность разрушили границы контекстов, вызвав тяжелейший межкомандный паралич: для банального изменения логики скидок или корзины приходилось синхронно переписывать контракты API в шести независимых командах и репозиториях. Shopify официально провозгласил верность концепции «Маджестик Монолита» (Majestic Monolith), но вместо хаотичного «комка грязи» они планомерно реорганизуют кодовую базу в строго изолированный «Модульный монолит» (Modular Monolith). Используя разработанный ими инструмент статического анализа Packwerk (в связке с софтверными контрактами Sorbet), компания жестко контролирует границы бизнес-доменов на уровне абстракции кода. Все модули находятся в едином репозитории и разворачиваются вместе, что избавляет инженеров от сетевой бюрократии, сохраняет строгую ACID-консистентность базы данных, но при этом изолирует зоны ответственности команд и сокращает TTM в разы. Segment (Twilio): тупик мелкозернистой изоляции Платформа сбора данных Segment изначально создала отдельный микросервис и отдельную очередь для интеграции с каждым внешним партнером (Mixpanel, Salesforce, Google Analytics и др.). В итоге их ИТ-ландшафт превратился в распределенный ад из более чем 140 разрозненных сервисов и 140 отдельных репозиториев. Из-за постоянных обновлений общих библиотек и латания рассинхронизированных зависимостей (Dependency Hell) разработчики тратили 80% времени на поддержание жизнедеятельности инфраструктуры и RabbitMQ-очередей, а развитие продукта полностью остановилось. Сотни простаивающих контейнеров впустую сжигали базовые CPU-квоты облака. В итоге Segment осуществила радикальный шаг: объединила код всех 140 интеграций обратно в один монолитный Go-бинарник, получивший кодовое имя Centrifuge. Маршрутизация трафика по конечным партнерам стала осуществляться через внутрипроцессную таблицу диспетчеризации в оперативной памяти. Это мгновенно сократило расходы на серверы, драматически подняло утилизацию CPU и полностью ликвидировало ад управления зависимостями, вернув продуктивность продуктовым командам. Ад оркестрации: почему сложные платформы автоматизации противопоказаны для High Load Разрубив систему на тысячи кусков, компании выбрали в качестве главного инструмента управления тяжелые платформы оркестрации контейнеров. Но они стали стандартом де-факто для высоких нагрузок абсолютно незаслуженно. Для систем с экстремальными транзакционными нагрузками и жесткими требованиями к задержкам (low-latency) избыточный слой контейнерной оркестрации противопоказан: 	 Сетевой пирог виртуализации. В таких средах сетевой трафик проходит сквозь бесконечные слои абстракций — виртуальные интерфейсы, оверлейные сети, прокси-таблицы ядра и инфраструктурные шлюзы. В транзакционном High Load подобная избыточность превращается в критическое узкое место. Сетевой диспетчер или аппаратный балансировщик эпохи классической SOA распределял трафик по экземплярам приложений практически со скоростью железа. 	 Борьба за ресурсы. Оркестратор пытается динамически управлять ресурсами на уровне ядра операционной системы, ничего не зная о процессах и внутренних механизмах управления памятью самого прикладного решения (например, о «сборке мусора»). В итоге планировщик инфраструктуры и внутренний диспетчер приложения начинают «драться» за процессорное время, вызывая жесткое удушение (throttling) CPU и непредсказуемые задержки (latency spikes) прямо посреди финансовой транзакции. 	 Сложность вместо надежности. Системы оркестрации создавались для управления тысячами эфемерных веб-компонентов, которые могут безболезненно падать каждую секунду. Но серьезная финтех-платформа или система управления предприятием состоит из стабильных, тяжеловесных сервисов, хранящих состояние (Stateful). Разворачивать под них сложнейшие распределенные оркестраторы — это чистая подмена понятий, увеличивающая аварийность системы из-за человеческого фактора и сложности конфигурации. Назад к здравому смыслу: эволюционная реабилитация SOA Признание краха мелкогранулированных микросервисов вовсе не означает, что индустрия должна в панике откатиться к неделимым монолитам. Выход из этого тупика лежит в возврате к классической, фундаментальной концепции SOA, но переосмысленной на новом технологическом витке: 	Крупная гранулярность. Сервис должен быть крупным. Не «сервис генерации PDF», а «Сервис расчетно-кассового обслуживания». Он объединяет в себе весь бизнес-домен. Внутри него компоненты общаются в оперативной памяти. Сетевая граница проводится только там, где бизнес-процессы действительно разделены организационно (например, интеграция систем разных поставщиков, где SOA и её интеграционные паттерны исторически незаменимы). 	Отделение бизнес-домена от интеграционного слоя. Мы берем из SOA проверенную интеграционную логику, но не тащим логику бизнес-домена на централизованную шину. Её задача — выполнять исключительно трансформацию, обогащение и маршрутизацию сообщений. Она выступает просто умным почтальоном для потока данных, связывая системы разных поставщиков. 	Изоляция без посредников. Для изоляции рабочей нагрузки не нужны тяжелые контейнерные движки с централизованными демонами управления, являющиеся классической единой точкой отказа и узким местом производительности. Настоящая изоляция крупного SOA-сервиса реализуется через легковесные инструменты нового поколения, работающие по принципу daemonless (без демона) и в режиме rootless (без прав суперпользователя) — такие как Podman. Контейнер в такой схеме запускается как обычный, изолированный процесс Linux, управляемый напрямую ядром ОС (через стандартный systemd). Это дает предсказуемость среды (Infrastructure as Code) и скорость железа без инфраструктурных накладных расходов оркестраторов. Вывод для бизнеса Эра микросервисного романтизма завершается. Компании, считающие свои деньги, больше не могут позволить себе оплачивать трехкратный инфраструктурный налог. Побеждает здравый инженерный расчет. Классическая SOA, очищенная от бюрократии старых инструментов и усиленная легковесной daemonless-контейнеризацией, возвращает себе статус эталонной архитектуры. Она дает ровно то, что обещали, но не смогли дать микросервисы: прогнозируемый TTM, контролируемый техдолг и адекватные затраты на железо. Настоящий High Load всегда покоится на уровне операционной системы и железа, а не на уровне абстракций оркестраторов. #IMAGE_235381#]]></description>
<source><![CDATA[&lltt;p&ggtt;Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и&nbsp;скорость. Сначала&nbsp;— через сервис-ориентированную архитектуру (SOA), затем&nbsp;— через «серебряную пулю» микросервисов.&lltt;/p&ggtt;
&lltt;p&ggtt;Это обещание звучало заманчиво: распилите монолит на&nbsp;крошечные независимые сервисы, общающиеся по&nbsp;вебу, и&nbsp;вы&nbsp;будете выкатывать функционал бизнесу за&nbsp;пару дней силами изолированных команд. Маркетинговый хайп победил инженерный рассудок.&lltt;/p&ggtt;
&lltt;p&ggtt;Сегодня за&nbsp;ширмой «современного стека» скрывается суровая реальность: тотальный паралич Time-To-Market (TTM), астрономический технический долг и&nbsp;кратные финансовые потери.&lltt;/p&ggtt;
&lltt;h2&ggtt;Архитектурные заблуждения и&nbsp;подмена понятий: ООП наизнанку&lltt;/h2&ggtt;
&lltt;p&ggtt;В&nbsp;чём фундаментальный просчет концепции микросервисов в&nbsp;их&nbsp;массовом исполнении? В&nbsp;том, что базовые принципы проектирования программного обеспечения&nbsp;— инкапсуляцию, слабую связность и&nbsp;объектно-ориентированный подход&nbsp;— попытались насильно перенести на&nbsp;уровень сети.&lltt;/p&ggtt;
&lltt;p&ggtt;Архитекторы «новой волны» решили, что микросервис&nbsp;— это изолированный объект, а&nbsp;сетевой HTTP/REST-запрос&nbsp;— это просто вызов метода. Индустрия проигнорировала законы физики. Если вызов метода в&nbsp;едином адресном пространстве оперативной памяти (In-Memory Call) занимает наносекунды и&nbsp;абсолютно надежен, то&nbsp;сетевой вызов между мелкогранулированными компонентами занимает уже миллисекунды. А&nbsp;сама сеть к&nbsp;тому&nbsp;же по&nbsp;определению ненадежна.&lltt;/p&ggtt;
&lltt;p&ggtt;Ирония судьбы&nbsp;— в&nbsp;том, что в&nbsp;эпоху расцвета классической SOA те&nbsp;же промышленные платформы, от&nbsp;enterprise-решений ведущих вендоров до&nbsp;систем с&nbsp;открытым исходным кодом на .NET, Java или Python, технически предоставляли абсолютно те&nbsp;же преимущества, которые сегодня приписывают исключительно микросервисам.&lltt;/p&ggtt;
&lltt;p&ggtt;Архитектурные возможности изначально позволяли объединить отдельные прикладные компоненты и&nbsp;интеграционные адаптеры в&nbsp;изолированные крупногранулированные сервисы в&nbsp;соответствии с&nbsp;границами доменной области. Внутри этого домена компоненты взаимодействовали в&nbsp;едином адресном пространстве оперативной памяти (In-Memory), а&nbsp;платформы великолепно масштабировались горизонтально за&nbsp;счет логических экземпляров среды выполнения в&nbsp;составе одной или нескольких операционных систем.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;какой-то момент в&nbsp;индустрии перестали соблюдать базовые принципы SOA-архитектуры, забыв, что микросервисы&nbsp;— это не&nbsp;более чем подмножество SOA.&lltt;/p&ggtt;
&lltt;p&ggtt;Вместо того чтобы наводить порядок в&nbsp;границах доменной области, разработчики объявили проверенные подходы «тяжелыми» и&nbsp;ушли в&nbsp;микросервисный веб. Они упустили из&nbsp;виду, что этот самый веб&nbsp;— про переносимость, и&nbsp;вся его прелесть проявляется тогда, когда речь идет об&nbsp;интеграции разнородных систем, развернутых на&nbsp;принципиально разных платформах, когда речь идет об&nbsp;интероперабельности.&lltt;/p&ggtt;
&lltt;p&ggtt;Физическая изоляция (сеть и&nbsp;контейнеризация) стала защитой от&nbsp;низкой культуры и&nbsp;дисциплины разработки. Если вы&nbsp;не&nbsp;умеете инкапсулировать код в&nbsp;логические модули, сеть заставит вас сделать это силой. Но&nbsp;цена такого принуждения оказалась непомерной для бизнеса.&lltt;/p&ggtt;
&lltt;h2&ggtt;Подмена понятий: из&nbsp;песочницы разработки в&nbsp;промышленную эксплуатацию&lltt;/h2&ggtt;
&lltt;p&ggtt;Чтобы понять, как мы&nbsp;оказались в&nbsp;этой точке, нужно вспомнить историю развития технологий разработки. Весь этот технологический стек&nbsp;— контейнеризация, платформы оркестрации и&nbsp;автоматизированные CI/CD-пайплайны&nbsp;— изначально задумывался исключительно как инструментарий для высвобождения рабочего времени разработчика.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;частности, изоляция сред в&nbsp;контейнерах была введена в&nbsp;процесс разработки как ответ на&nbsp;вечное проклятие: «на&nbsp;моей машине всё работало». Она была нужна, чтобы программист мог мгновенно развернуть готовое локальное окружение.&lltt;/p&ggtt;
&lltt;p&ggtt;Платформы оркестрации контейнеров создавались в&nbsp;недрах технологических гигантов для утилизации пустующих серверов дата-центров и&nbsp;быстрой подготовки эфемерных тестовых сред под нужды команд автоматизации. Эти инструменты создавались для «песочниц», прототипирования и&nbsp;автоматизации рутины. Никто не&nbsp;проектировал их&nbsp;под высоконагруженные транзакционные контуры, требующие промышленной надежности.&lltt;/p&ggtt;
&lltt;p&ggtt;Трагедия современной ИТ-индустрии в&nbsp;том, что инструмент быстрой лепки временных сред ошибочно приняли за&nbsp;стандарт. Архитекторы перенесли логику «песочницы» на&nbsp;боевые контуры транзакционных систем финансового и&nbsp;промышленного секторов. В&nbsp;результате бизнес получил хрупкую распределенную систему, где стабильность решения принесена в&nbsp;жертву сиюминутному удобству локального написания кода.&lltt;/p&ggtt;
&lltt;h2&ggtt;Великое заблуждение: архитектура системного&nbsp;ПО в&nbsp;транзакционном бизнесе&lltt;/h2&ggtt;
&lltt;p&ggtt;Микросервисная архитектура родилась не&nbsp;на&nbsp;предприятиях непрерывного цикла и&nbsp;не&nbsp;в&nbsp;банках с&nbsp;их&nbsp;высокоинтенсивными рабочими нагрузками. Она появилась в&nbsp;недрах цифровых гигантов (Netflix, Amazon, SoundCloud), у&nbsp;которых вообще не&nbsp;было чужих систем и&nbsp;разных поставщиков. Они контролировали 100% своего стека и&nbsp;писали всё с&nbsp;нуля.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;этих условиях все сервисы изначально взаимодействовали на&nbsp;одном «языке» (JSON/REST), и&nbsp;трансформировать форматы данных было просто не&nbsp;нужно. Внедрение сложных интеграционных шин в&nbsp;такую однородную среду принесло&nbsp;бы только лишние накладные расходы.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;главное&nbsp;— характер их&nbsp;работы. Микросервисы в&nbsp;их&nbsp;каноническом виде&nbsp;— это архитектура уровня системного&nbsp;ПО управления ресурсами. Условная транзакция в&nbsp;облачном провайдере или стриминговом сервисе запускает длительный, асинхронный процесс. Например, развертывание виртуальной машины из&nbsp;ISO-образа. Этот процесс занимает десятки секунд или минуты. Пользователь готов ждать.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;этом фоне 10&nbsp;миллисекунд сетевых задержек, возникающих при взаимодействии между мелкогранулированными системными сервисами (один выделяет диск, другой вешает IP),&nbsp;— это не&nbsp;более чем математическая погрешность. Там действительно не&nbsp;нужна интеграционная транзакционная «молотилка».&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;когда, например, в&nbsp;вакансиях «инновационного финтеха» для Core-системы со&nbsp;строгой OLTP-нагрузкой фигурируют микросервисы и&nbsp;оркестраторы&nbsp;— это признак тотального непонимания физики процессов. Финтех-операция должна выполняться синхронно, атомарно и&nbsp;за&nbsp;миллисекунды. И&nbsp;здесь 15&nbsp;миллисекунд сетевых издержек на&nbsp;каждый шаг цепочки (запрос в&nbsp;сервис баланса, запрос в&nbsp;антифрод, запрос в&nbsp;лимиты)&nbsp;— это архитектурный приговор.&lltt;/p&ggtt;
&lltt;p&ggtt;Система тратит время не&nbsp;на&nbsp;полезную работу (изменение пары байт в&nbsp;СУБД), а&nbsp;на&nbsp;ожидание ответов по&nbsp;сети, обработку HTTP-заголовков и&nbsp;обеспечение консистентности данных (Eventual Consistency), которая в&nbsp;транзакционных системах недопустима по&nbsp;определению.&lltt;/p&ggtt;
&lltt;h2&ggtt;Иллюзия Time-To-Market: быстро на&nbsp;старте, паралич на&nbsp;финише&lltt;/h2&ggtt;
&lltt;p&ggtt;Главный аргумент в&nbsp;пользу микросервисов&nbsp;— это ускорение TTM. И&nbsp;на&nbsp;этапе разработки системы с&nbsp;нуля эта иллюзия действительно работает. Написать один мелкий сервис, который выполняет одну конкретную функцию, можно за&nbsp;пару дней. Руководство и&nbsp;бизнес-заказчик аплодируют стоя.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблемы начинаются, когда система разрастается до&nbsp;сотен мелкогранулированных ИТ-сервисов, общающихся преимущественно по&nbsp;Web/HTTP. Бизнес&nbsp;же мыслит сквозными ценностями, а&nbsp;не&nbsp;микрофункциями. И&nbsp;когда для реализации одной новой бизнес-функциональности (например, внедрения нового типа лояльности) требуется одновременно изменить контракты в&nbsp;&lltt;nobr&ggtt;5-7&lltt;/nobr&ggtt; разных микросервисах, начинается&nbsp;ад:&lltt;/p&ggtt;
&lltt;ol&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Паралич взаимодействия команд:&lltt;/strong&ggtt; нужно согласовать изменения API&nbsp;с пятью независимыми командами. Продуктовый TTM падает до&nbsp;нуля, утопая в&nbsp;бесконечных созвонах, а&nbsp;также в&nbsp;согласованиях контрактов в&nbsp;спецификациях и&nbsp;задачах.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Интеграционный тупик:&lltt;/strong&ggtt; вместо релиза одной кнопкой компания получает сложнейшие распределенные релизные циклы. Архитектура превращается в&nbsp;распределенный монолит&nbsp;— худшее из&nbsp;обоих миров, выпуск релиза которого происходит дольше и&nbsp;болезненнее, чем в&nbsp;крупногранулированной SOA-архитектуре двадцать лет назад.&lltt;/li&ggtt;
&lltt;/ol&ggtt;
&lltt;h2&ggtt;Облачный грабеж и&nbsp;трехкратный «инфраструктурный налог»&lltt;/h2&ggtt;
&lltt;p&ggtt;Когда ИТ-директора обосновывали переход на&nbsp;микросервисы, главным экономическим аргументом был отказ от&nbsp;«вендорской иглы»&nbsp;— коммерческих лицензий за&nbsp;процессорные ядра или вычислительные узлы, выделенные под прикладное решение. Обещание звучало как финансовое освобождение: «Мы&nbsp;уйдем на&nbsp;свободное программное обеспечение (Open Source), перенесем всё в&nbsp;облако и&nbsp;будем платить только за&nbsp;реальное потребление».&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;на&nbsp;серьезных нагрузках микросервисная архитектура дает &lltt;strong&ggtt;2-3-кратный рост расходов бюджета&lltt;/strong&ggtt;. Этот «финансовый пылесос» состоит из&nbsp;трех главных составляющих:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Память и&nbsp;процессоры.&lltt;/strong&ggtt; В&nbsp;микросервисах каждому крошечному сервису нужно выделить сотни мегабайт оперативной памяти просто на&nbsp;прогрев его собственного изолированного окружения. Транзакция превращается в&nbsp;каскад из&nbsp;&lltt;nobr&ggtt;10-15&lltt;/nobr&ggtt; сетевых вызовов, где до&nbsp;&lltt;nobr&ggtt;40-60%&lltt;/nobr&ggtt; мощности процессора тратится на&nbsp;постоянную сериализацию и&nbsp;десериализацию JSON, шифрование TLS и&nbsp;перекладывание байтов по&nbsp;сетевым стекам. Чтобы переварить ту&nbsp;же нагрузку, приходится покупать в&nbsp;2,5 раза больше вычислительных ядер (vCPU). Умножьте это на&nbsp;сотни сервисов и&nbsp;на&nbsp;зоны доступности. Как итог: бизнес платит за&nbsp;гигабайты памяти и&nbsp;процессорное время, которые вообще не&nbsp;используются для выполнения прикладной логики. В&nbsp;то&nbsp;же время транзакция в&nbsp;крупногранулированном сервисе&nbsp;— это просто передача ссылки на&nbsp;объект в&nbsp;памяти, не&nbsp;требующая выделения дополнительной памяти и&nbsp;процессорного времени на&nbsp;сериализацию и&nbsp;десериализацию.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;Скрытый «убийца»&nbsp;— сетевой трафик.&lltt;/strong&ggtt; Чтобы обеспечить высокую доступность, экземпляры микросервисов размазываются по&nbsp;разным дата-центрам (зонам доступности). Облачные провайдеры жестко тарифицируют каждый гигабайт трафика между зонами доступности (Inter-AZ). В&nbsp;рамках единого крупногранулированного сервиса этот трафик был бесплатным (внутри хоста); в&nbsp;микросервисах счета за&nbsp;внутриоблачную сеть часто превышают стоимость самих процессоров.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;Инфраструктурные надстройки как величайший обман.&lltt;/strong&ggtt; Пытаясь уйти от&nbsp;концепции интеграционных шин, ИТ-архитекторы заявили, что связь теперь «бесплатная». Но&nbsp;когда сетью стало невозможно управлять, индустрия придумала концепцию Service Mesh. Вместо одной центральной шины компания получила тысячи микрошин в&nbsp;виде прокси-приложений (sidecar) для каждого контейнера. Эксплуатация таких решений в&nbsp;крупных проектах показывает, что эти прокси съедают от&nbsp;20&nbsp;до&nbsp;50% всей оперативной памяти и&nbsp;до&nbsp;30% CPU всего вычислительного кластера. Бизнес просто перенаправил миллионы из&nbsp;одного кармана в&nbsp;другой&nbsp;— в&nbsp;пользу облачных провайдеров.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h2&ggtt;Практика против моды: опыт технологических лидеров&lltt;/h2&ggtt;
&lltt;p&ggtt;Для тех, кто считает эти расчеты «теоретическим ретроградством», индустрия приготовила серию сокрушительных прецедентов от&nbsp;компаний, чьи масштабы нагрузок не&nbsp;подлежат сомнению.&lltt;/p&ggtt;
&lltt;h3&ggtt;Amazon Prime Video: отрезвление изнутри&lltt;/h3&ggtt;
&lltt;p&ggtt;Самый громкий удар по&nbsp;микросервисной религии нанесла сама компания Amazon&nbsp;— создатель главной облачной инфраструктуры планеты.&lltt;/p&ggtt;
&lltt;p&ggtt;Инженеры команды Amazon Prime Video, спроектировав распределенную систему мониторинга качества видеопотоков по&nbsp;«модному учебнику», столкнулись с&nbsp;финансовой катастрофой при попытке масштабирования. Изначальная архитектура опиралась на&nbsp;оркестрацию через AWS Step Functions и&nbsp;бессерверные вычисления AWS Lambda. Архитектурный просчет заключался в&nbsp;том, что компоненты пайплайна (медиаконвертер и&nbsp;детектор дефектов) обменивались терабайтами тяжелых сырых видеокадров, постоянно сохраняя и&nbsp;скачивая их&nbsp;через промежуточное дисковое хранилище Amazon S3.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;результате система уперлась в&nbsp;потолок производительности всего на&nbsp;5% от&nbsp;целевой мощности: компания моментально уперлась в&nbsp;лимиты AWS Step Functions по&nbsp;количеству переходов между состояниями (state transitions) в&nbsp;секунду, а&nbsp;счета за&nbsp;Tier-1&nbsp;API-запросы к&nbsp;S3&nbsp;и&nbsp;сетевую сериализацию кратно превысили стоимость самого компюта.&lltt;/p&ggtt;
&lltt;p&ggtt;Инженеры Amazon полностью переписали архитектуру, объединив все три распределенных компонента в&nbsp;единое монолитное приложение, развернутое в&nbsp;контейнерах Amazon ECS. Вместо пересылки тяжелых фреймов по&nbsp;сети через&nbsp;S3, этапы конвейера стали обмениваться данными напрямую в&nbsp;оперативной памяти (In-Memory) в&nbsp;рамках одного процесса. Результат: &lltt;strong&ggtt;затраты на&nbsp;инфраструктуру снизились на&nbsp;90%&lltt;/strong&ggtt;, а&nbsp;ограничения масштабируемости исчезли.&lltt;/p&ggtt;
&lltt;h3&ggtt;Shopify: битва за&nbsp;скорость «выкатки фич»&lltt;/h3&ggtt;
&lltt;p&ggtt;Гигант мировой интернет-торговли Shopify, обрабатывающий миллионы транзакций, вовремя остановил тотальное дробление систем. Архитекторы обнаружили, что мелкогранулированность и&nbsp;распределенность разрушили границы контекстов, вызвав тяжелейший межкомандный паралич: для банального изменения логики скидок или корзины приходилось синхронно переписывать контракты API&nbsp;в шести независимых командах и&nbsp;репозиториях.&lltt;/p&ggtt;
&lltt;p&ggtt;Shopify официально провозгласил верность концепции «Маджестик Монолита» (Majestic Monolith), но&nbsp;вместо хаотичного «комка грязи» они планомерно реорганизуют кодовую базу в&nbsp;строго изолированный «&lltt;strong&ggtt;Модульный монолит» (Modular Monolith)&lltt;/strong&ggtt;.&lltt;/p&ggtt;
&lltt;p&ggtt;Используя разработанный ими инструмент статического анализа Packwerk (в&nbsp;связке с&nbsp;софтверными контрактами Sorbet), компания жестко контролирует границы бизнес-доменов на&nbsp;уровне абстракции кода. Все модули находятся в&nbsp;едином репозитории и&nbsp;разворачиваются вместе, что избавляет инженеров от&nbsp;сетевой бюрократии, сохраняет строгую ACID-консистентность базы данных, но&nbsp;при этом изолирует зоны ответственности команд и&nbsp;сокращает TTM&nbsp;в разы.&lltt;/p&ggtt;
&lltt;h3&ggtt;Segment (Twilio): тупик мелкозернистой изоляции&lltt;/h3&ggtt;
&lltt;p&ggtt;Платформа сбора данных Segment изначально создала отдельный микросервис и&nbsp;отдельную очередь для интеграции с&nbsp;каждым внешним партнером (Mixpanel, Salesforce, Google Analytics и&nbsp;др.). В&nbsp;итоге их&nbsp;ИТ-ландшафт превратился в&nbsp;распределенный ад&nbsp;из&nbsp;более чем &lltt;strong&ggtt;140 разрозненных сервисов и&nbsp;140 отдельных репозиториев&lltt;/strong&ggtt;.&lltt;/p&ggtt;
&lltt;p&ggtt;Из-за постоянных обновлений общих библиотек и&nbsp;латания рассинхронизированных зависимостей (Dependency Hell) разработчики тратили&nbsp;80% времени на&nbsp;поддержание жизнедеятельности инфраструктуры и&nbsp;RabbitMQ-очередей, а&nbsp;развитие продукта полностью остановилось. Сотни простаивающих контейнеров впустую сжигали базовые CPU-квоты облака.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;итоге Segment осуществила радикальный шаг: объединила код всех 140 интеграций обратно в&nbsp;один монолитный Go-бинарник, получивший кодовое имя Centrifuge. Маршрутизация трафика по&nbsp;конечным партнерам стала осуществляться через внутрипроцессную таблицу диспетчеризации в&nbsp;оперативной памяти. Это мгновенно сократило расходы на&nbsp;серверы, драматически подняло утилизацию CPU и&nbsp;полностью ликвидировало ад&nbsp;управления зависимостями, вернув продуктивность продуктовым командам.&lltt;/p&ggtt;
&lltt;h2&ggtt;Ад&nbsp;оркестрации: почему сложные платформы автоматизации противопоказаны для High Load&lltt;/h2&ggtt;
&lltt;p&ggtt;Разрубив систему на&nbsp;тысячи кусков, компании выбрали в&nbsp;качестве главного инструмента управления тяжелые платформы оркестрации контейнеров. Но&nbsp;они стали стандартом де-факто для высоких нагрузок абсолютно незаслуженно. Для систем с&nbsp;экстремальными транзакционными нагрузками и&nbsp;жесткими требованиями к&nbsp;задержкам (low-latency) избыточный слой контейнерной оркестрации противопоказан:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Сетевой пирог виртуализации.&lltt;/strong&ggtt; В&nbsp;таких средах сетевой трафик проходит сквозь бесконечные слои абстракций&nbsp;— виртуальные интерфейсы, оверлейные сети, прокси-таблицы ядра и&nbsp;инфраструктурные шлюзы. В&nbsp;транзакционном High Load подобная избыточность превращается в&nbsp;критическое узкое место. Сетевой диспетчер или аппаратный балансировщик эпохи классической SOA распределял трафик по&nbsp;экземплярам приложений практически со&nbsp;скоростью железа.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;Борьба за&nbsp;ресурсы.&lltt;/strong&ggtt; Оркестратор пытается динамически управлять ресурсами на&nbsp;уровне ядра операционной системы, ничего не&nbsp;зная о&nbsp;процессах и&nbsp;внутренних механизмах управления памятью самого прикладного решения (например, о&nbsp;«сборке мусора»). В&nbsp;итоге планировщик инфраструктуры и&nbsp;внутренний диспетчер приложения начинают «драться» за&nbsp;процессорное время, вызывая жесткое удушение (throttling) CPU и&nbsp;непредсказуемые задержки (latency spikes) прямо посреди финансовой транзакции.&lltt;/li&ggtt;
	&lltt;li&ggtt; &lltt;strong&ggtt;Сложность вместо надежности.&lltt;/strong&ggtt; Системы оркестрации создавались для управления тысячами эфемерных веб-компонентов, которые могут безболезненно падать каждую секунду. Но&nbsp;серьезная финтех-платформа или система управления предприятием состоит из&nbsp;стабильных, тяжеловесных сервисов, хранящих состояние (Stateful). Разворачивать под них сложнейшие распределенные оркестраторы&nbsp;— это чистая подмена понятий, увеличивающая аварийность системы из-за человеческого фактора и&nbsp;сложности конфигурации.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h2&ggtt;Назад к&nbsp;здравому смыслу: эволюционная реабилитация SOA&lltt;/h2&ggtt;
&lltt;p&ggtt;Признание краха мелкогранулированных микросервисов вовсе не&nbsp;означает, что индустрия должна в&nbsp;панике откатиться к&nbsp;неделимым монолитам. Выход из&nbsp;этого тупика лежит в&nbsp;возврате к&nbsp;классической, фундаментальной концепции SOA, но&nbsp;переосмысленной на&nbsp;новом технологическом витке:&lltt;/p&ggtt;
&lltt;ol&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Крупная гранулярность.&lltt;/strong&ggtt; Сервис должен быть крупным. Не&nbsp;«сервис генерации PDF», а&nbsp;«Сервис расчетно-кассового обслуживания». Он&nbsp;объединяет в&nbsp;себе весь бизнес-домен. Внутри него компоненты общаются в&nbsp;оперативной памяти. Сетевая граница проводится только там, где бизнес-процессы действительно разделены организационно (например, интеграция систем разных поставщиков, где SOA и&nbsp;её&nbsp;интеграционные паттерны исторически незаменимы).&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Отделение бизнес-домена от&nbsp;интеграционного слоя.&lltt;/strong&ggtt; Мы&nbsp;берем из&nbsp;SOA проверенную интеграционную логику, но&nbsp;не&nbsp;тащим логику бизнес-домена на&nbsp;централизованную шину. Её&nbsp;задача&nbsp;— выполнять исключительно трансформацию, обогащение и&nbsp;маршрутизацию сообщений. Она выступает просто умным почтальоном для потока данных, связывая системы разных поставщиков.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Изоляция без посредников.&lltt;/strong&ggtt; Для изоляции рабочей нагрузки не&nbsp;нужны тяжелые контейнерные движки с&nbsp;централизованными демонами управления, являющиеся классической единой точкой отказа и&nbsp;узким местом производительности. Настоящая изоляция крупного SOA-сервиса реализуется через легковесные инструменты нового поколения, работающие по&nbsp;принципу &lltt;em&ggtt;daemonless&lltt;/em&ggtt; (без демона) и&nbsp;в&nbsp;режиме &lltt;em&ggtt;rootless&lltt;/em&ggtt; (без прав суперпользователя)&nbsp;— такие как Podman. Контейнер в&nbsp;такой схеме запускается как обычный, изолированный процесс Linux, управляемый напрямую ядром&nbsp;ОС (через стандартный systemd). Это дает предсказуемость среды (Infrastructure as&nbsp;Code) и&nbsp;скорость железа без инфраструктурных накладных расходов оркестраторов.&lltt;/li&ggtt;
&lltt;/ol&ggtt;
&lltt;h2&ggtt;Вывод для бизнеса&lltt;/h2&ggtt;
&lltt;p&ggtt;Эра микросервисного романтизма завершается. Компании, считающие свои деньги, больше не&nbsp;могут позволить себе оплачивать трехкратный инфраструктурный налог. Побеждает здравый инженерный расчет.&lltt;/p&ggtt;
&lltt;p&ggtt;Классическая SOA, очищенная от&nbsp;бюрократии старых инструментов и&nbsp;усиленная легковесной daemonless-контейнеризацией, возвращает себе статус эталонной архитектуры. Она дает ровно&nbsp;то, что обещали, но&nbsp;не&nbsp;смогли дать микросервисы: прогнозируемый TTM, контролируемый техдолг и&nbsp;адекватные затраты на&nbsp;железо. Настоящий High Load всегда покоится на&nbsp;уровне операционной системы и&nbsp;железа, а&nbsp;не&nbsp;на&nbsp;уровне абстракций оркестраторов.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235381#&lltt;/p&ggtt;]]></source>
<adate>20.08.2026</adate>
<dbid>235380</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/227/a53kgwuho28e7x72nt3bu74zw5j10a02.jpg]]>
</images>
<imagesname><![CDATA[;;Дмитрий Гаврилов, основатель ООО &#8220;Открытые Технологии Виртуализации&#8221;   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Как подготовить институциональные знания к использованию ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235369]]></link>
<description><![CDATA[Организации должны переосмыслить не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать, считают опрошенные порталом InformationWeek эксперты. Проблема клиента с предоставленной ему услугой передается агенту искусственного интеллекта после первоначального общения с чат-ботом. Агент проверяет официальную документацию, в которой четко указано, что в ситуациях такого типа применяется политика A — так что именно эту политику агент применяет и здесь. Это довольно распространенная ситуация, с которой регулярно сталкиваются многие предприятия. Кроме того, многие компании надеются, что использование ИИ-агента может повысить производительность. Однако такого повышения производительности не произойдет, если корпоративная база знаний, на которую опирается агент, будет неполной, неверной или устаревшей. Например, в приведенном выше сценарии представьте, что отдел продаж в течение нескольких месяцев уже придерживается политики В, но не обновил официальную документацию. У них может быть некий документ, объясняющий это изменение и новую политику, но он невидим для агентов ИИ, если не является частью базы знаний, к которой они могут получить доступ. В результате агент уверенно принимает неверное решение для данного клиента. Однако это не ошибка агента, а недостаток системы организационных знаний. Агенты ИИ не создают проблем со знаниями, но они выявляют проблемы, с которыми сталкиваются организации. Готовность к использованию людьми не означает готовность к использованию ИИ Часто организации полагают, что самой большой проблемой при переходе агентов ИИ от пилотов к производству является совершенствование самой модели. Но более серьезное препятствие часто носит более приземленный характер, говорит Кубер Шарма, старший директор UiPath по маркетингу продуктов для корпоративного ИИ и автоматизации. «Разрыв, который я чаще всего наблюдаю между пилотом и производственным внедрением ИИ-агентов, заключается не в модели. Дело в знаниях», — поясняет он. Организации разрабатывают ИИ-агентов для действий на основе документации, но затем обнаруживают, что документация не была для этого подготовлена. Вместо этого, по словам Шармы, она был создана для людей, которые могут читать между строк, консультироваться с коллегой или применять контекст. За время своего существования организация тратит значительное количество времени и энергии на написание документации для сотрудников: руководств по интранету, внутренних вики, документов о политиках, соглашений об обслуживании клиентов, брошюр о продукции и т. д. Какими бы важными они ни были, эти документы часто бывают неполными. Например, документ может еще не быть обновлен, чтобы отразить новую политику или процедуру или изменения в отраслевых или государственных нормативных актах. Когда люди используют эту документацию для поддержки своей работы, они могут выявить пробелы или несоответствия и предоставить важный контекст для их устранения. Интерпретируя неоднозначность и консультируясь с коллегами, они могут найти информацию, которую документация не охватывает, или решить, что конкретный документ больше не актуален. Но по мере того, как организации заменяют или дополняют агентами ИИ рабочую деятельность, осуществляемую людьми, они все больше сталкиваются с проблемами из-за неоднозначности документации. ИИ не способен обеспечить контекст или интерпретацию неполных баз знаний, которые могут обеспечить люди, и это приводит к проблемам, когда агенты сталкиваются с противоречивыми политиками, использованием электронной почты или чата в качестве документации, недокументированными исключениями или крайними случаями, дублированием документации и устаревшими практиками. Даже если документация точна, ее формат может стать препятствием. Файлы, хранящиеся в формате PDF, в наборах слайдов, графических материалах или специализированных учебных пакетах, могут содержать ценные институциональные знания, но без их дополнительной доработки агенты ИИ не смогут их анализировать и строить свои действия на их основе. Чтобы добиться успеха, агентам ИИ требуется четкая организационная память, а не институциональная интуиция и неполная документация. Институциональные знания выходят за рамки официальных документов Для некоторых организаций обновление официальной документации может ограничиваться обновлением нескольких ключевых PDF-файлов. Это важно, но база знаний предприятия включает в себя гораздо более широкий спектр документов и информации. Утверждения, решения, исключения, пути эскалации, бизнес-контекст, эволюция политик и неформальные практики — все это также является институциональной информацией, даже если она не отражена в официальной документации. Чтобы сделать институциональные знания доступными для агентов ИИ, часто требуется нечто большее, чем просто указать им на существующие файлы. По словам Джеймса Крэнвелла, руководителя отдела продуктов компании 5app, бóльшая часть корпоративного контента была создана для людей, а не для систем ИИ. Часто специалисты организации в предметной области загружают свои знания в документы Word, наборы слайдов, графики или PDF-файлы, иногда используя специфический для компании жаргон, сокращения и аббревиатуры, которые агентам ИИ трудно интерпретировать. Поэтому по мере того, как организации внедряют все больше агентов ИИ, стандартизация и структурирование их ресурсов знаний становится все более важной задачей. Крэнвелл не понаслышке знаком с этой проблемой. Недавно его команда создала ИИ-агент, способный анализировать пакеты электронного обучения SCORM, чтобы пользователи могли переходить к определенному разделу курса, а не извлекать сам файл курса. Этот опыт подтверждает, что организациям часто приходится адаптировать свои существующие ресурсы знаний, прежде чем агенты ИИ смогут эффективно их использовать. Успешное включение других источников институциональных знаний в базу знаний, используемую агентами ИИ, гарантирует, что эти агенты смогут более успешно интегрироваться в рабочие процессы предприятия. Чем больше у агента будет доступа к политикам, процедурам и другой информации, на основе которой он принимает решения, тем более информированными и точными будут эти решения, и тем лучше агент сможет не просто извлекать информацию, но и продуктивно применять ее на практике. По словам Шармы, знания, необходимые для работы агента, должны быть не только всеобъемлющи, но и конкретны. Не надейтесь на то, что существующий организационный контекст будет ему понятен, советует он. Вместо этого в документах должно быть четко указано, что они охватывают, а что нет, кому они принадлежат и когда они в последний раз проверялись и валидировались. Такой уровень конкретики помогает агентам ИИ отличать авторитетную информацию от устаревших или неполных рекомендаций. Когда институциональные знания устаревают Все большее число организаций полагаются на ИИ-агентов, которые берут на себя работу, ранее выполнявшуюся людьми. По данным McKinsey, 88% организаций в настоящее время используют ИИ для выполнения по крайней мере одной бизнес-функции, по сравнению с 78% годом ранее. И, согласно PwC, 79% опрошенных говорят, что агенты ИИ уже внедряются на их рабочих местах. По мере того как эти агенты будут становиться все более распространенными, будут возникать и проблемы, связанные с использованием ими устаревшей, неполной или неверной базы знаний. Когда это происходит, проблема выходит за привычные рамки: если сотрудник сбит с толку документацией, с которой он знакомится, то он может, по крайней мере, обсудить это с коллегой или использовать для интерпретации свои суждения и прошлый опыт. Неэффективные или неправильные решения, принимаемые агентами ИИ из-за плохой документации, приводят к неправильной маршрутизации, неправильным утверждениям или отказам, несогласованному взаимодействию с клиентами и, возможно, тысячам автоматизированных действий, которые не должны были выполняться. Как только агент начинает действовать на основе неполной информации, возникают вопросы подотчетности, что делает управление особенно важным. Организации, которые успешно справляются с этой задачей, рассматривают управление знаниями не как документирование, а как часть операционной модели агента ИИ, говорит Шарма. Когда агент выдает неверный результат, команды должны знать, кому принадлежат знания, лежащие в его основе, когда они проверялись в последний раз и почему агент полагается на них. Надежное управление базой знаний, на основе которой принимаются агентные решения, может смягчить некоторые из этих проблем. Организациям следует прояснить ряд вопросов, касающихся информации, которую агенты ИИ используют для принятия решений: 	 Кому принадлежат данные знания? 	 Кто обновляет их? Как часто? 	 Кто рассматривает и утверждает изменения? 	 Когда документ или его часть устаревают, кто и как их удаляет? 	 Когда официальная документация меняется, кто проводит аудит агентов ИИ, чтобы убедиться в понимании ими изменений? Без этих ответов организации рискуют разработать системы, автоматизирующие принятие неверных решений. «Агент уверенно выдает неверный ответ, основываясь на неверном источнике. Это хуже, чем отсутствие ответа. Это сбой системы управления, одобренный ИИ», — сказал Шарма. Ответы на эти вопросы и понимание всеми заинтересованными лицами важности согласования этих ответов с базой знаний компании помогут избежать проблем с документацией при внедрении ИИ-агентов. Цель состоит в том, чтобы официальные знания, подготовленные для агентов, всегда были актуальными, четко сформулированными, авторитетными, структурированными, управляемыми и объяснимыми. Убедитесь, что корпоративный источник истины готов к использованию ИИ Организации могут беспокоиться о том, что ИИ-агент не сможет должным образом разобраться в их бизнесе, но первым шагом должно стать обеспечение понимания бизнесом самого себя. Агенты ИИ не могут восполнить недостающий контекст или информацию так, как это могут сделать сотрудники. Они не могут согласовать противоречивые документы, вывести неписаные правила или признать, что «все знают», что процедура изменилась. Они принимают решения на основе институциональных знаний, предоставляемых организациями, и выявляют все слабые места или пробелы в этих знаниях. Предприятие, осознающее недостаточность своей базы знаний, получает неожиданную выгоду от того, что ему приходится сталкиваться с накопившимися несоответствиями и исправлять их, а также создавать систему управления, которая позволит ему продвигаться вперед с использованием более совершенной модели поддержания этих знаний. Подготовка институциональных знаний для ИИ — это задача управления контентом в дополнение к управленческому процессу. Организациям все чаще приходится переосмысливать не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Организации должны переосмыслить не&nbsp;только&nbsp;то, что они документируют, но&nbsp;и&nbsp;то, как они структурируют, поддерживают и&nbsp;представляют эти знания, чтобы автоматизированные системы могли надежно их&nbsp;использовать, считают опрошенные порталом &lltt;/em&ggtt;&lltt;em&ggtt;InformationWeek&lltt;/em&ggtt; &lltt;em&ggtt;эксперты.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема клиента с&nbsp;предоставленной ему услугой передается агенту искусственного интеллекта после первоначального общения с&nbsp;чат-ботом. Агент проверяет официальную документацию, в&nbsp;которой четко указано, что в&nbsp;ситуациях такого типа применяется политика A&nbsp;— так что именно эту политику агент применяет и&nbsp;здесь.&lltt;/p&ggtt;
&lltt;p&ggtt;Это довольно распространенная ситуация, с&nbsp;которой регулярно сталкиваются многие предприятия. Кроме того, многие компании надеются, что использование ИИ-агента может повысить производительность.&lltt;/p&ggtt;
&lltt;p&ggtt;Однако такого повышения производительности не&nbsp;произойдет, если корпоративная база знаний, на&nbsp;которую опирается агент, будет неполной, неверной или устаревшей. Например, в&nbsp;приведенном выше сценарии представьте, что отдел продаж в&nbsp;течение нескольких месяцев уже придерживается политики&nbsp;В, но&nbsp;не&nbsp;обновил официальную документацию. У&nbsp;них может быть некий документ, объясняющий это изменение и&nbsp;новую политику, но&nbsp;он&nbsp;невидим для агентов&nbsp;ИИ, если не&nbsp;является частью базы знаний, к&nbsp;которой они могут получить доступ.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;результате агент уверенно принимает неверное решение для данного клиента. Однако это не&nbsp;ошибка агента, а&nbsp;недостаток системы организационных знаний. Агенты ИИ&nbsp;не&nbsp;создают проблем со&nbsp;знаниями, но&nbsp;они выявляют проблемы, с&nbsp;которыми сталкиваются организации.&lltt;/p&ggtt;
&lltt;h3&ggtt;Готовность к&nbsp;использованию людьми не&nbsp;означает готовность к&nbsp;использованию ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Часто организации полагают, что самой большой проблемой при переходе агентов&nbsp;ИИ от&nbsp;пилотов к&nbsp;производству является совершенствование самой модели. Но&nbsp;более серьезное препятствие часто носит более приземленный характер, говорит Кубер Шарма, старший директор UiPath по&nbsp;маркетингу продуктов для корпоративного&nbsp;ИИ и&nbsp;автоматизации. «Разрыв, который я&nbsp;чаще всего наблюдаю между пилотом и&nbsp;производственным внедрением ИИ-агентов, заключается не&nbsp;в&nbsp;модели. Дело в&nbsp;знаниях»,&nbsp;— поясняет&nbsp;он. Организации разрабатывают ИИ-агентов для действий на&nbsp;основе документации, но&nbsp;затем обнаруживают, что документация не&nbsp;была для этого подготовлена. Вместо этого, по&nbsp;словам Шармы, она был создана для людей, которые могут читать между строк, консультироваться с&nbsp;коллегой или применять контекст.&lltt;/p&ggtt;
&lltt;p&ggtt;За&nbsp;время своего существования организация тратит значительное количество времени и&nbsp;энергии на&nbsp;написание документации для сотрудников: руководств по&nbsp;интранету, внутренних вики, документов о&nbsp;политиках, соглашений об&nbsp;обслуживании клиентов, брошюр о&nbsp;продукции и&nbsp;т.&nbsp;д. Какими&nbsp;бы важными они ни&nbsp;были, эти документы часто бывают неполными. Например, документ может еще не&nbsp;быть обновлен, чтобы отразить новую политику или процедуру или изменения в&nbsp;отраслевых или государственных нормативных актах.&lltt;/p&ggtt;
&lltt;p&ggtt;Когда люди используют эту документацию для поддержки своей работы, они могут выявить пробелы или несоответствия и&nbsp;предоставить важный контекст для их&nbsp;устранения. Интерпретируя неоднозначность и&nbsp;консультируясь с&nbsp;коллегами, они могут найти информацию, которую документация не&nbsp;охватывает, или решить, что конкретный документ больше не&nbsp;актуален.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;по&nbsp;мере того, как организации заменяют или дополняют агентами&nbsp;ИИ рабочую деятельность, осуществляемую людьми, они все больше сталкиваются с&nbsp;проблемами из-за неоднозначности документации. ИИ&nbsp;не&nbsp;способен обеспечить контекст или интерпретацию неполных баз знаний, которые могут обеспечить люди, и&nbsp;это приводит к&nbsp;проблемам, когда агенты сталкиваются с&nbsp;противоречивыми политиками, использованием электронной почты или чата в&nbsp;качестве документации, недокументированными исключениями или крайними случаями, дублированием документации и&nbsp;устаревшими практиками.&lltt;/p&ggtt;
&lltt;p&ggtt;Даже если документация точна, ее&nbsp;формат может стать препятствием. Файлы, хранящиеся в&nbsp;формате PDF, в&nbsp;наборах слайдов, графических материалах или специализированных учебных пакетах, могут содержать ценные институциональные знания, но&nbsp;без их&nbsp;дополнительной доработки агенты&nbsp;ИИ не&nbsp;смогут их&nbsp;анализировать и&nbsp;строить свои действия на&nbsp;их&nbsp;основе.&lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы добиться успеха, агентам&nbsp;ИИ требуется четкая организационная память, а&nbsp;не&nbsp;институциональная интуиция и&nbsp;неполная документация.&lltt;/p&ggtt;
&lltt;h3&ggtt;Институциональные знания выходят за&nbsp;рамки официальных документов&lltt;/h3&ggtt;
&lltt;p&ggtt;Для некоторых организаций обновление официальной документации может ограничиваться обновлением нескольких ключевых PDF-файлов. Это важно, но&nbsp;база знаний предприятия включает в&nbsp;себя гораздо более широкий спектр документов и&nbsp;информации. Утверждения, решения, исключения, пути эскалации, бизнес-контекст, эволюция политик и&nbsp;неформальные практики&nbsp;— все это также является институциональной информацией, даже если она не&nbsp;отражена в&nbsp;официальной документации.&lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы сделать институциональные знания доступными для агентов&nbsp;ИИ, часто требуется нечто большее, чем просто указать им&nbsp;на&nbsp;существующие файлы. По&nbsp;словам Джеймса Крэнвелла, руководителя отдела продуктов компании 5app, бóльшая часть корпоративного контента была создана для людей, а&nbsp;не&nbsp;для систем ИИ. Часто специалисты организации в&nbsp;предметной области загружают свои знания в&nbsp;документы Word, наборы слайдов, графики или PDF-файлы, иногда используя специфический для компании жаргон, сокращения и&nbsp;аббревиатуры, которые агентам&nbsp;ИИ трудно интерпретировать. Поэтому по&nbsp;мере того, как организации внедряют все больше агентов&nbsp;ИИ, стандартизация и&nbsp;структурирование их&nbsp;ресурсов знаний становится все более важной задачей.&lltt;/p&ggtt;
&lltt;p&ggtt;Крэнвелл не&nbsp;понаслышке знаком с&nbsp;этой проблемой. Недавно его команда создала ИИ-агент, способный анализировать пакеты электронного обучения SCORM, чтобы пользователи могли переходить к&nbsp;определенному разделу курса, а&nbsp;не&nbsp;извлекать сам файл курса. Этот опыт подтверждает, что организациям часто приходится адаптировать свои существующие ресурсы знаний, прежде чем агенты&nbsp;ИИ смогут эффективно их&nbsp;использовать.&lltt;/p&ggtt;
&lltt;p&ggtt;Успешное включение других источников институциональных знаний в&nbsp;базу знаний, используемую агентами&nbsp;ИИ, гарантирует, что эти агенты смогут более успешно интегрироваться в&nbsp;рабочие процессы предприятия. Чем больше у&nbsp;агента будет доступа к&nbsp;политикам, процедурам и&nbsp;другой информации, на&nbsp;основе которой он&nbsp;принимает решения, тем более информированными и&nbsp;точными будут эти решения, и&nbsp;тем лучше агент сможет не&nbsp;просто извлекать информацию, но&nbsp;и&nbsp;продуктивно применять ее&nbsp;на&nbsp;практике.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;словам Шармы, знания, необходимые для работы агента, должны быть не&nbsp;только всеобъемлющи, но&nbsp;и&nbsp;конкретны. Не&nbsp;надейтесь на&nbsp;то, что существующий организационный контекст будет ему понятен, советует&nbsp;он. Вместо этого в&nbsp;документах должно быть четко указано, что они охватывают, а&nbsp;что нет, кому они принадлежат и&nbsp;когда они в&nbsp;последний раз проверялись и&nbsp;валидировались. Такой уровень конкретики помогает агентам&nbsp;ИИ отличать авторитетную информацию от&nbsp;устаревших или неполных рекомендаций.&lltt;/p&ggtt;
&lltt;h3&ggtt;Когда институциональные знания устаревают&lltt;/h3&ggtt;
&lltt;p&ggtt;Все большее число организаций полагаются на&nbsp;ИИ-агентов, которые берут на&nbsp;себя работу, ранее выполнявшуюся людьми. По&nbsp;данным McKinsey, 88% организаций в&nbsp;настоящее время используют&nbsp;ИИ для выполнения по&nbsp;крайней мере одной бизнес-функции, по&nbsp;сравнению с&nbsp;78% годом ранее. И, согласно PwC, 79% опрошенных говорят, что агенты&nbsp;ИИ уже внедряются на&nbsp;их&nbsp;рабочих местах.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;мере того как эти агенты будут становиться все более распространенными, будут возникать и&nbsp;проблемы, связанные с&nbsp;использованием ими устаревшей, неполной или неверной базы знаний. Когда это происходит, проблема выходит за&nbsp;привычные рамки: если сотрудник сбит с&nbsp;толку документацией, с&nbsp;которой он&nbsp;знакомится, то&nbsp;он&nbsp;может, по&nbsp;крайней мере, обсудить это с&nbsp;коллегой или использовать для интерпретации свои суждения и&nbsp;прошлый опыт. Неэффективные или неправильные решения, принимаемые агентами&nbsp;ИИ из-за плохой документации, приводят к&nbsp;неправильной маршрутизации, неправильным утверждениям или отказам, несогласованному взаимодействию с&nbsp;клиентами&nbsp;и, возможно, тысячам автоматизированных действий, которые не&nbsp;должны были выполняться.&lltt;/p&ggtt;
&lltt;p&ggtt;Как только агент начинает действовать на&nbsp;основе неполной информации, возникают вопросы подотчетности, что делает управление особенно важным. Организации, которые успешно справляются с&nbsp;этой задачей, рассматривают управление знаниями не&nbsp;как документирование, а&nbsp;как часть операционной модели агента&nbsp;ИИ, говорит Шарма. Когда агент выдает неверный результат, команды должны знать, кому принадлежат знания, лежащие в&nbsp;его основе, когда они проверялись в&nbsp;последний раз и&nbsp;почему агент полагается на&nbsp;них.&lltt;/p&ggtt;
&lltt;p&ggtt;Надежное управление базой знаний, на&nbsp;основе которой принимаются агентные решения, может смягчить некоторые из&nbsp;этих проблем. Организациям следует прояснить ряд вопросов, касающихся информации, которую агенты&nbsp;ИИ используют для принятия решений:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; Кому принадлежат данные знания?&lltt;/li&ggtt;
	&lltt;li&ggtt; Кто обновляет&nbsp;их? Как часто?&lltt;/li&ggtt;
	&lltt;li&ggtt; Кто рассматривает и&nbsp;утверждает изменения?&lltt;/li&ggtt;
	&lltt;li&ggtt; Когда документ или его часть устаревают, кто и&nbsp;как их&nbsp;удаляет?&lltt;/li&ggtt;
	&lltt;li&ggtt; Когда официальная документация меняется, кто проводит аудит агентов&nbsp;ИИ, чтобы убедиться в&nbsp;понимании ими изменений?&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Без этих ответов организации рискуют разработать системы, автоматизирующие принятие неверных решений. «Агент уверенно выдает неверный ответ, основываясь на&nbsp;неверном источнике. Это хуже, чем отсутствие ответа. Это сбой системы управления, одобренный ИИ»,&nbsp;— сказал Шарма.&lltt;/p&ggtt;
&lltt;p&ggtt;Ответы на&nbsp;эти вопросы и&nbsp;понимание всеми заинтересованными лицами важности согласования этих ответов с&nbsp;базой знаний компании помогут избежать проблем с&nbsp;документацией при внедрении ИИ-агентов. Цель состоит в&nbsp;том, чтобы официальные знания, подготовленные для агентов, всегда были актуальными, четко сформулированными, авторитетными, структурированными, управляемыми и&nbsp;объяснимыми.&lltt;/p&ggtt;
&lltt;h3&ggtt;Убедитесь, что корпоративный источник истины готов к&nbsp;использованию ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Организации могут беспокоиться о&nbsp;том, что ИИ-агент не&nbsp;сможет должным образом разобраться в&nbsp;их&nbsp;бизнесе, но&nbsp;первым шагом должно стать обеспечение понимания бизнесом самого себя.&lltt;/p&ggtt;
&lltt;p&ggtt;Агенты ИИ&nbsp;не&nbsp;могут восполнить недостающий контекст или информацию так, как это могут сделать сотрудники. Они не&nbsp;могут согласовать противоречивые документы, вывести неписаные правила или признать, что «все знают», что процедура изменилась. Они принимают решения на&nbsp;основе институциональных знаний, предоставляемых организациями, и&nbsp;выявляют все слабые места или пробелы в&nbsp;этих знаниях. Предприятие, осознающее недостаточность своей базы знаний, получает неожиданную выгоду от&nbsp;того, что ему приходится сталкиваться с&nbsp;накопившимися несоответствиями и&nbsp;исправлять&nbsp;их, а&nbsp;также создавать систему управления, которая позволит ему продвигаться вперед с&nbsp;использованием более совершенной модели поддержания этих знаний.&lltt;/p&ggtt;
&lltt;p&ggtt;Подготовка институциональных знаний для ИИ&nbsp;— это задача управления контентом в&nbsp;дополнение к&nbsp;управленческому процессу. Организациям все чаще приходится переосмысливать не&nbsp;только&nbsp;то, что они документируют, но&nbsp;и&nbsp;то, как они структурируют, поддерживают и&nbsp;представляют эти знания, чтобы автоматизированные системы могли надежно их&nbsp;использовать.&lltt;/p&ggtt;]]></source>
<adate>20.08.2026</adate>
<dbid>235369</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект;;ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Ловушка ИИ-пилотов: почему бизнес теряет деньги на нейросетях]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235377]]></link>
<description><![CDATA[Компании продолжают вкладывать миллионы в нейросети, но всё чаще признают: результата нет. Разбираемся, почему пилоты не доходят до внедрения и что стоит изменить в подходе к ИИ уже сейчас. За последние два года искусственный интеллект прошел путь от модной новинки до строки в бюджете почти каждой крупной компании. Однако чем больше денег уходит на пилоты, тем острее встает вопрос: а где, собственно, отдача? По данным MIT NANDA, около 95% корпоративных ИИ-пилотов так и не доходят до измеримого финансового эффекта, а по оценке Gartner, довольны окупаемостью инвестиций менее 30% руководителей при среднем чеке проекта около 1,9 млн. долл. Похожая картина и в России. По данным издания «Ведомости», 95% отечественных компаний пока не окупают инвестиции в ИИ-технологии, хотя 40% называют искусственный интеллект главным трендом цифровизации. Проблема почти никогда не в самой технологии — модели давно умеют решать прикладные задачи. Проблема кроется в том, как компании выбирают, запускают и оценивают такие проекты. Почему пилоты не долетают до результата Первая причина — путаница между желанием попробовать технологию и реальной выгодой от ее внедрения. Аналитики фиксируют эффект «рабочего мусора»: сотрудники массово генерируют ИИ-контент, который выглядит готовым, но требует переделки. Формально ИИ внедрен, но по факту он просто перекладывает работу с одного этапа на другой. В результате вместо сокращения издержек компания получает двойную нагрузку: сначала сотрудник тратит время на формулировку запроса, затем — на проверку и доработку сгенерированного результата, а выгода от автоматизации сводится к нулю. Вторая причина — данные и процессы. Российские аналитики отмечают: около 90% проектов по генеративному ИИ в отечественных компаниях откладываются или закрываются не из-за качества моделей, а из-за неструктурированных данных и хаотичных регламентов, в которые нейросеть просто не вписывается. Внедрять ИИ в процесс, где нет единого источника данных и нет ответственного за результат, — заведомо неэффективно и не приведет к ожидаемому результату. Третья причина — отсутствие стратегии и метрик. Согласно исследованию МТС Web Services, лишь 26% российских компаний, закладывающих бюджет на ИИ, имеют четкую стратегию внедрения. Без понятных критериев успеха невозможно оценить окупаемость, а значит, проект существует скорее «для галочки», чем для бизнеса, и при первом же аудите бюджета или смене фокуса его свернут, списав затраты в убыток. Российская специфика: дорогие эксперименты и дефицит мощностей К управленческим проблемам добавляется инфраструктурная. По нашим данным, спрос на облачные GPU-мощности в России за первое полугодие 2026 года вырос на 507% год к году: число новых подключений увеличилось на 160%, а ежемесячная активность пользователей — на 260%. При этом дефицит высокопроизводительных ускорителей для обучения крупных моделей сохраняется: сроки поставки востребованных карт достигают 36-52 недель. По оценке отраслевых экспертов, совокупный разрыв в вычислительных мощностях между Россией и США измеряется сотнями раз, а весь российский рынок GPU-ускорителей для ИИ в 2025 году составил около 62,7 млрд. руб. — сумма, за которую крупные технологические экономики покупают буквально в разы больше вычислений. На практике это означает, что покупка собственного оборудования под эксперимент зачастую экономически нерациональна: один ускоритель уровня NVIDIA H200 стоит 30-40 тыс. долл., а полноценный сервер с восемью GPU — 300 тыс. долл. и выше, при том что жизненный цикл карты — всего 2-3 года. Компании, которые закладывают капитальные затраты на GPU в пилот, который может не взлететь, изначально закладывают в проект избыточный риск и одну из причин будущей низкой окупаемости. От ROI одной нейросети — к экономике процесса Ключевая ошибка, которую совершают почти все, — считать окупаемость самого ИИ-инструмента, а не изменения, которое он должен принести бизнесу. Исключение — ситуация, когда инструмент создается не для внутреннего использования, а как продукт для продажи на рынок: тогда его собственная окупаемость действительно становится главной метрикой. Поэтому рекомендуется считать не отдельный ROI (Return on Investment, коэффициент окупаемости инвестиций) чат-бота или копилота, а влияние на сквозной процесс — от заявки клиента до закрытия сделки, — и переходить к новой модели расчета: юнит-экономике с ИИ-агентами, где единицей измерения становится не человеко-час, а количество сценариев, закрытых без участия человека. На практике счет выглядит так. Сначала выбирается единица процесса — например, заявка клиента, доведенная от обращения до решения, — и фиксируется ее сегодняшняя стоимость: сумма человеко-часов, инструментов и накладных расходов, деленная на число закрытых единиц за период. Дальше внедряется ИИ-агент, и считается новая стоимость единицы — расходы на инфраструктуру и лицензии (или расходы на подписку или токены) плюс время сотрудников, которое еще нужно на контроль и разбор исключений. Разница до и после, умноженная на объем процесса, и есть реальная экономика проекта, а не абстрактный процент высвобожденного времени. Отдельно стоит следить за долей сценариев, закрытых без участия человека: если она растет от месяца к месяцу, изменение действительно масштабируется. Что делать прямо сейчас Универсального рецепта нет, но есть несколько работающих принципов. 	Считать метрику до старта, а не после. Пропишите одну фразу с цифрой и сроком — например, «сократить время обработки заявки с 4 часов до 40 минут за 3 месяца», и отдельно укажите, в каком экономическом эффекте это должно выразиться: например, в снижении затрат на найм дополнительных сотрудников, росте лояльности клиентов или увеличении среднего чека. Назначьте человека, который отвечает именно за эти показатели, а не за факт запуска проекта. 	Начинать с малого и наращивать масштаб. Берите один конкретный процесс, а не весь отдел целиком, и давайте пилоту 4-6 недель на одной команде. Если показатель из первого пункта сдвинулся — расширяйте на соседние процессы, если нет — меняйте гипотезу, а не бюджет. 	Заниматься данными и процессами, а не только моделью. Перед запуском проверьте на практике: сможет ли сотрудник за один день найти все данные, нужные для этого сценария, в одном месте, а не в трех разных системах и переписке. Если нет — сначала наведите порядок здесь, а не в выборе модели или ИИ-инструментов. 	Работать с командой, а не только с технологией. Назначьте внутри команды человека, который отвечает за процесс, и обсудите с сотрудниками до запуска, какие задачи берет на себя ИИ и что остается за ними: это снимает страх замены и превращает пилот в общий эксперимент, а не в решение, спущенное сверху. 	Не привязывать пилот к покупке оборудования. Один из вариантов — арендовать готовую инфраструктуру с почасовой оплатой: специализированные ИИ-платформы уже дают доступ и к GPU-серверам, и к готовым инференс-движкам, и к инструментам для разработки и автоматизации без необходимости собирать всё самостоятельно. Так эксперимент можно закрыть без потерь, если гипотеза не подтвердится, или быстро масштабировать, если она сработала. Наконец, стоит возвращаться к проекту не только на старте, а регулярно: сверять метрики каждые несколько месяцев и честно решать, масштабировать решение, дорабатывать или закрывать проект, а не держать его в статусе вечного пилота. И, главное, считать не окупаемость нейросети саму по себе, а то, как она меняет весь процесс целиком, — именно здесь чаще всего и находится реальная экономика, которую пропускают 70% руководителей, разочарованных в ИИ сегодня. #IMAGE_235378#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Компании продолжают вкладывать миллионы в&nbsp;нейросети, но&nbsp;всё чаще признают: результата нет. Разбираемся, почему пилоты не&nbsp;доходят до&nbsp;внедрения и&nbsp;что стоит изменить в&nbsp;подходе к&nbsp;ИИ уже сейчас.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;За&nbsp;последние два года искусственный интеллект прошел путь от&nbsp;модной новинки до&nbsp;строки в&nbsp;бюджете почти каждой крупной компании. Однако чем больше денег уходит на&nbsp;пилоты, тем острее встает вопрос: а&nbsp;где, собственно, отдача? По&nbsp;&lltt;a href="https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/"&ggtt;данным&lltt;/a&ggtt; MIT NANDA, около&nbsp;95% корпоративных ИИ-пилотов так и&nbsp;не&nbsp;доходят до&nbsp;измеримого финансового эффекта, а&nbsp;по&nbsp;&lltt;a href="https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence"&ggtt;оценке&lltt;/a&ggtt; Gartner, довольны окупаемостью инвестиций менее&nbsp;30% руководителей при среднем чеке проекта около 1,9&nbsp;млн. долл.&lltt;/p&ggtt;
&lltt;p&ggtt;Похожая картина и&nbsp;в&nbsp;России. По&nbsp;&lltt;a href="https://www.vedomosti.ru/global-ideas/articles/2026/06/02/1202053-vnedrenie-ii-biznes"&ggtt;данным&lltt;/a&ggtt; издания «Ведомости», 95% отечественных компаний пока не&nbsp;окупают инвестиции в&nbsp;ИИ-технологии, хотя&nbsp;40% называют искусственный интеллект главным трендом цифровизации. Проблема почти никогда не&nbsp;в&nbsp;самой технологии&nbsp;— модели давно умеют решать прикладные задачи. Проблема кроется в&nbsp;том, как компании выбирают, запускают и&nbsp;оценивают такие проекты.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему пилоты не&nbsp;долетают до&nbsp;результата&lltt;/h3&ggtt;
&lltt;p&ggtt;Первая причина&nbsp;— путаница между желанием попробовать технологию и&nbsp;реальной выгодой от&nbsp;ее&nbsp;внедрения. Аналитики фиксируют эффект «рабочего мусора»: сотрудники &lltt;a href="https://www.kommersant.ru/doc/8632735"&ggtt;массово генерируют&lltt;/a&ggtt; ИИ-контент, который выглядит готовым, но&nbsp;требует переделки. Формально ИИ&nbsp;внедрен, но&nbsp;по&nbsp;факту он&nbsp;просто перекладывает работу с&nbsp;одного этапа на&nbsp;другой. В&nbsp;результате вместо сокращения издержек компания получает двойную нагрузку: сначала сотрудник тратит время на&nbsp;формулировку запроса, затем&nbsp;— на&nbsp;проверку и&nbsp;доработку сгенерированного результата, а&nbsp;выгода от&nbsp;автоматизации сводится к&nbsp;нулю.&lltt;/p&ggtt;
&lltt;p&ggtt;Вторая причина&nbsp;— данные и&nbsp;процессы. Российские аналитики &lltt;a href="https://www.cnews.ru/news/top/2026-03-24_biznes_svernul_ili_zamorozil"&ggtt;отмечают&lltt;/a&ggtt;: около&nbsp;90% проектов по&nbsp;генеративному&nbsp;ИИ в&nbsp;отечественных компаниях откладываются или закрываются не&nbsp;из-за качества моделей, а&nbsp;из-за неструктурированных данных и&nbsp;хаотичных регламентов, в&nbsp;которые нейросеть просто не&nbsp;вписывается. Внедрять ИИ&nbsp;в&nbsp;процесс, где нет единого источника данных и&nbsp;нет ответственного за&nbsp;результат,&nbsp;— заведомо неэффективно и&nbsp;не&nbsp;приведет к&nbsp;ожидаемому результату.&lltt;/p&ggtt;
&lltt;p&ggtt;Третья причина&nbsp;— отсутствие стратегии и&nbsp;метрик. Согласно &lltt;a href="https://www.cnews.ru/news/top/2025-12-19_bolshinstvo_rossijskih_kompanij"&ggtt;исследованию&lltt;/a&ggtt; МТС Web Services, лишь&nbsp;26% российских компаний, закладывающих бюджет на&nbsp;ИИ, имеют четкую стратегию внедрения. Без понятных критериев успеха невозможно оценить окупаемость, а&nbsp;значит, проект существует скорее «для галочки», чем для бизнеса, и&nbsp;при первом&nbsp;же аудите бюджета или смене фокуса его свернут, списав затраты в&nbsp;убыток.&lltt;/p&ggtt;
&lltt;h3&ggtt;Российская специфика: дорогие эксперименты и&nbsp;дефицит мощностей&lltt;/h3&ggtt;
&lltt;p&ggtt;К&nbsp;управленческим проблемам добавляется инфраструктурная. По&nbsp;&lltt;a href="http://reg.ru/company/news/12957"&ggtt;нашим данным&lltt;/a&ggtt;, спрос на&nbsp;облачные GPU-мощности в&nbsp;России за&nbsp;первое полугодие 2026 года вырос на&nbsp;507% год к&nbsp;году: число новых подключений увеличилось на&nbsp;160%, а&nbsp;ежемесячная активность пользователей&nbsp;— на&nbsp;260%. При этом дефицит высокопроизводительных ускорителей для обучения крупных моделей сохраняется: сроки поставки востребованных карт достигают &lltt;nobr&ggtt;36-52 недель.&lltt;/nobr&ggtt; По&nbsp;оценке &lltt;a href="https://www.comnews.ru/content/245257/2026-05-14/2026-w20/1008/vychislitelnyy-tupik-pochemu-rossiyskiy-ii-ostaetsya-bez-moschnostey"&ggtt;отраслевых экспертов&lltt;/a&ggtt;, совокупный разрыв в&nbsp;вычислительных мощностях между Россией и&nbsp;США измеряется сотнями раз, а&nbsp;весь российский рынок GPU-ускорителей для&nbsp;ИИ в&nbsp;2025 году составил около 62,7&nbsp;млрд. руб. —&nbsp;сумма, за&nbsp;которую крупные технологические экономики покупают буквально в&nbsp;разы больше вычислений.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;практике это означает, что покупка собственного оборудования под эксперимент зачастую экономически нерациональна: один ускоритель уровня NVIDIA H200 стоит &lltt;nobr&ggtt;30-40 тыс.&lltt;/nobr&ggtt; долл., а&nbsp;полноценный сервер с&nbsp;восемью GPU&nbsp;— 300&nbsp;тыс. долл.&nbsp;и&nbsp;выше, при том что жизненный цикл карты&nbsp;— всего &lltt;nobr&ggtt;2-3 года.&lltt;/nobr&ggtt; Компании, которые закладывают капитальные затраты на&nbsp;GPU в&nbsp;пилот, который может не&nbsp;взлететь, изначально закладывают в&nbsp;проект избыточный риск и&nbsp;одну из&nbsp;причин будущей низкой окупаемости.&lltt;/p&ggtt;
&lltt;h3&ggtt;От&nbsp;ROI одной нейросети&nbsp;— к&nbsp;экономике процесса&lltt;/h3&ggtt;
&lltt;p&ggtt;Ключевая ошибка, которую совершают почти все,&nbsp;— считать окупаемость самого ИИ-инструмента, а&nbsp;не&nbsp;изменения, которое он&nbsp;должен принести бизнесу. Исключение&nbsp;— ситуация, когда инструмент создается не&nbsp;для внутреннего использования, а&nbsp;как продукт для продажи на&nbsp;рынок: тогда его собственная окупаемость действительно становится главной метрикой. Поэтому рекомендуется считать не&nbsp;отдельный ROI (Return on&nbsp;Investment, коэффициент окупаемости инвестиций) чат-бота или копилота, а&nbsp;влияние на&nbsp;сквозной процесс&nbsp;— от&nbsp;заявки клиента до&nbsp;закрытия сделки,&nbsp;— и&nbsp;переходить к&nbsp;новой модели расчета: юнит-экономике с&nbsp;ИИ-агентами, где единицей измерения становится не&nbsp;человеко-час, а&nbsp;количество сценариев, закрытых без участия человека.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;практике счет выглядит так. Сначала выбирается единица процесса&nbsp;— например, заявка клиента, доведенная от&nbsp;обращения до&nbsp;решения,&nbsp;— и&nbsp;фиксируется ее&nbsp;сегодняшняя стоимость: сумма человеко-часов, инструментов и&nbsp;накладных расходов, деленная на&nbsp;число закрытых единиц за&nbsp;период. Дальше внедряется ИИ-агент, и&nbsp;считается новая стоимость единицы&nbsp;— расходы на&nbsp;инфраструктуру и&nbsp;лицензии (или расходы на&nbsp;подписку или токены) плюс время сотрудников, которое еще нужно на&nbsp;контроль и&nbsp;разбор исключений. Разница до&nbsp;и&nbsp;после, умноженная на&nbsp;объем процесса, и&nbsp;есть реальная экономика проекта, а&nbsp;не&nbsp;абстрактный процент высвобожденного времени. Отдельно стоит следить за&nbsp;долей сценариев, закрытых без участия человека: если она растет от&nbsp;месяца к&nbsp;месяцу, изменение действительно масштабируется.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что делать прямо сейчас&lltt;/h3&ggtt;
&lltt;p&ggtt;Универсального рецепта нет, но&nbsp;есть несколько работающих принципов.&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt;Считать метрику до&nbsp;старта, а&nbsp;не&nbsp;после. &lltt;/strong&ggtt;Пропишите одну фразу с&nbsp;цифрой и&nbsp;сроком&nbsp;— например, «сократить время обработки заявки с&nbsp;4&nbsp;часов до&nbsp;40&nbsp;минут за&nbsp;3&nbsp;месяца», и&nbsp;отдельно укажите, в&nbsp;каком экономическом эффекте это должно выразиться: например, в&nbsp;снижении затрат на&nbsp;найм дополнительных сотрудников, росте лояльности клиентов или увеличении среднего чека. Назначьте человека, который отвечает именно за&nbsp;эти показатели, а&nbsp;не&nbsp;за&nbsp;факт запуска проекта.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Начинать с&nbsp;малого и&nbsp;наращивать масштаб. &lltt;/strong&ggtt;Берите один конкретный процесс, а&nbsp;не&nbsp;весь отдел целиком, и&nbsp;давайте пилоту &lltt;nobr&ggtt;4-6&lltt;/nobr&ggtt; недель на&nbsp;одной команде. Если показатель из&nbsp;первого пункта сдвинулся&nbsp;— расширяйте на&nbsp;соседние процессы, если нет&nbsp;— меняйте гипотезу, а&nbsp;не&nbsp;бюджет.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Заниматься данными и&nbsp;процессами, а&nbsp;не&nbsp;только моделью.&lltt;/strong&ggtt; Перед запуском проверьте на&nbsp;практике: сможет&nbsp;ли сотрудник за&nbsp;один день найти все данные, нужные для этого сценария, в&nbsp;одном месте, а&nbsp;не&nbsp;в&nbsp;трех разных системах и&nbsp;переписке. Если нет&nbsp;— сначала наведите порядок здесь, а&nbsp;не&nbsp;в&nbsp;выборе модели или ИИ-инструментов.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Работать с&nbsp;командой, а&nbsp;не&nbsp;только с&nbsp;технологией. &lltt;/strong&ggtt;Назначьте внутри команды человека, который отвечает за&nbsp;процесс, и&nbsp;обсудите с&nbsp;сотрудниками до&nbsp;запуска, какие задачи берет на&nbsp;себя&nbsp;ИИ и&nbsp;что остается за&nbsp;ними: это снимает страх замены и&nbsp;превращает пилот в&nbsp;общий эксперимент, а&nbsp;не&nbsp;в&nbsp;решение, спущенное сверху.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt;Не&nbsp;привязывать пилот к&nbsp;покупке оборудования.&lltt;/strong&ggtt; Один из&nbsp;вариантов&nbsp;— арендовать готовую инфраструктуру с&nbsp;почасовой оплатой: специализированные ИИ-платформы уже дают доступ и&nbsp;к&nbsp;GPU-серверам, и&nbsp;к&nbsp;готовым инференс-движкам, и&nbsp;к&nbsp;инструментам для разработки и&nbsp;автоматизации без необходимости собирать всё самостоятельно. Так эксперимент можно закрыть без потерь, если гипотеза не&nbsp;подтвердится, или быстро масштабировать, если она сработала.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Наконец, стоит возвращаться к&nbsp;проекту не&nbsp;только на&nbsp;старте, а&nbsp;регулярно: сверять метрики каждые несколько месяцев и&nbsp;честно решать, масштабировать решение, дорабатывать или закрывать проект, а&nbsp;не&nbsp;держать его в&nbsp;статусе вечного пилота. И, главное, считать не&nbsp;окупаемость нейросети саму по&nbsp;себе, а&nbsp;то, как она меняет весь процесс целиком,&nbsp;— именно здесь чаще всего и&nbsp;находится реальная экономика, которую пропускают&nbsp;70% руководителей, разочарованных в&nbsp;ИИ сегодня.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235378#&lltt;/p&ggtt;]]></source>
<adate>20.08.2026</adate>
<dbid>235377</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/8bd/h0l6lefusqkwt52f8knfobtzaxplsyot.jpg]]>
</images>
<imagesname><![CDATA[;;Евгений Мартынов, директор по информационным технологиям Рег.облака   ]]></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Вышло обновление Basis Dynamix Cloud Control 5.6]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235376]]></link>
<description><![CDATA[Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — решения для управления кластерами, расположенными в разных ЦОД, а также мажорной версии 3.0 встроенного модуля для развертывания сервисов в облаке Basis Automation Studio. Ключевыми изменениями релизов стали переработанная ролевая модель доступа пользователей, обновленная архитектура развертывания сервисов, новые инструменты управления ресурсами и углубление интеграции платформы с другими решениями экосистемы «Базис». Платформа Basis Dynamix Cloud Control предназначена для управления через единый портал частными и публичными облаками, построенными на базе различных платформ виртуализации — Basis Dynamix Enterprise, Basis Dynamix Standard, VMware vSphere и РУСТЭК. На смену встроенной ролевой модели в Basis Dynamix Cloud Control 5.6 пришла новая гибкая модель разграничения доступа, что позволяет администратору назначать права в точном соответствии с полномочиями пользователей. Переход на новую модель выполняется автоматически при обновлении инсталляции продукта: права пользователей мигрируют в новую структуру без ручной перенастройки. Вместе с новой моделью администраторы получили более удобные инструменты для работы с ролями, включая их клонирование — при копировании переносятся уровни доступа, права доступа и правила фильтрации исходной роли. В новой модели предусмотрены встроенные роли по умолчанию, готовые к использованию без дополнительной настройки. Поддерживается управление жизненным циклом пользовательских ролей для точечного предоставления необходимых прав на различные объекты. При архивировании учетной записи вместе с объектами доступа снимаются все связанные роли. В релизе 5.6 была существенно расширена функциональность сегментов Basis Dynamix Standard. Пользователям получили новые возможности, ранее уже доступные в других сегментах: поддержка сетей, роутеров, балансировщиков нагрузки, профилей безопасности и внешних систем хранения данных. Логика построения виртуальной сети стала более гибкой: маршрут по умолчанию на роутере создается автоматически, если пользователь не задал собственный. При этом в конфигурациях с несколькими роутерами разрешены удаление последнего порта роутера и отключение сети от роутера. Для облачных сегментов Basis Dynamix Enterprise в новом релизе была добавлена поддержка сервиса резервного копирования на базе Basis Virtual Protect — решения компании «Базис» для управления жизненным циклом резервных копий виртуальных машин. Администратор может подключить настроенный сервис к одному или нескольким сегментам Basis Dynamix Enterprise, для которых должны быть доступны инструменты резервного копирования. Автоматическая синхронизация изменений виртуальной инфраструктуры сегментов Basis Dynamix Enterprise дополнена операциями со снапшотами — созданием, восстановлением и удалением. Синхронизация в фоновом режиме помогает администратору поддерживать согласованность виртуальной инфраструктуры между платформой виртуализации и решением Basis Dynamix Cloud Control, что важно, например, при выполнении сервисных действий с серверами и дисками. Наконец, реализовано взаимодействие Basis Dynamix Cloud Control с платформой виртуализации Basis Dynamix Enterprise через учетную запись Basis Virtual Security — решения компании «Базис», предназначенного для защиты виртуальной инфраструктуры. В новом релизе Basis Dynamix Cloud Control особое внимание было уделено контролю над объёмом предоставляемых ресурсов, обеспечению предсказуемого потребления и оптимизации затрат. На уровне виртуального центра обработки данных (ВЦОД) введены лимиты и механизм согласования выделяемых ресурсов, дающие администраторам предсказуемый контроль над потреблением в рамках отдельных ВЦОД. Для облачных сегментов на платформе Basis Dynamix Enterprise реализовано управление коэффициентом и режимом переподписки виртуальных процессоров (vCPU), что позволяет администратору гибко регулировать плотность размещения виртуальных машин. Коэффициент переподписки определяет, сколько ядер vCPU будет приходиться на одно ядро физического процессора и отдельно указывается для каждого физического сервера. При отсутствии ограничений Basis Dynamix Cloud Control будет использовать для запуска виртуальных серверов любые узлы с достаточными ресурсами. При включенном режиме строгой переподписки виртуальные серверы не будут запускаться на физических узлах, если у тех недостаточно свободных ядер vCPU. Basis Automation Studio — это модуль Basis Dynamix Cloud Control, который представляет собой среду автоматизации развёртывания приложений и сервисов. С его помощью администратор платформы может управлять жизненным циклом облачных сервисов, работать с шаблонами и компонентами, публиковать готовые сервисы на витрине и предлагать их пользователям. Для Basis Automation Studio 3.0 одним из наиболее важных изменений стала смена архитектуры — модуль переведен на отказоустойчивую архитектуру в кластере Kubernetes. Компоненты Basis Automation Studio, включая контейнеры оркестратора и базу данных, работают в конфигурации высокой доступности: при выходе из строя отдельного узла нагрузка автоматически перераспределяется на оставшиеся узлы, работа платформы не прерывается. Для хранения общих данных используется распределенное отказоустойчивое хранилище, для базы данных — управление средствами оператора Kubernetes. Наряду с отказоустойчивостью появилось горизонтальное масштабирование: количество экземпляров ключевых сервисов задается при развертывании, что позволяет наращивать производительность платформы под растущую нагрузку без изменения ее архитектуры. Еще одним важным новшеством Basis Automation Studio 3.0 стало появление динамических провайдеров, которые предоставляют возможность создания динамических типов данных при заказе сервиса. Благодаря этому модуль может обращаться к внешним системам и возвращать в форму заказа вместо статичных полей актуальные данные, вычисляемые по пользовательским сценариям в изолированной среде выполнения. Динамические провайдеры отображаются на карточке домена и проекта. Внутри них дополнительно добавлен программный интерфейс управления динамическими типами провайдера для запуска пользовательских скриптов. Как и в Basis Dynamix Cloud Control, в модуле Basis Automation Studio 3.0 была переработана ролевая модель. Права доступа теперь задаются на уровне отдельных API-методов, сгруппированных по управляемым сущностям. Каждая роль привязана к области видимости: платформе, домену или проекту, — которая определяет предельный набор доступных действий. Пользователь привязывается к одной области видимости, но ему можно назначить несколько ролей, в том числе стандартных — в таком случае права доступа суммируются. «Приоритетными направлениями развития нашей облачной платформы Basis Dynamix Cloud Control остаются расширение возможностей управления виртуальной инфраструктурой и повышение совместимости облачного решения с другими продуктами экосистемы „Базиса“. В релизе 5.6 мы сделали несколько значительных шагов в обоих направлениях. Что касается нашего решения для управления облачными сервисами, перевод Basis Automation Studio на новую k8s-архитектуру позволит перемещать рабочую нагрузку без остановки работы продукта. Кроме того, для удобства работы с модулем мы внедрили динамические провайдеры и расширили возможности графического интерфейса платформы», — отметил Дмитрий Сорокин, технический директор компании «Базис»]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — решения для управления кластерами, расположенными в разных ЦОД, а также мажорной версии 3.0 встроенного модуля для развертывания сервисов в облаке Basis Automation Studio. Ключевыми изменениями релизов стали переработанная ролевая модель доступа пользователей, обновленная архитектура развертывания сервисов, новые инструменты управления ресурсами и углубление интеграции платформы с другими решениями экосистемы «Базис».&lltt;/p&ggtt;
&lltt;p&ggtt;Платформа Basis Dynamix Cloud Control предназначена для управления через единый портал частными и публичными облаками, построенными на базе различных платформ виртуализации — Basis Dynamix Enterprise, Basis Dynamix Standard, VMware vSphere и РУСТЭК.&lltt;/p&ggtt;
&lltt;p&ggtt;На смену встроенной ролевой модели в Basis Dynamix Cloud Control 5.6 пришла новая гибкая модель разграничения доступа, что позволяет администратору назначать права в точном соответствии с полномочиями пользователей. Переход на новую модель выполняется автоматически при обновлении инсталляции продукта: права пользователей мигрируют в новую структуру без ручной перенастройки. Вместе с новой моделью администраторы получили более удобные инструменты для работы с ролями, включая их клонирование — при копировании переносятся уровни доступа, права доступа и правила фильтрации исходной роли.&lltt;/p&ggtt;
&lltt;p&ggtt;В новой модели предусмотрены встроенные роли по умолчанию, готовые к использованию без дополнительной настройки. Поддерживается управление жизненным циклом пользовательских ролей для точечного предоставления необходимых прав на различные объекты. При архивировании учетной записи вместе с объектами доступа снимаются все связанные роли.&lltt;/p&ggtt;
&lltt;p&ggtt;В релизе 5.6 была существенно расширена функциональность сегментов Basis Dynamix Standard. Пользователям получили новые возможности, ранее уже доступные в других сегментах: поддержка сетей, роутеров, балансировщиков нагрузки, профилей безопасности и внешних систем хранения данных. Логика построения виртуальной сети стала более гибкой: маршрут по умолчанию на роутере создается автоматически, если пользователь не задал собственный. При этом в конфигурациях с несколькими роутерами разрешены удаление последнего порта роутера и отключение сети от роутера.&lltt;/p&ggtt;
&lltt;p&ggtt;Для облачных сегментов Basis Dynamix Enterprise в новом релизе была добавлена поддержка сервиса резервного копирования на базе Basis Virtual Protect — решения компании «Базис» для управления жизненным циклом резервных копий виртуальных машин. Администратор может подключить настроенный сервис к одному или нескольким сегментам Basis Dynamix Enterprise, для которых должны быть доступны инструменты резервного копирования. &lltt;/p&ggtt;
&lltt;p&ggtt;Автоматическая синхронизация изменений виртуальной инфраструктуры сегментов Basis Dynamix Enterprise дополнена операциями со снапшотами — созданием, восстановлением и удалением. Синхронизация в фоновом режиме помогает администратору поддерживать согласованность виртуальной инфраструктуры между платформой виртуализации и решением Basis Dynamix Cloud Control, что важно, например, при выполнении сервисных действий с серверами и дисками.&lltt;/p&ggtt;
&lltt;p&ggtt;Наконец, реализовано взаимодействие Basis Dynamix Cloud Control с платформой виртуализации Basis Dynamix Enterprise через учетную запись Basis Virtual Security — решения компании «Базис», предназначенного для защиты виртуальной инфраструктуры. &lltt;/p&ggtt;
&lltt;p&ggtt;В новом релизе Basis Dynamix Cloud Control особое внимание было уделено контролю над объёмом предоставляемых ресурсов, обеспечению предсказуемого потребления и оптимизации затрат. На уровне виртуального центра обработки данных (ВЦОД) введены лимиты и механизм согласования выделяемых ресурсов, дающие администраторам предсказуемый контроль над потреблением в рамках отдельных ВЦОД.&lltt;/p&ggtt;
&lltt;p&ggtt;Для облачных сегментов на платформе Basis Dynamix Enterprise реализовано управление коэффициентом и режимом переподписки виртуальных процессоров (vCPU), что позволяет администратору гибко регулировать плотность размещения виртуальных машин. Коэффициент переподписки определяет, сколько ядер vCPU будет приходиться на одно ядро физического процессора и отдельно указывается для каждого физического сервера. При отсутствии ограничений Basis Dynamix Cloud Control будет использовать для запуска виртуальных серверов любые узлы с достаточными ресурсами. При включенном режиме строгой переподписки виртуальные серверы не будут запускаться на физических узлах, если у тех недостаточно свободных ядер vCPU.&lltt;/p&ggtt;
&lltt;p&ggtt;Basis Automation Studio — это модуль Basis Dynamix Cloud Control, который представляет собой среду автоматизации развёртывания приложений и сервисов. С его помощью администратор платформы может управлять жизненным циклом облачных сервисов, работать с шаблонами и компонентами, публиковать готовые сервисы на витрине и предлагать их пользователям.&lltt;/p&ggtt;
&lltt;p&ggtt;Для Basis Automation Studio 3.0 одним из наиболее важных изменений стала смена архитектуры — модуль переведен на отказоустойчивую архитектуру в кластере Kubernetes. Компоненты Basis Automation Studio, включая контейнеры оркестратора и базу данных, работают в конфигурации высокой доступности: при выходе из строя отдельного узла нагрузка автоматически перераспределяется на оставшиеся узлы, работа платформы не прерывается. Для хранения общих данных используется распределенное отказоустойчивое хранилище, для базы данных — управление средствами оператора Kubernetes.&lltt;/p&ggtt;
&lltt;p&ggtt;Наряду с отказоустойчивостью появилось горизонтальное масштабирование: количество экземпляров ключевых сервисов задается при развертывании, что позволяет наращивать производительность платформы под растущую нагрузку без изменения ее архитектуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще одним важным новшеством Basis Automation Studio 3.0 стало появление динамических провайдеров, которые предоставляют возможность создания динамических типов данных при заказе сервиса. Благодаря этому модуль может обращаться к внешним системам и возвращать в форму заказа вместо статичных полей актуальные данные, вычисляемые по пользовательским сценариям в изолированной среде выполнения.&lltt;/p&ggtt;
&lltt;p&ggtt;Динамические провайдеры отображаются на карточке домена и проекта. Внутри них дополнительно добавлен программный интерфейс управления динамическими типами провайдера для запуска пользовательских скриптов.&lltt;/p&ggtt;
&lltt;p&ggtt;Как и в Basis Dynamix Cloud Control, в модуле Basis Automation Studio 3.0 была переработана ролевая модель. Права доступа теперь задаются на уровне отдельных API-методов, сгруппированных по управляемым сущностям. Каждая роль привязана к области видимости: платформе, домену или проекту, — которая определяет предельный набор доступных действий. Пользователь привязывается к одной области видимости, но ему можно назначить несколько ролей, в том числе стандартных — в таком случае права доступа суммируются.&lltt;/p&ggtt;
&lltt;p&ggtt;«Приоритетными направлениями развития нашей облачной платформы Basis Dynamix Cloud Control остаются расширение возможностей управления виртуальной инфраструктурой и повышение совместимости облачного решения с другими продуктами экосистемы „Базиса“. В релизе 5.6 мы сделали несколько значительных шагов в обоих направлениях. Что касается нашего решения для управления облачными сервисами, перевод Basis Automation Studio на новую k8s-архитектуру позволит перемещать рабочую нагрузку без остановки работы продукта. Кроме того, для удобства работы с модулем мы внедрили динамические провайдеры и расширили возможности графического интерфейса платформы», — отметил Дмитрий Сорокин, технический директор компании «Базис».&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235376</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Облака/ИТ-сервисы]]></tag>
</item>
<item>
<title><![CDATA[В системе управления перевозками Saby TMS можно подписывать ЭПД с телефона с помощью Рутокен ЭЦП 3.0 NFC]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235373]]></link>
<description><![CDATA[С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок. Для транспортных компаний это означает переход от бумажного документооборота к работе с электронными документами непосредственно на маршруте. Saby TMS позволяет оформлять и обрабатывать электронные транспортные документы и поддерживает удобный сценарий их подписания — с помощью Рутокен ЭЦП 3.0 NFC. Устройство Рутокен разработано и выпускается компанией «Актив». Раньше сотруднику, которому необходимо подписать ЭТрН КЭП, требовался компьютер или специальный переходник для подключения токена к смартфону. С Рутокен ЭЦП 3.0 NFC достаточно иметь смартфон с NFC и мобильное приложение Saby TMS. Сотрудник прикладывает Рутокен к смартфону и подписание документа происходит «на борту» устройства Рутокен, без копирования ключа подписи в память мобильного устройства. Такой сценарий особенно удобен водителям и экспедиторам, которым важно работать с документами прямо на маршруте, а не возвращаться в офис. «Для перевозчика важно, чтобы электронный документооборот не привязывал водителя к компьютеру или офису. Все действия с ЭТрН — от получения документа до его подписания — должны выполняться там, где происходит перевозка: на погрузке, выгрузке или в пути. Поддержка Рутокен ЭЦП 3.0 NFC в Saby TMS дает компаниям еще один удобный способ организовать такой мобильный сценарий и при этом использовать привычную КЭП», — отметил Денис Малышев, руководитель направления автоматизации логистики Saby TMS. «Мы видим тренд на мобильное подписание ЭТрН с использованием защищенных ключевых носителей. Рутокен ЭЦП 3.0 NFC позволяет перенести привычный сценарий работы с КЭП со стационарного компьютера на смартфон: достаточно приложить Рутокен к мобильному устройству с NFC для подписания документа. Совместимость с Saby TMS позволит использовать этот подход непосредственно в процессах грузоперевозок и дать бизнесу большую гибкость без компромиссов в безопасности», — поделился Анфимов Павел, заместитель директора по управлению продуктами, компания «Актив». В Saby TMS транспортные компании ведут основные документы — транспортные накладные, путевые листы, заказы на перевозку — прямо во время рейса. Для подписания через NFC понадобятся: смартфон с поддержкой NFC (iOS или Android), мобильное приложение Saby TMS и Рутокен ЭЦП 3.0 NFC с сертификатом и ключами электронной подписи]]></description>
<source><![CDATA[&lltt;p&ggtt;С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок. Для транспортных компаний это означает переход от бумажного документооборота к работе с электронными документами непосредственно на маршруте. Saby TMS позволяет оформлять и обрабатывать электронные транспортные документы и поддерживает удобный сценарий их подписания — с помощью Рутокен ЭЦП 3.0 NFC. Устройство Рутокен разработано и выпускается компанией «Актив».&lltt;/p&ggtt;
&lltt;p&ggtt;Раньше сотруднику, которому необходимо подписать ЭТрН КЭП, требовался компьютер или специальный переходник для подключения токена к смартфону. С Рутокен ЭЦП 3.0 NFC достаточно иметь смартфон с NFC и мобильное приложение Saby TMS.&lltt;/p&ggtt;
&lltt;p&ggtt;Сотрудник прикладывает Рутокен к смартфону и подписание документа происходит «на борту» устройства Рутокен, без копирования ключа подписи в память мобильного устройства. Такой сценарий особенно удобен водителям и экспедиторам, которым важно работать с документами прямо на маршруте, а не возвращаться в офис.&lltt;/p&ggtt;
&lltt;p&ggtt;«Для перевозчика важно, чтобы электронный документооборот не привязывал водителя к компьютеру или офису. Все действия с ЭТрН — от получения документа до его подписания — должны выполняться там, где происходит перевозка: на погрузке, выгрузке или в пути. Поддержка Рутокен ЭЦП 3.0 NFC в Saby TMS дает компаниям еще один удобный способ организовать такой мобильный сценарий и при этом использовать привычную КЭП», — отметил Денис Малышев, руководитель направления автоматизации логистики Saby TMS.&lltt;/p&ggtt;
&lltt;p&ggtt;«Мы видим тренд на мобильное подписание ЭТрН с использованием защищенных ключевых носителей. Рутокен ЭЦП 3.0 NFC позволяет перенести привычный сценарий работы с КЭП со стационарного компьютера на смартфон: достаточно приложить Рутокен к мобильному устройству с NFC для подписания документа. Совместимость с Saby TMS позволит использовать этот подход непосредственно в процессах грузоперевозок и дать бизнесу большую гибкость без компромиссов в безопасности», — поделился Анфимов Павел, заместитель директора по управлению продуктами, компания «Актив».&lltt;/p&ggtt;
&lltt;p&ggtt;В Saby TMS транспортные компании ведут основные документы — транспортные накладные, путевые листы, заказы на перевозку — прямо во время рейса.&lltt;/p&ggtt;
&lltt;p&ggtt;Для подписания через NFC понадобятся: смартфон с поддержкой NFC (iOS или Android), мобильное приложение Saby TMS и Рутокен ЭЦП 3.0 NFC с сертификатом и ключами электронной подписи.&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235373</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Indeed ITDR 2.2: больше сценариев MFA и улучшенный пользовательский опыт]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235375]]></link>
<description><![CDATA[Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для своевременного выявления и реагирования на угрозы, связанные с компрометацией айдентити. Обновление расширяет сценарии применения многофакторной аутентификации, улучшает пользовательский опыт при работе в консоли администрирования и упрощает развертывание решения в корпоративной инфраструктуре. Сегодня для защиты корпоративной инфраструктуры недостаточно контролировать только доступ пользователя в систему. Не менее важно отслеживать дальнейшую активность учетных записей и своевременно реагировать на подозрительные действия. Эти возможности получили развитие в новой версии Indeed ITDR 2.2. Одно из ключевых нововведений в Indeed ITDR 2.2 — подтверждение дополнительного фактора входа с помощью одноразовых паролей (OTP), основанных на времени (time-based one-time passwords, TOTP). Обновление расширяет интеграцию с Indeed Access Manager и позволяет использовать существующую инфраструктуру аутентификации в сценариях Indeed ITDR. Поддержка ТOTP особенно актуальна для организаций с закрытыми инфраструктурами без доступа к внешним сетям, где использование push-уведомлений невозможно. Кроме того, пользователи могут применять сторонние приложения-аутентификаторы, поддерживающие стандарт TOTP. Ввод одноразового пароля выполняется через легковесное приложение, устанавливаемое на рабочих станциях под управлением Windows. Оно своевременно отображает запрос на подтверждение дополнительного фактора. В рамках дальнейшего развития продукта планируется добавить поддержку одноразовых паролей через SMS, электронную почту и физические носители. В версии 2.2 компания «Индид» значительно расширила возможности работы с журналом событий доступа. На странице «События» консоли администрирования появилась гибкая система фильтрации по пользователю, ресурсу, протоколу, IP-адресу и контроллеру домена. Также улучшен интерфейс фильтрации по времени возникновения события и оптимизировано хранение данных, что повышает производительность поиска. Обновленный интерфейс упрощает работу с Indeed ITDR и позволяет быстрее находить необходимые события при анализе подозрительной активности, расследовании инцидентов и оценке рисков безопасности. Другие изменения Indeed ITDR делают более удобным развертывание продукта в инфраструктурах, где интеграция с Indeed Access Manager не требуется. Компонент Indeed Key Server теперь можно установить на отдельный узел с помощью единого сценария установки. Это упрощает развертывание сервера в демилитаризованной зоне (DMZ) и избавляет администраторов от необходимости вручную изменять конфигурационные файлы. В новой версии расширен набор сценариев обнаружения атак. Indeed ITDR теперь выявляет такие техники, как Golden PAC и SAM Account Spoofing, что позволяет эффективнее обнаруживать попытки компрометации доменной инфраструктуры. Кроме того, улучшена совместимость с различными вариантами TLS-сертификатов, включая сертификаты LDAPS без расширения SAN, а также сертификаты с именем субъекта в формате Distinguished Name. «Мы последовательно улучшаем Indeed ITDR, расширяя сценарии внедрения продукта и добавляя новые возможности детектирования. Наша задача — помочь организациям своевременно реагировать на угрозы, связанные с учетными данными, не перестраивая существующую инфраструктуру. При этом для нас важно обеспечить удобство работы как для пользователей, так и для специалистов по информационной безопасности и администраторов. Последние обновления отражают наиболее частые пожелания, которые мы получаем в процессе внедрения наших продуктов», — отметил Лев Овчинников, руководитель продукта Indeed ITDR в компании «Индид»]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для своевременного выявления и реагирования на угрозы, связанные с компрометацией айдентити. Обновление расширяет сценарии применения многофакторной аутентификации, улучшает пользовательский опыт при работе в консоли администрирования и упрощает развертывание решения в корпоративной инфраструктуре.&lltt;/p&ggtt;
&lltt;p&ggtt;Сегодня для защиты корпоративной инфраструктуры недостаточно контролировать только доступ пользователя в систему. Не менее важно отслеживать дальнейшую активность учетных записей и своевременно реагировать на подозрительные действия. Эти возможности получили развитие в новой версии Indeed ITDR 2.2.&lltt;/p&ggtt;
&lltt;p&ggtt;Одно из ключевых нововведений в Indeed ITDR 2.2 — подтверждение дополнительного фактора входа с помощью одноразовых паролей (OTP), основанных на времени (time-based one-time passwords, TOTP). Обновление расширяет интеграцию с Indeed Access Manager и позволяет использовать существующую инфраструктуру аутентификации в сценариях Indeed ITDR.&lltt;/p&ggtt;
&lltt;p&ggtt;Поддержка ТOTP особенно актуальна для организаций с закрытыми инфраструктурами без доступа к внешним сетям, где использование push-уведомлений невозможно. Кроме того, пользователи могут применять сторонние приложения-аутентификаторы, поддерживающие стандарт TOTP.&lltt;/p&ggtt;
&lltt;p&ggtt;Ввод одноразового пароля выполняется через легковесное приложение, устанавливаемое на рабочих станциях под управлением Windows. Оно своевременно отображает запрос на подтверждение дополнительного фактора. В рамках дальнейшего развития продукта планируется добавить поддержку одноразовых паролей через SMS, электронную почту и физические носители.&lltt;/p&ggtt;
&lltt;p&ggtt;В версии 2.2 компания «Индид» значительно расширила возможности работы с журналом событий доступа. На странице «События» консоли администрирования появилась гибкая система фильтрации по пользователю, ресурсу, протоколу, IP-адресу и контроллеру домена. Также улучшен интерфейс фильтрации по времени возникновения события и оптимизировано хранение данных, что повышает производительность поиска.&lltt;/p&ggtt;
&lltt;p&ggtt;Обновленный интерфейс упрощает работу с Indeed ITDR и позволяет быстрее находить необходимые события при анализе подозрительной активности, расследовании инцидентов и оценке рисков безопасности. &lltt;/p&ggtt;
&lltt;p&ggtt;Другие изменения Indeed ITDR делают более удобным развертывание продукта в инфраструктурах, где интеграция с Indeed Access Manager не требуется.&lltt;/p&ggtt;
&lltt;p&ggtt;Компонент Indeed Key Server теперь можно установить на отдельный узел с помощью единого сценария установки. Это упрощает развертывание сервера в демилитаризованной зоне (DMZ) и избавляет администраторов от необходимости вручную изменять конфигурационные файлы.&lltt;/p&ggtt;
&lltt;p&ggtt;В новой версии расширен набор сценариев обнаружения атак. Indeed ITDR теперь выявляет такие техники, как Golden PAC и SAM Account Spoofing, что позволяет эффективнее обнаруживать попытки компрометации доменной инфраструктуры.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме того, улучшена совместимость с различными вариантами TLS-сертификатов, включая сертификаты LDAPS без расширения SAN, а также сертификаты с именем субъекта в формате Distinguished Name.&lltt;/p&ggtt;
&lltt;p&ggtt;«Мы последовательно улучшаем Indeed ITDR, расширяя сценарии внедрения продукта и добавляя новые возможности детектирования. Наша задача — помочь организациям своевременно реагировать на угрозы, связанные с учетными данными, не перестраивая существующую инфраструктуру. При этом для нас важно обеспечить удобство работы как для пользователей, так и для специалистов по информационной безопасности и администраторов. Последние обновления отражают наиболее частые пожелания, которые мы получаем в процессе внедрения наших продуктов», — отметил Лев Овчинников, руководитель продукта Indeed ITDR в компании «Индид».&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235375</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[«ТризТех» представил новую версию PT NGFW со встроенным Remote Access VPN]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235374]]></link>
<description><![CDATA[Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением стал встроенный Remote Access VPN (RA VPN), который позволяет организовать защищенный удаленный доступ пользователей к корпоративной сети. Кроме того, в новой версии расширены возможности маршрутизации и построения отказоустойчивых сетей, усовершенствованы управление политиками безопасности и удобство эксплуатации продукта. PT NGFW продолжает развиваться как единая платформа сетевой безопасности для высоконагруженных и территориально распределенных инфраструктур. Главная функция версии 1.11, Remote Access VPN, обеспечивает безопасное удаленное подключение сотрудников к внутренним ИТ-ресурсам организации непосредственно средствами межсетевого экрана, без внедрения отдельного VPN-решения. Настройка и управление параметрами RA VPN также осуществляется из единого окна PT NGFW. Благодаря поддержке раздельного туннелирования, через VPN можно направлять только корпоративный трафик пользователей, оставляя доступ к публичным и облачным сервисам напрямую через Интернет. Это снижает нагрузку на VPN-шлюз и каналы связи, повышая скорость и комфорт работы сотрудников. При этом трафик удаленных пользователей проходит через полный стек механизмов защиты межсетевого экрана, то есть организация может применять к удаленным подключениям те же политики безопасности, что и к сетевому взаимодействию внутри корпоративной инфраструктуры. Аутентификация удаленных пользователей происходит через RADIUS-сервер, что делает возможным не только централизованное управление правами доступа, но и применение второго фактора. Помимо защищенного удаленного доступа, PT NGFW 1.11 получил ряд возможностей, ориентированных на потребности крупных компаний с высоконагруженными и распределенными сетями. Среди них — поддержка технологии ECMP (Equal Cost Multi-Path), которая позволяет одновременно использовать несколько равнозначных маршрутов для передачи трафика. Это помогает эффективнее использовать пропускную способность каналов связи и сохранять передачу трафика при отказе одного из них. Кроме того, PT NGFW 1.11 расширяет сценарии подключения удаленных площадок и список совместимых сетевых устройств за счет возможности создания туннелей GRE и GRE over IPsec, в том числе с применением динамической маршрутизации. Еще одной возможностью, востребованной в высокопроизводительных сетях и центрах обработки данных, стала поддержка Jumbo Frames — увеличенного размера Ethernet-кадров. Благодаря этому можно передавать большие объемы данных меньшим количеством пакетов, снижая накладные расходы на их обработку. Максимальный размер пакета можно настраивать как для всего устройства, так и для отдельных интерфейсов. В совокупности новые возможности маршрутизации, туннелирования и работы с трафиком позволяют адаптировать PT NGFW к более широкому спектру архитектур крупных корпоративных сетей. В новой версии также появились функции, направленные на повышение удобства повседневной эксплуатации PT NGFW. В частности, добавлена поддержка подстановочных символов (wildcards) при настройке URL-фильтрации, благодаря чему весь процесс становится для администраторов быстрее и проще. Управление маршрутизацией тоже стало комфортнее: пользователь может настроить профили проверки доступности узлов, и в случае необходимости трафик автоматически, без ручного вмешательства пользователя переключится на резервный канал. «Мы продолжаем развивать PT NGFW с учетом обратной связи от заказчиков и их ежедневного опыта эксплуатации продукта. Для нас важно, чтобы межсетевой экран одинаково эффективно решал и стратегические задачи, такие как организация защищенного удаленного доступа или построение масштабной отказоустойчивой сетевой архитектуры, так и повседневные задачи администратора — от настройки политик до диагностики и работы с журналами», — отметил Антон Кузнецов, CPO компании «ТризТех»]]></description>
<source><![CDATA[&lltt;p&ggtt;Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением стал встроенный Remote Access VPN (RA VPN), который позволяет организовать защищенный удаленный доступ пользователей к корпоративной сети. Кроме того, в новой версии расширены возможности маршрутизации и построения отказоустойчивых сетей, усовершенствованы управление политиками безопасности и удобство эксплуатации продукта.&lltt;/p&ggtt;
&lltt;p&ggtt;PT NGFW продолжает развиваться как единая платформа сетевой безопасности для высоконагруженных и территориально распределенных инфраструктур. Главная функция версии 1.11, Remote Access VPN, обеспечивает безопасное удаленное подключение сотрудников к внутренним ИТ-ресурсам организации непосредственно средствами межсетевого экрана, без внедрения отдельного VPN-решения. Настройка и управление параметрами RA VPN также осуществляется из единого окна PT NGFW.&lltt;/p&ggtt;
&lltt;p&ggtt;Благодаря поддержке раздельного туннелирования, через VPN можно направлять только корпоративный трафик пользователей, оставляя доступ к публичным и облачным сервисам напрямую через Интернет. Это снижает нагрузку на VPN-шлюз и каналы связи, повышая скорость и комфорт работы сотрудников. При этом трафик удаленных пользователей проходит через полный стек механизмов защиты межсетевого экрана, то есть организация может применять к удаленным подключениям те же политики безопасности, что и к сетевому взаимодействию внутри корпоративной инфраструктуры. Аутентификация удаленных пользователей происходит через RADIUS-сервер, что делает возможным не только централизованное управление правами доступа, но и применение второго фактора.&lltt;/p&ggtt;
&lltt;p&ggtt;Помимо защищенного удаленного доступа, PT NGFW 1.11 получил ряд возможностей, ориентированных на потребности крупных компаний с высоконагруженными и распределенными сетями. Среди них — поддержка технологии ECMP (Equal Cost Multi-Path), которая позволяет одновременно использовать несколько равнозначных маршрутов для передачи трафика. Это помогает эффективнее использовать пропускную способность каналов связи и сохранять передачу трафика при отказе одного из них.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме того, PT NGFW 1.11 расширяет сценарии подключения удаленных площадок и список совместимых сетевых устройств за счет возможности создания туннелей GRE и GRE over IPsec, в том числе с применением динамической маршрутизации.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще одной возможностью, востребованной в высокопроизводительных сетях и центрах обработки данных, стала поддержка Jumbo Frames — увеличенного размера Ethernet-кадров. Благодаря этому можно передавать большие объемы данных меньшим количеством пакетов, снижая накладные расходы на их обработку. Максимальный размер пакета можно настраивать как для всего устройства, так и для отдельных интерфейсов. В совокупности новые возможности маршрутизации, туннелирования и работы с трафиком позволяют адаптировать PT NGFW к более широкому спектру архитектур крупных корпоративных сетей.&lltt;/p&ggtt;
&lltt;p&ggtt;В новой версии также появились функции, направленные на повышение удобства повседневной эксплуатации PT NGFW. В частности, добавлена поддержка подстановочных символов (wildcards) при настройке URL-фильтрации, благодаря чему весь процесс становится для администраторов быстрее и проще. Управление маршрутизацией тоже стало комфортнее: пользователь может настроить профили проверки доступности узлов, и в случае необходимости трафик автоматически, без ручного вмешательства пользователя переключится на резервный канал.&lltt;/p&ggtt;
&lltt;p&ggtt;«Мы продолжаем развивать PT NGFW с учетом обратной связи от заказчиков и их ежедневного опыта эксплуатации продукта. Для нас важно, чтобы межсетевой экран одинаково эффективно решал и стратегические задачи, такие как организация защищенного удаленного доступа или построение масштабной отказоустойчивой сетевой архитектуры, так и повседневные задачи администратора — от настройки политик до диагностики и работы с журналами», — отметил Антон Кузнецов, CPO компании «ТризТех».&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235374</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Адаптация инфраструктуры: что меняется после перехода от пилота к промышленной эксплуатации ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235366]]></link>
<description><![CDATA[ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий на ограниченной группе пользователей. Но в промышленной эксплуатации с нагрузкой дела обстоят иначе. По оценке IDC, глобальные расходы на ИИ-инфраструктуру в 2026 году достигнут 487 млрд. долл., прибавив около 53% за год. Такой рост показывает простую вещь: инфраструктура становится одной из главных статей ИИ-бюджета, а не технической деталью на стороне ИТ. При этом сама по себе закупка мощностей ничего не гарантирует — можно купить дорогие карты и получить простои. Поэтому компании, которые выводят ИИ из пилота, начинают адаптировать не один сервер, а весь контур: от профиля нагрузки до метрик, безопасности и финансового учета. Рассмотрим, как адаптировать инфраструктуру под новые нагрузки и почему недостаточно просто приобрести GPU. Сначала сценарий, потом железо Выражение «ИИ-инфраструктура» звучит так, будто речь идет об одном типе нагрузки — но на деле под ним скрываются разные задачи: обучение модели с нуля, дообучение, классический ML, генерация эмбеддингов. И у каждой задачи — свои узкие места, например голосовому ассистенту важна низкая задержка ответа, а для аналитики критична стоимость обработки большого объема данных. Поэтому зрелые компании начинают с классификации сценариев. Они отвечают на несколько простых вопросов: 	 кто будет пользоваться искусственным интеллектом; 	 сколько запросов ожидается; 	 насколько важна скорость первого ответа; 	 какой объем контекста нужен; 	 можно ли обрабатывать запросы пакетно; 	 что происходит при задержке. Без этого закупка «железа под ИИ» превращается в лотерею — инфраструктура может и не выдержать реальный сценарий. Не всем нужен собственный обучающий кластер Многие компании по инерции думают об ИИ-инфраструктуре как о кластере для обучения моделей. На практике большинству организаций он не нужен — у них нет ни объема данных, ни задач, ради которых стоит учить модель с нуля. Для внутренних ассистентов, поиска по базе знаний, обработки обращений, подготовки документов и поддержки разработчиков лучше идти другим, более простым путем. Достаточно взять готовую модель, развернуть ее у себя или провайдера, подключить корпоративные данные и настроить инференс. «Спроектировать инференс-платформу» звучит не так эффектно, как «построить суперкомпьютер» — зато это ближе к реальным задачам бизнеса. GPU недостаточно просто купить — нужно научиться использовать Самая дорогая ошибка — считать, что проблема решается количеством карт. В действительности GPU часто простаивают, в то время как команды жалуются на нехватку мощностей. Это видно и по рынку: в отчете Cast AI за 2026 год средняя утилизация GPU в Kubernetes-кластерах составила всего 5%. Проблема эта редко связана с плохой организацией — чаще всего она структурная. В Kubernetes GPU в большинстве случаев воспринимается как неделимая единица: приложение запросило карту — получило ее целиком, а использует только часть мощности. В итоге дорогое оборудование формально занято, а фактически не загружено. Компании решают этот вопрос несколькими способами, например делят карту на изолированные части или выбирают инференс-серверы, которые умеют эффективнее упаковывать запросы. Карты без сети и хранилища тоже простаивают ИИ-нагрузки быстро показывают, что GPU — лишь часть инфраструктуры. Если данные и веса модели не успевают подаваться на узел, карта ждет. Бизнес при этом платит за дорогое оборудование, которое не делает полезной работы. Для больших моделей это становится отдельной инженерной задачей. Модель на 70 млрд. параметров в FP8 может весить около 70 Гб, а флагманские модели — сотни гигабайт. Их нужно быстро доставлять, хранить, обновлять и переиспользовать между узлами. Поэтому инфраструктура под ИИ должна включать сеть, хранилище, интерконнект, параллельную файловую систему и механику доставки весов. Если этого не сделать, компания покупает не мощность, а дорогую очередь ожидания. Обычные метрики не показывают качество ИИ-сервиса Классический мониторинг приложений плохо описывает ИИ-нагрузку. Для LLM-инференса важны другие показатели: time to first token, inter-token latency, throughput, tokens per second, запросы в секунду и стоимость обработки. NVIDIA в документации по benchmarking для LLM отдельно выделяет такие метрики как TTFT, ITL, TPS и end-to-end latency. Важно, что эти показатели нельзя оптимизировать для всех сценариев. Голосовому боту важен быстрый первый ответ, batch-аналитике — минимальная стоимость обработки. Поэтому зрелые команды задают SLO под конкретную ситуацию: для кого работает ИИ, какая задержка допустима, сколько компания готова платить за миллион токенов. Модель нельзя встраивать напрямую в каждое приложение Быстрый путь — подключить LLM прямо к монолиту или внутреннему порталу. На пилоте это удобно, однако в промышленной эксплуатации такой подход становится дорогим. Почему это происходит: 	 становится сложнее переключить провайдера; 	 приложение оказывается привязано к конкретной модели; 	 почти невозможно нормально рассчитать расходы по командам; 	 промпты и ответы выпадают из общего мониторинга. Рабочий вариант в таком случае — вынести работу с моделями в отдельный слой, ИИ-шлюз. Он становится единой точкой для квот, логирования, PII-фильтрации, кэширования, переключения моделей и контроля расходов. RAG требует архитектуры доступа RAG часто становится первым массовым корпоративным ИИ-сценарием: компания подключает документы, базы знаний, инструкции и хочет, чтобы сотрудники задавали вопросы на естественном языке. Однако вместе с пользой возникает и новый риск. Если права пользователя не участвуют в самом поисковом запросе, а фильтрация происходит уже после извлечения документов, векторная база превращается в канал переноса информации между отделами — быстрый, удобный и не оставляющий следов в привычных журналах доступа. Надеяться на фильтрацию постфактум нельзя, так как она регулярно пропускает содержимое чужих документов в ответы. Именно поэтому в корпоративном RAG роль, права доступа и подразделение пользователя должны быть частью самого запроса к индексу. Если гарантировать это архитектурно не получается, корпус должен сужаться до публичных документов — сегодня других надежных и безопасных вариантов тут нет. Стоимость нужно считать в токенах с первого дня ИИ-инфраструктура меняет привычный финансовый учет ИТ. Раньше компания считала серверы, лицензии, облачные ресурсы и человеко-часы. В ИИ-сервисах новой единицей стоимости становится токен. На пилоте это легко недооценить — слишком мало пользователей и запросов. В промышленной эксплуатации растут конкурентность, длина контекста, число пользователей, резервирование и объем логирования. Стоимость начинает расти нелинейно. Подсчет токенов нужен с первого дня. Компания должна понимать, кто генерирует расходы, какие сценарии самые дорогие, где можно кэшировать ответы, где подойдет более дешевая модель, а где оправдана премиальная. Платформа лучше разрозненных запусков Один из частых антипаттернов — когда каждый отдел сам разворачивает модель. На старте это кажется отличной возможностью не тормозить команды, однако вскоре компания получает дублирование расходов, разный уровень безопасности, отсутствие прозрачности и несколько точек риска. Но зрелая схема устроена иначе. Есть единый платформенный слой: инфраструктура, ИИ-шлюз, квоты, аудит, мониторинг, безопасность и SLA. Продуктовые команды отвечают за свои сценарии — промпты, корпус знаний, качество ответов, бизнес-эффект. Отдельный признак зрелости системы — оценка качества, evals. Без «золотого» набора примеров и регрессионного прогона невозможно ответить на вопрос, стало ли лучше после смены промпта или модели — и таким образом решения принимаются лишь на ощущениях. Зрелые команды относятся к промпту как к артефакту релиза: он версионируется, выкатывается постепенно и откатывается при деградации. Важно тут то, что закладывать evals нужно с первого дня, так как задним числом их уже не собрать. Так искусственный интеллект становится частью корпоративной архитектуры, переставая быть набором локальных экспериментов. Подведем итоги Адаптация ИТ-инфраструктуры под ИИ-нагрузки начинается с понимания сценариев: кому нужен искусственный интеллект, как часто, на каких данных, с какими рисками и за какие деньги. Компании, которые проходят этот путь осознанно, проектируют управляемый контур — инференс-платформу, правильные метрики, ИИ-шлюз, безопасный RAG, подсчет токенов и единые правила для всех команд. Не нужно делать его максимальным, перегружать всем и сразу — достаточно контроля, ясности и обратимости, то есть готовности сменить модель или провайдера, когда профиль нагрузки изменится. #IMAGE_235367#]]></description>
<source><![CDATA[&lltt;p&ggtt;ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных&nbsp;— и&nbsp;обкатать сценарий на&nbsp;ограниченной группе пользователей. Но&nbsp;в&nbsp;промышленной эксплуатации с&nbsp;нагрузкой дела обстоят иначе. По&nbsp;оценке IDC, глобальные расходы на&nbsp;ИИ-инфраструктуру в&nbsp;2026 году &lltt;a href="https://www.idc.com/resource-center/blog/ai-infrastructure-spending-caps-historic-year-at-90-billion-in-q4-2025-2029-spending-to-eclipse-1-trillion/"&ggtt;достигнут&lltt;/a&ggtt; 487&nbsp;млрд. долл., прибавив около&nbsp;53% за&nbsp;год. Такой рост показывает простую вещь: инфраструктура становится одной из&nbsp;главных статей ИИ-бюджета, а&nbsp;не&nbsp;технической деталью на&nbsp;стороне ИТ.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом сама по&nbsp;себе закупка мощностей ничего не&nbsp;гарантирует&nbsp;— можно купить дорогие карты и&nbsp;получить простои. Поэтому компании, которые выводят&nbsp;ИИ из&nbsp;пилота, начинают адаптировать не&nbsp;один сервер, а&nbsp;весь контур: от&nbsp;профиля нагрузки до&nbsp;метрик, безопасности и&nbsp;финансового учета.&lltt;/p&ggtt;
&lltt;p&ggtt;Рассмотрим, как адаптировать инфраструктуру под новые нагрузки и&nbsp;почему недостаточно просто приобрести GPU.&lltt;/p&ggtt;
&lltt;h3&ggtt;Сначала сценарий, потом железо&lltt;/h3&ggtt;
&lltt;p&ggtt;Выражение «ИИ-инфраструктура» звучит так, будто речь идет об&nbsp;одном типе нагрузки&nbsp;— но&nbsp;на&nbsp;деле под ним скрываются разные задачи: обучение модели с&nbsp;нуля, дообучение, классический&nbsp;ML, генерация эмбеддингов. И&nbsp;у&nbsp;каждой задачи&nbsp;— свои узкие места, например голосовому ассистенту важна низкая задержка ответа, а&nbsp;для аналитики критична стоимость обработки большого объема данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому зрелые компании начинают с&nbsp;классификации сценариев. Они отвечают на&nbsp;несколько простых вопросов:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; кто будет пользоваться искусственным интеллектом;&lltt;/li&ggtt;
	&lltt;li&ggtt; сколько запросов ожидается;&lltt;/li&ggtt;
	&lltt;li&ggtt; насколько важна скорость первого ответа;&lltt;/li&ggtt;
	&lltt;li&ggtt; какой объем контекста нужен;&lltt;/li&ggtt;
	&lltt;li&ggtt; можно&nbsp;ли обрабатывать запросы пакетно;&lltt;/li&ggtt;
	&lltt;li&ggtt; что происходит при задержке.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Без этого закупка «железа под&nbsp;ИИ» превращается в&nbsp;лотерею&nbsp;— инфраструктура может и&nbsp;не&nbsp;выдержать реальный сценарий.&lltt;/p&ggtt;
&lltt;h3&ggtt;Не&nbsp;всем нужен собственный обучающий кластер&lltt;/h3&ggtt;
&lltt;p&ggtt;Многие компании по&nbsp;инерции думают об&nbsp;ИИ-инфраструктуре как о&nbsp;кластере для обучения моделей. На&nbsp;практике большинству организаций он&nbsp;не&nbsp;нужен&nbsp;— у&nbsp;них нет ни&nbsp;объема данных, ни&nbsp;задач, ради которых стоит учить модель с&nbsp;нуля.&lltt;/p&ggtt;
&lltt;p&ggtt;Для внутренних ассистентов, поиска по&nbsp;базе знаний, обработки обращений, подготовки документов и&nbsp;поддержки разработчиков лучше идти другим, более простым путем. Достаточно взять готовую модель, развернуть ее&nbsp;у&nbsp;себя или провайдера, подключить корпоративные данные и&nbsp;настроить инференс.&lltt;/p&ggtt;
&lltt;p&ggtt;«Спроектировать инференс-платформу» звучит не&nbsp;так эффектно, как «построить суперкомпьютер»&nbsp;— зато это ближе к&nbsp;реальным задачам бизнеса.&lltt;/p&ggtt;
&lltt;h3&ggtt;GPU недостаточно просто купить&nbsp;— нужно научиться использовать&lltt;/h3&ggtt;
&lltt;p&ggtt;Самая дорогая ошибка&nbsp;— считать, что проблема решается количеством карт. В&nbsp;действительности GPU часто простаивают, в&nbsp;то&nbsp;время как команды жалуются на&nbsp;нехватку мощностей.&lltt;/p&ggtt;
&lltt;p&ggtt;Это видно и&nbsp;по&nbsp;рынку: в&nbsp;отчете Cast AI&nbsp;за&nbsp;2026 год средняя утилизация GPU в&nbsp;Kubernetes-кластерах &lltt;a href="https://cast.ai/reports/kubernetes-optimization-report/"&ggtt;составила&lltt;/a&ggtt; всего 5%. Проблема эта редко связана с&nbsp;плохой организацией&nbsp;— чаще всего она структурная. В&nbsp;Kubernetes GPU в&nbsp;большинстве случаев воспринимается как неделимая единица: приложение запросило карту&nbsp;— получило ее&nbsp;целиком, а&nbsp;использует только часть мощности. В&nbsp;итоге дорогое оборудование формально занято, а&nbsp;фактически не&nbsp;загружено.&lltt;/p&ggtt;
&lltt;p&ggtt;Компании решают этот вопрос несколькими способами, например делят карту на&nbsp;изолированные части или выбирают инференс-серверы, которые умеют эффективнее упаковывать запросы.&lltt;/p&ggtt;
&lltt;h3&ggtt;Карты без сети и&nbsp;хранилища тоже простаивают&lltt;/h3&ggtt;
&lltt;p&ggtt;ИИ-нагрузки быстро показывают, что GPU&nbsp;— лишь часть инфраструктуры. Если данные и&nbsp;веса модели не&nbsp;успевают подаваться на&nbsp;узел, карта ждет. Бизнес при этом платит за&nbsp;дорогое оборудование, которое не&nbsp;делает полезной работы.&lltt;/p&ggtt;
&lltt;p&ggtt;Для больших моделей это становится отдельной инженерной задачей. Модель на&nbsp;70&nbsp;млрд. параметров в&nbsp;FP8 может весить около 70&nbsp;Гб, а&nbsp;флагманские модели&nbsp;— сотни гигабайт. Их&nbsp;нужно быстро доставлять, хранить, обновлять и&nbsp;переиспользовать между узлами.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому инфраструктура под&nbsp;ИИ должна включать сеть, хранилище, интерконнект, параллельную файловую систему и&nbsp;механику доставки весов. Если этого не&nbsp;сделать, компания покупает не&nbsp;мощность, а&nbsp;дорогую очередь ожидания.&lltt;/p&ggtt;
&lltt;h3&ggtt;Обычные метрики не&nbsp;показывают качество ИИ-сервиса&lltt;/h3&ggtt;
&lltt;p&ggtt;Классический мониторинг приложений плохо описывает ИИ-нагрузку. Для &lltt;nobr&ggtt;LLM-инференса&lltt;/nobr&ggtt; важны другие показатели: time to&nbsp;first token, inter-token latency, throughput, tokens per second, запросы в&nbsp;секунду и&nbsp;стоимость обработки. NVIDIA в&nbsp;документации по&nbsp;benchmarking для LLM отдельно &lltt;a href="https://docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html"&ggtt;выделяет&lltt;/a&ggtt; такие метрики как TTFT, ITL, TPS и&nbsp;end-to-end latency.&lltt;/p&ggtt;
&lltt;p&ggtt;Важно, что эти показатели нельзя оптимизировать для всех сценариев. Голосовому боту важен быстрый первый ответ, batch-аналитике&nbsp;— минимальная стоимость обработки. Поэтому зрелые команды задают SLO под конкретную ситуацию: для кого работает&nbsp;ИИ, какая задержка допустима, сколько компания готова платить за&nbsp;миллион токенов.&lltt;/p&ggtt;
&lltt;h3&ggtt;Модель нельзя встраивать напрямую в&nbsp;каждое приложение&lltt;/h3&ggtt;
&lltt;p&ggtt;Быстрый путь&nbsp;— подключить LLM прямо к&nbsp;монолиту или внутреннему порталу. На&nbsp;пилоте это удобно, однако в&nbsp;промышленной эксплуатации такой подход становится дорогим.&lltt;/p&ggtt;
&lltt;p&ggtt;Почему это происходит:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; становится сложнее переключить провайдера;&lltt;/li&ggtt;
	&lltt;li&ggtt; приложение оказывается привязано к&nbsp;конкретной модели;&lltt;/li&ggtt;
	&lltt;li&ggtt; почти невозможно нормально рассчитать расходы по&nbsp;командам;&lltt;/li&ggtt;
	&lltt;li&ggtt; промпты и&nbsp;ответы выпадают из&nbsp;общего мониторинга.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Рабочий вариант в&nbsp;таком случае&nbsp;— вынести работу с&nbsp;моделями в&nbsp;отдельный слой, ИИ-шлюз. Он&nbsp;становится единой точкой для квот, логирования, PII-фильтрации, кэширования, переключения моделей и&nbsp;контроля расходов.&lltt;/p&ggtt;
&lltt;h3&ggtt;RAG требует архитектуры доступа&lltt;/h3&ggtt;
&lltt;p&ggtt;RAG часто становится первым массовым корпоративным ИИ-сценарием: компания подключает документы, базы знаний, инструкции и&nbsp;хочет, чтобы сотрудники задавали вопросы на&nbsp;естественном языке. Однако вместе с&nbsp;пользой возникает и&nbsp;новый риск.&lltt;/p&ggtt;
&lltt;p&ggtt;Если права пользователя не&nbsp;участвуют в&nbsp;самом поисковом запросе, а&nbsp;фильтрация происходит уже после извлечения документов, векторная база превращается в&nbsp;канал переноса информации между отделами&nbsp;— быстрый, удобный и&nbsp;не&nbsp;оставляющий следов в&nbsp;привычных журналах доступа. Надеяться на&nbsp;фильтрацию постфактум нельзя, так как она регулярно пропускает содержимое чужих документов в&nbsp;ответы.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому в&nbsp;корпоративном RAG роль, права доступа и&nbsp;подразделение пользователя должны быть частью самого запроса к&nbsp;индексу. Если гарантировать это архитектурно не&nbsp;получается, корпус должен сужаться до&nbsp;публичных документов&nbsp;— сегодня других надежных и&nbsp;безопасных вариантов тут нет.&lltt;/p&ggtt;
&lltt;h3&ggtt;Стоимость нужно считать в&nbsp;токенах с&nbsp;первого дня&lltt;/h3&ggtt;
&lltt;p&ggtt;ИИ-инфраструктура меняет привычный финансовый учет ИТ. Раньше компания считала серверы, лицензии, облачные ресурсы и&nbsp;человеко-часы. В&nbsp;ИИ-сервисах новой единицей стоимости становится токен.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;пилоте это легко недооценить&nbsp;— слишком мало пользователей и&nbsp;запросов. В&nbsp;промышленной эксплуатации растут конкурентность, длина контекста, число пользователей, резервирование и&nbsp;объем логирования. Стоимость начинает расти нелинейно.&lltt;/p&ggtt;
&lltt;p&ggtt;Подсчет токенов нужен с&nbsp;первого дня. Компания должна понимать, кто генерирует расходы, какие сценарии самые дорогие, где можно кэшировать ответы, где подойдет более дешевая модель, а&nbsp;где оправдана премиальная.&lltt;/p&ggtt;
&lltt;h3&ggtt;Платформа лучше разрозненных запусков&lltt;/h3&ggtt;
&lltt;p&ggtt;Один из&nbsp;частых антипаттернов&nbsp;— когда каждый отдел сам разворачивает модель. На&nbsp;старте это кажется отличной возможностью не&nbsp;тормозить команды, однако вскоре компания получает дублирование расходов, разный уровень безопасности, отсутствие прозрачности и&nbsp;несколько точек риска.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;зрелая схема устроена иначе. Есть единый платформенный слой: инфраструктура, ИИ-шлюз, квоты, аудит, мониторинг, безопасность и&nbsp;SLA. Продуктовые команды отвечают за&nbsp;свои сценарии&nbsp;— промпты, корпус знаний, качество ответов, бизнес-эффект.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельный признак зрелости системы&nbsp;— оценка качества, evals. Без «золотого» набора примеров и&nbsp;регрессионного прогона невозможно ответить на&nbsp;вопрос, стало&nbsp;ли лучше после смены промпта или модели&nbsp;— и&nbsp;таким образом решения принимаются лишь на&nbsp;ощущениях.&lltt;/p&ggtt;
&lltt;p&ggtt;Зрелые команды относятся к&nbsp;промпту как к&nbsp;артефакту релиза: он&nbsp;версионируется, выкатывается постепенно и&nbsp;откатывается при деградации. Важно тут&nbsp;то, что закладывать evals нужно с&nbsp;первого дня, так как задним числом их&nbsp;уже не&nbsp;собрать. Так искусственный интеллект становится частью корпоративной архитектуры, переставая быть набором локальных экспериментов.&lltt;/p&ggtt;
&lltt;h3&ggtt;Подведем итоги&lltt;/h3&ggtt;
&lltt;p&ggtt;Адаптация ИТ-инфраструктуры под ИИ-нагрузки начинается с&nbsp;понимания сценариев: кому нужен искусственный интеллект, как часто, на&nbsp;каких данных, с&nbsp;какими рисками и&nbsp;за&nbsp;какие деньги.&lltt;/p&ggtt;
&lltt;p&ggtt;Компании, которые проходят этот путь осознанно, проектируют управляемый контур&nbsp;— инференс-платформу, правильные метрики, ИИ-шлюз, безопасный RAG, подсчет токенов и&nbsp;единые правила для всех команд. Не&nbsp;нужно делать его максимальным, перегружать всем и&nbsp;сразу&nbsp;— достаточно контроля, ясности и&nbsp;обратимости, то&nbsp;есть готовности сменить модель или провайдера, когда профиль нагрузки изменится.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235367#&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235366</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/0c2/060s51f6s4wu8riq0aax6neatu2jluiu.jpg]]>
</images>
<imagesname><![CDATA[;;Султан Рамазанов, директор по искусственному интеллекту Umbrella IT   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Стоимость развёртывания ведущих мировых LLM в России за год выросла в 2,8 раза]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235372]]></link>
<description><![CDATA[MWS Cloud (входит в МТС Web Services) проанализировала требования к вычислительной инфраструктуре для запуска ведущих мировых и российских больших языковых моделей. По оценке компании, средняя стоимость минимального набора ускорителей Nvidia для запуска одной модели выросла с 13,7 млн. рублей в 2025 году до 38,8 млн. рублей в 2026 году — в 2,8 раза. В анализ вошли популярные открытые модели, выпущенные весной и летом соответствующего года. Для 2025 года рассматривались Kimi K2, gpt-oss-120b, Gemma 3 27B, GLM-4.5V, Qwen3 235B и российская Cotype Pro 2. Для 2026 года — Kimi K3, Qwen3.5 397B, DeepSeek-V4-Pro, DeepSeek-V4-Flash, GLM-5.2, Gemma 4 и Cotype Pro 3. Расчёт сделан для минимального количества видеокарт, необходимого для запуска модели и обработки одного запроса максимального заявленного размера. В стоимость включены серверы с GPU и коммутаторы к ним. 	 		 			 				Год 			 			 				Наиболее популярный GPU 			 			 				Другие GPU 			 		 		 			 				2025 			 			 				H100 — для трёх из шести моделей 			 			 				H200 — для двух моделей; A100 — для одной 			 		 		 			 				2026 			 			 				H200 — для трёх из семи моделей 			 			 				B300 — для двух моделей; H100 и A100 — ещё для двух 			 		 	 Рейтинг моделей по стоимости запуска в 2025 году 	 		 			 				Место 			 			 				Модель 			 			 				Количество параметров 			 			 				Минимальная конфигурация 			 			 				Стоимость 			 		 		 			 				1 			 			 				Kimi K2 			 			 				1 трлн (32 млрд. активных) 			 			 				8 × H200 141 Гб 			 			 				примерно 35 млн. рублей 			 		 		 			 				2 			 			 				Qwen3 			 			 				235 млрд. (22 млрд. активных) 			 			 				4 × H200 141 Гб 			 			 				примерно 18 млн. рублей 			 		 		 			 				3 			 			 				GLM-4.5V 			 			 				106 млрд. (12 млрд. активных) 			 			 				минимум 4 × H100 80 Гб 			 			 				примерно 15 млн. рублей 			 		 		 			 				4 			 			 				Gemma 3 			 			 				27 млрд 			 			 				2 × H100 80 Гб 			 			 				примерно 7,5 млн. рублей 			 		 		 			 				5 			 			 				gpt-oss 			 			 				117 млрд. (5,1 млрд. активных) 			 			 				1 × H100 80 Гб 			 			 				более 3,5 млн. рублей 			 		 		 			 				6 			 			 				Cotype Pro 2 			 			 				32 млрд 			 			 				1 × A100 80 Гб 			 			 				примерно 3 млн. рублей 			 		 	 Рейтинг моделей по стоимости запуска в 2026 году 	 		 			 				Место 			 			 				Модель 			 			 				Количество параметров 			 			 				Минимальная конфигурация 			 			 				Стоимость 			 		 		 			 				1 			 			 				Kimi K3 			 			 				2,8 трлн (104 млрд. активных) 			 			 				8 × B300 288 Гб 			 			 				примерно 80 млн. рублей 			 		 		 			 				2 			 			 				Qwen3.5 			 			 				397 млрд. (17 млрд. активных) 			 			 				8 × H200 141 Гб 			 			 				примерно 55 млн. рублей 			 		 		 			 				2 			 			 				DeepSeek-V4-Pro 			 			 				1,6 трлн (49 млрд. активных) 			 			 				8 × H200 141 Гб 			 			 				примерно 55 млн. рублей 			 		 		 			 				2 			 			 				GLM-5.2 			 			 				744 млрд. (около 40 млрд. активных) 			 			 				8 × H200 141 Гб 			 			 				примерно 55 млн. рублей 			 		 		 			 				5 			 			 				DeepSeek-V4-Flash 			 			 				284 млрд. (13 млрд. активных) 			 			 				1 × B300 288 Гб 			 			 				примерно 10 млн. рублей 			 		 		 			 				6 			 			 				Gemma 4 			 			 				31 млрд 			 			 				2 × H100 80 Гб 			 			 				примерно 7,5 млн. рублей 			 		 		 			 				7 			 			 				Cotype Pro 3 			 			 				27 млрд 			 			 				1 × A100 80 Гб 			 			 				примерно 3 млн. рублей 			 		 	 Новые LLM становятся более мощными: они лучше справляются со сложными задачами и могут учитывать больше информации в одном запросе. Однако для этого им требуется больше памяти и более производительные GPU. При этом растёт и стоимость самих видеокарт, поэтому развёртывание моделей обходится дороже. Отдельно MWS Cloud оценила возможные конфигурации на китайских ускорителях Huawei Ascend 910B. Возможность запуска на них подтверждена не для всех рассмотренных LLM: в выборке 2025 года подтверждение есть для трёх из шести моделей, в 2026 году — для пяти из семи. Среди моделей с подтверждённой или экспериментально подтверждённой поддержкой Huawei в 2025 году в среднем требовалось 10,7 ускорителя Ascend 910B, а в 2026 году — 13,6. Официальной цены на данные GPU нет, но, по оценкам, она может составлять от половины до двух третей стоимости сопоставимых GPU Nvidia. «Цены на GPU в России во многом зависят от мирового рынка: глобальная гонка в области ИИ увеличивает спрос на вычислительные мощности и поддерживает рост стоимости ускорителей. По данным исследования MWS Cloud, 47% респондентов ожидают удорожания GPU-ресурсов в ближайшие 12 месяцев, а 45% считают, что их значение для бизнеса будет расти. Развёртывать крупные модели на собственной инфраструктуре становится дороже, однако единого ценового предела, после которого рынок потеряет интерес к ИИ, нет: если покупка оборудования перестаёт окупаться, компании выбирают более компактные модели, оптимизируют вычисления или переходят в облако, где можно платить только за фактически используемые мощности. Один из индикаторов этого сдвига — рост облачного потребления ИИ-моделей: по оценке MWS Cloud, в первом полугодии 2026 года потребление китайских LLM российскими компаниями на платформах MWS GPT Model Hub и MWS GPT более чем в 11 раз превысило показатель за весь 2025 год», — отметил генеральный директор MWS Павел Воронин]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;MWS Cloud (входит в&nbsp;МТС Web Services) проанализировала требования к&nbsp;вычислительной инфраструктуре для запуска ведущих мировых и&nbsp;российских больших языковых моделей. По&nbsp;оценке компании, средняя стоимость минимального набора ускорителей Nvidia для запуска одной модели выросла с&nbsp;13,7&nbsp;млн. рублей в&nbsp;2025 году до&nbsp;38,8&nbsp;млн. рублей в&nbsp;2026 году&nbsp;— в&nbsp;2,8&nbsp;раза.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;анализ вошли популярные открытые модели, выпущенные весной и&nbsp;летом соответствующего года. Для 2025 года рассматривались Kimi&nbsp;K2, gpt-oss-120b, Gemma 3 27B, GLM-4.5V, Qwen3 235B и&nbsp;российская Cotype Pro&nbsp;2. Для 2026 года&nbsp;— Kimi K3, Qwen3.5 397B, DeepSeek-V4-Pro, DeepSeek-V4-Flash, GLM-5.2, Gemma 4&nbsp;и&nbsp;Cotype Pro&nbsp;3.&lltt;/p&ggtt;
&lltt;p&ggtt;Расчёт сделан для минимального количества видеокарт, необходимого для запуска модели и&nbsp;обработки одного запроса максимального заявленного размера. В&nbsp;стоимость включены серверы с&nbsp;GPU и&nbsp;коммутаторы к&nbsp;ним.&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Год&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Наиболее популярный GPU&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Другие GPU&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2025&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;H100&nbsp;— для трёх из&nbsp;шести моделей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;H200&nbsp;— для двух моделей; A100&nbsp;— для одной&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2026&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;H200&nbsp;— для трёх из&nbsp;семи моделей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;B300&nbsp;— для двух моделей; H100 и&nbsp;A100&nbsp;— ещё для двух&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Рейтинг моделей по&nbsp;стоимости запуска в&nbsp;2025 году&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Место&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Модель&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Количество параметров&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Минимальная конфигурация&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Стоимость&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Kimi K2&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1&nbsp;трлн (32&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8 × H200&nbsp;141&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 35&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Qwen3&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;235&nbsp;млрд. (22&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;4 × H200&nbsp;141&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 18&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;GLM-4.5V&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;106&nbsp;млрд. (12&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;минимум 4 × H100 80&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 15&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;4&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Gemma 3&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;27&nbsp;млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2 × H100 80&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 7,5&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;5&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;gpt-oss&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;117&nbsp;млрд. (5,1&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1 × H100 80&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;более 3,5&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Cotype Pro 2&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;32&nbsp;млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1 × A100 80&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 3&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Рейтинг моделей по&nbsp;стоимости запуска в&nbsp;2026 году&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Место&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Модель&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Количество параметров&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Минимальная конфигурация&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;&lltt;strong&ggtt;Стоимость&lltt;/strong&ggtt;&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Kimi K3&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,8 трлн (104&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8 × B300&nbsp;288&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 80&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Qwen3.5&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;397&nbsp;млрд. (17&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8 × H200&nbsp;141&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 55&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;DeepSeek-V4-Pro&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1,6 трлн (49&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8 × H200&nbsp;141&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 55&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;GLM-5.2&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;744&nbsp;млрд. (около 40&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8 × H200&nbsp;141&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 55&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;5&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;DeepSeek-V4-Flash&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;284&nbsp;млрд. (13&nbsp;млрд. активных)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1 × B300&nbsp;288&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 10&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Gemma 4&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;31&nbsp;млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2 × H100 80&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 7,5&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;7&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Cotype Pro 3&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;27&nbsp;млрд&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1 × A100 80&nbsp;Гб&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;примерно 3&nbsp;млн. рублей&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;Новые LLM становятся более мощными: они лучше справляются со&nbsp;сложными задачами и&nbsp;могут учитывать больше информации в&nbsp;одном запросе. Однако для этого им&nbsp;требуется больше памяти и&nbsp;более производительные GPU. При этом растёт и&nbsp;стоимость самих видеокарт, поэтому развёртывание моделей обходится дороже.&lltt;/p&ggtt;
&lltt;p&ggtt;Отдельно MWS Cloud оценила возможные конфигурации на&nbsp;китайских ускорителях Huawei Ascend 910B. Возможность запуска на&nbsp;них подтверждена не&nbsp;для всех рассмотренных LLM: в&nbsp;выборке 2025 года подтверждение есть для трёх из&nbsp;шести моделей, в&nbsp;2026 году&nbsp;— для пяти из&nbsp;семи.&lltt;/p&ggtt;
&lltt;p&ggtt;Среди моделей с&nbsp;подтверждённой или экспериментально подтверждённой поддержкой Huawei в&nbsp;2025 году в&nbsp;среднем требовалось 10,7 ускорителя Ascend 910B, а&nbsp;в&nbsp;2026 году&nbsp;— 13,6. Официальной цены на&nbsp;данные GPU нет, но, по&nbsp;оценкам, она может составлять от&nbsp;половины до&nbsp;двух третей стоимости сопоставимых GPU Nvidia.&lltt;/p&ggtt;
&lltt;p&ggtt;«Цены на&nbsp;GPU в&nbsp;России во&nbsp;многом зависят от&nbsp;мирового рынка: глобальная гонка в&nbsp;области&nbsp;ИИ увеличивает спрос на&nbsp;вычислительные мощности и&nbsp;поддерживает рост стоимости ускорителей. По&nbsp;данным исследования MWS Cloud, 47% респондентов ожидают удорожания GPU-ресурсов в&nbsp;ближайшие 12&nbsp;месяцев, а&nbsp;45% считают, что их&nbsp;значение для бизнеса будет расти. Развёртывать крупные модели на&nbsp;собственной инфраструктуре становится дороже, однако единого ценового предела, после которого рынок потеряет интерес к&nbsp;ИИ, нет: если покупка оборудования перестаёт окупаться, компании выбирают более компактные модели, оптимизируют вычисления или переходят в&nbsp;облако, где можно платить только за&nbsp;фактически используемые мощности. Один из&nbsp;индикаторов этого сдвига&nbsp;— рост облачного потребления ИИ-моделей: по&nbsp;оценке MWS Cloud, в&nbsp;первом полугодии 2026 года потребление китайских LLM российскими компаниями на&nbsp;платформах MWS GPT Model Hub и&nbsp;MWS GPT более чем в&nbsp;11&nbsp;раз превысило показатель за&nbsp;весь 2025&nbsp;год»,&nbsp;— отметил генеральный директор MWS Павел Воронин&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235372</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[РУССОФТ: ситуация на внутреннем рынке толкает софтверные компании в дружественный, но еще не очень понятный мир]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235371]]></link>
<description><![CDATA[Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир, наблюдаемая в последние годы, в 2025 году имела продолжение — снова выявлено очевидное снижение продаж на рынках недружественных стран. А вот столь же очевидного увеличения реализации продуктов и услуг в дружественных странах пока не видно. В то же время, на переохлажденном российском ИТ-рынке с возросшей налоговой нагрузкой компаниям становится слишком тесно. В такой ситуации логично предположить их движение в тех направлениях, которые открыты для международной экспансии. Направление в сторону недружественных стран сложно назвать перспективным. При всем желании российских компаний-разработчиков ПО сохранить продажи в Европе и Северной Америке, западные политики без устали работают над созданием непреодолимых для них препятствий. Многие их задумки реализуются, хотя при этом западные страны лишают свои предприятия и граждан доступа к качественным услугам и продуктам. По итогам 2025 года продажи отечественных софтверных компаний на рынках недружественных стран сократились примерно на 40% до ₽70 млрд. Сейчас страны Европы и США обеспечивают 2,4% совокупной выручки всей индустрии разработки ПО. При этом доля компаний, имеющих продажи в недружественных странах, намного больше — 14,3% от всех опрошенных компаний. Для Европы этот показатель равен 9,9%, а для США и Канады — 8,8% (в 2024 г. было 14,2% и 11,4% соответственно). Однако дальнейший уход с рынков западных стран столь же массово, как в предыдущие годы, компании не планируют. Сохранить присутствие на рынке Северной Америки в 2026 году рассчитывает 9,2%, что чуть больше, чем было по итогам 2025 года. Не исключено, что шансы остаться на одном из крупнейших рынков мира повысились, когда респонденты увидели потепление отношений между Россией и США после встречи в Анкоридже. Такой же эффект произвела в свое время победа Дональда Трампа на американских президентских выборах. Он вступил в должность в январе 2025 года, и вскоре стало известно о планах его встречи с Президентом РФ В.В. Путиным, которая состоялась в августе. С Европой все было хуже, ведь от них шли сигналы только на еще больший разрыв. Продажи в дружественных странах дальнего зарубежья в 2025 году в рублях не изменились и составили примерно ₽170 млрд. При этом доля этих продаж в совокупной выручке софтверных компаний упала — с 6,8% до 6,1%. Укрепление российской национальной валюты по отношению к доллару не позволило нарастить выручку в рублевом выражении. Однако в долларовом выражении продажи в дружественные страны все же увеличились примерно на 10%. Это касается как всего экспорта софтверных компаний, так и их продаж на рынках дружественных стран. Ближнее зарубежье обеспечило по итогам 2025 года 10,2% совокупной выручки российских разработчиков ПО. Годом ранее его доля была чуть меньше — 9,8%. Продажи на постсоветском пространстве выросли примерно на 18-19% в рублевом выражении (до ₽285 млрд) и примерно на 32% в долларах ($3,4 млрд). Указали на наличие продаж в этих странах 36,1% опрошенных компаний. На данный момент Ближнее зарубежье обеспечивает более половины экспорта российских софтверных компаний. Распределение продаж российских софтверных компаний по группам рынков в 2021-2025 годы 	 		 			 			 				2021 			 			 				2022 			 			 				2023 			 			 				2024 			 			 				2025 			 		 		 			 				Россия 			 			 				52,5% 			 			 				65,6% 			 			 				76,2% 			 			 				78,6% 			 			 				81,3% 			 		 		 			 				Ближнее зарубежье 			 			 				13,45% 			 			 				11,5% 			 			 				10,2% 			 			 				9,8% 			 			 				10,2% 			 		 		 			 				Россия и Ближнее зарубежье 			 			 				65,95% 			 			 				77,1% 			 			 				86,35% 			 			 				88,4% 			 			 				91,5% 			 		 		 			 				Дальнее зарубежье: 			 			 		 		 			 				— недружественные страны (до 2022 г. «Западный мир») 			 			 				25,25% 			 			 				12,5% 			 			 				7,6% 			 			 				4,8% 			 			 				2,4% 			 		 		 			 				— дружественные страны (до 2022 г. «Новые рынки») 			 			 				8,8% 			 			 				10,4% 			 			 				6,05% 			 			 				6,8% 			 			 				6,1% 			 		 	 Согласно прогнозу, основанному на планах опрошенных компаний, по итогам 2026 года российские софтверные компании увеличат свое присутствие с реальными продажами почти на всех рынках. Предполагается, что даже в США будут продавать свои продукты и услуг больше компаний, чем было в 2025 году. Падение присутствия российских экспортеров прогнозируется только на рынке Европы. Прогнозируя расширение географии и рост экспорта, необходимо признать, что опыт предыдущих лет показывает, что ожидания компаний относительно роста экспорта часто оказываются несколько завышенными. Присутствие российских компаний на зарубежных рынках в 2025 году с прогнозом на 2026 год, % опрошенных компаний 	 		 			 			 				2025 г. 			 			 				2026 г. (прогноз) 			 		 		 			 				Ближнее зарубежье 			 			 				36,1% 			 			 				40,5% 			 		 		 			 				Казахстан 			 			 				22,1% 			 			 				25,2% 			 		 		 			 				Белоруссия 			 			 				20,7% 			 			 				24,8% 			 		 		 			 				Узбекистан 			 			 				15,0% 			 			 				18,7% 			 		 		 			 				Европа (без России и Ближнего зарубежья) 			 			 				9,9% 			 			 				8,5% 			 		 		 			 				США/Канада 			 			 				8,8% 			 			 				9,2% 			 		 		 			 				Южная и Восточная Азия 			 			 				7,5% 			 			 				7,8% 			 		 		 			 				— Китай 			 			 				3,1% 			 			 				3,4% 			 		 		 			 				— Индия 			 			 				5,4% 			 			 				6,1% 			 		 		 			 				— Вьетнам 			 			 				1,7% 			 			 				2,4% 			 		 		 			 				— Индонезия 			 			 				2,0% 			 			 				3,1% 			 		 		 			 				Ближний Восток 			 			 				6,5% 			 			 				7,8% 			 		 		 			 				Южная и Центральная Америка 			 			 				2,7% 			 			 				3,1% 			 		 		 			 				Бразилия 			 			 				2,0% 			 			 				2,4% 			 		 		 			 				Мексика 			 			 				2,0% 			 			 				2,0% 			 		 		 			 				Аргентина 			 			 				2,0% 			 			 				2,4% 			 		 		 			 				Африка 			 			 				3,1% 			 			 				3,7% 			 		 		 			 				Австралия/Новая Зеландия 			 			 				1,4% 			 			 				1,7% 			 		 	 Несмотря на все препятствия, по итогам 2026 г. зарубежные продажи российских софтверных компаний все же могут вырасти более чем на 10% в долларовом выражении (с учетом той выручки, которая может остаться за пределами России). Однако для достижения уровня мировой конкурентоспособности, требующего огромных инвестиций, доходов от российского рынка будет недостаточно, и к нему необходимо будет прибавить выручку экспорта, которая должна быть как минимум, в разы больше, чем текущий доход от зарубежных продаж. По результатам исследования РУССОФТ, в 2025 году объем зарубежных продаж составил $6,3 млрд, а по итогам 2026 г. может достигнуть $7 млрд. При имеющемся темпе роста преодолеть планку в $40 млрд. удастся не ранее 2040 года, а к этому времени нынешние ориентиры уже будут не актуальны. Для наращивания экспорта можно рассчитывать, в первую очередь, на рост продаж на Ближнем зарубежье. Однако, хотя потенциал этого рынка еще не исчерпан, он в любом случае не принесет десятки миллиардов долларов. Для сравнения, один только индийский рынок может обеспечить продажи на порядок больше, чем все постсоветское пространство. Перспективными для освоения являются также рынки стран АСЕАН, прежде всего — Индонезии и Вьетнама. Более активной работе на Ближнем Востоке может помешать война. Большой интерес представляют страны Латинской Америки, но транспортные расходы и риски освоения еще непознанных рынков слишком велики. Для обеспечения прорыва на рынках дружественных стран необходимо устранять проблемы экспортеров, вызванные повышением налоговой нагрузки, которая к тому же может и не дать дополнительных поступлений в бюджет. Необходимо также повышать эффективность государственной поддержки экспорта ПО и услуг по его разработке, которую сейчас сложно признать высокой. До сих пор он не является приоритетом ни одной государственной программы и потому не может пользоваться финансовыми мерами поддержки инструментов Российского экспортного центра (кредиты покупателям, страхование поставок и предоставление гарантий Росэксимбанка для экспортных поставок). Стоит отметить, что сейчас отсутствуют показатели эффективности государственной политики в области развития ИТ-экспорта, поэтому приходится делать только общие предположения. Опрос РУССОФТ в рамках ежегодного Исследования софтверной индустрии показывает, что компании, которые уже присутствуют на зарубежных рынках, оценивают «Стимулирование экспорта ИТ государственными структурами и институтами» в целом удовлетворительно, но не очень высоко, даже в сравнении с другими направлениями государственной поддержки. В 2025 году опрошенные компании в среднем оценили стимулирование экспорта государством на 3,15 балла по 5-балльной системе, а при опросе в 2026 году этот показатель снизился до 3,01. Чтобы обеспечить рост зарубежных продаж до величины $40 млрд, необходимо начать со сбора полной информации о том, чего ждут экспортеры от государства и что их не устраивает. Затем уже формулировать или корректировать стратегию комплексной поддержки ИТ-экспорта, и прежде всего — признать экспорт ПО и услуг в качестве приоритета государственной поддержки экспорта в одной из Национальных программ развития. В принципе, проблемы на западных рынках в том или ином виде можно было предположить лет 15 назад, как и необходимость наращивания продаж в развивающихся странах для обеспечения технологического суверенитета. Не хватало стратегического видения и системного критического анализа. РУССОФТ в своих отчетах и пресс-релизах предлагал уделять больше внимания рынкам развивающихся стран, начиная с 2008 года. Современная ситуация толкает нас к тому, чтобы совместными усилиями с государственными структурами сформулировать стратегию развития экспорта софтверной индустрии и ИТ-экспорта в целом и закрепить за Россией статус одного из мировых технологических лидеров]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир, наблюдаемая в последние годы, в 2025 году имела продолжение — снова выявлено очевидное снижение продаж на рынках недружественных стран. А вот столь же очевидного увеличения реализации продуктов и услуг в дружественных странах пока не видно. В то же время, на переохлажденном российском ИТ-рынке с возросшей налоговой нагрузкой компаниям становится слишком тесно. В такой ситуации логично предположить их движение в тех направлениях, которые открыты для международной экспансии.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Направление в сторону недружественных стран сложно назвать перспективным. При всем желании российских компаний-разработчиков ПО сохранить продажи в Европе и Северной Америке, западные политики без устали работают над созданием непреодолимых для них препятствий. Многие их задумки реализуются, хотя при этом западные страны лишают свои предприятия и граждан доступа к качественным услугам и продуктам.&lltt;/p&ggtt;
&lltt;p&ggtt;По итогам 2025 года продажи отечественных софтверных компаний на рынках недружественных стран сократились примерно на 40% до ₽70 млрд. Сейчас страны Европы и США обеспечивают 2,4% совокупной выручки всей индустрии разработки ПО. При этом доля компаний, имеющих продажи в недружественных странах, намного больше — 14,3% от всех опрошенных компаний. Для Европы этот показатель равен 9,9%, а для США и Канады — 8,8% (в 2024 г. было 14,2% и 11,4% соответственно).&lltt;/p&ggtt;
&lltt;p&ggtt;Однако дальнейший уход с рынков западных стран столь же массово, как в предыдущие годы, компании не планируют. Сохранить присутствие на рынке Северной Америки в 2026 году рассчитывает 9,2%, что чуть больше, чем было по итогам 2025 года. Не исключено, что шансы остаться на одном из крупнейших рынков мира повысились, когда респонденты увидели потепление отношений между Россией и США после встречи в Анкоридже. Такой же эффект произвела в свое время победа Дональда Трампа на американских президентских выборах. Он вступил в должность в январе 2025 года, и вскоре стало известно о планах его встречи с Президентом РФ В.В. Путиным, которая состоялась в августе. С Европой все было хуже, ведь от них шли сигналы только на еще больший разрыв.&lltt;/p&ggtt;
&lltt;p&ggtt;Продажи в дружественных странах дальнего зарубежья в 2025 году в рублях не изменились и составили примерно ₽170 млрд. При этом доля этих продаж в совокупной выручке софтверных компаний упала — с 6,8% до 6,1%. Укрепление российской национальной валюты по отношению к доллару не позволило нарастить выручку в рублевом выражении. Однако в долларовом выражении продажи в дружественные страны все же увеличились примерно на 10%. Это касается как всего экспорта софтверных компаний, так и их продаж на рынках дружественных стран.&lltt;/p&ggtt;
&lltt;p&ggtt;Ближнее зарубежье обеспечило по итогам 2025 года 10,2% совокупной выручки российских разработчиков ПО. Годом ранее его доля была чуть меньше — 9,8%. Продажи на постсоветском пространстве выросли примерно на &lltt;nobr&ggtt;18-19%&lltt;/nobr&ggtt; в рублевом выражении (до ₽285 млрд) и примерно на 32% в долларах ($3,4 млрд). Указали на наличие продаж в этих странах 36,1% опрошенных компаний. На данный момент Ближнее зарубежье обеспечивает более половины экспорта российских софтверных компаний.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Распределение продаж российских софтверных компаний по группам рынков в &lltt;nobr&ggtt;2021-2025&lltt;/nobr&ggtt; годы&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; &lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2021&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2022&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2023&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2024&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2025&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Россия&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;52,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;65,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;76,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;78,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;81,3%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Ближнее зарубежье&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;13,45%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;11,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;10,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;9,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;10,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Россия и Ближнее зарубежье&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;65,95% &lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;77,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;86,35%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;88,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;91,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Дальнее зарубежье:&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td colspan="5"&ggtt; &lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;— недружественные страны (до 2022 г. «Западный мир»)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;25,25%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;12,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;7,6%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;4,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;— дружественные страны (до 2022 г. «Новые рынки»)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;10,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6,05%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;Согласно прогнозу, основанному на планах опрошенных компаний, по итогам 2026 года российские софтверные компании увеличат свое присутствие с реальными продажами почти на всех рынках. Предполагается, что даже в США будут продавать свои продукты и услуг больше компаний, чем было в 2025 году. Падение присутствия российских экспортеров прогнозируется только на рынке Европы. Прогнозируя расширение географии и рост экспорта, необходимо признать, что опыт предыдущих лет показывает, что ожидания компаний относительно роста экспорта часто оказываются несколько завышенными.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;strong&ggtt;Присутствие российских компаний на зарубежных рынках в 2025 году с прогнозом на 2026 год, %&lltt;/strong&ggtt; &lltt;strong&ggtt;опрошенных компаний&lltt;/strong&ggtt;&lltt;/p&ggtt;
&lltt;table&ggtt; 
	&lltt;tbody&ggtt; 
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; &lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2025 г.&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2026 г. (прогноз)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Ближнее зарубежье&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;36,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;40,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Казахстан&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;22,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;25,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Белоруссия&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;20,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;24,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Узбекистан&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;15,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;18,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Европа (без России и Ближнего зарубежья)&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;9,9%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;США/Канада&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;8,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;9,2%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Южная и Восточная Азия&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;7,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;7,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;— Китай&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;— Индия&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;5,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;— Вьетнам&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;— Индонезия&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Ближний Восток&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;6,5%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;7,8%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Южная и Центральная Америка&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Бразилия&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Мексика&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Аргентина&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,0%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;2,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Африка&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3,1%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;3,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
		&lltt;tr&ggtt; 
			&lltt;td&ggtt; 
				&lltt;p&ggtt;Австралия/Новая Зеландия&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1,4%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
			&lltt;td&ggtt; 
				&lltt;p&ggtt;1,7%&lltt;/p&ggtt;
			&lltt;/td&ggtt;
		&lltt;/tr&ggtt;
	&lltt;/tbody&ggtt;
&lltt;/table&ggtt;
&lltt;p&ggtt;Несмотря на все препятствия, по итогам 2026 г. зарубежные продажи российских софтверных компаний все же могут вырасти более чем на 10% в долларовом выражении (с учетом той выручки, которая может остаться за пределами России).&lltt;/p&ggtt;
&lltt;p&ggtt;Однако для достижения уровня мировой конкурентоспособности, требующего огромных инвестиций, доходов от российского рынка будет недостаточно, и к нему необходимо будет прибавить выручку экспорта, которая должна быть как минимум, в разы больше, чем текущий доход от зарубежных продаж. По результатам исследования РУССОФТ, в 2025 году объем зарубежных продаж составил $6,3 млрд, а по итогам 2026 г. может достигнуть $7 млрд. При имеющемся темпе роста преодолеть планку в $40 млрд. удастся не ранее 2040 года, а к этому времени нынешние ориентиры уже будут не актуальны.&lltt;/p&ggtt;
&lltt;p&ggtt;Для наращивания экспорта можно рассчитывать, в первую очередь, на рост продаж на Ближнем зарубежье. Однако, хотя потенциал этого рынка еще не исчерпан, он в любом случае не принесет десятки миллиардов долларов. Для сравнения, один только индийский рынок может обеспечить продажи на порядок больше, чем все постсоветское пространство. Перспективными для освоения являются также рынки стран АСЕАН, прежде всего — Индонезии и Вьетнама. Более активной работе на Ближнем Востоке может помешать война. Большой интерес представляют страны Латинской Америки, но транспортные расходы и риски освоения еще непознанных рынков слишком велики.&lltt;/p&ggtt;
&lltt;p&ggtt;Для обеспечения прорыва на рынках дружественных стран необходимо устранять проблемы экспортеров, вызванные повышением налоговой нагрузки, которая к тому же может и не дать дополнительных поступлений в бюджет. Необходимо также повышать эффективность государственной поддержки экспорта ПО и услуг по его разработке, которую сейчас сложно признать высокой. До сих пор он не является приоритетом ни одной государственной программы и потому не может пользоваться финансовыми мерами поддержки инструментов Российского экспортного центра (кредиты покупателям, страхование поставок и предоставление гарантий Росэксимбанка для экспортных поставок).&lltt;/p&ggtt;
&lltt;p&ggtt;Стоит отметить, что сейчас отсутствуют показатели эффективности государственной политики в области развития ИТ-экспорта, поэтому приходится делать только общие предположения. Опрос РУССОФТ в рамках ежегодного Исследования софтверной индустрии показывает, что компании, которые уже присутствуют на зарубежных рынках, оценивают «Стимулирование экспорта ИТ государственными структурами и институтами» в целом удовлетворительно, но не очень высоко, даже в сравнении с другими направлениями государственной поддержки. В 2025 году опрошенные компании в среднем оценили стимулирование экспорта государством на 3,15 балла по &lltt;nobr&ggtt;5-балльной&lltt;/nobr&ggtt; системе, а при опросе в 2026 году этот показатель снизился до 3,01.&lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы обеспечить рост зарубежных продаж до величины $40 млрд, необходимо начать со сбора полной информации о том, чего ждут экспортеры от государства и что их не устраивает. Затем уже формулировать или корректировать стратегию комплексной поддержки ИТ-экспорта, и прежде всего — признать экспорт ПО и услуг в качестве приоритета государственной поддержки экспорта в одной из Национальных программ развития.&lltt;/p&ggtt;
&lltt;p&ggtt;В принципе, проблемы на западных рынках в том или ином виде можно было предположить лет 15 назад, как и необходимость наращивания продаж в развивающихся странах для обеспечения технологического суверенитета. Не хватало стратегического видения и системного критического анализа. РУССОФТ в своих отчетах и пресс-релизах предлагал уделять больше внимания рынкам развивающихся стран, начиная с 2008 года. Современная ситуация толкает нас к тому, чтобы совместными усилиями с государственными структурами сформулировать стратегию развития экспорта софтверной индустрии и ИТ-экспорта в целом и закрепить за Россией статус одного из мировых технологических лидеров.&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235371</dbid>
<rubric>8</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Forrester: как технологическим руководителям следует относиться к квантовым вычислениям]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235370]]></link>
<description><![CDATA[Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители демонстрируют реальный прогресс в решении проблем масштабирования и коррекции ошибок. Существуют реалистичные планы по выпуску квантовых компьютеров, которые могут принести коммерческую выгоду. Но эта выгода будет неравномерной, проявляясь в конкретных классах высокоприоритетных задач и в разные временные горизонты. Технологическим руководителям необходимо практическое понимание того, где и когда квантовые вычисления, вероятно, будут иметь значение, пишет в корпоративном блоге Дэвид Мутер, главный аналитик Forrester. Квантовые компьютеры — это другие, а не более быстрые компьютеры Квантовые компьютеры — это не суперкомпьютеры с большей вычислительной мощностью, как это часто изображается в новостях. Классические компьютеры основаны на булевой логике, физически реализуемой в соответствии с уровнем напряжения в полупроводниках. Квантовые компьютеры основаны на линейной алгебре и интерференционных картинах, которые возникают из-за волновой природы квантовых объектов. Это делает квантовые вычисления принципиально иными, подходящими для других типов задач. Какие это типы задач? Речь идёт о задачах, связанных с экспоненциально растущим числом комбинаций, физическими системами квантового уровня или вероятностными результатами, которые трудно эффективно моделировать на классических системах. Примеры: оптимизация портфеля, молекулярное моделирование, открытие новых материалов, логистические маршруты, моделирование электрических сетей и некоторые формы стохастического анализа рисков. Что это значит? Если задачу можно решить классическим методом, она будет решаться классическим методом и впредь. Это также означает, что квантовые компьютеры станут компонентами более широкого вычислительного конвейера, решая вычислительные задачи, которые классические компьютеры не могут решить, а для остальных задач будут использоваться классические методы. Таким образом, квантовые вычисления не будут развиваться как самостоятельная платформа. Квантовые компьютеры будут гибридными, сочетая классические вычисления с квантовыми в единой системе. Поставщики, которые сделают квантовые вычисления доступными благодаря гибридным средам выполнения и интеграции с классическими вычислениями, станут главными лидерами рынка. Ценность квантовых вычислений эволюционирует в избирательную коммерческую значимость В краткосрочной перспективе состояние рынка по-прежнему будет определяться экспериментами. Прогресс будет достигнут за счет улучшения коррекции ошибок, совершенствования алгоритмов и более четкого понимания того, какие аппаратные средства масштабируемы. Наиболее неотложным приоритетом для бизнеса в это время будет безопасность. Организациям следует ускорить планирование постквантовой криптографии, поскольку достижения как в области квантового оборудования, так и в оптимизации алгоритма Шора для снижения требуемой вычислительной мощности квантовых вычислений приближают наступление «Дня квантовых вычислений» (Q-Day). В долгосрочной перспективе квантовые вычисления станут коммерчески значимыми, но избирательно. Они не станут повсеместным ускорителем для всех корпоративных технологий, как компьютеры, с которыми мы выросли. Скорее, это будет высокоточный инструмент для специализированных рабочих нагрузок. Наибольшие возможности будут сосредоточены в таких отраслях, как медико-биологические науки, химическая промышленность, материаловедение, финансовые услуги, логистика, производство и энергетика. Оценивайте потенциал квантовых вычислений по соответствию рабочей нагрузке Как и в случае с любой технологией, способ оценки квантовых вычислений заключается в определении того, какие бизнес-задачи обладают характеристиками, которые делают эту технологию потенциально полезной. Наиболее подходящие рабочие нагрузки, как правило, связаны с вычислительной сложностью, основанной на многомерной линейной алгебре, — это, например, оптимизация, молекулярное или физическое моделирование и вероятностное моделирование. Наименее подходящие рабочие нагрузки — это те, для которых уже существуют хорошие решения в классических системах или которые имеют большую сложность данных. Понимание перспектив и ограничений квантовых вычислений поможет организациям избежать как упущенных возможностей из-за чрезмерной самоуспокоенности, так и погони за ложными результатами, вызванной ажиотажем. Некоторым отраслям следует начать структурированное исследование уже сейчас, поскольку долгосрочный потенциал роста может проявиться раньше, чем ожидается. Другим следует отслеживать прогресс и избегать спекулятивных инвестиций до тех пор, пока прогресс в квантовых исследованиях не покажет более четкую совместимость рабочих нагрузок]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители демонстрируют реальный прогресс в решении проблем масштабирования и коррекции ошибок. Существуют реалистичные планы по выпуску квантовых компьютеров, которые могут принести коммерческую выгоду. Но эта выгода будет неравномерной, проявляясь в конкретных классах высокоприоритетных задач и в разные временные горизонты. Технологическим руководителям необходимо практическое понимание того, где и когда квантовые вычисления, вероятно, будут иметь значение, пишет в корпоративном блоге Дэвид Мутер, главный аналитик &lltt;/em&ggtt;&lltt;em&ggtt;Forrester&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;Квантовые компьютеры — это другие, а не более быстрые компьютеры&lltt;/h3&ggtt;
&lltt;p&ggtt;Квантовые компьютеры — это не суперкомпьютеры с большей вычислительной мощностью, как это часто изображается в новостях. Классические компьютеры основаны на булевой логике, физически реализуемой в соответствии с уровнем напряжения в полупроводниках. Квантовые компьютеры основаны на линейной алгебре и интерференционных картинах, которые возникают из-за волновой природы квантовых объектов. Это делает квантовые вычисления принципиально иными, подходящими для других типов задач.&lltt;/p&ggtt;
&lltt;p&ggtt;Какие это типы задач? Речь идёт о задачах, связанных с экспоненциально растущим числом комбинаций, физическими системами квантового уровня или вероятностными результатами, которые трудно эффективно моделировать на классических системах. Примеры: оптимизация портфеля, молекулярное моделирование, открытие новых материалов, логистические маршруты, моделирование электрических сетей и некоторые формы стохастического анализа рисков.&lltt;/p&ggtt;
&lltt;p&ggtt;Что это значит? Если задачу можно решить классическим методом, она будет решаться классическим методом и впредь. Это также означает, что квантовые компьютеры станут компонентами более широкого вычислительного конвейера, решая вычислительные задачи, которые классические компьютеры не могут решить, а для остальных задач будут использоваться классические методы.&lltt;/p&ggtt;
&lltt;p&ggtt;Таким образом, квантовые вычисления не будут развиваться как самостоятельная платформа. Квантовые компьютеры будут гибридными, сочетая классические вычисления с квантовыми в единой системе. Поставщики, которые сделают квантовые вычисления доступными благодаря гибридным средам выполнения и интеграции с классическими вычислениями, станут главными лидерами рынка.&lltt;/p&ggtt;
&lltt;h3&ggtt;Ценность квантовых вычислений эволюционирует в избирательную коммерческую значимость&lltt;/h3&ggtt;
&lltt;p&ggtt;В краткосрочной перспективе состояние рынка по-прежнему будет определяться экспериментами. Прогресс будет достигнут за счет улучшения коррекции ошибок, совершенствования алгоритмов и более четкого понимания того, какие аппаратные средства масштабируемы. Наиболее неотложным приоритетом для бизнеса в это время будет безопасность. Организациям следует ускорить планирование постквантовой криптографии, поскольку достижения как в области квантового оборудования, так и в оптимизации алгоритма Шора для снижения требуемой вычислительной мощности квантовых вычислений приближают наступление «Дня квантовых вычислений» (Q-Day).&lltt;/p&ggtt;
&lltt;p&ggtt;В долгосрочной перспективе квантовые вычисления станут коммерчески значимыми, но избирательно. Они не станут повсеместным ускорителем для всех корпоративных технологий, как компьютеры, с которыми мы выросли. Скорее, это будет высокоточный инструмент для специализированных рабочих нагрузок. Наибольшие возможности будут сосредоточены в таких отраслях, как медико-биологические науки, химическая промышленность, материаловедение, финансовые услуги, логистика, производство и энергетика.&lltt;/p&ggtt;
&lltt;h3&ggtt;Оценивайте потенциал квантовых вычислений по соответствию рабочей нагрузке&lltt;/h3&ggtt;
&lltt;p&ggtt;Как и в случае с любой технологией, способ оценки квантовых вычислений заключается в определении того, какие бизнес-задачи обладают характеристиками, которые делают эту технологию потенциально полезной. Наиболее подходящие рабочие нагрузки, как правило, связаны с вычислительной сложностью, основанной на многомерной линейной алгебре, — это, например, оптимизация, молекулярное или физическое моделирование и вероятностное моделирование. Наименее подходящие рабочие нагрузки — это те, для которых уже существуют хорошие решения в классических системах или которые имеют большую сложность данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Понимание перспектив и ограничений квантовых вычислений поможет организациям избежать как упущенных возможностей из-за чрезмерной самоуспокоенности, так и погони за ложными результатами, вызванной ажиотажем. Некоторым отраслям следует начать структурированное исследование уже сейчас, поскольку долгосрочный потенциал роста может проявиться раньше, чем ожидается. Другим следует отслеживать прогресс и избегать спекулятивных инвестиций до тех пор, пока прогресс в квантовых исследованиях не покажет более четкую совместимость рабочих нагрузок.&lltt;/p&ggtt;]]></source>
<adate>21.08.2026</adate>
<dbid>235370</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Цифровые двойники в производстве: почему последовательность важнее технологии]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235368]]></link>
<description><![CDATA[Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому, что организации пытаются перейти к оркестрации до того, как моделирование заслужит операционное доверие, пишет в корпоративном блоге Сара Ли, старший директор IDC по исследованиям ИТ-стратегий в производстве. Цифровые двойники превращаются из инструментов визуализации в операционную основу физического искусственного интеллекта на производственном участке, и этот термин теперь охватывает две возможности, которые часто рассматриваются как одно целое. Моделирование подтверждает изменения до того, как они достигнут производства. Оркестрация координирует выполнение в реальном времени машинами, системами ИИ и работниками. Какую возможность производитель создаст первой и насколько она будет обоснована, прежде чем перейти ко второй, часто определяет масштабируемость программы. Согласно отчету IDC «Industry Market Trends: Worldwide Manufacturing, 2026», примерно 57% производственных предприятий имеют инициативы в области ИИ, застрявшие на стадии проверки концепции, при этом менее половины демонстрируют измеримые результаты. Программы реализации цифровых двойников находятся в той же ситуации. Моделирование: проверка изменений до того, как они достигнут производственного цеха В этой роли цифровые двойники моделируют поведение процессов, производительность оборудования и конфигурации продукции, сочетая физические и основанные на данных модели, а также гибридные подходы, объединяющие инженерный опыт с операционными данными. Традиционная аналитика объясняет, что уже произошло. Моделирование позволяет производителям изучить, что может произойти дальше — это становится все более важным, поскольку автоматизация и роботизация повышают стоимость неудачных изменений. Сценарии применения различаются в зависимости от отраслевой структуры. Процессные производства моделируют отдельные технологические операции и переходы между партиями — прогнозируют производительность линий отбеливания на целлюлозно-бумажных комбинатах, моделируют загрязнения теплообменников на химических заводах или симулируют ферментацию в производстве напитков. Дискретные производства работают на уровне ячеек и линий: виртуальный ввод в эксплуатацию роботизированных ячеек до прибытия оборудования на место, балансировка времени такта при сборке смешанных моделей и генерация синтетических данных для обучения моделей визуального контроля. Возможности одинаковые, единицы анализа разные. Программы, заимствующие эталонную архитектуру с не той стороны этого разделения, как правило, застревают на структуре данных задолго до того, как застрянут на моделировании. Оркестрация: превращение интеллекта в скоординированные действия В этой роли цифровые двойники объединяют данные реального времени с датчиков, контрольных систем и систем управления производственными процессами для координации решений между машинами, агентами ИИ и работниками. Области применения включают координацию парков автономных мобильных роботов (AMR) и автоматизированных транспортных средств (AGV), динамическое балансирование производственных линий, управление энергетическими нагрузками в системах коммунального хозяйства и диспетчеризацию мероприятий по техническому обслуживанию или контролю качества в зависимости от изменяющихся условий. По мере внедрения агентного ИИ в производственную среду оркестрация становится средой выполнения, определяющей, какой агент действует, когда и в каких границах. Производители уже консервативно устанавливают эти границы. Согласно опросу IDC «2026 Agentic AI Functional Use», примерно 43% респондентов из производственной отрасли сообщают, что их агенты либо не обладают полномочиями по принятию решений, либо требуют одобрения человека для каждого решения. Только 8,5% допускают полную автономию по любому критически важному вопросу. В то же время 62,5% сообщают, что расширение автономии агентов находится в стадии активного рассмотрения. Устранение этого разрыва — это та работа, которую должна выполнить оркестрация. Почему последовательность не является необязательной Моделирование отдает приоритет точности прогнозирования и экспериментам в автономном режиме. Оркестрация отдает приоритет задержке, надежности и интеграции с системами управления и выполнения. Объединение их в единую программу обычно означает, что один набор требований уступает другому, и редко бывает очевидно заранее, какой именно. Доверие не предоставляется по запросу. Операторам и инженерам необходимы доказательства того, что модель отражает реальные условия работы предприятия, прежде чем они начнут действовать в соответствии с ее рекомендациями, и задолго до того, как они позволят агенту действовать от их имени. Трех ложных срабатываний за квартал обычно достаточно, чтобы операторы перестали открывать дашборд. Искушение перейти непосредственно к оркестрации понятно. Координация роботов, агентов ИИ и производственных систем обещает видимые операционные преимущества. Но без проверенного цифрового представления производства организации рискуют ускорить принятие решений, которым они еще не научились доверять. Программы, дающие результаты, начинаются с принятия операционного решения, а не с выбора технологии. Независимо от того, является ли целью выход годной продукции с первого раза, время переналадки, доступность активов или энергоемкость, это решение принимается в первую очередь. Что именно должен обеспечивать цифровой двойник? От моделей мира к цифровым двойникам и физическому ИИ По мере того, как производители готовятся к внедрению физического ИИ, различие между общим интеллектом и оперативным интеллектом становится все более важным. Модели мира дают системам ИИ широкое понимание того, как ведет себя физическая среда. Цифровые двойники обеспечивают промышленную специфику, которой не хватает этим моделям: геометрию предприятия, параметры процессов, логику управления и историю эксплуатации. Вместе они создают основу для более надежного физического ИИ. Модель мира может понимать, как ведут себя объекты и силы в целом, но цифровой двойник обеспечивает контекст, необходимый для определения того, является ли действие безопасным и эффективным на конкретном производстве, на конкретной линии, с конкретными материалами и ограничениями. Что требуется для масштабирования Ограничения должны быть согласованы между процессными и дискретными средами. Точность двойника зависит от точности потребляемых им данных. Без непрерывной синхронизации он превращается в устаревшее представление, которое обладает авторитетом модели, но не ее точностью. Безопасность становится все более важной по мере того, как двойники расширяют связность в операционных средах. Соединение инженерных моделей, систем ИИ и управления производством расширяет поверхность атаки и требует обеспечения безопасности на этапе проектирования для архитектуры, связности и управления. Работа также меняется по мере того, как двойники и агенты получают все больше возможностей принятия решений. Операторы и технические специалисты переходят от выполнения рутинных задач к контролю за системами, проверке рекомендаций и управлению исключениями. Это требует четкого определения ролей и путей эскалации, поскольку одних дополнительных часов обучения недостаточно для устранения этого пробела. Успешные программы цифровых двойников редко являются исключительной прерогативой ИТ-службы. Они требуют сотрудничества между операционными, инженерными, операционными группами, группами обработки данных и функциями управления ИИ. По мере того, как двойники эволюционируют из инженерных инструментов в платформы для принятия операционных решений, определение ответственности становится столь же важным, как и архитектура. Вопрос, который стоит изучить производителям Для руководителей операционных подразделений реальный вопрос заключается в том, достаточно ли развиты аспекты фундамента данных, проверки моделей, доверия операторов и управления, чтобы перейти на следующую ступень: от визуализации к автономному моделированию и далее к замкнутой системе оркестрации и к принятию агентами автономных решений. Переход на каждую следующую ступень должна быть обеспечен подтвержденными результатами на предыдущей. Программы, которые пропускают ступень, не движутся быстрее. Они застревают из-за отсутствия доверия модели, а доверие восстановить сложнее, чем исправить модель]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому, что организации пытаются перейти к оркестрации до того, как моделирование заслужит операционное доверие, пишет в корпоративном блоге Сара Ли, старший директор &lltt;/em&ggtt;&lltt;em&ggtt;IDC&lltt;/em&ggtt; &lltt;em&ggtt;по исследованиям ИТ-стратегий в производстве.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Цифровые двойники превращаются из инструментов визуализации в операционную основу физического искусственного интеллекта на производственном участке, и этот термин теперь охватывает две возможности, которые часто рассматриваются как одно целое. &lltt;em&ggtt;Моделирование&lltt;/em&ggtt; подтверждает изменения до того, как они достигнут производства. &lltt;em&ggtt;Оркестрация&lltt;/em&ggtt; координирует выполнение в реальном времени машинами, системами ИИ и работниками.&lltt;/p&ggtt;
&lltt;p&ggtt;Какую возможность производитель создаст первой и насколько она будет обоснована, прежде чем перейти ко второй, часто определяет масштабируемость программы.&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно отчету IDC «Industry Market Trends: Worldwide Manufacturing, 2026», примерно 57% производственных предприятий имеют инициативы в области ИИ, застрявшие на стадии проверки концепции, при этом менее половины демонстрируют измеримые результаты.&lltt;/p&ggtt;
&lltt;p&ggtt;Программы реализации цифровых двойников находятся в той же ситуации.&lltt;/p&ggtt;
&lltt;h3&ggtt;Моделирование: проверка изменений до того, как они достигнут производственного цеха&lltt;/h3&ggtt;
&lltt;p&ggtt;В этой роли цифровые двойники моделируют поведение процессов, производительность оборудования и конфигурации продукции, сочетая физические и основанные на данных модели, а также гибридные подходы, объединяющие инженерный опыт с операционными данными. Традиционная аналитика объясняет, что уже произошло. Моделирование позволяет производителям изучить, что может произойти дальше — это становится все более важным, поскольку автоматизация и роботизация повышают стоимость неудачных изменений.&lltt;/p&ggtt;
&lltt;p&ggtt;Сценарии применения различаются в зависимости от отраслевой структуры. Процессные производства моделируют отдельные технологические операции и переходы между партиями — прогнозируют производительность линий отбеливания на целлюлозно-бумажных комбинатах, моделируют загрязнения теплообменников на химических заводах или симулируют ферментацию в производстве напитков. Дискретные производства работают на уровне ячеек и линий: виртуальный ввод в эксплуатацию роботизированных ячеек до прибытия оборудования на место, балансировка времени такта при сборке смешанных моделей и генерация синтетических данных для обучения моделей визуального контроля.&lltt;/p&ggtt;
&lltt;p&ggtt;Возможности одинаковые, единицы анализа разные. Программы, заимствующие эталонную архитектуру с не той стороны этого разделения, как правило, застревают на структуре данных задолго до того, как застрянут на моделировании.&lltt;/p&ggtt;
&lltt;h3&ggtt;Оркестрация: превращение интеллекта в скоординированные действия&lltt;/h3&ggtt;
&lltt;p&ggtt;В этой роли цифровые двойники объединяют данные реального времени с датчиков, контрольных систем и систем управления производственными процессами для координации решений между машинами, агентами ИИ и работниками. Области применения включают координацию парков автономных мобильных роботов (AMR) и автоматизированных транспортных средств (AGV), динамическое балансирование производственных линий, управление энергетическими нагрузками в системах коммунального хозяйства и диспетчеризацию мероприятий по техническому обслуживанию или контролю качества в зависимости от изменяющихся условий.&lltt;/p&ggtt;
&lltt;p&ggtt;По мере внедрения агентного ИИ в производственную среду оркестрация становится средой выполнения, определяющей, какой агент действует, когда и в каких границах. Производители уже консервативно устанавливают эти границы.&lltt;/p&ggtt;
&lltt;p&ggtt;Согласно опросу IDC «2026 Agentic AI Functional Use», примерно 43% респондентов из производственной отрасли сообщают, что их агенты либо не обладают полномочиями по принятию решений, либо требуют одобрения человека для каждого решения. Только 8,5% допускают полную автономию по любому критически важному вопросу. В то же время 62,5% сообщают, что расширение автономии агентов находится в стадии активного рассмотрения.&lltt;/p&ggtt;
&lltt;p&ggtt;Устранение этого разрыва — это та работа, которую должна выполнить оркестрация.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему последовательность не является необязательной&lltt;/h3&ggtt;
&lltt;p&ggtt;Моделирование отдает приоритет точности прогнозирования и экспериментам в автономном режиме. Оркестрация отдает приоритет задержке, надежности и интеграции с системами управления и выполнения. Объединение их в единую программу обычно означает, что один набор требований уступает другому, и редко бывает очевидно заранее, какой именно.&lltt;/p&ggtt;
&lltt;p&ggtt;Доверие не предоставляется по запросу. Операторам и инженерам необходимы доказательства того, что модель отражает реальные условия работы предприятия, прежде чем они начнут действовать в соответствии с ее рекомендациями, и задолго до того, как они позволят агенту действовать от их имени. Трех ложных срабатываний за квартал обычно достаточно, чтобы операторы перестали открывать дашборд.&lltt;/p&ggtt;
&lltt;p&ggtt;Искушение перейти непосредственно к оркестрации понятно. Координация роботов, агентов ИИ и производственных систем обещает видимые операционные преимущества. Но без проверенного цифрового представления производства организации рискуют ускорить принятие решений, которым они еще не научились доверять.&lltt;/p&ggtt;
&lltt;p&ggtt;Программы, дающие результаты, начинаются с принятия операционного решения, а не с выбора технологии. Независимо от того, является ли целью выход годной продукции с первого раза, время переналадки, доступность активов или энергоемкость, это решение принимается в первую очередь. Что именно должен обеспечивать цифровой двойник?&lltt;/p&ggtt;
&lltt;h3&ggtt;От моделей мира к цифровым двойникам и физическому ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;По мере того, как производители готовятся к внедрению физического ИИ, различие между общим интеллектом и оперативным интеллектом становится все более важным.&lltt;/p&ggtt;
&lltt;p&ggtt;Модели мира дают системам ИИ широкое понимание того, как ведет себя физическая среда. Цифровые двойники обеспечивают промышленную специфику, которой не хватает этим моделям: геометрию предприятия, параметры процессов, логику управления и историю эксплуатации.&lltt;/p&ggtt;
&lltt;p&ggtt;Вместе они создают основу для более надежного физического ИИ. Модель мира может понимать, как ведут себя объекты и силы в целом, но цифровой двойник обеспечивает контекст, необходимый для определения того, является ли действие безопасным и эффективным на конкретном производстве, на конкретной линии, с конкретными материалами и ограничениями.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что требуется для масштабирования&lltt;/h3&ggtt;
&lltt;p&ggtt;Ограничения должны быть согласованы между процессными и дискретными средами.&lltt;/p&ggtt;
&lltt;p&ggtt;Точность двойника зависит от точности потребляемых им данных. Без непрерывной синхронизации он превращается в устаревшее представление, которое обладает авторитетом модели, но не ее точностью.&lltt;/p&ggtt;
&lltt;p&ggtt;Безопасность становится все более важной по мере того, как двойники расширяют связность в операционных средах. Соединение инженерных моделей, систем ИИ и управления производством расширяет поверхность атаки и требует обеспечения безопасности на этапе проектирования для архитектуры, связности и управления.&lltt;/p&ggtt;
&lltt;p&ggtt;Работа также меняется по мере того, как двойники и агенты получают все больше возможностей принятия решений. Операторы и технические специалисты переходят от выполнения рутинных задач к контролю за системами, проверке рекомендаций и управлению исключениями. Это требует четкого определения ролей и путей эскалации, поскольку одних дополнительных часов обучения недостаточно для устранения этого пробела.&lltt;/p&ggtt;
&lltt;p&ggtt;Успешные программы цифровых двойников редко являются исключительной прерогативой ИТ-службы. Они требуют сотрудничества между операционными, инженерными, операционными группами, группами обработки данных и функциями управления ИИ. По мере того, как двойники эволюционируют из инженерных инструментов в платформы для принятия операционных решений, определение ответственности становится столь же важным, как и архитектура.&lltt;/p&ggtt;
&lltt;h3&ggtt;Вопрос, который стоит изучить производителям&lltt;/h3&ggtt;
&lltt;p&ggtt;Для руководителей операционных подразделений реальный вопрос заключается в том, достаточно ли развиты аспекты фундамента данных, проверки моделей, доверия операторов и управления, чтобы перейти на следующую ступень: от визуализации к автономному моделированию и далее к замкнутой системе оркестрации и к принятию агентами автономных решений.&lltt;/p&ggtt;
&lltt;p&ggtt;Переход на каждую следующую ступень должна быть обеспечен подтвержденными результатами на предыдущей.&lltt;/p&ggtt;
&lltt;p&ggtt;Программы, которые пропускают ступень, не движутся быстрее. Они застревают из-за отсутствия доверия модели, а доверие восстановить сложнее, чем исправить модель.&lltt;/p&ggtt;]]></source>
<adate>19.08.2026</adate>
<dbid>235368</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Промышленная автоматизация;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[CommuniGate Pro представила первый официальный релиз десктопного и мобильного приложения]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235362]]></link>
<description><![CDATA[Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии десктопного и мобильного клиентских приложений. Релиз завершает этап бета-тестирования и переводит продукт на новую ступень готовности. Обновление включает более 20 новых функций, реализованных в постоянном диалоге с пользователями: изменения коснулись календаря, редактора написания письма, доступа к учетным записям и новых функций безопасности. Релиз направлен на решение трех задач — ускорение совместной работы, повышение прозрачности коммуникаций и упрощение рутинных операций. Пользователи получили возможность делиться своим расписанием с внешними партнерами или клиентами через публичные ссылки — теперь для просмотра календаря не требуется создавать учетную запись. При командной работе доступ к календарям предоставляется с гибкой настройкой уровней прав, что делает планирование прозрачным и управляемым. Полноформатный планировщик событий позволяет детально настраивать встречи и мероприятия в интуитивно понятном интерфейсе. Реализована возможность редактировать или удалять отдельное событие внутри повторяющейся серии, не нарушая всю последовательность, а также отображать время начала серии непосредственно в календаре. Значительные улучшения затронули и почтовый редактор. Теперь в тело письма можно мгновенно вставлять изображения, файлы и таблицы прямо из буфера обмена, а также создавать и редактировать таблицы встроенными средствами. Функция отложенной отправки позволяет задать точную дату и время доставки письма, а проверка орфографии подчеркивает ошибки, помогая избегать опечаток. Статус отправленных сообщений помогают отслеживать уведомления о доставке и прочтении с возможностью выбора автоматического или ручного режима в настройках. Для совместной работы с почтой и учетными записями реализован ряд новых возможностей. Доступ к почтовым папкам коллег настраивается для совместной работы, а функция делегирования позволяет доверенным лицам отправлять письма, принимать, переносить или назначать встречи от имени другого сотрудника. При отправке можно выбрать имя, от которого будет отправлено письмо, что обеспечивает прозрачность для получателя. Также пользователи могут создавать псевдонимы для своих учетных записей, чтобы лучше структурировать входящий поток. В релизе появились важные инструменты для защиты аккаунтов. Пользователи теперь могут самостоятельно сменить пароль непосредственно из интерфейса приложения, а также настроить двухфакторную аутентификацию — это обеспечивает дополнительный уровень защиты от несанкционированного доступа, что критически важно для корпоративных коммуникаций. Одним из ключевых нововведений стал функционал создания локальных архивов. Теперь можно сохранять свои почтовые сообщения непосредственно на устройстве, обеспечивая офлайн-доступ и дополнительную сохранность данных. На текущий момент доступно создание архивов и вложенных подпапок, архивация одного письма и группы писем, ручная архивация всей папки через контекстное меню, автоархивация по настройкам, удаление архивов и папок в них, ответ на письма из архива, пересылка писем из архива, работа с метками в архивах. Повышению удобства повседневной работы также способствуют обновленный поиск адресатов, который предлагает наиболее релевантных получателей при вводе фамилии, настройки режима удаления писем — через корзину, напрямую или пометку письма как удаленного, а также редизайн карточки контакта с более структурированным отображением информации. Для ускорения навигации добавлены горячие клавиши и возможность открывать письмо в новом окне одним нажатием Enter. Производительность приложения в целом была улучшена: оно стало быстрее и отзывчивее. «Мы сфокусировались на том, что напрямую влияет на эффективность повседневной работы, — прокомментировал Борис Моисеев, директор департамента разработки CommuniGate Pro. — Возможность вставить таблицу из Excel, файл или изображение в письмо за секунду, открыть календарь внешнему партнеру без создания учетной записи или выполнить проверку орфографии при написании письма — это базовые инструменты, экономящие реальное время каждого сотрудника каждый день». Первый официальный релиз десктопного и мобильного приложений уже доступен пользователям с действующей лицензией]]></description>
<source><![CDATA[&lltt;p&ggtt;Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии десктопного и мобильного клиентских приложений. Релиз завершает этап бета-тестирования и переводит продукт на новую ступень готовности. Обновление включает более 20 новых функций, реализованных в постоянном диалоге с пользователями: изменения коснулись календаря, редактора написания письма, доступа к учетным записям и новых функций безопасности.&lltt;/p&ggtt;
&lltt;p&ggtt;Релиз направлен на решение трех задач — ускорение совместной работы, повышение прозрачности коммуникаций и упрощение рутинных операций.&lltt;/p&ggtt;
&lltt;p&ggtt;Пользователи получили возможность делиться своим расписанием с внешними партнерами или клиентами через публичные ссылки — теперь для просмотра календаря не требуется создавать учетную запись. При командной работе доступ к календарям предоставляется с гибкой настройкой уровней прав, что делает планирование прозрачным и управляемым. Полноформатный планировщик событий позволяет детально настраивать встречи и мероприятия в интуитивно понятном интерфейсе. Реализована возможность редактировать или удалять отдельное событие внутри повторяющейся серии, не нарушая всю последовательность, а также отображать время начала серии непосредственно в календаре.&lltt;/p&ggtt;
&lltt;p&ggtt;Значительные улучшения затронули и почтовый редактор. Теперь в тело письма можно мгновенно вставлять изображения, файлы и таблицы прямо из буфера обмена, а также создавать и редактировать таблицы встроенными средствами. Функция отложенной отправки позволяет задать точную дату и время доставки письма, а проверка орфографии подчеркивает ошибки, помогая избегать опечаток. Статус отправленных сообщений помогают отслеживать уведомления о доставке и прочтении с возможностью выбора автоматического или ручного режима в настройках.&lltt;/p&ggtt;
&lltt;p&ggtt;Для совместной работы с почтой и учетными записями реализован ряд новых возможностей. Доступ к почтовым папкам коллег настраивается для совместной работы, а функция делегирования позволяет доверенным лицам отправлять письма, принимать, переносить или назначать встречи от имени другого сотрудника. При отправке можно выбрать имя, от которого будет отправлено письмо, что обеспечивает прозрачность для получателя. Также пользователи могут создавать псевдонимы для своих учетных записей, чтобы лучше структурировать входящий поток.&lltt;/p&ggtt;
&lltt;p&ggtt;В релизе появились важные инструменты для защиты аккаунтов. Пользователи теперь могут самостоятельно сменить пароль непосредственно из интерфейса приложения, а также настроить двухфакторную аутентификацию — это обеспечивает дополнительный уровень защиты от несанкционированного доступа, что критически важно для корпоративных коммуникаций.&lltt;/p&ggtt;
&lltt;p&ggtt;Одним из ключевых нововведений стал функционал создания локальных архивов. Теперь можно сохранять свои почтовые сообщения непосредственно на устройстве, обеспечивая офлайн-доступ и дополнительную сохранность данных. На текущий момент доступно создание архивов и вложенных подпапок, архивация одного письма и группы писем, ручная архивация всей папки через контекстное меню, автоархивация по настройкам, удаление архивов и папок в них, ответ на письма из архива, пересылка писем из архива, работа с метками в архивах.&lltt;/p&ggtt;
&lltt;p&ggtt;Повышению удобства повседневной работы также способствуют обновленный поиск адресатов, который предлагает наиболее релевантных получателей при вводе фамилии, настройки режима удаления писем — через корзину, напрямую или пометку письма как удаленного, а также редизайн карточки контакта с более структурированным отображением информации. Для ускорения навигации добавлены горячие клавиши и возможность открывать письмо в новом окне одним нажатием Enter. Производительность приложения в целом была улучшена: оно стало быстрее и отзывчивее.&lltt;/p&ggtt;
&lltt;p&ggtt;«Мы сфокусировались на том, что напрямую влияет на эффективность повседневной работы, — прокомментировал Борис Моисеев, директор департамента разработки CommuniGate Pro. — Возможность вставить таблицу из Excel, файл или изображение в письмо за секунду, открыть календарь внешнему партнеру без создания учетной записи или выполнить проверку орфографии при написании письма — это базовые инструменты, экономящие реальное время каждого сотрудника каждый день».&lltt;/p&ggtt;
&lltt;p&ggtt;Первый официальный релиз десктопного и мобильного приложений уже доступен пользователям с действующей лицензией.&lltt;/p&ggtt;]]></source>
<adate>18.08.2026</adate>
<dbid>235362</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ПК и периферия]]></tag>
</item>
<item>
<title><![CDATA[«Аладдин» и «Пассворк» подтвердили совместимость JaCarta Management System 4LX и менеджера паролей Пассворк]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235363]]></link>
<description><![CDATA[Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX) и менеджера паролей Пассворк. Корректность совместной работы решений подтверждена сертификатом, выданным по результатам испытаний. Эта совместимость закрывает конкретную задачу заказчиков: организовать вход в менеджер паролей через уже действующую в компании систему усиленной аутентификации без создания отдельных учётных данных. Таким образом, пользователю не нужно запоминать ещё один пароль или носить отдельный токен для доступа к хранилищу — он проходит аутентификацию через сервис JaCarta Identity Provider (JIP), входящий в JMS4LX. JaCarta Management System 4LX для Linux — это система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами. В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) — провайдер аутентификации/авторизации в приложения с поддержкой протоколов SAML и OIDC. Пассворк — это российский корпоративный менеджер паролей и секретов с возможностью развёртывания на собственном сервере заказчика или в облаке. Решение предназначено для безопасного хранения, управления и совместного использования учётных данных внутри компаний. Пассворк поддерживает ролевую модель доступа, полный аудит действий, интеграцию со службами каталогов и системами мониторинга безопасности. Пассворк включён в Единый реестр российского программного обеспечения (№ 6147 от 13.01.2020) и сертифицирован ФСТЭК России по 4-му уровню доверия (№ 5063 от 30.04.2026). «Заказчики, которые строят ИТ-инфраструктуру на отечественных решениях, должны быть уверены: продукты работают вместе корректно и без доработок. Сертификат даёт эту уверенность на уровне вендоров: совместимость Пассворка и JMS4LX зафиксирована документально, протестирована и будет поддерживаться», — прокомментировал Андрей Пьянков, генеральный директор «Пассворк». «Подтверждение совместимости JMS4LX и Пассворка позволяет заказчикам использовать уже существующую инфраструктуру аутентификации для доступа к менеджеру паролей. Для компаний, где JIP уже используется в качестве корпоративного SSO, это означает, что сотрудникам не нужно заводить отдельные учётные данные для Пассворка», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин»]]></description>
<source><![CDATA[&lltt;p&ggtt;Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX) и менеджера паролей Пассворк.&lltt;/p&ggtt;
&lltt;p&ggtt;Корректность совместной работы решений подтверждена сертификатом, выданным по результатам испытаний. Эта совместимость закрывает конкретную задачу заказчиков: организовать вход в менеджер паролей через уже действующую в компании систему усиленной аутентификации без создания отдельных учётных данных. Таким образом, пользователю не нужно запоминать ещё один пароль или носить отдельный токен для доступа к хранилищу — он проходит аутентификацию через сервис JaCarta Identity Provider (JIP), входящий в JMS4LX.&lltt;/p&ggtt;
&lltt;p&ggtt;JaCarta Management System 4LX для Linux — это система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами. В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) — провайдер аутентификации/авторизации в приложения с поддержкой протоколов SAML и OIDC. &lltt;/p&ggtt;
&lltt;p&ggtt;Пассворк — это российский корпоративный менеджер паролей и секретов с возможностью развёртывания на собственном сервере заказчика или в облаке. Решение предназначено для безопасного хранения, управления и совместного использования учётных данных внутри компаний. Пассворк поддерживает ролевую модель доступа, полный аудит действий, интеграцию со службами каталогов и системами мониторинга безопасности. Пассворк включён в Единый реестр российского программного обеспечения (№ 6147 от 13.01.2020) и сертифицирован ФСТЭК России по &lltt;nobr&ggtt;4-му&lltt;/nobr&ggtt; уровню доверия (№ 5063 от 30.04.2026).&lltt;/p&ggtt;
&lltt;p&ggtt;«Заказчики, которые строят ИТ-инфраструктуру на отечественных решениях, должны быть уверены: продукты работают вместе корректно и без доработок. Сертификат даёт эту уверенность на уровне вендоров: совместимость Пассворка и JMS4LX зафиксирована документально, протестирована и будет поддерживаться», — прокомментировал Андрей Пьянков, генеральный директор «Пассворк».&lltt;/p&ggtt;
&lltt;p&ggtt;«Подтверждение совместимости JMS4LX и Пассворка позволяет заказчикам использовать уже существующую инфраструктуру аутентификации для доступа к менеджеру паролей. Для компаний, где JIP уже используется в качестве корпоративного SSO, это означает, что сотрудникам не нужно заводить отдельные учётные данные для Пассворка», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».&lltt;/p&ggtt;]]></source>
<adate>18.08.2026</adate>
<dbid>235363</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность]]></tag>
</item>
<item>
<title><![CDATA[Почему фабрики ПО возвращаются — и как они работают в эпоху ИИ]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235361]]></link>
<description><![CDATA[Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности с фабрикой о экономически эффективном массовом производстве их совков для уборки собачьих экскрементов, комфортных носков или мочалок. Идея массового производства может быть актуальна и для доставки ПО, пишет на портале ZDNet независимый аналитик Джо Маккендрик. Представьте, что вы отправляете свой прототип — например, начальную версию приложения, написанную с помощью вайб-кодинга, — в сервис, который будет массово производить ваше решение в повторяемом автоматизированном режиме для распространения среди широкой аудитории. В этом и заключается обещание «фабрики ПО». В этой концепции нет ничего нового — она была очень популярна около двух десятилетий назад, когда разработка ПО стала более компонентной и повторяемой. Microsoft заговорила о фабриках ПО еще в 2008 г. Идея на некоторое время затихла, но теперь она вернулась, подпитываемая быстрым созданием программного кода, генерируемого и управляемого искусственным интеллектом. До недавнего времени, даже при наличии автоматизации и практик DevOps, «кодирование создавало узкие места для многих организаций, — говорит Мориц Плассниг, генеральный директор CloudBees. — Приходилось нанимать больше инженеров, но это было очень сложно и дорого». Сегодняшняя фабрика ПО построена на моделях ИИ Благодаря возможностям кодирования базовых моделей ИИ и связанных с ними агентов, концепция фабрики ПО возродилась — и сегодня серьезно рассматривается автоматизация жизненного цикла разработки ПО на уровне повторяющихся этапов. С помощью агентного кодирования «мы меньше ограничены в части кодирования», отмечает Плассниг. Оно также может повысить роль ИТ-специалистов: «Мастерство разработчиков никуда не денется, поскольку разработчики и инженеры переходят от написания кода к принятию решений о том, что будет создано и выпущено». Современная концепция фабрики ПО построена на основе моделей ИИ, представленных на рынке, — и эта концепция практически одинакова для всех моделей. «За последние полтора года многие компании, находящиеся на переднем крае использования агентов для автоматизации жизненного цикла разработки ПО, создавали одну и ту же машину и независимо друг от друга приходили к одному и тому же выводу о том, как эта машина должна выглядеть», — говорит Джеймин Уэст, инженер-разработчик и технологический евангелист. Среди компаний, создающих фабрики ПО, — такие светила современной агентной экономики, как Anthropic, Cognition, Cursor, Factory, Google, Github, OpenAI и Ramp. «Каждая из этих компаний пришла к одной и той же форме, — отмечает Уэст. — На данном этапе очень важно понимать, что это компании, находящиеся на передовой, и что формируется четкая закономерность в том, как они структурируют всю свою инженерную работу». По словам Пласснига, фабрика ПО служит способом быстрого воплощения идей: «Допустим, кто-то работает в службе поддержки клиентов, и у него возникает интересная идея, основанная на отзывах клиентов. Такой человек с идеей ПО может отправить ее на фабрику, где создается первая итерация. Далее специалисты по продуктам, инженеры и ИТ-специалисты изучают ее. Затем фабрика может снова взять ее и воплотить в жизнь. Это подобно тому, как в автоиндустрии появляется экспериментальный прототип, который потом передается на завод, который производит автомобили в больших масштабах». Фабрика ПО помогает решить проблему проверки и поддержки сотен тысяч строк кода, а также релизов, обновлений и модернизаций ПО, которые сегодня ежедневно происходят во многих организациях. «Вы хотите знать, действительно ли ПО работает, нет ли ошибок или хотя бы резкого роста частоты ошибок. Или, может быть, оно работает, но не превышает ли потребление памяти агентом желаемый уровень? Сегодня люди проверяют все эти оповещения, но если изменений будет в 100 раз больше, например, каждые несколько минут, система сломается. Мы дойдём до того момента, когда люди больше не смогут проверять, что работает, а что нет», — говорит Плассниг. Как выглядит фабрика ПО? Уэст описывает типичную фабрику, поддерживаемую базовыми моделями, как состоящую из шести компонентов: 	 Очередь. «Работа поступает в виде проблемы, а не промпта». 	 Плоскость управления. «Надежный уровень, а не ноутбук». 	 Песочница. «Одна на задачу. Уничтожается после ее завершения». 	 Запрос на слияние. «Единица вывода. Его получает человек». 	 Поток событий. «Отслеживает каждое действие. Прерывает его, не нарушая выполнение». 	 Надежная память. «Песочница выполняет каждый запуск. То, что не записано в файл, не сохраняется». Конечно, фабрики ПО, какими бы эффективными они ни были, не являются панацеей для внедрения передовых методов разработки ПО. «Сейчас уже не секрет, что генерация кода стала невероятно простой, — говорит Уэст. — Она теперь невероятно дешева. Но препятствием для многих компаний стала верификация. Убедиться, что агенты пишут код, очень легко. Но убедиться в правильности этого кода по-прежнему остается серьезной инженерной проблемой. И важно понимать, что создание фабрики ПО не означает, что вы просто отказываетесь от верификации или снижаете качество своей кодовой базы»]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть&nbsp;ли у&nbsp;них договоренности с&nbsp;фабрикой о&nbsp;экономически эффективном массовом производстве их&nbsp;совков для уборки собачьих экскрементов, комфортных носков или мочалок. Идея массового производства может быть актуальна и&nbsp;для доставки&nbsp;ПО, пишет на&nbsp;портале &lltt;/em&ggtt;&lltt;em&ggtt;ZDNet&lltt;/em&ggtt; &lltt;em&ggtt;независимый аналитик Джо Маккендрик.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Представьте, что вы&nbsp;отправляете свой прототип&nbsp;— например, начальную версию приложения, написанную с&nbsp;помощью вайб-кодинга,&nbsp;— в&nbsp;сервис, который будет массово производить ваше решение в&nbsp;повторяемом автоматизированном режиме для распространения среди широкой аудитории. В&nbsp;этом и&nbsp;заключается обещание «фабрики ПО».&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;этой концепции нет ничего нового&nbsp;— она была очень популярна около двух десятилетий назад, когда разработка&nbsp;ПО стала более компонентной и&nbsp;повторяемой. Microsoft &lltt;a href="https://en.wikipedia.org/wiki/Software_factory_(Microsoft_.NET)"&ggtt;заговорила&lltt;/a&ggtt; о&nbsp;фабриках&nbsp;ПО еще в&nbsp;2008&nbsp;г. Идея на&nbsp;некоторое время затихла, но&nbsp;теперь она вернулась, подпитываемая быстрым созданием программного кода, генерируемого и&nbsp;управляемого искусственным интеллектом.&lltt;/p&ggtt;
&lltt;p&ggtt;До&nbsp;недавнего времени, даже при наличии автоматизации и&nbsp;практик DevOps, «кодирование создавало узкие места для многих организаций,&nbsp;— говорит Мориц Плассниг, генеральный директор CloudBees. —&nbsp;Приходилось нанимать больше инженеров, но&nbsp;это было очень сложно и&nbsp;дорого».&lltt;/p&ggtt;
&lltt;h3&ggtt;Сегодняшняя фабрика&nbsp;ПО построена на&nbsp;моделях ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Благодаря возможностям кодирования базовых моделей&nbsp;ИИ и&nbsp;связанных с&nbsp;ними агентов, концепция фабрики&nbsp;ПО возродилась&nbsp;— и&nbsp;сегодня серьезно рассматривается автоматизация жизненного цикла разработки&nbsp;ПО на&nbsp;уровне повторяющихся этапов. С&nbsp;помощью агентного кодирования «мы&nbsp;меньше ограничены в&nbsp;части кодирования», отмечает Плассниг. Оно также может повысить роль ИТ-специалистов: «Мастерство разработчиков никуда не&nbsp;денется, поскольку разработчики и&nbsp;инженеры переходят от&nbsp;написания кода к&nbsp;принятию решений о&nbsp;том, что будет создано и&nbsp;выпущено».&lltt;/p&ggtt;
&lltt;p&ggtt;Современная концепция фабрики&nbsp;ПО построена на&nbsp;основе моделей&nbsp;ИИ, представленных на&nbsp;рынке,&nbsp;— и&nbsp;эта концепция практически одинакова для всех моделей. «За&nbsp;последние полтора года многие компании, находящиеся на&nbsp;переднем крае использования агентов для автоматизации жизненного цикла разработки&nbsp;ПО, создавали одну и&nbsp;ту&nbsp;же машину и&nbsp;независимо друг от&nbsp;друга приходили к&nbsp;одному и&nbsp;тому&nbsp;же выводу о&nbsp;том, как эта машина должна выглядеть»,&nbsp;— говорит Джеймин Уэст, инженер-разработчик и&nbsp;технологический евангелист.&lltt;/p&ggtt;
&lltt;p&ggtt;Среди компаний, создающих фабрики ПО,&nbsp;— такие светила современной агентной экономики, как Anthropic, Cognition, Cursor, Factory, Google, Github, OpenAI и&nbsp;Ramp. «Каждая из&nbsp;этих компаний пришла к&nbsp;одной и&nbsp;той&nbsp;же форме,&nbsp;— отмечает Уэст. —&nbsp;На&nbsp;данном этапе очень важно понимать, что это компании, находящиеся на&nbsp;передовой, и&nbsp;что формируется четкая закономерность в&nbsp;том, как они структурируют всю свою инженерную работу».&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;словам Пласснига, фабрика&nbsp;ПО служит способом быстрого воплощения идей: «Допустим, кто-то работает в&nbsp;службе поддержки клиентов, и&nbsp;у&nbsp;него возникает интересная идея, основанная на&nbsp;отзывах клиентов. Такой человек с&nbsp;идеей&nbsp;ПО может отправить ее&nbsp;на&nbsp;фабрику, где создается первая итерация. Далее специалисты по&nbsp;продуктам, инженеры и&nbsp;ИТ-специалисты изучают&nbsp;ее. Затем фабрика может снова взять ее&nbsp;и&nbsp;воплотить в&nbsp;жизнь. Это подобно тому, как в&nbsp;автоиндустрии появляется экспериментальный прототип, который потом передается на&nbsp;завод, который производит автомобили в&nbsp;больших масштабах».&lltt;/p&ggtt;
&lltt;p&ggtt;Фабрика ПО&nbsp;помогает решить проблему проверки и&nbsp;поддержки сотен тысяч строк кода, а&nbsp;также релизов, обновлений и&nbsp;модернизаций&nbsp;ПО, которые сегодня ежедневно происходят во&nbsp;многих организациях.&lltt;/p&ggtt;
&lltt;p&ggtt;«Вы&nbsp;хотите знать, действительно&nbsp;ли ПО&nbsp;работает, нет&nbsp;ли ошибок или хотя&nbsp;бы резкого роста частоты ошибок. Или, может быть, оно работает, но&nbsp;не&nbsp;превышает&nbsp;ли потребление памяти агентом желаемый уровень? Сегодня люди проверяют все эти оповещения, но&nbsp;если изменений будет в&nbsp;100 раз больше, например, каждые несколько минут, система сломается. Мы&nbsp;дойдём до&nbsp;того момента, когда люди больше не&nbsp;смогут проверять, что работает, а&nbsp;что нет»,&nbsp;— говорит Плассниг.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как выглядит фабрика ПО?&lltt;/h3&ggtt;
&lltt;p&ggtt;Уэст описывает типичную фабрику, поддерживаемую базовыми моделями, как состоящую из&nbsp;шести компонентов:&lltt;/p&ggtt;
&lltt;ol&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt; Очередь.&lltt;/strong&ggtt; «Работа поступает в&nbsp;виде проблемы, а&nbsp;не&nbsp;промпта».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Плоскость управления.&lltt;/strong&ggtt; «Надежный уровень, а&nbsp;не&nbsp;ноутбук».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Песочница.&lltt;/strong&ggtt; «Одна на&nbsp;задачу. Уничтожается после ее&nbsp;завершения».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Запрос на&nbsp;слияние.&lltt;/strong&ggtt; «Единица вывода. Его получает человек».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Поток событий.&lltt;/strong&ggtt; «Отслеживает каждое действие. Прерывает его, не&nbsp;нарушая выполнение».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Надежная память.&lltt;/strong&ggtt; «Песочница выполняет каждый запуск. То, что не&nbsp;записано в&nbsp;файл, не&nbsp;сохраняется».&lltt;/li&ggtt;
&lltt;/ol&ggtt;
&lltt;p&ggtt;Конечно, фабрики&nbsp;ПО, какими&nbsp;бы эффективными они ни&nbsp;были, не&nbsp;являются панацеей для внедрения передовых методов разработки ПО.&lltt;/p&ggtt;
&lltt;p&ggtt;«Сейчас уже не&nbsp;секрет, что генерация кода стала невероятно простой,&nbsp;— говорит Уэст. —&nbsp;Она теперь невероятно дешева. Но&nbsp;препятствием для многих компаний стала верификация. Убедиться, что агенты пишут код, очень легко. Но&nbsp;убедиться в&nbsp;правильности этого кода по-прежнему остается серьезной инженерной проблемой. И&nbsp;важно понимать, что создание фабрики&nbsp;ПО не&nbsp;означает, что вы&nbsp;просто отказываетесь от&nbsp;верификации или снижаете качество своей кодовой базы».&lltt;/p&ggtt;]]></source>
<adate>18.08.2026</adate>
<dbid>235361</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[ИИ как инструмент атаки: чем грозят новые технологии в руках хакеров]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235359]]></link>
<description><![CDATA[За четыре года число поисковых запросов вокруг темы «ИИ как угроза» выросло примерно в 30 раз и к 2026-му, по данным исследования Андрея Цая, вышло на первое место — обогнав даже запросы о защите самих ИИ-систем. Рассмотрим, насколько реальна эта угроза и что необходимо предпринять компаниям, чтобы ее отразить. ИИ как орудие злоумышленников На фоне развития искусственного интеллекта все чаще звучат разговоры о том, что ИИ может превратиться в инструмент злоумышленников. Однако слово «может» здесь уже не вполне уместно: ИИ становится рабочим инструментом в offensive security и способен выполнять часть задач, которые раньше требовали значительного объема ручной работы. Показателен пример XBOW — автономной системы для поиска и эксплуатации уязвимостей. В 2025 году XBOW поднялась на первое место американского рейтинга HackerOne, а позднее заняла первое место и в глобальном рейтинге платформы. При этом речь шла не о лабораторном тесте: система работала в реальных bug bounty-программах и отправляла отчеты об обнаруженных уязвимостях. Сам HackerOne отмечал выход XBOW на первое место американского рейтинга как пример того, что ИИ-системы уже способны эффективно находить определенные классы уязвимостей. Это не означает, что ИИ полностью заменил исследователя: например, команда XBOW проверяла отчеты перед отправкой в соответствии с правилами HackerOne. Но сам кейс хорошо показывает изменение масштаба и скорости работы: значительную часть поиска, проверки гипотез и валидации находок уже можно автоматизировать. Причина очевидна: ИИ хорошо справляется с интеллектуальной рутиной. Он может быстро обрабатывать большие объемы информации, находить закономерности, классифицировать данные и выполнять последовательности однотипных операций. И атака в этом смысле во многом похожа на другие сложные рабочие процессы. Значительная часть времени злоумышленника уходит на подготовку: сбор информации о цели, анализ инфраструктуры и технологий, поиск потенциально интересных объектов и проверку различных гипотез. Если часть этой работы передать ИИ, меняется сама экономика атаки: разведка, анализ и перебор вариантов становятся быстрее и дешевле, а один злоумышленник может выполнять объем работы, для которого раньше требовалось значительно больше времени. Необходимо также понимать, что скорость внедрения новых технологий у злоумышленников зачастую выше, чем в крупных организациях. Пока компания оценивает риски, согласовывает бюджет, выбирает модели и выстраивает процессы безопасного использования ИИ, атакующему достаточно получить доступ к публичному сервису или модели. Возникает асимметрия: стоимость автоматизации отдельных этапов атаки быстро снижается, тогда как стоимость полноценной защиты компании — нет. Поэтому основная угроза ИИ сегодня заключается не столько в появлении автономного «ИИ-хакера», сколько в росте производительности обычного злоумышленника. Проще атака — больше желающих Еще одна проблема заключается в том, что ИИ постепенно снижает порог входа в отдельные этапы кибератак. Часть задач, для которых раньше требовались специальные знания, теперь можно выполнять с помощью языковых моделей: собирать и анализировать информацию о цели, быстрее разбираться в незнакомых технологиях, модифицировать скрипты, готовить фишинговые сообщения или анализировать найденный код. Это не превращает человека без технических знаний в профессионального хакера, но сокращает разрыв между отсутствием компетенций и возможностью выполнить отдельные элементы атаки. Одновременно с этим появляются и новые классы атак на сами ИИ-приложения. Один из примеров — prompt injection (инъекция промптов), при которой злоумышленник через специально сформированные инструкции пытается изменить ожидаемое поведение системы. Например, если на корпоративном ресурсе работает интеллектуальный поиск или ИИ-агент, атакующий может попытаться заставить его проигнорировать исходные инструкции, обратиться к данным, которые не должны быть доступны пользователю, или выполнить нежелательное действие. Отдельно существуют jailbreak-техники, направленные на обход ограничений самой модели. Для экспериментов с такими атаками в ряде случаев действительно не требуется сложная инфраструктура: взаимодействие происходит через тот же интерфейс, которым пользуется обычный пользователь. Одновременно ИИ выступает как инструмент автоматизации для самого злоумышленника. Если раньше для подготовки определенной атаки требовалось самостоятельно изучать множество технических вопросов, теперь часть этой работы можно переложить на языковую модель: быстрее разобраться в технологии, получить объяснение незнакомого кода, подготовить или адаптировать отдельные фрагменты скриптов, систематизировать результаты разведки. Ограничения публичных моделей снижают возможности их прямого использования во вредоносных целях, однако злоумышленники постоянно экспериментируют и с техниками обхода таких ограничений. Для обхода ограничений могут использоваться изменение контекста запроса, ролевые сценарии, декомпозиция задачи на несколько внешне безобидных этапов и другие техники. Вместо прямого запроса пользователь может представить задачу как исследование, киберучение или анализ защищенности либо разбить ее на последовательность отдельных вопросов. Эффективность таких приемов зависит от конкретной модели и реализованных механизмов защиты, но для атакующего важен сам принцип: ИИ позволяет значительно быстрее проводить эксперименты и проверять множество вариантов. Еще сильнее меняется скорость работы. Если раньше сбор и изучение контекста для определенной атаки могли занимать дни, то автоматизированная система способна существенно сократить этот этап. В результате отдельные стадии атаки становятся проще, дешевле и лучше масштабируются. Высвободившееся время злоумышленник может потратить на более сложные действия, которые пока хуже поддаются автоматизации. Для бизнеса это неприятная тенденция, поскольку стоимость атаки снижается, но стоимость полноценной защиты от нее автоматически не уменьшается. Компании по-прежнему должны поддерживать инфраструктуру безопасности, контролировать доступы, анализировать события и защищать данные. Shadow AI как источник риска внутри компании Однако усиление внешнего атакующего — только одна сторона проблемы. ИИ одновременно меняет поверхность атаки внутри самой компании: сотрудники подключают публичные модели, генераторы кода, агентов и другие инструменты быстрее, чем служба безопасности успевает их обнаруживать и оценивать. Так возникает другая категория риска — Shadow AI (теневой ИИ). Термин появился по аналогии с давно известным Shadow IT (теневые ИТ) — ситуацией, когда сотрудники самостоятельно используют для рабочих задач программное обеспечение и сервисы, которые компания официально не разрешила и не контролирует. Например, сотруднику нужен удобный инструмент для хранения файлов, совместной работы или обработки документов, и он самостоятельно регистрируется во внешнем сервисе. С точки зрения сотрудника он просто выбрал удобный инструмент, а с точки зрения службы безопасности внутри компании появился неконтролируемый канал обработки корпоративных данных. С Shadow AI происходит похожая история. В компании может не быть понятных правил использования ИИ — какие сервисы разрешены, какие данные можно туда отправлять, какую информацию категорически запрещено загружать, какие инструменты допустимы для разработки и анализа. В результате сотрудники начинают самостоятельно выбирать открытые ИИ-сервисы и использовать их для рабочих задач. Главные риски здесь связаны с утечками данных. Сотрудник может работать с корпоративного компьютера или ноутбука в публичном ИИ-сервисе и передавать туда информацию, которую нельзя выводить за пределы компании. Причем он сам часто даже не задумывается, что создает риски утечки. Для него это просто удобный способ решить рабочую задачу. Допустим, сотрудник отдела продаж берет папку с документами по клиентам за прошлый год и загружает ее в ИИ с просьбой сформировать отчет, прогноз или маркетинговое предложение. На первый взгляд задача выглядит безобидной и даже полезной: сотрудник хочет быстрее проанализировать информацию, чтобы повысить продажи. Но вместе с запросом за пределы корпоративного контура уходит клиентская база: контактные данные, сведения о продажах, цены, скидки и другая коммерческая информация. В результате могут компрометироваться и персональные данные, и коммерческая тайна, и внутренняя информация о работе с клиентами. Традиционные средства контроля утечек данных остаются необходимой частью защиты, но в случае с ИИ их возможностей может быть недостаточно. Компании важно понимать не только то, какие данные передаются за пределы корпоративного контура, но и в какой ИИ-сервис они уходят, разрешен ли этот сервис конкретному сотруднику, идет ли речь о загрузке файла, отправке промпта или обращении к модели через API. Поэтому классические механизмы защиты приходится дополнять обнаружением ИИ-сервисов и контролем специфичных для них сценариев использования. У Shadow AI есть и техническая сторона. Внутри разработки могут появляться генераторы кода, различные модели, агенты и другие инструменты, которые сотрудники самостоятельно подключают к рабочим процессам. Проблема заключается в том, что качество и безопасность таких инструментов часто под вопросом. Один сотрудник может использовать модель для генерации кода, другой — подключить сторонний инструмент для автоматизации, третий — развернуть собственный сервис. При этом количество подобных решений может расти настолько быстро, что служба безопасности просто не успевает их обнаруживать и оценивать. А защищать то, что СБ не видит, технически невозможно. Если компания не знает, какими ИИ-инструментами пользуются сотрудники, она не может полноценно оценить риски, определить, какие данные через них проходят, и подобрать соответствующие средства защиты. Поэтому сама по себе политика запрета не решает проблему. Более того, жесткий запрет может сделать ситуацию менее прозрачной. Если сотруднику официально запрещено пользоваться ИИ, но инструмент необходим ему для работы, он с высокой вероятностью начнет искать собственное решение. В итоге компания формально может считать, что никакого ИИ у нее нет, тогда как сотрудники будут его использовать с личных устройств. Выход здесь — в создании контролируемой корпоративной среды для работы с ИИ. Если сотрудникам действительно нужны языковые модели, агенты или другие ИИ-инструменты, компания должна предоставить разрешенные способы их использования: определить перечень допустимых сервисов и моделей, правила работы с данными, механизмы доступа, журналирования и контроля. Это необязательно означает полный отказ от внешних ИИ-сервисов — важно, чтобы компания понимала, какие инструменты используются, какие данные в них передаются и на каких условиях они обрабатываются. Такая среда должна быть не только безопасной, но и удобной. Иначе запрет снова будет проигрывать удобству публичных инструментов. Сотрудник выбирает не по критерию безопасности. Он ищет способ быстрее выполнить свою работу. И если корпоративная система оказывается слишком неудобной, поиск обходных путей практически неизбежен. #IMAGE_235360#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;За&nbsp;четыре года число поисковых запросов вокруг темы «ИИ&nbsp;как угроза» выросло примерно в&nbsp;30&nbsp;раз и&nbsp;к&nbsp;&lltt;nobr&ggtt;2026-му,&lltt;/nobr&ggtt; по&nbsp;данным исследования Андрея Цая, вышло на&nbsp;первое место&nbsp;— обогнав даже запросы о&nbsp;защите самих ИИ-систем. Рассмотрим, насколько реальна эта угроза и&nbsp;что необходимо предпринять компаниям, чтобы ее&nbsp;отразить.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ&nbsp;как орудие злоумышленников&lltt;/h3&ggtt;
&lltt;p&ggtt;На&nbsp;фоне развития искусственного интеллекта все чаще звучат разговоры о&nbsp;том, что&nbsp;ИИ может превратиться в&nbsp;инструмент злоумышленников. Однако слово «может» здесь уже не&nbsp;вполне уместно: ИИ&nbsp;становится рабочим инструментом в&nbsp;offensive security и&nbsp;способен выполнять часть задач, которые раньше требовали значительного объема ручной работы. Показателен пример XBOW&nbsp;— автономной системы для поиска и&nbsp;эксплуатации уязвимостей. В&nbsp;2025 году XBOW поднялась на&nbsp;первое место американского рейтинга HackerOne, а&nbsp;позднее заняла первое место и&nbsp;в&nbsp;глобальном рейтинге платформы. При этом речь шла не&nbsp;о&nbsp;лабораторном тесте: система работала в&nbsp;реальных bug bounty-программах и&nbsp;отправляла отчеты об&nbsp;обнаруженных уязвимостях. Сам HackerOne отмечал выход XBOW на&nbsp;первое место американского рейтинга как пример того, что ИИ-системы уже способны эффективно находить определенные классы уязвимостей. Это не&nbsp;означает, что&nbsp;ИИ полностью заменил исследователя: например, команда XBOW проверяла отчеты перед отправкой в&nbsp;соответствии с&nbsp;правилами HackerOne. Но&nbsp;сам кейс хорошо показывает изменение масштаба и&nbsp;скорости работы: значительную часть поиска, проверки гипотез и&nbsp;валидации находок уже можно автоматизировать.&lltt;/p&ggtt;
&lltt;p&ggtt;Причина очевидна: ИИ&nbsp;хорошо справляется с&nbsp;интеллектуальной рутиной. Он&nbsp;может быстро обрабатывать большие объемы информации, находить закономерности, классифицировать данные и&nbsp;выполнять последовательности однотипных операций. И&nbsp;атака в&nbsp;этом смысле во&nbsp;многом похожа на&nbsp;другие сложные рабочие процессы. Значительная часть времени злоумышленника уходит на&nbsp;подготовку: сбор информации о&nbsp;цели, анализ инфраструктуры и&nbsp;технологий, поиск потенциально интересных объектов и&nbsp;проверку различных гипотез. Если часть этой работы передать&nbsp;ИИ, меняется сама экономика атаки: разведка, анализ и&nbsp;перебор вариантов становятся быстрее и&nbsp;дешевле, а&nbsp;один злоумышленник может выполнять объем работы, для которого раньше требовалось значительно больше времени.&lltt;/p&ggtt;
&lltt;p&ggtt;Необходимо также понимать, что скорость внедрения новых технологий у&nbsp;злоумышленников зачастую выше, чем в&nbsp;крупных организациях. Пока компания оценивает риски, согласовывает бюджет, выбирает модели и&nbsp;выстраивает процессы безопасного использования&nbsp;ИИ, атакующему достаточно получить доступ к&nbsp;публичному сервису или модели. Возникает асимметрия: стоимость автоматизации отдельных этапов атаки быстро снижается, тогда как стоимость полноценной защиты компании&nbsp;— нет. Поэтому основная угроза&nbsp;ИИ сегодня заключается не&nbsp;столько в&nbsp;появлении автономного «ИИ-хакера», сколько в&nbsp;росте производительности обычного злоумышленника.&lltt;/p&ggtt;
&lltt;h3&ggtt;Проще атака&nbsp;— больше желающих&lltt;/h3&ggtt;
&lltt;p&ggtt;Еще одна проблема заключается в&nbsp;том, что&nbsp;ИИ постепенно снижает порог входа в&nbsp;отдельные этапы кибератак. Часть задач, для которых раньше требовались специальные знания, теперь можно выполнять с&nbsp;помощью языковых моделей: собирать и&nbsp;анализировать информацию о&nbsp;цели, быстрее разбираться в&nbsp;незнакомых технологиях, модифицировать скрипты, готовить фишинговые сообщения или анализировать найденный код. Это не&nbsp;превращает человека без технических знаний в&nbsp;профессионального хакера, но&nbsp;сокращает разрыв между отсутствием компетенций и&nbsp;возможностью выполнить отдельные элементы атаки.&lltt;/p&ggtt;
&lltt;p&ggtt;Одновременно с&nbsp;этим появляются и&nbsp;новые классы атак на&nbsp;сами ИИ-приложения. Один из&nbsp;примеров&nbsp;— prompt injection (инъекция промптов), при которой злоумышленник через специально сформированные инструкции пытается изменить ожидаемое поведение системы. Например, если на&nbsp;корпоративном ресурсе работает интеллектуальный поиск или ИИ-агент, атакующий может попытаться заставить его проигнорировать исходные инструкции, обратиться к&nbsp;данным, которые не&nbsp;должны быть доступны пользователю, или выполнить нежелательное действие. Отдельно существуют jailbreak-техники, направленные на&nbsp;обход ограничений самой модели. Для экспериментов с&nbsp;такими атаками в&nbsp;ряде случаев действительно не&nbsp;требуется сложная инфраструктура: взаимодействие происходит через тот&nbsp;же интерфейс, которым пользуется обычный пользователь.&lltt;/p&ggtt;
&lltt;p&ggtt;Одновременно ИИ&nbsp;выступает как инструмент автоматизации для самого злоумышленника. Если раньше для подготовки определенной атаки требовалось самостоятельно изучать множество технических вопросов, теперь часть этой работы можно переложить на&nbsp;языковую модель: быстрее разобраться в&nbsp;технологии, получить объяснение незнакомого кода, подготовить или адаптировать отдельные фрагменты скриптов, систематизировать результаты разведки. Ограничения публичных моделей снижают возможности их&nbsp;прямого использования во&nbsp;вредоносных целях, однако злоумышленники постоянно экспериментируют и&nbsp;с&nbsp;техниками обхода таких ограничений.&lltt;/p&ggtt;
&lltt;p&ggtt;Для обхода ограничений могут использоваться изменение контекста запроса, ролевые сценарии, декомпозиция задачи на&nbsp;несколько внешне безобидных этапов и&nbsp;другие техники. Вместо прямого запроса пользователь может представить задачу как исследование, киберучение или анализ защищенности либо разбить ее&nbsp;на&nbsp;последовательность отдельных вопросов. Эффективность таких приемов зависит от&nbsp;конкретной модели и&nbsp;реализованных механизмов защиты, но&nbsp;для атакующего важен сам принцип: ИИ&nbsp;позволяет значительно быстрее проводить эксперименты и&nbsp;проверять множество вариантов.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще сильнее меняется скорость работы. Если раньше сбор и&nbsp;изучение контекста для определенной атаки могли занимать дни, то&nbsp;автоматизированная система способна существенно сократить этот этап. В&nbsp;результате отдельные стадии атаки становятся проще, дешевле и&nbsp;лучше масштабируются. Высвободившееся время злоумышленник может потратить на&nbsp;более сложные действия, которые пока хуже поддаются автоматизации.&lltt;/p&ggtt;
&lltt;p&ggtt;Для бизнеса это неприятная тенденция, поскольку стоимость атаки снижается, но&nbsp;стоимость полноценной защиты от&nbsp;нее автоматически не&nbsp;уменьшается. Компании по-прежнему должны поддерживать инфраструктуру безопасности, контролировать доступы, анализировать события и&nbsp;защищать данные.&lltt;/p&ggtt;
&lltt;h3&ggtt;Shadow AI&nbsp;как источник риска внутри компании&lltt;/h3&ggtt;
&lltt;p&ggtt;Однако усиление внешнего атакующего&nbsp;— только одна сторона проблемы. ИИ&nbsp;одновременно меняет поверхность атаки внутри самой компании: сотрудники подключают публичные модели, генераторы кода, агентов и&nbsp;другие инструменты быстрее, чем служба безопасности успевает их&nbsp;обнаруживать и&nbsp;оценивать. Так возникает другая категория риска&nbsp;— Shadow&nbsp;AI (теневой ИИ).&lltt;/p&ggtt;
&lltt;p&ggtt;Термин появился по&nbsp;аналогии с&nbsp;давно известным Shadow&nbsp;IT (теневые ИТ)&nbsp;— ситуацией, когда сотрудники самостоятельно используют для рабочих задач программное обеспечение и&nbsp;сервисы, которые компания официально не&nbsp;разрешила и&nbsp;не&nbsp;контролирует. Например, сотруднику нужен удобный инструмент для хранения файлов, совместной работы или обработки документов, и&nbsp;он&nbsp;самостоятельно регистрируется во&nbsp;внешнем сервисе. С&nbsp;точки зрения сотрудника он&nbsp;просто выбрал удобный инструмент, а&nbsp;с&nbsp;точки зрения службы безопасности внутри компании появился неконтролируемый канал обработки корпоративных данных.&lltt;/p&ggtt;
&lltt;p&ggtt;С&nbsp;Shadow AI&nbsp;происходит похожая история. В&nbsp;компании может не&nbsp;быть понятных правил использования ИИ&nbsp;— какие сервисы разрешены, какие данные можно туда отправлять, какую информацию категорически запрещено загружать, какие инструменты допустимы для разработки и&nbsp;анализа. В&nbsp;результате сотрудники начинают самостоятельно выбирать открытые ИИ-сервисы и&nbsp;использовать их&nbsp;для рабочих задач.&lltt;/p&ggtt;
&lltt;p&ggtt;Главные риски здесь связаны с&nbsp;утечками данных. Сотрудник может работать с&nbsp;корпоративного компьютера или ноутбука в&nbsp;публичном ИИ-сервисе и&nbsp;передавать туда информацию, которую нельзя выводить за&nbsp;пределы компании. Причем он&nbsp;сам часто даже не&nbsp;задумывается, что создает риски утечки. Для него это просто удобный способ решить рабочую задачу.&lltt;/p&ggtt;
&lltt;p&ggtt;Допустим, сотрудник отдела продаж берет папку с&nbsp;документами по&nbsp;клиентам за&nbsp;прошлый год и&nbsp;загружает ее&nbsp;в&nbsp;ИИ с&nbsp;просьбой сформировать отчет, прогноз или маркетинговое предложение. На&nbsp;первый взгляд задача выглядит безобидной и&nbsp;даже полезной: сотрудник хочет быстрее проанализировать информацию, чтобы повысить продажи. Но&nbsp;вместе с&nbsp;запросом за&nbsp;пределы корпоративного контура уходит клиентская база: контактные данные, сведения о&nbsp;продажах, цены, скидки и&nbsp;другая коммерческая информация. В&nbsp;результате могут компрометироваться и&nbsp;персональные данные, и&nbsp;коммерческая тайна, и&nbsp;внутренняя информация о&nbsp;работе с&nbsp;клиентами.&lltt;/p&ggtt;
&lltt;p&ggtt;Традиционные средства контроля утечек данных остаются необходимой частью защиты, но&nbsp;в&nbsp;случае с&nbsp;ИИ их&nbsp;возможностей может быть недостаточно. Компании важно понимать не&nbsp;только&nbsp;то, какие данные передаются за&nbsp;пределы корпоративного контура, но&nbsp;и&nbsp;в&nbsp;какой ИИ-сервис они уходят, разрешен&nbsp;ли этот сервис конкретному сотруднику, идет&nbsp;ли речь о&nbsp;загрузке файла, отправке промпта или обращении к&nbsp;модели через API. Поэтому классические механизмы защиты приходится дополнять обнаружением ИИ-сервисов и&nbsp;контролем специфичных для них сценариев использования.&lltt;/p&ggtt;
&lltt;p&ggtt;У&nbsp;Shadow AI&nbsp;есть и&nbsp;техническая сторона. Внутри разработки могут появляться генераторы кода, различные модели, агенты и&nbsp;другие инструменты, которые сотрудники самостоятельно подключают к&nbsp;рабочим процессам. Проблема заключается в&nbsp;том, что качество и&nbsp;безопасность таких инструментов часто под вопросом. Один сотрудник может использовать модель для генерации кода, другой&nbsp;— подключить сторонний инструмент для автоматизации, третий&nbsp;— развернуть собственный сервис. При этом количество подобных решений может расти настолько быстро, что служба безопасности просто не&nbsp;успевает их&nbsp;обнаруживать и&nbsp;оценивать. А&nbsp;защищать&nbsp;то, что&nbsp;СБ не&nbsp;видит, технически невозможно. Если компания не&nbsp;знает, какими ИИ-инструментами пользуются сотрудники, она не&nbsp;может полноценно оценить риски, определить, какие данные через них проходят, и&nbsp;подобрать соответствующие средства защиты.&lltt;/p&ggtt;
&lltt;p&ggtt;Поэтому сама по&nbsp;себе политика запрета не&nbsp;решает проблему. Более того, жесткий запрет может сделать ситуацию менее прозрачной. Если сотруднику официально запрещено пользоваться&nbsp;ИИ, но&nbsp;инструмент необходим ему для работы, он&nbsp;с&nbsp;высокой вероятностью начнет искать собственное решение. В&nbsp;итоге компания формально может считать, что никакого&nbsp;ИИ у&nbsp;нее нет, тогда как сотрудники будут его использовать с&nbsp;личных устройств.&lltt;/p&ggtt;
&lltt;p&ggtt;Выход здесь&nbsp;— в&nbsp;создании контролируемой корпоративной среды для работы с&nbsp;ИИ. Если сотрудникам действительно нужны языковые модели, агенты или другие ИИ-инструменты, компания должна предоставить разрешенные способы их&nbsp;использования: определить перечень допустимых сервисов и&nbsp;моделей, правила работы с&nbsp;данными, механизмы доступа, журналирования и&nbsp;контроля. Это необязательно означает полный отказ от&nbsp;внешних ИИ-сервисов&nbsp;— важно, чтобы компания понимала, какие инструменты используются, какие данные в&nbsp;них передаются и&nbsp;на&nbsp;каких условиях они обрабатываются.&lltt;/p&ggtt;
&lltt;p&ggtt;Такая среда должна быть не&nbsp;только безопасной, но&nbsp;и&nbsp;удобной. Иначе запрет снова будет проигрывать удобству публичных инструментов. Сотрудник выбирает не&nbsp;по&nbsp;критерию безопасности. Он&nbsp;ищет способ быстрее выполнить свою работу. И&nbsp;если корпоративная система оказывается слишком неудобной, поиск обходных путей практически неизбежен.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235360#&lltt;/p&ggtt;]]></source>
<adate>18.08.2026</adate>
<dbid>235359</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/14b/24iwhyepw9x9ufu31xcle0feseapomzm.jpg]]>
</images>
<imagesname><![CDATA[;;Светлана Газизова, владелец продукта по безопасности ИИ компании UserGate   ]]></imagesname>
<tag><![CDATA[Безопасность;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[SENSE: медианная зарплата senior-специалистов в ИТ вернулась к уровню 2023 года]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235358]]></link>
<description><![CDATA[Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более 43 тыс. человек по 36 ролям и выяснила, что медианная зарплата специалистов уровня Senior в I квартале 2026 года вернулась к показателю трёхлетней давности. За полгода она снизилась на 17%, с 360 тыс. до 300 тыс. рублей после вычета налогов. Исследование охватывает семь замеров с I квартала 2023 года по I квартал 2026-го. За это время российский ИТ-рынок прошёл полный цикл: от последовательного роста зарплат до их заметного снижения после пика III квартала 2025 года. Изменения затронули все грейды, за полгода медианная зарплата специалистов уровня Middle снизилась на 8%, с 250 тыс. до 230 тыс. рублей после вычета налогов. У Senior она сократилась на 17%, с 360 тыс. до 300 тыс. рублей, а у Lead — на 12%, с 450 тыс. до 395 тыс. рублей. При этом зарплаты Middle и Lead всё ещё немного превышают показатели начала 2023 года, тогда как медиана Senior полностью вернулась к уровню трехлетней давности. «Совпадение зарплатных показателей с уровнем 2023 года не означает, что рынок вернулся в прежнее состояние. За одинаковыми цифрами скрывается другая логика найма. Если раньше работодатели конкурировали за специалистов и расширяли зарплатные вилки, то теперь они точнее оценивают прикладную ценность каждой роли. Спрос сохраняется, но становится более избирательным: лучше всего удерживают позиции специалисты, чьи компетенции связаны с устойчивостью инфраструктуры, безопасностью и решением конкретных задач бизнеса. В этих условиях компаниям важно не только точнее нанимать специалистов, но и эффективнее развивать уже сформированные команды. Поэтому переход от HR Tech к People Tech, то есть от автоматизации отдельных HR-функций к управлению всем профессиональным путём сотрудника, становится одной из ключевых тем отраслевой дискуссии. Этот вопрос активно обсуждается в профессиональном сообществе, в том числе на конференциях для HR- и ИТ-лидеров. Бизнес стремится объединить подбор, адаптацию, обучение и оценку эффективности в единую систему, ориентированную на реальные задачи компании», — комментирует Иван Котковский, управляющий партнёр кадрового системного интегратора SENSE, сооснователь и член программного комитета ежегодного кэмпа PEOPLE TECH для HRD, CPO / CTO HR. Наиболее заметно снизились зарплаты в направлениях, которые активнее всего росли в 2024–2025 годах. Одним из таких направлений стало Data &#38; ML. Самую сильную коррекцию за полгода показали специалисты Data Quality уровня Lead: их медианная зарплата сократилась на 30%, с 400 тыс. до 280 тыс. рублей. Data Scientist Lead за тот же период потеряли 115 тыс. рублей, а Senior — 85 тыс. рублей. В то же время прикладные и инфраструктурные роли внутри Data &#38; ML оказались устойчивее: медианная зарплата DBA Middle снизилась только на 3%, а ML Middle — на 7%. По мнению аналитиков SENSE, рынок стал строже оценивать не само владение ИИ-инструментами, а способность специалистов решать с их помощью конкретные задачи бизнеса. Заметный откат произошёл и в классическом backend. За полгода медианная зарплата Python Senior снизилась на 28%, с 360 тыс. до 260 тыс. рублей, а C#.Net Senior — на 26%, с 380 тыс. до 280 тыс. рублей. Зарплата Java Middle к I кварталу 2026 года вернулась к отметке 250 тыс. рублей, зафиксированной в начале 2023-го. На динамику направления повлияли замедление найма и пересмотр ИТ-бюджетов в финансовом секторе, который долгое время оставался одним из основных заказчиков специалистов этого профиля. Существенную переоценку пережила и мобильная разработка. От собственных пиков III квартала 2024 года до I квартала 2026-го медианные зарплаты iOS-разработчиков снизились на 19–37% в зависимости от грейда, Android-разработчиков — на 19–31%. Сильнее всего коррекция затронула специалистов уровня Middle. Наиболее устойчивыми оказались направления, спрос на которые связан с долгосрочными задачами бизнеса. После пика зарплаты архитекторов информационной безопасности снизились не более чем на 1%, а медианы DevSecOps сохранились на прежнем уровне. В направлении 1С зарплаты по четырём из шести исследованных ролей не изменились по сравнению с III кварталом 2025 года. Относительно небольшую коррекцию также показали Frontend, DevOps и SRE. При этом в период роста отдельные роли показали особенно заметную динамику. От начала наблюдений до своих максимальных значений медианные зарплаты бизнес-аналитиков уровня Middle выросли на 67%, системных аналитиков Middle — на 66%. Архитекторы информационной безопасности уровня Middle прибавили 50%, DBA Lead — 46%, а DBA Senior — 43%. Это показывает, что общая коррекция не отменила структурный спрос на отдельные компетенции, хотя после пика III квартала 2025 года динамика стала разнонаправленной]]></description>
<source><![CDATA[&lltt;p&ggtt;Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более 43 тыс. человек по 36 ролям и выяснила, что медианная зарплата специалистов уровня Senior в I квартале 2026 года вернулась к показателю трёхлетней давности. За полгода она снизилась на 17%, с 360 тыс. до 300 тыс. рублей после вычета налогов. &lltt;/p&ggtt;
&lltt;p&ggtt;Исследование охватывает семь замеров с I квартала 2023 года по I квартал &lltt;nobr&ggtt;2026-го.&lltt;/nobr&ggtt; За это время российский ИТ-рынок прошёл полный цикл: от последовательного роста зарплат до их заметного снижения после пика III квартала 2025 года.&lltt;/p&ggtt;
&lltt;p&ggtt;Изменения затронули все грейды, за полгода медианная зарплата специалистов уровня Middle снизилась на 8%, с 250 тыс. до 230 тыс. рублей после вычета налогов. У Senior она сократилась на 17%, с 360 тыс. до 300 тыс. рублей, а у Lead — на 12%, с 450 тыс. до 395 тыс. рублей. При этом зарплаты Middle и Lead всё ещё немного превышают показатели начала 2023 года, тогда как медиана Senior полностью вернулась к уровню трехлетней давности.&lltt;/p&ggtt;
&lltt;p&ggtt;«Совпадение зарплатных показателей с уровнем 2023 года не означает, что рынок вернулся в прежнее состояние. За одинаковыми цифрами скрывается другая логика найма. Если раньше работодатели конкурировали за специалистов и расширяли зарплатные вилки, то теперь они точнее оценивают прикладную ценность каждой роли. Спрос сохраняется, но становится более избирательным: лучше всего удерживают позиции специалисты, чьи компетенции связаны с устойчивостью инфраструктуры, безопасностью и решением конкретных задач бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;В этих условиях компаниям важно не только точнее нанимать специалистов, но и эффективнее развивать уже сформированные команды. Поэтому переход от HR Tech к People Tech, то есть от автоматизации отдельных HR-функций к управлению всем профессиональным путём сотрудника, становится одной из ключевых тем отраслевой дискуссии. Этот вопрос активно обсуждается в профессиональном сообществе, в том числе на конференциях для HR- и ИТ-лидеров. Бизнес стремится объединить подбор, адаптацию, обучение и оценку эффективности в единую систему, ориентированную на реальные задачи компании», — комментирует Иван Котковский, управляющий партнёр кадрового системного интегратора SENSE, сооснователь и член программного комитета ежегодного кэмпа PEOPLE TECH для HRD, CPO / CTO HR.&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее заметно снизились зарплаты в направлениях, которые активнее всего росли в &lltt;nobr&ggtt;2024–2025 годах.&lltt;/nobr&ggtt; Одним из таких направлений стало Data & ML. Самую сильную коррекцию за полгода показали специалисты Data Quality уровня Lead: их медианная зарплата сократилась на 30%, с 400 тыс. до 280 тыс. рублей. Data Scientist Lead за тот же период потеряли 115 тыс. рублей, а Senior — 85 тыс. рублей.&lltt;/p&ggtt;
&lltt;p&ggtt;В то же время прикладные и инфраструктурные роли внутри Data & ML оказались устойчивее: медианная зарплата DBA Middle снизилась только на 3%, а ML Middle — на 7%. По мнению аналитиков SENSE, рынок стал строже оценивать не само владение ИИ-инструментами, а способность специалистов решать с их помощью конкретные задачи бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;Заметный откат произошёл и в классическом backend. За полгода медианная зарплата Python Senior снизилась на 28%, с 360 тыс. до 260 тыс. рублей, а C#.Net Senior — на 26%, с 380 тыс. до 280 тыс. рублей. Зарплата Java Middle к I кварталу 2026 года вернулась к отметке 250 тыс. рублей, зафиксированной в начале &lltt;nobr&ggtt;2023-го.&lltt;/nobr&ggtt; На динамику направления повлияли замедление найма и пересмотр ИТ-бюджетов в финансовом секторе, который долгое время оставался одним из основных заказчиков специалистов этого профиля.&lltt;/p&ggtt;
&lltt;p&ggtt;Существенную переоценку пережила и мобильная разработка. От собственных пиков III квартала 2024 года до I квартала &lltt;nobr&ggtt;2026-го&lltt;/nobr&ggtt; медианные зарплаты iOS-разработчиков снизились на &lltt;nobr&ggtt;19–37%&lltt;/nobr&ggtt; в зависимости от грейда, Android-разработчиков — на &lltt;nobr&ggtt;19–31%.&lltt;/nobr&ggtt; Сильнее всего коррекция затронула специалистов уровня Middle.&lltt;/p&ggtt;
&lltt;p&ggtt;Наиболее устойчивыми оказались направления, спрос на которые связан с долгосрочными задачами бизнеса. После пика зарплаты архитекторов информационной безопасности снизились не более чем на 1%, а медианы DevSecOps сохранились на прежнем уровне. В направлении 1С зарплаты по четырём из шести исследованных ролей не изменились по сравнению с III кварталом 2025 года. Относительно небольшую коррекцию также показали Frontend, DevOps и SRE.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом в период роста отдельные роли показали особенно заметную динамику. От начала наблюдений до своих максимальных значений медианные зарплаты бизнес-аналитиков уровня Middle выросли на 67%, системных аналитиков Middle — на 66%. Архитекторы информационной безопасности уровня Middle прибавили 50%, DBA Lead — 46%, а DBA Senior — 43%. Это показывает, что общая коррекция не отменила структурный спрос на отдельные компетенции, хотя после пика III квартала 2025 года динамика стала разнонаправленной.&lltt;/p&ggtt;]]></source>
<adate>17.08.2026</adate>
<dbid>235358</dbid>
<rubric>8</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Postgres Professional усилила платформу миграции ProGate 1.4.0 аналитической СУБД Postgres Pro AXE]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235355]]></link>
<description><![CDATA[Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — очередного обновления платформы миграции и репликации данных. Ключевое новшество версии — поддержка аналитической СУБД для гибридных нагрузок Postgres Pro AXE с загрузкой в S3-совместимое хранилище, что открывает заказчикам новые сценарии для построения аналитических хранилищ. Также в релиз вошла функциональность по повышению производительности утилит, укреплению безопасности и переработке механизма интроспекции схем данных. Postgres ProGate предназначена для проектов миграции, разового переноса данных и непрерывной репликацей между СУБД. Продукт помогает автоматизировать ключевые этапы работы с данными: первичную загрузку, синхронизацию изменений в режиме, близком к реальному времени, и проверку корректности переноса. Главное новшество версии — поддержка аналитической СУБД AXE в качестве приёмника данных с возможностью загрузки в S3-совместимое хранилище. Это расширяет сценарии использования платформы для построения современных аналитических хранилищ и data lake-решений на базе экосистемы Postgres Professional. Также одним из наиболее стала полная переработка механизма интроспекции. Реализована асинхронная обработка, что заметно ускоряет интроспекцию схем с большим количеством таблиц. Добавлена поддержка проверки привилегий доступа к схемам и таблицам, а также проверки совместимости подключений для prosync, включая права на чтение таблиц, — результаты доступны через API. Улучшено автоматическое сопоставление схем и таблиц для задач трансфера на основе совпадения имён. Утилита procopy получила более гибкий контроль над параллельной обработкой задач. Добавлен параметр sub_task_count, определяющий, на сколько подзадач может разбиваться исходная задача копирования, при этом расчёт размера подзадач теперь выполняется автоматически, а параметр sub_task_rows переведён в статус deprecated. Появился флаг force_restart_task, позволяющий перезапускать задачи без очистки данных и без изменения идентификатора задачи — это удобно для регулярных переносов данных, например, снапшотов T-1. Кроме того, в procopy и prosync добавлен параметр disable_constraint_checks, который отключает проверку ограничений и пользовательских триггеров на время записи батча в целевую PostgreSQL-совместимую БД, что ускоряет загрузку в сценариях, где целостность гарантируется на стороне источника или последующей верификацией. CDC-репликация стала стабильнее и быстрее. Добавлена опция single_loader, которая позволяет для конкретной таблицы принудительно использовать один загрузчик, обеспечивая последовательную обработку изменений для таблиц, связанных внешними ключами. Исправлена ошибка считывания записей с большими значениями SCN из онлайн-журналов Oracle. Устранено удержание WAL-файлов на источниках PostgreSQL при редких изменениях за счёт улучшения механизма продвижения слотов логической репликации. Повышена производительность применения изменений для Oracle. Добавлена фиксация блокировки учётной записи пользователя при превышении лимита неудачных попыток ввода пароля. Все компоненты системы переведены на Go 1.26.5, а Apache Thrift обновлён до версии v0.23.0 с устранением ранее обнаруженных уязвимостей. «Поддержка Postgres Pro AXE в качестве приёмника данных — это новый вектор развития продукта. Если раньше ProGate использовался преимущественно для миграции и репликации между операционными базами данных, то теперь платформа закрывает и сценарий поставки данных в аналитику с загрузкой в S3-совместимые хранилища. Это существенно расширяет область применения продукта и открывает нашим заказчикам возможность строить аналитические конвейеры на единой технологической платформе. В сочетании с переработанной интроспекцией, которая в разы ускоряет работу со схемами из сотен и тысяч таблиц, новыми опциями управления параллелизмом в procopy и усилением безопасности мы сделали серьёзный шаг в развитии платформы и дали нашим клиентам новые споособы решения своих бизнес-задач», — прокомментировал руководитель продукта Postgres ProGate Евгений Кривов]]></description>
<source><![CDATA[&lltt;p&ggtt;Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — очередного обновления платформы миграции и репликации данных. Ключевое новшество версии — поддержка аналитической СУБД для гибридных нагрузок Postgres Pro AXE с загрузкой в S3-совместимое хранилище, что открывает заказчикам новые сценарии для построения аналитических хранилищ. Также в релиз вошла функциональность по повышению производительности утилит, укреплению безопасности и переработке механизма интроспекции схем данных.&lltt;/p&ggtt;
&lltt;p&ggtt;Postgres ProGate предназначена для проектов миграции, разового переноса данных и непрерывной репликацей между СУБД. Продукт помогает автоматизировать ключевые этапы работы с данными: первичную загрузку, синхронизацию изменений в режиме, близком к реальному времени, и проверку корректности переноса.&lltt;/p&ggtt;
&lltt;p&ggtt;Главное новшество версии — поддержка аналитической СУБД AXE в качестве приёмника данных с возможностью загрузки в S3-совместимое хранилище. Это расширяет сценарии использования платформы для построения современных аналитических хранилищ и data lake-решений на базе экосистемы Postgres Professional.&lltt;/p&ggtt;
&lltt;p&ggtt;Также одним из наиболее стала полная переработка механизма интроспекции. Реализована асинхронная обработка, что заметно ускоряет интроспекцию схем с большим количеством таблиц. Добавлена поддержка проверки привилегий доступа к схемам и таблицам, а также проверки совместимости подключений для prosync, включая права на чтение таблиц, — результаты доступны через API. Улучшено автоматическое сопоставление схем и таблиц для задач трансфера на основе совпадения имён.&lltt;/p&ggtt;
&lltt;p&ggtt;Утилита procopy получила более гибкий контроль над параллельной обработкой задач. Добавлен параметр sub_task_count, определяющий, на сколько подзадач может разбиваться исходная задача копирования, при этом расчёт размера подзадач теперь выполняется автоматически, а параметр sub_task_rows переведён в статус deprecated. Появился флаг force_restart_task, позволяющий перезапускать задачи без очистки данных и без изменения идентификатора задачи — это удобно для регулярных переносов данных, например, снапшотов T-1.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме того, в procopy и prosync добавлен параметр disable_constraint_checks, который отключает проверку ограничений и пользовательских триггеров на время записи батча в целевую PostgreSQL-совместимую БД, что ускоряет загрузку в сценариях, где целостность гарантируется на стороне источника или последующей верификацией.&lltt;/p&ggtt;
&lltt;p&ggtt;&lltt;nobr&ggtt;CDC-репликация&lltt;/nobr&ggtt; стала стабильнее и быстрее. Добавлена опция single_loader, которая позволяет для конкретной таблицы принудительно использовать один загрузчик, обеспечивая последовательную обработку изменений для таблиц, связанных внешними ключами. Исправлена ошибка считывания записей с большими значениями SCN из онлайн-журналов Oracle. Устранено удержание WAL-файлов на источниках PostgreSQL при редких изменениях за счёт улучшения механизма продвижения слотов логической репликации. Повышена производительность применения изменений для Oracle.&lltt;/p&ggtt;
&lltt;p&ggtt;Добавлена фиксация блокировки учётной записи пользователя при превышении лимита неудачных попыток ввода пароля. Все компоненты системы переведены на Go 1.26.5, а Apache Thrift обновлён до версии v0.23.0 с устранением ранее обнаруженных уязвимостей.&lltt;/p&ggtt;
&lltt;p&ggtt;«Поддержка Postgres Pro AXE в качестве приёмника данных — это новый вектор развития продукта. Если раньше ProGate использовался преимущественно для миграции и репликации между операционными базами данных, то теперь платформа закрывает и сценарий поставки данных в аналитику с загрузкой в S3-совместимые хранилища. Это существенно расширяет область применения продукта и открывает нашим заказчикам возможность строить аналитические конвейеры на единой технологической платформе. В сочетании с переработанной интроспекцией, которая в разы ускоряет работу со схемами из сотен и тысяч таблиц, новыми опциями управления параллелизмом в procopy и усилением безопасности мы сделали серьёзный шаг в развитии платформы и дали нашим клиентам новые споособы решения своих бизнес-задач», — прокомментировал руководитель продукта Postgres ProGate Евгений Кривов.&lltt;/p&ggtt;]]></source>
<adate>17.08.2026</adate>
<dbid>235355</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[ИТ-менеджмент]]></tag>
</item>
<item>
<title><![CDATA[Data Lakehouse: что происходит на рынке озер-хранилищ данных]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235351]]></link>
<description><![CDATA[Корпоративные озера-хранилища данных (data lakehouse) эволюционируют. Изначально предназначенные в первую очередь для консолидации данных для аналитики, сегодня озера-хранилища данных стали операционной основой для агентного искусственного интеллекта, предоставляя надежные, управляемые и данные реального времени, необходимые интеллектуальным агентам для рассуждений и действий, пишет в корпоративном блоге Ноэль Юханна, вице-президент и главный аналитик Forrester. По мере того, как ИИ переходит от генерации инсайтов к выполнению бизнес-процессов, организациям необходимо переосмыслить ожидания от своей lakehouse-платформы. Эта эволюция переопределяет оценку поставщиков, приоритизируя готовность к ИИ, доверие, открытость и операционный интеллект, а не производительность хранения и запросов. Новые возможности lakehouse поддерживают сценарии использования агентного ИИ Чтобы помочь организациям справиться с этим сдвигом, в отчете «Forrester Wave: Data Lakehouses, Q3 2026» представлена оценка 14 ведущих поставщиков lakehouse. Она отражает меняющуюся роль озер-хранилищ в эпоху ИИ и определяет возможности, которые будут отличать платформы, способные поддерживать агентный ИИ корпоративного масштаба. Хотя традиционные возможности управления данными остаются важными, в отчете ясно показано, что готовые к будущему озера-хранилища должны также служить исполнительным уровнем для приложений, управляемых ИИ. Ключевые выводы из отчета заключаются в следующем: 	 Lakehouse становится исполнительным уровнем для агентного ИИ. Озеро-хранилище больше не ограничивается хранением и предоставлением данных для аналитики. Кроме этого оно должно постоянно предоставлять надежный, управляемый контекст реального времени, который агенты ИИ могут использовать для рассуждений, принятия решений и действий. Этот сдвиг коренным образом меняет подход организаций к оценке поставщиков. Вместо того чтобы отдавать приоритет только возможностям хранения, покупатели должны оценивать, насколько эффективно озеро-хранилище данных поддерживает ИИ-нативные рабочие нагрузки, операции в режиме реального времени и интеграцию с корпоративными экосистемами ИИ. 	 Доверие является основой готового к ИИ озера-хранилища данных. Поскольку агенты ИИ все чаще принимают автономные решения, недостатки в качестве, управлении, отслеживании происхождения или безопасности данных становятся рисками выполнения, а не аналитическими ограничениями. Организациям следует отдавать приоритет lakehouse-платформам, которые включают в себя управление данными, автоматическое отслеживание их происхождения, детальный контроль доступа, непрерывный мониторинг качества данных и обеспечение соблюдения политик в качестве основных возможностей платформы. 	 Открытые архитектуры имеют решающее значение для долгосрочного успеха ИИ. ИИ быстро развивается, требуя от организаций интеграции множества моделей, фреймворков оркестрации, облачных сред и сервисов данных. Озера-хранилища, построенные на основе открытых форматов таблиц, совместимых стандартов метаданных, расширяемых API и обмена данными без копирования, обеспечивают необходимую гибкость для адаптации, одновременно снижая зависимость от поставщика. При оценке поставщиков следует учитывать совместимость экосистем и архитектурную открытость как стратегические отличительные черты, а не как дополнительные функции. 	 Обеспечение использования ИИ является новым конкурентным преимуществом lakehouse-платформ. Хранение данных, масштабируемость и производительность запросов уже стали обязательными условиями. Сегодня отличительными чертами озер-хранилищ являются предоставление контекста реального времени, семантический интеллект, нативные векторные возможности и готовые к использованию ИИ сервисы данных, которые позволяют автономным агентам извлекать, анализировать и действовать на основе корпоративных данных. Организациям следует оценивать поставщиков на основе того, насколько эффективно их платформы поддерживают ИИ, поскольку эта возможность будет определять ценность для предприятий и конкурентное преимущество следующего поколения платформ данных. Apache Fluss — новое lakehouse-нативное потоковое хранилище Фонд Apache Software Foundation (ASF), глобальный центр разработки ПО с открытым исходным кодом, объявил о том, что Apache Fluss стал проектом верхнего уровня (TLP). Apache Fluss — это опенсорсная система потокового хранения для аналитики реального времени и ИИ. Она предоставляет уровень данных реального времени для lakehouse, объединяя потоковые данные, постоянно обновляемые таблицы и исторические данные lakehouse посредством общей абстракции таблиц. Fluss интегрируется с вычислительными движками, включая Apache Flink и Apache Spark, а также с открытыми lakehouse-форматами, включая Apache Paimon, Apache Iceberg, Apache Hudi и Lance. «Архитектура Lakestream от Fluss объединяет потоки данных с данными lakehouse, обеспечивая lakehouse возможности режима реального времени и одновременно сокращая дублирование данных и сложность конвейера обработки. Она доказала свою эффективность в масштабе основных производственных нагрузок электронной коммерции Alibaba, Это побудило нас открыть исходный код и передать Fluss в ASF. Я надеюсь, что Fluss станет открытой основой данных для озер-хранилищ реального времени и будет способствовать развитию аналитики и ИИ в открытой экосистеме данных», — сказал Фэн Ван, руководитель Open Data Platform в Alibaba Cloud]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Корпоративные озера-хранилища данных (&lltt;/em&ggtt;&lltt;em&ggtt;data&lltt;/em&ggtt; &lltt;em&ggtt;lakehouse&lltt;/em&ggtt;&lltt;em&ggtt;) эволюционируют. Изначально предназначенные в&nbsp;первую очередь для консолидации данных для аналитики, сегодня озера-хранилища данных стали операционной основой для агентного искусственного интеллекта, предоставляя надежные, управляемые и&nbsp;данные реального времени, необходимые интеллектуальным агентам для рассуждений и&nbsp;действий, пишет в&nbsp;корпоративном блоге Ноэль Юханна, вице-президент и&nbsp;главный аналитик &lltt;/em&ggtt;&lltt;em&ggtt;Forrester&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;мере того, как&nbsp;ИИ переходит от&nbsp;генерации инсайтов к&nbsp;выполнению бизнес-процессов, организациям необходимо переосмыслить ожидания от&nbsp;своей lakehouse-платформы. Эта эволюция переопределяет оценку поставщиков, приоритизируя готовность к&nbsp;ИИ, доверие, открытость и&nbsp;операционный интеллект, а&nbsp;не&nbsp;производительность хранения и&nbsp;запросов.&lltt;/p&ggtt;
&lltt;h3&ggtt;Новые возможности lakehouse поддерживают сценарии использования агентного ИИ&lltt;/h3&ggtt;
&lltt;p&ggtt;Чтобы помочь организациям справиться с&nbsp;этим сдвигом, в&nbsp;отчете «Forrester Wave: Data Lakehouses, Q3 2026» представлена оценка 14&nbsp;ведущих поставщиков lakehouse. Она отражает меняющуюся роль озер-хранилищ в&nbsp;эпоху&nbsp;ИИ и&nbsp;определяет возможности, которые будут отличать платформы, способные поддерживать агентный&nbsp;ИИ корпоративного масштаба. Хотя традиционные возможности управления данными остаются важными, в&nbsp;отчете ясно показано, что готовые к&nbsp;будущему озера-хранилища должны также служить исполнительным уровнем для приложений, управляемых ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Ключевые выводы из&nbsp;отчета заключаются в&nbsp;следующем:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; &lltt;strong&ggtt;Lakehouse&lltt;/strong&ggtt; &lltt;strong&ggtt;становится исполнительным уровнем для агентного ИИ.&lltt;/strong&ggtt; Озеро-хранилище больше не&nbsp;ограничивается хранением и&nbsp;предоставлением данных для аналитики. Кроме этого оно должно постоянно предоставлять надежный, управляемый контекст реального времени, который агенты&nbsp;ИИ могут использовать для рассуждений, принятия решений и&nbsp;действий. Этот сдвиг коренным образом меняет подход организаций к&nbsp;оценке поставщиков. Вместо того чтобы отдавать приоритет только возможностям хранения, покупатели должны оценивать, насколько эффективно озеро-хранилище данных поддерживает ИИ-нативные рабочие нагрузки, операции в&nbsp;режиме реального времени и&nbsp;интеграцию с&nbsp;корпоративными экосистемами ИИ.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Доверие является основой готового к&nbsp;ИИ озера-хранилища данных.&lltt;/strong&ggtt; Поскольку агенты&nbsp;ИИ все чаще принимают автономные решения, недостатки в&nbsp;качестве, управлении, отслеживании происхождения или безопасности данных становятся рисками выполнения, а&nbsp;не&nbsp;аналитическими ограничениями. Организациям следует отдавать приоритет lakehouse-платформам, которые включают в&nbsp;себя управление данными, автоматическое отслеживание их&nbsp;происхождения, детальный контроль доступа, непрерывный мониторинг качества данных и&nbsp;обеспечение соблюдения политик в&nbsp;качестве основных возможностей платформы.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Открытые архитектуры имеют решающее значение для долгосрочного успеха ИИ. &lltt;/strong&ggtt;ИИ&nbsp;быстро развивается, требуя от&nbsp;организаций интеграции множества моделей, фреймворков оркестрации, облачных сред и&nbsp;сервисов данных. Озера-хранилища, построенные на&nbsp;основе открытых форматов таблиц, совместимых стандартов метаданных, расширяемых API и&nbsp;обмена данными без копирования, обеспечивают необходимую гибкость для адаптации, одновременно снижая зависимость от&nbsp;поставщика. При оценке поставщиков следует учитывать совместимость экосистем и&nbsp;архитектурную открытость как стратегические отличительные черты, а&nbsp;не&nbsp;как дополнительные функции.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Обеспечение использования&nbsp;ИИ является новым конкурентным преимуществом &lltt;/strong&ggtt;&lltt;strong&ggtt;lakehouse&lltt;/strong&ggtt;&lltt;strong&ggtt;-платформ.&lltt;/strong&ggtt; Хранение данных, масштабируемость и&nbsp;производительность запросов уже стали обязательными условиями. Сегодня отличительными чертами озер-хранилищ являются предоставление контекста реального времени, семантический интеллект, нативные векторные возможности и&nbsp;готовые к&nbsp;использованию&nbsp;ИИ сервисы данных, которые позволяют автономным агентам извлекать, анализировать и&nbsp;действовать на&nbsp;основе корпоративных данных. Организациям следует оценивать поставщиков на&nbsp;основе того, насколько эффективно их&nbsp;платформы поддерживают&nbsp;ИИ, поскольку эта возможность будет определять ценность для предприятий и&nbsp;конкурентное преимущество следующего поколения платформ данных.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;h3&ggtt;Apache Fluss&nbsp;— новое lakehouse-нативное потоковое хранилище&lltt;/h3&ggtt;
&lltt;p&ggtt;Фонд Apache Software Foundation (ASF), глобальный центр разработки&nbsp;ПО с&nbsp;открытым исходным кодом, объявил о&nbsp;том, что Apache Fluss стал проектом верхнего уровня (TLP).&lltt;/p&ggtt;
&lltt;p&ggtt;Apache Fluss&nbsp;— это опенсорсная система потокового хранения для аналитики реального времени и&nbsp;ИИ. Она предоставляет уровень данных реального времени для lakehouse, объединяя потоковые данные, постоянно обновляемые таблицы и&nbsp;исторические данные lakehouse посредством общей абстракции таблиц. Fluss интегрируется с&nbsp;вычислительными движками, включая Apache Flink и&nbsp;Apache Spark, а&nbsp;также с&nbsp;открытыми lakehouse-форматами, включая Apache Paimon, Apache Iceberg, Apache Hudi и&nbsp;Lance.&lltt;/p&ggtt;
&lltt;p&ggtt;«Архитектура Lakestream от&nbsp;Fluss объединяет потоки данных с&nbsp;данными lakehouse, обеспечивая lakehouse возможности режима реального времени и&nbsp;одновременно сокращая дублирование данных и&nbsp;сложность конвейера обработки. Она доказала свою эффективность в&nbsp;масштабе основных производственных нагрузок электронной коммерции Alibaba, Это побудило нас открыть исходный код и&nbsp;передать Fluss в&nbsp;ASF. Я&nbsp;надеюсь, что Fluss станет открытой основой данных для озер-хранилищ реального времени и&nbsp;будет способствовать развитию аналитики и&nbsp;ИИ в&nbsp;открытой экосистеме данных»,&nbsp;— сказал Фэн Ван, руководитель Open Data Platform в&nbsp;Alibaba Cloud.&lltt;/p&ggtt;]]></source>
<adate>17.08.2026</adate>
<dbid>235351</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Big Data/Аналитика;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Атаки на основе ИИ-инференса оказывают новое давление на корпоративную конфиденциальность]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235352]]></link>
<description><![CDATA[Искусственный интеллект делает более быстрым и простым извлечение конфиденциальной личной информации из обычных бизнес-данных. Вице-президент Gartner Барт Виллемсен объясняет порталу InformationWeek, почему это происходит и что должны делать руководители служб информационной безопасности (CISO). Правила регулирования конфиденциальности данных, например европейский GDPR и американские федеральные законы, такие как HIPAA, больше не достаточны для защиты персональных данных в эпоху ИИ. Gartner прогнозирует, что к 2029 г. большинство инцидентов, связанных с нарушением конфиденциальности, будут вызваны ИИ-выводами об отдельных лицах, а не прямым раскрытием личной информации, такой как имена, адреса и номера социального страхования. По словам Виллемсена, способность ИИ быстро распознавать образы означает, что злоумышленникам больше не нужно красть или покупать учетные данные, чтобы получить конфиденциальную информацию о людях. Анонимизация данных сама по себе не обеспечивает достаточной защиты, поскольку алгоритмы ИИ могут повторно идентифицировать людей или выводить конфиденциальные атрибуты из анонимизированных наборов данных. «Настоящей анонимизации не существует, за исключением фактического удаления данных. Атака на основе инференса очень эффективна, потому что она затрагивает всё, а не только непосредственно идентифицируемые репозитории», — говорит Виллемсен. По мере совершенствования генеративного ИИ и машинного обучения эти технологии могут выводить конфиденциальные личные характеристики — такие как состояние здоровья или поведенческие модели — из анонимизированных или агрегированных данных. «Современные модели могут восстанавливать личные данные, используя поведенческие модели, показатели использования и агрегированные записи транзакций. Например, ИИ может идентифицировать людей по данным о поездках, социальным сетям, рентгеновским снимкам, ЭКГ, МРТ, даже походке или практически любой комбинации из примерно трёх транзакций», — объясняет Виллемсен. Кроме того, по его словам, когда ИИ галлюцинирует или создает синтетические данные о людях, эти неверные данные могут вызывать реальные проблемы. Например, предвзятость и галлюцинации ИИ могут привести к неправомерному тюремному заключению и серьезным ошибкам в юридических исследованиях. Последствия выходят далеко за рамки нарушений конфиденциальности, считает Эндрю Обадиару, CISO компании Cobalt. «ИИ может определить состояние здоровья человека, его финансовое положение, влияние внутри организации или вероятность ответа на фишинговое письмо, не имея доступа к медицинской карте или кадровому делу», — говорит он. По его словам, данные, которые не кажутся конфиденциальными — такие как справочники сотрудников, отношения с поставщиками, активность в социальных сетях или взаимодействие с клиентами — могут стать ценными, когда ИИ связывает эти фрагменты. ИИ может использовать их для определения структуры подчиненности, администрирования систем, взаимоотношений между руководителями, полномочий по расходам или того, какой инженер отвечает за критически важную производственную систему. Затем злоумышленники могут использовать эти данные, чтобы сделать свои атаки гораздо более точными. «В результате фишинговые кампании становятся значительно более убедительными, компрометация корпоративной электронной почты происходит быстрее, вымогательство — более целенаправленным, а операции по вторжению — гораздо эффективнее, поскольку злоумышленник уже знает, кого атаковать, прежде чем отправить первое письмо», — поясняет Обадиару. Организациям необходимо начать задумываться не только о том, какие данные они собирают, но и о том, «что эти данные раскрывают, когда они объединяются, сопоставляются и интерпретируются все более совершенными системами ИИ», — добавляет он. И, из-за развития технологий ИИ, правила обеспечения конфиденциальности, которые исторически были сосредоточены на непосредственно идентифицируемых данных, должны также распространяться на косвенно или повторно идентифицируемый контент. «Сочетание данных, зарегистрированных где угодно, доступа к ним по всему миру (случайно или в результате злонамеренного взлома) и возможностей, доступных любому, кто хочет получить доступ к данным с помощью современных аналитических и генеративных ИИ-технологий, — вот что отличает сегодняшнюю ситуацию. Кроме того, организации практически не очищают данные, которые им больше не нужны», — говорит Виллемсен. По его словам, риск повторной идентификации данных существовал задолго до сегодняшнего бума ИИ, но ИИ значительно ускоряет этот процесс. Он ссылается на исследование 2019 г., проведенное специалистами в области науки о данных Люком Роше, Жюльеном М. Хендрикксом и Ивом-Александром де Монжуа, которые разработали генеративную графическую модель для повторной идентификации людей. «Используя нашу модель, мы обнаружили, что 99,98% американцев будут правильно идентифицированы в любом наборе данных с использованием 15 демографических атрибутов», — написали они. ИИ усиливает угрозу повторной идентификации По словам Обадиару, что изменилось с развитием ИИ, так это то, что теперь «скорость на стороне злоумышленников — и масштаб». «Пять лет назад создание подробных профилей тысяч потенциальных жертв было экономически нецелесообразным. Сегодня это не так», — отмечает он. Виллемсен обращает внимание на исследование 2026 г., проведенное инженерами Саймоном Лерменом, Даниэлем Палекой, Джошуа Свансоном, Майклом Аэрни, Николасом Карлини и Флорианом Трамером. Авторы обнаружили, что больше языковые модели (LLM) могут повторно идентифицировать людей, «используя только псевдонимизированные онлайн-профили и переписки, что сопоставимо с тем, что может выполнить опытный следователь за много часов работы». Примечательно пояснение авторов: «В каждой ситуации методы на основе LLM значительно превосходят классические базовые методы, достигая до 68% полноты при 90% точности по сравнению с почти 0% для лучшего метода без применения LLM. Наши результаты показывают, что практическая неопределенность, защищающая псевдонимных пользователей в Интернете, больше не действует и что модели угроз для конфиденциальности в Интернете необходимо пересмотреть». По словам Обадиару, лучшие атаки на основе инференса совсем не выглядят как атаки. «Злоумышленник может начать с LinkedIn, публичных документов, социальных сетей, украденных учетных данных, активности на GitHub и утечек маркетинговых баз данных. Ни один из этих наборов данных сам по себе не представляет особой ценности. Но ИИ выполняет сложную работу по их объединению», — отмечает он. По словам Виллемсена, чтобы снизить риски нарушения конфиденциальности, основанные на инференсе, CISO следует начать с обеспечения управления данными на протяжении всего их жизненного цикла и удаления данных, как только они перестанут приносить бизнес-ценность, которая оправдывала бы затраты и риски их защиты. «У данных есть жизненный цикл, и мы знаем, что хранить их вечно — это неразумно. Поэтому жестко запрограммируйте его конец», — советует он. Шаги по устранению основанных на инференсе рисков от Gartner По словам Виллемсена, для CISO защита от угроз, основанных на ИИ-инференсе, начинается с управления ИИ. Вот его советы: 	 Управление ИИ. Внедрите в разработку ИИ установление механизмов защиты конфиденциальности на этапе проектирования и регулярно оценивайте риски предвзятости или инференса. 	 Внедрение технологий повышения конфиденциальности (PET). PET — это «набор технологических инструментов», — говорит Виллемсен. Эти технологии защищают персональные данные, обрабатывая их в защищенном состоянии или в рамках «конфиденциальных вычислений». К PET относятся дифференциальная конфиденциальность, синтетические данные, машинное обучение с учетом конфиденциальности и гомоморфное шифрование, которое выполняет вычисления над зашифрованными данными без необходимости их предварительного расшифрования. PET могут свести к минимуму вероятность повторной идентификации ИИ отдельных лиц, даже если ИИ проанализирует данные. 	 Контроль жизненного цикла. Сбор данных должен ограничиваться основными потребностями бизнеса и включать контроль доступа. Данные следует удалять, как только они перестают быть полезными и/или их защита становится экономически нецелесообразной. Что касается управления данными, то Виллемсен советует проводить «последовательную и очень тщательную очистку». 	 Повышение кибербезопасности для угроз, основанных на ИИ. Организациям следует расширять свои традиционные подходы к кибербезопасности, уделяя приоритетное внимание расширенному мониторингу, обнаружению аномалий и возможностям планирования сценариев для выявления угроз, основанных на инференсе. 	 Прозрачность и человеческий контроль. Задокументируйте, где в сети организации уместно использование ИИ-инференса, регулярно проводите аудит систем ИИ и поддерживайте участие человека в проверке выводов, генерируемых ИИ, прежде чем допустить технологию действовать с конфиденциальными данными. «Не стоит недооценивать риски, связанные с различными типами ИИ, прежде чем использовать какой-либо из них», — заключает Виллемсен]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Искусственный интеллект делает более быстрым и&nbsp;простым извлечение конфиденциальной личной информации из&nbsp;обычных бизнес-данных. Вице-президент Gartner Барт Виллемсен объясняет порталу &lltt;/em&ggtt;&lltt;em&ggtt;InformationWeek&lltt;/em&ggtt;&lltt;em&ggtt;, почему это происходит и&nbsp;что должны делать руководители служб информационной безопасности (&lltt;/em&ggtt;&lltt;em&ggtt;CISO&lltt;/em&ggtt;&lltt;em&ggtt;).&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Правила регулирования конфиденциальности данных, например европейский GDPR и&nbsp;американские федеральные законы, такие как HIPAA, больше не&nbsp;достаточны для защиты персональных данных в&nbsp;эпоху ИИ.&lltt;/p&ggtt;
&lltt;p&ggtt;Gartner &lltt;a href="https://www.gartner.com/en/documents/7864881"&ggtt;прогнозирует&lltt;/a&ggtt;, что к&nbsp;2029&nbsp;г. большинство инцидентов, связанных с&nbsp;нарушением конфиденциальности, будут вызваны ИИ-выводами об&nbsp;отдельных лицах, а&nbsp;не&nbsp;прямым раскрытием личной информации, такой как имена, адреса и&nbsp;номера социального страхования.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;словам Виллемсена, способность&nbsp;ИИ быстро распознавать образы означает, что злоумышленникам больше не&nbsp;нужно красть или покупать учетные данные, чтобы получить конфиденциальную информацию о&nbsp;людях. Анонимизация данных сама по&nbsp;себе не&nbsp;обеспечивает достаточной защиты, поскольку алгоритмы&nbsp;ИИ могут повторно идентифицировать людей или выводить конфиденциальные атрибуты из&nbsp;анонимизированных наборов данных.&lltt;/p&ggtt;
&lltt;p&ggtt;«Настоящей анонимизации не&nbsp;существует, за&nbsp;исключением фактического удаления данных. Атака на&nbsp;основе инференса очень эффективна, потому что она затрагивает всё, а&nbsp;не&nbsp;только непосредственно идентифицируемые репозитории»,&nbsp;— говорит Виллемсен.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;мере совершенствования генеративного&nbsp;ИИ и&nbsp;машинного обучения эти технологии могут выводить конфиденциальные личные характеристики&nbsp;— такие как состояние здоровья или поведенческие модели&nbsp;— из&nbsp;анонимизированных или агрегированных данных.&lltt;/p&ggtt;
&lltt;p&ggtt;«Современные модели могут восстанавливать личные данные, используя поведенческие модели, показатели использования и&nbsp;агрегированные записи транзакций. Например, ИИ&nbsp;может идентифицировать людей по&nbsp;данным о&nbsp;поездках, социальным сетям, рентгеновским снимкам, ЭКГ, МРТ, даже походке или практически любой комбинации из&nbsp;примерно трёх транзакций»,&nbsp;— объясняет Виллемсен.&lltt;/p&ggtt;
&lltt;p&ggtt;Кроме того, по&nbsp;его словам, когда&nbsp;ИИ галлюцинирует или создает синтетические данные о&nbsp;людях, эти неверные данные могут вызывать реальные проблемы. Например, предвзятость и&nbsp;галлюцинации&nbsp;ИИ могут привести к&nbsp;неправомерному тюремному заключению и&nbsp;серьезным ошибкам в&nbsp;юридических исследованиях.&lltt;/p&ggtt;
&lltt;p&ggtt;Последствия выходят далеко за&nbsp;рамки нарушений конфиденциальности, считает Эндрю Обадиару, CISO компании Cobalt. «ИИ&nbsp;может определить состояние здоровья человека, его финансовое положение, влияние внутри организации или вероятность ответа на&nbsp;фишинговое письмо, не&nbsp;имея доступа к&nbsp;медицинской карте или кадровому делу»,&nbsp;— говорит&nbsp;он.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;его словам, данные, которые не&nbsp;кажутся конфиденциальными&nbsp;— такие как справочники сотрудников, отношения с&nbsp;поставщиками, активность в&nbsp;социальных сетях или взаимодействие с&nbsp;клиентами&nbsp;— могут стать ценными, когда&nbsp;ИИ связывает эти фрагменты. ИИ&nbsp;может использовать их&nbsp;для определения структуры подчиненности, администрирования систем, взаимоотношений между руководителями, полномочий по&nbsp;расходам или того, какой инженер отвечает за&nbsp;критически важную производственную систему. Затем злоумышленники могут использовать эти данные, чтобы сделать свои атаки гораздо более точными.&lltt;/p&ggtt;
&lltt;p&ggtt;«В&nbsp;результате фишинговые кампании становятся значительно более убедительными, компрометация корпоративной электронной почты происходит быстрее, вымогательство&nbsp;— более целенаправленным, а&nbsp;операции по&nbsp;вторжению&nbsp;— гораздо эффективнее, поскольку злоумышленник уже знает, кого атаковать, прежде чем отправить первое письмо»,&nbsp;— поясняет Обадиару.&lltt;/p&ggtt;
&lltt;p&ggtt;Организациям необходимо начать задумываться не&nbsp;только о&nbsp;том, какие данные они собирают, но&nbsp;и&nbsp;о&nbsp;том, «что эти данные раскрывают, когда они объединяются, сопоставляются и&nbsp;интерпретируются все более совершенными системами ИИ»,&nbsp;— добавляет&nbsp;он. И, из-за развития технологий&nbsp;ИИ, правила обеспечения конфиденциальности, которые исторически были сосредоточены на&nbsp;непосредственно идентифицируемых данных, должны также распространяться на&nbsp;косвенно или повторно идентифицируемый контент.&lltt;/p&ggtt;
&lltt;p&ggtt;«Сочетание данных, зарегистрированных где угодно, доступа к&nbsp;ним по&nbsp;всему миру (случайно или в&nbsp;результате злонамеренного взлома) и&nbsp;возможностей, доступных любому, кто хочет получить доступ к&nbsp;данным с&nbsp;помощью современных аналитических и&nbsp;генеративных ИИ-технологий,&nbsp;— вот что отличает сегодняшнюю ситуацию. Кроме того, организации практически не&nbsp;очищают данные, которые им&nbsp;больше не&nbsp;нужны»,&nbsp;— говорит Виллемсен.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;его словам, риск повторной идентификации данных существовал задолго до&nbsp;сегодняшнего бума&nbsp;ИИ, но&nbsp;ИИ значительно ускоряет этот процесс. Он&nbsp;ссылается на&nbsp;&lltt;a href="https://www.nature.com/articles/s41467-019-10933-3.pdf"&ggtt;исследование&lltt;/a&ggtt; 2019&nbsp;г., проведенное специалистами в&nbsp;области науки о&nbsp;данных Люком Роше, Жюльеном М. Хендрикксом и&nbsp;Ивом-Александром де&nbsp;Монжуа, которые разработали генеративную графическую модель для повторной идентификации людей. «Используя нашу модель, мы&nbsp;обнаружили, что 99,98% американцев будут правильно идентифицированы в&nbsp;любом наборе данных с&nbsp;использованием 15&nbsp;демографических атрибутов»,&nbsp;— написали они.&lltt;/p&ggtt;
&lltt;h3&ggtt;ИИ&nbsp;усиливает угрозу повторной идентификации&lltt;/h3&ggtt;
&lltt;p&ggtt;По&nbsp;словам Обадиару, что изменилось с&nbsp;развитием&nbsp;ИИ, так это&nbsp;то, что теперь «скорость на&nbsp;стороне злоумышленников&nbsp;— и&nbsp;масштаб». «Пять лет назад создание подробных профилей тысяч потенциальных жертв было экономически нецелесообразным. Сегодня это не&nbsp;так»,&nbsp;— отмечает&nbsp;он.&lltt;/p&ggtt;
&lltt;p&ggtt;Виллемсен обращает внимание на&nbsp;&lltt;a href="https://arxiv.org/pdf/2602.16800"&ggtt;исследование&lltt;/a&ggtt; 2026&nbsp;г., проведенное инженерами Саймоном Лерменом, Даниэлем Палекой, Джошуа Свансоном, Майклом Аэрни, Николасом Карлини и&nbsp;Флорианом Трамером. Авторы обнаружили, что больше языковые модели (LLM) могут повторно идентифицировать людей, «используя только псевдонимизированные онлайн-профили и&nbsp;переписки, что сопоставимо с&nbsp;тем, что может выполнить опытный следователь за&nbsp;много часов работы».&lltt;/p&ggtt;
&lltt;p&ggtt;Примечательно пояснение авторов: «В&nbsp;каждой ситуации методы на&nbsp;основе LLM значительно превосходят классические базовые методы, достигая до&nbsp;68% полноты при&nbsp;90% точности по&nbsp;сравнению с&nbsp;почти&nbsp;0% для лучшего метода без применения LLM. Наши результаты показывают, что практическая неопределенность, защищающая псевдонимных пользователей в&nbsp;Интернете, больше не&nbsp;действует и&nbsp;что модели угроз для конфиденциальности в&nbsp;Интернете необходимо пересмотреть».&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;словам Обадиару, лучшие атаки на&nbsp;основе инференса совсем не&nbsp;выглядят как атаки. «Злоумышленник может начать с&nbsp;LinkedIn, публичных документов, социальных сетей, украденных учетных данных, активности на&nbsp;GitHub и&nbsp;утечек маркетинговых баз данных. Ни&nbsp;один из&nbsp;этих наборов данных сам по&nbsp;себе не&nbsp;представляет особой ценности. Но&nbsp;ИИ&nbsp;выполняет сложную работу по&nbsp;их&nbsp;объединению»,&nbsp;— отмечает&nbsp;он.&lltt;/p&ggtt;
&lltt;p&ggtt;По&nbsp;словам Виллемсена, чтобы снизить риски нарушения конфиденциальности, основанные на&nbsp;инференсе, CISO следует начать с&nbsp;обеспечения управления данными на&nbsp;протяжении всего их&nbsp;жизненного цикла и&nbsp;удаления данных, как только они перестанут приносить бизнес-ценность, которая оправдывала&nbsp;бы затраты и&nbsp;риски их&nbsp;защиты. «У&nbsp;данных есть жизненный цикл, и&nbsp;мы&nbsp;знаем, что хранить их&nbsp;вечно&nbsp;— это неразумно. Поэтому жестко запрограммируйте его конец»,&nbsp;— советует&nbsp;он.&lltt;/p&ggtt;
&lltt;h3&ggtt;Шаги по&nbsp;устранению основанных на&nbsp;инференсе рисков от&nbsp;Gartner&lltt;/h3&ggtt;
&lltt;p&ggtt;По&nbsp;словам Виллемсена, для CISO защита от&nbsp;угроз, основанных на&nbsp;ИИ-инференсе, начинается с&nbsp;управления ИИ. Вот его советы:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt;&lltt;strong&ggtt; Управление ИИ.&lltt;/strong&ggtt; Внедрите в&nbsp;разработку&nbsp;ИИ установление механизмов защиты конфиденциальности на&nbsp;этапе проектирования и&nbsp;регулярно оценивайте риски предвзятости или инференса.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Внедрение технологий повышения конфиденциальности (PET).&lltt;/strong&ggtt; PET&nbsp;— это «набор технологических инструментов»,&nbsp;— говорит Виллемсен. Эти технологии защищают персональные данные, обрабатывая их&nbsp;в&nbsp;защищенном состоянии или в&nbsp;рамках «конфиденциальных вычислений». К&nbsp;PET относятся дифференциальная конфиденциальность, синтетические данные, машинное обучение с&nbsp;учетом конфиденциальности и&nbsp;гомоморфное шифрование, которое выполняет вычисления над зашифрованными данными без необходимости их&nbsp;предварительного расшифрования. PET могут свести к&nbsp;минимуму вероятность повторной идентификации&nbsp;ИИ отдельных лиц, даже если&nbsp;ИИ проанализирует данные.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Контроль жизненного цикла.&lltt;/strong&ggtt; Сбор данных должен ограничиваться основными потребностями бизнеса и&nbsp;включать контроль доступа. Данные следует удалять, как только они перестают быть полезными и/или их&nbsp;защита становится экономически нецелесообразной. Что касается управления данными, то&nbsp;Виллемсен советует проводить «последовательную и&nbsp;очень тщательную очистку».&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Повышение кибербезопасности для угроз, основанных на&nbsp;ИИ.&lltt;/strong&ggtt; Организациям следует расширять свои традиционные подходы к&nbsp;кибербезопасности, уделяя приоритетное внимание расширенному мониторингу, обнаружению аномалий и&nbsp;возможностям планирования сценариев для выявления угроз, основанных на&nbsp;инференсе.&lltt;/li&ggtt;
	&lltt;li&ggtt;&lltt;strong&ggtt; Прозрачность и&nbsp;человеческий контроль.&lltt;/strong&ggtt; Задокументируйте, где в&nbsp;сети организации уместно использование ИИ-инференса, регулярно проводите аудит систем&nbsp;ИИ и&nbsp;поддерживайте участие человека в&nbsp;проверке выводов, генерируемых&nbsp;ИИ, прежде чем допустить технологию действовать с&nbsp;конфиденциальными данными.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;«Не&nbsp;стоит недооценивать риски, связанные с&nbsp;различными типами&nbsp;ИИ, прежде чем использовать какой-либо из&nbsp;них»,&nbsp;— заключает Виллемсен.&lltt;/p&ggtt;]]></source>
<adate>17.08.2026</adate>
<dbid>235352</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Безопасность;;Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[ИСИЭЗ НИУ ВШЭ: топ-20 фронтиров мировой науки-2025]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235349]]></link>
<description><![CDATA[Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие передний край глобальной исследовательской повестки. Среди выделенных по итогам 2025 года 890 фронтиров самые высокие значения индекса значимости у тематик, связанных с решением экологических проблем, цифровой трансформацией и психическим здоровьем человека. Климатическая повестка выходит за рамки прогнозирования изменений температуры. Исследования также охватывают поведение людей, оценку рисков и адаптацию к новым условиям, что требует объединения естественных и общественных наук. Одновременно меняется сам подход к взаимодействию с природой: антропоцентрическая парадигма, ставящая во главу угла интересы человека, постепенно уступает место экоцентрической. Рост городского населения и расширение урбанизированных территорий меняют структуру землепользования, усиливают нагрузку на природные ресурсы. Важным инструментом адаптации и планирования территорий становятся геоинформационные системы. В городах формируются локальные климатические эффекты, включая острова тепла и изменение режима осадков, повышается уязвимость к экстремальным погодным явлениям. Смягчать эти эффекты могут экосистемные услуги — секвестрация углерода, фильтрация загрязнителей и регулирование гидрологического режима. Гидротермальная карбонизация органических отходов позволяет получать энергетически ценные продукты и богатые углеродом материалы, что способствует развитию экономики замкнутого цикла. Необходимость снизить негативное воздействие на окружающую среду стимулирует развитие возобновляемой и водородной энергетики. Дальнейшее развитие топливных элементов и электролизеров во многом зависит от создания эффективных катализаторов. Наиболее перспективными считаются наночастицы благородных металлов, а более доступными альтернативами — оксиды никеля и кобальта и карбиды железа. В солнечной энергетике разрабатываются фотоэлектрические элементы нового поколения, в частности перовскитные и тандемные структуры, а также прозрачные проводящие покрытия. Для решения сложных задач уже недостаточно только наращивать вычислительные мощности: требуется одновременно собирать данные, моделировать процессы и управлять ими. В 2025 году заметно усилилась синергия вычислительных и измерительных технологий. ИИ из инструмента анализа превращается в технологию действия. Обработка данных переносится на периферию (edge) — непосредственно в устройства, датчики и локальные модули. В основе систем периферийного ИИ лежит машинное обучение, позволяющее интерпретировать разнородные и зашумленные данные без обращения к облачным центрам. В интеллектуальные системы управления все чаще встраивают нейросети, например для координации групп автономных роботов или управления роботизированными манипуляторами. Широко применяется глубокое обучение, позволяющее работать с неструктурированными данными и оперативно реагировать на изменения. Чем сложнее модели, тем важнее регуляризация. В критических областях применения ИИ особенно высоки требования к устойчивости моделей и способности точно обрабатывать новые данные. Например, медицинские диагностические системы должны надежно работать для пациентов, чьи демографические характеристики отличаются от представленных в обучающей выборке. Разработки на стыке ИИ и физики сокращают путь сигнала от регистрации до его интерпретации. Усиливать и стабилизировать сигналы позволяют резонаторные технологии, применяемые в высокочувствительных радиочастотных и сенсорных устройствах. Так, фотонные «электронные носы» на основе массивов микрорезонаторов формируют уникальный «оптический отпечаток» анализируемой смеси, а локальный ИИ-интерфейс распознает его непосредственно на чипе. Спектроскопия, выделенная в самостоятельный фронтир, позволяет увидеть то, что прежде оставалось скрытым. В 2025 г. коллаборация BASE в ЦЕРН впервые продемонстрировала применение крайне значимой для изучения асимметрии материи и антиматерии когерентной спектроскопии квантовых переходов спина одиночного антипротона. В прикладной сфере поверхностно-усиленная рамановская спектроскопия (SERS) на наночастицах позволяет регистрировать сигналы отдельных молекул и в комбинации с ИИ-анализом спектров разрабатывать методы цитологической диагностики. В классических дисциплинах такой объединенный инструментарий обеспечивает переход от наблюдения к целенаправленному управлению процессами на микро- и наноуровне. В физике совершенствуются методы управления светом, электрическими сигналами, магнитными состояниями и квантовыми эффектами, которые используются в системах спутниковой связи и навигации, жидкокристаллических дисплеях, кремниевых фотонных устройствах и голографическом хранении данных. В химии сочетание измерений и моделирования поддерживает молекулярный дизайн: изучение процессов гидрогенизации и динамики адсорбции в нестационарных условиях помогает создавать материалы и катализаторы с заданными свойствами. Такие разработки способствуют миниатюризации оптических чипов, росту скорости обработки информации и плотности ее записи. Крупный блок ведущих фронтиров образуют исследования в области развития человеческого потенциала и связанные с поддержанием здоровья как человека, так и животных. Их общая черта — внимание к раннему выявлению рисков: от молекулярных и клеточных изменений до механизмов психических расстройств и факторов развития ребенка. В биомедицине и ветеринарии биомаркеры позволяют отслеживать изменения задолго до появления выраженных клинических признаков, обеспечивая переход от симптоматической к ранней, точной и персонализированной диагностике. Анализ сывороточных биомаркеров помогает выявлять воспалительные процессы, метаболические нарушения, опухоли, повреждения тканей и др. Другой фронтир связан с антиоксидантами, подавляющими свободнорадикальное окисление, которое может запускать и усиливать различные патологические процессы. Одна из центральных тематик этого блока — ментальное здоровье. Возрастает значение исследований, направленных на выявление биологических, психологических и средовых механизмов формирования психических расстройств, а также факторов, способствующих сохранению психологической устойчивости. Профилактика ментальных расстройств затрагивает и сферу воспитания детей, согласно результатам исследований, качество связи родителя с ребенком в раннем возрасте оказывает прямое влияние на метилирование ДНК и формирование архитектуры нейронных сетей мозга. Эта проблематика имеет не только медицинское, но и социальное, экономическое и демографическое значение, поскольку ментальное здоровье во многом определяет уровень качества жизни человека. Карта ведущих научных фронтиров отражает поиск системных ответов на глобальные вызовы. Сохранение планеты становится фокусом экологических исследований, работы в области биомедицины направлены на повышение качества жизни человека, фундаментальную основу новых решений обеспечивают биология, физика и химия, цифровые технологии расширяют возможности измерения и управления. Перечень фронтиров может служить ориентиром при выборе тем исследований и определении приоритетов поддержки науки и технологий]]></description>
<source><![CDATA[&lltt;p&ggtt;Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие передний край глобальной исследовательской повестки. Среди выделенных по итогам 2025 года 890 фронтиров самые высокие значения индекса значимости у тематик, связанных с решением экологических проблем, цифровой трансформацией и психическим здоровьем человека.&lltt;/p&ggtt;
&lltt;p&ggtt;Климатическая повестка выходит за рамки прогнозирования изменений температуры. Исследования также охватывают поведение людей, оценку рисков и адаптацию к новым условиям, что требует объединения естественных и общественных наук. Одновременно меняется сам подход к взаимодействию с природой: антропоцентрическая парадигма, ставящая во главу угла интересы человека, постепенно уступает место экоцентрической.&lltt;/p&ggtt;
&lltt;p&ggtt;Рост городского населения и расширение урбанизированных территорий меняют структуру землепользования, усиливают нагрузку на природные ресурсы. Важным инструментом адаптации и планирования территорий становятся геоинформационные системы. В городах формируются локальные климатические эффекты, включая острова тепла и изменение режима осадков, повышается уязвимость к экстремальным погодным явлениям. Смягчать эти эффекты могут экосистемные услуги — секвестрация углерода, фильтрация загрязнителей и регулирование гидрологического режима. Гидротермальная карбонизация органических отходов позволяет получать энергетически ценные продукты и богатые углеродом материалы, что способствует развитию экономики замкнутого цикла.&lltt;/p&ggtt;
&lltt;p&ggtt;Необходимость снизить негативное воздействие на окружающую среду стимулирует развитие возобновляемой и водородной энергетики. Дальнейшее развитие топливных элементов и электролизеров во многом зависит от создания эффективных катализаторов. Наиболее перспективными считаются наночастицы благородных металлов, а более доступными альтернативами — оксиды никеля и кобальта и карбиды железа. В солнечной энергетике разрабатываются фотоэлектрические элементы нового поколения, в частности перовскитные и тандемные структуры, а также прозрачные проводящие покрытия.&lltt;/p&ggtt;
&lltt;p&ggtt;Для решения сложных задач уже недостаточно только наращивать вычислительные мощности: требуется одновременно собирать данные, моделировать процессы и управлять ими. В 2025 году заметно усилилась синергия вычислительных и измерительных технологий.&lltt;/p&ggtt;
&lltt;p&ggtt;ИИ из инструмента анализа превращается в технологию действия. Обработка данных переносится на периферию (edge) — непосредственно в устройства, датчики и локальные модули. В основе систем периферийного ИИ лежит машинное обучение, позволяющее интерпретировать разнородные и зашумленные данные без обращения к облачным центрам.&lltt;/p&ggtt;
&lltt;p&ggtt;В интеллектуальные системы управления все чаще встраивают нейросети, например для координации групп автономных роботов или управления роботизированными манипуляторами. Широко применяется глубокое обучение, позволяющее работать с неструктурированными данными и оперативно реагировать на изменения.&lltt;/p&ggtt;
&lltt;p&ggtt;Чем сложнее модели, тем важнее регуляризация. В критических областях применения ИИ особенно высоки требования к устойчивости моделей и способности точно обрабатывать новые данные. Например, медицинские диагностические системы должны надежно работать для пациентов, чьи демографические характеристики отличаются от представленных в обучающей выборке.&lltt;/p&ggtt;
&lltt;p&ggtt;Разработки на стыке ИИ и физики сокращают путь сигнала от регистрации до его интерпретации. Усиливать и стабилизировать сигналы позволяют резонаторные технологии, применяемые в высокочувствительных радиочастотных и сенсорных устройствах. Так, фотонные «электронные носы» на основе массивов микрорезонаторов формируют уникальный «оптический отпечаток» анализируемой смеси, а локальный ИИ-интерфейс распознает его непосредственно на чипе.&lltt;/p&ggtt;
&lltt;p&ggtt;Спектроскопия, выделенная в самостоятельный фронтир, позволяет увидеть то, что прежде оставалось скрытым. В 2025 г. коллаборация BASE в ЦЕРН впервые продемонстрировала применение крайне значимой для изучения асимметрии материи и антиматерии когерентной спектроскопии квантовых переходов спина одиночного антипротона. В прикладной сфере поверхностно-усиленная рамановская спектроскопия (SERS) на наночастицах позволяет регистрировать сигналы отдельных молекул и в комбинации с ИИ-анализом спектров разрабатывать методы цитологической диагностики.&lltt;/p&ggtt;
&lltt;p&ggtt;В классических дисциплинах такой объединенный инструментарий обеспечивает переход от наблюдения к целенаправленному управлению процессами на микро- и наноуровне. В физике совершенствуются методы управления светом, электрическими сигналами, магнитными состояниями и квантовыми эффектами, которые используются в системах спутниковой связи и навигации, жидкокристаллических дисплеях, кремниевых фотонных устройствах и голографическом хранении данных. В химии сочетание измерений и моделирования поддерживает молекулярный дизайн: изучение процессов гидрогенизации и динамики адсорбции в нестационарных условиях помогает создавать материалы и катализаторы с заданными свойствами. Такие разработки способствуют миниатюризации оптических чипов, росту скорости обработки информации и плотности ее записи.&lltt;/p&ggtt;
&lltt;p&ggtt;Крупный блок ведущих фронтиров образуют исследования в области развития человеческого потенциала и связанные с поддержанием здоровья как человека, так и животных. Их общая черта — внимание к раннему выявлению рисков: от молекулярных и клеточных изменений до механизмов психических расстройств и факторов развития ребенка.&lltt;/p&ggtt;
&lltt;p&ggtt;В биомедицине и ветеринарии биомаркеры позволяют отслеживать изменения задолго до появления выраженных клинических признаков, обеспечивая переход от симптоматической к ранней, точной и персонализированной диагностике. Анализ сывороточных биомаркеров помогает выявлять воспалительные процессы, метаболические нарушения, опухоли, повреждения тканей и др. Другой фронтир связан с антиоксидантами, подавляющими свободнорадикальное окисление, которое может запускать и усиливать различные патологические процессы.&lltt;/p&ggtt;
&lltt;p&ggtt;Одна из центральных тематик этого блока — ментальное здоровье. Возрастает значение исследований, направленных на выявление биологических, психологических и средовых механизмов формирования психических расстройств, а также факторов, способствующих сохранению психологической устойчивости. Профилактика ментальных расстройств затрагивает и сферу воспитания детей, согласно результатам исследований, качество связи родителя с ребенком в раннем возрасте оказывает прямое влияние на метилирование ДНК и формирование архитектуры нейронных сетей мозга. Эта проблематика имеет не только медицинское, но и социальное, экономическое и демографическое значение, поскольку ментальное здоровье во многом определяет уровень качества жизни человека.&lltt;/p&ggtt;
&lltt;p&ggtt;Карта ведущих научных фронтиров отражает поиск системных ответов на глобальные вызовы. Сохранение планеты становится фокусом экологических исследований, работы в области биомедицины направлены на повышение качества жизни человека, фундаментальную основу новых решений обеспечивают биология, физика и химия, цифровые технологии расширяют возможности измерения и управления. Перечень фронтиров может служить ориентиром при выборе тем исследований и определении приоритетов поддержки науки и технологий.&lltt;/p&ggtt;]]></source>
<adate>14.08.2026</adate>
<dbid>235349</dbid>
<rubric>1</rubric>
<orubric>13721</orubric>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[Искусственный интеллект]]></tag>
</item>
<item>
<title><![CDATA[Почему деанонимизация доменов становится глобальным трендом]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235343]]></link>
<description><![CDATA[Доменная отрасль во многих странах постепенно интегрируется с системами цифровой идентификации. Государства рассматривают доменную инфраструктуру как часть общей системы кибербезопасности, устойчивости онлайн-сервисов и управления онлайн-активами. Россия также движется в этом направлении: с сентября 2026 года для доменов в зонах .ru, .рф и .su ключевые операции будут связаны с подтверждением администратора через ЕСИА. Рассмотрим, как меняется регулирование доменной отрасли в разных странах, как российский подход соотносится с международной практикой и что новые требования означают для бизнеса. В России меняются правила регистрации доменов С 1 сентября 2026 года вступают в силу новые правила регистрации и продления доменов в зонах .ru, .рф и .su. Администраторам потребуется обязательная идентификация через ЕСИА — систему авторизации на портале «Госуслуги». Изменения закреплены федеральным законом № 569-ФЗ. Новые требования распространяются на все категории администраторов. Физическим лицам и индивидуальным предпринимателям понадобится подтвержденная учетная запись на Госуслугах. Юридическим лицам необходимо зарегистрировать организацию на портале и назначить сотрудника с подтвержденными полномочиями для управления доменами. Иностранные граждане и компании также должны будут учитывать новые требования: пройти идентификацию через ЕСИА при наличии такой возможности либо заранее выбрать иную допустимую модель управления доменом. Некоторые регистраторы предлагают решение «Доверенный администратор» (trustee-сервис), которое позволяет управлять доменом в зонах .ru, .рф и .su без идентификации через Госуслуги. Домен регистрируется на российское юрлицо с подтвержденной записью в ЕСИА, а вы сохраняете полный контроль через свой личный кабинет. Обязанность указывать достоверные данные при регистрации доменов существовала и раньше: администраторы должны были предоставлять регистраторам актуальные паспортные, контактные и регистрационные данные. Однако проверка этой информации в значительной степени оставалась ручной и зависела от предоставленных документов. Теперь система предполагает цифровое подтверждение данных через государственную инфраструктуру идентификации. Это должно повысить прозрачность доменной среды, упростить установление владельцев интернет-ресурсов и усилить меры против мошеннических и противоправных онлайн-активностей. Для пользователей регистрация и продление доменов в стандартных сценариях также станут проще: часть данных будет автоматически заполняться на основе информации из ЕСИА без необходимости отдельно загружать документы и подтверждения. Но для компаний с неупорядоченным доменным портфелем новые правила могут выявить старые проблемы: домены, оформленные на бывших сотрудников, подрядчиков, старые юридические лица или аккаунты, к которым давно нет доступа. Почему государства стали внимательнее к доменной инфраструктуре Рост внимания к доменной отрасли напрямую связан с вопросами кибербезопасности. Домены регулярно используются в фишинговых атаках, распространении вредоносного ПО, мошеннических схемах и управлении ботнетами. Для атакующих домен остается удобной точкой входа: он помогает имитировать бренд, запускать поддельные лендинги, маскировать инфраструктуру и перенаправлять пользователей на вредоносные ресурсы. Проблема носит глобальный характер. По данным исследования американской аналитической компании Interisle Consulting Group, в 2025 году количество доменов, использованных в фишинговых атаках по всему миру, превысило 1,5 млн., а общее число зарегистрированных фишинговых кампаний приблизилось к 2 млн. Российский сегмент интернета также сталкивается с ростом подобных угроз. По данным проекта «Доменный патруль» Координационного центра .RU/.РФ, в 2025 году в рунете заблокировали более 42 тыс. фишинговых сайтов и свыше 10 тыс. ресурсов, распространявших вредоносное ПО. На этом фоне государства рассматривают доменную инфраструктуру как часть системы цифровой устойчивости и кибербезопасности. Возможность быстро установить владельца интернет-ресурса позволяет оперативнее реагировать на инциденты, снижать масштабы злоупотреблений и выстраивать взаимодействие между регистраторами, ИБ-службами и правоохранительными органами. Еще один фактор — повышение прозрачности цифровой среды. Для регуляторов важно понимать, кто управляет ключевыми онлайн-активами внутри национального доменного пространства. Это позволяет снизить риски анонимного использования доменов в противоправной деятельности и сделать управление цифровой инфраструктурой более предсказуемым при взаимодействии бизнеса и государства. Для бизнеса эта логика тоже важна. Домен давно перестал быть просто адресом сайта: он связан с почтой, клиентским трафиком, рекламными кампаниями, API-интеграциями, SSL/TLS-сертификатами и доверием пользователей. Потеря контроля над доменом может привести не только к недоступности сайта, но и к сбоям в сервисах, утрате почтового контура или репутационному ущербу. Какие модели идентификации действуют в разных странах Подходы к идентификации владельцев доменов отличаются в зависимости от страны, однако почти все крупные юрисдикции движутся в сторону более прозрачной модели регулирования. В Евросоюзе изменения связаны с директивой NIS2, которая требует от регистраторов и реестров обеспечивать проверку и актуальность данных владельцев доменов. Речь идет не о централизованной государственной идентификации, а о повышении прозрачности доменной среды и снижении количества анонимных или недостоверных регистраций. Германия стала одной из первых стран, внедривших такие требования. Владельцы доменов должны подтверждать контактные данные, а при подозрительной активности регулятор или регистратор вправе запросить дополнительную верификацию. Европейская модель в большей степени носит риск-ориентированный характер: углубленная проверка обычно применяется при выявлении подозрительных действий или жалоб. В случае отказа от подтверждения данных домен может быть ограничен в обслуживании или заблокирован. Азиатские страны чаще используют более формализованные механизмы проверки личности или регистрационных данных. В Китае действует система real-name verification с обязательной проверкой документов владельца домена. В Индии регулирование также движется в сторону усиления KYC/e-KYC-процедур для доменных регистраций, в том числе на фоне судебной практики и обсуждения мер против фишинга и мошеннических сайтов. В ряде стран регулирование доменной отрасли строится вокруг принципа локального присутствия. Например, регистрация доменов в Австралии или Сингапуре может требовать локализации бизнеса, наличия национального регистрационного номера или использования trustee-сервисов, когда формальным администратором выступает местный регистратор, а фактическое управление остается за иностранной организацией. Как устроена российская модель идентификации Российская система идентификации администраторов доменов строится вокруг интеграции регистраторов с ЕСИА — Единой системой идентификации и аутентификации, используемой на портале Госуслуг. При регистрации или продлении домена администратор должен будет авторизоваться через Госуслуги и подтвердить свою учетную запись. Для физических лиц и индивидуальных предпринимателей потребуется подтвержденный аккаунт пользователя. Юридическим лицам необходимо зарегистрировать организацию в ЕСИА и назначить сотрудника с подтвержденными полномочиями для управления доменами. После авторизации сведения о владельце домена будут автоматически подтверждаться через государственную систему идентификации и передаваться регистратору в рамках установленного регулирования. Это позволит отказаться от значительной части ручных проверок и отдельной загрузки документов при стандартных сценариях регистрации и продления доменов. Российская модель сочетает элементы нескольких международных подходов, но при этом формирует собственную систему регулирования. В отличие от европейской модели, где углубленная проверка обычно применяется в ответ на подозрительную активность или жалобы, российский подход предполагает превентивную идентификацию администратора до выполнения ключевых операций с доменом. При этом российская система опирается не на новую отдельную процедуру, а на уже существующую цифровую инфраструктуру ЕСИА. Для пользователей это снижает количество ручных действий, а для регистраторов и государства создает более устойчивую модель подтверждения данных администратора домена. Как администраторам доменов в компаниях подготовиться к новым правилам До вступления новых требований остается немного времени, поэтому компаниям стоит провести аудит доменного портфеля и проверить текущую модель управления онлайн-активами. Бизнесу важно: 	 собрать перечень всех доменов, используемых компанией 	 проверить связанные элементы инфраструктуры: DNS-записи, SSL/TLS-сертификаты, почтовые настройки, редиректы, поддомены и домены рекламных кампаний; 	 проверить, на кого зарегистрированы домены и актуальны ли данные администраторов; 	 убедиться, что критически важные домены оформлены на юридическое лицо компании, а не на сотрудников, подрядчиков или внешних разработчиков; 	 проверить, у кого есть доступ к учетным записям, через которые осуществляется управление доменами; 	 зарегистрировать организацию в ЕСИА и определить сотрудников, ответственных за администрирование доменов; 	 убедиться, что у ответственных сотрудников есть подтвержденные полномочия для работы через Госуслуги. Особое внимание стоит уделить доменам, зарегистрированным на бывших сотрудников или сторонних исполнителей. После запуска обязательной идентификации отсутствие прямого контроля над учетной записью администратора может осложнить продление домена, подтверждение данных или восстановление доступа к онлайн-ресурсам компании. Также стоит определить владельца процесса внутри компании. На практике доменами могут заниматься ИТ, ИБ, юристы, маркетинг и подрядчики, но при отсутствии единого ответственного доменный портфель быстро становится непрозрачным. Минимальный набор контроля — единый реестр доменов, регламент продления, порядок выдачи доступов, резервные контакты и регулярная проверка критичных доменных операций. Для бизнеса новые правила управления доменами — это повод проверить, кто фактически контролирует ключевые онлайн-адреса, где находятся доступы и можно ли без задержек подтвердить права на домен. Чем раньше компания проведет аудит доменного портфеля, тем ниже риск столкнуться с проблемами при продлении, изменении DNS-настроек или восстановлении доступа к онлайн-сервисам. В итоге подготовка к ЕСИА становится частью грамотного управления цифровой инфраструктурой — так же, как контроль учетных записей, сертификатов, почты и других критичных сервисов. #IMAGE_235344#]]></description>
<source><![CDATA[&lltt;p&ggtt;Доменная отрасль во&nbsp;многих странах постепенно интегрируется с&nbsp;системами цифровой идентификации. Государства рассматривают доменную инфраструктуру как часть общей системы кибербезопасности, устойчивости онлайн-сервисов и&nbsp;управления онлайн-активами. Россия также движется в&nbsp;этом направлении: с&nbsp;сентября 2026 года для доменов в&nbsp;зонах .ru, .рф и .su ключевые операции будут связаны с&nbsp;подтверждением администратора через ЕСИА.&lltt;/p&ggtt;
&lltt;p&ggtt;Рассмотрим, как меняется регулирование доменной отрасли в&nbsp;разных странах, как российский подход соотносится с&nbsp;международной практикой и&nbsp;что новые требования означают для бизнеса.&lltt;/p&ggtt;
&lltt;h3&ggtt;В&nbsp;России меняются правила регистрации доменов&lltt;/h3&ggtt;
&lltt;p&ggtt;С&nbsp;1&nbsp;сентября 2026 года вступают в&nbsp;силу новые правила регистрации и&nbsp;продления доменов в&nbsp;зонах .ru, .рф и .su. Администраторам потребуется обязательная идентификация через ЕСИА&nbsp;— систему авторизации на&nbsp;портале «Госуслуги». Изменения закреплены федеральным &lltt;a href="https://www.consultant.ru/document/cons_doc_LAW_523115/"&ggtt;законом №&nbsp;&lltt;nobr&ggtt;569-ФЗ&lltt;/nobr&ggtt;&lltt;/a&ggtt;.&lltt;/p&ggtt;
&lltt;p&ggtt;Новые требования распространяются на&nbsp;все категории администраторов. Физическим лицам и&nbsp;индивидуальным предпринимателям понадобится подтвержденная учетная запись на&nbsp;Госуслугах. Юридическим лицам необходимо зарегистрировать организацию на&nbsp;портале и&nbsp;назначить сотрудника с&nbsp;подтвержденными полномочиями для управления доменами. Иностранные граждане и&nbsp;компании также должны будут учитывать новые требования: пройти идентификацию через ЕСИА при наличии такой возможности либо заранее выбрать иную допустимую модель управления доменом. Некоторые регистраторы предлагают решение «Доверенный администратор» (trustee-сервис), которое позволяет управлять доменом в&nbsp;зонах .ru, .рф и .su без идентификации через Госуслуги. Домен регистрируется на&nbsp;российское юрлицо с&nbsp;подтвержденной записью в&nbsp;ЕСИА, а&nbsp;вы&nbsp;сохраняете полный контроль через свой личный кабинет.&lltt;/p&ggtt;
&lltt;p&ggtt;Обязанность указывать достоверные данные при регистрации доменов существовала и&nbsp;раньше: администраторы должны были предоставлять регистраторам актуальные паспортные, контактные и&nbsp;регистрационные данные. Однако проверка этой информации в&nbsp;значительной степени оставалась ручной и&nbsp;зависела от&nbsp;предоставленных документов.&lltt;/p&ggtt;
&lltt;p&ggtt;Теперь система предполагает цифровое подтверждение данных через государственную инфраструктуру идентификации. Это должно повысить прозрачность доменной среды, упростить установление владельцев интернет-ресурсов и&nbsp;усилить меры против мошеннических и&nbsp;противоправных онлайн-активностей.&lltt;/p&ggtt;
&lltt;p&ggtt;Для пользователей регистрация и&nbsp;продление доменов в&nbsp;стандартных сценариях также станут проще: часть данных будет автоматически заполняться на&nbsp;основе информации из&nbsp;ЕСИА без необходимости отдельно загружать документы и&nbsp;подтверждения. Но&nbsp;для компаний с&nbsp;неупорядоченным доменным портфелем новые правила могут выявить старые проблемы: домены, оформленные на&nbsp;бывших сотрудников, подрядчиков, старые юридические лица или аккаунты, к&nbsp;которым давно нет доступа.&lltt;/p&ggtt;
&lltt;h3&ggtt;Почему государства стали внимательнее к&nbsp;доменной инфраструктуре&lltt;/h3&ggtt;
&lltt;p&ggtt;Рост внимания к&nbsp;доменной отрасли напрямую связан с&nbsp;вопросами кибербезопасности. Домены регулярно используются в&nbsp;фишинговых атаках, распространении вредоносного&nbsp;ПО, мошеннических схемах и&nbsp;управлении ботнетами. Для атакующих домен остается удобной точкой входа: он&nbsp;помогает имитировать бренд, запускать поддельные лендинги, маскировать инфраструктуру и&nbsp;перенаправлять пользователей на&nbsp;вредоносные ресурсы.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема носит глобальный характер. По&nbsp;данным &lltt;a href="https://interisle.net/insights/phishing-landscape-2025-an-annual-study-of-the-scope-and-distribution-of-phishing"&ggtt;исследования&lltt;/a&ggtt; американской аналитической компании Interisle Consulting Group, в&nbsp;2025 году количество доменов, использованных в&nbsp;фишинговых атаках по&nbsp;всему миру, превысило 1,5&nbsp;млн., а&nbsp;общее число зарегистрированных фишинговых кампаний приблизилось к&nbsp;2&nbsp;млн.&lltt;/p&ggtt;
&lltt;p&ggtt;Российский сегмент интернета также сталкивается с&nbsp;ростом подобных угроз. По&nbsp;&lltt;a href="https://domainpatrol.ru/upload/iblock/676/kq5hwn3umunbtr2b21ndavh17ptw6is1/KO_2025_rus.pdf"&ggtt;данным&lltt;/a&ggtt; проекта «Доменный патруль» Координационного центра .RU/.РФ, в&nbsp;2025 году в&nbsp;рунете заблокировали более 42&nbsp;тыс. фишинговых сайтов и&nbsp;свыше 10&nbsp;тыс. ресурсов, распространявших вредоносное ПО.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;этом фоне государства рассматривают доменную инфраструктуру как часть системы цифровой устойчивости и&nbsp;кибербезопасности. Возможность быстро установить владельца интернет-ресурса позволяет оперативнее реагировать на&nbsp;инциденты, снижать масштабы злоупотреблений и&nbsp;выстраивать взаимодействие между регистраторами, ИБ-службами и&nbsp;правоохранительными органами.&lltt;/p&ggtt;
&lltt;p&ggtt;Еще один фактор&nbsp;— повышение прозрачности цифровой среды. Для регуляторов важно понимать, кто управляет ключевыми онлайн-активами внутри национального доменного пространства. Это позволяет снизить риски анонимного использования доменов в&nbsp;противоправной деятельности и&nbsp;сделать управление цифровой инфраструктурой более предсказуемым при взаимодействии бизнеса и&nbsp;государства. Для бизнеса эта логика тоже важна. Домен давно перестал быть просто адресом сайта: он&nbsp;связан с&nbsp;почтой, клиентским трафиком, рекламными кампаниями, API-интеграциями, SSL/TLS-сертификатами и&nbsp;доверием пользователей. Потеря контроля над доменом может привести не&nbsp;только к&nbsp;недоступности сайта, но&nbsp;и&nbsp;к&nbsp;сбоям в&nbsp;сервисах, утрате почтового контура или репутационному ущербу.&lltt;/p&ggtt;
&lltt;h3&ggtt;Какие модели идентификации действуют в&nbsp;разных странах&lltt;/h3&ggtt;
&lltt;p&ggtt;Подходы к&nbsp;идентификации владельцев доменов отличаются в&nbsp;зависимости от&nbsp;страны, однако почти все крупные юрисдикции движутся в&nbsp;сторону более прозрачной модели регулирования.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;Евросоюзе изменения связаны с&nbsp;директивой NIS2, которая требует от&nbsp;регистраторов и&nbsp;реестров обеспечивать проверку и&nbsp;актуальность данных владельцев доменов. Речь идет не&nbsp;о&nbsp;централизованной государственной идентификации, а&nbsp;о&nbsp;повышении прозрачности доменной среды и&nbsp;снижении количества анонимных или недостоверных регистраций.&lltt;/p&ggtt;
&lltt;p&ggtt;Германия стала одной из&nbsp;первых стран, внедривших такие требования. Владельцы доменов должны подтверждать контактные данные, а&nbsp;при подозрительной активности регулятор или регистратор вправе запросить дополнительную верификацию. Европейская модель в&nbsp;большей степени носит риск-ориентированный характер: углубленная проверка обычно применяется при выявлении подозрительных действий или жалоб. В&nbsp;случае отказа от&nbsp;подтверждения данных домен может быть ограничен в&nbsp;обслуживании или заблокирован.&lltt;/p&ggtt;
&lltt;p&ggtt;Азиатские страны чаще используют более формализованные механизмы проверки личности или регистрационных данных. В&nbsp;Китае действует система real-name verification с&nbsp;обязательной проверкой документов владельца домена. В&nbsp;Индии регулирование также движется в&nbsp;сторону усиления KYC/e-KYC-процедур для доменных регистраций, в&nbsp;том числе на&nbsp;фоне судебной практики и&nbsp;обсуждения мер против фишинга и&nbsp;мошеннических сайтов.&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;ряде стран регулирование доменной отрасли строится вокруг принципа локального присутствия. Например, регистрация доменов в&nbsp;Австралии или Сингапуре может требовать локализации бизнеса, наличия национального регистрационного номера или использования trustee-сервисов, когда формальным администратором выступает местный регистратор, а&nbsp;фактическое управление остается за&nbsp;иностранной организацией.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как устроена российская модель идентификации&lltt;/h3&ggtt;
&lltt;p&ggtt;Российская система идентификации администраторов доменов строится вокруг интеграции регистраторов с&nbsp;ЕСИА&nbsp;— Единой системой идентификации и&nbsp;аутентификации, используемой на&nbsp;портале Госуслуг.&lltt;/p&ggtt;
&lltt;p&ggtt;При регистрации или продлении домена администратор должен будет авторизоваться через Госуслуги и&nbsp;подтвердить свою учетную запись. Для физических лиц и&nbsp;индивидуальных предпринимателей потребуется подтвержденный аккаунт пользователя. Юридическим лицам необходимо зарегистрировать организацию в&nbsp;ЕСИА и&nbsp;назначить сотрудника с&nbsp;подтвержденными полномочиями для управления доменами.&lltt;/p&ggtt;
&lltt;p&ggtt;После авторизации сведения о&nbsp;владельце домена будут автоматически подтверждаться через государственную систему идентификации и&nbsp;передаваться регистратору в&nbsp;рамках установленного регулирования. Это позволит отказаться от&nbsp;значительной части ручных проверок и&nbsp;отдельной загрузки документов при стандартных сценариях регистрации и&nbsp;продления доменов.&lltt;/p&ggtt;
&lltt;p&ggtt;Российская модель сочетает элементы нескольких международных подходов, но&nbsp;при этом формирует собственную систему регулирования. В&nbsp;отличие от&nbsp;европейской модели, где углубленная проверка обычно применяется в&nbsp;ответ на&nbsp;подозрительную активность или жалобы, российский подход предполагает превентивную идентификацию администратора до&nbsp;выполнения ключевых операций с&nbsp;доменом.&lltt;/p&ggtt;
&lltt;p&ggtt;При этом российская система опирается не&nbsp;на&nbsp;новую отдельную процедуру, а&nbsp;на&nbsp;уже существующую цифровую инфраструктуру ЕСИА. Для пользователей это снижает количество ручных действий, а&nbsp;для регистраторов и&nbsp;государства создает более устойчивую модель подтверждения данных администратора домена.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как администраторам доменов в&nbsp;компаниях подготовиться к&nbsp;новым правилам&lltt;/h3&ggtt;
&lltt;p&ggtt;До&nbsp;вступления новых требований остается немного времени, поэтому компаниям стоит провести аудит доменного портфеля и&nbsp;проверить текущую модель управления онлайн-активами.&lltt;/p&ggtt;
&lltt;p&ggtt;Бизнесу важно:&lltt;/p&ggtt;
&lltt;ul&ggtt; 
	&lltt;li&ggtt; собрать перечень всех доменов, используемых компанией&lltt;/li&ggtt;
	&lltt;li&ggtt; проверить связанные элементы инфраструктуры: DNS-записи, SSL/TLS-сертификаты, почтовые настройки, редиректы, поддомены и&nbsp;домены рекламных кампаний;&lltt;/li&ggtt;
	&lltt;li&ggtt; проверить, на&nbsp;кого зарегистрированы домены и&nbsp;актуальны&nbsp;ли данные администраторов;&lltt;/li&ggtt;
	&lltt;li&ggtt; убедиться, что критически важные домены оформлены на&nbsp;юридическое лицо компании, а&nbsp;не&nbsp;на&nbsp;сотрудников, подрядчиков или внешних разработчиков;&lltt;/li&ggtt;
	&lltt;li&ggtt; проверить, у&nbsp;кого есть доступ к&nbsp;учетным записям, через которые осуществляется управление доменами;&lltt;/li&ggtt;
	&lltt;li&ggtt; зарегистрировать организацию в&nbsp;ЕСИА и&nbsp;определить сотрудников, ответственных за&nbsp;администрирование доменов;&lltt;/li&ggtt;
	&lltt;li&ggtt; убедиться, что у&nbsp;ответственных сотрудников есть подтвержденные полномочия для работы через Госуслуги.&lltt;/li&ggtt;
&lltt;/ul&ggtt;
&lltt;p&ggtt;Особое внимание стоит уделить доменам, зарегистрированным на&nbsp;бывших сотрудников или сторонних исполнителей. После запуска обязательной идентификации отсутствие прямого контроля над учетной записью администратора может осложнить продление домена, подтверждение данных или восстановление доступа к&nbsp;онлайн-ресурсам компании.&lltt;/p&ggtt;
&lltt;p&ggtt;Также стоит определить владельца процесса внутри компании. На&nbsp;практике доменами могут заниматься ИТ, ИБ, юристы, маркетинг и&nbsp;подрядчики, но&nbsp;при отсутствии единого ответственного доменный портфель быстро становится непрозрачным. Минимальный набор контроля&nbsp;— единый реестр доменов, регламент продления, порядок выдачи доступов, резервные контакты и&nbsp;регулярная проверка критичных доменных операций.&lltt;/p&ggtt;
&lltt;p&ggtt;Для бизнеса новые правила управления доменами&nbsp;— это повод проверить, кто фактически контролирует ключевые онлайн-адреса, где находятся доступы и&nbsp;можно&nbsp;ли без задержек подтвердить права на&nbsp;домен. Чем раньше компания проведет аудит доменного портфеля, тем ниже риск столкнуться с&nbsp;проблемами при продлении, изменении DNS-настроек или восстановлении доступа к&nbsp;онлайн-сервисам. В&nbsp;итоге подготовка к&nbsp;ЕСИА становится частью грамотного управления цифровой инфраструктурой&nbsp;— так&nbsp;же, как контроль учетных записей, сертификатов, почты и&nbsp;других критичных сервисов.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235344#&lltt;/p&ggtt;]]></source>
<adate>14.08.2026</adate>
<dbid>235343</dbid>
<rubric>8</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/6a8/zb58owq85ptyu2xke9ocq0q8lmkej3v6.jpg]]>
</images>
<imagesname><![CDATA[;;Георгий Казаров, руководитель отдела доменов Руцентра   ]]></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Откуда берутся DevOps-инженеры — и почему их всё равно не хватает]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235347]]></link>
<description><![CDATA[Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться в людей, зная, что те уйдут, — и что это говорит о рынке IT-кадров? Хороший DevOps-инженер готовится к докладу на конференции — шлифует слайды, прогоняет демо. Он еще не знает, что через два месяца уволится. Не потому что плохо платили или надоело — просто выступил, к нему подошли, предложили больше. Это не провал HR, а нормальная механика рынка, в которой облачные провайдеры играют специфическую роль — они растят специалистов, которых потом хотят все. Рынок сжался — но не для всех В 2025 году вакансий для айтишников стало на 26% меньше, чем годом ранее. Казалось бы, передышка для работодателей. Но облачные провайдеры её не почувствовали: клиентская база росла, крупный бизнес ускорял переход в облако, и спрос на опытных инженеров оставался высоким. По данным TechTarget, 87% технических директоров по-прежнему говорят, что не могут найти нужных специалистов. Проблема структурная. Технологические навыки устаревают примерно за 2,5 года, а университеты обновляют программы куда медленнее. Система подготовки кадров просто не рассчитана на такую скорость изменений — и отрасль давно научилась справляться с этим своими силами. Как устроена карьерная труба В провайдерской среде есть устойчивая модель, которую внутри индустрии неформально называют «трубой». Специалист приходит с минимальными навыками — в техподдержку, на дежурную смену, в администрирование. Работает на больших объемах и разнообразных задачах. Постепенно растёт. Через несколько лет из него получается инженер с реальной экспертизой. Если посмотреть на DevOps-инженеров в облачных командах, то 9 из 10 — те, кто проросли внутри компании, а не пришли готовыми. Это не случайность и не особенность одного провайдера. Это общая логика отрасли: в отличие от BigTech, где специалист приходит уже сформированным под конкретную задачу, провайдерская среда по природе своей многоуровневая. Здесь есть ступеньки, на которых можно учиться в процессе работы — и это работает. Чем облако привлекает инженера Объяснять выбор в пользу провайдера только деньгами — упрощение. Суть в характере работы. DevOps в корпоративном IT обслуживает одну команду, настраивает один пайплайн, работает по гайдам. Задача решена — переключается на следующую, примерно такую же. В облачном провайдере задача другая: не развернуть инфраструктуру для своей команды, а создать сервис, который потом будет предоставляться тысячам клиентов в автоматизированном режиме. Это ближе к разработке, чем к эксплуатации. Другой уровень сложности, другое мышление. Именно поэтому опыт из облака ценится на рынке: инженер, проработавший в провайдере, приходит в BigTech с насмотренностью и навыками, которые там сложно получить иначе. Рынок это подтверждает — по данным Enigma Intelligence, наиболее востребованными в 2025-2026 годах стали специалисты в Platform Engineering и DevSecOps, то есть именно в том, чем занимаются облачные команды каждый день. Когда специалист уходит Конференции стали обязательной частью профессиональной жизни инженера. Выступить с докладом — значит показать экспертизу, прокачать личный бренд, поделиться опытом с сообществом. Всё это так. Но у этой медали есть обратная сторона: человек всё о себе рассказал, экспертизу показал, контакты на последнем слайде оставил. Хедхантерам остается только подойти после секции. Однажды так мы потеряли одного из сильных инженеров: выступил с докладом, познакомился с нужным человеком и через два месяца принял оффер. Обидно? Отчасти. Неожиданно? Нет. Такова механика открытого рынка — и мы сами участвуем в ней с обеих сторон. Переходы между провайдерами — обычная история. Специалисты идут туда, где больше объёмы, интереснее задачи, выше зарплата. Это работает в обе стороны. Главное — понимать, что удержать человека силой невозможно, а вот создать среду, из которой не хочется уходить, — вполне. К слову, к клиентам инженеры уходят редко — и это не случайно. В облачном провайдинге специалист не привязан к конкретному заказчику: с ним работает команда, контакты ситуативны, личного коннекта, который мог бы перерасти в оффер, почти не возникает. Это механика аутсорс-разработки, не провайдинга. Рынок труда: от голода к насыщению Ещё полтора года назад картина была другой. Вакансия могла висеть полгода — и ни одного подходящего кандидата, даже при конкурентной зарплате. Дефицит ощущался физически: планы запуска продуктов сдвигались, нагрузка на команды росла. С лета 2025 года ситуация изменилась. Крупные компании начали тихие сокращения: официальных объявлений нет, но мидлы с именитым бэкграундом появились на рынке. Параллельно в BigTech заработала механика «банки» — когда проект закрывается, команду не распускают сразу, а дают несколько месяцев на поиск места внутри. Кто не находит — выходит на рынок. Итог: рынок соискателя превратился в рынок работодателя. Вакансии закрываются быстрее, а зарплатная гонка утихает. 47% IT-специалистов называют главным фактором при выборе работы гибкий формат и возможность роста — зарплату ставят на первое место только 18%. Для провайдеров, которые исторически делают ставку на развитие сотрудников, — это сигнал в нужную сторону. Что дальше Рост облачного рынка в России замедляется: 35-40% несколько лет назад, около 29% в 2024 году, прогноз на 2026-й — порядка 24%. При таком замедлении найм тоже будет сжиматься. Компании, которые в период бума набирали людей «с запасом», сейчас пересматривают ФОТ и смотрят, что команды реально делают. Но структурная история с «трубой» никуда не денется — и в этом, пожалуй, главное. Провайдеры продолжат выращивать специалистов снизу, потому что иначе не работает. Готовых инженеров с нужным стеком на рынке не хватало и не будет хватать, особенно с учётом того, что автоматизация убирает начальные позиции и подпитка снизу для всей отрасли постепенно иссякает. На Западе это уже институализировалось: Microsoft запустила Datacenter Academy, AWS строит партнёрства с техническими школами через Workforce Accelerator — провайдеры сами пишут учебные программы, поставляют оборудование для лабораторий, финансируют стипендии. В России этот путь только начинается. Инженер, который вырос в провайдере и ушел к конкуренту или в BigTech, — это не только потеря. Он знает продукт изнутри, иногда рекомендует его клиентам, иногда возвращается. Это другая форма лояльности. И она тоже работает. #IMAGE_235348#]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться в&nbsp;людей, зная, что те&nbsp;уйдут,&nbsp;— и&nbsp;что это говорит о&nbsp;рынке IT-кадров?&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Хороший DevOps-инженер готовится к&nbsp;докладу на&nbsp;конференции&nbsp;— шлифует слайды, прогоняет демо. Он&nbsp;еще не&nbsp;знает, что через два месяца уволится. Не&nbsp;потому что плохо платили или надоело&nbsp;— просто выступил, к&nbsp;нему подошли, предложили больше. Это не&nbsp;провал&nbsp;HR, а&nbsp;нормальная механика рынка, в&nbsp;которой облачные провайдеры играют специфическую роль&nbsp;— они растят специалистов, которых потом хотят все.&lltt;/p&ggtt;
&lltt;h3&ggtt;Рынок сжался&nbsp;— но&nbsp;не&nbsp;для всех&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;2025 году вакансий для айтишников стало на&nbsp;26% меньше, чем годом ранее. Казалось&nbsp;бы, передышка для работодателей. Но&nbsp;облачные провайдеры её&nbsp;не&nbsp;почувствовали: клиентская база росла, крупный бизнес ускорял переход в&nbsp;облако, и&nbsp;спрос на&nbsp;опытных инженеров оставался высоким. По&nbsp;&lltt;a href="https://www.techtarget.com/whatis/feature/Tech-job-market-statistics-and-outlook"&ggtt;данным &lltt;/a&ggtt;TechTarget, 87% технических директоров по-прежнему говорят, что не&nbsp;могут найти нужных специалистов.&lltt;/p&ggtt;
&lltt;p&ggtt;Проблема структурная. Технологические навыки устаревают примерно за&nbsp;2,5&nbsp;года, а&nbsp;университеты обновляют программы куда медленнее. Система подготовки кадров просто не&nbsp;рассчитана на&nbsp;такую скорость изменений&nbsp;— и&nbsp;отрасль давно научилась справляться с&nbsp;этим своими силами.&lltt;/p&ggtt;
&lltt;h3&ggtt;Как устроена карьерная труба&lltt;/h3&ggtt;
&lltt;p&ggtt;В&nbsp;провайдерской среде есть устойчивая модель, которую внутри индустрии неформально называют «трубой». Специалист приходит с&nbsp;минимальными навыками&nbsp;— в&nbsp;техподдержку, на&nbsp;дежурную смену, в&nbsp;администрирование. Работает на&nbsp;больших объемах и&nbsp;разнообразных задачах. Постепенно растёт. Через несколько лет из&nbsp;него получается инженер с&nbsp;реальной экспертизой.&lltt;/p&ggtt;
&lltt;p&ggtt;Если посмотреть на&nbsp;DevOps-инженеров в&nbsp;облачных командах, то&nbsp;9&nbsp;из&nbsp;10&nbsp;— те, кто проросли внутри компании, а&nbsp;не&nbsp;пришли готовыми. Это не&nbsp;случайность и&nbsp;не&nbsp;особенность одного провайдера. Это общая логика отрасли: в&nbsp;отличие от&nbsp;BigTech, где специалист приходит уже сформированным под конкретную задачу, провайдерская среда по&nbsp;природе своей многоуровневая. Здесь есть ступеньки, на&nbsp;которых можно учиться в&nbsp;процессе работы&nbsp;— и&nbsp;это работает.&lltt;/p&ggtt;
&lltt;h3&ggtt;Чем облако привлекает инженера&lltt;/h3&ggtt;
&lltt;p&ggtt;Объяснять выбор в&nbsp;пользу провайдера только деньгами&nbsp;— упрощение. Суть в&nbsp;характере работы.&lltt;/p&ggtt;
&lltt;p&ggtt;DevOps в&nbsp;корпоративном&nbsp;IT обслуживает одну команду, настраивает один пайплайн, работает по&nbsp;гайдам. Задача решена&nbsp;— переключается на&nbsp;следующую, примерно такую&nbsp;же. В&nbsp;облачном провайдере задача другая: не&nbsp;развернуть инфраструктуру для своей команды, а&nbsp;создать сервис, который потом будет предоставляться тысячам клиентов в&nbsp;автоматизированном режиме. Это ближе к&nbsp;разработке, чем к&nbsp;эксплуатации. Другой уровень сложности, другое мышление.&lltt;/p&ggtt;
&lltt;p&ggtt;Именно поэтому опыт из&nbsp;облака ценится на&nbsp;рынке: инженер, проработавший в&nbsp;провайдере, приходит в&nbsp;BigTech с&nbsp;насмотренностью и&nbsp;навыками, которые там сложно получить иначе. Рынок это подтверждает&nbsp;— по&nbsp;&lltt;a href="https://enigmai.ru/salary/devops/devops-salary-2026/"&ggtt;данным&lltt;/a&ggtt; Enigma Intelligence, наиболее востребованными в&nbsp;&lltt;nobr&ggtt;2025-2026&lltt;/nobr&ggtt; годах стали специалисты в&nbsp;Platform Engineering и&nbsp;DevSecOps, то&nbsp;есть именно в&nbsp;том, чем занимаются облачные команды каждый день.&lltt;/p&ggtt;
&lltt;h3&ggtt;Когда специалист уходит&lltt;/h3&ggtt;
&lltt;p&ggtt;Конференции стали обязательной частью профессиональной жизни инженера. Выступить с&nbsp;докладом&nbsp;— значит показать экспертизу, прокачать личный бренд, поделиться опытом с&nbsp;сообществом. Всё это так. Но&nbsp;у&nbsp;этой медали есть обратная сторона: человек всё о&nbsp;себе рассказал, экспертизу показал, контакты на&nbsp;последнем слайде оставил. Хедхантерам остается только подойти после секции.&lltt;/p&ggtt;
&lltt;p&ggtt;Однажды так мы&nbsp;потеряли одного из&nbsp;сильных инженеров: выступил с&nbsp;докладом, познакомился с&nbsp;нужным человеком и&nbsp;через два месяца принял оффер. Обидно? Отчасти. Неожиданно? Нет. Такова механика открытого рынка&nbsp;— и&nbsp;мы&nbsp;сами участвуем в&nbsp;ней с&nbsp;обеих сторон.&lltt;/p&ggtt;
&lltt;p&ggtt;Переходы между провайдерами&nbsp;— обычная история. Специалисты идут туда, где больше объёмы, интереснее задачи, выше зарплата. Это работает в&nbsp;обе стороны. Главное&nbsp;— понимать, что удержать человека силой невозможно, а&nbsp;вот создать среду, из&nbsp;которой не&nbsp;хочется уходить,&nbsp;— вполне.&lltt;/p&ggtt;
&lltt;p&ggtt;К&nbsp;слову, к&nbsp;клиентам инженеры уходят редко&nbsp;— и&nbsp;это не&nbsp;случайно. В&nbsp;облачном провайдинге специалист не&nbsp;привязан к&nbsp;конкретному заказчику: с&nbsp;ним работает команда, контакты ситуативны, личного коннекта, который мог&nbsp;бы перерасти в&nbsp;оффер, почти не&nbsp;возникает. Это механика аутсорс-разработки, не&nbsp;провайдинга.&lltt;/p&ggtt;
&lltt;h3&ggtt;Рынок труда: от&nbsp;голода к&nbsp;насыщению&lltt;/h3&ggtt;
&lltt;p&ggtt;Ещё полтора года назад картина была другой. Вакансия могла висеть полгода&nbsp;— и&nbsp;ни&nbsp;одного подходящего кандидата, даже при конкурентной зарплате. Дефицит ощущался физически: планы запуска продуктов сдвигались, нагрузка на&nbsp;команды росла.&lltt;/p&ggtt;
&lltt;p&ggtt;С&nbsp;лета 2025 года ситуация изменилась. Крупные компании начали тихие сокращения: официальных объявлений нет, но&nbsp;мидлы с&nbsp;именитым бэкграундом появились на&nbsp;рынке. Параллельно в&nbsp;BigTech заработала механика «банки»&nbsp;— когда проект закрывается, команду не&nbsp;распускают сразу, а&nbsp;дают несколько месяцев на&nbsp;поиск места внутри. Кто не&nbsp;находит&nbsp;— выходит на&nbsp;рынок.&lltt;/p&ggtt;
&lltt;p&ggtt;Итог: рынок соискателя превратился в&nbsp;рынок работодателя. Вакансии закрываются быстрее, а&nbsp;зарплатная гонка утихает.&nbsp;47% IT-специалистов &lltt;a href="https://www.newstaff.ru/trendy-najma-it-specialistov-v-2025-godu-chto-menyaetsya-na-rynke/"&ggtt;называют&lltt;/a&ggtt; главным фактором при выборе работы гибкий формат и&nbsp;возможность роста&nbsp;— зарплату ставят на&nbsp;первое место только 18%. Для провайдеров, которые исторически делают ставку на&nbsp;развитие сотрудников,&nbsp;— это сигнал в&nbsp;нужную сторону.&lltt;/p&ggtt;
&lltt;h3&ggtt;Что дальше&lltt;/h3&ggtt;
&lltt;p&ggtt;Рост облачного рынка в&nbsp;России замедляется: &lltt;nobr&ggtt;35-40%&lltt;/nobr&ggtt; несколько лет назад, около&nbsp;29% в&nbsp;2024&nbsp;году, прогноз на&nbsp;&lltt;nobr&ggtt;2026-й —&lltt;/nobr&ggtt; порядка 24%. При таком замедлении найм тоже будет сжиматься. Компании, которые в&nbsp;период бума набирали людей «с&nbsp;запасом», сейчас пересматривают ФОТ и&nbsp;смотрят, что команды реально делают.&lltt;/p&ggtt;
&lltt;p&ggtt;Но&nbsp;структурная история с&nbsp;«трубой» никуда не&nbsp;денется&nbsp;— и&nbsp;в&nbsp;этом, пожалуй, главное. Провайдеры продолжат выращивать специалистов снизу, потому что иначе не&nbsp;работает. Готовых инженеров с&nbsp;нужным стеком на&nbsp;рынке не&nbsp;хватало и&nbsp;не&nbsp;будет хватать, особенно с&nbsp;учётом того, что автоматизация убирает начальные позиции и&nbsp;подпитка снизу для всей отрасли постепенно иссякает.&lltt;/p&ggtt;
&lltt;p&ggtt;На&nbsp;Западе это уже институализировалось: Microsoft запустила Datacenter Academy, AWS строит партнёрства с&nbsp;техническими школами через Workforce Accelerator&nbsp;— провайдеры сами пишут учебные программы, поставляют оборудование для лабораторий, финансируют стипендии. В&nbsp;России этот путь только начинается.&lltt;/p&ggtt;
&lltt;p&ggtt;Инженер, который вырос в&nbsp;провайдере и&nbsp;ушел к&nbsp;конкуренту или в&nbsp;BigTech,&nbsp;— это не&nbsp;только потеря. Он&nbsp;знает продукт изнутри, иногда рекомендует его клиентам, иногда возвращается. Это другая форма лояльности. И&nbsp;она тоже работает.&lltt;/p&ggtt;
&lltt;p&ggtt;#IMAGE_235348#&lltt;/p&ggtt;]]></source>
<adate>14.08.2026</adate>
<dbid>235347</dbid>
<rubric>8</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/d30/l9yw6f3ukd5bd4cr2asxg1i78jxmdr0y.jpg]]>
</images>
<imagesname><![CDATA[;;Сергей Рыжков, руководитель онлайн-продаж и аналитики Рег.облака   ]]></imagesname>
<tag><![CDATA[ИТ-индустрия]]></tag>
</item>
<item>
<title><![CDATA[Forrester: масштабирование агентных ERP-систем требует широкого корпоративного контроля]]></title>
<link><![CDATA[https://www.itweek.ru/themes/detail.php?ID=235345]]></link>
<description><![CDATA[Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» задачу, но реальным ограничением для их внедрения станет корпоративный контроль — смогут ли технологические руководители проверять действия агентов, управлять их использованием и сохранять бизнес-смысл в условиях фрагментации, пишет в корпоративном блоге Фарам Медхора, главный аналитик Forrester. Фрагментация — это реальность работы ERP-систем: согласно исследованию Forrester «Enterprise Applications Software Survey 2026», только 7% лиц, принимающих решения по ERP на предприятиях, используют только один экземпляр системы. В сложной многоэкземплярной инфраструктуре агенты будут наследовать региональные варианты, приобретенные системы и противоречивые определения, что выявит недостатки управления, которые технологические руководители могли терпеть во времена, когда автоматизация оставалась под контролем человека. Если технологические руководители хотят начать пожинать плоды агентных ERP-систем, им не стоит начинать с каталога агентов. Вместо этого им следует начать с модели управления, чтобы понять, насколько они смогут подтвердить, оценить и защитить автономность с помощью переносимости. #IMAGE_235346# Контроль за доказательствами: верификация — это новый скоростной лимит ERP Агентная ERP создает проблему контроля. Каждое действие агента требует подтверждения: кто его одобрил, какая учетная запись его выполнила, какие данные были использованы и кто несет ответственность за результаты, когда действия агента достигают этапов проводок, сверки или закрытия. Эта проблема контроля затрагивает наиболее уязвимые места в большинстве ERP-систем: управление данными, контроль и безопасность. Согласно нашим данным, 65% пользователей ERP оценивают точность данных как сложную проблему, и 64% говорят то же самое о безопасности и соответствии нормативным требованиям. Риски уже очевидны. Уязвимость BodySnatcher (CVE-2025-12420) показала, как некорректная аутентификация агентов может позволить осуществлять привилегированное подмену личности в ServiceNow, а дело Moffatt против Air Canada (2024) подтвердило, что компании (а не поставщик) остаются ответственными за предоставленную ИИ информацию о клиентах. Агентную ERP-систему следует рассматривать в первую очередь с точки зрения обеспечения контроля, а во вторую — с точки зрения автоматизации. Сегментируйте автономность по классам транзакций: расширяйте возможности консультативных агентов сейчас, требуйте полной отслеживаемости для контролируемого выполнения и откладывайте автономное выполнение до тех пор, пока команды не смогут доказать ответственность за исключения, предоставить аудиторские доказательства и возможность отката. Для этого вам потребуется перейти к стандартизированному ядру, которое вы откладывали, поскольку агенты будут усиливать вариативность процессов, данных и контроля. Вам также потребуется сначала провести каждого кандидата на автоматизацию через стандартизацию, и если вы не можете его стандартизировать, это означает, что вы не можете его безопасно автоматизировать. Контроль за ценой: счетчик — это новый контроль объема работ Ценообразование ERP-систем движется в сторону моделей, основанных на использовании, кредитных пулах и многоуровневых счетчиках. Это переносит риск с прайс-листа поставщика на ваш текущий тариф. Большинство CIO по-прежнему договариваются о продлении как о фиксированных затратах, но эта привычка устареет по мере роста использования агентов. Как только агенты начнут применяться в повседневной работе, использование может превысить бюджетные рамки. Фактически, 30% руководителей, принимающих решения в сфере корпоративного SaaS, уже отмечают непредсказуемость ценообразования на основе использования как проблему. Мы уже видим, как контроль дает сбой. Uber исчерпала свой бюджет на ИИ за несколько месяцев после того, как применение Claude Code широко распространилось среди инженеров. Salesforce учитывает использование Agentforce через Flex Credits с учетом превышения лимитов. Покупатели RISE with SAP колеблются, когда не могут самостоятельно отслеживать лицензирование и использование. Это означает, что технологические руководители никогда не должны подписывать соглашения об использовании агентной ERP без телеметрии со стороны покупателя, жестких ограничений, триггеров превышения лимитов и сценариев потребления, смоделированных финансовыми специалистами. Помните, если поставщик контролирует и счетчик, и интерпретацию показаний счетчика, вы не контролируете программу. Контроль за переносимостью: следующая проблема привязки к поставщику — семантическая Перенос ваших данных к новому поставщику больше не является трудной задачей. Трудность заключается в том, чтобы разобраться, как старый поставщик определял ваш бизнес. Если ваши KPI, бизнес-сущности и связи данных построены вокруг модели одного поставщика, вы остаетесь привязанными к нему даже после миграции данных. Это то, что мы называем семантической зависимостью. Открытые стандарты, такие как MCP и Agent2Agent, которые могут снизить барьеры для подключения, теперь развиваются под эгидой Linux Foundation, но этого недостаточно (даже близко) для обеспечения переносимости сути бизнеса. Технологическим лидерам необходимо ознакомиться с новым термином: семантическая переносимость. В дальнейшем вам нужно будет включать семантическую переносимость в каждое продление контракта. Это означает требование прав на экспорт определений KPI, моделей сущностей и связей основных данных, прежде чем вы будете добавлять больше интеллектуальных функций в контекстный слой поставщика. Это крайне важно, потому что то, что вы не можете экспортировать сегодня, завтра станет вашей стоимостью перехода. Масштабируйте операционную модель до развертывания агентов Наиболее эффективные CIO не будут гнаться за самым эффектным помощником. Они сначала определят ответственность: кто утверждает агентов, кто отвечает за ожидания, кто контролирует бюджеты потребления и кто управляет семантикой. Именно с этой моделью будут работать ваши финансовые директора, аудиторы и клиенты]]></description>
<source><![CDATA[&lltt;p&ggtt;&lltt;em&ggtt;Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» задачу, но&nbsp;реальным ограничением для их&nbsp;внедрения станет корпоративный контроль&nbsp;— смогут&nbsp;ли технологические руководители проверять действия агентов, управлять их&nbsp;использованием и&nbsp;сохранять бизнес-смысл в&nbsp;условиях фрагментации, пишет в&nbsp;корпоративном блоге Фарам Медхора, главный аналитик &lltt;/em&ggtt;&lltt;em&ggtt;Forrester&lltt;/em&ggtt;&lltt;em&ggtt;.&lltt;/em&ggtt;&lltt;/p&ggtt;
&lltt;p&ggtt;Фрагментация&nbsp;— это реальность работы ERP-систем: согласно исследованию Forrester «Enterprise Applications Software Survey 2026», только&nbsp;7% лиц, принимающих решения по&nbsp;ERP на&nbsp;предприятиях, используют только один экземпляр системы. В&nbsp;сложной многоэкземплярной инфраструктуре агенты будут наследовать региональные варианты, приобретенные системы и&nbsp;противоречивые определения, что выявит недостатки управления, которые технологические руководители могли терпеть во&nbsp;времена, когда автоматизация оставалась под контролем человека.&lltt;/p&ggtt;
&lltt;p&ggtt;Если технологические руководители хотят начать пожинать плоды агентных ERP-систем, им&nbsp;не&nbsp;стоит начинать с&nbsp;каталога агентов. Вместо этого им&nbsp;следует начать с&nbsp;модели управления, чтобы понять, насколько они смогут подтвердить, оценить и&nbsp;защитить автономность с&nbsp;помощью переносимости.&lltt;/p&ggtt;
&lltt;p&ggtt; #IMAGE_235346#&lltt;/p&ggtt;
&lltt;h3&ggtt;Контроль за&nbsp;доказательствами: верификация&nbsp;— это новый скоростной лимит ERP&lltt;/h3&ggtt;
&lltt;p&ggtt;Агентная ERP создает проблему контроля. Каждое действие агента требует подтверждения: кто его одобрил, какая учетная запись его выполнила, какие данные были использованы и&nbsp;кто несет ответственность за&nbsp;результаты, когда действия агента достигают этапов проводок, сверки или закрытия.&lltt;/p&ggtt;
&lltt;p&ggtt;Эта проблема контроля затрагивает наиболее уязвимые места в&nbsp;большинстве ERP-систем: управление данными, контроль и&nbsp;безопасность. Согласно нашим данным, 65% пользователей ERP оценивают точность данных как сложную проблему, и&nbsp;64% говорят то&nbsp;же самое о&nbsp;безопасности и&nbsp;соответствии нормативным требованиям. Риски уже очевидны. Уязвимость BodySnatcher (CVE-2025-12420) показала, как некорректная аутентификация агентов может позволить осуществлять привилегированное подмену личности в&nbsp;ServiceNow, а&nbsp;дело Moffatt против Air Canada (2024) подтвердило, что компании (а&nbsp;не&nbsp;поставщик) остаются ответственными за&nbsp;предоставленную&nbsp;ИИ информацию о&nbsp;клиентах.&lltt;/p&ggtt;
&lltt;p&ggtt;Агентную ERP-систему следует рассматривать в&nbsp;первую очередь с&nbsp;точки зрения обеспечения контроля, а&nbsp;во&nbsp;вторую&nbsp;— с&nbsp;точки зрения автоматизации. Сегментируйте автономность по&nbsp;классам транзакций: расширяйте возможности консультативных агентов сейчас, требуйте полной отслеживаемости для контролируемого выполнения и&nbsp;откладывайте автономное выполнение до&nbsp;тех пор, пока команды не&nbsp;смогут доказать ответственность за&nbsp;исключения, предоставить аудиторские доказательства и&nbsp;возможность отката.&lltt;/p&ggtt;
&lltt;p&ggtt;Для этого вам потребуется перейти к&nbsp;стандартизированному ядру, которое вы&nbsp;откладывали, поскольку агенты будут усиливать вариативность процессов, данных и&nbsp;контроля. Вам также потребуется сначала провести каждого кандидата на&nbsp;автоматизацию через стандартизацию, и&nbsp;если вы&nbsp;не&nbsp;можете его стандартизировать, это означает, что вы&nbsp;не&nbsp;можете его безопасно автоматизировать.&lltt;/p&ggtt;
&lltt;h3&ggtt;Контроль за&nbsp;ценой: счетчик&nbsp;— это новый контроль объема работ&lltt;/h3&ggtt;
&lltt;p&ggtt;Ценообразование ERP-систем движется в&nbsp;сторону моделей, основанных на&nbsp;использовании, кредитных пулах и&nbsp;многоуровневых счетчиках. Это переносит риск с&nbsp;прайс-листа поставщика на&nbsp;ваш текущий тариф. Большинство CIO по-прежнему договариваются о&nbsp;продлении как о&nbsp;фиксированных затратах, но&nbsp;эта привычка устареет по&nbsp;мере роста использования агентов. Как только агенты начнут применяться в&nbsp;повседневной работе, использование может превысить бюджетные рамки. Фактически, 30% руководителей, принимающих решения в&nbsp;сфере корпоративного SaaS, уже отмечают непредсказуемость ценообразования на&nbsp;основе использования как проблему.&lltt;/p&ggtt;
&lltt;p&ggtt;Мы&nbsp;уже видим, как контроль дает сбой. Uber исчерпала свой бюджет на&nbsp;ИИ за&nbsp;несколько месяцев после того, как применение Claude Code широко распространилось среди инженеров. Salesforce учитывает использование Agentforce через Flex Credits с&nbsp;учетом превышения лимитов. Покупатели RISE with SAP колеблются, когда не&nbsp;могут самостоятельно отслеживать лицензирование и&nbsp;использование.&lltt;/p&ggtt;
&lltt;p&ggtt;Это означает, что технологические руководители никогда не&nbsp;должны подписывать соглашения об&nbsp;использовании агентной ERP без телеметрии со&nbsp;стороны покупателя, жестких ограничений, триггеров превышения лимитов и&nbsp;сценариев потребления, смоделированных финансовыми специалистами. Помните, если поставщик контролирует и&nbsp;счетчик, и&nbsp;интерпретацию показаний счетчика, вы&nbsp;не&nbsp;контролируете программу.&lltt;/p&ggtt;
&lltt;h3&ggtt;Контроль за&nbsp;переносимостью: следующая проблема привязки к&nbsp;поставщику&nbsp;— семантическая&lltt;/h3&ggtt;
&lltt;p&ggtt;Перенос ваших данных к&nbsp;новому поставщику больше не&nbsp;является трудной задачей. Трудность заключается в&nbsp;том, чтобы разобраться, как старый поставщик определял ваш бизнес. Если ваши KPI, бизнес-сущности и&nbsp;связи данных построены вокруг модели одного поставщика, вы&nbsp;остаетесь привязанными к&nbsp;нему даже после миграции данных. Это&nbsp;то, что мы&nbsp;называем семантической зависимостью. Открытые стандарты, такие как MCP и&nbsp;Agent2Agent, которые могут снизить барьеры для подключения, теперь развиваются под эгидой Linux Foundation, но&nbsp;этого недостаточно (даже близко) для обеспечения переносимости сути бизнеса.&lltt;/p&ggtt;
&lltt;p&ggtt;Технологическим лидерам необходимо ознакомиться с&nbsp;новым термином: семантическая переносимость. В&nbsp;дальнейшем вам нужно будет включать семантическую переносимость в&nbsp;каждое продление контракта. Это означает требование прав на&nbsp;экспорт определений KPI, моделей сущностей и&nbsp;связей основных данных, прежде чем вы&nbsp;будете добавлять больше интеллектуальных функций в&nbsp;контекстный слой поставщика. Это крайне важно, потому что&nbsp;то, что вы&nbsp;не&nbsp;можете экспортировать сегодня, завтра станет вашей стоимостью перехода.&lltt;/p&ggtt;
&lltt;h3&ggtt;Масштабируйте операционную модель до&nbsp;развертывания агентов&lltt;/h3&ggtt;
&lltt;p&ggtt;Наиболее эффективные CIO не&nbsp;будут гнаться за&nbsp;самым эффектным помощником. Они сначала определят ответственность: кто утверждает агентов, кто отвечает за&nbsp;ожидания, кто контролирует бюджеты потребления и&nbsp;кто управляет семантикой. Именно с&nbsp;этой моделью будут работать ваши финансовые директора, аудиторы и&nbsp;клиенты.&lltt;/p&ggtt;]]></source>
<adate>14.08.2026</adate>
<dbid>235345</dbid>
<rubric>7</rubric>
<orubric>13725</orubric>
<images><![CDATA[;;https://www.itweek.ru/upload/iblock/c3b/s1w8sfd11zzra64llpzud3qgvdprqnb8.jpg]]>
</images>
<imagesname><![CDATA[;;Источник: Forrester   ]]></imagesname>
<tag><![CDATA[ИТ-менеджмент;;Искусственный интеллект;;Идеи и практики автоматизации]]></tag>
</item>
<item>
<title><![CDATA[Решение по автоматизации процесса управления актами о несоответствии и браке на производственном предприятии]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=164339]]></link>
<description><![CDATA[ В начале 2013 года на производственном объединении &#171;Элтехника&#187; (Санкт-Петербург) завершился проект автоматизации процесса управления качеством продукции, выполненный на базе Docsvision. В рамках проекта компания «Системная Экспертиза» &#8212; сертифицированный партнер Docsvision, провела анализ и предложила решение по автоматизации процесса управления актами о несоответствии и браке, которое и было реализовано в кратчайшие сроки. На предприятии система используется для автоматизации процессов делопроизводства, согласования договоров, а также для решения специфических для бизнеса задач, например, таких как управление документооборотом, связанным с заказами клиентов (с момента возникновения заявки до отгрузки продукции по заказу). ]]></description>
<source><![CDATA[
&lltt;p&ggtt;В&nbsp;начале 2013 года на&nbsp;производственном объединении &laquo;Элтехника&raquo; (Санкт-Петербург) завершился проект автоматизации процесса управления качеством продукции, выполненный на&nbsp;базе Docsvision. В&nbsp;рамках проекта компания «Системная Экспертиза»&nbsp;&mdash; сертифицированный партнер Docsvision, провела анализ и&nbsp;предложила решение по&nbsp;автоматизации процесса управления актами о&nbsp;несоответствии и&nbsp;браке, которое и&nbsp;было реализовано в&nbsp;кратчайшие сроки. На&nbsp;предприятии система используется для автоматизации процессов делопроизводства, согласования договоров, а&nbsp;также для решения специфических для бизнеса задач, например, таких как управление документооборотом, связанным с&nbsp;заказами клиентов (с&nbsp;момента возникновения заявки до&nbsp;отгрузки продукции по&nbsp;заказу).&lltt;/p&ggtt;
]]></source>
<adate>19.06.2014</adate>
<dbid>164339</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Масштабное внедрение Docsvision в мэрии города Ярославля]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=164036]]></link>
<description><![CDATA[ Мэрия города Ярославля и все ее структурные подразделения успешно работают в единой системе электронного документооборота более 2-х лет, и более 1,5 лет (на начало 2014 г.) бесперебойно работает автоматизированная система документообмена между структурными подразделениями правительства Ярославской области и мэрии. Проект стал ещё одним успешным примером реализации межведомственного электронного взаимодействия. Внедрение Docsvision в мэрии города Ярославля успешно реализовано компанией &#171;Проф-Консалтинг&#187; &#8212; ярославским партнером Docsvision. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Мэрия города Ярославля и&nbsp;все ее&nbsp;структурные подразделения успешно работают в&nbsp;единой системе электронного документооборота более &lltt;nobr&ggtt;2-х&lltt;/nobr&ggtt; лет, и&nbsp;более 1,5 лет (на&nbsp;начало 2014&nbsp;г.) бесперебойно работает автоматизированная система документообмена между структурными подразделениями правительства Ярославской области и&nbsp;мэрии. Проект стал ещё одним успешным примером реализации межведомственного электронного взаимодействия. Внедрение Docsvision в&nbsp;мэрии города Ярославля успешно реализовано компанией &laquo;Проф-Консалтинг&raquo;&nbsp;&mdash; ярославским партнером Docsvision. &lltt;/p&ggtt;
]]></source>
<adate>05.06.2014</adate>
<dbid>164036</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Автоматизация деятельности медицинских учреждений: универсальное масштабируемое решение Kraftway]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=132537]]></link>
<description><![CDATA[ Универсальное защищенное масштабируемое решение Kraftway основано на использовании модульной системы на базе blade-комплекса, размещаемого в вандалозащищенном шумопоглощающем шкафу, а также тонкого клиента собственной разработки Kraftway и PACS-станции для обработки цифровых изображений, получаемых с медицинских диагоностических комплексов. Особенностью решения является наличие в аппаратных компонентах системы встроенных модулей безопасности от компании &#171;Аладдин Р.Д.&#187;, которые тесно интегрированы с BIOS и предназначены для выполнения функций аппаратно-программного модуля доверенной загрузки (АПМДЗ). Созданный Kraftway программно-аппаратный комплекс позволяет автоматизировать все этапы оказания медицинской помощи и оптимизировать работу всех подразделений ЛПУ независимо от профиля медучреждения. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Универсальное защищенное масштабируемое решение Kraftway основано на использовании модульной системы на базе blade-комплекса, размещаемого в вандалозащищенном шумопоглощающем шкафу, а также тонкого клиента собственной разработки Kraftway и PACS-станции для обработки цифровых изображений, получаемых с медицинских диагоностических комплексов. Особенностью решения является наличие в аппаратных компонентах системы встроенных модулей безопасности от компании &laquo;Аладдин Р.Д.&raquo;, которые тесно интегрированы с BIOS и предназначены для выполнения функций аппаратно-программного модуля доверенной загрузки (АПМДЗ). Созданный Kraftway программно-аппаратный комплекс позволяет автоматизировать все этапы оказания медицинской помощи и оптимизировать работу всех подразделений ЛПУ независимо от профиля медучреждения.&lltt;/p&ggtt;
 ]]></source>
<adate>11.07.2011</adate>
<dbid>132537</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Создание системы управления персоналом в ЗАО «Корпорация «Гринн»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=118257]]></link>
<description><![CDATA[В курской корпорации «ГРИНН» успешно и в срок завершен проект создания единой системы управления персоналом. Были достигнуты главные цели проекта: заложен фундамент единой кадровой политики компании, создано решение по управлению персоналом, соответствующее масштабам и темпам развития бизнеса корпорации]]></description>
<source><![CDATA[В курской корпорации «ГРИНН» успешно и в срок завершен проект создания единой системы управления персоналом. Были достигнуты главные цели проекта: заложен фундамент единой кадровой политики компании, создано решение по управлению персоналом, соответствующее масштабам и темпам развития бизнеса корпорации.]]></source>
<adate>19.03.2009</adate>
<dbid>118257</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Система ALFA: новое качество управления производством]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=117231]]></link>
<description><![CDATA[Основной фактор, определяющий спрос на услуги ИТ-консалтинга со стороны промышленного сектора, это необходимость повышения эффективности производства и оптимизация затрат на него. Для достижения этих целей наиболее востребованным инструментом является специализированное программное обеспечение, которое позволяет реализовать задачи планирования ресурсов предприятия на разных уровнях, оперативной корректировки и контроля исполнения планов производства и расхода ресурсов]]></description>
<source><![CDATA[Основной фактор, определяющий спрос на услуги ИТ-консалтинга со стороны промышленного сектора, это необходимость повышения эффективности производства и оптимизация затрат на него. Для достижения этих целей наиболее востребованным инструментом является специализированное программное обеспечение, которое позволяет реализовать задачи планирования ресурсов предприятия на разных уровнях, оперативной корректировки и контроля исполнения планов производства и расхода ресурсов.]]></source>
<adate>15.01.2009</adate>
<dbid>117231</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Переосмысление рабочего места в современных реалиях]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=222552]]></link>
<description><![CDATA[COVID-19: влияние на работников по всему миру. Переход бизнеса к гибридному офису. «Новая норма» порождает вызовы для ИТ-служб]]></description>
<source><![CDATA[&lltt;p&ggtt;COVID-19: влияние на&nbsp;работников по&nbsp;всему миру. Переход бизнеса к&nbsp;гибридному офису.&lltt;/p&ggtt;
&lltt;p&ggtt;«Новая норма» порождает вызовы для ИТ-служб.&lltt;/p&ggtt;]]></source>
<adate>18.02.2022</adate>
<dbid>222552</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Гибридный офис с платформой Aruba ESP]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=222553]]></link>
<description><![CDATA[«Мгновенный» переход на удалённую работу. Рост устройств &#8594; вопросы подключения, управления и безопасности. «Растянутость» ИТ ресурсов. Новая парадигма утилизации офиса и взаимодействия сотрудников]]></description>
<source><![CDATA[&lltt;p&ggtt;«Мгновенный» переход на&nbsp;удалённую работу. Рост устройств &#8594; вопросы подключения, управления и&nbsp;безопасности. «Растянутость» ИТ&nbsp;ресурсов.&lltt;/p&ggtt;
&lltt;p&ggtt;Новая парадигма утилизации офиса и&nbsp;взаимодействия сотрудников.&lltt;/p&ggtt;]]></source>
<adate>18.02.2022</adate>
<dbid>222553</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Чем помогут интеллектуальные механизмы при электронном документообороте с контрагентами?]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=210944]]></link>
<description><![CDATA[С каждым годом количество компаний, перешедших на обмен юридически значимыми документами в электронном виде, активно растет. К 2024 году государство планирует обеспечить условия для проведения большинства сделок в электронном виде. Обмениваться в электронном виде можно как структурированными, так и неструктурированными документами. Для автоматизации работы с последними требуется использовать инструменты для распознавания текста документа и получения структурированных данных на стороне получателя. Заканчиваются ли возможности применения интеллектуальных инструментов на распознавании неструктурированных документов? Ответ вы найдете в статье]]></description>
<source><![CDATA[&lltt;p&ggtt;С&nbsp;каждым годом количество компаний, перешедших на&nbsp;обмен юридически значимыми документами в&nbsp;электронном виде, активно растет. К&nbsp;2024 году государство планирует обеспечить условия для проведения большинства сделок в&nbsp;электронном виде. &lltt;/p&ggtt;
&lltt;p&ggtt;Обмениваться в&nbsp;электронном виде можно как структурированными, так и&nbsp;неструктурированными документами. Для автоматизации работы с&nbsp;последними требуется использовать инструменты для распознавания текста документа и&nbsp;получения структурированных данных на&nbsp;стороне получателя. &lltt;/p&ggtt;
&lltt;p&ggtt; Заканчиваются&nbsp;ли возможности применения интеллектуальных инструментов на&nbsp;распознавании неструктурированных документов? Ответ вы&nbsp;найдете в&nbsp;статье.&lltt;/p&ggtt;]]></source>
<adate>25.12.2019</adate>
<dbid>210944</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Электронный обмен первичными учетными документами. Опыт сети магазинов косметики «Подружка»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=210943]]></link>
<description><![CDATA[Розничная сеть «Подружка» насчитывает более 230 мультибрендовых магазинов косметики, парфюмерии и полезных мелочей в разных регионах России. Специфика работы торговой сети подразумевает взаимодействие с сотнями поставщиков. Масштабы документооборота впечатляющие, и минимизировать издержки помог переход на электронное взаимодействие с контрагентами через сервисы обмена. Так как контрагенты работают с разными операторами ЭДО, торговая сеть подключились сразу к нескольким сервисам обмена. На первом этапе проекта специалисты DIRECTUM оптимизировали работу с нетоварными первичными учетными документами. Второй этап охватил товарные документы. Больше деталей проекта — в статье]]></description>
<source><![CDATA[&lltt;p&ggtt;Розничная сеть «Подружка» насчитывает более 230 мультибрендовых магазинов косметики, парфюмерии и&nbsp;полезных мелочей в&nbsp;разных регионах России. Специфика работы торговой сети подразумевает взаимодействие с&nbsp;сотнями поставщиков. Масштабы документооборота впечатляющие, и&nbsp;минимизировать издержки помог переход на&nbsp;электронное взаимодействие с&nbsp;контрагентами через сервисы обмена. &lltt;/p&ggtt;
&lltt;p&ggtt;Так как контрагенты работают с&nbsp;разными операторами ЭДО, торговая сеть подключились сразу к&nbsp;нескольким сервисам обмена. На&nbsp;первом этапе проекта специалисты DIRECTUM оптимизировали работу с&nbsp;нетоварными первичными учетными документами. Второй этап охватил товарные документы. Больше деталей проекта&nbsp;— в&nbsp;статье.&lltt;/p&ggtt;]]></source>
<adate>25.12.2019</adate>
<dbid>210943</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[5 советов, как безболезненно перейти на юридически значимый электронный документооборот с контрагентами]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=210942]]></link>
<description><![CDATA[Допустим, в вашей организации уже используется система электронного документооборота. Следующий шаг — отказаться от бумаги во взаимодействии с контрагентами. Но как сделать так, чтобы «акклиматизация» к новым условиям работы прошла благополучно? Какой политики придерживаться, чтобы деловые партнеры восприняли перспективу электронного взаимодействия как точку роста для собственного бизнеса? В статье опишем 5 советов, как безболезненно перейти на юридически значимый электронный документооборот с вашими контрагентами, пусть даже их несколько тысяч. Советами делятся эксперты сервиса Synerdocs (разработчик — компания DIRECTUM), за плечами которых десятки тысяч подключенных к ЭДО пользователей]]></description>
<source><![CDATA[&lltt;p&ggtt;Допустим, в&nbsp;вашей организации уже используется система электронного документооборота. Следующий шаг&nbsp;— отказаться от&nbsp;бумаги во&nbsp;взаимодействии с&nbsp;контрагентами. Но&nbsp;как сделать так, чтобы «акклиматизация» к&nbsp;новым условиям работы прошла благополучно? Какой политики придерживаться, чтобы деловые партнеры восприняли перспективу электронного взаимодействия как точку роста для собственного бизнеса?&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;статье опишем 5&nbsp;советов, как безболезненно перейти на&nbsp;юридически значимый электронный документооборот с&nbsp;вашими контрагентами, пусть даже их&nbsp;несколько тысяч. Советами делятся эксперты сервиса Synerdocs (разработчик&nbsp;— компания DIRECTUM), за&nbsp;плечами которых десятки тысяч подключенных к&nbsp;ЭДО пользователей.&lltt;/p&ggtt;]]></source>
<adate>25.12.2019</adate>
<dbid>210942</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Электронный документооборот с контрагентами: с чего начать?]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=210941]]></link>
<description><![CDATA[На начальном этапе внедрения ЭДО невозможно настроить юридически значимый обмен сразу всеми видами документов (первичкой, договорами, отраслевыми документами) и подключить всех контрагентов. Поэтому приходится переходить на электронный документооборот постепенно, начав с одного бизнес-процесса и планомерно захватывая другие. С каких документов лучше запускать электронный обмен: актов, счетов-фактур или договоров? Каких контрагентов подключить к ЭДО в первую очередь? В статье мы перечислили рекомендации, которые помогут вам пошагово перейти на электронный документооборот с контрагентами]]></description>
<source><![CDATA[&lltt;p&ggtt;На&nbsp;начальном этапе внедрения ЭДО невозможно настроить юридически значимый обмен сразу всеми видами документов (первичкой, договорами, отраслевыми документами) и&nbsp;подключить всех контрагентов. Поэтому приходится переходить на&nbsp;электронный документооборот постепенно, начав с&nbsp;одного бизнес-процесса и&nbsp;планомерно захватывая другие. &lltt;/p&ggtt;
&lltt;p&ggtt;С&nbsp;каких документов лучше запускать электронный обмен: актов, счетов-фактур или договоров? Каких контрагентов подключить к&nbsp;ЭДО в&nbsp;первую очередь? В&nbsp;статье мы&nbsp;перечислили рекомендации, которые помогут вам пошагово перейти на&nbsp;электронный документооборот с&nbsp;контрагентами.&lltt;/p&ggtt;]]></source>
<adate>25.12.2019</adate>
<dbid>210941</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Чек-лист по выбору СЭД: 5 требований]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=210940]]></link>
<description><![CDATA[Обмен электронными документами с контрагентами — тренд, который продиктован реалиями современного бизнеса. Идеальный электронный документооборот (ЭДО) подразумевает максимальную автоматизацию на всех этапах работы с документами — от создания, согласования и подписания до обмена с контрагентами. Совершенная схема ЭДО предполагает связку: учетная система + система электронного документооборота (СЭД) + сервис обмена документами. С помощью каких механизмов СЭД может максимально исключить участие человека в обработке документов? Какой должна быть система для удобства руководителя компании? Об этих и других требованиях вы узнаете в статье]]></description>
<source><![CDATA[&lltt;p&ggtt;Обмен электронными документами с&nbsp;контрагентами&nbsp;— тренд, который продиктован реалиями современного бизнеса. Идеальный электронный документооборот (ЭДО) подразумевает максимальную автоматизацию на&nbsp;всех этапах работы с&nbsp;документами&nbsp;— от&nbsp;создания, согласования и&nbsp;подписания до&nbsp;обмена с&nbsp;контрагентами.&lltt;/p&ggtt;
&lltt;p&ggtt;Совершенная схема ЭДО предполагает связку: учетная система + система электронного документооборота (СЭД) + сервис обмена документами. &lltt;/p&ggtt;
&lltt;p&ggtt;С&nbsp;помощью каких механизмов СЭД может максимально исключить участие человека в&nbsp;обработке документов? Какой должна быть система для удобства руководителя компании? Об&nbsp;этих и&nbsp;других требованиях вы&nbsp;узнаете в&nbsp;статье.&lltt;/p&ggtt;]]></source>
<adate>25.12.2019</adate>
<dbid>210940</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Движущие факторы и преимущества периферийных вычислений]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=207896]]></link>
<description><![CDATA[Основными трендами развития интернета сегодня являются: увеличение объемов передаваемого контента и рост количества подключенных «вещей». В то же время, мобильные и телекоммуникационные сети движутся в сторону «облачных» вычислений. Для реализации текущих и будущих потребностей, вычислительные мощности и средства хранения данных «помещены» на периферию/границу сети для того, чтобы снизить время на передачу данных и увеличить их доступность. Периферийные вычисления переносят данные, требующие высокой пропускной способности канала передачи данных, чувствительные к задержке, ближе к пользователю или источнику данных. В информационной статье описываются факторы развития периферийных вычислений, исследуются различные типы доступных периферийных вычислений]]></description>
<source><![CDATA[&lltt;p&ggtt;Основными трендами развития интернета сегодня являются: увеличение объемов передаваемого контента и&nbsp;рост количества подключенных «вещей». В&nbsp;то&nbsp;же время, мобильные и&nbsp;телекоммуникационные сети движутся в&nbsp;сторону «облачных» вычислений. Для реализации текущих и&nbsp;будущих потребностей, вычислительные мощности и&nbsp;средства хранения данных «помещены» на&nbsp;периферию/границу сети для того, чтобы снизить время на&nbsp;передачу данных и&nbsp;увеличить их&nbsp;доступность. Периферийные вычисления переносят данные, требующие высокой пропускной способности канала передачи данных, чувствительные к&nbsp;задержке, ближе к&nbsp;пользователю или источнику данных. В&nbsp;информационной статье описываются факторы развития периферийных вычислений, исследуются различные типы доступных периферийных вычислений.&lltt;/p&ggtt;]]></source>
<adate>12.11.2019</adate>
<dbid>207896</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Решение проблем периферийных вычислений (Edge computing) с помощью интегрированной экосистемы. Новая информационная статья Schneider Electric]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=209620]]></link>
<description><![CDATA[Цифровые технологии приобретают все большее значение в современном мире. Для того чтобы обеспечить достаточно высокий уровень вычислительных мощностей, широкие возможности подключения и доступность ресурсов в любом месте, необходима гибридная архитектура, включающая периферийные ЦОДы. Чтобы помочь профессионалам в сфере ИТ в разработке стратегии развертывания периферийных вычислений (Edge computing), компания Schneider Electric, мировой эксперт в области проектирования и строительства центров обработки данных, выпустила новую Информационную статью № 277 «Решение задач в сфере инфраструктуры периферийных вычислений». В документе представлена система профилактики потенциальных проблем на периферии, а также приведены рекомендации по формированию экосистемы партнеров, сотрудничество с которыми позволит интегрировать и запустить все необходимые инфраструктурные компоненты]]></description>
<source><![CDATA[&lltt;p&ggtt;Цифровые технологии приобретают все большее значение в&nbsp;современном мире. Для того чтобы обеспечить достаточно высокий уровень вычислительных мощностей, широкие возможности подключения и&nbsp;доступность ресурсов в&nbsp;любом месте, необходима гибридная архитектура, включающая периферийные ЦОДы.&lltt;/p&ggtt;
&lltt;p&ggtt;Чтобы помочь профессионалам в&nbsp;сфере&nbsp;ИТ в&nbsp;разработке стратегии развертывания периферийных вычислений (Edge computing), компания Schneider Electric, мировой эксперт в&nbsp;области проектирования и&nbsp;строительства центров обработки данных, выпустила новую Информационную статью №&nbsp;277 «Решение задач в&nbsp;сфере инфраструктуры периферийных вычислений».&lltt;/p&ggtt;
&lltt;p&ggtt;В&nbsp;документе представлена система профилактики потенциальных проблем на&nbsp;периферии, а&nbsp;также приведены рекомендации по&nbsp;формированию экосистемы партнеров, сотрудничество с&nbsp;которыми позволит интегрировать и&nbsp;запустить все необходимые инфраструктурные компоненты.&lltt;/p&ggtt;]]></source>
<adate>12.11.2019</adate>
<dbid>209620</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Миграция с VMware на OpenStack с минимальным даунтаймом]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=196630]]></link>
<description><![CDATA[ Опытные ИТ-руководители понимают: если корпоративная инфраструктура или ее часть выйдет из строя, большинство бизнес-процессов остановится. Но выделить бюджет на приобретение сервиса Disaster Recovery (восстановление после сбоев) готова не каждая компания -большинство в качестве платформы виртуализации использует коммерческие продукты (как vSphere VMware, например). Это значит, что и резервную площадку им строить придется на решении вендора, что удвоит лицензионные выплаты. Альтернативой может стать услуга Disaster Recovery на базе OpenStack. Никаких лицензионных отчислений &#8212; клиент платит только за используемые ресурсы. Своевременная разработка и внедрение плана восстановления инфраструктуры в случае серьезного сбоя в работе основной площадки позволит избежать финансовых и репутационных потерь при аварии. Кроме того, при тестовых прогонах сценария есть возможность протестировать облако на OpenStack и задаться вопросом: зачем платить больше? ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Опытные ИТ-руководители понимают: если корпоративная инфраструктура или ее&nbsp;часть выйдет из&nbsp;строя, большинство бизнес-процессов остановится. Но&nbsp;выделить бюджет на&nbsp;приобретение сервиса Disaster Recovery (восстановление после сбоев) готова не&nbsp;каждая компания -большинство в&nbsp;качестве платформы виртуализации использует коммерческие продукты (как vSphere VMware, например). Это значит, что и&nbsp;резервную площадку им&nbsp;строить придется на&nbsp;решении вендора, что удвоит лицензионные выплаты.&lltt;/p&ggtt;
 
&lltt;p&ggtt;Альтернативой может стать услуга Disaster Recovery на&nbsp;базе OpenStack. Никаких лицензионных отчислений&nbsp;&mdash; клиент платит только за&nbsp;используемые ресурсы.&lltt;/p&ggtt;
 
&lltt;p&ggtt;Своевременная разработка и&nbsp;внедрение плана восстановления инфраструктуры в&nbsp;случае серьезного сбоя в&nbsp;работе основной площадки позволит избежать финансовых и&nbsp;репутационных потерь при аварии. Кроме того, при тестовых прогонах сценария есть возможность протестировать облако на&nbsp;OpenStack и&nbsp;задаться вопросом: зачем платить больше?&lltt;/p&ggtt;
]]></source>
<adate>07.08.2017</adate>
<dbid>196630</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Исследование DIRECTUM: Готовы ли российские компании к облакам?]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=190994]]></link>
<description><![CDATA[ Изменения отношения к облачным технологиям &#8212; очевидны. Но нам интереснее увидеть больше конкретики по рынку СЭД, тем более, что компания DIRECTUM обладает такой информацией. В течение 2014-2016 гг. мы опрашивали потенциальных и текущих заказчиков СЭД об их отношении к облачным технологиям вообще и готовности переходу на SaaS для управления документами. Всего было получено 495 ответов. Респонденты были разделены по категориям количества компьютеров (до 50, 50-100, 100-200 и более 200), наличия или отсутствия СЭД в компании и региону расположения (Москва и остальная Россия). Какие выводы мы получили? ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Изменения отношения к&nbsp;облачным технологиям&nbsp;&mdash; очевидны. Но&nbsp;нам интереснее увидеть больше конкретики по&nbsp;рынку СЭД, тем более, что компания DIRECTUM обладает такой информацией. В&nbsp;течение &lltt;nobr&ggtt;2014-2016 гг. мы опрашивали&lltt;/nobr&ggtt; потенциальных и&nbsp;текущих заказчиков СЭД об&nbsp;их&nbsp;отношении к&nbsp;облачным технологиям вообще и&nbsp;готовности переходу на&nbsp;SaaS для управления документами. Всего было получено 495&nbsp;ответов. Респонденты были разделены по&nbsp;категориям количества компьютеров (до&nbsp;50, &lltt;nobr&ggtt;50-100,&lltt;/nobr&ggtt; &lltt;nobr&ggtt;100-200&lltt;/nobr&ggtt; и&nbsp;более 200), наличия или отсутствия СЭД в&nbsp;компании и&nbsp;региону расположения (Москва и&nbsp;остальная Россия). Какие выводы мы&nbsp;получили?&lltt;/p&ggtt;
]]></source>
<adate>14.12.2016</adate>
<dbid>190994</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Анализ и визуализация данных в СЭД CompanyMedia]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=189677]]></link>
<description><![CDATA[ Универсальное аналитическое решение в составе СЭД CompanyMedia, ориентировано на сбор, агрегацию, обработку и предоставление в удобном виде и в реальном времени данных, основанных на фактической информации, содержащейся в системе и отражающей различные аспекты деятельности организации в интересах принятия управленческих решений, анализа эффективности деятельности, оценки персонала. Предметом анализа являются атрибуты различных документов, обрабатываемых в CompanyMedia: количественные, стоимостные, временные, сезонно-географические и другие показатели, а также события жизненного цикла, регистрируемые в системе. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Универсальное аналитическое решение в&nbsp;составе СЭД CompanyMedia, ориентировано на&nbsp;сбор, агрегацию, обработку и&nbsp;предоставление в&nbsp;удобном виде и&nbsp;в&nbsp;реальном времени данных, основанных на&nbsp;фактической информации, содержащейся в&nbsp;системе и&nbsp;отражающей различные аспекты деятельности организации в&nbsp;интересах принятия управленческих решений, анализа эффективности деятельности, оценки персонала. Предметом анализа являются атрибуты различных документов, обрабатываемых в&nbsp;CompanyMedia: количественные, стоимостные, временные, сезонно-географические и&nbsp;другие показатели, а&nbsp;также события жизненного цикла, регистрируемые в&nbsp;системе.&lltt;/p&ggtt;
 ]]></source>
<adate>31.10.2016</adate>
<dbid>189677</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«ИнтерТраст» предлагает готовые проекты документов, регламентирующих использование электронной подписи и электронного контента]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=189676]]></link>
<description><![CDATA[ Компания &#171;ИнтерТраст&#187; расширяет спектр услуг по обеспечению правомерности использования электронных документов. Заказчики, пользующиеся системой CompanyMedia, теперь могут приобрести готовый пакет проектов документов, регламентирующих применение простой электронной подписи и другие аспекты работы со значимым электронным контентом. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Компания &laquo;ИнтерТраст&raquo; расширяет спектр услуг по&nbsp;обеспечению правомерности использования электронных документов. Заказчики, пользующиеся системой CompanyMedia, теперь могут приобрести готовый пакет проектов документов, регламентирующих применение простой электронной подписи и&nbsp;другие аспекты работы со&nbsp;значимым электронным контентом.&lltt;/p&ggtt;
]]></source>
<adate>31.10.2016</adate>
<dbid>189676</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Автоматизация работы с агентами. Опыт Synerdocs в СПАО «Ингосстрах»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=188724]]></link>
<description><![CDATA[ В 2014 году одна из крупнейших страховых компаний России &#8212; СПАО &#171;Ингосстрах&#187; — приняла решение освоить современные технологии, позволяющие снизить объем бумажных документов и оптимизировать финансовые и временные затраты по обработке входящих документов от агентов. Были определены основные требования и критерии, которым должно удовлетворять решение по автоматизации документооборота с агентами. В первую очередь это безопасность отправки документов с сохранением их юридической значимости, небольшие затраты на первичное внедрение системы, развитая функциональность. Согласно выдвинутым требованиям была проведена оценка основных представителей рынка, предлагающих услуги по автоматизации внешнего документооборота. В итоге выбор был сделан в пользу сервиса обмена электронными документами Synerdocs. Во-первых, сервис отвечал требованиям безопасности и обеспечивал юридическую значимость при обмене документами. Во-вторых, его внедрение в работу СПАО «Ингосстрах» не требовало больших инвестиций. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;В&nbsp;2014 году одна из&nbsp;крупнейших страховых компаний России&nbsp;&mdash; СПАО &laquo;Ингосстрах&raquo;&nbsp;— приняла решение освоить современные технологии, позволяющие снизить объем бумажных документов и&nbsp;оптимизировать финансовые и&nbsp;временные затраты по&nbsp;обработке входящих документов от&nbsp;агентов. Были определены основные требования и&nbsp;критерии, которым должно удовлетворять решение по&nbsp;автоматизации документооборота с&nbsp;агентами. В&nbsp;первую очередь это безопасность отправки документов с&nbsp;сохранением их&nbsp;юридической значимости, небольшие затраты на&nbsp;первичное внедрение системы, развитая функциональность.&lltt;/p&ggtt;
 
&lltt;p&ggtt;Согласно выдвинутым требованиям была проведена оценка основных представителей рынка, предлагающих услуги по&nbsp;автоматизации внешнего документооборота. В&nbsp;итоге выбор был сделан в&nbsp;пользу сервиса обмена электронными документами &lltt;a href="http://www.synerdocs.ru/extra_corp" target="_blank" &ggtt;Synerdocs&lltt;/a&ggtt;. Во-первых, сервис отвечал требованиям безопасности и&nbsp;обеспечивал юридическую значимость при обмене документами. Во-вторых, его внедрение в&nbsp;работу СПАО «Ингосстрах» не&nbsp;требовало больших инвестиций.&lltt;/p&ggtt;
]]></source>
<adate>22.09.2016</adate>
<dbid>188724</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Переход на электронные документы в отдельно взятой торговой сети. Пример Synerdocs и Wildberries]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=188723]]></link>
<description><![CDATA[В конце 2014 года крупнейший российский интернет-магазин Wildberries объявил своим партнерам о переводе обмена документами в электронный вид с помощью сервиса Synerdocs. Опыт, который приобрела торговая сеть в ходе данного проекта, служит отличной иллюстрацией работы e-commerce с электронными документами. Wildberries требовалось решение, которое бы объединило процесс формирования первичных документов в учетной системе с подписанием, отправкой и получением документов. Плюс подчеркивалась необходимость в быстром добавлении новых контрагентов в систему, гибкость при масштабировании, интеграции и роуминге. По данным критериям был проанализирован ряд операторов электронного документооборота, действующих на территории РФ. В итоге выбор был сделан в пользу сервиса Synerdocs]]></description>
<source><![CDATA[&lltt;p&ggtt;В&nbsp;конце 2014 года крупнейший российский интернет-магазин Wildberries объявил своим партнерам о&nbsp;переводе обмена документами в&nbsp;электронный вид с&nbsp;помощью сервиса Synerdocs. Опыт, который приобрела торговая сеть в&nbsp;ходе данного проекта, служит отличной иллюстрацией работы e-commerce с&nbsp;электронными документами.&lltt;/p&ggtt;
&lltt;p&ggtt;Wildberries требовалось решение, которое&nbsp;бы объединило процесс формирования первичных документов в&nbsp;учетной системе с&nbsp;подписанием, отправкой и&nbsp;получением документов. Плюс подчеркивалась необходимость в&nbsp;быстром добавлении новых контрагентов в&nbsp;систему, гибкость при масштабировании, интеграции и&nbsp;роуминге. По&nbsp;данным критериям был проанализирован ряд операторов электронного документооборота, действующих на&nbsp;территории РФ. В&nbsp;итоге выбор был сделан в&nbsp;пользу сервиса &lltt;a href="http://www.synerdocs.ru/extra_corp" target="_blank"&ggtt;Synerdocs&lltt;/a&ggtt;.&lltt;/p&ggtt;]]></source>
<adate>22.09.2016</adate>
<dbid>188723</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Мобильное приложение CompanyMedia — управление документами и задачами из любой точки мира]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=185567]]></link>
<description><![CDATA[Мобильное приложение CompanyMedia представляет собой полнофункциональное рабо­чее место участников электронного документооборота &#8212; руководителей различного уров­ня и предметных специалистов. Мобильный доступ к СЭД позволяет быстро принимать управленческие решения, предоставляет возможность удаленного участия в бизнес-про­цессах организации. По функциональности решение не уступает возможностям, представленным в web-интерфейсе системы CompanyMedia. Благодаря этому многие руководители, поль­зующиеся мобильным приложением, работают в СЭД только с применением планшетов и полностью отказываются от стационарных компьютеров и ноутбуков]]></description>
<source><![CDATA[&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;Мобильное приложение CompanyMedia представляет собой полнофункциональное рабо­чее место участников электронного документооборота&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;&mdash; руководителей различного уров­ня и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;предметных специалистов. Мобильный доступ к&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;СЭД позволяет быстро принимать управленческие решения, предоставляет возможность удаленного участия в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;бизнес-про­цессах организации. По&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;функциональности решение не&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;уступает возможностям, представленным в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;web-интерфейсе системы CompanyMedia. Благодаря этому многие руководители, поль­зующиеся мобильным приложением, работают в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;СЭД только с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;применением планшетов и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;полностью отказываются от&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;стационарных компьютеров и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;ноутбуков.&lltt;/span&ggtt;]]></source>
<adate>12.05.2016</adate>
<dbid>185567</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«CompanyMedia-Кейсы» — управление неструктурированными процессами на основе навыков]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=185566]]></link>
<description><![CDATA[Применение инструментов адаптивного кейс-менеджмента (ACM, adaptive case management) оптимально для управления неструктуриро­ванными или частично структурированными бизнес-процессами. Большинство управленцев уже имеют дело с кейсами &#8212; они ежедневно работают в условиях многозадачности и динамично меняющихся процессов. При этом нерегламентированные процессы зачастую не оставляют информационного следа в системах организации. В результате, сталкиваясь с аналогичной задачей, специалисты каждый раз действуют &#171;на ощупь&#187; — сведения о том, как тот или иной процесс был выстроен ранее, редко становятся частью корпоративных баз знаний и практически не используются повторно. ACM, с одной стороны, предоставляет средства оперативного управления подобными процессами, а с другой — позволяет выявить и сохранить компетенции, практическое применение которых способно повысить эффективность любой организации]]></description>
<source><![CDATA[&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;Применение инструментов адаптивного кейс-менеджмента (ACM, adaptive case management) оптимально для управления неструктуриро­ванными или частично структурированными бизнес-процессами. Большинство управленцев уже имеют дело с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;кейсами&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;&mdash; они ежедневно работают в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;условиях многозадачности и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;динамично меняющихся процессов. При этом нерегламентированные процессы зачастую не&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;оставляют информационного следа в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;системах организации. В&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;результате, сталкиваясь с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;аналогичной задачей, специалисты каждый раз действуют &laquo;на&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;ощупь&raquo;&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;— сведения о&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;том, как тот или иной процесс был выстроен ранее, редко становятся частью корпоративных баз знаний и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;практически не&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;используются повторно. ACM, с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;одной стороны, предоставляет средства оперативного управления подобными процессами, а&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;другой&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;— позволяет выявить и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;сохранить компетенции, практическое применение которых способно повысить эффективность любой организации.&lltt;/span&ggtt;]]></source>
<adate>12.05.2016</adate>
<dbid>185566</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«CompanyMedia-Заседания» — инструмент повышения эффективности коллегиальных органов]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=185565]]></link>
<description><![CDATA[Бизнес-решение &#171;CompanyMedia &#8212; Заседания&#187; предназначено для комплексной автоматизации подготовки, проведения и контроля исполнения решений, принимаемых в ходе заседаний коллегиальных органов — рабочих групп, комиссий, комитетов, наблюдательных советов и др. Одна из ключевых особенностей решения — возможность дистанционного участия в работе заседаний с применением планшетных устройств]]></description>
<source><![CDATA[&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;Бизнес-решение &laquo;CompanyMedia&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;&mdash; Заседания&raquo; предназначено для комплексной автоматизации подготовки, проведения и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;контроля исполнения решений, принимаемых в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;ходе заседаний коллегиальных органов&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;— рабочих групп, комиссий, комитетов, наблюдательных советов и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;др. Одна из&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;ключевых особенностей решения&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;— возможность дистанционного участия в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;работе заседаний с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;применением планшетных устройств.&lltt;/span&ggtt;]]></source>
<adate>12.05.2016</adate>
<dbid>185565</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«CompanyMedia-Закупки» — автоматизация закупочной деятельности (223-ФЗ и 44-ФЗ). Опыт Банка ВТБ]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=185564]]></link>
<description><![CDATA[Бизнес-решение &#171;CompanyMedia &#8212; Закупки&#187; позволяет автоматизировать процессы подготовки и оформления документов, необходимых для проведения процедуры закупок. Решение ориентировано прежде всего на компании и организации, осуществляющие приобретение товаров и услуг в соответствии с федеральными законами № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» и № 44- ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». В Банке ВТБ решение применяется автоматизации всех этапов закупоч­ной деятельности, включая сбор и согласование заявок внутри банка, формирование и публикацию пакетов закупочной документации, осуществление процедуры закупок, выбор контрагентов и подготовку проектов договоров с поставщиками]]></description>
<source><![CDATA[&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;Бизнес-решение &laquo;CompanyMedia&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;&mdash; Закупки&raquo; позволяет автоматизировать процессы подготовки и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;оформления документов, необходимых для проведения процедуры закупок. Решение ориентировано прежде всего на&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;компании и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;организации, осуществляющие приобретение товаров и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;услуг в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;соответствии с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;федеральными законами №&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;nobr style="background-color: rgb(239, 239, 170);"&ggtt;223-ФЗ&lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt; «О&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;закупках товаров, работ, услуг отдельными видами юридических лиц» и №&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;44- ФЗ&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;«О&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;контрактной системе в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;сфере закупок товаров, работ, услуг для обеспечения государственных и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;муниципальных нужд». В&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;Банке ВТБ решение применяется автоматизации всех этапов закупоч­ной деятельности, включая сбор и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;согласование заявок внутри банка, формирование и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;публикацию пакетов закупочной документ&lltt;/span&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;ации, осуществление процедуры закупок, выбор контрагентов и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;подготовку проектов договоров с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;поставщиками.&lltt;/span&ggtt;]]></source>
<adate>12.05.2016</adate>
<dbid>185564</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«CompanyMedia-Договоры» для работы с контрактной документацией на всех этапах. Опыт группы «Астерра»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=185563]]></link>
<description><![CDATA[Бизнес-решение &#171;CompanyMedia &#8212; Договоры&#187; предназначено для авто­матизации всех этапов работы с контрактной документацией, включая создание проектов договоров, их согласование, формирование элек­тронного архива. Решение позволяет существенно сократить сроки согласования по договорам, а также полностью исключить риск потери каких-либо документов. Решение ориентировано на широкий круг пользователей, включая руководство организаций, специалистов юридических и финансовых департаментов, сотрудников бухгалтерий и других подразделений, участвующих в договорной работе]]></description>
<source><![CDATA[&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;Бизнес-решение &laquo;CompanyMedia&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;&mdash; Договоры&raquo; предназначено для авто­матизации всех этапов работы с&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;контрактной документацией, включая создание проектов договоров, их&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;согласование, формирование элек­тронного архива. Решение позволяет существенно сократить сроки согласования по&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;договорам, а&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;также полностью исключить риск потери каких-либо документов. Решение ориентировано на&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;широкий круг пользователей, включая руководство организаций, специалистов юридических и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;финансовых департаментов, сотрудников бухгалтерий и&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;других подразделений, участвующих в&lltt;/span&ggtt;&lltt;nobr class="nbsp" unselectable="on" style="height: 1em; background-color: rgb(239, 239, 170);"&ggtt; &lltt;/nobr&ggtt;&lltt;span style="background-color: rgb(255, 255, 255);"&ggtt;договорной работе.&lltt;/span&ggtt;]]></source>
<adate>12.05.2016</adate>
<dbid>185563</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«CompanyMedia-Делопроизводство» — решение «ИнтерТраст» для сквозной автоматизации документооборота]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=185562]]></link>
<description><![CDATA[ Решение &#171;CompanyMedia-Делопроизводство&#187; предназначено для автоматизации документооборота в территориально-распределенных организациях, технология делопроизводства которых предполагает централизованное отслеживание дви­жения документов в режиме реального времени. Решение позволяет повысить эффективность управления, сократить сроки про­хождения документов и повысить эффективность контрольных функций. В совокупности с повышением прозрачности процессов решение заметно повышает эффективность процедур до­кументооборота и управляемость организации в целом. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Решение &laquo;CompanyMedia-Делопроизводство&raquo; предназначено для автоматизации документооборота в территориально-распределенных организациях, технология делопроизводства которых предполагает централизованное отслеживание дви­жения документов в режиме реального времени. Решение позволяет повысить эффективность управления, сократить сроки про­хождения документов и повысить эффективность контрольных функций. В совокупности с повышением прозрачности процессов решение заметно повышает эффективность процедур до­кументооборота и управляемость организации в целом.&lltt;/p&ggtt;
]]></source>
<adate>12.05.2016</adate>
<dbid>185562</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Облачные услуги КРОК для гибкого управления бизнесом и соответствия требованиям законодательства]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=179838]]></link>
<description><![CDATA[ Компания КРОК предлагает использовать ресурсы Виртуального дата-центра &#8212; облака собственной разработки на базе открытого ПО — для обеспечения соответствия требованиям законодательства в области персональных данных. С 1 сентября 2015 года все компании, работающие с персональными данными российских пользователей, обязаны хранить и обрабатывать их только на российских серверах. Облако в данном случае является наиболее удобным инструментом для быстрой миграции данных. Читайте также о других облачных услугах КРОК. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Компания КРОК предлагает использовать ресурсы Виртуального дата-центра&nbsp;&mdash; облака собственной разработки на&nbsp;базе открытого ПО&nbsp;— для обеспечения соответствия требованиям законодательства в&nbsp;области персональных данных. С&nbsp;1&nbsp;сентября 2015 года все компании, работающие с&nbsp;персональными данными российских пользователей, обязаны хранить и&nbsp;обрабатывать их&nbsp;только на&nbsp;российских серверах. Облако в&nbsp;данном случае является наиболее удобным инструментом для быстрой миграции данных. Читайте также о&nbsp;других облачных услугах КРОК. &lltt;/p&ggtt;
 ]]></source>
<adate>10.11.2015</adate>
<dbid>179838</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Решения КРОК в области оптимизации хранения]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=179836]]></link>
<description><![CDATA[ Учитывая сложную экономическую ситуацию, компания КРОК предлагает несколько антикризисных услуг. Они позволяют оптимизировать инфраструктуру хранения, снизив капитальные издержки, повысив скорость работы приложений, обеспечив сохранность данных. В числе предложений КРОК: СХД как услуга, экспресс-оптимизация хранения менее чем за месяц, использование новых технологий, таких как программно-определяемые системы хранения. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Учитывая сложную экономическую ситуацию, компания КРОК предлагает несколько антикризисных услуг. Они позволяют оптимизировать инфраструктуру хранения, снизив капитальные издержки, повысив скорость работы приложений, обеспечив сохранность данных. В&nbsp;числе предложений КРОК: СХД как услуга, экспресс-оптимизация хранения менее чем за&nbsp;месяц, использование новых технологий, таких как программно-определяемые системы хранения. &lltt;/p&ggtt;
 ]]></source>
<adate>10.11.2015</adate>
<dbid>179836</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Сборник статей «Как определить ценность Интернета вещей для бизнеса»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=175902]]></link>
<description><![CDATA[ Internet of Things &#8212; тренд, который уже сейчас кардинально меняет бизнес во всем мире. И хотя некоторые до сих пор с опаской присматриваются к этому явлению, всем понятно: чем раньше начать использовать IoT, тем больше пользы можно получить. О том, как правильно это сделать, с чего начать и как не заблудиться по дороге, можно узнать в сборнике статей &#171;Как определить ценность Интернета вещей для бизнеса&#187;. 	 Первая статья содержит конкретные рекомендации по выбору IoT-платформы, рассказывает с чего начинать ее внедрение и как преодолевать возникающие трудности. 	 Вторая статья на конкретных проектах показывает, как внедрить IoT, заставив инвестиции приносить пользу в оптимальные сроки и с максимальной эффективностью. 	 Третья — представляет модель развитости продукта, способного поддерживать сетевые функции, рассказывает о том, как эту модель использовать в бизнесе и какие дополнительные выгоды можно за счет этого получить. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Internet of&nbsp;Things&nbsp;&mdash; тренд, который уже сейчас кардинально меняет бизнес во&nbsp;всем мире. И&nbsp;хотя некоторые до&nbsp;сих пор с&nbsp;опаской присматриваются к&nbsp;этому явлению, всем понятно: чем раньше начать использовать IoT, тем больше пользы можно получить. О&nbsp;том, как правильно это сделать, с&nbsp;чего начать и&nbsp;как не&nbsp;заблудиться по&nbsp;дороге, можно узнать в&nbsp;сборнике статей &laquo;Как определить ценность Интернета вещей для бизнеса&raquo;. &lltt;/p&ggtt;
 
&lltt;ul&ggtt; 	 
  &lltt;li&ggtt; Первая статья содержит конкретные рекомендации по&nbsp;выбору IoT-платформы, рассказывает с&nbsp;чего начинать ее&nbsp;внедрение и&nbsp;как преодолевать возникающие трудности.&lltt;/li&ggtt;
 	 
  &lltt;li&ggtt; Вторая статья на&nbsp;конкретных проектах показывает, как внедрить IoT, заставив инвестиции приносить пользу в&nbsp;оптимальные сроки и&nbsp;с&nbsp;максимальной эффективностью.&lltt;/li&ggtt;
 	 
  &lltt;li&ggtt; Третья&nbsp;— представляет модель развитости продукта, способного поддерживать сетевые функции, рассказывает о&nbsp;том, как эту модель использовать в&nbsp;бизнесе и&nbsp;какие дополнительные выгоды можно за&nbsp;счет этого получить.&lltt;/li&ggtt;
 &lltt;/ul&ggtt;
 ]]></source>
<adate>15.07.2015</adate>
<dbid>175902</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Сервис — это наше «все» в прошлом, настоящем и будущем!]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=173853]]></link>
<description><![CDATA[ Сервисные центры ГК &#171;Паладин&#187; осуществляют различные виды обслуживания вычислительной техники Hewlett-Packard. Основными из них являются гарантийные, платные и договорные работы. ]]></description>
<source><![CDATA[ 
&lltt;p&ggtt;Сервисные центры ГК &laquo;Паладин&raquo; осуществляют различные виды обслуживания вычислительной техники Hewlett-Packard. Основными из них являются гарантийные, платные и договорные работы.&lltt;/p&ggtt;
 ]]></source>
<adate>21.04.2015</adate>
<dbid>173853</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[HP SM соединяет лучшие практики с жизнью]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=173852]]></link>
<description><![CDATA[ Множественный опыт российских и зарубежных компаний показали, что ПО для управления ИТ-услугами помогает упростить управление службой поддержки и снизить издержки за счет применения встроенных правил библиотеки ИТ-инфрастуктуры (ITIL). ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Множественный опыт российских и зарубежных компаний показали, что ПО для управления ИТ-услугами помогает упростить управление службой поддержки и снизить издержки за счет применения встроенных правил библиотеки ИТ-инфрастуктуры (ITIL).&lltt;/p&ggtt;
 ]]></source>
<adate>21.04.2015</adate>
<dbid>173852</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Автоматизация документооборота производственной компании «Целер» на базе Docsvision]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=173260]]></link>
<description><![CDATA[ Решение на базе СЭД для производственного предприятия. Специализация ООО &#171;Целер&#187; &#8212; изготовление деталей с антикоррозионным покрытием для нефтегазовых трубопроводов. Решение на базе Docsvision закрыло необходимость в программе, которая бы систематизировала поток информации и интегрировала все бизнес-процессы, связанные с производственным циклом: от получения входящих документов и заявок на изготовление и до отгрузки готовой продукции заказчику. Программа представляет собой соединение СЭД и специально созданных для нужд предприятия расчетных модулей. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Решение на&nbsp;базе СЭД для производственного предприятия. Специализация ООО &laquo;Целер&raquo;&nbsp;&mdash; изготовление деталей с&nbsp;антикоррозионным покрытием для нефтегазовых трубопроводов. Решение на&nbsp;базе Docsvision закрыло необходимость в&nbsp;программе, которая&nbsp;бы систематизировала поток информации и&nbsp;интегрировала все бизнес-процессы, связанные с&nbsp;производственным циклом: от&nbsp;получения входящих документов и&nbsp;заявок на&nbsp;изготовление и&nbsp;до&nbsp;отгрузки готовой продукции заказчику. Программа представляет собой соединение СЭД и&nbsp;специально созданных для нужд предприятия расчетных модулей. &lltt;/p&ggtt;
 ]]></source>
<adate>06.04.2015</adate>
<dbid>173260</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Администрация Стрежевого подключает к корпоративному документальному серверу eDocLib муниципальные учреждения]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=171505]]></link>
<description><![CDATA[ Единая информационная система Администрации городского округа Стрежевой (Томская область), базой для которой стали продукты компании ЭОС &#171;ДЕЛО&#187; и eDocLib, масштабируется за счет подключения новых организаций. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Единая информационная система Администрации городского округа Стрежевой (Томская область), базой для которой стали продукты компании ЭОС &laquo;ДЕЛО&raquo; и&nbsp;eDocLib, масштабируется за&nbsp;счет подключения новых организаций.&lltt;/p&ggtt;
 ]]></source>
<adate>26.02.2015</adate>
<dbid>171505</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Распределительная теплосетевая компания «ОмскРТС» внедрила СЭД «ДЕЛО» в первый месяц своей хозяйственной деятельности]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=171242]]></link>
<description><![CDATA[ &#171;Территориальная генерирующая компания № 11&#187; (ОАО «ТГК-11»), одна из крупнейших теплоэнергетических бизнес-структур в Сибири, выделила в самостоятельное предприятие ОАО «ОмскРТС». ]]></description>
<source><![CDATA[
&lltt;p&ggtt;&laquo;Территориальная генерирующая компания №&nbsp;11&raquo; (ОАО «ТГК-11»), одна из&nbsp;крупнейших теплоэнергетических бизнес-структур в&nbsp;Сибири, выделила в&nbsp;самостоятельное предприятие ОАО «ОмскРТС».&lltt;/p&ggtt;
 ]]></source>
<adate>18.02.2015</adate>
<dbid>171242</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[СЭДД «ДЕЛО» в органах исполнительной власти и местного самоуправления Республики Северная Осетия-Алания: переход к 5-му этапу]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=170816]]></link>
<description><![CDATA[ В органах государственной власти Республики Северная Осетия-Алания (РСО-Алания) в ближайшие недели начнется 5-й этап внедрения системы электронного документооборота и делопроизводства (СЭДД) &#171;ДЕЛО&#187;. ]]></description>
<source><![CDATA[ 
&lltt;p&ggtt;В&nbsp;органах государственной власти Республики Северная Осетия-Алания (РСО-Алания) в&nbsp;ближайшие недели начнется &lltt;nobr&ggtt;5-й&lltt;/nobr&ggtt; этап внедрения системы электронного документооборота и&nbsp;делопроизводства (СЭДД) &laquo;ДЕЛО&raquo;.&lltt;/p&ggtt;
 ]]></source>
<adate>10.02.2015</adate>
<dbid>170816</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Главное водоснабжающее предприятие Ставропольского края ведет документооборот в EOS for SharePoint]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=170759]]></link>
<description><![CDATA[ Одно из крупнейших в регионе предприятий &#8212; Государственное унитарное предприятие Ставропольского края &#171;Ставрополькрайводоканал&#187;, начало внедрение системы управления корпоративным контентом EOS for SharePoint в сентябре прошлого года. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Одно из&nbsp;крупнейших в&nbsp;регионе предприятий&nbsp;&mdash; Государственное унитарное предприятие Ставропольского края &laquo;Ставрополькрайводоканал&raquo;, начало внедрение системы управления корпоративным контентом EOS for SharePoint в&nbsp;сентябре прошлого года.&lltt;/p&ggtt;
 ]]></source>
<adate>09.02.2015</adate>
<dbid>170759</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Начато внедрение АИК «НАДЗОР» в Следственном управлении СК РФ по Республике Башкортостан]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=170612]]></link>
<description><![CDATA[ Следственные управления Следственного комитета Российской Федерации продолжают внедрение автоматизированного информационного комплекса &#171;НАДЗОР&#187; (АИК «НАДЗОР»), разработанного ЭОС для решения задач по документационному обеспечению деятельности органов прокуратуры и следствия. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Следственные управления Следственного комитета Российской Федерации продолжают внедрение автоматизированного информационного комплекса &laquo;НАДЗОР&raquo; (АИК «НАДЗОР»), разработанного ЭОС для решения задач по&nbsp;документационному обеспечению деятельности органов прокуратуры и&nbsp;следствия.&lltt;/p&ggtt;
 ]]></source>
<adate>04.02.2015</adate>
<dbid>170612</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Благодаря решениям «ДЕЛО» и «Архивное Дело» мы можем вести учет документов АМС на протяжении всего их жизненного цикла]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=170488]]></link>
<description><![CDATA[ В Администрации местного самоуправления (АМС) г. Владикавказа с 2010 года ведется проект внедрения СЭД &#171;ДЕЛО&#187; (компании ЭОС). В начале 2014 года система была дополнена решением «Архивное Дело», благодаря чему стала возможной поддержка полного жизненного цикла документов. ]]></description>
<source><![CDATA[ 
&lltt;p&ggtt;В&nbsp;Администрации местного самоуправления (АМС) г. Владикавказа с&nbsp;2010 года ведется проект внедрения СЭД &laquo;ДЕЛО&raquo; (компании ЭОС). В&nbsp;начале 2014 года система была дополнена решением «Архивное Дело», благодаря чему стала возможной поддержка полного жизненного цикла документов.&lltt;/p&ggtt;
 ]]></source>
<adate>02.02.2015</adate>
<dbid>170488</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Маленькая грязная тайна отрасли безопасности]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=166353]]></link>
<description><![CDATA[ В последние годы центральное место в обсуждении вопросов сетевой безопасности занимают постоянные угрозы повышенной сложности (advanced persistent threats &#8212; APTs). Многие организации внедряют новые решения для защиты от вредоносных программ этого типа. Тем не менее киберпреступникам по-прежнему удается преодолевать даже самые мощные системы защиты сети, в том числе защитные системы очень крупных предприятий. Одним из грязных приемов, который хакеры используют для обхода систем защиты и проникновения в наиболее защищенные сети, являются динамические техники обхода (advanced evasion techniques — AETs). Такие техники широко известны в хакерском сообществе и активно распространяются и используются в течение последних лет, однако среди специалистов, ответственных за блокировку этих техник, наблюдается непонимание, неверная интерпретация неэффективных средств защиты. В то время как среди специалистов разгораются ожесточенные дискуссии по поводу самого существования динамических техник обхода, хакеры продолжают успешно использовать эти техники для кражи информации. Такая ситуация позволяет хакерам использовать дополнительные средства для дальнейшего совершенствования сетевых атак и при этом еще дольше оставаться незамеченными, что в конечном итоге ведет к ущербу для компаний и дорогостоящим утечкам информации. Чем дольше продолжаются споры о существовании динамических техник обхода, тем дольше предприятия будут уязвимы для атак такого типа. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;В&nbsp;последние годы центральное место в&nbsp;обсуждении вопросов сетевой безопасности занимают постоянные угрозы повышенной сложности (advanced persistent threats&nbsp;&mdash; APTs). Многие организации внедряют новые решения для защиты от&nbsp;вредоносных программ этого типа. Тем не&nbsp;менее киберпреступникам по-прежнему удается преодолевать даже самые мощные системы защиты сети, в&nbsp;том числе защитные системы очень крупных предприятий.&lltt;/p&ggtt;
 
&lltt;p&ggtt;Одним из&nbsp;грязных приемов, который хакеры используют для обхода систем защиты и&nbsp;проникновения в&nbsp;наиболее защищенные сети, являются динамические техники обхода (advanced evasion techniques&nbsp;— AETs). Такие техники широко известны в&nbsp;хакерском сообществе и&nbsp;активно распространяются и&nbsp;используются в&nbsp;течение последних лет, однако среди специалистов, ответственных за&nbsp;блокировку этих техник, наблюдается непонимание, неверная интерпретация неэффективных средств защиты.&lltt;/p&ggtt;
 
&lltt;p&ggtt;В&nbsp;то&nbsp;время как среди специалистов разгораются ожесточенные дискуссии по&nbsp;поводу самого существования динамических техник обхода, хакеры продолжают успешно использовать эти техники для кражи информации. Такая ситуация позволяет хакерам использовать дополнительные средства для дальнейшего совершенствования сетевых атак и&nbsp;при этом еще дольше оставаться незамеченными, что в&nbsp;конечном итоге ведет к&nbsp;ущербу для компаний и&nbsp;дорогостоящим утечкам информации. Чем дольше продолжаются споры о&nbsp;существовании динамических техник обхода, тем дольше предприятия будут уязвимы для атак такого типа.&lltt;/p&ggtt;
 ]]></source>
<adate>09.09.2014</adate>
<dbid>166353</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Автоматизация документооборота в рекламном бизнесе: внедрение Docsvision в ООО «Доминанта»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=164947]]></link>
<description><![CDATA[ Внедрение системы Docsvision в компании &#171;Доминанта&#187;, работающей в рекламном бизнесе (компания имеет сеть крупноформатных рекламных носителей в Московском регионе), позволило повысить эффективность внутренних процессов. Реализация проекта в 2014 году позволила организовать централизованное структурированное хранилище документов с возможностью быстрого поиска, сократить трудозатраты на маршрутизацию и обработку документов, повысить уровень исполнительской дисциплины, минимизировать риски утраты и несанкционированного доступа к документам, обеспечить удаленный доступ сотрудников к корпоративной информации, резко сократить бумажный документооборот внутри компании. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Внедрение системы Docsvision в&nbsp;компании &laquo;Доминанта&raquo;, работающей в&nbsp;рекламном бизнесе (компания имеет сеть крупноформатных рекламных носителей в&nbsp;Московском регионе), позволило повысить эффективность внутренних процессов. Реализация проекта в&nbsp;2014 году позволила организовать централизованное структурированное хранилище документов с&nbsp;возможностью быстрого поиска, сократить трудозатраты на&nbsp;маршрутизацию и&nbsp;обработку документов, повысить уровень исполнительской дисциплины, минимизировать риски утраты и&nbsp;несанкционированного доступа к&nbsp;документам, обеспечить удаленный доступ сотрудников к&nbsp;корпоративной информации, резко сократить бумажный документооборот внутри компании.&lltt;/p&ggtt;
]]></source>
<adate>16.07.2014</adate>
<dbid>164947</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«Бумага» уходит в прошлое]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=159854]]></link>
<description><![CDATA[Замминистра ИТ и связи Ростовской области Михаил Фишкин рассказал, как СЭД «Дело» позволяет уйти от бумажных носителей на всех уровнях власти практически полностью]]></description>
<source><![CDATA[&lltt;p&ggtt;Замминистра ИТ&nbsp;и&nbsp;связи Ростовской области Михаил Фишкин рассказал, как СЭД «Дело» позволяет уйти от&nbsp;бумажных носителей на&nbsp;всех уровнях власти практически полностью&lltt;/p&ggtt;]]></source>
<adate>12.02.2014</adate>
<dbid>159854</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[В Следственном управлении по Удмуртской Республике запущен в промышленную эксплуатацию АИК «НАДЗОР»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=159121]]></link>
<description><![CDATA[Следственное управление Следственного комитета Российской Федерации по Удмуртской Республике (далее — следственное управление) с декабря 2013 года ведет документооборот с помощью автоматизированного информационного комплекса «НАДЗОР», разработанного ЭОС. В течение двух предновогодних недель система работала в тестовом режиме, а с начала января АИК «НАДЗОР» функционирует в полном объеме на всех рабочих местах пользователей]]></description>
<source><![CDATA[&lltt;p&ggtt;Следственное управление Следственного комитета Российской Федерации по&nbsp;Удмуртской Республике (далее&nbsp;— следственное управление) с&nbsp;декабря 2013 года ведет документооборот с&nbsp;помощью автоматизированного информационного комплекса «НАДЗОР», разработанного ЭОС. В&nbsp;течение двух предновогодних недель система работала в&nbsp;тестовом режиме, а&nbsp;с&nbsp;начала января АИК «НАДЗОР» функционирует в&nbsp;полном объеме на&nbsp;всех рабочих местах пользователей.&lltt;/p&ggtt;]]></source>
<adate>27.01.2014</adate>
<dbid>159121</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Владимир Баласанян (ЭОС) награжден грамотой Министерства юстиции]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=158993]]></link>
<description><![CDATA[В Минюсте и его территориальных подразделениях по инициативе Департамента организации и контроля (подразделения, отвечающего в Минюсте за организацию единой системы документооборота) с 2011 года реализуется проект по созданию СЭД на базе программного комплекса «ДЕЛО». Министерством юстиции, одним из первых среди федеральных органов власти, была сформулирована и реализована на практике концепция создания единой СЭД как для центрального аппарата министерства, так и для 80 регионов]]></description>
<source><![CDATA[&lltt;p&ggtt;В&nbsp;Минюсте и&nbsp;его территориальных подразделениях по&nbsp;инициативе Департамента организации и&nbsp;контроля (подразделения, отвечающего в&nbsp;Минюсте за&nbsp;организацию единой системы документооборота) с&nbsp;2011 года реализуется проект по&nbsp;созданию СЭД на&nbsp;базе программного комплекса «ДЕЛО». Министерством юстиции, одним из&nbsp;первых среди федеральных органов власти, была сформулирована и&nbsp;реализована на&nbsp;практике концепция создания единой СЭД как для центрального аппарата министерства, так и&nbsp;для 80&nbsp;регионов.&lltt;/p&ggtt;]]></source>
<adate>22.01.2014</adate>
<dbid>158993</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Обзор EMC Greenplum – решения для бизнес-аналитики]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=148967]]></link>
<description><![CDATA[ Бизнес-аналитика &#8212; относительно новое направление обработки данных. Она позволяет извлечь прибыль из данных, которые раньше считались &#171;мертвым&#187; грузом с высокими затратами на хранение. Этим оно напоминает производства по добыче золота. Только темпы развития отличаются на порядки. А проблемы и подходы — очень похожи. В обоих случаях, перерабатывается огромное количество «сырья». Но в случае добычи редких металлов мы получаем огромные горы обеднённой породы, а в случае бизнес-аналитики — петабайты данных, из которых сложно извлечь какую-либо прибыль. Но появляются новые технологии обогащения, и всё повторяется заново. EMC Greenplum — «новое слово» в технологии аналитической обработки массивов накопленных данных. Это высокопроизводительная многопоточная система аналитической обработки структурированных или неструктурированных данных, гибкая и бесшовная при масштабировании. Внедрение такой технологии поваляет оперативно анализировать накопленные данные для выявления дополнительных источников дохода. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Бизнес-аналитика&nbsp;&mdash; относительно новое направление обработки данных.
  &lltt;br /&ggtt;
 Она позволяет извлечь прибыль из&nbsp;данных, которые раньше считались &laquo;мертвым&raquo; грузом с&nbsp;высокими затратами на&nbsp;хранение.
  &lltt;br /&ggtt;
 Этим оно напоминает производства по&nbsp;добыче золота.
  &lltt;br /&ggtt;
 Только темпы развития отличаются на&nbsp;порядки.
  &lltt;br /&ggtt;
 А&nbsp;проблемы и&nbsp;подходы&nbsp;— очень похожи.
  &lltt;br /&ggtt;
 В&nbsp;обоих случаях, перерабатывается огромное количество «сырья».
  &lltt;br /&ggtt;
 Но&nbsp;в&nbsp;случае добычи редких металлов мы&nbsp;получаем огромные горы обеднённой породы, а&nbsp;в&nbsp;случае бизнес-аналитики&nbsp;— петабайты данных, из&nbsp;которых сложно извлечь какую-либо прибыль.
  &lltt;br /&ggtt;
 Но&nbsp;появляются новые технологии обогащения, и&nbsp;всё повторяется заново.
  &lltt;br /&ggtt;
 EMC Greenplum&nbsp;— «новое слово» в&nbsp;технологии аналитической обработки массивов накопленных данных. Это высокопроизводительная многопоточная система аналитической обработки структурированных или неструктурированных данных, гибкая и&nbsp;бесшовная при масштабировании. Внедрение такой технологии поваляет оперативно анализировать накопленные данные для выявления дополнительных источников дохода.&lltt;/p&ggtt;
]]></source>
<adate>29.03.2013</adate>
<dbid>148967</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Мировой опыт крупных внедрений открытых СУБД (NTT Group)]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=128183]]></link>
<description><![CDATA[NTT Group, крупнейшая телекоммуникационная компания Японии. ]]></description>
<source><![CDATA[&lltt;p&ggtt;NTT Group, крупнейшая телекоммуникационная компания Японии.&lltt;/p&ggtt;
]]></source>
<adate>21.02.2011</adate>
<dbid>128183</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[В Якутской городской Думе начался первый этап внедрения СЭД «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=157146]]></link>
<description><![CDATA[СЭД «ДЕЛО» была выбрана в качестве программной платформы для создания системы электронного документооборота в Якутской Думе]]></description>
<source><![CDATA[&lltt;p&ggtt;СЭД «ДЕЛО» была выбрана в&nbsp;качестве программной платформы для создания системы электронного документооборота в&nbsp;Якутской Думе.&lltt;/p&ggtt;]]></source>
<adate>11.11.2013</adate>
<dbid>157146</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Контрольно-счетная палата Санкт-Петербурга начала внедрение СЭД «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=156825]]></link>
<description><![CDATA[Осенью этого года начался первый этап автоматизации документооборота в Контрольно-счетной палате Санкт-Петербурга]]></description>
<source><![CDATA[&lltt;p&ggtt;Осенью этого года начался первый этап автоматизации документооборота в&nbsp;Контрольно-счетной палате Санкт-Петербурга.&lltt;/p&ggtt;]]></source>
<adate>30.10.2013</adate>
<dbid>156825</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Хакасия продолжает развивать электронный документооборот в органах исполнительной власти]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=156781]]></link>
<description><![CDATA[Базовой системой для автоматизации документооборота в Правительстве Республики и региональных министерствах и ведомствах выбрана СЭД «ДЕЛО», разработанная компанией ЭОС]]></description>
<source><![CDATA[&lltt;p&ggtt;Базовой системой для автоматизации документооборота в&nbsp;Правительстве Республики и&nbsp;региональных министерствах и&nbsp;ведомствах выбрана СЭД «ДЕЛО», разработанная компанией ЭОС.&lltt;/p&ggtt;]]></source>
<adate>29.10.2013</adate>
<dbid>156781</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Система «ДЕЛО» продолжает внедряться в органах власти Республики Северная Осетия-Алания]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=156725]]></link>
<description><![CDATA[Главной целью проекта является создание целостной информационной инфраструктуры, охватывающей все органы государственной власти Республики Северная Осетия-Алания, организация взаимодействия между ними с использованием современных информационных и коммуникационных технологий]]></description>
<source><![CDATA[&lltt;p&ggtt;Главной целью проекта является создание целостной информационной инфраструктуры, охватывающей все органы государственной власти Республики Северная Осетия-Алания, организация взаимодействия между ними с&nbsp;использованием современных информационных и&nbsp;коммуникационных технологий.&lltt;/p&ggtt;]]></source>
<adate>28.10.2013</adate>
<dbid>156725</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Лидер рынка SAN: от ЦОД к сетям сервис-провайдеров и операторов связи]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=124984]]></link>
<description><![CDATA[ В разгар кризиса компания Brocade &#8212; мировой лидер в области SAN-технологий (по данным Dell&#8217;Oro Group) — изменила свою бизнес-стратегию. Одной из главных причин для этого послужило приобретение ею в конце 2008 г. Foundry Networks — крупнейшего производителя сетевого IP-оборудования, ориентированного на среду передачи Ethernet. Именно Foundry Networks была пионером в создании таких продуктов, как: Gigabit/10Gigabit Ethernet коммутатор; Multi-Terabit IP/MPLS маршрутизатор; коммутатор/маршрутизатор с производительностью два миллиарда пакетов в секунду. Благодаря покупке Foundry Networks компания Brocade теперь может предложить своим заказчикам решения для построения всей сетевой инфраструктуры. Помимо технологий для ЦОД и ЛВС организаций, ее продуктовый портфель включает многочисленные разработки для сетей сервис-провайдеров и операторов связи. Эти разработки обладают ключевыми для заказчика характеристиками — как с инвестиционной, так и с технологической точек зрения. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;В&nbsp;разгар кризиса компания Brocade&nbsp;&mdash; мировой лидер в&nbsp;области SAN-технологий (по&nbsp;данным Dell&rsquo;Oro Group)&nbsp;— изменила свою бизнес-стратегию. Одной из&nbsp;главных причин для этого послужило приобретение ею&nbsp;в&nbsp;конце 2008&nbsp;г. Foundry Networks&nbsp;— крупнейшего производителя сетевого IP-оборудования, ориентированного на&nbsp;среду передачи Ethernet. Именно Foundry Networks была пионером в&nbsp;создании таких продуктов, как: Gigabit/10Gigabit Ethernet коммутатор; Multi-Terabit IP/MPLS маршрутизатор; коммутатор/маршрутизатор с&nbsp;производительностью два миллиарда пакетов в&nbsp;секунду. &lltt;/p&ggtt;

&lltt;p&ggtt;Благодаря покупке Foundry Networks компания Brocade теперь может предложить своим заказчикам решения для построения всей сетевой инфраструктуры. Помимо технологий для ЦОД и&nbsp;ЛВС организаций, ее&nbsp;продуктовый портфель включает многочисленные разработки для сетей сервис-провайдеров и&nbsp;операторов связи. Эти разработки обладают ключевыми для заказчика характеристиками&nbsp;— как с&nbsp;инвестиционной, так и&nbsp;с&nbsp;технологической точек зрения. &lltt;/p&ggtt;
]]></source>
<adate>27.08.2010</adate>
<dbid>124984</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[СИСТЕМА «ДЕЛО» ПРОДОЛЖАЕТ ВНЕДРЯТЬСЯ В МУНИЦИПАЛЬНЫХ АДМИНИСТРАЦИЯХ МОСКОВСКОЙ ОБЛАСТИ]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=156256]]></link>
<description><![CDATA[К числу муниципалитетов Московской области, использующих для автоматизации документооборота систему «ДЕЛО», скоро присоединится администрация городского поселения Солнечногорск]]></description>
<source><![CDATA[&lltt;p&ggtt;К&nbsp;числу муниципалитетов Московской области, использующих для автоматизации документооборота систему «ДЕЛО», скоро присоединится администрация городского поселения Солнечногорск.. &lltt;/p&ggtt;]]></source>
<adate>14.10.2013</adate>
<dbid>156256</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Крупнейшая в Алтайском крае сеть аптек продолжает автоматизировать бизнес-процессы на базе решения «eDocLib: Актив Бизнес»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=156171]]></link>
<description><![CDATA[Внедрение информационных технологий в бизнес-процессы позволило существенно повысить уровень качества предоставляемых услуг. Не только повысилась эффективность работы сотрудников, но и улучшилась психологическая атмосфера в коллективе]]></description>
<source><![CDATA[&lltt;p&ggtt;Внедрение информационных технологий в&nbsp;бизнес-процессы позволило существенно повысить уровень качества предоставляемых услуг. Не&nbsp;только повысилась эффективность работы сотрудников, но&nbsp;и&nbsp;улучшилась психологическая атмосфера в&nbsp;коллективе.&lltt;/p&ggtt;]]></source>
<adate>09.10.2013</adate>
<dbid>156171</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Завершен очередной этап развития системы документооборота «ДЕЛО» в Администрации г. Владикавказа]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=156103]]></link>
<description><![CDATA[Администрацией сделан очередной шаг к полностью электронному документообороту]]></description>
<source><![CDATA[Администрацией сделан очередной шаг к полностью электронному документообороту.]]></source>
<adate>08.10.2013</adate>
<dbid>156103</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[СибГУТИ расширяет использование СЭД «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=155840]]></link>
<description><![CDATA[Руководство вуза постепенно расширяет масштаб применения системы, ежегодно закупая дополнительные рабочие места СЭД &#171;ДЕЛО&#187; и ее приложений]]></description>
<source><![CDATA[&lltt;p&ggtt;Руководство вуза постепенно расширяет масштаб применения системы, ежегодно закупая дополнительные рабочие места СЭД &laquo;ДЕЛО&raquo; и&nbsp;ее&nbsp;приложений.&lltt;/p&ggtt;]]></source>
<adate>01.10.2013</adate>
<dbid>155840</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Система «ДЕЛО» внедрена в Минздраве Мурманской области в рамках мероприятий региональной программы модернизации здравоохранения]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=155011]]></link>
<description><![CDATA[В Мурманской области долгосрочная целевая программа модернизации здравоохранения осуществляется через внедрение современных информационных систем. Первым этапом реализации этого направления стало внедрение СЭД «ДЕЛО» в Министерстве здравоохранения Мурманской области]]></description>
<source><![CDATA[&lltt;p&ggtt;В&nbsp;Мурманской области долгосрочная целевая программа модернизации здравоохранения осуществляется через внедрение современных информационных систем. Первым этапом реализации этого направления стало внедрение СЭД «ДЕЛО» в&nbsp;Министерстве здравоохранения Мурманской области.&lltt;/p&ggtt;]]></source>
<adate>12.09.2013</adate>
<dbid>155011</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Многопрофильные холдинги выбирают «ДЕЛО»: начато внедрение в ЗАО «Центргазпромстрой»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=153698]]></link>
<description><![CDATA[В июне 2013 года стартовал проект создания системы электронного документооборота в ЗАО «Центргазпромстрой», дочернем предприятии ОАО «Центргаз». Система «ДЕЛО», успешно работающая во всех департаментах и отделах головной компании с 2010 года, внедрена во всех подразделениях этого филиала]]></description>
<source><![CDATA[&lltt;p&ggtt;В&nbsp;июне 2013 года стартовал проект создания системы электронного документооборота в&nbsp;ЗАО «Центргазпромстрой», дочернем предприятии ОАО «Центргаз». Система «ДЕЛО», успешно работающая во&nbsp;всех департаментах и&nbsp;отделах головной компании с&nbsp;2010&nbsp;года, внедрена во&nbsp;всех подразделениях этого филиала.&lltt;/p&ggtt;]]></source>
<adate>21.08.2013</adate>
<dbid>153698</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Управление Роспотребнадзора по Тульской области ведет документооборот в системе «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=153264]]></link>
<description><![CDATA[Средствами системы автоматизирован учет входящих документов, а также специфические процессы документооборота Управления &#8212; рассмотрение обращений граждан и регистрация нормативных документов о проведении проверок]]></description>
<source><![CDATA[&lltt;p&ggtt;Средствами системы автоматизирован учет входящих документов, а&nbsp;также специфические процессы документооборота Управления&nbsp;&mdash; рассмотрение обращений граждан и&nbsp;регистрация нормативных документов о&nbsp;проведении проверок.&lltt;/p&ggtt;]]></source>
<adate>09.08.2013</adate>
<dbid>153264</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[В администрации Пятигорска завершен первый этап внедрения СЭД «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=153119]]></link>
<description><![CDATA[Благодаря внедрению системы в администрации Пятигорска появилась возможность работы в единой базе данных всех отделов, управлений и структурных подразделений аппарата. Администрация планирует дальнейшее развитие проекта по автоматизации документооборота]]></description>
<source><![CDATA[&lltt;p&ggtt;Благодаря внедрению системы в&nbsp;администрации Пятигорска появилась возможность работы в&nbsp;единой базе данных всех отделов, управлений и&nbsp;структурных подразделений аппарата. Администрация планирует дальнейшее развитие проекта по&nbsp;автоматизации документооборота.&lltt;/p&ggtt;]]></source>
<adate>05.08.2013</adate>
<dbid>153119</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Новый этап развития системы «ДЕЛО» в Законодательном Собрании Новосибирской области]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=152988]]></link>
<description><![CDATA[Законодательное Собрание Новосибирской области реализовало один из самых масштабных среди региональных парламентов проектов по автоматизации внутреннего документооборота — закуплены рабочие места для 100% работников аппарата, автоматизированы все процессы движения документов]]></description>
<source><![CDATA[&lltt;p&ggtt;Законодательное Собрание Новосибирской области реализовало один из&nbsp;самых масштабных среди региональных парламентов проектов по&nbsp;автоматизации внутреннего документооборота&nbsp;— закуплены рабочие места для 100% работников аппарата, автоматизированы все процессы движения документов.&lltt;/p&ggtt;]]></source>
<adate>29.07.2013</adate>
<dbid>152988</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Производственные предприятия выбирают EOS for SharePoint: внедрение системы в ОАО «Калужский двигатель»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=152876]]></link>
<description><![CDATA[На машиностроительном предприятии ОАО &#171;Калужский двигатель&#187; продолжается внедрение решения EOS for SharePoint компании ЭОС. ECM-система EOS for SharePoint выбрана для создания корпоративного портала, автоматизации внешнего и внутреннего документооборота предприятия]]></description>
<source><![CDATA[&lltt;p&ggtt;На&nbsp;машиностроительном предприятии ОАО &laquo;Калужский двигатель&raquo; продолжается внедрение решения EOS for SharePoint компании ЭОС. ECM-система EOS for SharePoint выбрана для создания корпоративного портала, автоматизации внешнего и&nbsp;внутреннего документооборота предприятия.&lltt;/p&ggtt;]]></source>
<adate>24.07.2013</adate>
<dbid>152876</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Городская Дума Тольятти:  в СЭД «ДЕЛО» будут работать все специалисты]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=152681]]></link>
<description><![CDATA[Мэрия Тольятти активно развивает документооборот на базе СЭД &#171;ДЕЛО&#187; уже 10 лет, и специалисты Думы смогли очень хорошо познакомиться с системой, оценить ее возможности и интерфейс]]></description>
<source><![CDATA[&lltt;p&ggtt;Мэрия Тольятти активно развивает документооборот на&nbsp;базе СЭД &laquo;ДЕЛО&raquo; уже 10&nbsp;лет, и&nbsp;специалисты Думы смогли очень хорошо познакомиться с&nbsp;системой, оценить ее&nbsp;возможности и&nbsp;интерфейс.&lltt;/p&ggtt;]]></source>
<adate>16.07.2013</adate>
<dbid>152681</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[В Администрации Владивостока продолжается внедрение решений ЭОС]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=152450]]></link>
<description><![CDATA[Уже более шести лет Администрация города Владивостока планомерно развивает электронный документооборот в своих структурных подразделениях на базе СЭД «ДЕЛО», решения компании «Электронные Офисные Системы»]]></description>
<source><![CDATA[&lltt;p&ggtt;Уже более шести лет Администрация города Владивостока планомерно развивает электронный документооборот в&nbsp;своих структурных подразделениях на&nbsp;базе СЭД «ДЕЛО», решения компании «Электронные Офисные Системы».&lltt;/p&ggtt;]]></source>
<adate>08.07.2013</adate>
<dbid>152450</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Первый заместитель генерального директора компании ЭОС (ПВ) Юрий Назаров: «Сегодня клиент хочет одновременно работать в разных системах и на разных устройствах»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=152396]]></link>
<description><![CDATA[Неотъемлемой частью деятельности любого разработчика программных продуктов является постоянная работа по усовершенствованию своих продуктов. Процесс вывода на рынок новых версий продуктов продолжается у компании &#171;Электронные Офисные Системы&#187; (ЭОС). При работе над обновлениями в компании уделяют значительное внимание, как общим тенденциям отраслевого рынка, так и запросам клиентов по новому функционалу. Сроки выхода решений и особенности новых версий продуктов стали предметом разговора с первым заместителем генерального директора компании ЭОС (ПВ) Юрием Назаровым]]></description>
<source><![CDATA[&lltt;p&ggtt;Неотъемлемой частью деятельности любого разработчика программных продуктов является постоянная работа по&nbsp;усовершенствованию своих продуктов. Процесс вывода на&nbsp;рынок новых версий продуктов продолжается у&nbsp;компании &laquo;Электронные Офисные Системы&raquo; (ЭОС). При работе над обновлениями в&nbsp;компании уделяют значительное внимание, как общим тенденциям отраслевого рынка, так и&nbsp;запросам клиентов по&nbsp;новому функционалу. Сроки выхода решений и&nbsp;особенности новых версий продуктов стали предметом разговора с&nbsp;первым заместителем генерального директора компании ЭОС (ПВ) Юрием Назаровым.&lltt;/p&ggtt;]]></source>
<adate>04.07.2013</adate>
<dbid>152396</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[М2М Прайвет Банк расширяет сферу применения ЕСМ-системы EOS for SharePoint]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151940]]></link>
<description><![CDATA[ Решение, созданное на базе платформы Microsoft SharePoint, внедрено для комплексного управления документооборотом, а также для автоматизации работы с поручениями и заданиями. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Решение, созданное на базе платформы Microsoft SharePoint, внедрено для комплексного управления документооборотом, а также для автоматизации работы с поручениями и заданиями.&lltt;/p&ggtt;
]]></source>
<adate>20.06.2013</adate>
<dbid>151940</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Администрация Усинска, «нефтяной столицы» Республики Коми, внедряет «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151892]]></link>
<description><![CDATA[ В Администрации муниципального образования городского округа &#171;Усинск&#187; реализуется проект по созданию системы документооборота на базе СЭД «ДЕЛО». Система внедряется сразу во всех ключевых подразделениях с перспективой охвата 100% сотрудников Администрации. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;В Администрации муниципального образования городского округа &laquo;Усинск&raquo; реализуется проект по созданию системы документооборота на базе СЭД «ДЕЛО». Система внедряется сразу во всех ключевых подразделениях с перспективой охвата 100% сотрудников Администрации.&lltt;/p&ggtt;
]]></source>
<adate>19.06.2013</adate>
<dbid>151892</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«Электронное ДЕЛО» внедрил «БИП-Институт правоведения»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151828]]></link>
<description><![CDATA[ Система &#171;Электронное ДЕЛО&#187;, много лет успешно работающая в сотнях организаций Беларуси, смогла и в «Институте правоведения» решить все задачи, поставленные заказчиком. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Система &laquo;Электронное ДЕЛО&raquo;, много лет успешно работающая в&nbsp;сотнях организаций Беларуси, смогла и&nbsp;в&nbsp;«Институте правоведения» решить все задачи, поставленные заказчиком.&lltt;/p&ggtt;
 ]]></source>
<adate>19.06.2013</adate>
<dbid>151828</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Ведущий коммерческий банк Республики Беларусь ОАО «Банк БелВЭБ» более года успешно использует СЭД «Электронное ДЕЛО» в корпоративном режиме]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151497]]></link>
<description><![CDATA[По итогам анализа рынка решений по автоматизации делопроизводства руководство Банка БелВЭБ сделало свой выбор в пользу СЭД &#171;Электронное ДЕЛО&#187; (на базе СЭД &#171;ДЕЛО&#187; компании ЭОС), обладающую необходимым функционалом для решения поставленных задач]]></description>
<source><![CDATA[&lltt;p&ggtt;По&nbsp;итогам анализа рынка решений по&nbsp;автоматизации делопроизводства руководство Банка БелВЭБ сделало свой выбор в&nbsp;пользу СЭД &laquo;Электронное ДЕЛО&raquo; (на&nbsp;базе СЭД &laquo;ДЕЛО&raquo; компании ЭОС), обладающую необходимым функционалом для решения поставленных задач.&lltt;/p&ggtt;]]></source>
<adate>10.06.2013</adate>
<dbid>151497</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[«ДЕЛО» в Забайкальском крае: единой системой документооборота охвачены все региональные органы исполнительной власти]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151475]]></link>
<description><![CDATA[C конца 2010 года региональные органы исполнительной власти начали работу в единой базе данных. Во всех структурах средствами &#171;ДЕЛА&#187; обеспечивается контроль исполнения документов и поручений. Особое место в системе занимает губернаторский контроль, который осуществляется силами Главного контрольного управления Губернатора Забайкальского края]]></description>
<source><![CDATA[&lltt;p&ggtt;C&nbsp;конца 2010 года региональные органы исполнительной власти начали работу в&nbsp;единой базе данных. Во&nbsp;всех структурах средствами &laquo;ДЕЛА&raquo; обеспечивается контроль исполнения документов и&nbsp;поручений. Особое место в&nbsp;системе занимает губернаторский контроль, который осуществляется силами Главного контрольного управления Губернатора Забайкальского края.&lltt;/p&ggtt;]]></source>
<adate>07.06.2013</adate>
<dbid>151475</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Заместитель Председателя правительства Камчатского края Алексей Войтов: «Электронный документооборот сделал нашу работу более оперативной»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151409]]></link>
<description><![CDATA[С января 2013 года в Правительстве Камчатского края работает единая система электронного документооборота, созданная на базе СЭД &#171;ДЕЛО&#187; компании &#171;Электронные офисные системы&#187; (ЭОС), объединяющая 34 исполнительных органа государственной власти и 7 структурных подразделений аппарата губернатора и Правительства Камчатского края]]></description>
<source><![CDATA[&lltt;p&ggtt;С&nbsp;января 2013 года в&nbsp;Правительстве Камчатского края работает единая система электронного документооборота, созданная на&nbsp;базе СЭД &laquo;ДЕЛО&raquo; компании &laquo;Электронные офисные системы&raquo; (ЭОС), объединяющая 34&nbsp;исполнительных органа государственной власти и&nbsp;7&nbsp;структурных подразделений аппарата губернатора и&nbsp;Правительства Камчатского края.&lltt;/p&ggtt;]]></source>
<adate>06.06.2013</adate>
<dbid>151409</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Министерство по развитию Дальнего Востока в мае 2013 года отметило свою первую годовщину. Итоги работы в СЭД «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151406]]></link>
<description><![CDATA[Подводим первые итоги внедрения СЭД &#171;ДЕЛО&#187; в Министерстве по развитию Дальнего Востока: система позволила повысить исполнительскую дисциплину, четко организовать работу со входящей и исходящей корреспонденцией, обращениями граждан, автоматизировать контроль исполнения поручений, т.е. наладить эффективную работу по обращениям граждан]]></description>
<source><![CDATA[&lltt;p&ggtt;Подводим первые итоги внедрения СЭД &laquo;ДЕЛО&raquo; в&nbsp;Министерстве по&nbsp;развитию Дальнего Востока: система позволила повысить исполнительскую дисциплину, четко организовать работу со&nbsp;входящей и&nbsp;исходящей корреспонденцией, обращениями граждан, автоматизировать контроль исполнения поручений, т.е. наладить эффективную работу по&nbsp;обращениям граждан.&lltt;/p&ggtt;]]></source>
<adate>06.06.2013</adate>
<dbid>151406</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Внедрение СЭД «ДЕЛО» в администрации правительства ХМАО-Югры]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151015]]></link>
<description><![CDATA[Администрация Ханты-Мансийского автономного округа &#8212; Югры модернизирует систему электронного документооборота и делопроизводства &#171;ДЕЛО&#187; от компании ЭОС]]></description>
<source><![CDATA[&lltt;p&ggtt;Администрация Ханты-Мансийского автономного округа&nbsp;&mdash; Югры модернизирует систему электронного документооборота и&nbsp;делопроизводства &laquo;ДЕЛО&raquo; от&nbsp;компании ЭОС.&lltt;/p&ggtt;]]></source>
<adate>27.05.2013</adate>
<dbid>151015</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[В Белорусском морском пароходстве начало работать «Электронное ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=151004]]></link>
<description><![CDATA[Еще одно многопрофильное предприятие Республики Беларусь начало работу в СЭД &#171;Электронное ДЕЛО&#187;. О внедрении продукта в ОАО &#171;Белорусское морское пароходство&#187; сообщил партнер ЭОС &#8212; ООО &#171;Электронное ДЕЛО&#187;]]></description>
<source><![CDATA[&lltt;p&ggtt;Еще одно многопрофильное предприятие Республики Беларусь начало работу в&nbsp;СЭД &laquo;Электронное ДЕЛО&raquo;. О&nbsp;внедрении продукта в&nbsp;ОАО &laquo;Белорусское морское пароходство&raquo; сообщил партнер ЭОС&nbsp;&mdash; ООО &laquo;Электронное ДЕЛО&raquo;.&lltt;/p&ggtt;]]></source>
<adate>27.05.2013</adate>
<dbid>151004</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Комплексная система управления собственностью (IPC PM)]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=146228]]></link>
<description><![CDATA[ Система предназначена для автоматизации операционной деятельности по содержанию, восстановлению, развитию имущественных комплексов и управленческих бизнес-процессов по учету, контролю, планированию, мотивации и финансированию этой операционной деятельности. Задачи, которые решает система: 	 Создание единой базы данных правоустанавливающей, технической и страховой документации объектов имущества; 	 Обеспечение эффективного взаимодействия с органами власти; 	 Оптимизация материальных, временных и финансовых затрат на содержание и эксплуатацию объектов имущества путём нормирования и контроля материально &#8212; технического снабжения; 	 Контроль надлежащего уровня оказываемых и приобретаемых услуг, выполнение установленных стандартов и государственных требований по ТОиР недвижимости; 	 Оперативный анализа состояния имущества и его экономических показателей на протяжении всего жизненного цикла; 	 Калькуляция затрат на содержание имущества. Для кого предназначен продукт: 	 Предприятия ЖКХ; 	 Девелоперские компании; 	 Крупные компании с корпоративной недвижимостью; 	 Федеральные и Муниципальные учреждения; 	 Ритейл. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Система предназначена для автоматизации операционной деятельности по&nbsp;содержанию, восстановлению, развитию имущественных комплексов и&nbsp;управленческих бизнес-процессов по&nbsp;учету, контролю, планированию, мотивации и&nbsp;финансированию этой операционной деятельности. &lltt;/p&ggtt;
 
&lltt;p&ggtt; Задачи, которые решает система: &lltt;/p&ggtt;
 
&lltt;ul&ggtt; 	
  &lltt;li&ggtt;Создание единой базы данных правоустанавливающей, технической и&nbsp;страховой документации объектов имущества;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Обеспечение эффективного взаимодействия с&nbsp;органами власти;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Оптимизация материальных, временных и&nbsp;финансовых затрат на&nbsp;содержание и&nbsp;эксплуатацию объектов имущества путём нормирования и&nbsp;контроля материально&nbsp;&mdash; технического снабжения;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Контроль надлежащего уровня оказываемых и&nbsp;приобретаемых услуг, выполнение установленных стандартов и&nbsp;государственных требований по&nbsp;ТОиР недвижимости;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Оперативный анализа состояния имущества и&nbsp;его экономических показателей на&nbsp;протяжении всего жизненного цикла;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Калькуляция затрат на&nbsp;содержание имущества.&lltt;/li&ggtt;
 &lltt;/ul&ggtt;
 
&lltt;p&ggtt; Для кого предназначен продукт: &lltt;/p&ggtt;
 
&lltt;ul&ggtt; 	
  &lltt;li&ggtt;Предприятия ЖКХ;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Девелоперские компании;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Крупные компании с&nbsp;корпоративной недвижимостью;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Федеральные и&nbsp;Муниципальные учреждения;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt;Ритейл.&lltt;/li&ggtt;
 &lltt;/ul&ggtt;
]]></source>
<adate>24.01.2013</adate>
<dbid>146228</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Использование СЭД ЭСКАДО в ОАО «Медицина» для организации совещаний/заседаний]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=146227]]></link>
<description><![CDATA[ Модуль &#171;Заседания&#187; обеспечивает работу с документами, используемыми при подготовке и проведении заседаний (совещаний). Автоматизированы бизнес-процессы, касающиеся составления и согласования планов и повесток совещаний, а также формирования сводных отчетов и протоколов совещаний. Успех совещания на 90% зависит от качества его подготовки. Благодаря технологиям электронного документооборота все участники совещания заранее предупреждены о повестке дня, в систему загружены все необходимые для совещания материалы, составлен и согласован со всеми участниками протокол обсуждения. Такая подготовка приводит к тому, что: 	 на совещание приходят владеющие нужной информацией работники; 	 сокращается время на обсуждение, т.к. участники сосредоточены на ключевых вопросах; 	 принятое решение исполняется; 	 участники включены в совместную работу. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Модуль &laquo;Заседания&raquo; обеспечивает работу с&nbsp;документами, используемыми при подготовке и&nbsp;проведении заседаний (совещаний). Автоматизированы бизнес-процессы, касающиеся составления и&nbsp;согласования планов и&nbsp;повесток совещаний, а&nbsp;также формирования сводных отчетов и&nbsp;протоколов совещаний. &lltt;/p&ggtt;
 
&lltt;p&ggtt; Успех совещания на&nbsp;90% зависит от&nbsp;качества его подготовки. Благодаря технологиям электронного документооборота все участники совещания заранее предупреждены о&nbsp;повестке дня, в&nbsp;систему загружены все необходимые для совещания материалы, составлен и&nbsp;согласован со&nbsp;всеми участниками протокол обсуждения. &lltt;/p&ggtt;
 
&lltt;p&ggtt; Такая подготовка приводит к&nbsp;тому, что: &lltt;/p&ggtt;
 
&lltt;ul&ggtt; 	
  &lltt;li&ggtt; на&nbsp;совещание приходят владеющие нужной информацией работники;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt; сокращается время на&nbsp;обсуждение, т.к. участники сосредоточены на&nbsp;ключевых вопросах;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt; принятое решение исполняется;&lltt;/li&ggtt;
 	
  &lltt;li&ggtt; участники включены в&nbsp;совместную работу.&lltt;/li&ggtt;
 &lltt;/ul&ggtt;
]]></source>
<adate>24.01.2013</adate>
<dbid>146227</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Здесь и сейчас или где-нибудь потом?]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=132534]]></link>
<description><![CDATA[ Наверняка Вам когда-нибудь доводилось оказаться на ответственной встрече без визитных карточек. Или с визиткой, на которой какая-то часть информации потеряла актуальность. Согласитесь, не самое приятное воспоминание. И если традиционным выходом из такой ситуации для вас является очередной заказ большой партии визитных карточек на стороне с ожиданием заказа в течение нескольких дней, то вам может очень понравиться альтернативный вариант. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Наверняка Вам когда-нибудь доводилось оказаться на ответственной встрече без визитных карточек. Или с визиткой, на которой какая-то часть информации потеряла актуальность. Согласитесь, не самое приятное воспоминание. И если традиционным выходом из такой ситуации для вас является очередной заказ большой партии визитных карточек на стороне с ожиданием заказа в течение нескольких дней, то вам может очень понравиться альтернативный вариант. &lltt;/p&ggtt;
 ]]></source>
<adate>11.07.2011</adate>
<dbid>132534</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Федеральная служба России по контролю за оборотом наркотиков продолжает реализацию мероприятий по переходу на электронный документооборот на базе СЭД «ДЕЛО»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=150830]]></link>
<description><![CDATA[В центральном аппарате и территориальных управлениях Федеральной службы Российской Федерации по контролю за оборотом наркотиков (ФСКН России) документооборот автоматизирован с использованием СЭД &#171;ДЕЛО&#187;, разработанной компанией &#171;Электронные Офисные Системы&#187;. Для более полного охвата системой &#171;ДЕЛО&#187; подразделений службы принято решение об увеличении числа пользователей СЭД]]></description>
<source><![CDATA[&lltt;p&ggtt;В&nbsp;центральном аппарате и&nbsp;территориальных управлениях Федеральной службы Российской Федерации по&nbsp;контролю за&nbsp;оборотом наркотиков (ФСКН России) документооборот автоматизирован с&nbsp;использованием СЭД &laquo;ДЕЛО&raquo;, разработанной компанией &laquo;Электронные Офисные Системы&raquo;. Для более полного охвата системой &laquo;ДЕЛО&raquo; подразделений службы принято решение об&nbsp;увеличении числа пользователей СЭД.&lltt;/p&ggtt;]]></source>
<adate>21.05.2013</adate>
<dbid>150830</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Индустриальный парк в Новосибирской области продолжает строиться «под управлением» системы «eDocLib: Актив Бизнес»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=150829]]></link>
<description><![CDATA[&#171;Управляющая компания &#171;Промышленно-логистический парк&#187; (УК ПЛП) приняла решение о расширении использования ECM-системы &#171;eDocLib: Актив Бизнес&#187;. В апреле текущего года были закуплены дополнительные рабочие места системы, а также комплект лицензий модуля интеграции с MS Outlook. С момента начала эксплуатации системы в компании это уже третий этап ее масштабирования]]></description>
<source><![CDATA[&lltt;p&ggtt;&laquo;Управляющая компания &laquo;Промышленно-логистический парк&raquo; (УК&nbsp;ПЛП) приняла решение о&nbsp;расширении использования ECM-системы &laquo;eDocLib: Актив Бизнес&raquo;. В&nbsp;апреле текущего года были закуплены дополнительные рабочие места системы, а&nbsp;также комплект лицензий модуля интеграции с&nbsp;MS&nbsp;Outlook. С&nbsp;момента начала эксплуатации системы в&nbsp;компании это уже третий этап ее&nbsp;масштабирования.&lltt;/p&ggtt;]]></source>
<adate>21.05.2013</adate>
<dbid>150829</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Eaton Ellipse ECO – новое поколение энергосберегающих ИБП]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=131861]]></link>
<description><![CDATA[Многоотраслевая корпорация Eaton выводит на российский рынок новейшую версию своего самого популярного продукта &#8211; ИБП Eaton Ellipse ECO. Благодаря встроенной функции EcoControl, модернизированный ИБП Eaton Ellipse Eco обеспечивает 25% экономию энергии в сравнении с изделиями предшествующего поколения. Эта экономия достигается за счет автоматического отключения периферийного оборудования при выключении ведущего устройства. Компактный ИБП Ellipse ECO обеспечивает защиту питания для различного производственного и коммерческого электронного оборудования, включая ПК, рабочие станции, телефонную аппаратуру и кассовые терминалы. Подобно своему предшественнику, ИБП Ellipse ECO имеет топологию off-line и защищает офисное оборудование от основных проблем в электроснабжении, таких как пропадание, провал и всплеск напряжения. Eaton Ellipse ECO поставляется в 5 вариантах мощности &#8211; от 500 до 1600 ВА. ]]></description>
<source><![CDATA[&lltt;p&ggtt;Многоотраслевая корпорация Eaton выводит на российский рынок новейшую версию своего самого популярного продукта &ndash; ИБП Eaton Ellipse ECO. Благодаря встроенной функции EcoControl, модернизированный ИБП Eaton Ellipse Eco обеспечивает 25% экономию энергии в сравнении с изделиями предшествующего поколения. Эта экономия достигается за счет автоматического отключения периферийного оборудования при выключении ведущего устройства. Компактный ИБП Ellipse ECO обеспечивает защиту питания для различного производственного и коммерческого электронного оборудования, включая ПК, рабочие станции, телефонную аппаратуру и кассовые терминалы. Подобно своему предшественнику, ИБП Ellipse ECO имеет топологию off-line и защищает офисное оборудование от основных проблем в электроснабжении, таких как пропадание, провал и всплеск напряжения. Eaton Ellipse ECO поставляется в 5 вариантах мощности &ndash; от 500 до 1600 ВА.&lltt;/p&ggtt;
]]></source>
<adate>09.06.2011</adate>
<dbid>131861</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Программа «Let’s Green with HP»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=132796]]></link>
<description><![CDATA[ Компания Hewlett Packard, признанный лидер на мировом рынке в области компьютерных технологий, запустила программу &#171;Let&#8217;s Green with HP&#187; по утилизации ноутбуков. Теперь любая компания может сдать на утилизацию старые ноутбуки любой торговой марки и купить новые модели HP со скидкой в 5 000 рублей. В программе могут принять участие только юридические лица, предварительно пройдя регистрацию на сайте www.lets-green.ru. В форме регистрации необходимо указать свои контактные данные, старые модели ноутбуков на замену, новые модели ноутбуков HP, утилизирующую компанию, розничный магазин. Let&#8217;s Green with HP! ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Компания Hewlett Packard, признанный лидер на&nbsp;мировом рынке в&nbsp;области компьютерных технологий, запустила программу &laquo;Let&rsquo;s Green with&nbsp;HP&raquo; по&nbsp;утилизации ноутбуков. Теперь любая компания может сдать на&nbsp;утилизацию старые ноутбуки любой торговой марки и&nbsp;купить новые модели&nbsp;HP со&nbsp;скидкой в&nbsp;5&nbsp;000&nbsp;рублей. &lltt;/p&ggtt;
 
&lltt;p&ggtt;В&nbsp;программе могут принять участие только юридические лица, предварительно пройдя регистрацию на&nbsp;сайте www.lets-green.ru. В&nbsp;форме регистрации необходимо указать свои контактные данные, старые модели ноутбуков на&nbsp;замену, новые модели ноутбуков&nbsp;HP, утилизирующую компанию, розничный магазин. &lltt;/p&ggtt;
 
&lltt;p&ggtt;Let&rsquo;s Green with&nbsp;HP!&lltt;/p&ggtt;
 ]]></source>
<adate>02.08.2011</adate>
<dbid>132796</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Интеграционное решение для платформы 1С]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=146203]]></link>
<description><![CDATA[ Функционал решения Интерпроком позволяет создавать приложения, взаимодействующие с 1С, реализовать специализированный АРМ сотрудника, витрину интернет &#8212; магазина или даже альтернативный клиент 1С. В настоящее время платформа 1С представлена широкой линейкой программных средств различного назначения. Ряд её качеств, таких как возможность настройки, расширения и создания новых программных средств на базе единой платформы, регулярные обновления программы, сделали 1С очень популярной в нашей стране и в СНГ. При этом перед IT подразделениями часто возникает задача связать воедино данные, лежащие внутри и за рамками хранилища 1С. Ещё одна задача — отобразить данные 1С в витрине интернет — магазина или включить 1С в бизнес-процесс, реализованный на внешних серверах. Применение разработки Интерпроком полностью исключает необходимость вмешательства в конфигурацию 1С и программирование на встроенном языке, что особенно важно для многих компаний, в которых поддержка 1С систем осуществляется внешними организациями. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Функционал решения Интерпроком позволяет создавать приложения, взаимодействующие с&nbsp;1С, реализовать специализированный АРМ сотрудника, витрину интернет&nbsp;&mdash; магазина или даже альтернативный клиент 1С. &lltt;/p&ggtt;
 
&lltt;p&ggtt; В&nbsp;настоящее время платформа 1С&nbsp;представлена широкой линейкой программных средств различного назначения. Ряд её&nbsp;качеств, таких как возможность настройки, расширения и&nbsp;создания новых программных средств на&nbsp;базе единой платформы, регулярные обновления программы, сделали 1С&nbsp;очень популярной в&nbsp;нашей стране и&nbsp;в&nbsp;СНГ. &lltt;/p&ggtt;
 
&lltt;p&ggtt; При этом перед&nbsp;IT подразделениями часто возникает задача связать воедино данные, лежащие внутри и&nbsp;за&nbsp;рамками хранилища 1С. Ещё одна задача&nbsp;— отобразить данные 1С&nbsp;в&nbsp;витрине интернет&nbsp;— магазина или включить 1С&nbsp;в&nbsp;бизнес-процесс, реализованный на&nbsp;внешних серверах. &lltt;/p&ggtt;
 
&lltt;p&ggtt; Применение разработки Интерпроком полностью исключает необходимость вмешательства в&nbsp;конфигурацию 1С&nbsp;и&nbsp;программирование на&nbsp;встроенном языке, что особенно важно для многих компаний, в&nbsp;которых поддержка 1С&nbsp;систем осуществляется внешними организациями.&lltt;/p&ggtt;
]]></source>
<adate>24.01.2013</adate>
<dbid>146203</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Внедрение требований соглашения SLA в план контроля базы данных]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=116569]]></link>
<description><![CDATA[Контроль баз данных — это важная часть в процессе поддержания систем предприятия на нужном уровне. Если контроль баз данных эффективен, администратор рабочих баз данных может принимать стратегические решения на основе значимой информации, получаемой в режиме реального времени, а также устанавливать приоритеты реагирования на изменения в системной среде на основе влияния на деятельность предприятия, пользователей и соблюдение требований соглашения SLA]]></description>
<source><![CDATA[&lltt;p&ggtt;Контроль баз данных — это важная часть в процессе поддержания систем предприятия на нужном уровне. Если контроль баз данных эффективен, администратор рабочих баз данных может принимать стратегические решения на основе значимой информации, получаемой в режиме реального времени, а также устанавливать приоритеты реагирования на изменения в системной среде на основе влияния на деятельность предприятия, пользователей и соблюдение требований соглашения SLA.]]></source>
<adate>01.12.2008</adate>
<dbid>116569</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Быстрое профилирование SQL для повышения производительности баз данных]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=116528]]></link>
<description><![CDATA[В этом документе рассказывается о трёх способах оптимизации производительности баз данных: 1. Выявление операторов SQL, снижающих производительность базы данных, с последующим графическим представлением анализа времени ожидания. 2. Поиск детализированной информации об активности каждого оператора SQL, оформленной в виде столбцов со ссылками. 3. Профилирование с помощью пользовательского средства, управляемого без агента, которое после простой установки обеспечит поддержку различных платформ RDMS. ]]></description>
<source><![CDATA[&lltt;p&ggtt;В этом документе рассказывается о трёх способах оптимизации производительности баз данных: &lltt;/p&ggtt;

&lltt;p&ggtt;1. Выявление операторов SQL, снижающих производительность базы данных, с последующим графическим представлением анализа времени ожидания. &lltt;/p&ggtt;

&lltt;p&ggtt;2. Поиск детализированной информации об активности каждого оператора SQL, оформленной в виде столбцов со ссылками. &lltt;/p&ggtt;

&lltt;p&ggtt;3. Профилирование с помощью пользовательского средства, управляемого без агента, которое после простой установки обеспечит поддержку различных платформ RDMS. &lltt;/p&ggtt;
]]></source>
<adate>27.11.2008</adate>
<dbid>116528</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Paragon System Recovery: бесперебойная работа IT – инфраструктуры]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=115397]]></link>
<description><![CDATA[Обслуживание многочисленного парка вычислительных машин в рамках даже небольшой компании выливается в значительные траты времени и денежных средств. Однако, сегодня все проблемы легко решаются с помощью специализированного программного обеспечения]]></description>
<source><![CDATA[Обслуживание многочисленного парка вычислительных машин в рамках даже небольшой компании выливается в значительные траты времени и денежных средств. Однако, сегодня все проблемы легко решаются с помощью специализированного программного обеспечения.]]></source>
<adate>23.10.2008</adate>
<dbid>115397</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Возьмите в союзники вендора]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=106387]]></link>
<description><![CDATA[За последние три года представительство корпорации Oracle в странах СНГ заметно укрепило партнерскую сеть разработчиков приложений (Independent Software Vendors, ISV), использующих ее базовые технологии: за это время более чем втрое выросло как число таких партнеров, так и количество созданных ими решений. О том, чем привлекательна партнерская программа Oracle и какие преимущества дает разработчикам участие в ней, нам рассказал Константин Новиков, руководитель отдела по работе с компаниями-разработчиками “Oracle СНГ”]]></description>
<source><![CDATA[За последние три года представительство корпорации Oracle в странах СНГ заметно укрепило партнерскую сеть разработчиков приложений (Independent Software Vendors, ISV), использующих ее базовые технологии: за это время более чем втрое выросло как число таких партнеров, так и количество созданных ими решений. О том, чем привлекательна партнерская программа Oracle и какие преимущества дает разработчикам участие в ней, нам рассказал Константин Новиков, руководитель отдела по работе с компаниями-разработчиками “Oracle СНГ”.]]></source>
<adate>04.02.2008</adate>
<dbid>106387</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Перспективы и преимущества эффективности информационных технологий]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=119347]]></link>
<description><![CDATA[Представленный информационный бюллетень помогает понять, какие преимущества можно получить от повышения общей эффективности использования информации по всем направлениям информационных технологий и бизнеса, что немаловажно в нынешней сложной экономической обстановке]]></description>
<source><![CDATA[&lltt;p&ggtt;Представленный информационный бюллетень помогает понять, какие преимущества можно получить от повышения общей эффективности использования информации по всем направлениям информационных технологий и бизнеса, что немаловажно в нынешней сложной экономической обстановке. ]]></source>
<adate>05.06.2009</adate>
<dbid>119347</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Система хранения данных EMC Symmetrix V-Max 24-x-навсегда для виртуализованных центров обработки данных]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=119185]]></link>
<description><![CDATA[Руководители ИТ-отделов полагаются на СХД EMC Symmetrix, соответствующие требованиям приложений корпоративного класса к отказоустойчивости, масштабируемости и производительности, уже на протяжении более чем 10 лет. Данный отчет посвящен результатам практического тестирования и апробации новой революционной архитектуры Symmetrix с акцентом на нововведения, способные в максимальной степени заинтересовать предприятия, пользующиеся виртуализованными серверами и объединенными информационными инфраструктурами. ]]></description>
<source><![CDATA[&lltt;p&ggtt;Руководители ИТ-отделов полагаются на СХД EMC Symmetrix, соответствующие требованиям приложений корпоративного класса к отказоустойчивости, масштабируемости и производительности, уже на протяжении более чем 10 лет. Данный отчет посвящен результатам практического тестирования и апробации новой революционной архитектуры Symmetrix с акцентом на нововведения, способные в максимальной степени заинтересовать предприятия, пользующиеся виртуализованными серверами и объединенными информационными инфраструктурами. &lltt;/p&ggtt;
]]></source>
<adate>25.05.2009</adate>
<dbid>119185</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[EMC VFCache — краткий обзор]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=143949]]></link>
<description><![CDATA[ Несмотря на то, что производительность систем хранения данных постоянно растёт, темпы этого роста всё равно отстают от темпов роста вычислительной мощности серверов. Это приводит к тому, что узким местом становится именно СХД, не успевающая обработать запросы ввода/вывода в случае пиковых нагрузок. В ИТ-сообществе эта проблема получила название &#171;отставание ввода-вывода&#187; (I/O gap). Для подобных ситуациях компания EMC предлагает использовать решение VFCache, позволяющее кэшировать данные ещё до отправки их на СХД. VFCache представляет собой специализированную плату, устанавливаемую внутрь сервера.Программное обеспечение, устанавливаемое на сервере, использует карту VFCache в качестве кэш-памяти для наиболее часто используемых данных, сокращая время доступа к хранилищу и снимая с массива хранения данных нагрузку по обработке операций ввода-вывода. В результате, снижается нагрузка на кэш-память СХД и на SAN, что позволяет снизить задержки обработки запросов и повысить производительность всей инфраструктуры в целом, обеспечить защиту данных критически важных приложений. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Несмотря на&nbsp;то, что производительность систем хранения данных постоянно растёт, темпы этого роста всё равно отстают от&nbsp;темпов роста вычислительной мощности серверов. &lltt;/p&ggtt;
 
&lltt;p&ggtt; Это приводит к&nbsp;тому, что узким местом становится именно СХД, не&nbsp;успевающая обработать запросы ввода/вывода в&nbsp;случае пиковых нагрузок. &lltt;/p&ggtt;
 
&lltt;p&ggtt; В&nbsp;ИТ-сообществе эта проблема получила название &laquo;отставание ввода-вывода&raquo; (I/O gap). &lltt;/p&ggtt;
 
&lltt;p&ggtt; Для подобных ситуациях компания EMC предлагает использовать решение VFCache, позволяющее кэшировать данные ещё до&nbsp;отправки их&nbsp;на&nbsp;СХД. &lltt;/p&ggtt;
 
&lltt;p&ggtt; VFCache представляет собой специализированную плату, устанавливаемую внутрь сервера.Программное обеспечение, устанавливаемое на&nbsp;сервере, использует карту VFCache в&nbsp;качестве кэш-памяти для наиболее часто используемых данных, сокращая время доступа к&nbsp;хранилищу и&nbsp;снимая с&nbsp;массива хранения данных нагрузку по&nbsp;обработке операций ввода-вывода. &lltt;/p&ggtt;
 
&lltt;p&ggtt; В&nbsp;результате, снижается нагрузка на&nbsp;кэш-память СХД и&nbsp;на&nbsp;SAN, что позволяет снизить задержки обработки запросов и&nbsp;повысить производительность всей инфраструктуры в&nbsp;целом, обеспечить защиту данных критически важных приложений.&lltt;/p&ggtt;
 ]]></source>
<adate>01.11.2012</adate>
<dbid>143949</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[EMC Isilon - следующий шаг в эволюции систем хранения данных]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=143764]]></link>
<description><![CDATA[ На смену двухконтроллерным СХД постепенно приходят системы, основанные на кластерной архитектуре. Такие системы расширяются равномерно, постепенно увеличивая не только хранимую ёмкость, но и вычислительную мощность системы. Это позволяет избежать &#171;бутылочного горлышка&#187;, которым являлись контроллеры СХД раньше. Одним из примеров таких систем может служить EMC Isilon, представляющая собой следующий этап развития систем для консолидации данных. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;На&nbsp;смену двухконтроллерным СХД постепенно приходят системы, основанные на&nbsp;кластерной архитектуре. Такие системы расширяются равномерно, постепенно увеличивая не&nbsp;только хранимую ёмкость, но&nbsp;и&nbsp;вычислительную мощность системы. &lltt;/p&ggtt;
 
&lltt;p&ggtt;Это позволяет избежать &laquo;бутылочного горлышка&raquo;, которым являлись контроллеры СХД раньше. Одним из&nbsp;примеров таких систем может служить EMC&nbsp;Isilon, представляющая собой следующий этап развития систем для консолидации данных. &lltt;/p&ggtt;
 ]]></source>
<adate>29.10.2012</adate>
<dbid>143764</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Взгляд ЕМС на дедупликацию данных при резервном копировании]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=119348]]></link>
<description><![CDATA[Данный информационный бюллетень посвящен причинам, по которым предприятия нуждаются в дедупликации, а также достоинствам дедупликации как компонента стратегии резервного копирования. В бюллетене приведены краткие сведения о системах резервного копирования EMC со встроенными средствами дедупликации, оптимизированными для применения с разными приложениями и удовлетворения требований к резервному копированию и восстановлению данных. ]]></description>
<source><![CDATA[&lltt;p&ggtt;Данный информационный бюллетень посвящен причинам, по которым предприятия нуждаются в дедупликации, а также достоинствам дедупликации как компонента стратегии резервного копирования. В бюллетене приведены краткие сведения о системах резервного копирования EMC со встроенными средствами дедупликации, оптимизированными для применения с разными приложениями и удовлетворения требований к резервному копированию и восстановлению данных. &lltt;/p&ggtt;
]]></source>
<adate>08.06.2009</adate>
<dbid>119348</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Symmetrix V-Max: виртуализованный центр обработки данных будущего]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=119187]]></link>
<description><![CDATA[ Новая система Symmetrix V-Max компании ЕМС построена на основе принципиально новой виртуальной матричной архитектуры. В ней используются виртуальные матричные интерфейсы, через которые система взаимодействует с механизмами подключения. Это позволяет формировать наборы стандартных ресурсов (портов, ресурсов памяти, дисков), которыми можно управлять как единым целым. Ресурсы хранения данных можно динамически подключать и отключать на большом расстоянии без влияния на работу приложений, что позволяет говорить о настоящей круглосуточной доступности. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Новая система Symmetrix V-Max компании ЕМС построена на основе принципиально новой виртуальной матричной архитектуры. В ней используются виртуальные матричные интерфейсы, через которые система взаимодействует с механизмами подключения. Это позволяет формировать наборы стандартных ресурсов (портов, ресурсов памяти, дисков), которыми можно управлять как единым целым. Ресурсы хранения данных можно динамически подключать и отключать на большом расстоянии без влияния на работу приложений, что позволяет говорить о настоящей круглосуточной доступности.&lltt;/p&ggtt;
]]></source>
<adate>25.05.2009</adate>
<dbid>119187</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Cisco, EMC и VMware развивают облачные инфраструктуры]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=119186]]></link>
<description><![CDATA[ Виртуализация серверов &#8212; один из важнейших этапов создания облака, поскольку она позволяет собрать воедино все интеллектуальные механизмы управления безопасностью, соблюдением нормативных требований, производительностью и коэффициентом готовности серверов, сетей и систем хранения данных. Три лидера отрасли — VMware, Cisco и EMC — начали совместную работу над выпуском протестированных и полностью совместимых решений, способных ускорить переход к облачным вычислительным средам. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Виртуализация серверов &mdash; один из важнейших этапов создания облака, поскольку она позволяет собрать воедино все интеллектуальные механизмы управления безопасностью, соблюдением нормативных требований, производительностью и коэффициентом готовности серверов, сетей и систем хранения данных. Три лидера отрасли — VMware, Cisco и EMC — начали совместную работу над выпуском протестированных и полностью совместимых решений, способных ускорить переход к облачным вычислительным средам. &lltt;/p&ggtt;
]]></source>
<adate>25.05.2009</adate>
<dbid>119186</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Виртуализация центров обработки данных - новая эпоха &#34;виртуальных&#34; корпоративных СХД высшего класса]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=119006]]></link>
<description><![CDATA[В последнее время разработчики корпоративных систем хранения данных высшего класса стали уделять внимание тому, насколько их продукты способны помочь клиентам оптимизировать инфраструктуру хранения данных для виртуального вычислительного центра. Последним и наиболее ярким примером этой тенденции стала EMC Symmetrix V-Max &#8212; новейшая версия флагманской системы хранения данных этого ведущего разработчика. ]]></description>
<source><![CDATA[&lltt;p&ggtt;В последнее время разработчики корпоративных систем хранения данных высшего класса стали уделять внимание тому, насколько их продукты способны помочь клиентам оптимизировать инфраструктуру хранения данных для виртуального вычислительного центра. Последним и наиболее ярким примером этой тенденции стала EMC Symmetrix V-Max &mdash; новейшая версия флагманской системы хранения данных этого ведущего разработчика. &lltt;/p&ggtt;
]]></source>
<adate>12.05.2009</adate>
<dbid>119006</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[EMC оптимизирует Symmetrix для виртуализированных центров обработки данных: Symmetrix V-Max]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=118995]]></link>
<description><![CDATA[Корпорация EMC представила новую версию своей популярной системы хранения данных высшего класса Symmetrix. Пожалуй, самая известная платформа EMC существует уже около 20 лет, но модель Symmetrix V-Max оптимизирована с учетом новейших тенденций развития вычислительных центров и ориентирована на новую экономическую модель: так называемые виртуальные центры обработки данных. ]]></description>
<source><![CDATA[&lltt;p&ggtt;Корпорация EMC представила новую версию своей популярной системы хранения данных высшего класса Symmetrix. Пожалуй, самая известная платформа EMC существует уже около 20 лет, но модель Symmetrix V-Max оптимизирована с учетом новейших тенденций развития вычислительных центров и ориентирована на новую экономическую модель: так называемые виртуальные центры обработки данных.
]]></source>
<adate>08.05.2009</adate>
<dbid>118995</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[ЕМС Symmetrix V-Max - информационная структура для]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=118994]]></link>
<description><![CDATA[ Новая энергоэффективная система хранения данных Symmetrix V-Max представляет собой самый быстрый массив высшего класса в мире и позволяет решать уникальные задачи в сфере хранения данных для виртуальных ЦОД. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;Новая энергоэффективная система хранения данных Symmetrix V-Max представляет собой самый быстрый массив высшего класса в мире и позволяет решать уникальные задачи в сфере хранения данных для виртуальных ЦОД.&lltt;/p&ggtt;
]]></source>
<adate>08.05.2009</adate>
<dbid>118994</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Sun делает ставку на кластерные технологии]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=110827]]></link>
<description><![CDATA[В середине прошлого десятилетия компания Sun Microsystems стала одним из лидеров рынка высокопроизводительных вычислений (HPC) в результате феноменального успеха сервера корпоративного класса Sun Enterprise 10000 (Starfire). Эта система первоначально разрабатывалась корпорацией Cray именно как суперкомпьютер на базе процессоров UltraSPARC II, а после того как Sun приобрела отделение Cray, занимавшееся проектом Starfire, она стала предлагаться как сервер для корпоративного центра обработки данных, обеспечивающий благодаря технологии “динамических доменов” не только высокую производительность, но и уровень надежности и доступности, необходимый для критически важных бизнес-приложений]]></description>
<source><![CDATA[В середине прошлого десятилетия компания Sun Microsystems стала одним из лидеров рынка высокопроизводительных вычислений (HPC) в результате феноменального успеха сервера корпоративного класса Sun Enterprise 10000 (Starfire). Эта система первоначально разрабатывалась корпорацией Cray именно как суперкомпьютер на базе процессоров UltraSPARC II, а после того как Sun приобрела отделение Cray, занимавшееся проектом Starfire, она стала предлагаться как сервер для корпоративного центра обработки данных, обеспечивающий благодаря технологии “динамических доменов” не только высокую производительность, но и уровень надежности и доступности, необходимый для критически важных бизнес-приложений.]]></source>
<adate>10.06.2008</adate>
<dbid>110827</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[Виртуализация рабочих мест]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=150151]]></link>
<description><![CDATA[Виртуализация десктопов (Virtual Desktop Infrastructure &#8212; VDI) &#8212; это создание рабочих столов в виртуальной среде. С помощью технологии виртуализации рабочих мест сотрудник, имея любое устройство с доступом в Интернет &#8212; смартфон, планшетный компьютер, тонкий клиент, &#8212; может получить доступ к персональному рабочему столу и корпоративным информационным ресурсам. Внедрение VDI позволяет компании упростить создание и администрирование рабочих мест пользователей, обеспечить гибкость своей IT-инфраструктуры]]></description>
<source><![CDATA[&lltt;p&ggtt;Виртуализация десктопов (Virtual Desktop Infrastructure&nbsp;&mdash; VDI)&nbsp;&mdash; это создание рабочих столов в&nbsp;виртуальной среде. С&nbsp;помощью технологии виртуализации рабочих мест сотрудник, имея любое устройство с&nbsp;доступом в&nbsp;Интернет&nbsp;&mdash; смартфон, планшетный компьютер, тонкий клиент,&nbsp;&mdash; может получить доступ к&nbsp;персональному рабочему столу и&nbsp;корпоративным информационным ресурсам. Внедрение VDI позволяет компании упростить создание и&nbsp;администрирование рабочих мест пользователей, обеспечить гибкость своей IT-инфраструктуры.&lltt;/p&ggtt;]]></source>
<adate>23.04.2013</adate>
<dbid>150151</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[С новым поколением дисковых массивов Dell EqualLogic хранение корпоративных данных стало проще и эффективнее]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=139608]]></link>
<description><![CDATA[ Новые решения Dell для хранения корпоративных данных, включая дисковые массивы нового поколения Dell EqualLogic, дают в руки заказчиков инструменты управления корпоративными данным принципиально нового уровня &#8211; информация оказывается под полным контролем, а потому корпоративные приложения всегда будут в боевой готовности, абсолютно доступные для принятия бизнесом правильных решений. С их помощью предприятия и организации смогут легко и бесшовно с минимальными финансовыми вложениями перейти к построению современной масштабируемой и виртуализированной инфраструктуры хранения, которая обеспечит стабильную и надежную ИТ-поддержку бизнеса в условиях непредсказуемо меняющейся информационной среды. ]]></description>
<source><![CDATA[ 
&lltt;p&ggtt;Новые решения Dell для хранения корпоративных данных, включая дисковые массивы нового поколения Dell EqualLogic, дают в руки заказчиков инструменты управления корпоративными данным принципиально нового уровня &ndash; информация оказывается под полным контролем, а потому корпоративные приложения всегда будут в боевой готовности, абсолютно доступные для принятия бизнесом правильных решений. С их помощью предприятия и организации смогут легко и бесшовно с минимальными финансовыми вложениями перейти к построению современной масштабируемой и виртуализированной инфраструктуры хранения, которая обеспечит стабильную и надежную ИТ-поддержку бизнеса в условиях непредсказуемо меняющейся информационной среды.&lltt;/p&ggtt;
 ]]></source>
<adate>28.05.2012</adate>
<dbid>139608</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
<item>
<title><![CDATA[СМ компьютер. Сервер под VMware – создайте собственное «облако»]]></title>
<link><![CDATA[https://www.itweek.ru/white-papers/detail.php?ID=137713]]></link>
<description><![CDATA[ IT-инфраструктура малых и средних предприятий обычно включает в себя несколько физических серверов. Платформа виртуализации VMware позволит значительно сэкономить ресурсы предприятия при помощи переноса всей программной среды с физических устройств в масштабируемую виртуальную среду, объединив управление всеми задачами в одном физическом сервере. ]]></description>
<source><![CDATA[
&lltt;p&ggtt;IT-инфраструктура малых и средних предприятий обычно включает в себя несколько физических серверов. Платформа виртуализации VMware позволит значительно сэкономить ресурсы предприятия при помощи переноса всей программной среды с физических устройств в масштабируемую виртуальную среду, объединив управление всеми задачами в одном физическом сервере.&lltt;/p&ggtt;
 ]]></source>
<adate>16.03.2012</adate>
<dbid>137713</dbid>
<rubric>4</rubric>
<orubric>76</orubric>
<picture></picture>
<images></images>
<imagesname></imagesname>
<tag><![CDATA[]]></tag>
</item>
</channel>
</rss>
