https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif https://www.itweek.ru https://www.itweek.ru/themes/detail.php?ID=235426 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>С 1 сентября в России вступают в силу изменения в законодательстве, которые затронут всех владельцев доменов в зонах </em><em>.RU, .SU и .РФ. Согласно Федеральному закону № <nobr>569-ФЗ,</nobr> регистрация и дальнейшее управление доменными именами будут возможны только после идентификации администратора через ЕСИА («Госуслуги</em><em>»)</em><em>. При этом подзаконные акты, которые должны определить порядок применения новых требований, пока находятся в стадии разработки. </em><em>Рассмотрим</em><em>, какие риски это создает для бизнеса и что предпринимателям стоит сделать уже сейчас.</em></p> <p>Идея обязательной идентификации направлена на снижение количества анонимных регистраций и мошенничества с доменными именами. После внедрения механизма каждый администратор домена будет подтверждать свою личность через «Госуслуги» — ЕСИА, что, по замыслу авторов нововведения, должно повысить прозрачность российского доменного пространства.</p> <p>Рынок уже начал готовиться к изменениям. Наблюдается заметный рост количества обращений клиентов к регистраторам по вопросам переоформления доменов и актуализации регистрационных данных. Серьезной нагрузки на службы поддержки пока нет, окончательные правила регистрации будут утверждены до 1 сентября. И у регистраторов остается время на полноценное тестирование новых процессов и интеграцию с государственными информационными системами.</p> <h3>Какие риски влекут новые правила</h3> <p>Главный риск для компаний связан не со штрафами — их закон не предусматривает, — но с потерей возможности управлять собственным доменом. Если администратор не сможет пройти идентификацию через ЕСИА, он так же не сможет зарегистрировать новый домен в зонах .RU, .SU и .РФ, продлить срок его действия, изменить регистрационные данные или перенести домен к другому регистратору. В перспективе это может привести к утрате самого доменного имени. Нововведения касаются именно кантри-кодов .RU, .SU и .РФ — или страновых доменов, которые в отличии от доменов общего пользования, таких как, например, .РУС, могут иметь отдельные требования и правила регистрации.</p> <p>Еще один риск — потеря доступа к корпоративной почте и связанным с ней онлайн-сервисам. Если почта работает на домене компании (name@company.ru), а компания потеряла возможность управлять им, могут возникнуть проблемы с почтовыми настройками: станет невозможно изменить <nobr>MX-записи,</nobr> которые указывают, где находится почта, или подтвердить права на домен для почтовых сервисов, могут также возникнуть перебои в доставке писем. Компании, которые используют корпоративную почту или домен для авторизации, восстановления доступа или подтверждения владения системами аналитики, рекламными кабинетами, облачными сервисами, CRM, сервисами для рассылок и прочими онлайн-сервисами, потеряют доступ к этим ресурсам.</p> <h3>Как подготовиться к новой процедуре идентификации</h3> <p>Особенно внимательно стоит проверить старые корпоративные сайты. Нередко оказывается, что домен зарегистрирован не на владельца бизнеса, а на бывшего директора, системного администратора, разработчика сайта или даже на юридическое лицо, которое уже ликвидировано.</p> <p>Такая ситуация часто остается незамеченной, так как при повседневной работе сайта компании обычно не требуется взаимодействовать с администратором домена. Компания пользуется сайтом и считает его своим, потому что у нее есть доступ к CMS, хостингу, контенту, есть возможность менять страницы.</p> <p>В результате бизнес может не знать, что права на управление доменным именем оформлены на человека, который больше не связан с компанией. Но после введения идентификации через ЕСИА именно такая ситуация может стать причиной потери доступа к домену.</p> <p>Соответственно, если домен оформлен на бывшего руководителя или сотрудника, предпринимателю следует заранее установить с ним контакт и провести смену администратора. Сменить администратора после вступления новых правил в силу может оказаться значительно сложнее.</p> <p>Аналогичный подход рекомендуется и компаниям, чьи домены зарегистрированы на организации без подтвержденной учетной записи на «Госуслугах». В этом случае разумно либо заранее создать такую учетную запись, либо переоформить домен на администратора, который сможет пройти необходимую процедуру идентификации через ЕСИА, например, на собственника бизнеса или действующего директора.</p> <p>Владельцам сайтов не стоит ожидать существенного роста расходов. Интеграция с ЕСИА потребует значительных инвестиций от доменных регистраторов, но для конечных пользователей удорожание регистрации и продления доменов составит всего несколько сотен рублей в год. Для бизнеса такие затраты не сопоставимы с рисками потери уже раскрученного сайта, восстановление которого потребует значительно больше времени и средств.</p> <h3>Что делать, если сохранить текущий домен не получится</h3> <p>Если компания понимает, что сохранить существующий домен не удастся, подготовиться к переезду на новый сайт лучше заранее. Для сайтов, уже имеющих поисковый трафик, смена домена без предварительной подготовки может привести к потере позиций в поисковой выдаче, поэтому перенос необходимо планировать заблаговременно, используя инструменты поисковых систем для корректной смены адреса сайта.</p> <p>До появления окончательных правил регистрации стоит провести «ревизию» доменного портфеля: проверить, кто указан администратором каждого домена, актуальны ли регистрационные данные и сможет ли этот человек или организация пройти идентификацию через ЕСИА после вступления новых требований в силу. Именно такая подготовка сегодня остается самым эффективным способом избежать потери доступа к корпоративному сайту.</p> <p>#IMAGE_235427#</p> С 1 сентября в России вступают в силу изменения в законодательстве, которые затронут всех владельцев … article Алексей Созонов, заместитель директора доменного регистратора Webnames.ru https://www.itweek.ru/themes/detail.php?ID=235422 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>Искусственный интеллект — это нечто гораздо большее, чем просто повышение индивидуальной эффективности. Организациям следует задуматься о том, как автоматизация межкомандных процессов может способствовать стратегическому росту и снижению операционного сопротивления, пишет на портале </em><em>InformationWeek</em> <em>Мэтт Лайтесон, </em><em>CIO</em> <em>IBM по технологическим платформам.</em></p> <p>Сегодня слишком много разговоров об ИИ сосредоточено на индивидуальной продуктивности и рутинных задачах, а также на развитии набора навыков. Это важные темы, но бизнес-лидеры упускают из виду ключевой момент.</p> <p>Ценность корпоративного ИИ заключается не в том, чтобы повысить скорость выполнения задач или превзойти человека в креативности, а в чем-то гораздо более значимом: в обеспечении обмена информацией, аналитикой и знаниями в масштабах всей организации и раскрытии потенциала талантов, который сдерживается организационным сопротивлением.</p> <p>Вполне естественно сосредоточиться на том, как ИИ может помочь людям быстрее выполнять задачи, будь то создание рецептов и составление маршрутов для путешествий в домашних условиях или реферирование PDF-файлов и анализ массивов данных на работе. Но компании — это не просто здания, в которых работают «индивидуалисты». Это интегрированные и организованные системы, протоколы, ноу-хау, технологии и многое другое, что позволяет им масштабироваться и постоянно добиваться большего с меньшими затратами.</p> <h3> Масштабирование ИИ за пределы индивидуального уровня</h3> <p>Организационное сопротивление — это не второстепенная проблема. Совокупность внутренней бюрократии, избыточных процессов и других препятствий может существенно замедлить работу команды. По данным исследования, проведенного компанией McKinsey в ноябре 2025 г., 57% рабочего времени в США можно автоматизировать с помощью доступных сегодня технологий.</p> <p>Рассмотрим пример: аналитик по закупкам сверяет заказы на поставку со счетами-фактурами. В настоящее время эти сотрудники тратят много времени на сопоставление позиций, проверку условий договоров с поставщиками и устранение расхождений в данных из разных систем. Это малоэффективная работа, которая отнимает время, силы и возможности для более глубокой и целенаправленной деятельности.</p> <p>А теперь представьте, что весь процесс в значительной степени автоматизирован. Аналитик загружает счет-фактуру или отмечает заказ на поставку. ИИ берет на себя заполнение сметы расходов, сопоставление позиций и предоставляет администраторам инсайты, чтобы они могли быстрее принимать решения и исправлять ошибки. После сверки данные автоматически обновляются во всех финансовых системах. Нет необходимости вводить данные повторно, нет необходимости в ручном контроле, нет напрасной траты времени.</p> <p>Вот когда можно ощутить реальный эффект от внедрения автоматизации. Время экономит не только один аналитик. Благодаря автоматизированной сверке данных отделы закупок, финансов и комплаенса могут направить свои усилия на более важные задачи. Это оптимизирует то, что делается для сокращения операционных расходов, ускорения роста выручки за счет повышения скорости и повышения качества внутренних процессов и управления рисками за счет обеспечения соответствия каждого этапа рабочего процесса политикам, разрешениям и принципам управления. Благодаря этим трем направлениям — оптимизации затрат, ускорению роста и управлению рисками — корпоративный ИИ приносит прибыль, которая намного превышает эффект от прироста производительности отдельных сотрудников.</p> <h3>Создание основы</h3> <p>Для эффективного масштабирования ИИ на предприятии требуется нечто большее, чем просто использование нового инструмента отдельным человеком. Для этого требуется стек ИИ корпоративного уровня, который позволяет пользователям находить нужных агентов, получать доступ к корпоративной информации и генерировать инсайты, которые поддерживают стратегию команды. В сочетании с изменениями в организационной культуре эти возможности на уровне рабочих процессов позволяют по-настоящему получить выгоду от ИИ.</p> <p>Это больше, чем просто автоматизация задач; это оркестрация рабочего процесса. ИИ, работающий на основе упорядоченных данных, четких разрешений и эффективного управления, способен выполнять роль связующей ткани организации, управляя задачами в различных приложениях.</p> <p>В случае с нашим аналитиком по закупкам это означает понимание того, кто уполномочен просматривать данные и утверждать действия, и соответствующее перемещение информации с портала запросов в систему учета расходов. Чистые, интегрированные системы ИИ позволяют аналитику быстро находить нужных агентов или получать доступ к любому из них через единый портал.</p> <p>Когда он обдумывает новый проект, интерактивный ИИ-помощник может ответить на любые его вопросы, предоставив достоверные данные в соответствии с уровнем доступа, и направить ход его мыслей в нужное русло. Если ему нужно связаться с разными членами команды, ИИ-помощник может составить персонализированные сообщения с учетом индивидуальных особенностей, принадлежности к команде, географического положения и других факторов. Использование ИИ позволяет сотрудникам быстро и продуктивно способствовать стратегическому развитию бизнеса.</p> <h3>От работы с ИИ к ИИ как рабочей силе</h3> <p>Это не просто технологическая трансформация. После внедрения ИИ на предприятии компаниям придется пересмотреть свои процессы и корпоративную культуру, чтобы адаптировать их к новым реалиям. Результатом станут не только быстрые ответы на электронные письма и генерация контента. Мы увидим более активный обмен информацией, креативность, стратегическое планирование и критически важную работу, которую сотрудники смогут выполнять, не отвлекаясь на то, что у них получается хуже всего.</p> <p>Ставки высоки: по оценкам McKinsey, ИИ может принести компаниям прибыль в размере 4,4 трлн. долл. Мы уже видим это на примере IBM: мы уже сэкономили 4,5 млрд. долл., несмотря на то, что ИИ только начинает проникать в нашу деятельность. Внедрив методы управления организационными изменениями, предприятия могут оптимизировать рабочие процессы, чтобы сократить расходы, ускорить рост доходов и снизить риски.</p> <p>Сейчас самое время подготовиться к этой возможности и воспользоваться ею. После внедрения отдельных ИИ-инструментов компаниям необходимо сосредоточиться на корпоративных рабочих процессах, которые созрели для агентной трансформации. Им следует развернуть единую платформу, которая позволит создавать, повторно использовать, масштабировать и контролировать ИИ на всех уровнях предприятия — и при этом обеспечивать безопасность. По мере внедрения корпоративного ИИ компаниям необходимо вовлекать в этот процесс сотрудников, подталкивать их не только к использованию новых инструментов, но и к переосмыслению рабочих процессов. В совокупности эти шаги запустят «маховик» ИИ, откроют возможности для непрерывных инноваций и в конечном итоге обеспечат значимую бизнес-ценность.</p> Искусственный интеллект — это нечто гораздо большее, чем просто повышение индивидуальной эффективности. Организациям следует … article https://www.itweek.ru/themes/detail.php?ID=235417 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>Глобальная стратегия Atlassian по переходу в облако делает миграцию из этой экосистемы все более актуальной задачей для российских компаний. Рассмотрим, как при переходе сохранить бизнес-логику, минимизировать риски и правильно организовать процесс.</em></p> <h3>Почему пришло время мигрировать c Atlassian</h3> <p>Решениями Atlassian еще пользуются в российских компаниях, но все больше факторов подталкивают бизнес к переходу на альтернативные платформы. 15 февраля 2024 года вендор прекратил официальную поддержку, выпуск обновлений и исправлений для продуктов линейки Server. Формально эти системы можно продолжать использовать в закрытом контуре, принимая на себя риски.</p> <p>30 марта 2026 года закрылись продажи продуктов линейки Data Center новым клиентам, а с 30 марта 2028 года обладатели действующих подписок не смогут покупать новые лицензии, расширения и приложения из Atlassian Marketplace. 28 марта 2029 года жизненный цикл локальных решений окончательно подойдет к концу: сроки действия подписок Data Center завершатся, а системы, связанные с приложениями из Marketplace, перейдут в режим только для чтения.</p> <p>На смену этим решениям в экосистеме вендора приходит линейка Cloud. Это часть стратегии перевода в облако, которую Atlassian последовательно реализует уже несколько лет. Однако российскому бизнесу Cloud подходит не на 100%, поскольку не в полной мере отвечает требованиям информационной безопасности, не поддерживает работу в закрытом контуре и сложную кастомизацию. К тому же многие отечественные компании не могут выносить данные в зарубежный облачный сервис.</p> <p>В этих условиях раннее планирование миграции с Atlassian выглядит оптимальным вариантом. Оно позволит избежать рисков, связанных с продолжением эксплуатации устаревших продуктов без официальной поддержки.</p> <p>Во-первых, даже закрытый контур не делает систему «бессмертной». Чем дольше она работает без обновлений безопасности, тем выше становятся накопленные риски. Во-вторых, по мере модернизации остальной ИТ-инфраструктуры может ухудшаться ее совместимость с лишенными поддержки решениями Atlassian. В-третьих, через два-три года может быть сложнее найти сотрудников, хорошо знакомых со старой версией системы, старыми плагинами и кастомизациями. В-четвертых, бизнес-процессы постепенно перестраиваются, а вместе с ними должна дорабатываться платформа. Такие изменения лучше вносить сразу в новую систему, чем в старую, от которой вероятно придется отказаться.</p> <h3>Что перенести на новую платформу</h3> <p>При миграции с Atlassian в первую очередь следует перенести управление задачами, проектами и статусами, а главное — жизненными циклами, ведь именно на них опираются реальные бизнес-процессы. Важно переместить не просто карточки, а соответствующие им операции, иначе система не будет работать и превратится в обычный архив.</p> <p>Второй слой миграции — структура данных: настраиваемые поля и схемы распределения прав доступа. Они кажутся незначительными элементами, но именно на их основе строятся отчетность, маршрутизация, фильтры и SLA (соглашения об уровне услуг). Главное — не копировать все поля и права без изменений, а заново собрать модель таким образом, чтобы она была безопасной и актуальной.</p> <p>Третий слой — аналитика: дашборды, отчеты и настроенные фильтры. Основная ценность системы для руководителей часто заключается не в управлении задачами, а именно в этих инструментах. Без них даже переход на более мощную платформу может вызвать негативную реакцию менеджмента. В связи с этим следует тщательно продумать перенос аналитики и заранее включить его в план проекта.</p> <p>Четвертый слой — базы знаний из Confluence и сопутствующие вложения из Jira. При миграции важно оценить, какие из них лучше перенести в активный контур, какие — архивировать, а какие — удалить. Переход на новую платформу станет удачным моментом для такой оптимизации.</p> <p>Следующий слой — экосистема: внешние интеграции и установленные плагины, которых в крупной компании может накопиться очень много. Для их правильного переноса следует перед миграцией составить архитектурную схему, на которой будет указано, какие интеграции и плагины используются, зачем они нужны и насколько они критичны для бизнеса. Это поможет спланировать, что предстоит актуализировать, что — собрать заново, а что — заменить.</p> <h3>Пошаговый план миграции</h3> <p>Чтобы переход на новую платформу прошел успешно, важно использовать системный подход к подготовке и осуществлению миграции. Эту работу можно разделить на шесть шагов.</p> <p><strong>Шаг 1. Инвентаризация данных и аудит процессов. </strong>Сначала необходимо проанализировать набор используемых продуктов Atlassian, проверить их версии и сроки окончания поддержки. Следует оценить связанные с платформой риски на горизонте двух-трех лет, а также определить, требуется ли ее дорабатывать в ближайшее время. Работа в условиях закрытого контура не снимает вопросы технической поддержки, информационной безопасности, обновлений, совместимости и планирования выхода из экосистемы — их все равно нужно прояснить заранее. Также следует составить карту процессов, разделяя их по сценариям и выделяя критически важные для бизнеса операции. Это поможет сделать обоснованный выбор, на какую систему или гибридное решение переходить. Главным критерием должна стать возможность воспроизвести текущие процессы на новой платформе.</p> <p><strong>Шаг 2. Проектирование целевой модели в новой системе. </strong>После инвентаризации следует спроектировать целевую модель с описанием того, как процессы будут функционировать после перехода. Необходимо определить, какие операции перейдут в новую систему, что произойдет с архивом, где потребуются интеграции и как они будут работать, а также каким образом будет организован переход пользователей. Отдельного внимания требуют правила переноса исторических данных и нефункциональные требования. Необходимо описать, как должна работать система, задать требования к отказоустойчивости и информационной безопасности.</p> <p><strong>Шаг 3. Первичная настройка и кастомизация платформы. </strong>На этом этапе нужно настроить выбранную платформу или связку платформ: создать процессы, формы, роли и другие элементы, необходимые для работы решений, а также настроить права доступа, аналитику, уведомления, интеграции и маршруты согласования — все то, что обеспечивает функционирование ПО в рамках реальных рабочих процессов. Важно не стремиться к точному копированию старой системы, иначе есть риск перенести накопившиеся в ней проблемы в новый интерфейс; устаревшие процессы целесообразно собрать заново, проведя их аудит и оптимизацию.</p> <p><strong>Шаг 4. Тестовый перенос ограниченного объема данных. </strong>В его рамках следует проверить, как в новую систему перемещаются задачи, поля, статусы и другие элементы. Особое внимание стоит уделить тому, что не перенеслось автоматически: как правило эта информация наиболее полезна для доработки процесса. В автоматическом режиме обычно переносятся задачи, описания и другие элементы, поддающиеся прямому сопоставлению. Однако корректность такого переноса напрямую зависит от точности карты соответствия полей между системами, особенно если платформы различаются по структуре данных. При этом важно четко определить назначение каждого элемента: без правильной интерпретации значений старых полей и статусов автоматизированный перенос данных может пройти некорректно. По итогам этого шага необходимо проанализировать миграционный отчет, однако не менее важна сама практика тестового переноса.</p> <p><strong>Шаг 5. Проверка реальных пользовательских сценариев. </strong>На этом этапе в первую очередь тестируют пользовательский опыт: насколько удобно создавать заявки, согласовывать их и назначать исполнителей, работают ли переназначение по процессу, SLA и аналитика, закрываются ли обращения и насколько удовлетворены пользователи. Если все эти сценарии выполняются корректно, миграция становится не просто технически успешной, но и полезной для бизнеса.</p> <p><strong>Шаг 6. Итоговая промышленная миграция. </strong>Финальный этап — промышленная миграция, сопровождаемая волнами коммуникации с командами. Она должна стать не резким отключением старой системы, а плавным управляемым переходом, о котором заранее знают все участники и в рамках которого четко определены роли и зоны ответственности. Это исключает ситуации, в которых сотрудники месяцами дублируют работу в двух системах одновременно, и позволяет сервисным менеджерам бесшовно перейти на новую платформу.</p> <h3>Основные риски миграции</h3> <p>Если неправильно спланировать переход на новую платформу, можно нарушить уникальную бизнес-логику, зафиксированную в глубоких кастомизациях решений Atlassian. Это более серьезный риск, чем потерять данные. Даже если успешно перенести все задачи, комментарии и вложения, но упустить из виду правила согласования или автоматическое переназначение, бизнес-процесс не будет работать.</p> <p>Другой важный риск — сложности и ошибки при переносе исторических данных. Если таких записей накопилось много, перемещать весь массив может быть дорого, долго и нецелесообразно. Однако вовсе не перенести исторические данные — опасно для бизнеса. Разумным выбором станет категоризация элементов с учетом ценности и применения в рабочих процессах.</p> <p>Третий риск при миграции — неполный или некорректный перенос прав доступа и ролевых моделей. Следует отдельно планировать распределение прав на новой платформе: если они выйдут за нужные рамки, возникнут проблемы безопасности, а если слишком сильно ограничить доступ, пользователи не смогут нормально работать. Это особенно критично для сервисных процессов, HR-заявок, защиты данных, финансовых согласований, проектной документации и базы знаний.</p> <p>Четвертый риск — жесткая зависимость от приложений из Marketplace, у которых нет прямых аналогов. На старых версиях Atlassian одни и те же плагины могли работать годами. В таких случаях при миграции возникают вопросы, какую логику они используют, кто ее поддерживает, можно ли отказаться от этих приложений и есть ли у них аналоги. Иногда небольшой плагин оказывается самым критичным элементом всего бизнес-процесса, поэтому миграцию надо начинать с аудита, а не с выбора новой платформы.</p> <p>Наконец, главная ошибка — попытка перенести систему как есть, без предварительной оптимизации. При таком подходе вместе с полезными составляющими можно скопировать источники хаоса. Задача миграции не сохранить все плюсы и минусы старой системы, а обеспечить корректную работу процессов, убрать лишнее и выстроить эффективную архитектуру.</p> <h3>Безопасный переход</h3> <p>Сделать миграцию максимально комфортной и безопасной поможет в первую очередь отказ от переноса всех составляющих старой системы. Активные элементы можно добавить в рабочий контур, важные исторические данные — сохранить в архиве, а ненужные записи — удалить. Еще одним обязательным условием успеха станет тестовый перенос. Пилотная часть проекта поможет проверить критически важные узлы архитектуры и оценить реальную картину.</p> <p>Для компании, которая рассматривает миграцию с Atlassian, на первом плане должен быть не вопрос, работает ли платформа сегодня, а возможность безопасно выстраивать процессы на ее базе в перспективе. Если слишком долго откладывать переход на новую систему, можно оказаться в ситуации, когда поддерживать старые решения слишком дорого, а отказаться от них слишком сложно. В связи с этим лучше заранее выстроить на основе отечественного ПО новую жизнеспособную архитектуру, которая будет получать официальную поддержку и эволюционировать вместе с бизнес-процессами компании.</p> <p>#IMAGE_235418#</p> Глобальная стратегия Atlassian по переходу в облако делает миграцию из этой экосистемы все более актуальной … article Константин Преображенский, начальник отдела аналитики и проектов IBS https://www.itweek.ru/themes/detail.php?ID=235408 Fri, 28 Aug 2026 00:00:00 +0300 <p><em>DNS </em><em>(Domain Name System</em><em>,</em><em> система доменных имен)</em> <em>редко попадает в поле зрения пользователей и даже менеджмента компаний: пока сайт открывается, о не</em><em>й</em><em> почти не вспоминают. Но чем сильнее бизнес зависит от онлайн-каналов, тем важнее становится этот невидимый слой интернета. От DNS зависит, откроется ли сайт, сработает ли приложение, пройдет ли запрос к API и продолжит ли компания общаться с клиентами через цифровые сервисы. </em><em>Рассмотрим</em><em>, почему DNS в России становится вопросом устойчивости бизнеса.</em></p> <p>Раньше DNS воспринималась скорее как техническая настройка: пока сайт открывался, бизнес редко задумывался, как именно работает маршрутизация трафика. Однако за последние несколько лет ситуация изменилась. Для компаний DNS постепенно становится вопросом не только производительности, но и устойчивости, управляемости и контроля над критическими сервисами.</p> <p>Причин здесь несколько. Бизнес всё сильнее зависит от цифровых каналов: сайт, приложение, API (Application Programming Interface, интерфейс для обмена данными и командами между разными программами и цифровыми системами), почта, личный кабинет — всё это начинается с DNS. Одновременно растут требования к доступности сервисов и предсказуемости инфраструктуры. В этих условиях рынок постепенно переходит от классической модели DNS к более распределенным архитектурам, в первую очередь — к Anycast.</p> <h3>Что такое DNS и почему это важно для бизнеса</h3> <p>DNS — базовый механизм маршрутизации интернет-трафика, который связывает доменное имя с сервером, где расположен сервис.</p> <p>Когда пользователь вводит адрес сайта, открывает мобильное приложение или обращается к API, именно DNS определяет, куда должен быть направлен запрос и насколько быстро он дойдет до нужного ресурса. Этот процесс остается незаметным для пользователя, но напрямую влияет на доступность цифрового сервиса.</p> <p>От DNS зависят:</p> <ul> <li> скорость первого отклика сайта или приложения;</li> <li> стабильность пользовательского доступа;</li> <li> корректная работа почты и цифровых сервисов;</li> <li> возможность быстро управлять инфраструктурой;</li> <li> устойчивость сервисов при нагрузках и сбоях.</li> </ul> <p>Через DNS компании настраивают почтовую инфраструктуру, подтверждают права на домены для внешних сервисов, подключают аналитические и облачные платформы, управляют маршрутизацией трафика. Поэтому DNS постепенно становится связующим слоем между доменом, инфраструктурой и пользователем.</p> <p>Если DNS работает медленно или нестабильно, пользователь может не попасть к сервису даже в том случае, если сама инфраструктура продолжает работать корректно. В цифровой экономике отказ DNS — это уже прямой операционный риск.</p> <h3>Почему DNS переходит к распределенной модели</h3> <p>Традиционно DNS строилась по модели Unicast: один IP-адрес соответствует одному конкретному серверу. Пользовательский запрос всегда направляется в заранее определенную точку. Если сервер находится далеко или испытывает высокую нагрузку, растет задержка ответа, а при сбое страдает доступность сервиса.</p> <p>Модель Anycast работает иначе. Один и тот же IP-адрес одновременно используется на нескольких географически распределенных узлах, а запрос автоматически направляется к ближайшей или наиболее доступной точке. За счет этого сервис не зависит от одного узла: если одна точка перегружена или недоступна, запросы могут обслуживаться через другие узлы сети.</p> <p>Для бизнеса это дает сразу несколько эффектов:</p> <ul> <li> снижение задержки и более быстрый отклик сервисов;</li> <li> распределение нагрузки между несколькими узлами;</li> <li> более высокую устойчивость к сбоям;</li> <li> возможность масштабировать инфраструктуру без остановки сервисов.</li> </ul> <p>Именно поэтому Anycast давно используется крупными глобальными DNS-провайдерами и сетями серверов для быстрой доставки контента пользователям (CDN-платформами) как базовая архитектура для сервисов с высокими требованиями к доступности.</p> <p>По сути, DNS проходит ту же трансформацию, которую раньше прошли облачные платформы и сети доставки контента: из вспомогательной настройки она превращается в отдельный инфраструктурный слой со своими требованиями к производительности и отказоустойчивости. При этом Anycast не отменяет необходимости правильно управлять DNS-зонами: контролировать записи, доступы, сроки действия доменов, изменения конфигурации и резервные сценарии. Технология повышает устойчивость, но не заменяет операционную дисциплину.</p> <h3>Почему тема DNS стала особенно актуальной сейчас</h3> <p>Переход к Anycast — это естественный этап развития DNS-инфраструктуры, который уже стал стандартной практикой для высоконагруженных сервисов. В России этот подход сегодня получает более широкое распространение — во многом под влиянием изменений в технологической и регуляторной среде последних лет.</p> <p>После 2022 года компании начали учитывать не только технические характеристики сервисов, но и устойчивость инфраструктуры к внешним ограничениям: доступность поддержки, стабильность расчетов, зависимость от зарубежной юрисдикции. Даже в случаях, когда зарубежные сервисы продолжают работать, бизнес всё чаще оценивает риски, связанные с критической зависимостью от внешних платформ. Для DNS этот вопрос особенно чувствителен, если доменная инфраструктура становится недоступной или плохо управляемой, последствия могут затронуть не один сервис, а весь цифровой контур компании.</p> <p>Параллельно усилился тренд на «заземление» инфраструктуры — размещение и обслуживание ключевых элементов цифрового контура в России. Этому способствует как регулирование, так и сама логика управления рисками. Речь не только о физическом размещении отдельных сервисов, но и о более понятной юрисдикции, доступной поддержке, прозрачных правилах обслуживания и возможности быстрее реагировать на инциденты.</p> <p><a href="https://www.consultant.ru/document/cons_doc_LAW_61801/?utm_source=chatgpt.com">Закон о персональных данных</a> требует хранить и обрабатывать данные граждан РФ с использованием баз данных на территории страны, а регулирование в сфере <a href="https://www.consultant.ru/document/cons_doc_LAW_220885/?utm_source=chatgpt.com">критической информационной инфраструктуры</a> и <a href="https://www.consultant.ru/document/cons_doc_LAW_323815/?utm_source=chatgpt.com">устойчивости</a> Рунета задает общий вектор на контролируемость и отказоустойчивость цифровых сервисов. DNS напрямую не является базой персональных данных, но она находится в том же контуре операционной устойчивости: без нее не работают сайт, почта, личный кабинет, API и другие сервисы, через которые бизнес взаимодействует с клиентами.</p> <p>В последние годы этот подход начал усиливаться и на практике: регуляторы <a href="https://www.interfax.ru/digital/1017951">рекомендуют</a> использовать российские хостинг- и CDN-площадки в случаях, когда от инфраструктуры зависит стабильность сервисов.</p> <p>Для бизнеса это означает, что вопрос «где расположена DNS» постепенно становится таким же важным, как вопрос «где находятся данные», и компании начинают смотреть на него шире — кто управляет DNS, где находятся ключевые точки инфраструктуры, как быстро можно получить поддержку и какие резервные сценарии предусмотрены на случай сбоя.</p> <h3>Как меняется рынок DNS в России</h3> <p>Исторически компании часто выбирали DNS по остаточному принципу: либо использовали базовые сервисы регистратора, либо подключали зарубежные решения, если требовались высокая производительность и гибкость управления.</p> <p>Сегодня требования изменились. Бизнесу важны:</p> <ul> <li> скорость отклика;</li> <li> отказоустойчивость;</li> <li> прозрачное управление инфраструктурой;</li> <li> масштабируемость;</li> <li> понятная юрисдикция и доступная поддержка.</li> </ul> <p>На этом фоне в России начали активнее развиваться распределенные DNS-модели. В первую очередь они становятся востребованы у компаний, для которых онлайн-каналы напрямую связаны с выручкой, клиентским опытом и непрерывностью процессов: e-commerce, медиа, финансовых сервисов, SaaS-платформ, образовательных проектов и крупных корпоративных сайтов.</p> <h3>Anycast DNS как часть новой операционной устойчивости</h3> <p>Для бизнеса внедрение Anycast выходит за рамки технического обновления DNS и представляет собой стратегический пересмотр архитектуры сетевой инфраструктуры: компании начинают воспринимать цифровые сервисы как непрерывный операционный контур, где отказ даже одного элемента может влиять на выручку, клиентский опыт и стабильность процессов.</p> <p>В этой логике DNS перестает быть «фоновой настройкой», о которой вспоминают только при регистрации домена. Сегодня от нее зависит, насколько быстро пользователь получит доступ к сервису, как инфраструктура переживает пиковые нагрузки и насколько устойчиво работает цифровой контур в случае сбоев или внешних ограничений. Именно поэтому распределенные модели вроде Anycast постепенно становятся новой инфраструктурной нормой для цифровых сервисов.</p> <p> #IMAGE_235409#</p> DNS (Domain Name System, система доменных имен) редко попадает в поле зрения пользователей и даже менеджмента компаний … article Георгий Казаров, руководитель отдела доменов Руцентра https://www.itweek.ru/themes/detail.php?ID=235425 Thu, 27 Aug 2026 17:41:32 +0300 <p>В сентябре 2026 года компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представит заказчикам vitiscale — собственную горизонтально масштабируемую СХД, спроектированную для самых требовательных задач. vitiscale обеспечивает десятки миллионов IOPS и сотни тысяч RPS в секунду при минимальном времени отклика и гарантирует производительность, необходимую для эффективной работы AI/ML-решений, аналитики больших массивов данных, высоконагруженных ферм СУБД и быстрого восстановления данных.</p> <p>«vitiscale — это полностью оригинальная разработка, а не производное от существующего решения на основе open-source, — рассказал Филипп Комиссаров, технический директор datagarden. — Мы сознательно пошли на то, чтобы переписать программную архитектуру системы хранения практически с нуля: только так можно было извлечь из оборудования максимум и устранить те узкие места, с которыми мы годами сталкивались в ходе эксплуатации хранилищ такого класса. Для заказчика это выражается во вполне практичных вещах: та же задача решается кратно меньшим числом узлов, требует значительно меньше энергии и места в стойках, а производительность и емкость растут линейно и без остановки сервисов. Мы строили vitiscale, ориентируясь на нагрузки эпохи искусственного интеллекта и аналитики больших данных, где одинаково важны и высочайшая производительность, и минимальный отклик».</p> <p>Программная архитектура 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).</p> <p>Горизонтально масштабируемую СХД vitiscale команда datagarden разрабатывает с 2022 года. Ключевая цель проекта — максимально эффективно использовать аппаратные ресурсы системы. Над продуктом работает команда инженеров, которые в течение многих лет эксплуатировали хранилища данного класса и знают их узкие места изнутри.</p> <p>Компания datagarden разрабатывает и производит в России централизованные и распределенные системы хранения данных. Архитектура и алгоритмы хранения в основе продуктов datagarden соответствуют современным профилям нагрузок — от виртуализации и СУБД до искусственного интеллекта — и рассчитаны на непрерывную эксплуатацию и рост объемов данных.</p> В сентябре 2026 года компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового … message https://www.itweek.ru/themes/detail.php?ID=235424 Thu, 27 Aug 2026 17:40:05 +0300 <p>В 2026 году два крупнейших регулятора — Евросоюз с AI Act (Regulation (EU) 2024/1689) и Россия с <nobr>243-ФЗ —</nobr> впервые массово перенесли ответственность за ИИ-системы с разработчика модели на всю цепочку, включая провайдера вычислительной среды. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, что теперь географическое расположение GPU, юрисдикция дата-центра и архитектура логирования превращаются в переменные, которые определяют легальность ИИ-модели.</p> <p>AI Act — это первый в мире комплексный подход к регулированию ИИ на уровне целого союза. Он вводит регулирование поэтапно. С февраля 2025 года начали действовать запреты на системы с неприемлемым риском, в том числе запрещены отдельные практики (социальный скоринг, биометрическая идентификация в реальном времени в чувствительных контекстах), и нормы ИИ-грамотности. С августа <nobr>2025-го</nobr> вступили в силу обязательства для поставщиков моделей общего назначения (general-purpose AI или GPAI). С августа <nobr>2026-го</nobr> начал применяться основной массив обязанностей к системам высокого риска. С августа <nobr>2027-го</nobr> начнут действовать дополнительные требования к высокорисковым системам. Именно эта последняя волна бьет по инфраструктуре сильнее всего.</p> <p>На уровне ЕС созданы Управление по ИИ (AI Office) при Еврокомиссии и Европейский совет по ИИ — они координируют правоприменение. AI Office с августа <nobr>2025-го</nobr> имеют инспекционные полномочия и может запрашивать техническую документацию, включая сведения о среде, в которой обучалась и работает модель.</p> <p>Для инфраструктурного провайдера это означает конкретный набор обязательств. Провайдер GPAI-модели обязан вести и актуализировать техническую документацию, описывающую модель, процессы ее обучения и тестирования, результаты оценки; раскрывать пользователям информацию о возможностях и ограничениях модели; соблюдать политику авторских прав; публиковать детальную сводку по обучающим данным по шаблону AI Office. Для моделей, создающих системный риск, добавляются расширенные обязанности — подробные стратегии оценки и внутреннего тестирования. Без технической реализации этих требований в облаке заказчик просто не пройдет аудит — даже если его собственная модель полностью корректна.</p> <p>26 июля 2026 года подписан <nobr>243-ФЗ</nobr> «О поддержке развития технологий искусственного интеллекта в Российской Федерации», основная часть вступает в силу с 1 сентября 2026 года. Закон регулирует узкий, но емкий сегмент — большие фундаментальные модели с числом параметров от 1 миллиарда. Для них устанавливаются пять базовых требований. Разработчиком модели должно быть российское юридическое лицо, и оно же должно отвечать за изменение характеристик модели. Компания-разработчик обязана обеспечить полную техническую и технологическую воспроизводимость всего цикла разработки, включая обучение. Подготовка ответов на запросы пользователей и хранение данных должны производиться в ЦОДах на территории России, принадлежащих российским юрлицам. Используемые зарубежные компоненты должны распространяться на условиях открытой лицензии. С 1 марта 2027 года добавляется требование о подтверждении соответствия модели российскому законодательству и традиционным духовно-нравственным ценностям.</p> <p>Важная деталь: закон не запрещает трансграничное использование ИИ-компонентов и не обязывает обучать модель только на российских данных. Это снимает главный страх рынка и одновременно переводит фокус с расположения данных на локализацию оборудования. И вот тут инфраструктура выходит на первый план.</p> <p>Локализация данных и вычислений по <nobr>243-ФЗ</nobr> требует российской юрисдикции ЦОД и российского юрлица-провайдера. Без гео-распределенных площадок и входа в реестр отечественного ПО это правило не выполнить.</p> <p>Контроль доступа к GPU-среде предполагает изоляцию dev-, research- и prod-контуров и минимизацию круга лиц с правами. На уровне собственного сервера это дорого и хрупко; на уровне провайдера — стандартная функция приватных кластеров с ролевой моделью на гипервизоре.</p> <p>Мониторинг инференса требует понимать, что генерирует модель в проде. Реализуется через inline-модули аудита, которые интегрируются с системами защиты вроде СЗИИ и работают на стороне облака, а не на стороне разработчика модели.</p> <p>Отчетность по вычислениям — требование, которое на горизонте <nobr>2-3</nobr> лет станет обязательным: считать, сколько ресурсов ушло на обучение и инференс. Здесь критичны телеметрия GPU, биллинг с разбивкой по задачам и прозрачные SLA — то, что у зрелого провайдера уже реализовано.</p> <p>Для заказчика реализация таких требований самостоятельно довольно сложная задача: для этого нужна либо собственная инженерная команда по инфраструктуре, либо опытный сервис-провайдер.</p> <p>Раньше комплаенс лежал на заказчике. Сейчас без провайдера, который технически обеспечивает локализацию, логирование и изоляцию, выполнить <nobr>243-ФЗ</nobr> практически невозможно. Соответственно, на первый план будет выходить регуляторно-совместимый контур для ИИ с прецедентами в финсекторе или госсекторе.</p> <p>Подтверждает этот сдвиг и динамика рынка. По прогнозу Gartner, мировые расходы на ИИ-оптимизацию IaaS в 2026 году вырастут на 96% и достигнут 42 млрд долларов. IDC оценивает общие траты на ИИ-инфраструктуру в $497 млрд за 2026 год, причем в первом квартале 2026 рынок уже преодолел отметку $89,7 млрд (+33% год к году). Фокус на инфраструктуру, которая умеет работать с ИИ-нагрузкой: с GPU, с телеметрией, с изолированными контурами.</p> <p>Сервис-провайдер M1Cloud один из первых предложил безопасность ИИ, обеспечение прослеживаемости и соответствия требованиям регуляторов на уровне инфраструктуры, благодаря партнерству с ООО СЗИИ («Системы защиты искусственного интеллекта») и интеграции в облачную инфраструктуру решения для специализированной защиты ИИ-моделей от современных киберугроз.</p> В 2026 году два крупнейших регулятора — Евросоюз с AI Act (Regulation (EU) 2024/1689) и Россия … message https://www.itweek.ru/themes/detail.php?ID=235423 Thu, 27 Aug 2026 17:38:31 +0300 <p>Спрос на услуги и решения класса DevSecOps в российских компаниях вырос примерно на <nobr>20-22%</nobr> с начала 2026 года по сравнению с аналогичным периодом 2025 года. Эксперты «Кросстеха» связывают эту динамику с развитием процессов внутренней разработки в российских компаниях, где безопасность становится неотъемлемой частью процесса создания продукта.</p> <p>Специалисты отмечают, что в начале <nobr>2020-х</nobr> собственная разработка была в основном распространена в финансовом секторе и телекоме — компании из этих отраслей традиционно используют широкий стек ПО как для внутренних процессов, так и для взаимодействия с клиентами. В середине 2026 года внутренние команды разработки становятся обыденностью. Так, по данным «Кросстеха», лидерами по запросам на проекты, связанные с DevSecOps, в первой половине 2026 года стали промышленность и ритейл.</p> <p>Среди основных причин популяризации собственной разработки среди российских компаний — желание бизнеса контролировать технологии, которые используются в его инфраструктуре, и отсутствие решений, которые удовлетворяют потребности бизнеса. Еще одна причина — снижение стоимости разработки за счет развития искусственного интеллекта, которые забирает на себя значительную часть процесса создания IT-решений.</p> <p>Расширение числа проектов, связанных с разработкой собственных решений, ведет к необходимости внедрять безопасную разработку, благодаря чему с начала 2026 года растет спрос на DevSecOps. Наиболее востребованным остается внедрение инструментов тестирования кода (SAST, DAST, SCA), пентест приложений и API, а также консалтинг по DevSecOps и построение процесса безопасной разработки внутри компании.</p> <p>«Компании, которые еще недавно интегрировали готовые продукты, сегодня оказались в роли разработчиков — и далеко не всегда с соответствующей культурой безопасной разработки. Уязвимость может попасть в продукт не через код, который написала команда, а через внешнюю библиотеку или контейнерный образ, о котором никто не задумывался. Именно поэтому спрос смещается не просто на инструменты, а на выстраивание процесса — от анализа зависимостей до безопасности на каждом этапе CI/CD», — прокомментировал Антон Редько, руководитель группы «Безопасная разработка» «Кросстеха».</p> Спрос на услуги и решения класса DevSecOps в российских компаниях вырос примерно на 20-22% с начала 2026 … message https://www.itweek.ru/themes/detail.php?ID=235421 Thu, 27 Aug 2026 10:38:03 +0300 <p><em>Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале </em><em>BigDataWire</em> <em>Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.</em></p> <p>На протяжении многих лет аналитические команды помогали организациям разобраться в своих данных. Они создавали дашборды. Они создавали отчеты. Они создавали конвейеры обработки данных. Они разрабатывали определения, документировали метрики и помогали руководителям отвечать на вопросы о том, что происходит внутри компании.</p> <p>Теперь сотрудники компаний все чаще обращаются к ChatGPT, Claude, Copilot и другим системам на основе ИИ вместо того, чтобы напрямую открывать дашборды. Вместо того, чтобы самостоятельно работать с инструментами отчетности, они задают вопрос и ждут ответа.</p> <p>Когда сотрудник запрашивает информацию с дашборда, тот выдает ему метрику. Когда сотрудник обращается к ИИ-помощнику, тот интерпретирует информацию, объединяет данные из нескольких систем, применяет логику и выдает заключение.</p> <p>Но кто-то все равно должен определить, верен ли ответ, и эта ответственность все чаще ложится на аналитические команды.</p> <h3>Традиционное управление решало другие задачи</h3> <p>На протяжении большей части современной эпохи работы с данными управление было сосредоточено на вопросах доступа, происхождения данных, определений и доверия. Организациям нужно было знать, кто имеет доступ к данным, откуда поступает информация, как определяются метрики и на какие отчеты можно полагаться при принятии решений.</p> <p>Для решения этих проблем появились каталоги данных, инструменты отслеживания происхождения данных, платформы для документирования и системы управления. Они помогли организациям обеспечить согласованность во все более сложных средах обработки данных и повысили уверенность сотрудников в информации, которой они пользовались каждый день.</p> <p>Эта система работала, потому что окончательное решение оставалось за людьми. Аналитики и бизнес-руководители отвечали за интерпретацию информации, учет контекста и определение того, как данные должны влиять на принятие решений. Система управления была создана для того, чтобы обеспечить людям доступ к достоверной информации. Она не была предназначена для оценки того, как ПО обрабатывает эту информацию.</p> <h3>Агенты создают новую проблему в сфере управления</h3> <p>Одно из самых распространенных заблуждений в сфере корпоративного ИИ заключается в том, что управление — это в первую очередь проблема доступа. Логика кажется разумной: если у агента есть доступ к нужным системам и данным, он должен быть в состоянии выдать правильный ответ.</p> <p>К сожалению, доступ и точность — это не одно и то же.</p> <p>В отличие от традиционных аналитических инструментов, агенты не просто извлекают информацию. Они интерпретируют ее, объединяют сигналы из нескольких систем, применяют бизнес-логику и генерируют рекомендации, которые все больше влияют на решения и действия.</p> <p>Это значит, что агент может получить доступ к абсолютно достоверной информации и все равно прийти к неверному выводу.</p> <p>Данные о клиенте могут быть точными. Прогноз продаж может быть актуальным. Финансовые показатели могут быть корректно определены. Тем не менее, агент может неправильно комбинировать эти входные данные, неправильно понимать контекст, в котором они используются, или непоследовательно применять бизнес-логику.</p> <p>Многие организации полагают, что управление заканчивается, как только будут установлены необходимые разрешения и подключены нужные источники данных. На самом деле эти элементы управления определяют только то, к какой информации агент может получить доступ. Они не определяют, правильно ли агент интерпретирует эту информацию.</p> <p>Традиционные системы управления никогда не были разработаны для решения этой проблемы. Разрешения не предотвращают неправильного толкования, отслеживание происхождения не гарантирует разумного обоснования, а документация не обеспечивает последовательного выполнения.</p> <p>Поскольку организации внедряют агентов во все большее число рабочих процессов, им нужен способ оценить не только то, что может видеть система ИИ, но и то, можно ли доверять выводам, которые она делает.</p> <h3>Аналитические группы становятся ИИ-рецензентами</h3> <p>Кто-то должен выявлять повторяющиеся сбои, сопоставлять результаты с реальностью и определять, повышается или снижается надежность с течением времени.</p> <p>Эта работа, естественно, ложится на плечи аналитиков.</p> <p>Они уже понимают, что лежит в основе данных, как определяются показатели, откуда берется бизнес-логика и как информация перемещается по организации. Не менее важно, что они понимают, как должен выглядеть правильный ответ и где наиболее вероятно возникновение ошибок.</p> <p>По мере того как ИИ становится все более важной частью доступа сотрудников к информации, аналитические группы берут на себя обязанности, которые все больше напоминают обеспечение качества. Они проверяют результаты, оценивают надежность, расследуют сбои, отслеживают согласованность и выявляют условия, которые заставляют агентов выдавать неверные результаты.</p> <p>Исторически сложилось так, что аналитические группы отвечали за то, чтобы дашборды и отчеты точно отражали бизнес. ИИ расширяет зону их ответственности. Тем же командам теперь предлагается оценить, дают ли агенты, вторые пилоты и аналитические системы на базе ИИ ответы, заслуживающие такого же уровня доверия.</p> <h3>Управление выходит за рамки данных</h3> <p>Большинство программ управления были построены вокруг контроля доступа к информации. Цель состояла в том, чтобы обеспечить сотрудникам доступ к необходимым им данным, сохраняя при этом согласованность, безопасность и доверие во всей организации.</p> <p>ИИ ставит перед ними другую задачу. Агент может иметь доступ к нужным системам, нужным данным и нужным разрешениям, но при этом выдавать неполный, противоречивый или просто неправильный ответ.</p> <p>Это смещает фокус управления за пределы контроля доступа и управления данными. Организациям необходимо иметь представление о том, как ведут себя агенты, насколько последовательно они применяют бизнес-логику и остаются ли результаты, которые они генерируют, надежными с течением времени.</p> <p>Организация, которая не может доверять выводам, сделанным ее системами ИИ, не решила проблему управления просто потому, что базовые данные хорошо управляются. По мере того как агенты все глубже интегрируются в бизнес-процессы, надежность, валидация и контроль становятся не менее важными, чем прослеживаемость происхождения, права доступа и документация.</p> <h3>Переход от управления данными к управлению ИИ</h3> <p>Профессия аналитика уже претерпела несколько серьезных трансформаций: от отчетности и бизнес-аналитики к самообслуживанию в аналитике и современным платформам данных. ИИ порождает еще одну трансформацию.</p> <p>По мере того как агенты все активнее участвуют в предоставлении сотрудникам доступа к информации, организациям становятся нужны люди, которые смогут оценивать надежность, расследовать сбои и определять, заслуживают ли доверия результаты работы ИИ. Аналитические команды хорошо подходят для выполнения этой задачи, поскольку они уже разбираются в данных, бизнес-логике и операционном контексте, лежащих в основе ответов, которые выдают эти системы.</p> <p>На протяжении многих лет их роль заключалась в том, чтобы помогать людям принимать более взвешенные решения на основе данных. Теперь они все чаще отвечают за то, чтобы системы ИИ могли делать то же самое.</p> Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале BigDataWire Сохам … article https://www.itweek.ru/themes/detail.php?ID=235419 Thu, 27 Aug 2026 09:05:07 +0300 <p><em>Сегодня ИИ, а точнее машинное обучение (ML), все глубже встраивается в управление доставкой, помогая прогнозировать спрос и опоздания, рассчитывать сроки и оптимизировать процессы. Разбираемся, какие задачи последней мили уже можно передать алгоритмам и почему главным преимуществом логистических платформ становится не сам искусственный интеллект, а качество накопленных данных и возможности прогнозирования.</em></p> <h3>От автоматизации к планированию и прогнозу</h3> <p>Переход от простой автоматизации к прогнозному управлению доставкой происходил постепенно. По мере накопления данных и развития технологий логистические системы стали решать все более сложные задачи. Условно этот процесс можно разделить на два этапа.</p> <p><strong>Цифровизация доставки.</strong> Этот этап связан прежде всего с автоматизацией рутинных операций. Системы научились распределять заказы между курьерами, строить маршруты, рассчитывать предполагаемое время доставки (ETA), объединять несколько заказов в одну цепочку и пересчитывать параметры при изменении ситуации. Это позволило сократить объем ручной работы и снизить зависимость процессов от диспетчера.</p> <p><strong>Прогнозное управление. </strong>Здесь системы начинают не только обрабатывать текущую ситуацию, но и прогнозировать дальнейшее развитие событий. Например, модели машинного обучения анализируют историю заказов и оценивают будущий спрос в конкретной зоне и временном интервале. Это позволяет бизнесу заранее планировать количество курьеров и адаптировать ресурсы к ожидаемой нагрузке, что особенно важно для доставки последней мили, где спрос распределяется неравномерно. Количество заказов в пятницу вечером и утром буднего дня может отличаться в несколько раз. Если курьеров недостаточно, увеличивается нагрузка и растет риск опозданий. Если их слишком много, появляются простои, а стоимость выполнения одного заказа увеличивается.</p> <p>И ценность ML заключается не в самом прогнозе, а в возможности использовать его для принятия операционных решений. В частности, чем точнее компания понимает будущую нагрузку, тем эффективнее может распределять ресурсы и поддерживать баланс между стоимостью доставки и качеством сервиса.</p> <p>При этом прогнозирование дает бизнесу еще одну возможность: проверять решения до их внедрения. На основе накопленных данных можно моделировать различные сценарии работы доставки и смотреть, как изменение отдельных параметров повлияет на результат. Например, при расширении зоны доставки можно рассчитать необходимое количество курьеров, изменение их загрузки и возможное влияние нового радиуса на стоимость заказа и сроки.</p> <p>Такие тесты позволяют проверять гипотезы на виртуальной модели, не экспериментируя сразу на реальных заказах и клиентах. В результате управление доставкой постепенно переходит от реактивного подхода, когда бизнес исправляет уже возникшую проблему, к проактивному, когда последствия решения можно оценить заранее.</p> <h3>Динамическая маршрутизация</h3> <p>Еще одна важная задача в управлении последней милей связана с построением маршрутов. Здесь важно уточнить, что сама маршрутизация не является задачей искусственного интеллекта. В ее основе лежат алгоритмы оптимизации, а модели машинного обучения могут использоваться для более точного прогнозирования отдельных параметров, которые учитываются при расчетах.</p> <p>Современная система должна учитывать не только расстояние между точками, но и временные интервалы доставки, доступность и загрузку курьеров, зоны обслуживания, приоритеты заказов и другие ограничения. При этом исходные условия постоянно меняются. Поступают новые заказы, один курьер задерживается, другой освобождается раньше, меняется время готовности заказа.</p> <p>Поэтому маршрут не формируется один раз на всю смену. Система пересчитывает его по мере поступления новых данных и помогает перераспределять заказы между исполнителями. <nobr>ML-модели</nobr> могут дополнять этот процесс, например повышая точность расчета ожидаемого времени доставки (ETA).</p> <p>Для бизнеса результат такой оптимизации выражается в конкретных показателях, таких как сокращение простоев и лишнего пробега, более равномерная загрузка курьеров и соблюдение заявленных сроков доставки.</p> <h3>Опоздания под контролем</h3> <p>Еще одно направление, где машинное обучение может быть полезно, связано с прогнозированием опозданий. В традиционной модели проблема становится очевидной, когда курьер уже выбился из графика или клиент не получил заказ в обещанное время. <nobr>ML-модели</nobr> позволяют оценить риск задержки заранее, анализируя накопленные данные и текущие параметры доставки. Причины при этом могут быть совершенно разными. Одни возникают внутри самого процесса, когда, например, заказ поздно собрали, задержали на упаковке или не успели передать исполнителю. Другие возникают из-за форс мажорных обстоятельств и их невозможно полностью исключить организационными мерами. Например, на движение курьера могут повлиять авария, перекрытие дороги, проверка сотрудниками полиции и т. д.</p> <p>Задача алгоритмов в такой ситуации не в том, чтобы исключить все форс-мажоры, а в том, чтобы как можно раньше увидеть отклонение и минимизировать его последствия. Если система получает актуальные данные о ходе доставки, она может пересчитать ETA, изменить последовательность выполнения заказов или перераспределить часть нагрузки между исполнителями.</p> <p>В результате бизнес получает возможность управлять отклонением «на лету», еще до того, как оно превратится в опоздание для клиента. И чем раньше будет обнаружен риск, тем больше вариантов остается для корректировки ситуации и сохранения заявленного уровня сервиса.</p> <h3>Где заканчивается работа алгоритма</h3> <p>По мере развития технологий все больше операционных задач можно автоматизировать. Система способна распределять заказы между курьерами, пересчитывать маршруты, рассчитывать ETA и выявлять риск отклонения от заданных сроков. Однако это не означает, что управление доставкой можно полностью передать алгоритмам.</p> <p>Ключевые правила по-прежнему определяет бизнес. Компания решает, какие зоны обслуживать, какие временные интервалы предлагать клиентам, какие заказы считать приоритетными и какой уровень сервиса поддерживать. Алгоритмы работают внутри этих ограничений и помогают находить оптимальное решение в конкретной ситуации.</p> <p>При этом автоматизация постепенно освобождает сотрудников от значительной части рутинных операций. Им уже не нужно вручную распределять каждый заказ, постоянно перестраивать маршруты или отслеживать движение каждого курьера. Эти задачи система может выполнять самостоятельно в рамках заданных правил.</p> <p>В результате роль человека не сокращается, а меняется. Чем больше типовых операций берет на себя технология, тем больше внимания сотрудник может уделять задачам более высокого уровня, анализировать показатели, искать причины отклонений, проверять гипотезы, менять правила работы системы и продумывать новые сценарии. Алгоритмы в этом смысле не заменяют специалиста, а позволяют ему перейти от ручного управления процессом к работе с решениями и развитием доставки.</p> <h3>Качество и полнота данных выходят на первый план</h3> <p>Когда набор технологических возможностей у логистических платформ становится сопоставимым, различия начинают формироваться на уровне данных. Одна и та же модель может показывать разную точность в зависимости от того, на какой информации она обучалась и с какими сценариями сталкивалась раньше.</p> <p>При этом большой объем данных сам по себе не гарантирует хороший результат. Важны их качество, полнота, актуальность и разнообразие. Чем лучше данные отражают реальные процессы доставки и возможные отклонения, тем надежнее модель работает в новых ситуациях.</p> <p>Особенно заметно это при моделировании сценариев. Чтобы оценить последствия изменения зоны доставки, нагрузки или доступного курьерского ресурса, недостаточно знать только среднее количество заказов. Чем полнее система видит историю операций и взаимосвязь разных параметров, тем ближе результаты виртуального теста к тому, что произойдет в реальных условиях.</p> <p>И в отличие от отдельных технологий, накопленную историю операций невозможно быстро скопировать или приобрести. Она формируется со временем, поэтому именно данные постепенно становятся одним из ключевых активов логистических платформ и определяют качество работы <nobr>ML-моделей.</nobr></p> <h3>Что дальше</h3> <p>Следующий этап развития технологий управления доставкой будет связан не столько с расширением функционала, сколько с повышением точности уже существующих решений. По мере накопления данных модели смогут лучше учитывать особенности спроса, загрузку и поведение курьеров, а также отклонения, возникающие в разных сценариях доставки.</p> <p>При этом полностью автономное управление последней милей пока остается скорее перспективой, ведь слишком многое здесь зависит от нестандартных ситуаций, которые требуют оценки и вмешательства человека. Поэтому задача технологий — не исключить его из процесса, а взять на себя расчеты и значительную часть операционных решений, сохранив за специалистом контроль в ситуациях, где алгоритма недостаточно.</p> <p>В результате развитие ML в логистике будет определяться не количеством новых функций с маркировкой ИИ, а тем, насколько точно технологии работают с реальными процессами и улучшают конечный результат. И ценность таких решений будет измеряться конкретными показателями, насколько они помогают сокращать опоздания и простои, поддерживать качество сервиса и снижать стоимость доставки.</p> <p>#IMAGE_235420#</p> Сегодня ИИ, а точнее машинное обучение (ML), все глубже встраивается в управление доставкой, помогая … article Денис Сокольников, технический директор компании “Мастер Деливери” https://www.itweek.ru/themes/detail.php?ID=235401 Thu, 27 Aug 2026 00:00:00 +0300 <p>Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих интеграций, доработок, миграции данных и поддержки. Разбираем, где компании чаще всего ошибаются и что стоит проверить до старта проекта.</p> <p>Российский бизнес продолжает вкладывать в цифровизацию все больше денег. По предварительной <a href="http://issek.hse.ru/mirror/pubs/share/1132489160.pdf">оценке</a> ИСИЭЗ НИУ ВШЭ, затраты на развитие цифровой экономики в России в 2025 году составили 7,1 трлн. рублей, это на 6,5% больше, чем годом ранее. Только внутренние затраты организаций на создание, распространение и использование цифровых технологий оцениваются в 4,5 трлн. рублей. За пять лет эта сумма выросла примерно вдвое. Причем 87,5% расходов крупных и средних организаций на цифровые технологии в 2024 году финансировались из собственных средств.</p> <p>В 2026 году расходы продолжают расти. В исследовании Apple Hills Digital, Selectel, Cloud.ru и VK Tech 65% опрошенных российских компаний <a href="https://apple-hills.com/ru/reports/cloud-consumption-trends-2025">сообщили</a>, что увеличили ИТ-бюджеты: 48% подняли их в пределах 15%, еще 17% более чем на 15%. Исследование охватило 419 компаний из разных отраслей и 27 глубинных интервью с ИТ-руководителями.</p> <p>То есть вопрос уже не столько в том, готов ли российский бизнес тратить деньги на цифровизацию. Готов. Другой вопрос: сколько из этих денег действительно должно было быть потрачено.</p> <p>Компания может согласовать систему за 20 млн. рублей, успешно провести тендер и даже уложиться в смету. А потом обнаружить, что отдельно нужны интеграции, миграция данных, переделка нескольких внутренних сервисов, обучение сотрудников, дополнительная инфраструктура и команда, которая будет развивать продукт после запуска.</p> <p>Иногда проблема обнаруживается еще позже: система работает, но не дает эффекта, ради которого ее создавали.</p> <p>Это не редкий сценарий. Оператор ИТ-решений ОБИТ в 2025 году <a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/">проанализировал</a> более 100 входящих запросов от компаний среднего и крупного бизнеса с оборотом от 2 млрд. рублей. В выборку вошли промышленность, ритейл, ИТ и телеком, логистика. Почти в каждом втором случае компании приходили с запросом на повторный проект или доработку после предыдущего неудачного внедрения. Самыми частыми причинами стали недооценка стоимости владения, проблемы интеграции и неправильный выбор решения.</p> <p>Разберем ошибки, из-за которых цифровизация становится дороже, чем могла бы быть.</p> <h2>Ошибка 1. Цифровизировать компанию отдельными проектами</h2> <p>У компании появляется CRM. Потом ERP. Отдельно развивается мобильное приложение. Маркетинг подключает систему лояльности, HR работает в своей системе, финансы в своей. Где-то появляется BI, затем AI-сервис. Каждый проект можно защитить отдельно. У каждого есть заказчик, задача, бюджет. Иногда все они даже работают нормально.</p> <p>Через несколько лет обнаруживается другая проблема: весь этот набор плохо работает как единая система. Одни и те же данные хранятся в нескольких местах. У одного клиента разные ID. Часть информации синхронизируется автоматически, часть переносится вручную. Новая функция в мобильном приложении требует изменений в трех внутренних системах. Замена CRM неожиданно затрагивает продажи, приложение, аналитику и программу лояльности. Так появляется тот самый зоопарк ИТ-систем.</p> <p>В III Всероссийском опросе по цифровой трансформации Comindware, Artezio и РУССОФТ 60% участников <a href="https://www.comindware.ru/blog/investitsii-v-tsifrovizatsiyu-v-rossii-vyrosli-v-poltora-raza/amp/">сообщили</a>, что проводят отдельные проекты цифровизации, но не имеют общей стратегии. Еще 18% сказали, что такой стратегии нет вообще. 80% компаний используют разрозненные интеграции между информационными системами, а в единой цифровой среде работают только 12%.</p> <p>У этой проблемы уже вполне материальные последствия. К2Тех <a href="https://k2.tech/press_releases/opros-k2teh-68-kompanij-ne-vidyat-czelostnuyu-kartinu-biznesa-iz-za-zooparka-it-sistem/">опросил</a> более 300 руководителей и ИТ-специалистов средних и крупных российских компаний. 68% респондентов сообщили, что из-за зоопарка решений не могут получить целостную картину данных. 47% сталкиваются с высокими скрытыми затратами на поддержку разрозненных систем, еще 33% говорят о техническом долге, который мешает развитию.</p> <p>Проблема тут не в количестве программ. У крупной компании их и не может быть две или три. Вопрос в том, как устроены связи между ними и понимает ли компания, каким должен быть ее ИТ-ландшафт через несколько лет.</p> <p>Допустим, отделу продаж действительно нужна новая система. Помимо вопроса «Решает ли она нашу задачу?» стоит задать еще один: «Что произойдет со всей инфраструктурой после ее появления?». Новая система может дать локальный эффект сейчас, но заметно увеличить стоимость любых изменений потом.</p> <p>Что проверить до следующего внедрения? Нужно хотя бы на верхнем уровне понимать:</p> <ul> <li> какие системы новый продукт заменяет, а какие дополняет;</li> <li> какие данные он будет получать и передавать;</li> <li> где будет храниться мастер-версия данных;</li> <li> сколько новых интеграций появится;</li> <li> не придется ли хранить еще одну копию уже существующей информации;</li> <li> от каких систем и подрядчиков новый продукт будет зависеть;</li> <li> можно ли будет заменить его через несколько лет без перестройки половины ИТ-ландшафта.</li> </ul> <p>Здесь полезна архитектурная схема не только текущего состояния, но и целевого. Иначе цифровой контур формируется не потому, что его кто-то таким спроектировал, а потому что проекты запускались один за другим.</p> <h2>Ошибка 2. Не решить заранее, какой результат должен дать проект</h2> <p><strong>«</strong>Запустить CRM до декабря» звучит как цель. «Разработать приложение» тоже. Как и «автоматизировать оформление заказа», «внедрить AI» или «перевести сотрудников в новую систему». Только все это цели проекта, а не бизнеса.</p> <p>Русская школа управления в 2025 году <a href="https://uprav.ru/blog/55-rukovoditeley-nazyvayut-vysokuyu-stoimost-glavnym-barerom-tsifrovizatsii-biznesa/">опросила</a> руководителей и HR-специалистов российских компаний. 55% назвали одним из главных барьеров цифровизации высокую стоимость внедрения. Но на втором месте оказался гораздо более интересный ответ: <em>35% не понимают эффекта от цифровых решений</em>. Еще 29% назвали сопротивление сотрудников, 27% недостаток компетенций у руководителей, 26% сложности ИТ-инфраструктуры.</p> <p>Проблема становится заметна после релиза. Проект завершили. Система работает. Как понять, что несколько миллионов были потрачены не зря? <br/> Если до начала работы компания не измеряла текущий процесс, ответа может и не быть. </p> <p>Например, смысл нового личного кабинета может быть не в самом факте его появления, а в том, чтобы больше клиентов решали свои вопросы без обращения в поддержку.</p> <p>У автоматизации документооборота задача может состоять в сокращении срока согласования с пяти дней до одного. У нового внутреннего сервиса — в том, чтобы операция, которая занимала у сотрудника 20 минут, выполнялась за пять. А у мобильного приложения — не обязательно в росте установок. Возможно, важнее доля пользователей, дошедших до покупки или снижение нагрузки на офлайн-канал.</p> <p>Поэтому еще до разработки хорошо зафиксировать три вещи: что происходит сейчас. Например, обработка одной заявки занимает 40 минут. Что хотим получить. Например, 15 минут. Как и когда будем это измерять.</p> <p>Без первой точки сравнения можно получить красивый продукт, хорошие отзывы внутри команды и ни одного доказательства, что бизнес стал работать лучше. Еще хуже, когда KPI цифровизации выбирается из технических показателей. Количество функций, число релизов или процент готовности проекта мало говорят о результате для компании. Система может быть написана без критических ошибок, запущена в срок и полностью соответствовать техническому заданию. И одновременно быть неудачным бизнес-проектом.</p> <h2>Ошибка 3. Считать бюджет внедрения, а не реальную стоимость владения</h2> <p>Это одна из самых приземленных ошибок, потому что ее легко увидеть в деньгах. В <a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/">исследовании</a> ОБИТ 61% проблемных проектов были связаны с недооценкой стоимости владения ИТ-решением. Компании не полностью учитывали стоимость интеграции, дальнейшего обслуживания и обучения сотрудников. В 48% случаев возникали сложности интеграции с существующей инфраструктурой, в 35% выбранное решение не соответствовало фактическим требованиям бизнеса.</p> <p>По оценке ОБИТ, доработки и исправления после неудачного внедрения могут потребовать еще <nobr>10-30%</nobr> от первоначального бюджета. В отдельных случаях перезапуск проекта требует вложений, сопоставимых с первоначальными или даже вдвое большими.</p> <p>Если компания говорит, что внедрение стоит 15 млн. рублей, стоит уточнить, что именно входит в эти 15 млн.:</p> <ul> <li>Только разработка? </li> <li>Разработка и лицензии? </li> <li>А интеграции? </li> <li>Миграция данных? </li> <li>Изменения в действующих системах? </li> <li>Инфраструктура? </li> <li>Информационная безопасность? </li> <li>Переходный период, когда старое и новое решение работают параллельно?</li> <li> Обучение? </li> <li>Поддержка? </li> <li>Развитие продукта через год? </li> <li>Стоимость сотрудников заказчика, которые будут участвовать в проекте?</li> </ul> <p>Цифровой продукт редко заканчивает потреблять деньги в день релиза. Поэтому сравнивать варианты только по стоимости разработки не очень полезно.</p> <p>Условный проект может выглядеть так:</p> <ul> <li>15 млн. рублей стоит разработка и внедрение;</li> <li>еще 2 млн. потребовали доработки интеграций; </li> <li>1,5 млн. ушли на подготовку и миграцию данных из смежных ИС; </li> <li>1 млн. на переход и обучение;</li> <li>2,5 млн. на поддержку и доработки первого года.</li> </ul> <p>Мы получили уже 22 млн. вместо 15 млн. Это не среднерыночный расчет и не прогноз для любого проекта, а просто иллюстрация того, насколько по-разному могут выглядеть «стоимость разработки» и «сколько бизнес реально потратил на изменение». Поэтому разумнее считать совокупную стоимость владения (ТСО) хотя бы на несколько лет.</p> <p>Иногда более дорогой продукт на этапе покупки оказывается дешевле в эксплуатации. А иногда дешевое коробочное решение через два года обрастает таким количеством доработок, что стоимость его поддержки становится отдельной строкой бюджета.</p> <h2>Ошибка 4. Сначала выбрать технологию, а потом искать ей задачу</h2> <p>Еще несколько лет назад бизнес хотел блокчейн. Сейчас хочет AI. Между ними были супераппы, low-code, микросервисы и много чего еще. Фраза «нам нужно внедрить AI» сама по себе ничего не говорит о том, что компании нужно сделать. То же относится к CRM, ERP, мобильному приложению или отечественной замене зарубежной системы.</p> <p>В анализе ОБИТ 35% проблемных внедрений были связаны с тем, что выбранное решение не соответствовало фактическим бизнес-требованиям. В числе причин компания называет недостаточное тестирование продукта до внедрения и незрелость самого решения. Отдельно эта проблема проявилась во время импортозамещения.</p> <p>Т1 и РУССОФТ <a href="https://t1.ru/media/news/issledovanie-it-kholdinga-t1-i-russoft-spros-na-rossiyskie-it-resheniya-opredelyaetsya-strategiey-ra">исследовали</a> 78 российских компаний с фокусом на крупный бизнес. Среди серьезных препятствий при переходе на отечественные системы компании называли высокую стоимость новых продуктов, проблемы совместимости с текущей инфраструктурой и недостаточную функциональную зрелость части российских аналогов.</p> <p>Одновременно 54% респондентов уже включают миграцию на российские технологии в стратегию развития собственных информационных систем. Только 14% рассматривают импортозамещение исключительно как вынужденную реакцию на внешние обстоятельства.</p> <p>В исследовании РБК и Ростелекома среди 308 руководителей российских компаний 36,7% <a href="https://rtkit.rbc.ru/">назвали</a> одной из проблем импортозамещения интеграцию отечественных решений с существующими системами, 32,5% долгие сроки внедрения.</p> <p>То есть задача «заменим зарубежную систему на российскую» сама по себе тоже может оказаться слишком узкой. Если компания все равно вынуждена менять критичный кусок ИТ-ландшафта, логично сначала посмотреть, нужен ли ей точный цифровой аналог старого процесса. Возможно, за годы работы изменился сам бизнес, появились лишние этапы, а некоторые функции старого продукта уже никому не нужны.</p> <p>Поэтому порядок лучше разворачивать следующим образом: сначала проблема → затем целевой процесс → требования → ограничения текущей архитектуры → возможные решения → выбор между готовым продуктом, доработкой и собственной разработкой</p> <p>Не обязательно каждый раз писать новую систему. И не обязательно сразу раскатывать выбранное решение на всю компанию. Если технология новая, интеграций много, а процессы критичные, пилот часто дешевле большого запуска. На ограниченной группе пользователей можно проверить реальные сценарии, производительность, интеграции и ограничения продукта. Это намного лучше, чем обнаружить их после миграции нескольких тысяч сотрудников.</p> <p>После анализа проблемных проектов ОБИТ тоже рекомендует предварительное тестирование и пилотирование, а миграцию критичных систем проводить поэтапно.</p> <h2>Ошибка 5. Автоматизировать старый процесс, не задаваясь вопросом, нужен ли он таким вообще</h2> <p>Когда компания готовит требования к новой системе, самый простой способ их получить — описать текущую работу. Есть пять этапов согласования? Переносим пять этапов в систему. Сотрудник четыре раза вводит одни и те же данные? Сделаем ему четыре красивые формы. Раньше документ отправляли на почту руководителю? Теперь будет кнопка «Отправить руководителю». Формально это цифровизация. Но процесс остался прежним.</p> <p>Здесь есть показательный пример из финансового сектора. В исследовании Ассоциации ФинТех при участии К2Тех 70% компаний <a href="https://k2.tech/press_releases/67-finansovyh-kompanij-rf-vklyuchili-perehod-na-rossijskie-resheniya-v-svoi-strategii-razvitiya/">сообщили</a>, что в ходе трансформации ИТ-архитектуры провели аудит и пересмотр значимой части бизнес-процессов. Более 80% организаций отметили положительные эффекты такой перестройки: повышение эффективности, большую гибкость, создание задела для развития и работу с накопленным техническим долгом.</p> <p>Конечно, финансовый сектор нельзя автоматически переносить на весь российский бизнес. Но сам подход показателен: смена технологий становится поводом пересмотреть процесс, а не просто перенести его в новую систему.</p> <p>· До автоматизации полезно буквально нарисовать процесс как есть: что сейчас делает клиент, сотрудник и система. Затем нарисовать должно быть. И к каждому действию задать неприятный вопрос: </p> <ul> <li>А зачем оно вообще существует? </li> <li> Почему заявка должна пройти три согласования? </li> <li> Почему данные повторно вводятся руками? </li> <li> Почему менеджер переносит информацию из одной программы в другую? </li> <li> Почему человек принимает решение, которое полностью определяется набором формальных правил?</li> <li> Почему клиент должен заполнять то, что компания уже о нем знает?</li> <li> Какие этапы после цифровизации должны не ускориться, а исчезнуть?</li> <li> Если раньше сотрудник заполнял Excel, а теперь заполняет новую корпоративную систему и на всякий случай продолжает вести тот же Excel, то бизнес не очень много выиграл.</li> </ul> <h2>Ошибка 6. Недооценить интеграции, данные, безопасность и аварийные сценарии</h2> <p>На презентации новый продукт обычно выглядит отдельно. Есть красивые экраны приложения, новый личный кабинет, CRM или внутренняя платформа. В реальной ИТ-инфраструктуре ничего отдельно не существует.</p> <p>Мобильному приложению нужно получить пользователя из одной системы, остаток из другой, цены из третьей, историю заказов из четвертой, принять платеж через внешнего провайдера и вернуть результат в ERP. <br/> И здесь начинается та часть проекта, которую бизнес не всегда видит на старте. </p> <p>У ОБИТ сложности интеграции были причиной проблем в 48% проанализированных проектов. Компания отмечает, что они приводили не только к дополнительным затратам, но и к рискам простоев бизнес-процессов.</p> <p>У Comindware 80% участников исследования работают с разрозненными интеграциями.</p> <p>У К2Тех 74% опрошенных видят решение проблемы несогласованных данных в сквозной интеграции систем и создании единого контура управления данными. Интересно, что бизнес не обязательно хочет выбрасывать существующий ИТ-ландшафт: 46% компаний называют приоритетом оптимизацию текущих систем без масштабных инвестиций.</p> <p>То есть еще до интерфейсов полезно нарисовать карту интеграций и данных:</p> <ul> <li>Откуда приходит каждый тип информации?</li> <li> Какая система считается источником истины?</li> <li> Кому разрешено менять данные?</li> <li> Как часто они синхронизируются? </li> <li> Что происходит, если две системы содержат разные значения?</li> <li> Что будет, если внешнее API не отвечает?</li> <li> А если запрос был отправлен дважды?</li> <li> Как система восстановит операцию после сбоя?</li> <li> Кто увидит ошибку и кто будет ее разбирать?</li> <li> Вот эти вопросы часто влияют на стоимость проекта сильнее, чем количество экранов.</li> </ul> <strong>Отдельно стоит проверить, что будет при сбоях.</strong> <p>Цифровизация делает бизнес быстрее, но заодно сильнее связывает операции с технологиями. Если раньше недоступность одного сервиса мешала части сотрудников, после автоматизации сбой может остановить всю цепочку.</p> <p>КРОК в исследовании 70 ИТ-руководителей крупных и крупнейших российских компаний <a href="https://www.croc.ru/press_releases/issledovanie-krok-90-kompanij-apk-i-52-ritejlerov-stali-bolshe-tratit-na-it-v-2025-godu/">отметил</a>, что в 2025 году заметно вырос фокус на резервировании и отказоустойчивости. Среди инфраструктурных проблем 36% респондентов называли отсутствие резервного ЦОДа, необходимость зеркалировать резервные копии, дублировать сети и сервисы. Поэтому до запуска стоит проверять не только happy path, где все работает как задумано.</p> <ul> <li>Что произойдет, если платежный сервис недоступен два часа?</li> <li> Если упала CRM?</li> <li> Если внешняя система отвечает десять секунд вместо одной?</li> <li> Если в Black Friday нагрузка выросла в несколько раз?</li> <li> Если мобильное приложение работает, а один из внутренних сервисов нет?</li> </ul> <p>Хорошая архитектура предусматривает не только полную работоспособность, но и управляемую деградацию. Пользователь по возможности должен сохранить хотя бы часть сценариев, а бизнес понимать, как система вернется в штатный режим.</p> <p><strong>И безопасность нельзя добавлять последним пунктом перед релизом. </strong></p> <p>Исследования показали, что крупные российские компании назвали соответствие высоким требованиям информационной безопасности главным критерием выбора ИТ-партнера, а кибербезопасность остается одним из основных направлений ИТ-инвестиций российского бизнеса.</p> <p>Но безопасность влияет не только на выбор подрядчика. Она может заметно поменять архитектуру, способ хранения данных, процессы авторизации, интеграции, инфраструктуру и стоимость разработки. Если требования ИБ появляются после того, как продукт уже почти готов, часть работы иногда приходится делать заново.</p> <h2>Ошибка 7. Решить, что legacy обязательно нужно переписать</h2> <p>Старому коду легко назначить виноватого. Если релизы идут медленно, разработчики жалуются на монолит, документации мало и вокруг системы накопилось много странных решений, появляется естественное желание: давайте перепишем все нормально. Иногда это правда правильный вариант. Но возраст системы сам по себе еще не бизнес-проблема.</p> <p>Опираясь на данные вышеуказанных исследований, 78% российских компаний, использующих облачные технологии, сохраняют legacy-системы. У 14% legacy составляет больше половины ИТ-портфеля. 46% участников называют одним из главных приоритетов оптимизацию существующих систем без масштабных инвестиций. В исследовании КРОК более 30% респондентов говорили о необходимости обновления оборудования и работы с legacy. Тут нет противоречия. Потому что legacy можно модернизировать по-разному.</p> <p>Допустим, старое ядро работает стабильно, содержит критическую бизнес-логику и справляется с нагрузкой. Но у него плохие интеграции. Тогда иногда разумнее оставить ядро и построить нормальный API-слой.</p> <p>Если тормозит один модуль, можно вынести его. Если система мешает независимым релизам, разделить наиболее проблемные компоненты. Если высокая стоимость поддержки связана с конкретной частью кода, провести рефакторинг именно там.</p> <p>Полная замена тоже возможна, но тогда бизнесу стоит понимать, что именно он покупает за стоимость переписывания:</p> <ul> <li>Будут быстрее запускаться функции?</li> <li> Снизится стоимость поддержки?</li> <li> Уйдут ограничения по нагрузке?</li> <li> Станет проще находить разработчиков?</li> <li> Исчезнут риски безопасности?</li> <li> Можно будет подключать новые продукты?</li> <li> Если на эти вопросы нет ответа, то проект под названием «перепишем все с нуля» легко превращается в очень дорогой способ получить почти то же самое.</li> </ul> <p>Особенно рискован big bang, когда старая система выключается, а новая должна одномоментно заменить все функции. Чем критичнее продукт, тем разумнее рассматривать поэтапную миграцию, когда часть функций или пользователей переводится последовательно и у команды остается возможность проверить систему на реальной работе.</p> <p>Иногда хороший результат технического аудита звучит не как «вам нужно 30 млн. рублей на новый продукт», а как «эту часть вообще не трогаем».</p> <h2>Ошибка 8. Сначала внедрить AI, а потом разбираться с данными</h2> <p>С AI проблема качества данных стала гораздо заметнее. Можно купить хороший инструмент прогнозирования, подключить BI, внедрить AI-ассистента или модель для автоматического принятия решений. Но если клиент хранится в трех системах под разными идентификаторами, справочники не совпадают, часть данных вводится вручную, а происхождение цифры в отчете никто не может объяснить, новая технология это не исправит. Она будет работать с тем, что ей дали.</p> <p>51% компаний сохраняют внедрение AI среди ключевых приоритетов. Одновременно 68% респондентов говорят, что не получают целостной картины данных из-за разрозненного ИТ-ландшафта.</p> <p>В исследовании КРОК качество входных данных и отсутствие формальных регламентов названы среди факторов, которые мешают масштабированию технологических инициатив.</p> <p>Отдельно Strategy Partners <a href="https://strategy.ru/research/research/polovina-promyshlennyh-predpriyatij-ispytyvaet-deficit-chelovecheskih-resursov-i-kompetencij-dlya-raboty-s-dannymi/">исследовала</a> работу с данными на российских промышленных предприятиях. В 56% компаний ручной ввод остается распространенным способом сбора данных. Только у четверти есть отдельное подразделение для работы с данными, еще у 36% выделен специалист по аналитике. Среди основных барьеров компании называют нехватку людей, компетенций и технических ресурсов.</p> <p>Это особенно важный момент для AI-проектов, потому что там качество исходной информации напрямую связано с качеством результата.</p> <p>До запуска стоит разобраться:</p> <ul> <li> где хранится мастер-версия данных;</li> <li> кто является их владельцем;</li> <li> кто отвечает за качество;</li> <li> есть ли дубли;</li> <li> насколько информация полная и свежая;</li> <li> как изменяются справочники;</li> <li> можно ли понять происхождение конкретного значения;</li> <li> какие данные вообще нельзя использовать в выбранном сценарии;</li> <li> кто отвечает за ошибку, если автоматическая система приняла неправильное решение.</li> </ul> <p>Если у компании три разных значения одного показателя в трех системах, AI не создаст магическим образом правильное. Есть риск, что появится просто четвертый вариант.</p> <h2>Ошибка 9. Считать, что цифровизация закончилась в день релиза</h2> <p>Команда несколько месяцев или лет делает систему. Проходит приемка. Проект закрывают. На презентации появляется зеленый статус «внедрено». А сотрудники продолжают пользоваться Excel. Или переносят часть данных вручную. Или нашли способ обходить новый процесс, потому что старый быстрее. Или система используется, но время выполнения операции не уменьшилось.</p> <p>Технический запуск еще не означает, что произошло изменение бизнеса.</p> <p>В исследовании Т1 и РУССОФТ сопротивление сотрудников новым системам отметили 79,5% представителей крупных компаний. В исследовании Русской школы управления эту проблему отметили 29% респондентов.</p> <p>Разница в цифрах большая, потому что исследования изучали разные выборки и сценарии. Т1 и РУССОФТ рассматривали крупный бизнес и переход на отечественные системы, РШУ шире спрашивала о цифровизации управленческих процессов. Но обе работы показывают, что технология сама по себе не заставляет людей изменить способ работы.</p> <p>И здесь легко дать неправильный совет: «нужно лучше обучать сотрудников». Обучение нужно, но сначала стоит проверить сам продукт. Если раньше сотрудник выполнял пять действий, а после внедрения системы делает восемь, сопротивление не обязательно связано с консерватизмом. Если новая программа работает медленнее старой, человек будет искать обходной путь. Если данные нужно вводить и в старую, и в новую систему, он продолжит вести Excel. Если продукт не учитывает реальные исключения из процесса, сотрудники быстро построят вокруг него собственный параллельный процесс в почте и мессенджерах.</p> <p>Поэтому после релиза важно измерять не только технические показатели. Да, нужны uptime, количество ошибок и SLA. Но параллельно стоит смотреть:</p> <ul> <li> какая доля сотрудников действительно работает в новой системе;</li> <li> какую часть процесса они проходят в ней полностью;</li> <li> сколько ручных операций осталось;</li> <li> сколько времени занимает задача;</li> <li> изменилась ли частота ошибок;</li> <li> не продолжают ли сотрудники вести параллельные таблицы;</li> <li> как часто им приходится обходить систему;</li> <li> изменился ли бизнес-показатель, ради которого все начиналось.</li> </ul> <p><strong>Цифровизация заканчивается тогда, когда изменился процесс и появился измеримый результат для бизнеса.</strong></p> <p>Именно поэтому сложный цифровой продукт почти никогда нельзя воспринимать как объект, который один раз разработали и забыли. Меняется бизнес, появляются новые требования, интеграции, регуляторика, нагрузка. Продукту приходится меняться вместе с ними.</p> <h2>Что проверить до того, как утвердить бюджет</h2> <p>Ошибки из этой статьи могут выглядеть очень разными, но большинство можно обнаружить до начала большой разработки. Перед запуском проекта полезно честно ответить хотя бы на несколько групп вопросов.</p> <p><strong>Бизнес</strong><strong>:</strong></p> <ul> <li>Какую проблему мы решаем?</li> <li> Сколько она стоит компании сейчас? </li> <li> Какой показатель должен измениться после запуска?</li> <li> Знаем ли мы его текущее значение?</li> <li> Как поймем через полгода, что проект сработал?</li> </ul> <p><strong>Процесс</strong><strong>:</strong></p> <ul> <li>Нужно ли вообще автоматизировать процесс в его нынешнем виде?</li> <li> Какие этапы можно убрать?</li> <li> Какие действия должен перестать делать человек?</li> <li> Не создаем ли мы цифровую копию старой бюрократии?</li> </ul> <p><strong>ИТ-ландшафт</strong><strong>:</strong></p> <ul> <li>Какие системы затронет новый продукт?</li> <li> Сколько интеграций потребуется?</li> <li> Где находится источник истины для каждого типа данных?</li> <li> Что придется доработать в существующих системах?</li> <li> Что будет, если одна из интеграций перестанет работать?</li> </ul> <p><strong>Деньги</strong><strong>:</strong></p> <ul> <li>Посчитана стоимость разработки или полная стоимость владения?</li> <li> Учтены ли миграция данных, инфраструктура, интеграции и обучение?</li> <li> Как будет финансироваться поддержка?</li> <li> Кто будет развивать систему после первого релиза?</li> <li> Сколько решение будет стоить компании через три года?</li> </ul> <p><strong>Технология</strong><strong>:</strong></p> <ul> <li>Почему выбран именно этот класс решений?</li> <li> Смотрели ли мы альтернативы?</li> <li> Нужна ли собственная разработка?</li> <li> Можно ли доработать существующий продукт?</li> <li> Нужно ли действительно полностью переписывать legacy?</li> <li> Можно ли сначала проверить гипотезу на пилоте?</li> </ul> <p><strong>Риски</strong><strong>:</strong></p> <ul> <li>Что произойдет при пиковой нагрузке?</li> <li> Как работает система при частичной недоступности сервисов?</li> <li> Есть ли план поэтапной миграции и возможность отката?</li> <li> Учтены ли требования информационной безопасности в архитектуре, а не только перед релизом?</li> <li> Какие данные система получает и можно ли им доверять?</li> </ul> <p><strong>Пользователи</strong><strong>:</strong></p> <ul> <li>Участвовали ли реальные сотрудники или клиенты в проверке сценариев?</li> <li> Станет ли им проще выполнять задачу?</li> <li> Не придется ли пользоваться старой и новой системой одновременно?</li> <li> Как мы измерим реальное использование продукта после запуска?</li> </ul> <p>Если на значительную часть этих вопросов пока нет ответа, возможно, компании еще рано проводить тендер на разработку.</p> <p>Иногда первым этапом должен стать не дизайн приложения и не оценка программистами количества часов, а обследование: разбор процессов, архитектуры, интеграций, данных, технического долга, требований безопасности и экономики будущего решения.</p> <p>Такой этап тоже стоит денег. Но его задача как раз в том, чтобы не выяснять самые дорогие особенности проекта тогда, когда контракт уже подписан, команда работает, а половина бюджета потрачена.</p> <p>Цифровизация обходится дорого не только тогда, когда разработчики ошибаются в коде. Гораздо больше денег можно потерять раньше: выбрать не ту задачу, не посчитать владение, добавить еще одну систему в уже сложный ландшафт или автоматизировать процесс, который стоило сначала переделать.</p> <p>И чем крупнее проект, тем дороже становится вопрос, который бизнес не задал себе на старте.</p> <p> #IMAGE_235402#</p> Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих … article Владимир Белозеров, заместитель коммерческого директора компании KODE https://www.itweek.ru/themes/detail.php?ID=235416 Wed, 26 Aug 2026 17:10:38 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI платформы. Обновление позволяет снизить нагрузку на администраторов системы и сократить количество ручных действий за счет гибкой настройки индикаторов SLA и копирования блоков рабочих процессов, а также упрощает работу с записями в связанных списках благодаря добавлению поддержки массового редактирования.</p> <p>Ключевое изменение версии 1.35.0 — более гибкая настройка индикаторов SLA. Теперь параметры расчёта индикации — момент запуска отсчёта, момент превышения срока, рабочее расписание и часовой пояс — можно определять не только вручную, но и на основании данных из связанных с обращением записей. </p> <p>Такая функциональность полезна в территориально распределённых компаниях. Например, сроки по заявке нужно считать по графику той площадки, которая обслуживает сотрудника: у сотрудника указан город, у города — обслуживающая площадка, у площадки — свой рабочий календарь и часовой пояс. Раньше под каждый календарь приходилось заводить отдельный индикатор, клиенты компании сообщали о <nobr>10–15</nobr> копиях одного и того же SLA. Теперь достаточно одного индикатора: он проходит по цепочке связей и охватывает нужные параметры сам. Календарь — только один из параметров, по тому же механизму задаются часовой пояс и обе временны́е точки. При этом источником служит любая связанная с обращением запись, то есть под контекст подстраивается не отдельный сценарий, а расчёт SLA целиком.</p> <p>Второе значимое улучшение — добавление возможности копирования блоков в редакторе рабочих процессов. Администраторы теперь могут копировать блок действий в текущие процессы, а также другие рабочие процессы, сохранив все параметры настройки. Новая функциональность заметно ускоряет настройку процессов и сокращает количество ошибок при настройке.</p> <p>Дополнительно были расширены возможности массового редактирования: теперь редактирование поддерживается не только в основных списках записей, но и в связанных списках. Администраторы и агенты поддержки могут быстро вносить одинаковые изменения сразу в несколько записей, без необходимости переходить в отдельное представление списка.</p> <p>«Мы сознательно сосредоточились на участках, где у администраторов больше всего рутины: гибкие SLA и переиспользование блоков рабочих процессов. Для нас стоимость владения системой — отдельное направление развития в каждом релизе. Мы считаем, что платформа должна дешеветь в сопровождении по мере роста конфигурации, не наоборот. Ведь именно от нагрузки, связанной с поддержкой системы, зависит, сколько времени и ресурсов команда клиента сможет потратить на ее развитие», — прокомментировал Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG.</p> <p>Помимо новой функциональности, в версии 1.35.0 устранён ряд дефектов, включая проблемы с контейнерами, уязвимости безопасности и ошибки в работе индикаций. </p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI платформы. Обновление … message https://www.itweek.ru/themes/detail.php?ID=235415 Wed, 26 Aug 2026 17:09:06 +0300 <p>Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное, безопасное и системное использование инструментов генеративного ИИ для проектов по интеграции данных и разработке дата-продуктов. Новый подход призван перевести корпоративные ИИ-эксперименты из режима точечного применения в управляемый процесс с прозрачными расчетами, которые опираются на отслеживаемые данные и дают контролируемый результат. </p> <p>Методология предназначена для компаний, которые уже используют или планируют использовать <nobr>LLM-инструменты</nobr> и ИИ-агентов в разработке решений по управлению данными. </p> <p>В ее основе лежит концепция Data Governance, переосмысленная с учетом современных возможностей генеративного ИИ. Дата-продукты являются разновидностью программного обеспечения, однако обладают целым рядом особенностей, требующих отдельной методики разработки. В традиционной разработке основной фокус сосредоточен на функциях продукта: интерфейсе, бизнес-логике, пользовательских сценариях, фронтенде и бэкенде. В случае с дата-продуктами он направлен преимущественно на сами данные — их происхождение, определения, взаимосвязи, контекст и правила интерпретации. </p> <p>Ключевая задача методологии — сделать так, чтобы данным можно было верить. В корпоративной среде недостаточно получить цифру, которая выглядит правдоподобно. Важно понимать, из каких источников она получена, по каким правилам рассчитана, какие исходные данные использовались, кто отвечает за определения, можно ли воспроизвести расчет и т.п. Качество данных особенно важно для бизнес-аналитики, управленческой и регуляторной отчетности.</p> <p>Ошибка в одном показателе или неоднозначность в трактовке данных может привести к неверным руководящим решениям, в том числе стратегическим, а также к претензиям со стороны надзорных органов.</p> <p>Предложенный подход включает ряд ключевых этапов:</p> <ul> <li>оценку текущей зрелости компании в работе с данными и ИИ-инструментами;</li> <li>адаптацию методологии к конкретным бизнес-реалиям и ИТ-ландшафту;</li> <li>определение функциональной архитектуры будущей системы;</li> <li>анализ уже существующих инструментов Data Governance, каталогов, глоссариев и средств контроля качества данных;</li> <li>выявление недостающих элементов;</li> <li>выбор инструментов для поддержки целевого процесса;</li> <li>запуск пилотного проекта по созданию дата-продукта по новой методике;</li> <li>формирование контекстного и семантического слоя для уже существующих источников.</li> </ul> <p>Методология вводит понятие опорного слоя и придает ему особое значение. Опорный слой включает в себя онтологию и семантику, а также так называемый контур доверия. Без него невозможно обеспечить единое понимание бизнес-понятий, метрик и правил интерпретации данных на уровне всей компании. Именно опорный слой должен стать связующим элементом между бизнес-смыслом, источниками данных, методиками расчета показателей и ИИ-инструментами, которые участвуют в разработке, а в дальнейшем, и потреблении данных.</p> <p>Методология также предполагает бережное отношение к уже сделанным компанией инвестициям. Если у нее есть каталоги данных, бизнес-глоссарии, инструменты контроля качества или другие элементы Data Governance, их не нужно заменять автоматически. В них уже накоплены метаданные, определения и управленческий контекст. Задача состоит в том, чтобы встроить существующие активы в новую архитектуру, определить недостающие элементы и обеспечить совместимость старого и нового подходов.</p> <p>«Есть иллюзия, что с помощью ИИ можно в считанные минуты сгенерировать нужное приложение, имея только бизнес-идею. На самом деле это не так просто, особенно в отношении дата-продуктов. Крайне важно определить для ИИ „смысл“ данных компании, погрузить его в контекст. В противном случае есть серьезный риск получить „черный ящик“, корректность и безопасность работы которого невозможно проверить. Наша методология объясняет, как сформировать грамотную среду управления данными и построить взаимодействие с ИИ так, чтобы дата-продукты были предсказуемыми, прозрачными и воспроизводимыми и как результат, давали корректную аналитику», — прокомментировала Лариса Малькова, управляющий директор практики «Данные и прикладной ИИ» Axenix.</p> Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное … message https://www.itweek.ru/themes/detail.php?ID=235414 Wed, 26 Aug 2026 17:04:43 +0300 <p>Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие решения на базе ИИ: постоянное взаимодействие с технологией дает им комплексное представление о ее возможностях, ограничениях и влиянии на рынок труда. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил прогнозные оценки более 500 таких организаций, полученные в рамках Мониторинга разработки и применения технологий искусственного интеллекта и цифровой трансформации бизнеса.</p> <p>В работе с информацией направление изменений зависит от характера выполняемых задач. Спрос на базовые навыки, связанные с вводом данных и подготовкой документации, будет в целом снижаться (сокращение прогнозируют 45% организаций, рост — 25%), а на аналитические компетенции — расти (36% против 27% прогнозирующих снижение). ИИ автоматизирует рутинные операции, однако постановка задач, интерпретация выводов и принятие решений сохранятся за специалистами.</p> <p>Для ИТ-навыков оценки влияния ИИ оказались неоднозначными. Снижение спроса на навыки программирования прогнозируют 30% организаций, рост — 29%, стабильность — 34%. Автоматизация части работы с кодом может сдерживать найм, однако усложнение программных продуктов и интеграция ИИ-моделей одновременно повышают потребность в технической экспертизе. Востребованность навыков установки и защиты компьютерных систем оценивается более определенно: роста спроса ожидают 38% респондентов, снижения — лишь 11%. Вероятно, увеличение объема генерируемого ИИ кода и применение технологии для кибератак повышают потребность в квалифицированном контроле, настройке и защите систем.</p> <p>В менеджменте центр тяжести будет смещаться от администрирования к стратегии и лидерству. Снижение управленческих рутин прогнозируют 35% организаций, рост — 26%. При этом повышения востребованности стратегического мышления и навыков управления процессами ожидают 41% респондентов, лидерства и мотивации — 36%; снижение спроса на эти навыки предполагают лишь 6 и 4% соответственно. Документооборот, календарное планирование и контроль отчетности поддаются автоматизации, тогда как выбор приоритетов, разрешение конфликтов, мотивация команды и формирование среды доверия остаются за руководителями.</p> <p>Для рабочих профессий уязвимость перед ИИ зависит прежде всего от степени стандартизации операций и разнообразия условий труда. В обследовании сопоставлялись навыки разного уровня квалификации — от вождения и обслуживания оборудования до сортировки, погрузки, сборки и строительства. Наиболее высок риск снижения спроса на сортировку и упаковку: сокращение прогнозируют 29% организаций, рост — 16%. Значительно устойчивее монтаж и ремонт оборудования (снижение ожидают только 6%, рост — 24%) и строительство (снижение — 8%; две трети респондентов предполагают сохранение или рост спроса). В отношении вождения оценки разделились: 21% ожидают сокращения востребованности, 22% — повышения. Повторяющиеся операции в стабильных условиях легче передать роботизированным системам, тогда как работа в изменчивой среде пока требует человеческой адаптивности. В долгосрочной перспективе развитие робототехники и автономных систем будет расширять границы автоматизации.</p> <p>Высокой устойчивостью к ИИ-автоматизации обладают человекоориентированные компетенции: уход за людьми, оказание медицинских услуг, коммуникации, сотрудничество, консультирование, креативность. Наименее уязвимы навыки, основанные на командной работе, общении, доверии и физическом присутствии: снижение спроса на них прогнозируют лишь <nobr>9–13%.</nobr> Более неоднозначно оценивается креативность: роста ее востребованности ожидают 28% респондентов, снижения — 23%. С одной стороны, ИИ уже способен генерировать тексты и изображения, с другой — снижает порог входа в креативную деятельность, беря на себя технические задачи и тем самым создавая возможности для новых замыслов и подходов.</p> <p>Изменения профессиональных компетенций затронут большинство профессий. Риски и возможности, которые несет ИИ, определяются не статусом профессии или уровнем квалификации работников, а содержанием выполняемых задач. Повторяющиеся стандартизированные задачи, которые можно описать с помощью инструкций и алгоритмов, в перспективе будут переданы ИИ, а необходимые для их выполнения навыки потеряют ценность. Одновременно увеличится спрос на компетенции более высокого порядка, связанные с принятием решений в условиях неопределенности, лидерством, командной работой, обеспечением безопасности. Итоговый баланс оценок подтверждает этот сдвиг: верхние позиции заняли стратегическое управление, лидерство и мотивация, установка и защита компьютерных систем, нижние — документирование информации, сортировка и упаковка, простые административные задачи.</p> Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие … message https://www.itweek.ru/themes/detail.php?ID=235413 Wed, 26 Aug 2026 17:04:31 +0300 <p><em>Рост инвестиций в развитие российских софтверных компаний, который достигал примерно <nobr>30-35%</nobr> в 2024 году, в 2025 году сменился их сокращением на 37%. Абсолютная величина совокупных инвестиций уменьшилась с ₽575 млрд. до ₽360 млрд.</em></p> <p>В условиях отсутствия других полноценных источников инвестиций почти вся прибыль предприятий, специализирующихся на разработке ПО, направляется на развитие, поэтому увеличение налоговой нагрузки неизбежно привело к сокращению инвестиционной активности. Напомним, что с 1 января 2025 года был введен НДС для малых компаний, использующих УСН, а вместо нулевого налога на прибыль для аккредитованных ИТ-компаний введена ставка в размере 5%.</p> <p>Математически само по себе увеличение отчислений в бюджет могло дать сокращение только на <nobr>5-10%.</nobr> На увеличение налоговой нагрузки наложилось снижение темпов роста спроса из-за высокой ставки ЦБ РФ и ряда других факторов. В результате продажи компаний-разработчиков ПО росли медленнее их затрат, а это привело к снижению рентабельности софтверного бизнеса.</p> <p><strong>Основные показатели, характеризующие инвестиционную активность в софтверной индустрии в <nobr>2024-2026</nobr> годах</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2024 г.</p> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Отношение совокупных инвестиций к совокупному обороту софтверных компаний</p> </td> <td> <p>23,5%</p> </td> <td> <p>12,8%</p> </td> <td> <p>13,0%</p> </td> </tr> <tr> <td> <p>Объем инвестиций</p> </td> <td> <p>₽575 млрд</p> </td> <td> <p>₽360 млрд</p> </td> <td> <p>₽425 млрд</p> </td> </tr> <tr> <td> <p>Доля опрошенных компаний, сообщивших о привлечении инвестиций</p> </td> <td> <p>47,2%</p> </td> <td> <p>38,0%</p> </td> <td> <p>35,3%</p> </td> </tr> <tr> <td> <p>Доля внешнего финансирования <br/> в общем объеме инвестиций </p> </td> <td> <p>19,3%</p> </td> <td> <p>17,7%</p> </td> <td> <p>19,0%</p> </td> </tr> <tr> <td> <p>Доля опрошенных компаний, сообщивших о наличии внешних инвестиций</p> </td> <td> <p>27,4%</p> </td> <td> <p>25,5%</p> </td> <td> <p>25,1%</p> </td> </tr> <tr> <td> <p>Общий объем внешних инвестиций</p> </td> <td> <p>₽110 млрд</p> </td> <td> <p>₽64 млрд</p> </td> <td> <p>₽81 млрд</p> </td> </tr> </tbody> </table> <p>Ассоциация РУССОФТ проводила в 2025 году экспресс-опросы софтверных компаний с целью моделирования изменения ряда показателей финансового состояния бизнеса при сохранении всех льгот и при частичном лишении налоговых послаблений. Результаты этих опросов показали, что увеличение налоговой нагрузки негативно отразится прежде всего на объеме инвестиций. При нынешних условиях в софтверной индустрии существует прямая корреляция совокупной прибыли софтверных компаний и совокупных вложений в их развитие. Поскольку совокупная чистая прибыль по итогам 2025 года сократилась примерно на треть, то и почти аналогично снизился объем инвестиций в софтверной индустрии.</p> <p>С 1 января 2026 года было введено еще одно изменение в налоговой политике — страховые взносы для аккредитованных ИТ-компаний увеличились примерно вдвое (с 7,6% до 15%). С учетом того, что <nobr>60-80%</nobr> затрат софтверных компаний приходится на фонд оплаты труда, дополнительные отчисления существенно сокращают прибыль при прочих равных условиях. Тем не менее, результаты опроса показывают сдержанный оптимизм.</p> <p>Расчеты на основании планов опрошенных компаний на 2026 год дают рост совокупных инвестиций на 18%. Предположительно выручка увеличится на 17%, чуть возрастет доля внешнего финансирования (с 17,7% до 19,0%), а дополнительные отчисления в пенсионный и социальные фонды частично компенсирует снижение темпов роста средней зарплаты. Прибавка на 18% отражает скорее самый оптимистический сценарий. Реалистичный же предполагает меньший прирост. При этом нельзя исключить и сокращение инвестиций.</p> <p>Показатель удовлетворенности респондентов имеющимся объемом инвестиций, как правило, очень низкий. Опрашиваемые компании в течение нескольких лет видели перспективы окупаемости при вложениях, которые должны были быть в <nobr>2-3</nobr> раза больше фактических. Произошедший в 2021 году инвестиционный бум привел к тому, что потребность в инвестициях в индустрию была удовлетворена намного лучше, чем в предыдущие годы — на 58%. В 2022 году произошел рост показателя удовлетворенности респондентами объемами финансовых вложений до 63%, но этот год был особенным: из-за высокой степени неопределенности не столько выросли вложения, сколько снизилась в них потребность. В 2023 году показатель удовлетворенности снизился до 51%, а в 2024 году — до 42%. Уменьшение этого показателя при росте объема инвестиций говорит о том, что потребность в инвестициях росла быстрее, чем объем инвестиций в развитие софтверных компаний, что было объяснимо на фоне активной реализации процесса импортозамещения ПО.</p> <p>По итогам 2025 года показатель удовлетворенности в инвестициях уменьшился еще больше. По всем опрошенным компаниям фактические вложения составили менее четверти от требуемых (23,5%). Если опираться на ожидания опрошенных компаний, то в 2026 году этот показатель должен повыситься, но все же останется очень низким — 27,2%.</p> <p>Удовлетворенность в объеме инвестиций ниже у продуктовых компаний в сравнении с сервисными, что объясняется их потребностью в разработке собственного программного продукта, что занимает длительное время.</p> <h3>Распределение стабильно</h3> <p>По итогам 2024 года доля собственных инвестиций софтверных компаний составила 77,3%. В 2025 году изменение этого показателя оказалось незначительным. В 2026 году имеются надежды на небольшое увеличение внешнего финансирования (прежде всего, государственного), но структура инвестиций в целом ожидается неизменной при допущении незначительных колебаний.</p> <p><strong>Распределение объема инвестиций в индустрию программного обеспечения по источникам финансирования (по итогам <nobr>2024-2026 годов)</nobr></strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2024 г.</p> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Собственные вложения (реинвестиции из прибыли)</p> </td> <td> <p>77,3%</p> </td> <td> <p>76,8%</p> </td> <td> <p>74,8%</p> </td> </tr> <tr> <td> <p>Дополнительные вложения учредителей</p> </td> <td> <p>3,5%</p> </td> <td> <p>5,6%</p> </td> <td> <p>6,2%</p> </td> </tr> <tr> <td> <p>Полученные от заказчиков/клиентов средства, которые пошли на развитие (создание новых тиражируемых решений или новых версий уже существующих решений)</p> </td> <td> <p>15,7%</p> </td> <td> <p>13,85%</p> </td> <td> <p>14,4%</p> </td> </tr> <tr> <td> <p>Государственное финансирование (без участия частных инвесторов), включая гранты и субсидирование льготного кредитования</p> </td> <td> <p>1,9%</p> </td> <td> <p>1,6%</p> </td> <td> <p>4,3%</p> </td> </tr> <tr> <td> <p>Вложения сторонних частных инвесторов (в т. ч. фондовый рынок, венчурные фонды, включая созданные с участием государства)</p> </td> <td> <p>0,4%</p> </td> <td> <p>2,15%</p> </td> <td> <p>0,3%</p> </td> </tr> <tr> <td> <p>Другие источники</p> </td> <td> <p>1,2%</p> </td> <td> <p>—</p> </td> <td> <p>—</p> </td> </tr> </tbody> </table> <p>Если при анализе данных по распределению инвестиций между собственными и привлеченными средствами по итогам 2025 года к собственным средствам добавить инвестиции со стороны учредителей, то эта доля увеличится до 82,4%. Следовательно, на все источники внешнего финансирования приходится 17,6%. Годом ранее этот показатель был равен 19,2%.</p> <p>Вложения сторонних частных инвесторов обеспечивают 2,15% общего объема инвестиций, а годом ранее они составляли 0,4%. Однако делать вывод о каком-то росте активности частных инвесторов пока преждевременно. При единичных случаях привлечения внешних инвесторов очень велико влияние случайных факторов. Рост до 2,15% в 2025 году обеспечила одна компания, участвовавшая в опросе. Без учета ее данных такого роста не будет. К тому же, в 2026 году ожидается возвращение участия внешних источников инвестиций к прежнему уровню.</p> <h3>Самые привлекательные</h3> <p>При делении компаний на категории выяснилось, что у компаний с выручкой менее ₽375 млн. в 2025 году имелась бОльшая доля внешних инвестиций в общем объеме вложений, чем у компаний большего размера. Аналогичное преимущество имелось у небольших предприятий по итогам 2024 года. Соотношение общего объема вложений к обороту у них также выше, чем у компаний с выручкой более ₽375 млн.</p> <p>Продуктовая модель предполагает бОльшую инвестиционную привлекательность в сравнении с сервисной. Однако доля внешнего финансирования в общем объеме инвестиций в <nobr>2024-2025</nobr> годах была выше именно у сервисных компаний. Это, скорее всего, связано с меньшими рисками для внешних инвесторов из-за более коротких сроков окупаемости, и с более низкой рентабельностью, а значит меньшим объемом наличия у них собственных средств для инвестиций.</p> <p>Если по итогам 2024 года соотношение объема инвестиций в развитие относительно оборота были выше у компаний, которые работают только в России в сравнении с предприятиями, имеющими продажи за рубежом, то по итогам 2025 года произошло выравнивание показателей у этих двух категорий компаний.</p> <p><strong>Данные об инвестициях по категориям опрошенных компаний по итогам 2025 года</strong> </p> <table> <tbody> <tr> <td> </td> <td> <p>Объем инвестиций <br/> по отношению к обороту </p> </td> <td> <p>Сообщили <br/> о наличии инвестиций <br/> в 2025 г.,% опрошенных компаний </p> </td> <td> <p>Доля внешнего финансирования во всём объеме инвестиций</p> </td> <td> <p>Сообщили <br/> о наличии внешнего финансирования в 2025 г.,% опрошенных компаний </p> </td> </tr> <tr> <td> <p><strong>Все опрошенные компании</strong></p> </td> <td> <p>13,8%</p> </td> <td> <p>38,0%</p> </td> <td> <p>9,9%</p> </td> <td> <p>25,5%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Размер компаний</strong></p> </td> </tr> <tr> <td> <p>Оборот <br/> менее ₽375 млн </p> </td> <td> <p>24,2%</p> </td> <td> <p>35,7%</p> </td> <td> <p>19,4%</p> </td> <td> <p>24,2%</p> </td> </tr> <tr> <td> <p>Оборот <br/> более ₽375 млн </p> </td> <td> <p>13,1%</p> </td> <td> <p>43,8%</p> </td> <td> <p>8,9%</p> </td> <td> <p>28,8%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Модель бизнеса</strong></p> </td> </tr> <tr> <td> <p>Продуктовая</p> </td> <td> <p>15,0%</p> </td> <td> <p>42,6%</p> </td> <td> <p>8,6%</p> </td> <td> <p>23,6%</p> </td> </tr> <tr> <td> <p>Сервисная</p> </td> <td> <p>6,8%</p> </td> <td> <p>31,8%</p> </td> <td> <p>22,4%</p> </td> <td> <p>28,0%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Наличие экспортных доходов</strong></p> </td> </tr> <tr> <td> <p>Не присутствовали <br/> за рубежом в 2025 г. </p> </td> <td> <p>14,8%</p> </td> <td> <p>33,9%</p> </td> <td> <p>11,5%</p> </td> <td> <p>26,3%</p> </td> </tr> <tr> <td> <p>Присутствовали <br/> за рубежом в 2025 г. </p> </td> <td> <p>12,5%</p> </td> <td> <p>39,5%</p> </td> <td> <p>9,8%</p> </td> <td> <p>18,6%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Местоположение головного офиса</strong></p> </td> </tr> <tr> <td> <p>Москва</p> </td> <td> <p>14,3%</p> </td> <td> <p>39,7%</p> </td> <td> <p>17,2%</p> </td> <td> <p>23,8%</p> </td> </tr> <tr> <td> <p>Петербург</p> </td> <td> <p>13,2%</p> </td> <td> <p>38,8%</p> </td> <td> <p>10,8%</p> </td> <td> <p>24,5%</p> </td> </tr> <tr> <td> <p>Другие города</p> </td> <td> <p>13,6%</p> </td> <td> <p>37,1%</p> </td> <td> <p>7,1%</p> </td> <td> <p>26,6%</p> </td> </tr> </tbody> </table> Рост инвестиций в развитие российских софтверных компаний, который достигал примерно 30-35% в 2024 году … message https://www.itweek.ru/themes/detail.php?ID=235407 Wed, 26 Aug 2026 09:27:29 +0300 <p><em>Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки мультиоблачного искусственного интеллекта, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Диверсификация поставщиков облачных услуг для поддержки стратегии ИИ может принести свои плоды, но если CIO и CTO не сохранят контроль, они рискуют сделать данные неуправляемыми.</p> <p>По мере того, как рабочие нагрузки ИИ распространяются по все более разнообразной технологической экосистеме, конфиденциальные данные и операционный контекст перемещаются вместе с ними, отмечает Брайан Груттадауриа, CTO по гибридным облакам Hewlett Packard Enterprise. «Реальная цена разрастания поставщиков заключается не только в дополнительной сложности; это фрагментация данных, контекста, управления и контроля именно в тот момент, когда ИИ больше всего от них зависит», — говорит он.</p> <p>Диверсификация поставщиков в рамках мультиоблачной стратегии требует распределения рабочих нагрузок между несколькими облачными провайдерами. Она в основном используется для минимизации зависимости от поставщика, повышения отказоустойчивости и резервирования, а также оптимизации затрат и производительности. К сожалению, в сочетании с ИИ диверсификация поставщиков может внезапно превратиться в настоящий ад.</p> <h3>Признаки неправильной диагностики проблемы</h3> <p>Слишком многие организации рассматривают мультиоблачный ИИ как архитектурную проблему, тогда как на самом деле это организационная и финансовая проблема, считает Джесси Дин, CIO компании TDI Security, занимающейся управлением кибербезопасностью. «Из-за страха перед привязкой к поставщику и слабого управления компании разбрасывают данные и модели по нескольким облакам», — отмечает он. Это может привести к размыванию инженерного кадрового потенциала и увеличению долгосрочных затрат. ИТ-руководителям необходимо все тщательно продумать, чтобы устранить фундаментальные недостатки. «Приоритизация единой стратегии стандартизации данных и приверженность основной облачной среде для размещения данных являются ключом к снижению технической сложности и затрат», — полагает Дин.</p> <p>По словам Ха Хоанг, CIO компании Commvault, риск заключается не в том, что организации полагаются на несколько облаков, поскольку у многих из них есть веские причины для этого. «Риск заключается в том, что каждое облако превращается в собственную экосистему ИИ с различными моделями, конвейерами данных, политиками управления и инструментами для разработчиков», — предупреждает она.</p> <p>Как и многие ИТ-руководители, Хоанг считает, что ИИ принесет наибольшую пользу, когда сможет безопасно получать доступ к надежным корпоративным данным и работать согласованно в масштабе всего бизнеса. Если данные фрагментированы, а политики безопасности различаются в каждом облаке, организации могут получить разрозненных агентов, дублирование инвестиций и непоследовательные бизнес-результаты. «Мультиоблачная среда должна быть обдуманным архитектурным решением, а не случайным результатом независимого выбора технологий», — говорит она.</p> <p>Наиболее явным признаком чрезмерной диверсификации поставщиков является то, что данные и рабочие нагрузки больше не являются последовательно видимыми или управляемыми в разных средах, отмечает Груттадауриа. «Если ИТ-служба не может видеть и контролировать актив, независимо от того, где он находится — в облаке, локально или на периферии, — это признак того, что архитектура переросла возможности управления», — предупреждает он.</p> <h3>Поиск пути выхода из ловушки мультиоблачного ИИ</h3> <p>Ответ на вопрос о том, как избежать ловушки мультиоблачного ИИ, заключается в создании единой ткани данных, охватывающей облако, локальные системы и периферию, формируя единое операционное пространство имен вместо набора разрозненных хранилищ данных, считает Юрий Губин, технический директор компании DataArt, занимающейся разработкой ПО и ИТ-консалтингом. «Когда данные, рабочие нагрузки и ИИ используют общую основу, они остаются видимыми, управляемыми и переносимыми независимо от того, где они работают», — говорит он. Это позволяет организациям внедрять инновации от разных поставщиков, не беря на себя бремя мультивендорной сложности.</p> <p>Начните с управления, а не с технологий, советует Хоанг: «Определите небольшое количество утвержденных платформ ИИ, установите общие стандарты безопасности и идентификации и рассматривайте корпоративные данные как общий актив, а не как нечто, принадлежащее отдельным облакам или бизнес-подразделениям». ИТ-руководители также должны проектировать решения с учетом переносимости там, где это имеет смысл с точки зрения бизнеса. «Это не означает, что каждая рабочая нагрузка должна свободно перемещаться между облаками, но это означает избегание ненужной привязки по основным возможностям ИИ», — поясняет она. Это обеспечит гибкость, которая может создать конкурентное преимущество.</p> <h3>Не забывайте о бизнес-целях</h3> <p>Лучшая профилактика — это создание корпоративной операционной модели ИИ до того, как внедрение ИИ начнет масштабироваться, полагает Хоанг. «Каждая новая платформа ИИ должна соответствовать общим стандартам безопасности, доступа к данным, наблюдаемости, управления и контроля затрат», — говорит она. Также важно обеспечить, чтобы каждая инвестиция в ИИ была связана с измеримым бизнес-результатом. Цель состоит не в том, чтобы поддерживать каждую модель или каждого облачного провайдера; цель состоит в том, чтобы обеспечить бизнес-результаты с наименьшей операционной сложностью.</p> Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки … article https://www.itweek.ru/themes/detail.php?ID=235399 Wed, 26 Aug 2026 00:00:00 +0300 <p>ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если <a href="https://www.itweek.ru/themes/detail.php?ID=235254">система получает доступ к корпоративным данным</a>, выполняет действия и запускает процессы, ей действительно нужны права, ограничения и понятная зона ответственности. Так появляются ИИ-аналитики, ИИ-юристы, ИИ-рекрутеры, ИИ-разработчики.</p> <p>Проблемы возникают, когда саму <a href="https://www.itweek.ru/ai/article/detail.php?ID=235377">ИИ-систему</a> начинают выстраивать по принципам привычной оргструктуры. Такой подход понятен, потому что проще встроить нового исполнителя в уже сложившуюся модель работы, чем сразу пересматривать способ ее организации. Но по мере роста числа агентов становится заметно, что фиксированные цифровые роли подходят не для всех задач. И здесь возникает вопрос — а действительно ли ИИ нужна собственная «должность»?</p> <h3>Почему ролевая модель плохо масштабируется</h3> <p>Ролевая модель хорошо работает, пока задачи выполняют люди. У каждого сотрудника есть свой набор компетенций, полномочий и доступов, который формируется под конкретную функцию. Поэтому знания и ответственность естественно закрепляются за отдельными ролями.</p> <p>С ИИ эта логика работает иначе. Ему не обязательно задавать только одну специализацию и ограничивать круг задач. Где-то системе могут понадобиться договоры, юридические правила и история взаимодействия с клиентом, где-то — техническая документация, финансовые показатели и данные из нескольких корпоративных систем. Нужный контекст и инструменты можно подключать непосредственно под задачу.</p> <p>Когда эту возможность не учитывают, количество цифровых ролей начинает расти. Под отдельные функции создаются самостоятельные агенты, хотя на практике несколько из них могут работать с одними данными, обращаться к тем же системам и частично дублировать друг друга. Различаться при этом они будут инструкциями.</p> <p>В одном из наблюдаемых нами кейсов на первом этапе ИИ-трансформации компания создавала узкоспециализированных агентов под отдельные роли. По мере их роста стало заметно, что функции начинают пересекаться, а часть агентов фактически дублирует друг друга. Тогда в систему добавили мастер-агента, который анализировал существующую структуру, менял инструкции, перераспределял задачи и проектировал новые роли. После одного из аудитов он объединил дублирующиеся функции и существенно сократил количество агентов.</p> <p>Этот пример хорошо показывает ограничение ролевого подхода: отдельная специализация оправдана там, где действительно нужны свои полномочия, инструменты или правила работы. Но создавать постоянную цифровую «должность» под каждую новую функцию необязательно.</p> <h3>От должности — к задаче</h3> <p>Альтернативный подход — строить работу вокруг конкретной задачи. Под нее система получает нужный набор контекста: инструкции, данные, правила, корпоративные знания и инструменты. Для следующей задачи этот набор может быть другим.</p> <p>Меняется и вопрос, который задает бизнес. Не «какого цифрового сотрудника нам создать?», а «какой результат нужно получить и что потребуется системе для его достижения?».</p> <p>Такая логика меняет и работу с корпоративными знаниями. Если у каждого агента собственные инструкции и правила, по мере роста системы становится сложнее следить за их актуальностью и полнотой. Одно изменение может затронуть сразу несколько цифровых ролей. В едином контуре знания не закрепляются за конкретным агентом: нужные правила, инструкции, данные и инструменты подключаются в зависимости от задачи.</p> <p>Но корпоративный контекст — это не только регламенты и базы знаний. Такие документы описывают установленный порядок работы, тогда как на практике он может отличаться. Представим, что по регламенту счет на оплату должен пройти проверку, согласование и затем уйти в бухгалтерию. В реальности часть счетов возвращается из-за ошибок, для крупных сумм требуется дополнительное согласование, а некоторые документы проходят по другому маршруту.</p> <p>Различаться может и выполнение отдельных операций внутри одного процесса. Один сотрудник сразу сверяет данные в учетной системе, другой сначала ищет договор, затем проверяет карточку контрагента и только после этого возвращается к счету. Результат один, но последовательность действий и трудозатраты разные.</p> <p>Для ИИ эти нюансы особенно важны. Если фактический порядок работы отличается от формального описания, система рискует опираться на неполную модель процесса и автоматизировать сценарий, который не учитывает часть реальной работы. Поэтому такие расхождения нужно сначала выявить.</p> <p>Для этого используют аналитику бизнес-операций (Task Mining) и аналитику бизнес-процессов (Process Mining). Task Mining показывает, как сотрудники выполняют отдельные операции на компьютере: какие действия совершают и в какой последовательности работают с системами. Process Mining позволяет увидеть реальные маршруты процесса, задержки, возвраты и отклонения между этапами. Для ИИ эти данные могут стать важнейшим источником контекста наряду с классическими регламентами, правилами и корпоративными знаниями.</p> <h3>ИИ должен менять процесс</h3> <p>Когда понятно, как выполняется процесс на самом деле, возникает следующий вопрос — нужно ли автоматизировать его в существующем виде?</p> <p>Представим процесс, который проходит через пять подразделений. Один сотрудник анализирует обращение, второй проверяет документы, третий оценивает риски, четвертый готовит решение, пятый формирует ответ. Можно создать столько же ИИ-агентов и автоматизировать операции на каждом этапе.</p> <p>Работа ускорится, но сам процесс останется прежним. Между этапами сохранятся передачи, повторные проверки, согласования и ожидание. ИИ будет быстрее выполнять существующую схему вместе с действиями, которые могли появиться из-за прежнего распределения функций между людьми.</p> <p>Поэтому перед автоматизацией важно посмотреть на процесс целиком и определить, какие этапы действительно нужны для получения результата. Часть проверок можно объединить, часть передач убрать, а некоторые действия могут вообще потерять смысл. При наличии необходимых доступов и интеграций ИИ может сам собрать данные, провести стандартные проверки, подготовить результат и подключить человека там, где требуется экспертное решение или ответственность.</p> <p>В таком случае эффект дает не столько скорость выполнения отдельных операций, сколько изменение самого процесса. Сокращается количество передач, ручных действий и промежуточных этапов, которые раньше были необходимы из-за устройства работы.</p> <p>Именно здесь появляется потенциал для существенного роста производительности с учетом возможностей ИИ.</p> <h3>Управлять нужно результатом</h3> <p>Если работа строится вокруг задачи, количество агентов само по себе мало о чем говорит. Сто цифровых сотрудников не делают компанию автоматически эффективнее десяти. Иногда большое количество ролей означает лишь то, что существующую оргструктуру почти без изменений воспроизвели в ИИ-системе.</p> <p>Поэтому смотреть стоит на результат: сколько времени теперь занимает процесс, как изменилась стоимость выполнения задачи, какую часть операций система закрывает самостоятельно и где по-прежнему требуется участие человека.</p> <p>Сама оргструктура при этом остается. Она нужна, чтобы закреплять ответственность и полномочия между людьми. Но логика работы ИИ не обязана повторять эту схему: задача может проходить через систему без искусственного деления на цифровые должности и передаваться сотруднику только в тех точках, где его участие действительно необходимо.</p> <p>Для руководителя меняется и объект контроля. Важно понимать, как распределена работа между человеком и ИИ, по каким правилам действует система, где проходят границы ее самостоятельности и какой результат это дает бизнесу.</p> <p>#IMAGE_235400#</p> ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если система получает доступ … article Александр Бочкин, генеральный директор “Инфомаксимум” https://www.itweek.ru/themes/detail.php?ID=235404 Tue, 25 Aug 2026 18:45:56 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата проанализировал уровень использования цифровых технологий в крупных и средних организациях (без учета субъектов малого предпринимательства) в 2025 г.</p> <p>В 2025 г. цифровые технологии использовали порядка 84% крупных и средних организаций — больше, чем годом ранее.</p> <p>Базовым условием распространения цифровых технологий является доступ к интернету. Фиксированным подключением пользуются почти четыре из пяти организаций (78%), мобильным интернетом — почти две из пяти (39%).</p> <p>Информационно-коммуникационную инфраструктуру наряду с доступом к интернету характеризуют использование операционных систем с открытым исходным кодом (например, Linux) и наличие серверов. В 2025 г. такие операционные системы применяли 24% крупных и средних организаций, серверы имели 37%.</p> <p>Среди цифровых технологий наиболее востребованы цифровые платформы и облачные сервисы, за ними следуют геоинформационные системы. Каждая десятая из обследованных организаций внедрила RFID-технологии; чуть меньше — Интернет вещей и технологии сбора, обработки и анализа больших данных. Каждая двадцатая применяла технологии искусственного интеллекта для решения производственных задач. Промышленные роботы, аддитивные технологии и цифровые двойники в силу своей специфики распространены меньше — в <nobr>1–2%</nobr> крупных и средних организаций.</p> <p>Ключевым барьером для использования передовых цифровых технологий — решений для сбора, обработки и анализа больших данных, искусственного интеллекта и Интернета вещей — как и в предыдущие годы, остаются высокие затраты: их отмечает каждая вторая организация. Каждая третья указывает на отсутствие массивов данных и недостаточное развитие ИКТ-инфраструктуры; в среднем каждая четвертая — на нехватку средств для привлечения квалифицированных кадров, обладающих навыками работы с такими технологиями.</p> <p>Наряду с ресурсными ограничениями ряд организаций сообщили об отсутствии потребности в этих технологиях. Это свидетельствует о том, что темпы внедрения зависят не только от объема необходимых вложений, но и от готовности организаций пересматривать бизнес-процессы. Поэтому такие решения распространяются постепенно и прежде всего там, где дают измеримый эффект.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического … message https://www.itweek.ru/themes/detail.php?ID=235403 Tue, 25 Aug 2026 18:43:34 +0300 <p>Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если сравнивать их с зарубежными решениями того класса, с которыми российские разработчики сами сопоставляют свои LLM, российские модели по-прежнему могут стоить существенно дороже.</p> <p>Российские разработчики заметно снизили стоимость использования языковых моделей по сравнению с октябрем 2025 года.</p> <p>Наиболее сильное снижение произошло у GigaChat. Стоимость GigaChat Lite снизилась с 0,20 до 0,065 рубля за 1 тыс. токенов — на 67,5%. В линейке GigaChat Pro цена сократилась с 1,50 до 0,50 рубля — на 66,7%.</p> <p>В линейке Яндекса снижение было меньше. YandexGPT Pro стоила 1,20 рубля за 1 тыс. токенов, модель старшего поколения YandexGPT Pro 5.1 — 0,80 рубля, то есть на 33% меньше. Стоимость YandexGPT Lite не изменилась и составляет 0,20 рубля.</p> <p>В 2026 году российские разработчики также расширили линейки более доступными моделями. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за 1 тыс. генерируемых токенов. В коммерческой линейке GigaChat стоимость Lite-модели составляет 0,065 рубля за 1 тыс. токенов.</p> <p>Снижение цен можно объяснить тем, что российские разработчики постепенно сокращают прежнюю ценовую премию и приближают тарифы к мировому рынку. На это косвенно указывает стоимость доступа к одним и тем же зарубежным моделям через российские облачные платформы.</p> <p>Так, DeepSeek V4 Flash напрямую стоит 0,0375 рубля за 1 тыс. входных и 0,112 рубля за 1 тыс. генерируемых токенов. Через Yandex AI Studio — 0,30 и 0,50 рубля соответственно, то есть в 8 и 4,5 раза дороже.</p> <p>У Cloud.ru разрыв меньше: DeepSeek V4 Pro стоит напрямую 0,112 рубля за 1 тыс. входных и 0,337 рубля за выходные токены, через Cloud.ru — 0,183 и 0,732 рубля, или примерно в 1,6 и 2,2 раза дороже.</p> <p>Эти показатели не позволяют рассчитать реальную маржинальность провайдеров. Публичные тарифы не раскрывают себестоимость инфраструктуры, условия развертывания моделей и коммерческие расходы. Однако они показывают, насколько различается ценовая премия за доступ к одной и той же модели через разных поставщиков инфраструктуры.</p> <p>Снижение тарифов само по себе не означает, что российские LLM стали самыми доступными. Для оценки их ценовой конкурентоспособности российские модели сравнили не с наиболее новыми и дорогими frontier-решениями, а с зарубежными моделями, которые сами разработчики выбирали в качестве ориентиров для своих релизов.</p> <p>При запуске YandexGPT 5.1 Pro Яндекс сравнивал ее с GPT-4.1. Сейчас YandexGPT 5.1 Pro стоит 0,80 рубля за 1 тыс. входных и генерируемых токенов, тогда как GPT-4.1 — около 0,17 рубля за входные и 0,68 рубля за генерируемые.</p> <p>В результате YandexGPT 5.1 Pro обходится примерно в 4,7 раза дороже GPT-4.1 по входным токенам и примерно на 17% дороже по выходным.</p> <p>Еще заметнее разница у 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 раза — по исходным токенам.</p> <p>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 рубля соответственно.</p> <p>То есть Alice AI LLM Flash примерно в 1,6 раза дороже по входным токенам, но почти в два раза дешевле по выходным. Это показывает, что конечная экономика зависит не только от модели, но и от структуры конкретной задачи — соотношения объема входного контекста и генерации.</p> <p>Сравнение актуальных тарифов показывает, что наиболее низкую цену на мировом рынке по-прежнему в значительной степени задают китайские модели.</p> <p>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 рубля.</p> <p>В этом же нижнем ценовом диапазоне находятся европейский Mistral Large 3 — 0,04 рубля за входные и 0,13 рубля за выходные токены, а также GPT-5.4 mini — около 0,064 и 0,383 рубля.</p> <p>Из российских решений ближе всего к нижней части диапазона находятся GigaChat Lite с ценой 0,065 рубля за 1 тыс. токенов и Alice AI LLM Flash с тарифами 0,10 рубля за вход и 0,20 рубля за выход.</p> <p>Старшие российские модели стоят заметно дороже: GigaChat Pro — 0,50 рубля за 1 тыс. токенов, GigaChat 2 Max — 0,65 рубля, YandexGPT Pro 5.1 — 0,80 рубля. Alice AI LLM стоит 0,50 рубля за входные и 1,20 рубля за выходные токены.</p> <p>Высокая стоимость больше не является обязательным признаком frontier-модели.</p> <p>В верхней части диапазона остаются Claude Fable 5 с ценой около 0,80 рубля за 1 тыс. входных и 4 рубля за генерируемые токены, а также GPT-5.6 Terra — около 0,34 и 1,53 рубля соответственно.</p> <p>Однако на рынке США появляются более дешевые альтернативы сопоставимого высокого класса. Один из показательных примеров Grok с заметно более низкой стоимостью, чем у ряда решений OpenAI и Anthropic.</p> <p>Ценовое давление на наиболее дорогие LLM идет уже не только со стороны китайских разработчиков. Конкуренция усиливается и внутри американского сегмента. Новые игроки предлагают сопоставимый уровень возможностей в сложных логических задачах, программировании и агентных сценариях при более низкой стоимости инференса.</p> Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если … message https://www.itweek.ru/themes/detail.php?ID=235398 Tue, 25 Aug 2026 10:15:42 +0300 <p>13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия, посвященная поиску баланса между сокращением затрат и поддержанием эффективности в крупных компаниях. Мероприятие прошло в седьмой раз подряд и было организовано системным интегратором и разработчиком ИТ‑решений DCLogic.</p> <p>В дискуссии также приняли участие ведущие эксперты ИТ‑рынка — представители ИТ‑вендоров и дистрибьюторов, а также руководители и специалисты крупного бизнеса, которые поделились практическими кейсами и отраслевыми наблюдениями. Модератором сессии выступил Сергей Козырь, генеральный директор Digital Advisers, который структурировал обсуждение и помог раскрыть ключевые аспекты темы.</p> <p>Эксперты обозначили конкретные инструменты, позволяющие enterprise‑компаниям оптимизировать ИТ‑расходы: переход на гибкие модели оплаты (включая подписочные сервисы), запуск пилотных проектов для быстрой проверки гипотез и масштабирования только доказавших эффективность решений. Особый акцент был сделан на измеримости ценности — внедрение технологий, теперь обосновывают через четкие метрики и экономический эффект, что помогает исключить нецелевые траты.</p> <p>Также выделили ключевые векторы применения ИИ в enterprise‑сегменте: компании делают ставку на интеграцию генеративного ИИ в существующие ИТ‑контуры для сокращения рутинных операций при сохранении безопасности данных, активно развивают внутренние компетенции по созданию ИИ‑агентов, чтобы снизить зависимость от дорогостоящих внешних разработок, и при этом также привязывают внедрение ИИ технологий к измеримым бизнес‑результатам.</p> <p>Важной частью дискуссии стали экспертные оценки. Сергей Козырь отметил: «С одной стороны, сегодня бизнес сталкивается с серьезными вызовами: у многих компаний наблюдается невыполнение планов. С другой — происходит сокращение бюджетов и доступных возможностей. При этом объем задач для ИТ‑подразделений не уменьшается, а зачастую даже растет — особенно в условиях оптимизации».</p> <p>Евгений Шелестюк, генеральный директор DCLogic, добавил: «За последние два месяца мы заметили резкий сдвиг в запросах клиентов. Если раньше компании стремились наращивать капитал и повышать стоимость бизнеса, то сейчас главный тренд — переход на подписочную модель, чтобы снизить единовременные затраты.</p> <p>Клиенты хотят платить меньше „в моменте“ и получать решения в формате сервиса: аренда серверов, доступ к облачным ресурсам, помесячная оплата — фактически это аналог рассрочки».</p> <p>Участники также выделили важность системного подхода: аудит ИТ‑инфраструктуры, прозрачное бюджетирование и дорожные карты позволяют выявлять избыточные процессы и выбирать оптимальные решения. Дополнительным рычагом экономии стало применение готовых интеграционных инструментов (коннекторов, типовых решений), сокращающих стоимость и сроки проектов. Отдельно эксперты рассмотрели эволюцию рисков — от классической ИБ к комплексному подходу, включающему и физическую защиту объектов, и корректную работу с данными.</p> <p>Представленные на дискуссии практики дают рынку готовые ориентиры: компании могут применять описанные механизмы для снижения издержек, ускорения окупаемости ИТ‑проектов и формирования устойчивой стратегии развития. Такой подход позволяет не просто сокращать бюджет, а перераспределять ресурсы на наиболее результативные направления, сохраняя конкурентоспособность в меняющихся условиях.</p> 13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия … message https://www.itweek.ru/themes/detail.php?ID=235396 Tue, 25 Aug 2026 09:20:24 +0300 <p><em>Угроза «SaaS-апокалипсиса» упускает из виду более широкую картину. Хотя большинство комментариев сосредоточены на снижении доходов от модели, основанной на использовании рабочих мест (прогнозируя, что агенты искусственного интеллекта положат конец лицензиям на ПО), это лишь один из девяти критически важных факторов, способствующих кардинальным изменениям, пишут в корпоративном блоге вице-президенты и главные аналитики </em><em>Forrester</em> <em>Крейг Ле Клер и Тед Шадлер.</em></p> <p>Будучи глобальной исследовательской компанией, оценивающей весь технологический ландшафт, Forrester создала AI Disruption Model — модель анализа влияния ИИ на основе данных. Эта модель, построенная на исследованиях Forrester и общедоступной информации, отсеивает лишнюю информацию, обеспечивая прозрачность рыночных изменений и всеобъемлющую основу для прогнозирования будущего.</p> <p>Forrester AI Disruption Model оценивает 17 категорий технологий и услуг, охватывающих более 200 рынков. Данная модель анализирует структурную динамику рынка по девяти ключевым факторам, включая взаимозаменяемость ИИ, трудоемкость, коммерческую модель, поддержку агентных рабочих нагрузок, затраты на переход и регуляторные барьеры. Главный вывод очевиден: влияние ИИ не будет распределено равномерно. В то время как некоторые рынки и поставщики сталкиваются с серьезными трудностями, другие готовы к историческому ускорению.</p> <p> #IMAGE_235397#</p> <p>Мы разделили рынки на четыре категории: подверженные дестабилизации (disrupted), нейтрально реагирующие (neutral), подверженные балансу факторов (contested) и обеспечивающие ускорение (accelerated):</p> <ul> <li> Рынки, подверженные дестабилизации — здесь ИИ воспроизводит свою основную ценность. Если ИИ может сделать что-то, что может сделать человек или существующий программный продукт, он это сделает. Поставщики и сервис-провайдеры в этой категории сталкиваются с ценовым давлением, сокращением рабочих мест и коммодитизацией своих основных возможностей или наборов функций. Наиболее серьезно дестабилизирующие факторы, связанные с ИИ, затрагивают трудоемкие сегменты, такие как внедрение технологий, разработка ПО на заказ, креативные услуги и корпоративное обучение. Эти рынки находятся под огромным давлением, поскольку ИИ берет на себя функции, ранее выполнявшиеся экспертами-людьми.</li> <li> Нейтрально реагирующие рынки — здесь ценность не является преимущественно информационной. Если поставщики и сервис-провайдеры предлагают физические возможности, ориентированные на регулируемые рынки или защищенные высокими затратами на смену поставщика, они менее подвержены влиянию перехода на ИИ. Эти факторы сдерживают прогресс ИИ и обеспечивают стабильность ценности.</li> <li> Рынки, подверженные балансу факторов — готовые к ускоренному развитию. Поставщики и сервис-провадеры на таких рынках видят баланс обеспечивающих нейтральное реагирование и ускорение факторов, позволяющий перейти к ускоренному развитию. Они не будут сидеть сложа руки и ждать, пока их вытеснят, а перенаправят инвестиционный капитал и НИОКР на поддержку агентных рабочих нагрузок, данных, доверия и суверенитета. Поставщики в этой категории могут позитивно внедрять ИИ в свои платформы, но сталкиваются с проблемами реализации, капитала и трудовых ресурсов.</li> <li> Рынки, обеспечивающие ускорение — здесь продают все, что требуется для работы с ИИ. Поставщики инфраструктуры, данных, моделей, интеграции или возможностей обеспечения доверия являются основой агентных рабочих процессов — и будущими опорами бизнеса, основанного на ИИ. Спрос на их предложения напрямую зависит от уровня внедрения ИИ: чем больше специализированных ИИ-агентов и целевых агентных систем развертывают предприятия, тем больше технологий продают эти поставщики.</li> </ul> <p>Задача для покупателей корпоративных технологий, поставщиков и сервисных компаний — понять, как ИИ меняет рынки. Независимо от того, являетесь ли вы покупателем, стремящимся оптимизировать свой технологический портфель, или поставщиком, защищающим свою долю рынка и будущее, Forrester AI Disruption Model предлагает схему, необходимую для понимания этого сдвига.</p> <p>Покупатели корпоративных технологий могут использовать эту модель с целью защиты инвестиций при закупках, изолируя устаревшие, обремененные долгами инструменты, чтобы направить инвестиции масштабируемым, готовым к использованию агентных систем поставщикам. Для поставщиков технологий и сервис-провайдеров модель предлагает действенную дорожную карту, позволяющую оценить риски, защитить основной доход и переориентироваться на долгосрочный рост, прежде чем устаревшие модели исчерпают себя.</p> Угроза «SaaS-апокалипсиса» упускает из виду более широкую картину. Хотя большинство комментариев сосредоточены … article https://www.itweek.ru/themes/detail.php?ID=235394 Tue, 25 Aug 2026 09:06:47 +0300 <p>Скорость работы за последний год выросла у всех, кто подключил к процессам ИИ-инструменты. Вместе со скоростью выросла и вероятность того, что ошибка уйдет в производство незамеченной: проверять результат стало некогда, а иногда некому.</p> <p>Рассмотрим, как бизнесу выстроить систему верификации и почему ответственность за решение остается на человеке при любой степени автоматизации.</p> <h3>60% компаний работают с нейросетями без регламента</h3> <p>Требование повышать эффективность сегодня стоит перед большинством компаний, и ИИ-инструменты выглядят самым доступным способом это требование выполнить. Там, где раньше задача занимала день, после подключения нейросети уходит несколько часов. Поэтому внедрение идет в десятки процессов одновременно, при этом, часто без предварительной перестройки процессов.</p> <p>Побочный эффект такого темпа уже заметен. Проверка результата занимает время, которое как раз и хотели сэкономить, поэтому часть шагов начинает выпадать: цифры не сверяются с источником, формулировки принимаются в том виде, в каком их выдала модель, спорные места дорабатываются реже. Углы срезаются постепенно и почти незаметно для самой команды.</p> <p>Безопаснее всего ускоряться там, где ошибка обходится сравнительно дешево. Такой подход сохраняет выигрыш в скорости и снимает основной риск, поэтому имеет смысл закрепить его как процедуру. Пока что такая процедура есть у меньшинства: около 60% организаций <a href="https://pohodu.media/tenevoj-ii-kak-bezopasno-rabotat-s-nejrosetjami-v-kompanii/">не имеют</a> формализованных правил работы с нейросетями, при том что 26% сотрудников используют их регулярно и еще 35% периодически. Сотрудник в такой ситуации сам решает, какой сервис выбрать, какие данные туда отправить и насколько тщательно нужно проверять ответ.</p> <p>Отсутствие правил само по себе не создает проблему, пока результат работы модели остается корректным. Но когда модель ошибается, а ошибка выглядит достоверно и уходит дальше по цепочке без проверки, бизнес сталкивается с серьезными рисками. Именно такие случаи сейчас доходят до публичных разбирательств и показывают, во что обходится компании непроверенный ответ.</p> <h3>Модель выдумывает ссылки, компания платит штраф</h3> <p>Ярче всего проблема ИИ-галлюцинаций проявилась в юридической сфере. Причина в том, что каждая ссылка в документе проверяется второй стороной и судом, поэтому выдуманная норма обнаруживается почти всегда. Модель выдает ее с точной формулировкой и номером дела, но при проверке выясняется, что документа не существует.</p> <p>В базе таких случаев к июлю 2026 года <a href="https://www.kommersant.ru/doc/8799829">накопилось</a> 1725 дел из 35 стран с 5169 некорректными ссылками. История дошла и до российских судов: весной 2026 года арбитражный суд <a href="https://ziam.moscow/publikatsii/sud-oshtrafoval-kompaniyu-za-ispolzovanie-ii-pri-podgotovke-kassatsionnoy-zhaloby/">оштрафовал</a> компанию на 50 тысяч рублей за ссылки на несуществующую судебную практику, квалифицировав это как обман суда.</p> <p>Принципиальная деталь этого решения касается любого бизнеса. Суд не выяснял, придумал ссылки человек или модель, поскольку ответственность за поданный документ несет тот, кто его подписал. Инструмент, с помощью которого документ готовился, на распределение ответственности не влияет.</p> <p>В работе с нейросетями важно помнить, что модель подстраивается под задачу пользователя и стремится дать ответ, который выглядит подходящим, поэтому недостающие детали достраиваются правдоподобно. Скорость развития моделей на эту особенность влияет слабо: случаи с выдуманными ссылками продолжают накапливаться быстрее, чем годом раньше. Проверка результата поэтому переходит из разряда желательных процедур в обязательные.</p> <h3>Ответственность нельзя разделить с инструментом</h3> <p>Подпись под решением всегда ставит человек, и это единственная точка, где ответственность фиксируется юридически. Вина при разборе распределяется между сотрудником, который принес решение, и руководителем, который его согласовал. Модель в этой схеме места не занимает ни при каком раскладе.</p> <p>По этой причине, если специалист согласовал решение, не разобравшись в предметной области, проблема лежит исключительно в его экспертизе. Ответственность за результат остается ровно там же, где была до появления нейросетей, поэтому требования к пониманию сути задачи растут вместе со скоростью ее выполнения.</p> <h3>Как посчитать цену ошибки в своей компании</h3> <p>Почти ни у одной компании сейчас нет понимания, во сколько ей обходится конкретная ошибка. Однако ее стоит посчитать в потраченных часах, деньгах, потерянных клиентах и репутационных издержках, чтобы оценивать риски трезво. Так, три дня неудачного эксперимента укладываются в допустимую потерю, поскольку компания теряет только время команды, а ошибка в клиентских данных, в расчете себестоимости или в юридическом документе стоит несопоставимо дороже.</p> <p>Шкала собирается из трех шагов. Сначала все процессы раскладываются по уровню критичности, от свободных экспериментов до задач, где ошибка стоит компании контракта. Затем на каждый уровень назначается лимит эксперимента в днях и деньгах, а для самых критичных задач вводится обязательная проверка вторым человеком. Отдельным списком фиксируются задачи, результат которых вообще не принимается без ревью.</p> <p>Такая шкала позволяет компании ускоряться с пониманием всей ответственности. Там, где ошибка обходится дешево, команда может работать на полной скорости и учиться на неудачных попытках. Там, где ошибка стоит дорого, часть скорости сознательно отдается за контроль, причем решение об этом принимается заранее и не зависит от загрузки конкретного дня.</p> <h3>К работе руководителя добавилась проверка результата</h3> <p>Раньше от руководителя требовались экспертиза и накопленный опыт. Теперь к ним добавилась обязательная верификация того, что принес сотрудник вместе с инструментом. Задача эта постоянная, поскольку объем проходящих через руководителя решений вырос вместе с общей скоростью работы.</p> <p>Чтобы проверять, руководитель обязан понимать принцип работы модели и знать конкретные места, где она может допустить ошибку: выдуманные ссылки и цитаты, подгонка ответа под ожидание, потеря контекста в длинных задачах. Рядовому сотруднику допустимо этого не знать, но руководителю такой пробел непозволителен, поскольку именно он ставит подпись.</p> <p>По уровням это разворачивается в понятную схему. Линейный менеджер отвечает за верификацию на своем участке, руководитель департамента — за корректность процессов внутри направления, топ-менеджмент определяет зоны, где риск неприемлем, на уровне всей компании.</p> <h3>С чего начать внедрение нейросетей в бизнес-процессы</h3> <p>Все перечисленное сводится к нескольким процедурам, которые компания способна завести своими силами за месяц. Порядок здесь имеет значение: сначала описывается организационная часть процессов, потому что без нее непонятно, что и с какой тщательностью проверять, и затем детализируется техническая.</p> <p><strong>Организационная часть:</strong></p> <ul> <li> Разложить процессы по уровню критичности и зафиксировать, во сколько компании обходится ошибка на каждом из них.</li> <li> Назначить ответственного за проверку на каждом уровне, от линейного руководителя до топ-менеджмента.</li> <li> Ввести правило обязательной проверки фактов, цифр и ссылок в документах, которые уходят за пределы компании.</li> <li> Установить лимит эксперимента в днях и деньгах для задач с низкой критичностью.</li> <li> Составить список задач, результат которых не принимается без проверки человеком.</li> </ul> <p><strong>Техническая часть:</strong></p> <ul> <li> Собрать базу скиллов, тулов и плагинов с правилами работы ИИ-агента для разных этапов процесса. Каждый этап работы получает свой набор инструкций, который определяет, на какие данные агент опирается, какой результат считается корректным и какие действия недопустимы.</li> <li> Настроить процесс ревью, при котором решения, выданные агентом, проверяет другой агент.</li> <li> Запустить рефлексию по итогам ревью: агент разбирает собственные ошибки и определяет, на каком шаге и почему инструкция сработала неверно.</li> <li> Скорректировать работу агента по результатам ревью, чтобы та же ошибка не воспроизводилась на следующих задачах.</li> </ul> <p>Разумеется, скорость работы остается конкурентным преимуществом, и компании, которые откажутся от нее из осторожности, проиграют тем, кто научился работать быстро. Смысл шкалы критичности в том, что она показывает, где можно двигаться на полной скорости без оглядки и где стоит потратить лишний час на проверку. Без такой разметки команда либо тормозит везде одинаково, либо везде одинаково рискует.</p> <p>Технология при этом развивается быстрее, чем компании успевают выстраивать вокруг нее процессы. Верификация становится постоянной частью работы руководителя, благодаря которой ускорение всех процессов возможно. Компании, которые отстраивают эти процессы, получают возможность внедрять новые инструменты без пауз и рисков, которые несут незамеченные ошибки.</p> <p>#IMAGE_235395#</p> Скорость работы за последний год выросла у всех, кто подключил к процессам ИИ-инструменты. Вместе … article Олег Строкатый, руководитель направления контроля качества ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=235393 Mon, 24 Aug 2026 17:07:41 +0300 <p>По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО среди значимых облачных инцидентов выросла на 15 процентных пунктов — с 10% до 25%. За полгода доля выросла в 2,5 раза, при этом абсолютное число значимых инцидентов, связанных с цепочками поставок, более чем удвоилось.</p> <p>Рост связан с тем, что современная разработка опирается на большое число внешних компонентов и автоматизированных процессов, которым компания вынуждена доверять. Даже относительно небольшой корпоративный продукт зависит от внешних библиотек, пакетов, расширений среды разработки, систем сборки и репозиториев. Каждый такой компонент связан с учетными записями сопровождающих, токенами доступа и автоматизированными процессами публикации. Компрометация одного аккаунта сопровождающего, токена публикации или элемента CI/CD может дать злоумышленнику штатный канал доставки вредоносного кода в корпоративную сборку. Вредоносный пакет устанавливается штатным менеджером зависимостей, измененный компонент попадает в сборку, а похищенный токен используется в легитимном CI/CD-процессе. Для средств сетевого контроля установка пакета, обращение CI/CD к репозиторию или публикация артефакта часто выглядят как обычная работа команды разработки.</p> <p>В первой половине 2026 года подобные кампании затрагивали сразу несколько экосистем, включая npm, PyPI, Composer, расширения Visual Studio Code, плагины Jenkins и AUR. В одном из эпизодов компрометация единственной учетной записи разработчика позволила внедрить вредоносные изменения более чем в 140 пакетов. В других случаях атакующие получали контроль над аккаунтами сопровождающих и публиковали измененные версии сразу сотен компонентов. Масштаб такой операции зависит от числа организаций, которые автоматически получают обновления скомпрометированного проекта через привычный процесс установки зависимостей.</p> <p>Отдельную роль играет кража секретов разработчиков. Вредоносный пакет может использоваться как средство первоначального доступа, после чего атакующие извлекают персональные токены GitHub, ключи облачных платформ, учетные данные реестров пакетов или переменные окружения из систем сборки. Эти данные могут открыть доступ к следующему уровню инфраструктуры: приватным репозиториям, облачным ресурсам, контейнерным реестрам или системам сборки. В исследованных кампаниях украденные токены применялись повторно через несколько недель после первоначальной компрометации, причем часть такой активности, по оценкам исследователей, могла относиться уже к другим группам. В одном из эпизодов злоумышленники заявляли о доступе примерно к четырем тысячам частных репозиториев. Такой сценарий требует не только удалить вредоносный пакет, но и отозвать или заменить учетные данные, которые могли быть похищены во время его выполнения.</p> <p>Структура атак через цепочки поставок в 2026 году складывается из нескольких связанных сценариев. Первый строится вокруг компрометации открытого пакета или аккаунта его сопровождающего. Второй затрагивает CI/CD и позволяет менять сборки, кэши либо workflow без прямого доступа к конечному приложению. Еще один распространенный путь проходит через учетные данные разработчиков, когда первоначальное заражение используется для перехода в облачную инфраструктуру или внутренние репозитории. Отдельно развиваются атаки через плагины и расширения инструментов разработки. Такие инструменты особенно ценны для злоумышленника, если они имеют доступ к секретам, сборке или корпоративным сервисам. Расширение IDE работает внутри среды, где разработчик уже авторизован в корпоративных сервисах, а Jenkins-плагин или компонент сборочного конвейера может взаимодействовать с инфраструктурой от имени сервисной учетной записи.</p> <p>В результате граница между компрометацией поставщика и атакой на конечную компанию становится менее очевидной. Организация может не иметь уязвимого публичного сервиса и при этом получить вредоносный код через обновление зависимости. Другой сценарий начинается за пределами ее инфраструктуры, когда атакующий похищает токен сотрудника у разработчика стороннего продукта, а затем использует этот доступ уже против облачных ресурсов клиента. Для бизнеса последствия такого проникновения выходят за рамки заражения отдельной рабочей станции. При наличии широких прав у сервисных аккаунтов атакующий получает возможность читать секреты, менять содержимое репозиториев, воздействовать на процессы сборки и переходить к другим облачным проектам.</p> <p>При оценке отраслевого распределения инцидентов, связанных с цепочками поставок, наиболее высокая доля приходится на технологические компании и разработчиков ПО — около 34% случаев. Финансовый сектор формирует еще 21%, интернет-ритейл и другие цифровые торговые площадки — 16%, промышленность — 14%, компании из сферы профессиональных и корпоративных услуг — около 9%. На остальные отрасли приходится порядка 6%. Такая структура связана прежде всего с интенсивностью использования сторонних компонентов. У технологических компаний больше открытых зависимостей, репозиториев и автоматизированных сборочных процессов, финансовые организации активно используют внешние программные продукты и интеграции, а в ритейле и промышленности риск дополнительно расширяют многочисленные подрядчики, облачные сервисы и специализированное ПО. В этих условиях компрометация одного поставщика может затронуть сразу несколько организаций, которые используют общий пакет, плагин или компонент сборочной инфраструктуры.</p> <p>Риск усиливается, когда управление зависимостями отделено от управления доступом и секретами. Команда может проверять уязвимости библиотек, но не отслеживать, кому разрешена их публикация и какие права имеет CI/CD после установки нового компонента. В другой организации защищен репозиторий исходного кода, однако сервисный токен сборочной системы имеет административные полномочия в облаке. Именно через такие связи атака выходит за пределы исходной точки: один похищенный секрет может дать доступ к следующему сервису, а затем — к другим учетным данным и системам. Один похищенный секрет превращается в доступ к следующему сервису, а оттуда к другим учетным данным и системам.</p> <p>Для снижения риска компаниям следует контролировать всю цепочку доверия от исходного кода и зависимостей до CI/CD и развертывания в продуктивной среде. Новые зависимости имеет смысл проверять до включения в сборку, а недавно опубликованные версии не устанавливать автоматически без дополнительной верификации. Для критичных проектов оправдан период задержки перед использованием новой версии пакета, поскольку часть вредоносных публикаций удаляется вскоре после обнаружения. Доступ CI/CD следует ограничивать минимально необходимыми действиями, долгоживущие токены заменять короткоживущими учетными данными, а секреты разработчиков регулярно проверять на утечки и аномальное применение. Отдельного контроля требуют изменения владельцев пакетов, публикация новых версий, отключение защиты веток и действия сервисных аккаунтов за пределами обычного профиля.</p> <p>Практический приоритет — ограничить последствия компрометации одного элемента цепочки. Организация должна исходить из того, что популярная зависимость, аккаунт сопровождающего или токен разработчика могут быть скомпрометированы, и заранее ограничивать их возможности. Чем меньше полномочий получает такой компонент после попадания внутрь процесса разработки, тем ниже вероятность того, что одна вредоносная публикация даст атакующему доступ сразу к репозиториям, облачным ресурсам и корпоративным данным.</p> По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО … message https://www.itweek.ru/themes/detail.php?ID=235392 Mon, 24 Aug 2026 17:02:39 +0300 <p>Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для корпоративной инфраструктуры. Ключевыми направлениями развития релиза стали разграничения прав доступа администраторов, совместимость со SpaceVM 7, а также совершенствование инструментов администрирования, поддержки многоуровневой PKI и сценариев управления <nobr>VDI-средой.</nobr></p> <p>В состав релиза вошли 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.</p> <p>В Space VDI 6.2.0 реализована балансировка пользовательских подключений в мультишлюзе Space Gateway. Решение позволяет объединить несколько шлюзов в единый контур удалённого доступа и распределять нагрузку между ними при подключении пользователей.</p> <p>Мультишлюз Space Gateway предназначен для инфраструктур с большим числом удалённых пользователей. Балансировка подключений между шлюзами помогает масштабировать контур удалённого доступа и эффективнее использовать вычислительные и сетевые ресурсы.</p> <p>Space Dispatcher — управляющий компонент платформы получил существенное развитие в новом релизе Space VDI. В версии 6.2.0 реализована поддержка многоуровневой инфраструктуры открытых ключей, а инструменты работы с сертификатами получили дальнейшее развитие в интерфейсе и административных сценариях платформы. Это расширяет возможности интеграции Space VDI с корпоративной PKI и делает управление сертификатами более удобным в рамках единого контура администрирования.</p> <p>В новой версии также добавлены инструменты для разграничения прав доступа администраторов для управления на уровне пулов с помощью пользовательской роли «Модератор», развиты механизмы обновления компонентов, расширены административные сценарии и усовершенствована работа со службами каталогов, событиями и параметрами безопасности. В совокупности эти изменения повышают гибкость управления средой виртуальных рабочих мест и делают эксплуатацию платформы более предсказуемой в инфраструктурах с высокими требованиями к надёжности и управляемости.</p> <p>Отдельное внимание в релизе уделено развитию сценариев предоставления корпоративных приложений. В документации Space VDI появился новый раздел с рекомендациями по работе с пулами приложений, которые позволяют предоставлять пользователям доступ к отдельным приложениям без развёртывания полноценного виртуального рабочего стола. Такой подход помогает точнее настраивать пользовательские сценарии и более гибко организовывать доступ к прикладным системам.</p> <p>«Space VDI изначально создавалась как отечественная платформа с собственной технологической базой и глубокой интеграцией компонентов экосистемы Space. Такой подход позволяет нам обеспечивать предсказуемое развитие продукта, стабильную совместимость между компонентами и долгосрочную поддержку заказчиков в проектах импортозамещения. Мы видим высокий спрос на VDI со стороны коммерческих компаний и государственных организаций, поэтому продолжаем последовательно развивать инструменты администрирования и безопасности платформы. Новые возможности Space VDI 6.2.0 помогают заказчикам проще масштабировать инфраструктуру виртуальных рабочих мест, сохраняя высокий уровень управляемости среды и удобство её эксплуатации», — отметил Руслан Белов, директор по продукту Space VDI компании «ДАКОМ М». </p> <p>Для заказчиков в открытой документации продукта подготовлены рекомендации по обновлению и миграции компонентов Space Dispatcher с учетом особенностей используемой инфраструктуры. При переходе на Space VDI 6.2.0 необходимо соблюдать матрицу совместимости компонентов экосистемы Space и выполнять обновление в рекомендованной последовательности.</p> Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для … message https://www.itweek.ru/themes/detail.php?ID=235391 Mon, 24 Aug 2026 16:53:15 +0300 <p>Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет искать ответы в корпоративных документах, а также выполнять аналитические задачи. Платформа рассчитана в первую очередь на крупные и средние компании с повышенными требованиями к информационной безопасности и суверенитету данных.</p> <p>В крупных компаниях информация, необходимая для принятия решений, как правило распределена между разными источниками. Документы и регламенты хранятся в корпоративных порталах и СЭД, данные о клиентах — в CRM, финансовые показатели — в учетных системах, а часть информации остается в файлах и у отдельных экспертов. </p> <p>Чтобы получить аргументированный ответ на вопрос, сотрудникам приходится тратить время на длительный поиск, переключаться между системами, вручную сводить данные из разных систем. NaviCortex объединяет корпоративные источники в единое рабочее пространство и позволяет взаимодействовать с ними в едином интерфейсе.</p> <p>В отличие от классических систем интеллектуального поиска, которые работают по схеме «запрос — поиск по документам — ответ», новое решение «Навикон» построено на агентной архитектуре. Получив задачу, ИИ-агент самостоятельно разбивает ее на этапы, определяет необходимые источники, обращается к корпоративным системам, выполняет расчеты и проверяет результат. При сложных запросах отдельные части задачи могут передаваться специализированным агентам, а дополнительная проверка позволяет сверять числа, периоды и другие необходимые данные. </p> <p>Например, на вопрос о текущей задолженности клиента и возможности продолжать отгрузки платформа может одновременно получить сумму задолженности из ERP, проверить финансовую политику компании в базе знаний и уточнить статус клиента в CRM. В результате пользователь получает единый ответ, а не набор ссылок на три разные системы. По тому же принципу платформа сопоставляет показатели из разрозненных источников, готовит аналитические справки, проверяет требования регламентов или собирает информацию для управленческой отчетности.</p> <p>Платформа не только находит информацию и отвечает на вопросы, но и выполняет работу по запросу пользователя. Агент пишет и запускает код в изолированной песочнице, рассчитывает показатели, строит таблицы и графики — а результат формирует в виде готового документа, таблицы или презентации. Для загрузки собственных файлов и дальнейшей работы с ними пользователям доступно персональное защищенное пространство.</p> <p>NaviCortex можно интегрировать с ERP, CRM, WMS, СЭД, корпоративными порталами, базами данных и другими системами через API. Заказчики, в свою очередь, могут специализированных агентов для отдельных сотрудников, подразделений и сценариев без переработки всей системы.</p> <p>Отдельное внимание разрабочик уделил вопросам корпоративной безопасности. Платформа учитывает права конкретного пользователя при обращении к документам и информационным системам, контролирует входящие запросы и ответы, фиксирует действия в журнале аудита и изолирует пользовательские песочницы. Решение может быть развернуто внутри закрытого контура компании, работать по гибридной модели или размещаться в облаке российского провайдера. При локальном развертывании данные и генерацию ответов можно оставить в инфраструктуре заказчика.</p> <p>«Сейчас корпоративный ИИ часто сводится к чат-боту, который умеет искать информацию в базе документов. Но реальные вопросы бизнеса устроены сложнее: для ответа нужно взять данные из нескольких систем, сопоставить их с внутренними правилами, что-то рассчитать, проверить результат, а иногда — сразу подготовить документ. Именно под такие задачи мы создавали NaviCortex. Наша цель — дать сотруднику ИИ-инструмент, который понимает контекст бизнеса компании и способен самостоятельно пройти путь от вопроса до готового результата», — прокомментировал Илья Народицкий, директор по стратегическим инновациям компании «Навикон».</p> <p>Продукт оптимизирован для работы на русском языке и поддерживает модели с открытым исходным кодом, которые можно размещать в инфраструктуре заказчика. Клиент получает доступ к исходному коду платформы и может развивать и кастомизировать решение самостоятельно или с поддержкой «Навикон». </p> <p>Платформа подойдет компаниям с большим объемом внутренней информации и разветвленным ИТ-ландшафтом. В частности, организациям из регулируемых сфер — финсектора, фармацевтики, пищевой промышленности и ритейла.</p> Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет … message https://www.itweek.ru/themes/detail.php?ID=235390 Mon, 24 Aug 2026 09:48:45 +0300 <p><em>Инструменты кодирования с использованием искусственного интеллекта ускоряют работу отдельных специалистов, но большие запросы на слияние (pull requests, </em><em>PR</em><em>), слабые методы измерения и устаревшие процессы сдерживают производительность и уверенность инженеров, отмечают опрошенные порталом </em><em>The</em> <em>New</em> <em>Stack</em> <em>эксперты.</em></p> <p>ИИ отлично справляется с тем, чтобы ускорить работу отдельных людей, но окружающие системы затем снова всё замедляют. Этот результат — или, скорее, его отсутствие — усиливается размером компании и размером PR. До такой степени, что, хотя инвестиции в ИИ в большинстве компаний увеличились в 28 раз, показатели скорости разработки остаются на прежнем уровне и даже снижаются. Таковы результаты недавно опубликованного исследования DX «State of AI Impact in Engineering», в котором оцениваются инженерные организации по таким параметрам, как скорость, эффективность, качество и влияние.</p> <p>«Это вызывает беспокойство, потому что, когда затраты выросли в 28 раз — и стали буквально единственным экспоненциально выросшим показателем — а скорость не растет экспоненциально, мы не выпускаем экспоненциально больше ПО», — сетует Джастин Реок, заместитель технического директора DX.</p> <p>В то время как расходы на ИИ продолжают стремительно расти, коэффициент инноваций — соотношение усилий инженеров, затрачиваемых на разработку новых функций, с затратами на техническое обслуживание, рутинную работу и операционные издержки — остается неизменным. Это означает, что, согласно отчету DX, ИИ не освобождает время инженеров для разработки интересных бизнес-решений.</p> <p>Почему же индустрия тратит так много денег на агентные и ​​ИИ-инструменты для разработчиков, одновременно проводя сокращения штата, и все это безрезультатно?</p> <h3>Имеет ли место тенденция к ухудшению опыта разработчиков?</h3> <p>«Возможно, мы все еще находимся в переломном моменте, когда большая часть сэкономленного времени по-прежнему тратится на технический долг, на задачи из бэклога, которые не обязательно помечены как новые функции», — говорит Реок, который все еще надеется, что разрыв между затратами и выгодами от ИИ — это всего лишь проблемы роста. «Но с точки зрения опыта разработчиков меня также беспокоит выявленное в отчете конкретное противоречие между поддерживаемостью кода и уверенностью в изменениях», — добавляет он.</p> <p>Эти два фактора составляют основу индекса опыта разработчиков (Developer Experience Index, DXI):</p> <ul> <li><strong> Поддерживаемость кода:</strong> я чувствую себя комфортно, внося изменения в код; я понимаю код, который передо мной.</li> <li><strong> Уверенность в изменениях:</strong> я уверен, что, выпустив код в продакшн, я ничего не сломаю.</li> </ul> <p>Традиционно, как объясняет Реок, поддерживаемость кода и уверенность в изменениях положительно коррелируют, поскольку первая делает инженеров более уверенными в выпуске кода в продакшн. «ИИ упрощает понимание того, что перед вами, и даже внесение в это изменений. Но уверенность в изменениях сейчас находится в отрицательной зоне, — говорит он. — Мы стали больше бояться выпускать код. Мы можем легче понимать, поддерживать, просматривать код и вносить в него изменения. Но мы меньше доверяем тому, что выпускаем».</p> <p>Это обходится еще дороже. По словам Реока, за каждый пункт улучшения DXI приходится платить десятью часами работы каждого инженера в год. Это впервые, когда в масштабах всей отрасли наблюдается снижение этого показателя на два пункта.</p> <h3>Является ли ИИ неподходящим инструментом для крупных организаций?</h3> <p>Как показывает исследование DX, небольшие организации тратят больше средств на ИИ и получают от него больше пользы, в то время как традиционные софтверные компании с трудом получают какую-либо отдачу от инвестиций.</p> <p>Мартин Дэвидсон, технический директор микроконсалтинговой компании a2bic.ai, и его соучредитель, обладающие в общей сложности <nobr>80-летним</nobr> опытом, доводят ситуацию до крайности: они могут управлять командами ИИ-агентов, выполняющих работу 100 инженеров начального и среднего уровня. «Небольшим организациям не приходится платить издержки нелинейной координации и коммуникации, которые увеличиваются с ростом размера организации. Вспомните мифический человеко-месяц: каналы связи растут как n(n−1)/2, поэтому у команды из 10 человек 45 каналов накладных расходов, — объясняет Дэвидсон. — Трое из этих людей фактически нужны только для согласования действий. Но как только остаётся один или два человека, затраты на коммуникации исчезают. По мере сокращения среднего звена управления отпадает необходимость в ежемесячных общих собраниях на всех уровнях организации».</p> <p>По его словам, в средних и крупных организациях пытаются внедрить — или «впихнуть» — ИИ в существующие системы, охватывающие людей, процессы и технологии. Но ИИ — это фундаментальный технологический и операционный сдвиг парадигмы. Это то, что он называет проблемой обновления, когда некоторые из этих структур больше не соответствуют своему назначению.</p> <p>«Это нельзя переделать. У нас есть процессы и структуры, которые были разработаны, когда написание кода было дорогостоящим делом. Сейчас это уже не так — написание кода по сути бесплатно, но мы всё ещё цепляемся за старые структуры. А они недешевы, — продолжает Дэвидсон. — Структуры компании похожи на здания — в какой-то момент вы понимаете, что они больше не соответствуют своему назначению, и их нужно снести и выстроить заново».</p> <p>Конечно, это не новая проблема. Это та же самая логика, которая удерживала подавляющее большинство предприятий от полного перехода в облако.</p> <p>«Возможно, победителями станут не те компании, которые успешно трансформируются. Возможно, победителями станут те, кто начнет все с чистого листа, без каких-либо ограничений. Это трудно сделать, если вы работаете в устаревшей организации. И, вероятно, еще более трудно, если вы ею управляете», — отмечает Дэвисон.</p> <p>К счастью, ИИ очень хорошо распознает закономерности, что делает его очень полезным для разгадывания тайн унаследованных систем, их миграции в облако и переписывания.</p> <h3>ИИ усугубляет разрастание кода</h3> <p>Конечно, многие команды и их промпты игнорируют общепринятые шаблоны достижения успеха, в том числе тот факт, что уменьшение размера пакета способствует более стабильным релизам. В отчете DX говорится, что в июле 2025 г. средний размер PR составлял 42 строки кода, а годом позже — 72 строки.</p> <p>Кроме того, из всех показателей DXI, измеренных за последний квартал, больше всего пострадал показатель поэтапной разработки — когда инженеры работают над небольшими, поэтапными изменениями. «Такая разработка дает множество преимуществ в дальнейшем: откат изменений, меньше проверок, более понятная документация, улучшенные модульные тесты и так далее», — отмечает Реок.</p> <p>Не только DX выявляет эти тревожные тенденции. В новом отчете LinearB о разрыве в производительности ИИ-разработки 253 организации ранжированы по использованию ИИ на четыре категории. Исследование показывает, что меньший размер PR напрямую связан с более успешным внедрением ИИ. У «элитных организаций», входящих в 10% лучших, средний размер PR — менее 100 строк кода, в то время как у организаций из нижней части списка — им «недостает фокуса» — PR составляют более 228 строк кода.</p> <h3>Можно ли улучшить то, что не измеряется?</h3> <p>Исследования DX и LinearB по измерению количественного и качественного опыта разработчиков основаны на собственных данных, полученных от организаций, использующих их продукты, поэтому ни один из этих результатов не отражает полной картины. На самом деле, ситуация в остальной части отрасли может быть гораздо хуже.</p> <p>Согласно отчету LeadDev «AI Impact Report 2026», только 31% опрошенных команд вообще измеряют влияние ИИ. Исследователи определили эти измерения следующим образом:</p> <ul> <li> реальное повышение производительности;</li> <li> риск безопасности;</li> <li> сохранение основных инженерных навыков;</li> <li> управление агентным ИИ;</li> <li> реструктуризация команды;</li> <li> наем и обучение младших специалистов.</li> </ul> <p>Среди организаций, которые фактически начали внедрять инструменты для разработчиков на основе ИИ, согласно отчету LeadDev, 70% теперь описывают себя как внедрившие их «широко или полностью», и только 26% сообщают, что ИИ повысил производительность инженеров более чем на 25%. Эти 26%, как уточняет Майкл Хилл, управляющий редактор LeadDev и автор отчета, включают в себя респондентов, полагающихся на интуицию, а не только на подтвержденные данные.</p> <p>«Оптимизм в отношении производительности (26% отмечают значительный рост) и разрыв в измерениях (только 31% фактически отслеживает его) — это два отдельных результата, полученные на основе ответов на два разных вопроса», — отмечает он, а это значит, что «большинство людей, сообщающих о росте, не могут это доказать».</p> <p>Как известно, нельзя улучшить то, что не измеряешь. Но даже у тех, кто проводит измерения, результаты вызывают беспокойство.</p> Инструменты кодирования с использованием искусственного интеллекта ускоряют работу отдельных специалистов, но большие … article https://www.itweek.ru/themes/detail.php?ID=235389 Mon, 24 Aug 2026 09:25:14 +0300 <p><em>В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как улучшить результаты и снизить затраты на ИИ-инициативы, одновременно защитив корпоративный бренд? В конце концов, высшее руководство все чаще называет внедрение ИИ основным поводом для сокращения штата на 20% и более. Советы директоров и инвесторы компаний оказывают сильное давление на исполнительных руководителей, требуя показать финансовые и ощутимые выгоды от масштабных инвестиций в ИИ, которые обходятся крупным предприятиям более чем в 10 млн. долл. в год, пишет на портале </em><em>BigDataWire</em> <em>Кумар Гошвами, соучредитель и генеральный директор Komprise.</em></p> <p>В целом, пока сложно продемонстрировать окупаемость инвестиций в ИИ. Исследование MIT Research показало, что 95% пилотных проектов генеративного ИИ не приносят измеримой финансовой отдачи, а Gartner прогнозирует, что более 40% проектов агентного ИИ будут отменены к концу 2027 г.</p> <p>Хотя существует множество факторов, объясняющих низкую рентабельность инвестиций и высокий уровень неудач, качество данных является постоянным препятствием, на которое указывают аналитики. Индустрия ИИ до сих пор фокусировалась на уровне рассуждений, в то время как уровню подготовки данных уделялось сравнительно меньше внимания.</p> <p>Более того, подготовка данных часто обсуждается в терминах «последней мили»: разбить документы на фрагменты, сгенерировать вложения, загрузить векторную базу данных, построить конвейер поиска. Это предполагает, что к моменту попадания в конвейер данные чистые, классифицированные, управляемые и релевантные, но это в значительной степени не соответствует действительности. Исследования снова и снова показывают, что организации сталкиваются с проблемами, связанными с разрозненностью, управлением и общим качеством данных. Опрос Databricks показал, что только 37% руководителей считают свои приложения генеративного ИИ готовыми к внедрению в производство.</p> <p>Этот разрыв — проблема «первой мили» ИИ: поиск данных, их понимание, классификация и определение того, что вообще не должно попадать в модель.</p> <h3>Проблема неструктурированных данных для ИИ</h3> <p>Если вы спросите поставщика облачных услуг или платформы LLM, как использовать неструктурированные данные, они почти всегда начнут с того, что посоветуют вам загрузить файлы в хранилище S3 или в озеро-хранилище (lakehouse) данных. Однако этот подход быстро меняется, поскольку объем файловых и объектных данных неуклонно растет, а затраты и риски безопасности для ИИ увеличиваются.</p> <p>Неструктурированные данные, которые составляют от 80 до 90% новых корпоративных данных, растут примерно в три раза быстрее, чем структурированные данные, и теперь являются исходным материалом, необходимым для каждой корпоративной ИИ-инициативы. Тем не менее, большинство ИТ-команд по-прежнему не могут сказать вам, где все это хранится, каково его содержимое или как безопасно использовать это в ИИ.</p> <p>Проблема обработки больших объемов неструктурированных данных многогранна, она охватывает следующее:</p> <ul> <li> файловые хранилища NAS, накопленные за многие годы, и объектные хранилища, распределенные по облачным провайдерам;</li> <li> миллиарды разнообразных файлов: документы, отсканированные PDF-файлы, чертежи САПР, архивы электронной почты, мультимедийные файлы, данные приборов и многое другое;</li> <li> широко распространены дубликаты, «осиротевшие», тривиальные и «зомби», или «мертвые» данные, засоряющие хранилище и ухудшающие видимость;</li> <li> несогласованная структура папок и отсутствие структуры, контекста и богатых метаданных, что затрудняет обнаружение и организацию неструктурированных данных;</li> <li> большая часть этих данных трудно поддается запросам, поскольку они не хранятся в базе данных, разбросаны по разрозненным хранилищам и имеют мало идентифицирующих характеристик.</li> </ul> <h3>Объяснение проблемы «первой мили»</h3> <p>Для подготовки данных к использованию в ИИ необходимо выполнить несколько критически важных этапов предварительной обработки: индексирование в хранилищах разных производителей, обнаружение, очистка и удаление дубликатов, классификация путем обогащения и извлечения метаданных, обнаружение конфиденциальных данных и включение политик управления и безопасности в рабочие процессы обработки данных для ИИ.</p> <p>Эта проблема выявлена ​​в исследовании Komprise «2026 State of Unstructured Data Management», согласно которому классификацию и маркировку неструктурированных данных назвали своей главной проблемой при подготовке данных для ИИ 56% директоров по ИТ-инфраструктуре, по сравнению с 41% годом ранее. Управление и безопасность заняли второе место с 46%.</p> <p>Причина этой проблемы «первой мили» заключается в том, что ИИ эволюционировал от массовых потребительских чат-ботов до стратегических, крупномасштабных корпоративных инициатив с использованием корпоративных данных.</p> <ul> <li><strong>Миф об «песочнице» ИИ.</strong> До недавнего времени большинство корпоративных ИИ-проектов представляли собой изолированные эксперименты или небольшие проверки концепций. При обработке 500 корпоративных документов их можно вручную выбрать, загрузить в хранилище данных и запустить конвейер RAG. Однако с расширением применения ИИ на более крупные задачи это не масштабируется для рабочих нагрузок, которые могут включать 100 000 или более файлов, с неизвестным процентом файлов, не подходящих для данной задачи.</li> <li><strong>Миф о векторной фильтрации.</strong> Существует устойчивое предположение, что векторная база данных автоматически отфильтрует избыточный или устаревший контент. На практике, если у компании есть десяток версий одних и тех же устаревших документов, разбросанных по различным системам хранения, поиск пользователя выдаст несколько противоречащих друг другу версий в одном и том же запросе. ИИ-инженеры не учитывают, что подача огромного количества устаревших, избыточных или низкокачественных данных в модель ИИ приводит к сильным иллюзиям, медленному времени ответа на запросы и раздуванию счетов за токены.</li> <li><strong>Отсутствие инструментов управления на уровне файлов.</strong> Традиционные инструменты хранения данных были созданы для администраторов хранилищ и предназначены для резервного копирования, многоуровневого хранения и архивирования, а не для развертывания рабочих процессов обработки данных для специалистов в области науки о данных. Не хватает инструментов для безопасной и эффективной доставки чистых, организованных файлов из устаревших корпоративных файловых хранилищ в конвейеры обработки данных. В эти рабочие процессы необходимо интегрировать средства управления соответствием нормативным требованиям в отношении использования данных путем выявления конфиденциальных и регулируемых данных и принятия соответствующих мер при необходимости.</li> <li><strong>Экономика владения.</strong> Бизнес-приложения, такие как CRM, ERP и системы взаимодействия с клиентами, влияющие на выручку, имеют финансовую историю и поддержку руководства, поэтому они бюджетируются. Неструктурированные данные в основном находятся в другой бюджетной строке: ИТ-инфраструктура и системы хранения, центр затрат без влияния на доходы. Поиск дубликатов, устаревших или регулируемых файлов, по общему мнению, является более сложной инженерной задачей, но у нее нет бизнес-спонсора в отличие от новой функции CRM. Однако ИТ-команды сейчас понимают, что ИИ зависит от высококачественных, управляемых данных, а подготовка данных требует значительных бюджетных затрат.</li> </ul> <h3>Lakehouse не решает проблему</h3> <p>ИИ повысил важность озера-хранилища данных — архитектуры, сочетающей в себе недорогое хранение в озере данных с управлением уровня хранилища данных. Тем не менее, у lakehouse есть ограничения, когда речь идет о курировании неструктурированных данных для ИИ.</p> <p>Во-первых, lakehouse по-прежнему требует размещения необработанных данных где-то, прежде чем уровень управления сможет с ними работать. Большинство реализаций следуют поэтапной схеме, часто называемой «медальонной архитектурой», размещая необработанные данные в «бронзовом» слое, прежде чем они будут очищены и структурированы. Для строк, извлеченных из CRM, этот шаг обходится недорого. Для петабайтов файловых данных, распределенных по локальным NAS-серверам, нескольким облачным хранилищам и периферийным точкам, это не так, а большие объемы уже являются нормой.</p> <p>Во-вторых, инструменты, созданные для перемещения данных на платформы, такие как ETL и ELT, не были разработаны для больших наборов неструктурированных данных, распределенных по разрозненным хранилищам.</p> <p>Это обосновывает подход «нулевого перемещения»: индексировать и классифицировать данные там, где они хранятся, отфильтровывать избыточные, устаревшие, тривиальные (ROT) данные до их перемещения и перемещать только управляемое подмножество, необходимое для рабочей нагрузки. Lakehouse — прекрасное место назначения. Но требует предварительного решения о том, что там должно находиться.</p> <h3>Переход к нулевой фазе</h3> <p>Финансовые затраты на перемещение всего — это только половина проблемы. Другая половина проявляется в том, что производит система ИИ: ввод в модель низкокачественного или дублирующегося контента, как правило, приводит к заведомо неверному ответу. Существуют также затраты на управление. Контроль доступа на уровне файлов существует не просто так, и когда необработанные данные копируются целиком в новую среду, эти средства контроля не всегда переносятся вместе с ними.</p> <p>Разбивка на фрагменты, синтаксический анализ и векторные вложения по-прежнему необходимы, но они относятся к концу процесса. Нам нужен нулевой этап перед ними: найти, какие данные существуют и где, классифицировать их по содержимому и конфиденциальности, отфильтровать нерелевантные данные и обеспечить соблюдение правил управления и доступа до того, как какие-либо данные будут перемещены в модель или озеро-хранилище данных.</p> <p>Вот как развиваются рабочий процесс и набор инструментов для конвейеров обработки данных ИИ:</p> <ul> <li> инструменты обнаружения и классификации для поиска контента в разрозненных хранилищах;</li> <li> платформы управления неструктурированными данными для метаданных, политик и перемещения;</li> <li> уровни управления и контроля доступа для обеспечения безопасности и отслеживания происхождения данных;</li> <li> инструменты синтаксического анализа, оптического распознавания символов и обогащения для преобразования файлов в пригодный для использования контент;</li> <li> уровни поиска и векторного представления для обслуживания рабочей нагрузки ИИ.</li> </ul> <p>В дальнейшем ИТ- и дата-командам необходимо рассматривать индексирование, поиск и классификацию данных как инфраструктуру, а не как второстепенный аспект. Это позволит организациям эффективно отсеивать дубликаты файлов, неавторитетные и нерелевантные данные, одновременно учитывая специфические требования к данным, которые не подпадают под действие нормативных требований и правил безопасности.</p> <p>Предприятия, которые преодолеют барьер «первой мили», в конечном итоге будут передавать меньше данных в ИИ, экономя на токенах, хранении, вычислительных ресурсах и затратах на передачу данных, обеспечивая при этом доступность только необходимых для конкретного сценария использования данных.</p> <p>Предприятиям, которые хотят, чтобы ИИ работал в масштабе с достижимой окупаемостью инвестиций, в первую очередь необходимо ответить на вопрос: «Где хранятся наши неструктурированные данные, что в них содержится и как мы можем обеспечить их доставку с соблюдением принципов управления?», а не «Какую модель встраивания нам следует использовать?».</p> В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как … article https://www.itweek.ru/themes/detail.php?ID=235388 Fri, 21 Aug 2026 10:03:49 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата анализирует динамику и структуру затрат крупных и средних организаций (без учета субъектов малого предпринимательства) на внедрение и использование цифровых технологий в 2025 г.</p> <p>В 2025 г. организации направили на внедрение и использование цифровых технологий почти 5,9 трлн руб., что в текущих ценах на 11,8% выше показателя 2024 г.</p> <p>Основные статьи расходов — ПО (лицензии, SaaS, разработка, доработка, адаптация), на которое пришлось 37% анализируемых затрат, и ИКТ-оборудование (приобретение, аренда, обслуживание, модернизация, ремонт) с долей 27%.</p> <p>Расходы на ПО выросли на 13,7%, во многом за счет увеличения заказной разработки.</p> <p>Общий объем затрат на оборудование практически сохранился на уровне 2024 г. (-0,9%), при этом расходы на приобретение ИКТ-оборудования снизились (-10,2%), прежде всего в сегменте вычислительной техники, что объясняется как высокой базой 2024 г. (годом ранее отмечался рост затрат на четверть), так и сложностями с импортом, в том числе из-за возникшего в 2025 г. дефицита серверов и оперативной памяти на мировом рынке. Одновременно в 1,5 раза вырос объем затрат на аренду вычислительных мощностей (IaaS).</p> <p>Наиболее высокими темпами росли расходы на базы данных и цифровой контент: при доле всего 3,3% в структуре затрат за год они увеличились в 1,7 раза.</p> <p>Более половины анализируемых затрат приходится на сферу ИТ и связи (36%) и финансовый сектор (23,1%). В 2025 г. вложения выросли как в этих, так и в большинстве других отраслей— всего в 16 из 18. Расходы в госуправлении, здравоохранении, оптовой и розничной торговле увеличились на <nobr>20–22%,</nobr> в ИТ и связи, финансовом секторе, обрабатывающей промышленности, профессиональной и научно-технической деятельности, на транспорте — на <nobr>11–14%.</nobr></p> <p>Основную часть затрат на цифровые технологии организации покрыли за счет собственных средств (86,6%). Доля бюджетных составила 12,3%, заемных и прочих привлеченных средств — немногим более 1%.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического … message https://www.itweek.ru/themes/detail.php?ID=235387 Fri, 21 Aug 2026 09:09:39 +0300 <p>Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0. Обновление фокусируется на улучшении управляемости групповыми политиками, расширении поддержки отечественных операционных систем с мандатно-ролевым доступом и повышении отказоустойчивости распределённых инфраструктур.</p> <p>Одним из центральных улучшений стало отображение LDAP-структуры непосредственно в интерфейс управления групповыми политиками. Теперь администраторы видят полную иерархию организационных подразделений с привязанными и наследуемыми политиками в режиме реального времени. Это упрощает навигацию по каталогу и позволяет назначать групповые политики напрямую на нужное подразделение без дополнительных переходов между модулями. Всё это ускоряет работу администратора и снижает риск ошибок при настройке.</p> <p>В схему LDAP-каталога добавлены новые классы объектов и атрибуты, необходимые для работы с мандатно-ролевым доступом (МРД) в Astra Linux Special Edition (релизы «Смоленск» и «Воронеж»). Благодаря этому MULTIDIRECTORY теперь полностью совместима с требованиями по защите информации, предъявляемыми к системам в государственных и регулируемых отраслях. Обновление позволяет централизованно управлять учётными записями и политиками безопасности в инфраструктурах, где используются сертифицированные версии Astra Linux с МРД.</p> <p>Для распределённых и высоконагруженных инфраструктур реализована динамическая балансировка запросов между контроллерами домена в отказоустойчивой конфигурации. Система учитывает состояние healthcheck каждого контроллера и автоматически перенаправляет запросы на доступные узлы. Это позволяет разворачивать MULTIDIRECTORY в отказоустойчивом кластере, обеспечивая бесперебойную работу инфраструктуры даже при выходе отдельных компонентов из строя.</p> <p>В новой версии устранён ряд критических ошибок, влияющих на стабильность и совместимость системы. Исправлены BER-обёртка для LDAP Controls, логика определения namingContexts в rootDSE и обработка удаления атрибутов в Modify Request — теперь операция не чувствительна к регистру. Устранены ошибки в генерации файлов init.sls в результирующих политиках, очистке тома Salt Master от устаревших политик и ожидании готовности сервисов Kerberos.</p> <p>Обновление MULTIDIRECTORY 3.2.0 превращает службу каталогов в отказоустойчивое решение для распределённых инфраструктур, которое обеспечивает соответствие регуляторным требованиям и стабильность работы в сертифицированных контурах защиты информации.</p> Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0 … message https://www.itweek.ru/themes/detail.php?ID=235384 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Новое исследование «</em><em>Scaling</em> <em>AI</em> <em>agents</em> <em>with</em> <em>trustworthy</em> <em>data</em><em>» от MIT Technology Review и Google Cloud подтверждает, что эффективное внедрение искусственного интеллекта начинается с надежного фундамента данных и современных методов управления данными.</em></p> <p>Отчет основан на опросе 300 директоров по данным и аналитике, CIO, CTO, директоров по ИИ, а также руководителей отделов продуктов, ИТ, данных и ИИ в различных отраслях.</p> <p>#IMAGE_235385#</p> <p>Основные выводы из исследования:</p> <ul> <li>Большинство организаций (83%) сообщили об использовании агентного ИИ, при этом 73% используют его для ограниченного числа сценариев. Только каждая десятая организация использует его широко.</li> <li> Хотя 100% респондентов заявили, что планируют использовать агентный ИИ в течение следующих двух лет, только около половины респондентов доверяют точности и релевантности результатов работы агентов ИИ.</li> <li> Исследование также показало, что в среднем инструментам агентного ИИ доступны около 45% данных компании, при этом избранная группа респондентов, называемая «лидерами в области данных», предоставляет ИИ доступ к более чем 70% своих данных. Другие сообщают о предоставлении доступа к 30% или менее своих данных.</li> <li> В отчете успех и доверие лидеров в области данных к агентному ИИ объясняются прочным фундаментом данных, в то время как другие организации сообщают о проблемах, связанных с устаревшими системами.</li> </ul> <p>«Мы должны предоставлять агентам доступ к данным безопасным и надежным способом, чтобы люди могли максимально эффективно использовать данные, зная, что они полностью надежны», — считает Раджприт Баджва, вице-президент Shopify по инженерии и инфраструктуре данных.</p> <p>В отчете упоминается группа компаний, которую называют «лидерами в области данных». Эти компании сообщают о большем успехе в использовании агентного ИИ и меньшем количестве ограничений данных со стороны устаревших систем. Хотя только около 50% респондентов доверяют своим агентам ИИ, 100% лидеров в области данных сообщили о доверии к точности и решениям своих агентов ИИ. В отчете говорится, что это «сильный показатель того, что надежный ИИ требует надежного фундамента данных».</p> <p>За пределами группы лидеров в области данных 66% респондентов заявили, что устаревшие системы ограничивают их возможности масштабирования агентного ИИ, а 68% заявили, что устаревшие системы замедляют скорость работы агентов. Среди других проблем — недостаток контекста и унификации данных (40% респондентов опроса Teradata/Wakefield «Why Agentic AI Stalls Enterprise» сообщили об тех же проблемах, несмотря на наличие надежных моделей ИИ).</p> <p>«Организации стремительно переходят к операционной модели, в основе которой лежит ИИ. Теперь ИИ учитывается при принятии каждого бизнес-решения, в каждом рабочем процессе и при любых инвестициях. Без четкой приверженности ИИ на уровне всего предприятия организациям будет сложно в полной мере реализовать его потенциал в масштабе предприятия», — говорит Карли Идоин, вице-президент-аналитик Gartner.</p> Новое исследование «Scaling AI agents with trustworthy data» от MIT Technology Review и Google Cloud подтверждает … message https://www.itweek.ru/themes/detail.php?ID=235382 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Зарубежные аудиторы ушли из России, но потребность в зрелой стратегии информационной безопасности никуда не исчезла. Теперь российским компаниям приходится одновременно развивать собственные команды, обращаться к локальным консультантам и превращать ИИ-агентов в персональных экспертов по кибербезопасности.</em></p> <p>После ухода из России крупнейших международных аудиторских компаний рынок информационной безопасности лишился не просто известных брендов. Вместе с ними ушел доступ к огромному массиву практического опыта, который формировался благодаря работе с компаниями из разных стран, отраслей и регуляторных сред.</p> <p>Российский рынок составляет около 2% мирового рынка ИТ и информационной безопасности. Поэтому локальные специалисты и консультанты объективно работают с меньшим количеством сценариев, бизнес-моделей и инцидентов. Именно клиентское покрытие давало зарубежным аудиторам ключевое преимущество: они могли переносить в проекты процессы и подходы, проверенные на международном уровне.</p> <p>Рост доли России с 2 до 4% мирового ИТ-рынка к 2030 году можно рассматривать не как прогноз, а как ориентир для отрасли. Однако для такого роста недостаточно увеличивать число технологий и специалистов. Российскому бизнесу нужны зрелые процессы, в том числе в информационной безопасности. После ухода международных аудиторов готового доступа к таким практикам стало меньше, поэтому компаниям приходится фактически заново собирать эту экспертизу — внутри собственных команд, с помощью российских консультантов и ИИ-агентов.</p> <p>Сегодня перед российским средним и крупным бизнесом стоит сложный вопрос: откуда брать зрелую экспертизу и на чем строить стратегию информационной безопасности, если прежние источники знаний стали недоступны?</p> <p>Единственного решения здесь нет. Компании могут использовать три подхода — внедрять ИИ-агентов, развивать собственные команды и привлекать российских аудиторов. Но по-настоящему жизнеспособная стратегия возникает только тогда, когда бизнес совмещает все три направления.</p> <h3>ИИ-агент может стать экспертом по кибербезопасности — но на его обучение потребуется время</h3> <p>Современный ИИ — это уже не просто приложение, в которое пользователь вводит запрос через браузер. Бизнес может приобрести специализированный сервис, подключенный через API к крупным языковым моделям и способный самостоятельно выбирать источники и инструменты для решения конкретной задачи.</p> <p>На основе такой системы можно создать персонального ИИ-эксперта по информационной безопасности.</p> <p>Для этого агенту необходимо предоставить максимально полную базу знаний: российскую и зарубежную профессиональную литературу, нормативные документы, методологии, отраслевые исследования, описания угроз и практические материалы. Чем больше релевантной информации получает система, тем точнее становятся ее рекомендации.</p> <p>При последовательном обучении через год такой агент сможет превратиться в полноценного помощника для команды информационной безопасности. Он сможет обращаться в том числе к источникам, находящимся за пределами России, анализировать международные практики и сопоставлять их с задачами конкретного бизнеса.</p> <p>ИИ-агент способен помочь компании определить основные риски, понять, какой аудит необходимо провести, какие данные собрать и какой информации не хватает для принятия решений. Он также может использоваться при подготовке рекомендаций и формировании первоначальной карты информационной безопасности.</p> <p>При этом ИИ не должен работать бесконтрольно. Вместе с агентами компании необходимо внедрять системы проверки их действий, результатов и доступа к корпоративной информации.</p> <h3>Одного универсального специалиста недостаточно: стратегия ИБ требует целой команды</h3> <p>Второй путь — развитие собственной экспертизы. Это наиболее устойчивый, но одновременно самый дорогой вариант.</p> <p>Построить стратегию информационной безопасности силами одного универсального специалиста невозможно. Для полноценной оценки рисков нужны сотрудники с разными компетенциями: специалисты по ИТ и информационной безопасности, финансисты, представители бизнеса и другие эксперты.</p> <p>Каждый из них отвечает за отдельную часть задачи. Технические специалисты оценивают инфраструктуру и средства защиты. Финансисты помогают рассчитать возможный ущерб и стоимость мероприятий. Представители бизнеса определяют, какие процессы и данные действительно критичны для компании.</p> <p>Формирование полноценной стратегической карты может занимать не менее трех лет. После этого ее необходимо ежегодно пересматривать и актуализировать с учетом изменений бизнеса, инфраструктуры и угроз.</p> <p>Для компании это означает необходимость постоянно содержать команду специалистов либо заново привлекать экспертов при каждом обновлении стратегии. Поэтому собственная экспертиза дает бизнесу независимость, но требует долгосрочных инвестиций в найм, обучение и сохранение команды.</p> <h3>Российские аудиторы остаются необходимы, хотя их опыт пока уступает международному</h3> <p>Третий вариант — обращаться к компаниям, которые продолжают работать в России.</p> <p>У локальных аудиторов меньше международного опыта, готовых сценариев и накопленных отраслевых практик, чем было у крупнейших зарубежных компаний. Кроме того, на российском рынке пока не так много организаций, готовых заказывать комплексную разработку стратегии информационной безопасности: такие проекты стоят дорого и требуют участия руководства.</p> <p>Тем не менее полностью отказаться от внешней экспертизы бизнес не может. Независимые консультанты позволяют посмотреть на инфраструктуру и процессы со стороны, выявить риски, которые внутренняя команда может не замечать, и проверить обоснованность уже принятых решений.</p> <p>Российские аудиторы становятся важной частью системы, но их работа должна дополняться внутренней экспертизой компании и возможностями ИИ.</p> <h3>Стратегия ИБ показывает не только как защищаться, но и сколько это будет стоить</h3> <p>Стратегия информационной безопасности строится вокруг трех базовых принципов: целостности, доступности и достоверности информации.</p> <p>Ее задача — определить, в каких областях компания подвержена рискам и к каким последствиям они могут привести.</p> <p>Например, бизнесу необходимо обеспечить доступность стратегически важных документов. Но эта доступность может быть нарушена по разным причинам: из-за отключения электроэнергии, отказа сервера, действий злоумышленников или порчи документов сотрудником.</p> <p>Стратегия позволяет последовательно ответить на несколько вопросов: какие сценарии возможны, насколько они вероятны, какой ущерб могут причинить и какие меры помогут их предотвратить.</p> <p>На основе этого компания определяет, сколько денег необходимо потратить на минимизацию каждого риска. При этом стратегия не предполагает, что бизнес должен закрыть абсолютно все угрозы. Некоторые риски можно принять, если стоимость защиты окажется выше потенциального ущерба.</p> <p>Поэтому стратегия отвечает не только на вопрос, как закрыть риск, но и нужно ли вообще это делать. В отдельных случаях эффективнее не покупать дополнительную систему защиты, а пересмотреть сам бизнес-процесс.</p> <h3>Бесплатное или корпоративное решение: выбор должен зависеть от задачи</h3> <p>Стратегия также помогает определить, какие специалисты требуются компании и в каком количестве. Для минимизации каждого риска нужен свой набор компетенций, причем эти специалисты необязательно должны работать в штате.</p> <p>Одновременно бизнес решает, какие системы целесообразно разработать самостоятельно, а какие — приобрести у внешнего поставщика.</p> <p>Особенно активно сейчас обсуждается выбор между бесплатными решениями с открытым исходным кодом и платными корпоративными продуктами. Однако сама по себе стоимость лицензии не должна становиться главным аргументом.</p> <p>Решение необходимо выбирать исходя из задачи, масштаба внедрения, количества пользователей и условий эксплуатации. Бесплатный продукт может оказаться подходящим для одного сценария, но потребовать значительных затрат на настройку, поддержку и контроль в другом.</p> <p>Стратегия информационной безопасности позволяет связать технологический выбор с реальными потребностями бизнеса, а не с модой или формальным требованием внедрить определенный класс решений.</p> <h3>Трехлетняя карта заранее показывает, что делать и какой бюджет закладывать</h3> <p>Результатом стратегической работы становится дорожная карта. Она определяет, какие мероприятия компания должна выполнить в первый, второй и последующие годы.</p> <p>Благодаря этому бизнес может заранее распределить бюджет, запланировать внедрение систем, обучение сотрудников, аудит процессов и привлечение внешних специалистов.</p> <p>Такая карта не является неизменным документом. Если компания выходит в новый сегмент, запускает продукты, перестраивает инфраструктуру или меняет бизнес-модель, стратегию информационной безопасности необходимо актуализировать.</p> <p>Защита должна развиваться вместе с бизнесом. Иначе даже качественно подготовленный документ через несколько лет перестанет соответствовать реальным процессам и угрозам.</p> <h3>В одиночку не сработает: российскому бизнесу придется объединить все три подхода</h3> <p>В текущих условиях российским компаниям не стоит выбирать между собственной командой, ИИ и внешними аудиторами. Все три подхода необходимо использовать одновременно.</p> <p>Бизнесу нужно развивать внутреннюю экспертизу, инвестировать в обучение специалистов и сохранять целостность команды. Параллельно следует внедрять ИИ-агентов, обучать их на российских и зарубежных источниках и создавать механизмы контроля за их действиями.</p> <p>Кроме того, компаниям необходимо пользоваться услугами российских аудиторов, которые могут независимо оценить процессы, инфраструктуру и принятые решения.</p> <p>Отдельное внимание следует уделять системам, предотвращающим утечки персональных данных, поскольку развитие ИИ и расширение цифровой инфраструктуры создают дополнительные риски для корпоративной информации.</p> <p>Уход международных аудиторов лишил российский рынок части накопленной экспертизы, но не сделал построение зрелой системы информационной безопасности невозможным. Совмещение внутренней команды, внешнего аудита и возможностей ИИ позволяет создать стратегию, которая будет учитывать реальные бизнес-риски, доступные ресурсы и долгосрочные цели компании.</p> <p>#IMAGE_235383#</p> Зарубежные аудиторы ушли из России, но потребность в зрелой стратегии информационной безопасности никуда … article Сергей Крюков, генеральный директор exploitDog (НИР) https://www.itweek.ru/themes/detail.php?ID=235370 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители демонстрируют реальный прогресс в решении проблем масштабирования и коррекции ошибок. Существуют реалистичные планы по выпуску квантовых компьютеров, которые могут принести коммерческую выгоду. Но эта выгода будет неравномерной, проявляясь в конкретных классах высокоприоритетных задач и в разные временные горизонты. Технологическим руководителям необходимо практическое понимание того, где и когда квантовые вычисления, вероятно, будут иметь значение, пишет в корпоративном блоге Дэвид Мутер, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Квантовые компьютеры — это другие, а не более быстрые компьютеры</h3> <p>Квантовые компьютеры — это не суперкомпьютеры с большей вычислительной мощностью, как это часто изображается в новостях. Классические компьютеры основаны на булевой логике, физически реализуемой в соответствии с уровнем напряжения в полупроводниках. Квантовые компьютеры основаны на линейной алгебре и интерференционных картинах, которые возникают из-за волновой природы квантовых объектов. Это делает квантовые вычисления принципиально иными, подходящими для других типов задач.</p> <p>Какие это типы задач? Речь идёт о задачах, связанных с экспоненциально растущим числом комбинаций, физическими системами квантового уровня или вероятностными результатами, которые трудно эффективно моделировать на классических системах. Примеры: оптимизация портфеля, молекулярное моделирование, открытие новых материалов, логистические маршруты, моделирование электрических сетей и некоторые формы стохастического анализа рисков.</p> <p>Что это значит? Если задачу можно решить классическим методом, она будет решаться классическим методом и впредь. Это также означает, что квантовые компьютеры станут компонентами более широкого вычислительного конвейера, решая вычислительные задачи, которые классические компьютеры не могут решить, а для остальных задач будут использоваться классические методы.</p> <p>Таким образом, квантовые вычисления не будут развиваться как самостоятельная платформа. Квантовые компьютеры будут гибридными, сочетая классические вычисления с квантовыми в единой системе. Поставщики, которые сделают квантовые вычисления доступными благодаря гибридным средам выполнения и интеграции с классическими вычислениями, станут главными лидерами рынка.</p> <h3>Ценность квантовых вычислений эволюционирует в избирательную коммерческую значимость</h3> <p>В краткосрочной перспективе состояние рынка по-прежнему будет определяться экспериментами. Прогресс будет достигнут за счет улучшения коррекции ошибок, совершенствования алгоритмов и более четкого понимания того, какие аппаратные средства масштабируемы. Наиболее неотложным приоритетом для бизнеса в это время будет безопасность. Организациям следует ускорить планирование постквантовой криптографии, поскольку достижения как в области квантового оборудования, так и в оптимизации алгоритма Шора для снижения требуемой вычислительной мощности квантовых вычислений приближают наступление «Дня квантовых вычислений» (Q-Day).</p> <p>В долгосрочной перспективе квантовые вычисления станут коммерчески значимыми, но избирательно. Они не станут повсеместным ускорителем для всех корпоративных технологий, как компьютеры, с которыми мы выросли. Скорее, это будет высокоточный инструмент для специализированных рабочих нагрузок. Наибольшие возможности будут сосредоточены в таких отраслях, как медико-биологические науки, химическая промышленность, материаловедение, финансовые услуги, логистика, производство и энергетика.</p> <h3>Оценивайте потенциал квантовых вычислений по соответствию рабочей нагрузке</h3> <p>Как и в случае с любой технологией, способ оценки квантовых вычислений заключается в определении того, какие бизнес-задачи обладают характеристиками, которые делают эту технологию потенциально полезной. Наиболее подходящие рабочие нагрузки, как правило, связаны с вычислительной сложностью, основанной на многомерной линейной алгебре, — это, например, оптимизация, молекулярное или физическое моделирование и вероятностное моделирование. Наименее подходящие рабочие нагрузки — это те, для которых уже существуют хорошие решения в классических системах или которые имеют большую сложность данных.</p> <p>Понимание перспектив и ограничений квантовых вычислений поможет организациям избежать как упущенных возможностей из-за чрезмерной самоуспокоенности, так и погони за ложными результатами, вызванной ажиотажем. Некоторым отраслям следует начать структурированное исследование уже сейчас, поскольку долгосрочный потенциал роста может проявиться раньше, чем ожидается. Другим следует отслеживать прогресс и избегать спекулятивных инвестиций до тех пор, пока прогресс в квантовых исследованиях не покажет более четкую совместимость рабочих нагрузок.</p> Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители … article https://www.itweek.ru/themes/detail.php?ID=235386 Thu, 20 Aug 2026 11:38:42 +0300 <p>В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов. Рынок совершает переход от систем, которые отвечают на запросы, к системам, которые действуют самостоятельно — от генеративного к агентному ИИ. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, как трансформируется облачная инфраструктура для использования ИИ-агентов.</p> <p>Глобальный рынок агентного ИИ, по оценкам Stratistics MRC, в этом году достигнет $10,3 млрд и будет расти до $207,6 млрд к 2034 году при среднегодовом темпе роста 45,6%. По данным PwC, 88% руководителей планируют увеличить бюджеты на ИИ именно ради агентных сценариев, а Gartner прогнозирует, что к концу 2026 года 40% корпоративных приложений будут оснащены специализированными ИИ-агентами (против менее 5% в 2025 году). Агентный ИИ — это принципиально иная парадигма. Автономные агенты планируют действия, обращаются к корпоративным API, делегируют задачи другим ИИ-системам и выполняют многошаговые сценарии с минимальным участием человека. Человек смещается из позиции исполнителя в позицию супервайзера.</p> <p>За взрывным ростом внедрения ИИ-агентов скрывается фундаментальная проблема: корпоративная инфраструктура к этому не готова. По данным Google Cloud, 83% организаций заявляют о необходимости срочной модернизации мощностей для поддержки промышленного агентного ИИ.</p> <p>Запрос, который раньше генерировал один ответ, теперь запускает каскад из сотен действий. В отличие от пакетной обработки — чтение баз данных, межсервисное взаимодействие, координацию агентов. Каждое действие потребляет токены, генерирует сетевой трафик и требует ресурсов для логирования. Агентам нужна память о контексте и прогрессе. Каждый лишний шаг в цепочке вызовов умножает задержку, что требует от провайдера высочайшей скорости интерконнекта и оптимизированных сетей. Возникает феномен «инференс-налога» (inference tax) — скрытых затрат на вывод данных и разрастание хранилищ, с которыми уже столкнулись 62% технических руководителей (по данным Google Cloud).</p> <p>Российский рынок следует глобальному тренду, но со своей спецификой. Совместное исследование Apple Hills Digital, VK Tech, Cloud.ru и Selectel показывает, что 46% отечественных компаний уже используют или тестируют ИИ в облаке, а 27% клиентов провайдеров уже применяют облачных ИИ-агентов. Бюджеты на ИИ увеличили 35% компаний, опередив по темпам роста даже кибербезопасность. Если при классическом обучении моделей затраты относительно предсказуемы, то агентный ИИ генерирует расходы экспоненциально. Без автоматического мониторинга и управления каскадными вызовами компании рискуют столкнуться с тем, что до трети (а в случае с агентами — и больше) облачного бюджета будет сожжено впустую на неоптимальные маршруты агентов и простаивающие stateful-контейнеры.</p> <p>В новых реалиях облачный провайдер перестает быть просто поставщиком вычислительных мощностей и становится стратегическим партнером. Только облако способно обеспечить экономически обоснованную эластичность под непредсказуемые пиковые нагрузки агентных систем, избавляя бизнес от необходимости покупать дорогостоящее железо, которое устаревает за полтора года. Помимо этого, облако становится единой платформой для управления и безопасности: когда сотни автономных агентов получают доступ к корпоративным данным, централизованный аудит, управление правами и MLOps. Зрелый провайдер берет на себя роль FinOps-консультанта, помогая оптимизировать «инференс-налог»: распределяя нагрузку между CPU (для оркестрации), GPU (для тяжелого инференса) и специализированными ускорителями, а также настраивая автоматическое масштабирование stateful-сред.</p> В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов … message https://www.itweek.ru/themes/detail.php?ID=235380 Thu, 20 Aug 2026 09:43:39 +0300 <p>Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и скорость. Сначала — через сервис-ориентированную архитектуру (SOA), затем — через «серебряную пулю» микросервисов.</p> <p>Это обещание звучало заманчиво: распилите монолит на крошечные независимые сервисы, общающиеся по вебу, и вы будете выкатывать функционал бизнесу за пару дней силами изолированных команд. Маркетинговый хайп победил инженерный рассудок.</p> <p>Сегодня за ширмой «современного стека» скрывается суровая реальность: тотальный паралич Time-To-Market (TTM), астрономический технический долг и кратные финансовые потери.</p> <h2>Архитектурные заблуждения и подмена понятий: ООП наизнанку</h2> <p>В чём фундаментальный просчет концепции микросервисов в их массовом исполнении? В том, что базовые принципы проектирования программного обеспечения — инкапсуляцию, слабую связность и объектно-ориентированный подход — попытались насильно перенести на уровень сети.</p> <p>Архитекторы «новой волны» решили, что микросервис — это изолированный объект, а сетевой HTTP/REST-запрос — это просто вызов метода. Индустрия проигнорировала законы физики. Если вызов метода в едином адресном пространстве оперативной памяти (In-Memory Call) занимает наносекунды и абсолютно надежен, то сетевой вызов между мелкогранулированными компонентами занимает уже миллисекунды. А сама сеть к тому же по определению ненадежна.</p> <p>Ирония судьбы — в том, что в эпоху расцвета классической SOA те же промышленные платформы, от enterprise-решений ведущих вендоров до систем с открытым исходным кодом на .NET, Java или Python, технически предоставляли абсолютно те же преимущества, которые сегодня приписывают исключительно микросервисам.</p> <p>Архитектурные возможности изначально позволяли объединить отдельные прикладные компоненты и интеграционные адаптеры в изолированные крупногранулированные сервисы в соответствии с границами доменной области. Внутри этого домена компоненты взаимодействовали в едином адресном пространстве оперативной памяти (In-Memory), а платформы великолепно масштабировались горизонтально за счет логических экземпляров среды выполнения в составе одной или нескольких операционных систем.</p> <p>В какой-то момент в индустрии перестали соблюдать базовые принципы SOA-архитектуры, забыв, что микросервисы — это не более чем подмножество SOA.</p> <p>Вместо того чтобы наводить порядок в границах доменной области, разработчики объявили проверенные подходы «тяжелыми» и ушли в микросервисный веб. Они упустили из виду, что этот самый веб — про переносимость, и вся его прелесть проявляется тогда, когда речь идет об интеграции разнородных систем, развернутых на принципиально разных платформах, когда речь идет об интероперабельности.</p> <p>Физическая изоляция (сеть и контейнеризация) стала защитой от низкой культуры и дисциплины разработки. Если вы не умеете инкапсулировать код в логические модули, сеть заставит вас сделать это силой. Но цена такого принуждения оказалась непомерной для бизнеса.</p> <h2>Подмена понятий: из песочницы разработки в промышленную эксплуатацию</h2> <p>Чтобы понять, как мы оказались в этой точке, нужно вспомнить историю развития технологий разработки. Весь этот технологический стек — контейнеризация, платформы оркестрации и автоматизированные CI/CD-пайплайны — изначально задумывался исключительно как инструментарий для высвобождения рабочего времени разработчика.</p> <p>В частности, изоляция сред в контейнерах была введена в процесс разработки как ответ на вечное проклятие: «на моей машине всё работало». Она была нужна, чтобы программист мог мгновенно развернуть готовое локальное окружение.</p> <p>Платформы оркестрации контейнеров создавались в недрах технологических гигантов для утилизации пустующих серверов дата-центров и быстрой подготовки эфемерных тестовых сред под нужды команд автоматизации. Эти инструменты создавались для «песочниц», прототипирования и автоматизации рутины. Никто не проектировал их под высоконагруженные транзакционные контуры, требующие промышленной надежности.</p> <p>Трагедия современной ИТ-индустрии в том, что инструмент быстрой лепки временных сред ошибочно приняли за стандарт. Архитекторы перенесли логику «песочницы» на боевые контуры транзакционных систем финансового и промышленного секторов. В результате бизнес получил хрупкую распределенную систему, где стабильность решения принесена в жертву сиюминутному удобству локального написания кода.</p> <h2>Великое заблуждение: архитектура системного ПО в транзакционном бизнесе</h2> <p>Микросервисная архитектура родилась не на предприятиях непрерывного цикла и не в банках с их высокоинтенсивными рабочими нагрузками. Она появилась в недрах цифровых гигантов (Netflix, Amazon, SoundCloud), у которых вообще не было чужих систем и разных поставщиков. Они контролировали 100% своего стека и писали всё с нуля.</p> <p>В этих условиях все сервисы изначально взаимодействовали на одном «языке» (JSON/REST), и трансформировать форматы данных было просто не нужно. Внедрение сложных интеграционных шин в такую однородную среду принесло бы только лишние накладные расходы.</p> <p>Но главное — характер их работы. Микросервисы в их каноническом виде — это архитектура уровня системного ПО управления ресурсами. Условная транзакция в облачном провайдере или стриминговом сервисе запускает длительный, асинхронный процесс. Например, развертывание виртуальной машины из ISO-образа. Этот процесс занимает десятки секунд или минуты. Пользователь готов ждать.</p> <p>На этом фоне 10 миллисекунд сетевых задержек, возникающих при взаимодействии между мелкогранулированными системными сервисами (один выделяет диск, другой вешает IP), — это не более чем математическая погрешность. Там действительно не нужна интеграционная транзакционная «молотилка».</p> <p>Но когда, например, в вакансиях «инновационного финтеха» для Core-системы со строгой OLTP-нагрузкой фигурируют микросервисы и оркестраторы — это признак тотального непонимания физики процессов. Финтех-операция должна выполняться синхронно, атомарно и за миллисекунды. И здесь 15 миллисекунд сетевых издержек на каждый шаг цепочки (запрос в сервис баланса, запрос в антифрод, запрос в лимиты) — это архитектурный приговор.</p> <p>Система тратит время не на полезную работу (изменение пары байт в СУБД), а на ожидание ответов по сети, обработку HTTP-заголовков и обеспечение консистентности данных (Eventual Consistency), которая в транзакционных системах недопустима по определению.</p> <h2>Иллюзия Time-To-Market: быстро на старте, паралич на финише</h2> <p>Главный аргумент в пользу микросервисов — это ускорение TTM. И на этапе разработки системы с нуля эта иллюзия действительно работает. Написать один мелкий сервис, который выполняет одну конкретную функцию, можно за пару дней. Руководство и бизнес-заказчик аплодируют стоя.</p> <p>Проблемы начинаются, когда система разрастается до сотен мелкогранулированных ИТ-сервисов, общающихся преимущественно по Web/HTTP. Бизнес же мыслит сквозными ценностями, а не микрофункциями. И когда для реализации одной новой бизнес-функциональности (например, внедрения нового типа лояльности) требуется одновременно изменить контракты в <nobr>5-7</nobr> разных микросервисах, начинается ад:</p> <ol> <li> <strong>Паралич взаимодействия команд:</strong> нужно согласовать изменения API с пятью независимыми командами. Продуктовый TTM падает до нуля, утопая в бесконечных созвонах, а также в согласованиях контрактов в спецификациях и задачах.</li> <li><strong>Интеграционный тупик:</strong> вместо релиза одной кнопкой компания получает сложнейшие распределенные релизные циклы. Архитектура превращается в распределенный монолит — худшее из обоих миров, выпуск релиза которого происходит дольше и болезненнее, чем в крупногранулированной SOA-архитектуре двадцать лет назад.</li> </ol> <h2>Облачный грабеж и трехкратный «инфраструктурный налог»</h2> <p>Когда ИТ-директора обосновывали переход на микросервисы, главным экономическим аргументом был отказ от «вендорской иглы» — коммерческих лицензий за процессорные ядра или вычислительные узлы, выделенные под прикладное решение. Обещание звучало как финансовое освобождение: «Мы уйдем на свободное программное обеспечение (Open Source), перенесем всё в облако и будем платить только за реальное потребление».</p> <p>Но на серьезных нагрузках микросервисная архитектура дает <strong>2-3-кратный рост расходов бюджета</strong>. Этот «финансовый пылесос» состоит из трех главных составляющих:</p> <ul> <li> <strong>Память и процессоры.</strong> В микросервисах каждому крошечному сервису нужно выделить сотни мегабайт оперативной памяти просто на прогрев его собственного изолированного окружения. Транзакция превращается в каскад из <nobr>10-15</nobr> сетевых вызовов, где до <nobr>40-60%</nobr> мощности процессора тратится на постоянную сериализацию и десериализацию JSON, шифрование TLS и перекладывание байтов по сетевым стекам. Чтобы переварить ту же нагрузку, приходится покупать в 2,5 раза больше вычислительных ядер (vCPU). Умножьте это на сотни сервисов и на зоны доступности. Как итог: бизнес платит за гигабайты памяти и процессорное время, которые вообще не используются для выполнения прикладной логики. В то же время транзакция в крупногранулированном сервисе — это просто передача ссылки на объект в памяти, не требующая выделения дополнительной памяти и процессорного времени на сериализацию и десериализацию.</li> <li> <strong>Скрытый «убийца» — сетевой трафик.</strong> Чтобы обеспечить высокую доступность, экземпляры микросервисов размазываются по разным дата-центрам (зонам доступности). Облачные провайдеры жестко тарифицируют каждый гигабайт трафика между зонами доступности (Inter-AZ). В рамках единого крупногранулированного сервиса этот трафик был бесплатным (внутри хоста); в микросервисах счета за внутриоблачную сеть часто превышают стоимость самих процессоров.</li> <li> <strong>Инфраструктурные надстройки как величайший обман.</strong> Пытаясь уйти от концепции интеграционных шин, ИТ-архитекторы заявили, что связь теперь «бесплатная». Но когда сетью стало невозможно управлять, индустрия придумала концепцию Service Mesh. Вместо одной центральной шины компания получила тысячи микрошин в виде прокси-приложений (sidecar) для каждого контейнера. Эксплуатация таких решений в крупных проектах показывает, что эти прокси съедают от 20 до 50% всей оперативной памяти и до 30% CPU всего вычислительного кластера. Бизнес просто перенаправил миллионы из одного кармана в другой — в пользу облачных провайдеров.</li> </ul> <h2>Практика против моды: опыт технологических лидеров</h2> <p>Для тех, кто считает эти расчеты «теоретическим ретроградством», индустрия приготовила серию сокрушительных прецедентов от компаний, чьи масштабы нагрузок не подлежат сомнению.</p> <h3>Amazon Prime Video: отрезвление изнутри</h3> <p>Самый громкий удар по микросервисной религии нанесла сама компания Amazon — создатель главной облачной инфраструктуры планеты.</p> <p>Инженеры команды Amazon Prime Video, спроектировав распределенную систему мониторинга качества видеопотоков по «модному учебнику», столкнулись с финансовой катастрофой при попытке масштабирования. Изначальная архитектура опиралась на оркестрацию через AWS Step Functions и бессерверные вычисления AWS Lambda. Архитектурный просчет заключался в том, что компоненты пайплайна (медиаконвертер и детектор дефектов) обменивались терабайтами тяжелых сырых видеокадров, постоянно сохраняя и скачивая их через промежуточное дисковое хранилище Amazon S3.</p> <p>В результате система уперлась в потолок производительности всего на 5% от целевой мощности: компания моментально уперлась в лимиты AWS Step Functions по количеству переходов между состояниями (state transitions) в секунду, а счета за Tier-1 API-запросы к S3 и сетевую сериализацию кратно превысили стоимость самого компюта.</p> <p>Инженеры Amazon полностью переписали архитектуру, объединив все три распределенных компонента в единое монолитное приложение, развернутое в контейнерах Amazon ECS. Вместо пересылки тяжелых фреймов по сети через S3, этапы конвейера стали обмениваться данными напрямую в оперативной памяти (In-Memory) в рамках одного процесса. Результат: <strong>затраты на инфраструктуру снизились на 90%</strong>, а ограничения масштабируемости исчезли.</p> <h3>Shopify: битва за скорость «выкатки фич»</h3> <p>Гигант мировой интернет-торговли Shopify, обрабатывающий миллионы транзакций, вовремя остановил тотальное дробление систем. Архитекторы обнаружили, что мелкогранулированность и распределенность разрушили границы контекстов, вызвав тяжелейший межкомандный паралич: для банального изменения логики скидок или корзины приходилось синхронно переписывать контракты API в шести независимых командах и репозиториях.</p> <p>Shopify официально провозгласил верность концепции «Маджестик Монолита» (Majestic Monolith), но вместо хаотичного «комка грязи» они планомерно реорганизуют кодовую базу в строго изолированный «<strong>Модульный монолит» (Modular Monolith)</strong>.</p> <p>Используя разработанный ими инструмент статического анализа Packwerk (в связке с софтверными контрактами Sorbet), компания жестко контролирует границы бизнес-доменов на уровне абстракции кода. Все модули находятся в едином репозитории и разворачиваются вместе, что избавляет инженеров от сетевой бюрократии, сохраняет строгую ACID-консистентность базы данных, но при этом изолирует зоны ответственности команд и сокращает TTM в разы.</p> <h3>Segment (Twilio): тупик мелкозернистой изоляции</h3> <p>Платформа сбора данных Segment изначально создала отдельный микросервис и отдельную очередь для интеграции с каждым внешним партнером (Mixpanel, Salesforce, Google Analytics и др.). В итоге их ИТ-ландшафт превратился в распределенный ад из более чем <strong>140 разрозненных сервисов и 140 отдельных репозиториев</strong>.</p> <p>Из-за постоянных обновлений общих библиотек и латания рассинхронизированных зависимостей (Dependency Hell) разработчики тратили 80% времени на поддержание жизнедеятельности инфраструктуры и RabbitMQ-очередей, а развитие продукта полностью остановилось. Сотни простаивающих контейнеров впустую сжигали базовые CPU-квоты облака.</p> <p>В итоге Segment осуществила радикальный шаг: объединила код всех 140 интеграций обратно в один монолитный Go-бинарник, получивший кодовое имя Centrifuge. Маршрутизация трафика по конечным партнерам стала осуществляться через внутрипроцессную таблицу диспетчеризации в оперативной памяти. Это мгновенно сократило расходы на серверы, драматически подняло утилизацию CPU и полностью ликвидировало ад управления зависимостями, вернув продуктивность продуктовым командам.</p> <h2>Ад оркестрации: почему сложные платформы автоматизации противопоказаны для High Load</h2> <p>Разрубив систему на тысячи кусков, компании выбрали в качестве главного инструмента управления тяжелые платформы оркестрации контейнеров. Но они стали стандартом де-факто для высоких нагрузок абсолютно незаслуженно. Для систем с экстремальными транзакционными нагрузками и жесткими требованиями к задержкам (low-latency) избыточный слой контейнерной оркестрации противопоказан:</p> <ul> <li> <strong>Сетевой пирог виртуализации.</strong> В таких средах сетевой трафик проходит сквозь бесконечные слои абстракций — виртуальные интерфейсы, оверлейные сети, прокси-таблицы ядра и инфраструктурные шлюзы. В транзакционном High Load подобная избыточность превращается в критическое узкое место. Сетевой диспетчер или аппаратный балансировщик эпохи классической SOA распределял трафик по экземплярам приложений практически со скоростью железа.</li> <li> <strong>Борьба за ресурсы.</strong> Оркестратор пытается динамически управлять ресурсами на уровне ядра операционной системы, ничего не зная о процессах и внутренних механизмах управления памятью самого прикладного решения (например, о «сборке мусора»). В итоге планировщик инфраструктуры и внутренний диспетчер приложения начинают «драться» за процессорное время, вызывая жесткое удушение (throttling) CPU и непредсказуемые задержки (latency spikes) прямо посреди финансовой транзакции.</li> <li> <strong>Сложность вместо надежности.</strong> Системы оркестрации создавались для управления тысячами эфемерных веб-компонентов, которые могут безболезненно падать каждую секунду. Но серьезная финтех-платформа или система управления предприятием состоит из стабильных, тяжеловесных сервисов, хранящих состояние (Stateful). Разворачивать под них сложнейшие распределенные оркестраторы — это чистая подмена понятий, увеличивающая аварийность системы из-за человеческого фактора и сложности конфигурации.</li> </ul> <h2>Назад к здравому смыслу: эволюционная реабилитация SOA</h2> <p>Признание краха мелкогранулированных микросервисов вовсе не означает, что индустрия должна в панике откатиться к неделимым монолитам. Выход из этого тупика лежит в возврате к классической, фундаментальной концепции SOA, но переосмысленной на новом технологическом витке:</p> <ol> <li><strong>Крупная гранулярность.</strong> Сервис должен быть крупным. Не «сервис генерации PDF», а «Сервис расчетно-кассового обслуживания». Он объединяет в себе весь бизнес-домен. Внутри него компоненты общаются в оперативной памяти. Сетевая граница проводится только там, где бизнес-процессы действительно разделены организационно (например, интеграция систем разных поставщиков, где SOA и её интеграционные паттерны исторически незаменимы).</li> <li><strong>Отделение бизнес-домена от интеграционного слоя.</strong> Мы берем из SOA проверенную интеграционную логику, но не тащим логику бизнес-домена на централизованную шину. Её задача — выполнять исключительно трансформацию, обогащение и маршрутизацию сообщений. Она выступает просто умным почтальоном для потока данных, связывая системы разных поставщиков.</li> <li><strong>Изоляция без посредников.</strong> Для изоляции рабочей нагрузки не нужны тяжелые контейнерные движки с централизованными демонами управления, являющиеся классической единой точкой отказа и узким местом производительности. Настоящая изоляция крупного SOA-сервиса реализуется через легковесные инструменты нового поколения, работающие по принципу <em>daemonless</em> (без демона) и в режиме <em>rootless</em> (без прав суперпользователя) — такие как Podman. Контейнер в такой схеме запускается как обычный, изолированный процесс Linux, управляемый напрямую ядром ОС (через стандартный systemd). Это дает предсказуемость среды (Infrastructure as Code) и скорость железа без инфраструктурных накладных расходов оркестраторов.</li> </ol> <h2>Вывод для бизнеса</h2> <p>Эра микросервисного романтизма завершается. Компании, считающие свои деньги, больше не могут позволить себе оплачивать трехкратный инфраструктурный налог. Побеждает здравый инженерный расчет.</p> <p>Классическая SOA, очищенная от бюрократии старых инструментов и усиленная легковесной daemonless-контейнеризацией, возвращает себе статус эталонной архитектуры. Она дает ровно то, что обещали, но не смогли дать микросервисы: прогнозируемый TTM, контролируемый техдолг и адекватные затраты на железо. Настоящий High Load всегда покоится на уровне операционной системы и железа, а не на уровне абстракций оркестраторов.</p> <p>#IMAGE_235381#</p> Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и скорость. Сначала — через сервис-ориентированную … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=235377 Thu, 20 Aug 2026 00:00:00 +0300 <p><em>Компании продолжают вкладывать миллионы в нейросети, но всё чаще признают: результата нет. Разбираемся, почему пилоты не доходят до внедрения и что стоит изменить в подходе к ИИ уже сейчас.</em></p> <p>За последние два года искусственный интеллект прошел путь от модной новинки до строки в бюджете почти каждой крупной компании. Однако чем больше денег уходит на пилоты, тем острее встает вопрос: а где, собственно, отдача? По <a href="https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/">данным</a> MIT NANDA, около 95% корпоративных ИИ-пилотов так и не доходят до измеримого финансового эффекта, а по <a href="https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence">оценке</a> Gartner, довольны окупаемостью инвестиций менее 30% руководителей при среднем чеке проекта около 1,9 млн. долл.</p> <p>Похожая картина и в России. По <a href="https://www.vedomosti.ru/global-ideas/articles/2026/06/02/1202053-vnedrenie-ii-biznes">данным</a> издания «Ведомости», 95% отечественных компаний пока не окупают инвестиции в ИИ-технологии, хотя 40% называют искусственный интеллект главным трендом цифровизации. Проблема почти никогда не в самой технологии — модели давно умеют решать прикладные задачи. Проблема кроется в том, как компании выбирают, запускают и оценивают такие проекты.</p> <h3>Почему пилоты не долетают до результата</h3> <p>Первая причина — путаница между желанием попробовать технологию и реальной выгодой от ее внедрения. Аналитики фиксируют эффект «рабочего мусора»: сотрудники <a href="https://www.kommersant.ru/doc/8632735">массово генерируют</a> ИИ-контент, который выглядит готовым, но требует переделки. Формально ИИ внедрен, но по факту он просто перекладывает работу с одного этапа на другой. В результате вместо сокращения издержек компания получает двойную нагрузку: сначала сотрудник тратит время на формулировку запроса, затем — на проверку и доработку сгенерированного результата, а выгода от автоматизации сводится к нулю.</p> <p>Вторая причина — данные и процессы. Российские аналитики <a href="https://www.cnews.ru/news/top/2026-03-24_biznes_svernul_ili_zamorozil">отмечают</a>: около 90% проектов по генеративному ИИ в отечественных компаниях откладываются или закрываются не из-за качества моделей, а из-за неструктурированных данных и хаотичных регламентов, в которые нейросеть просто не вписывается. Внедрять ИИ в процесс, где нет единого источника данных и нет ответственного за результат, — заведомо неэффективно и не приведет к ожидаемому результату.</p> <p>Третья причина — отсутствие стратегии и метрик. Согласно <a href="https://www.cnews.ru/news/top/2025-12-19_bolshinstvo_rossijskih_kompanij">исследованию</a> МТС Web Services, лишь 26% российских компаний, закладывающих бюджет на ИИ, имеют четкую стратегию внедрения. Без понятных критериев успеха невозможно оценить окупаемость, а значит, проект существует скорее «для галочки», чем для бизнеса, и при первом же аудите бюджета или смене фокуса его свернут, списав затраты в убыток.</p> <h3>Российская специфика: дорогие эксперименты и дефицит мощностей</h3> <p>К управленческим проблемам добавляется инфраструктурная. По <a href="http://reg.ru/company/news/12957">нашим данным</a>, спрос на облачные GPU-мощности в России за первое полугодие 2026 года вырос на 507% год к году: число новых подключений увеличилось на 160%, а ежемесячная активность пользователей — на 260%. При этом дефицит высокопроизводительных ускорителей для обучения крупных моделей сохраняется: сроки поставки востребованных карт достигают <nobr>36-52 недель.</nobr> По оценке <a href="https://www.comnews.ru/content/245257/2026-05-14/2026-w20/1008/vychislitelnyy-tupik-pochemu-rossiyskiy-ii-ostaetsya-bez-moschnostey">отраслевых экспертов</a>, совокупный разрыв в вычислительных мощностях между Россией и США измеряется сотнями раз, а весь российский рынок GPU-ускорителей для ИИ в 2025 году составил около 62,7 млрд. руб. — сумма, за которую крупные технологические экономики покупают буквально в разы больше вычислений.</p> <p>На практике это означает, что покупка собственного оборудования под эксперимент зачастую экономически нерациональна: один ускоритель уровня NVIDIA H200 стоит <nobr>30-40 тыс.</nobr> долл., а полноценный сервер с восемью GPU — 300 тыс. долл. и выше, при том что жизненный цикл карты — всего <nobr>2-3 года.</nobr> Компании, которые закладывают капитальные затраты на GPU в пилот, который может не взлететь, изначально закладывают в проект избыточный риск и одну из причин будущей низкой окупаемости.</p> <h3>От ROI одной нейросети — к экономике процесса</h3> <p>Ключевая ошибка, которую совершают почти все, — считать окупаемость самого ИИ-инструмента, а не изменения, которое он должен принести бизнесу. Исключение — ситуация, когда инструмент создается не для внутреннего использования, а как продукт для продажи на рынок: тогда его собственная окупаемость действительно становится главной метрикой. Поэтому рекомендуется считать не отдельный ROI (Return on Investment, коэффициент окупаемости инвестиций) чат-бота или копилота, а влияние на сквозной процесс — от заявки клиента до закрытия сделки, — и переходить к новой модели расчета: юнит-экономике с ИИ-агентами, где единицей измерения становится не человеко-час, а количество сценариев, закрытых без участия человека.</p> <p>На практике счет выглядит так. Сначала выбирается единица процесса — например, заявка клиента, доведенная от обращения до решения, — и фиксируется ее сегодняшняя стоимость: сумма человеко-часов, инструментов и накладных расходов, деленная на число закрытых единиц за период. Дальше внедряется ИИ-агент, и считается новая стоимость единицы — расходы на инфраструктуру и лицензии (или расходы на подписку или токены) плюс время сотрудников, которое еще нужно на контроль и разбор исключений. Разница до и после, умноженная на объем процесса, и есть реальная экономика проекта, а не абстрактный процент высвобожденного времени. Отдельно стоит следить за долей сценариев, закрытых без участия человека: если она растет от месяца к месяцу, изменение действительно масштабируется.</p> <h3>Что делать прямо сейчас</h3> <p>Универсального рецепта нет, но есть несколько работающих принципов.</p> <ul> <li><strong>Считать метрику до старта, а не после. </strong>Пропишите одну фразу с цифрой и сроком — например, «сократить время обработки заявки с 4 часов до 40 минут за 3 месяца», и отдельно укажите, в каком экономическом эффекте это должно выразиться: например, в снижении затрат на найм дополнительных сотрудников, росте лояльности клиентов или увеличении среднего чека. Назначьте человека, который отвечает именно за эти показатели, а не за факт запуска проекта.</li> <li><strong>Начинать с малого и наращивать масштаб. </strong>Берите один конкретный процесс, а не весь отдел целиком, и давайте пилоту <nobr>4-6</nobr> недель на одной команде. Если показатель из первого пункта сдвинулся — расширяйте на соседние процессы, если нет — меняйте гипотезу, а не бюджет.</li> <li><strong>Заниматься данными и процессами, а не только моделью.</strong> Перед запуском проверьте на практике: сможет ли сотрудник за один день найти все данные, нужные для этого сценария, в одном месте, а не в трех разных системах и переписке. Если нет — сначала наведите порядок здесь, а не в выборе модели или ИИ-инструментов.</li> <li><strong>Работать с командой, а не только с технологией. </strong>Назначьте внутри команды человека, который отвечает за процесс, и обсудите с сотрудниками до запуска, какие задачи берет на себя ИИ и что остается за ними: это снимает страх замены и превращает пилот в общий эксперимент, а не в решение, спущенное сверху.</li> <li><strong>Не привязывать пилот к покупке оборудования.</strong> Один из вариантов — арендовать готовую инфраструктуру с почасовой оплатой: специализированные ИИ-платформы уже дают доступ и к GPU-серверам, и к готовым инференс-движкам, и к инструментам для разработки и автоматизации без необходимости собирать всё самостоятельно. Так эксперимент можно закрыть без потерь, если гипотеза не подтвердится, или быстро масштабировать, если она сработала.</li> </ul> <p>Наконец, стоит возвращаться к проекту не только на старте, а регулярно: сверять метрики каждые несколько месяцев и честно решать, масштабировать решение, дорабатывать или закрывать проект, а не держать его в статусе вечного пилота. И, главное, считать не окупаемость нейросети саму по себе, а то, как она меняет весь процесс целиком, — именно здесь чаще всего и находится реальная экономика, которую пропускают 70% руководителей, разочарованных в ИИ сегодня.</p> <p> #IMAGE_235378#</p> Компании продолжают вкладывать миллионы в нейросети, но всё чаще признают: результата нет. Разбираемся, почему пилоты … article Евгений Мартынов, директор по информационным технологиям Рег.облака https://www.itweek.ru/themes/detail.php?ID=235369 Thu, 20 Aug 2026 00:00:00 +0300 <p><em>Организации должны переосмыслить не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Проблема клиента с предоставленной ему услугой передается агенту искусственного интеллекта после первоначального общения с чат-ботом. Агент проверяет официальную документацию, в которой четко указано, что в ситуациях такого типа применяется политика A — так что именно эту политику агент применяет и здесь.</p> <p>Это довольно распространенная ситуация, с которой регулярно сталкиваются многие предприятия. Кроме того, многие компании надеются, что использование ИИ-агента может повысить производительность.</p> <p>Однако такого повышения производительности не произойдет, если корпоративная база знаний, на которую опирается агент, будет неполной, неверной или устаревшей. Например, в приведенном выше сценарии представьте, что отдел продаж в течение нескольких месяцев уже придерживается политики В, но не обновил официальную документацию. У них может быть некий документ, объясняющий это изменение и новую политику, но он невидим для агентов ИИ, если не является частью базы знаний, к которой они могут получить доступ.</p> <p>В результате агент уверенно принимает неверное решение для данного клиента. Однако это не ошибка агента, а недостаток системы организационных знаний. Агенты ИИ не создают проблем со знаниями, но они выявляют проблемы, с которыми сталкиваются организации.</p> <h3>Готовность к использованию людьми не означает готовность к использованию ИИ</h3> <p>Часто организации полагают, что самой большой проблемой при переходе агентов ИИ от пилотов к производству является совершенствование самой модели. Но более серьезное препятствие часто носит более приземленный характер, говорит Кубер Шарма, старший директор UiPath по маркетингу продуктов для корпоративного ИИ и автоматизации. «Разрыв, который я чаще всего наблюдаю между пилотом и производственным внедрением ИИ-агентов, заключается не в модели. Дело в знаниях», — поясняет он. Организации разрабатывают ИИ-агентов для действий на основе документации, но затем обнаруживают, что документация не была для этого подготовлена. Вместо этого, по словам Шармы, она был создана для людей, которые могут читать между строк, консультироваться с коллегой или применять контекст.</p> <p>За время своего существования организация тратит значительное количество времени и энергии на написание документации для сотрудников: руководств по интранету, внутренних вики, документов о политиках, соглашений об обслуживании клиентов, брошюр о продукции и т. д. Какими бы важными они ни были, эти документы часто бывают неполными. Например, документ может еще не быть обновлен, чтобы отразить новую политику или процедуру или изменения в отраслевых или государственных нормативных актах.</p> <p>Когда люди используют эту документацию для поддержки своей работы, они могут выявить пробелы или несоответствия и предоставить важный контекст для их устранения. Интерпретируя неоднозначность и консультируясь с коллегами, они могут найти информацию, которую документация не охватывает, или решить, что конкретный документ больше не актуален.</p> <p>Но по мере того, как организации заменяют или дополняют агентами ИИ рабочую деятельность, осуществляемую людьми, они все больше сталкиваются с проблемами из-за неоднозначности документации. ИИ не способен обеспечить контекст или интерпретацию неполных баз знаний, которые могут обеспечить люди, и это приводит к проблемам, когда агенты сталкиваются с противоречивыми политиками, использованием электронной почты или чата в качестве документации, недокументированными исключениями или крайними случаями, дублированием документации и устаревшими практиками.</p> <p>Даже если документация точна, ее формат может стать препятствием. Файлы, хранящиеся в формате PDF, в наборах слайдов, графических материалах или специализированных учебных пакетах, могут содержать ценные институциональные знания, но без их дополнительной доработки агенты ИИ не смогут их анализировать и строить свои действия на их основе.</p> <p>Чтобы добиться успеха, агентам ИИ требуется четкая организационная память, а не институциональная интуиция и неполная документация.</p> <h3>Институциональные знания выходят за рамки официальных документов</h3> <p>Для некоторых организаций обновление официальной документации может ограничиваться обновлением нескольких ключевых PDF-файлов. Это важно, но база знаний предприятия включает в себя гораздо более широкий спектр документов и информации. Утверждения, решения, исключения, пути эскалации, бизнес-контекст, эволюция политик и неформальные практики — все это также является институциональной информацией, даже если она не отражена в официальной документации.</p> <p>Чтобы сделать институциональные знания доступными для агентов ИИ, часто требуется нечто большее, чем просто указать им на существующие файлы. По словам Джеймса Крэнвелла, руководителя отдела продуктов компании 5app, бóльшая часть корпоративного контента была создана для людей, а не для систем ИИ. Часто специалисты организации в предметной области загружают свои знания в документы Word, наборы слайдов, графики или PDF-файлы, иногда используя специфический для компании жаргон, сокращения и аббревиатуры, которые агентам ИИ трудно интерпретировать. Поэтому по мере того, как организации внедряют все больше агентов ИИ, стандартизация и структурирование их ресурсов знаний становится все более важной задачей.</p> <p>Крэнвелл не понаслышке знаком с этой проблемой. Недавно его команда создала ИИ-агент, способный анализировать пакеты электронного обучения SCORM, чтобы пользователи могли переходить к определенному разделу курса, а не извлекать сам файл курса. Этот опыт подтверждает, что организациям часто приходится адаптировать свои существующие ресурсы знаний, прежде чем агенты ИИ смогут эффективно их использовать.</p> <p>Успешное включение других источников институциональных знаний в базу знаний, используемую агентами ИИ, гарантирует, что эти агенты смогут более успешно интегрироваться в рабочие процессы предприятия. Чем больше у агента будет доступа к политикам, процедурам и другой информации, на основе которой он принимает решения, тем более информированными и точными будут эти решения, и тем лучше агент сможет не просто извлекать информацию, но и продуктивно применять ее на практике.</p> <p>По словам Шармы, знания, необходимые для работы агента, должны быть не только всеобъемлющи, но и конкретны. Не надейтесь на то, что существующий организационный контекст будет ему понятен, советует он. Вместо этого в документах должно быть четко указано, что они охватывают, а что нет, кому они принадлежат и когда они в последний раз проверялись и валидировались. Такой уровень конкретики помогает агентам ИИ отличать авторитетную информацию от устаревших или неполных рекомендаций.</p> <h3>Когда институциональные знания устаревают</h3> <p>Все большее число организаций полагаются на ИИ-агентов, которые берут на себя работу, ранее выполнявшуюся людьми. По данным McKinsey, 88% организаций в настоящее время используют ИИ для выполнения по крайней мере одной бизнес-функции, по сравнению с 78% годом ранее. И, согласно PwC, 79% опрошенных говорят, что агенты ИИ уже внедряются на их рабочих местах.</p> <p>По мере того как эти агенты будут становиться все более распространенными, будут возникать и проблемы, связанные с использованием ими устаревшей, неполной или неверной базы знаний. Когда это происходит, проблема выходит за привычные рамки: если сотрудник сбит с толку документацией, с которой он знакомится, то он может, по крайней мере, обсудить это с коллегой или использовать для интерпретации свои суждения и прошлый опыт. Неэффективные или неправильные решения, принимаемые агентами ИИ из-за плохой документации, приводят к неправильной маршрутизации, неправильным утверждениям или отказам, несогласованному взаимодействию с клиентами и, возможно, тысячам автоматизированных действий, которые не должны были выполняться.</p> <p>Как только агент начинает действовать на основе неполной информации, возникают вопросы подотчетности, что делает управление особенно важным. Организации, которые успешно справляются с этой задачей, рассматривают управление знаниями не как документирование, а как часть операционной модели агента ИИ, говорит Шарма. Когда агент выдает неверный результат, команды должны знать, кому принадлежат знания, лежащие в его основе, когда они проверялись в последний раз и почему агент полагается на них.</p> <p>Надежное управление базой знаний, на основе которой принимаются агентные решения, может смягчить некоторые из этих проблем. Организациям следует прояснить ряд вопросов, касающихся информации, которую агенты ИИ используют для принятия решений:</p> <ul> <li> Кому принадлежат данные знания?</li> <li> Кто обновляет их? Как часто?</li> <li> Кто рассматривает и утверждает изменения?</li> <li> Когда документ или его часть устаревают, кто и как их удаляет?</li> <li> Когда официальная документация меняется, кто проводит аудит агентов ИИ, чтобы убедиться в понимании ими изменений?</li> </ul> <p>Без этих ответов организации рискуют разработать системы, автоматизирующие принятие неверных решений. «Агент уверенно выдает неверный ответ, основываясь на неверном источнике. Это хуже, чем отсутствие ответа. Это сбой системы управления, одобренный ИИ», — сказал Шарма.</p> <p>Ответы на эти вопросы и понимание всеми заинтересованными лицами важности согласования этих ответов с базой знаний компании помогут избежать проблем с документацией при внедрении ИИ-агентов. Цель состоит в том, чтобы официальные знания, подготовленные для агентов, всегда были актуальными, четко сформулированными, авторитетными, структурированными, управляемыми и объяснимыми.</p> <h3>Убедитесь, что корпоративный источник истины готов к использованию ИИ</h3> <p>Организации могут беспокоиться о том, что ИИ-агент не сможет должным образом разобраться в их бизнесе, но первым шагом должно стать обеспечение понимания бизнесом самого себя.</p> <p>Агенты ИИ не могут восполнить недостающий контекст или информацию так, как это могут сделать сотрудники. Они не могут согласовать противоречивые документы, вывести неписаные правила или признать, что «все знают», что процедура изменилась. Они принимают решения на основе институциональных знаний, предоставляемых организациями, и выявляют все слабые места или пробелы в этих знаниях. Предприятие, осознающее недостаточность своей базы знаний, получает неожиданную выгоду от того, что ему приходится сталкиваться с накопившимися несоответствиями и исправлять их, а также создавать систему управления, которая позволит ему продвигаться вперед с использованием более совершенной модели поддержания этих знаний.</p> <p>Подготовка институциональных знаний для ИИ — это задача управления контентом в дополнение к управленческому процессу. Организациям все чаще приходится переосмысливать не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать.</p> Организации должны переосмыслить не только то, что они документируют, но и то, как они структурируют … article https://www.itweek.ru/themes/detail.php?ID=235376 Wed, 19 Aug 2026 14:24:22 +0300 <p>Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — решения для управления кластерами, расположенными в разных ЦОД, а также мажорной версии 3.0 встроенного модуля для развертывания сервисов в облаке Basis Automation Studio. Ключевыми изменениями релизов стали переработанная ролевая модель доступа пользователей, обновленная архитектура развертывания сервисов, новые инструменты управления ресурсами и углубление интеграции платформы с другими решениями экосистемы «Базис».</p> <p>Платформа Basis Dynamix Cloud Control предназначена для управления через единый портал частными и публичными облаками, построенными на базе различных платформ виртуализации — Basis Dynamix Enterprise, Basis Dynamix Standard, VMware vSphere и РУСТЭК.</p> <p>На смену встроенной ролевой модели в Basis Dynamix Cloud Control 5.6 пришла новая гибкая модель разграничения доступа, что позволяет администратору назначать права в точном соответствии с полномочиями пользователей. Переход на новую модель выполняется автоматически при обновлении инсталляции продукта: права пользователей мигрируют в новую структуру без ручной перенастройки. Вместе с новой моделью администраторы получили более удобные инструменты для работы с ролями, включая их клонирование — при копировании переносятся уровни доступа, права доступа и правила фильтрации исходной роли.</p> <p>В новой модели предусмотрены встроенные роли по умолчанию, готовые к использованию без дополнительной настройки. Поддерживается управление жизненным циклом пользовательских ролей для точечного предоставления необходимых прав на различные объекты. При архивировании учетной записи вместе с объектами доступа снимаются все связанные роли.</p> <p>В релизе 5.6 была существенно расширена функциональность сегментов Basis Dynamix Standard. Пользователям получили новые возможности, ранее уже доступные в других сегментах: поддержка сетей, роутеров, балансировщиков нагрузки, профилей безопасности и внешних систем хранения данных. Логика построения виртуальной сети стала более гибкой: маршрут по умолчанию на роутере создается автоматически, если пользователь не задал собственный. При этом в конфигурациях с несколькими роутерами разрешены удаление последнего порта роутера и отключение сети от роутера.</p> <p>Для облачных сегментов Basis Dynamix Enterprise в новом релизе была добавлена поддержка сервиса резервного копирования на базе Basis Virtual Protect — решения компании «Базис» для управления жизненным циклом резервных копий виртуальных машин. Администратор может подключить настроенный сервис к одному или нескольким сегментам Basis Dynamix Enterprise, для которых должны быть доступны инструменты резервного копирования. </p> <p>Автоматическая синхронизация изменений виртуальной инфраструктуры сегментов Basis Dynamix Enterprise дополнена операциями со снапшотами — созданием, восстановлением и удалением. Синхронизация в фоновом режиме помогает администратору поддерживать согласованность виртуальной инфраструктуры между платформой виртуализации и решением Basis Dynamix Cloud Control, что важно, например, при выполнении сервисных действий с серверами и дисками.</p> <p>Наконец, реализовано взаимодействие Basis Dynamix Cloud Control с платформой виртуализации Basis Dynamix Enterprise через учетную запись Basis Virtual Security — решения компании «Базис», предназначенного для защиты виртуальной инфраструктуры. </p> <p>В новом релизе Basis Dynamix Cloud Control особое внимание было уделено контролю над объёмом предоставляемых ресурсов, обеспечению предсказуемого потребления и оптимизации затрат. На уровне виртуального центра обработки данных (ВЦОД) введены лимиты и механизм согласования выделяемых ресурсов, дающие администраторам предсказуемый контроль над потреблением в рамках отдельных ВЦОД.</p> <p>Для облачных сегментов на платформе Basis Dynamix Enterprise реализовано управление коэффициентом и режимом переподписки виртуальных процессоров (vCPU), что позволяет администратору гибко регулировать плотность размещения виртуальных машин. Коэффициент переподписки определяет, сколько ядер vCPU будет приходиться на одно ядро физического процессора и отдельно указывается для каждого физического сервера. При отсутствии ограничений Basis Dynamix Cloud Control будет использовать для запуска виртуальных серверов любые узлы с достаточными ресурсами. При включенном режиме строгой переподписки виртуальные серверы не будут запускаться на физических узлах, если у тех недостаточно свободных ядер vCPU.</p> <p>Basis Automation Studio — это модуль Basis Dynamix Cloud Control, который представляет собой среду автоматизации развёртывания приложений и сервисов. С его помощью администратор платформы может управлять жизненным циклом облачных сервисов, работать с шаблонами и компонентами, публиковать готовые сервисы на витрине и предлагать их пользователям.</p> <p>Для Basis Automation Studio 3.0 одним из наиболее важных изменений стала смена архитектуры — модуль переведен на отказоустойчивую архитектуру в кластере Kubernetes. Компоненты Basis Automation Studio, включая контейнеры оркестратора и базу данных, работают в конфигурации высокой доступности: при выходе из строя отдельного узла нагрузка автоматически перераспределяется на оставшиеся узлы, работа платформы не прерывается. Для хранения общих данных используется распределенное отказоустойчивое хранилище, для базы данных — управление средствами оператора Kubernetes.</p> <p>Наряду с отказоустойчивостью появилось горизонтальное масштабирование: количество экземпляров ключевых сервисов задается при развертывании, что позволяет наращивать производительность платформы под растущую нагрузку без изменения ее архитектуры.</p> <p>Еще одним важным новшеством Basis Automation Studio 3.0 стало появление динамических провайдеров, которые предоставляют возможность создания динамических типов данных при заказе сервиса. Благодаря этому модуль может обращаться к внешним системам и возвращать в форму заказа вместо статичных полей актуальные данные, вычисляемые по пользовательским сценариям в изолированной среде выполнения.</p> <p>Динамические провайдеры отображаются на карточке домена и проекта. Внутри них дополнительно добавлен программный интерфейс управления динамическими типами провайдера для запуска пользовательских скриптов.</p> <p>Как и в Basis Dynamix Cloud Control, в модуле Basis Automation Studio 3.0 была переработана ролевая модель. Права доступа теперь задаются на уровне отдельных API-методов, сгруппированных по управляемым сущностям. Каждая роль привязана к области видимости: платформе, домену или проекту, — которая определяет предельный набор доступных действий. Пользователь привязывается к одной области видимости, но ему можно назначить несколько ролей, в том числе стандартных — в таком случае права доступа суммируются.</p> <p>«Приоритетными направлениями развития нашей облачной платформы Basis Dynamix Cloud Control остаются расширение возможностей управления виртуальной инфраструктурой и повышение совместимости облачного решения с другими продуктами экосистемы „Базиса“. В релизе 5.6 мы сделали несколько значительных шагов в обоих направлениях. Что касается нашего решения для управления облачными сервисами, перевод Basis Automation Studio на новую k8s-архитектуру позволит перемещать рабочую нагрузку без остановки работы продукта. Кроме того, для удобства работы с модулем мы внедрили динамические провайдеры и расширили возможности графического интерфейса платформы», — отметил Дмитрий Сорокин, технический директор компании «Базис».</p> Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — … message https://www.itweek.ru/themes/detail.php?ID=235375 Wed, 19 Aug 2026 14:20:12 +0300 <p>Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для своевременного выявления и реагирования на угрозы, связанные с компрометацией айдентити. Обновление расширяет сценарии применения многофакторной аутентификации, улучшает пользовательский опыт при работе в консоли администрирования и упрощает развертывание решения в корпоративной инфраструктуре.</p> <p>Сегодня для защиты корпоративной инфраструктуры недостаточно контролировать только доступ пользователя в систему. Не менее важно отслеживать дальнейшую активность учетных записей и своевременно реагировать на подозрительные действия. Эти возможности получили развитие в новой версии Indeed ITDR 2.2.</p> <p>Одно из ключевых нововведений в Indeed ITDR 2.2 — подтверждение дополнительного фактора входа с помощью одноразовых паролей (OTP), основанных на времени (time-based one-time passwords, TOTP). Обновление расширяет интеграцию с Indeed Access Manager и позволяет использовать существующую инфраструктуру аутентификации в сценариях Indeed ITDR.</p> <p>Поддержка ТOTP особенно актуальна для организаций с закрытыми инфраструктурами без доступа к внешним сетям, где использование push-уведомлений невозможно. Кроме того, пользователи могут применять сторонние приложения-аутентификаторы, поддерживающие стандарт TOTP.</p> <p>Ввод одноразового пароля выполняется через легковесное приложение, устанавливаемое на рабочих станциях под управлением Windows. Оно своевременно отображает запрос на подтверждение дополнительного фактора. В рамках дальнейшего развития продукта планируется добавить поддержку одноразовых паролей через SMS, электронную почту и физические носители.</p> <p>В версии 2.2 компания «Индид» значительно расширила возможности работы с журналом событий доступа. На странице «События» консоли администрирования появилась гибкая система фильтрации по пользователю, ресурсу, протоколу, IP-адресу и контроллеру домена. Также улучшен интерфейс фильтрации по времени возникновения события и оптимизировано хранение данных, что повышает производительность поиска.</p> <p>Обновленный интерфейс упрощает работу с Indeed ITDR и позволяет быстрее находить необходимые события при анализе подозрительной активности, расследовании инцидентов и оценке рисков безопасности. </p> <p>Другие изменения Indeed ITDR делают более удобным развертывание продукта в инфраструктурах, где интеграция с Indeed Access Manager не требуется.</p> <p>Компонент Indeed Key Server теперь можно установить на отдельный узел с помощью единого сценария установки. Это упрощает развертывание сервера в демилитаризованной зоне (DMZ) и избавляет администраторов от необходимости вручную изменять конфигурационные файлы.</p> <p>В новой версии расширен набор сценариев обнаружения атак. Indeed ITDR теперь выявляет такие техники, как Golden PAC и SAM Account Spoofing, что позволяет эффективнее обнаруживать попытки компрометации доменной инфраструктуры.</p> <p>Кроме того, улучшена совместимость с различными вариантами TLS-сертификатов, включая сертификаты LDAPS без расширения SAN, а также сертификаты с именем субъекта в формате Distinguished Name.</p> <p>«Мы последовательно улучшаем Indeed ITDR, расширяя сценарии внедрения продукта и добавляя новые возможности детектирования. Наша задача — помочь организациям своевременно реагировать на угрозы, связанные с учетными данными, не перестраивая существующую инфраструктуру. При этом для нас важно обеспечить удобство работы как для пользователей, так и для специалистов по информационной безопасности и администраторов. Последние обновления отражают наиболее частые пожелания, которые мы получаем в процессе внедрения наших продуктов», — отметил Лев Овчинников, руководитель продукта Indeed ITDR в компании «Индид».</p> Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для … message https://www.itweek.ru/themes/detail.php?ID=235374 Wed, 19 Aug 2026 14:16:20 +0300 <p>Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением стал встроенный Remote Access VPN (RA VPN), который позволяет организовать защищенный удаленный доступ пользователей к корпоративной сети. Кроме того, в новой версии расширены возможности маршрутизации и построения отказоустойчивых сетей, усовершенствованы управление политиками безопасности и удобство эксплуатации продукта.</p> <p>PT NGFW продолжает развиваться как единая платформа сетевой безопасности для высоконагруженных и территориально распределенных инфраструктур. Главная функция версии 1.11, Remote Access VPN, обеспечивает безопасное удаленное подключение сотрудников к внутренним ИТ-ресурсам организации непосредственно средствами межсетевого экрана, без внедрения отдельного VPN-решения. Настройка и управление параметрами RA VPN также осуществляется из единого окна PT NGFW.</p> <p>Благодаря поддержке раздельного туннелирования, через VPN можно направлять только корпоративный трафик пользователей, оставляя доступ к публичным и облачным сервисам напрямую через Интернет. Это снижает нагрузку на VPN-шлюз и каналы связи, повышая скорость и комфорт работы сотрудников. При этом трафик удаленных пользователей проходит через полный стек механизмов защиты межсетевого экрана, то есть организация может применять к удаленным подключениям те же политики безопасности, что и к сетевому взаимодействию внутри корпоративной инфраструктуры. Аутентификация удаленных пользователей происходит через RADIUS-сервер, что делает возможным не только централизованное управление правами доступа, но и применение второго фактора.</p> <p>Помимо защищенного удаленного доступа, PT NGFW 1.11 получил ряд возможностей, ориентированных на потребности крупных компаний с высоконагруженными и распределенными сетями. Среди них — поддержка технологии ECMP (Equal Cost Multi-Path), которая позволяет одновременно использовать несколько равнозначных маршрутов для передачи трафика. Это помогает эффективнее использовать пропускную способность каналов связи и сохранять передачу трафика при отказе одного из них.</p> <p>Кроме того, PT NGFW 1.11 расширяет сценарии подключения удаленных площадок и список совместимых сетевых устройств за счет возможности создания туннелей GRE и GRE over IPsec, в том числе с применением динамической маршрутизации.</p> <p>Еще одной возможностью, востребованной в высокопроизводительных сетях и центрах обработки данных, стала поддержка Jumbo Frames — увеличенного размера Ethernet-кадров. Благодаря этому можно передавать большие объемы данных меньшим количеством пакетов, снижая накладные расходы на их обработку. Максимальный размер пакета можно настраивать как для всего устройства, так и для отдельных интерфейсов. В совокупности новые возможности маршрутизации, туннелирования и работы с трафиком позволяют адаптировать PT NGFW к более широкому спектру архитектур крупных корпоративных сетей.</p> <p>В новой версии также появились функции, направленные на повышение удобства повседневной эксплуатации PT NGFW. В частности, добавлена поддержка подстановочных символов (wildcards) при настройке URL-фильтрации, благодаря чему весь процесс становится для администраторов быстрее и проще. Управление маршрутизацией тоже стало комфортнее: пользователь может настроить профили проверки доступности узлов, и в случае необходимости трафик автоматически, без ручного вмешательства пользователя переключится на резервный канал.</p> <p>«Мы продолжаем развивать PT NGFW с учетом обратной связи от заказчиков и их ежедневного опыта эксплуатации продукта. Для нас важно, чтобы межсетевой экран одинаково эффективно решал и стратегические задачи, такие как организация защищенного удаленного доступа или построение масштабной отказоустойчивой сетевой архитектуры, так и повседневные задачи администратора — от настройки политик до диагностики и работы с журналами», — отметил Антон Кузнецов, CPO компании «ТризТех».</p> Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением … message https://www.itweek.ru/themes/detail.php?ID=235373 Wed, 19 Aug 2026 14:10:57 +0300 <p>С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок. Для транспортных компаний это означает переход от бумажного документооборота к работе с электронными документами непосредственно на маршруте. Saby TMS позволяет оформлять и обрабатывать электронные транспортные документы и поддерживает удобный сценарий их подписания — с помощью Рутокен ЭЦП 3.0 NFC. Устройство Рутокен разработано и выпускается компанией «Актив».</p> <p>Раньше сотруднику, которому необходимо подписать ЭТрН КЭП, требовался компьютер или специальный переходник для подключения токена к смартфону. С Рутокен ЭЦП 3.0 NFC достаточно иметь смартфон с NFC и мобильное приложение Saby TMS.</p> <p>Сотрудник прикладывает Рутокен к смартфону и подписание документа происходит «на борту» устройства Рутокен, без копирования ключа подписи в память мобильного устройства. Такой сценарий особенно удобен водителям и экспедиторам, которым важно работать с документами прямо на маршруте, а не возвращаться в офис.</p> <p>«Для перевозчика важно, чтобы электронный документооборот не привязывал водителя к компьютеру или офису. Все действия с ЭТрН — от получения документа до его подписания — должны выполняться там, где происходит перевозка: на погрузке, выгрузке или в пути. Поддержка Рутокен ЭЦП 3.0 NFC в Saby TMS дает компаниям еще один удобный способ организовать такой мобильный сценарий и при этом использовать привычную КЭП», — отметил Денис Малышев, руководитель направления автоматизации логистики Saby TMS.</p> <p>«Мы видим тренд на мобильное подписание ЭТрН с использованием защищенных ключевых носителей. Рутокен ЭЦП 3.0 NFC позволяет перенести привычный сценарий работы с КЭП со стационарного компьютера на смартфон: достаточно приложить Рутокен к мобильному устройству с NFC для подписания документа. Совместимость с Saby TMS позволит использовать этот подход непосредственно в процессах грузоперевозок и дать бизнесу большую гибкость без компромиссов в безопасности», — поделился Анфимов Павел, заместитель директора по управлению продуктами, компания «Актив».</p> <p>В Saby TMS транспортные компании ведут основные документы — транспортные накладные, путевые листы, заказы на перевозку — прямо во время рейса.</p> <p>Для подписания через NFC понадобятся: смартфон с поддержкой NFC (iOS или Android), мобильное приложение Saby TMS и Рутокен ЭЦП 3.0 NFC с сертификатом и ключами электронной подписи.</p> С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок … message https://www.itweek.ru/themes/detail.php?ID=235372 Wed, 19 Aug 2026 13:09:40 +0300 <p><em>MWS Cloud (входит в МТС Web Services) проанализировала требования к вычислительной инфраструктуре для запуска ведущих мировых и российских больших языковых моделей. По оценке компании, средняя стоимость минимального набора ускорителей Nvidia для запуска одной модели выросла с 13,7 млн. рублей в 2025 году до 38,8 млн. рублей в 2026 году — в 2,8 раза.</em></p> <p>В анализ вошли популярные открытые модели, выпущенные весной и летом соответствующего года. Для 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.</p> <p>Расчёт сделан для минимального количества видеокарт, необходимого для запуска модели и обработки одного запроса максимального заявленного размера. В стоимость включены серверы с GPU и коммутаторы к ним.</p> <table> <tbody> <tr> <td> <p><strong>Год</strong></p> </td> <td> <p><strong>Наиболее популярный GPU</strong></p> </td> <td> <p><strong>Другие GPU</strong></p> </td> </tr> <tr> <td> <p>2025</p> </td> <td> <p>H100 — для трёх из шести моделей</p> </td> <td> <p>H200 — для двух моделей; A100 — для одной</p> </td> </tr> <tr> <td> <p>2026</p> </td> <td> <p>H200 — для трёх из семи моделей</p> </td> <td> <p>B300 — для двух моделей; H100 и A100 — ещё для двух</p> </td> </tr> </tbody> </table> <p><strong>Рейтинг моделей по стоимости запуска в 2025 году</strong></p> <table> <tbody> <tr> <td> <p><strong>Место</strong></p> </td> <td> <p><strong>Модель</strong></p> </td> <td> <p><strong>Количество параметров</strong></p> </td> <td> <p><strong>Минимальная конфигурация</strong></p> </td> <td> <p><strong>Стоимость</strong></p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>Kimi K2</p> </td> <td> <p>1 трлн (32 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 35 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>Qwen3</p> </td> <td> <p>235 млрд. (22 млрд. активных)</p> </td> <td> <p>4 × H200 141 Гб</p> </td> <td> <p>примерно 18 млн. рублей</p> </td> </tr> <tr> <td> <p>3</p> </td> <td> <p>GLM-4.5V</p> </td> <td> <p>106 млрд. (12 млрд. активных)</p> </td> <td> <p>минимум 4 × H100 80 Гб</p> </td> <td> <p>примерно 15 млн. рублей</p> </td> </tr> <tr> <td> <p>4</p> </td> <td> <p>Gemma 3</p> </td> <td> <p>27 млрд</p> </td> <td> <p>2 × H100 80 Гб</p> </td> <td> <p>примерно 7,5 млн. рублей</p> </td> </tr> <tr> <td> <p>5</p> </td> <td> <p>gpt-oss</p> </td> <td> <p>117 млрд. (5,1 млрд. активных)</p> </td> <td> <p>1 × H100 80 Гб</p> </td> <td> <p>более 3,5 млн. рублей</p> </td> </tr> <tr> <td> <p>6</p> </td> <td> <p>Cotype Pro 2</p> </td> <td> <p>32 млрд</p> </td> <td> <p>1 × A100 80 Гб</p> </td> <td> <p>примерно 3 млн. рублей</p> </td> </tr> </tbody> </table> <p><strong>Рейтинг моделей по стоимости запуска в 2026 году</strong></p> <table> <tbody> <tr> <td> <p><strong>Место</strong></p> </td> <td> <p><strong>Модель</strong></p> </td> <td> <p><strong>Количество параметров</strong></p> </td> <td> <p><strong>Минимальная конфигурация</strong></p> </td> <td> <p><strong>Стоимость</strong></p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>Kimi K3</p> </td> <td> <p>2,8 трлн (104 млрд. активных)</p> </td> <td> <p>8 × B300 288 Гб</p> </td> <td> <p>примерно 80 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>Qwen3.5</p> </td> <td> <p>397 млрд. (17 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>DeepSeek-V4-Pro</p> </td> <td> <p>1,6 трлн (49 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>GLM-5.2</p> </td> <td> <p>744 млрд. (около 40 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>5</p> </td> <td> <p>DeepSeek-V4-Flash</p> </td> <td> <p>284 млрд. (13 млрд. активных)</p> </td> <td> <p>1 × B300 288 Гб</p> </td> <td> <p>примерно 10 млн. рублей</p> </td> </tr> <tr> <td> <p>6</p> </td> <td> <p>Gemma 4</p> </td> <td> <p>31 млрд</p> </td> <td> <p>2 × H100 80 Гб</p> </td> <td> <p>примерно 7,5 млн. рублей</p> </td> </tr> <tr> <td> <p>7</p> </td> <td> <p>Cotype Pro 3</p> </td> <td> <p>27 млрд</p> </td> <td> <p>1 × A100 80 Гб</p> </td> <td> <p>примерно 3 млн. рублей</p> </td> </tr> </tbody> </table> <p>Новые LLM становятся более мощными: они лучше справляются со сложными задачами и могут учитывать больше информации в одном запросе. Однако для этого им требуется больше памяти и более производительные GPU. При этом растёт и стоимость самих видеокарт, поэтому развёртывание моделей обходится дороже.</p> <p>Отдельно MWS Cloud оценила возможные конфигурации на китайских ускорителях Huawei Ascend 910B. Возможность запуска на них подтверждена не для всех рассмотренных LLM: в выборке 2025 года подтверждение есть для трёх из шести моделей, в 2026 году — для пяти из семи.</p> <p>Среди моделей с подтверждённой или экспериментально подтверждённой поддержкой Huawei в 2025 году в среднем требовалось 10,7 ускорителя Ascend 910B, а в 2026 году — 13,6. Официальной цены на данные GPU нет, но, по оценкам, она может составлять от половины до двух третей стоимости сопоставимых GPU Nvidia.</p> <p>«Цены на GPU в России во многом зависят от мирового рынка: глобальная гонка в области ИИ увеличивает спрос на вычислительные мощности и поддерживает рост стоимости ускорителей. По данным исследования MWS Cloud, 47% респондентов ожидают удорожания GPU-ресурсов в ближайшие 12 месяцев, а 45% считают, что их значение для бизнеса будет расти. Развёртывать крупные модели на собственной инфраструктуре становится дороже, однако единого ценового предела, после которого рынок потеряет интерес к ИИ, нет: если покупка оборудования перестаёт окупаться, компании выбирают более компактные модели, оптимизируют вычисления или переходят в облако, где можно платить только за фактически используемые мощности. Один из индикаторов этого сдвига — рост облачного потребления ИИ-моделей: по оценке MWS Cloud, в первом полугодии 2026 года потребление китайских LLM российскими компаниями на платформах MWS GPT Model Hub и MWS GPT более чем в 11 раз превысило показатель за весь 2025 год», — отметил генеральный директор MWS Павел Воронин</p> MWS Cloud (входит в МТС Web Services) проанализировала требования к вычислительной инфраструктуре для запуска ведущих … message https://www.itweek.ru/themes/detail.php?ID=235371 Wed, 19 Aug 2026 11:57:58 +0300 <p><em>Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир, наблюдаемая в последние годы, в 2025 году имела продолжение — снова выявлено очевидное снижение продаж на рынках недружественных стран. А вот столь же очевидного увеличения реализации продуктов и услуг в дружественных странах пока не видно. В то же время, на переохлажденном российском ИТ-рынке с возросшей налоговой нагрузкой компаниям становится слишком тесно. В такой ситуации логично предположить их движение в тех направлениях, которые открыты для международной экспансии.</em></p> <p>Направление в сторону недружественных стран сложно назвать перспективным. При всем желании российских компаний-разработчиков ПО сохранить продажи в Европе и Северной Америке, западные политики без устали работают над созданием непреодолимых для них препятствий. Многие их задумки реализуются, хотя при этом западные страны лишают свои предприятия и граждан доступа к качественным услугам и продуктам.</p> <p>По итогам 2025 года продажи отечественных софтверных компаний на рынках недружественных стран сократились примерно на 40% до ₽70 млрд. Сейчас страны Европы и США обеспечивают 2,4% совокупной выручки всей индустрии разработки ПО. При этом доля компаний, имеющих продажи в недружественных странах, намного больше — 14,3% от всех опрошенных компаний. Для Европы этот показатель равен 9,9%, а для США и Канады — 8,8% (в 2024 г. было 14,2% и 11,4% соответственно).</p> <p>Однако дальнейший уход с рынков западных стран столь же массово, как в предыдущие годы, компании не планируют. Сохранить присутствие на рынке Северной Америки в 2026 году рассчитывает 9,2%, что чуть больше, чем было по итогам 2025 года. Не исключено, что шансы остаться на одном из крупнейших рынков мира повысились, когда респонденты увидели потепление отношений между Россией и США после встречи в Анкоридже. Такой же эффект произвела в свое время победа Дональда Трампа на американских президентских выборах. Он вступил в должность в январе 2025 года, и вскоре стало известно о планах его встречи с Президентом РФ В.В. Путиным, которая состоялась в августе. С Европой все было хуже, ведь от них шли сигналы только на еще больший разрыв.</p> <p>Продажи в дружественных странах дальнего зарубежья в 2025 году в рублях не изменились и составили примерно ₽170 млрд. При этом доля этих продаж в совокупной выручке софтверных компаний упала — с 6,8% до 6,1%. Укрепление российской национальной валюты по отношению к доллару не позволило нарастить выручку в рублевом выражении. Однако в долларовом выражении продажи в дружественные страны все же увеличились примерно на 10%. Это касается как всего экспорта софтверных компаний, так и их продаж на рынках дружественных стран.</p> <p>Ближнее зарубежье обеспечило по итогам 2025 года 10,2% совокупной выручки российских разработчиков ПО. Годом ранее его доля была чуть меньше — 9,8%. Продажи на постсоветском пространстве выросли примерно на <nobr>18-19%</nobr> в рублевом выражении (до ₽285 млрд) и примерно на 32% в долларах ($3,4 млрд). Указали на наличие продаж в этих странах 36,1% опрошенных компаний. На данный момент Ближнее зарубежье обеспечивает более половины экспорта российских софтверных компаний.</p> <p><strong>Распределение продаж российских софтверных компаний по группам рынков в <nobr>2021-2025</nobr> годы</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2021</p> </td> <td> <p>2022</p> </td> <td> <p>2023</p> </td> <td> <p>2024</p> </td> <td> <p>2025</p> </td> </tr> <tr> <td> <p>Россия</p> </td> <td> <p>52,5%</p> </td> <td> <p>65,6%</p> </td> <td> <p>76,2%</p> </td> <td> <p>78,6%</p> </td> <td> <p>81,3%</p> </td> </tr> <tr> <td> <p>Ближнее зарубежье</p> </td> <td> <p>13,45%</p> </td> <td> <p>11,5%</p> </td> <td> <p>10,2%</p> </td> <td> <p>9,8%</p> </td> <td> <p>10,2%</p> </td> </tr> <tr> <td> <p>Россия и Ближнее зарубежье</p> </td> <td> <p>65,95% </p> </td> <td> <p>77,1%</p> </td> <td> <p>86,35%</p> </td> <td> <p>88,4%</p> </td> <td> <p>91,5%</p> </td> </tr> <tr> <td> <p>Дальнее зарубежье:</p> </td> <td colspan="5"> </td> </tr> <tr> <td> <p>— недружественные страны (до 2022 г. «Западный мир»)</p> </td> <td> <p>25,25%</p> </td> <td> <p>12,5%</p> </td> <td> <p>7,6%</p> </td> <td> <p>4,8%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>— дружественные страны (до 2022 г. «Новые рынки»)</p> </td> <td> <p>8,8%</p> </td> <td> <p>10,4%</p> </td> <td> <p>6,05%</p> </td> <td> <p>6,8%</p> </td> <td> <p>6,1%</p> </td> </tr> </tbody> </table> <p>Согласно прогнозу, основанному на планах опрошенных компаний, по итогам 2026 года российские софтверные компании увеличат свое присутствие с реальными продажами почти на всех рынках. Предполагается, что даже в США будут продавать свои продукты и услуг больше компаний, чем было в 2025 году. Падение присутствия российских экспортеров прогнозируется только на рынке Европы. Прогнозируя расширение географии и рост экспорта, необходимо признать, что опыт предыдущих лет показывает, что ожидания компаний относительно роста экспорта часто оказываются несколько завышенными.</p> <p><strong>Присутствие российских компаний на зарубежных рынках в 2025 году с прогнозом на 2026 год, %</strong> <strong>опрошенных компаний</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Ближнее зарубежье</p> </td> <td> <p>36,1%</p> </td> <td> <p>40,5%</p> </td> </tr> <tr> <td> <p>Казахстан</p> </td> <td> <p>22,1%</p> </td> <td> <p>25,2%</p> </td> </tr> <tr> <td> <p>Белоруссия</p> </td> <td> <p>20,7%</p> </td> <td> <p>24,8%</p> </td> </tr> <tr> <td> <p>Узбекистан</p> </td> <td> <p>15,0%</p> </td> <td> <p>18,7%</p> </td> </tr> <tr> <td> <p>Европа (без России и Ближнего зарубежья)</p> </td> <td> <p>9,9%</p> </td> <td> <p>8,5%</p> </td> </tr> <tr> <td> <p>США/Канада</p> </td> <td> <p>8,8%</p> </td> <td> <p>9,2%</p> </td> </tr> <tr> <td> <p>Южная и Восточная Азия</p> </td> <td> <p>7,5%</p> </td> <td> <p>7,8%</p> </td> </tr> <tr> <td> <p>— Китай</p> </td> <td> <p>3,1%</p> </td> <td> <p>3,4%</p> </td> </tr> <tr> <td> <p>— Индия</p> </td> <td> <p>5,4%</p> </td> <td> <p>6,1%</p> </td> </tr> <tr> <td> <p>— Вьетнам</p> </td> <td> <p>1,7%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>— Индонезия</p> </td> <td> <p>2,0%</p> </td> <td> <p>3,1%</p> </td> </tr> <tr> <td> <p>Ближний Восток</p> </td> <td> <p>6,5%</p> </td> <td> <p>7,8%</p> </td> </tr> <tr> <td> <p>Южная и Центральная Америка</p> </td> <td> <p>2,7%</p> </td> <td> <p>3,1%</p> </td> </tr> <tr> <td> <p>Бразилия</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Мексика</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,0%</p> </td> </tr> <tr> <td> <p>Аргентина</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Африка</p> </td> <td> <p>3,1%</p> </td> <td> <p>3,7%</p> </td> </tr> <tr> <td> <p>Австралия/Новая Зеландия</p> </td> <td> <p>1,4%</p> </td> <td> <p>1,7%</p> </td> </tr> </tbody> </table> <p>Несмотря на все препятствия, по итогам 2026 г. зарубежные продажи российских софтверных компаний все же могут вырасти более чем на 10% в долларовом выражении (с учетом той выручки, которая может остаться за пределами России).</p> <p>Однако для достижения уровня мировой конкурентоспособности, требующего огромных инвестиций, доходов от российского рынка будет недостаточно, и к нему необходимо будет прибавить выручку экспорта, которая должна быть как минимум, в разы больше, чем текущий доход от зарубежных продаж. По результатам исследования РУССОФТ, в 2025 году объем зарубежных продаж составил $6,3 млрд, а по итогам 2026 г. может достигнуть $7 млрд. При имеющемся темпе роста преодолеть планку в $40 млрд. удастся не ранее 2040 года, а к этому времени нынешние ориентиры уже будут не актуальны.</p> <p>Для наращивания экспорта можно рассчитывать, в первую очередь, на рост продаж на Ближнем зарубежье. Однако, хотя потенциал этого рынка еще не исчерпан, он в любом случае не принесет десятки миллиардов долларов. Для сравнения, один только индийский рынок может обеспечить продажи на порядок больше, чем все постсоветское пространство. Перспективными для освоения являются также рынки стран АСЕАН, прежде всего — Индонезии и Вьетнама. Более активной работе на Ближнем Востоке может помешать война. Большой интерес представляют страны Латинской Америки, но транспортные расходы и риски освоения еще непознанных рынков слишком велики.</p> <p>Для обеспечения прорыва на рынках дружественных стран необходимо устранять проблемы экспортеров, вызванные повышением налоговой нагрузки, которая к тому же может и не дать дополнительных поступлений в бюджет. Необходимо также повышать эффективность государственной поддержки экспорта ПО и услуг по его разработке, которую сейчас сложно признать высокой. До сих пор он не является приоритетом ни одной государственной программы и потому не может пользоваться финансовыми мерами поддержки инструментов Российского экспортного центра (кредиты покупателям, страхование поставок и предоставление гарантий Росэксимбанка для экспортных поставок).</p> <p>Стоит отметить, что сейчас отсутствуют показатели эффективности государственной политики в области развития ИТ-экспорта, поэтому приходится делать только общие предположения. Опрос РУССОФТ в рамках ежегодного Исследования софтверной индустрии показывает, что компании, которые уже присутствуют на зарубежных рынках, оценивают «Стимулирование экспорта ИТ государственными структурами и институтами» в целом удовлетворительно, но не очень высоко, даже в сравнении с другими направлениями государственной поддержки. В 2025 году опрошенные компании в среднем оценили стимулирование экспорта государством на 3,15 балла по <nobr>5-балльной</nobr> системе, а при опросе в 2026 году этот показатель снизился до 3,01.</p> <p>Чтобы обеспечить рост зарубежных продаж до величины $40 млрд, необходимо начать со сбора полной информации о том, чего ждут экспортеры от государства и что их не устраивает. Затем уже формулировать или корректировать стратегию комплексной поддержки ИТ-экспорта, и прежде всего — признать экспорт ПО и услуг в качестве приоритета государственной поддержки экспорта в одной из Национальных программ развития.</p> <p>В принципе, проблемы на западных рынках в том или ином виде можно было предположить лет 15 назад, как и необходимость наращивания продаж в развивающихся странах для обеспечения технологического суверенитета. Не хватало стратегического видения и системного критического анализа. РУССОФТ в своих отчетах и пресс-релизах предлагал уделять больше внимания рынкам развивающихся стран, начиная с 2008 года. Современная ситуация толкает нас к тому, чтобы совместными усилиями с государственными структурами сформулировать стратегию развития экспорта софтверной индустрии и ИТ-экспорта в целом и закрепить за Россией статус одного из мировых технологических лидеров.</p> Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир … message https://www.itweek.ru/themes/detail.php?ID=235368 Wed, 19 Aug 2026 09:30:08 +0300 <p><em>Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому, что организации пытаются перейти к оркестрации до того, как моделирование заслужит операционное доверие, пишет в корпоративном блоге Сара Ли, старший директор </em><em>IDC</em> <em>по исследованиям ИТ-стратегий в производстве.</em></p> <p>Цифровые двойники превращаются из инструментов визуализации в операционную основу физического искусственного интеллекта на производственном участке, и этот термин теперь охватывает две возможности, которые часто рассматриваются как одно целое. <em>Моделирование</em> подтверждает изменения до того, как они достигнут производства. <em>Оркестрация</em> координирует выполнение в реальном времени машинами, системами ИИ и работниками.</p> <p>Какую возможность производитель создаст первой и насколько она будет обоснована, прежде чем перейти ко второй, часто определяет масштабируемость программы.</p> <p>Согласно отчету IDC «Industry Market Trends: Worldwide Manufacturing, 2026», примерно 57% производственных предприятий имеют инициативы в области ИИ, застрявшие на стадии проверки концепции, при этом менее половины демонстрируют измеримые результаты.</p> <p>Программы реализации цифровых двойников находятся в той же ситуации.</p> <h3>Моделирование: проверка изменений до того, как они достигнут производственного цеха</h3> <p>В этой роли цифровые двойники моделируют поведение процессов, производительность оборудования и конфигурации продукции, сочетая физические и основанные на данных модели, а также гибридные подходы, объединяющие инженерный опыт с операционными данными. Традиционная аналитика объясняет, что уже произошло. Моделирование позволяет производителям изучить, что может произойти дальше — это становится все более важным, поскольку автоматизация и роботизация повышают стоимость неудачных изменений.</p> <p>Сценарии применения различаются в зависимости от отраслевой структуры. Процессные производства моделируют отдельные технологические операции и переходы между партиями — прогнозируют производительность линий отбеливания на целлюлозно-бумажных комбинатах, моделируют загрязнения теплообменников на химических заводах или симулируют ферментацию в производстве напитков. Дискретные производства работают на уровне ячеек и линий: виртуальный ввод в эксплуатацию роботизированных ячеек до прибытия оборудования на место, балансировка времени такта при сборке смешанных моделей и генерация синтетических данных для обучения моделей визуального контроля.</p> <p>Возможности одинаковые, единицы анализа разные. Программы, заимствующие эталонную архитектуру с не той стороны этого разделения, как правило, застревают на структуре данных задолго до того, как застрянут на моделировании.</p> <h3>Оркестрация: превращение интеллекта в скоординированные действия</h3> <p>В этой роли цифровые двойники объединяют данные реального времени с датчиков, контрольных систем и систем управления производственными процессами для координации решений между машинами, агентами ИИ и работниками. Области применения включают координацию парков автономных мобильных роботов (AMR) и автоматизированных транспортных средств (AGV), динамическое балансирование производственных линий, управление энергетическими нагрузками в системах коммунального хозяйства и диспетчеризацию мероприятий по техническому обслуживанию или контролю качества в зависимости от изменяющихся условий.</p> <p>По мере внедрения агентного ИИ в производственную среду оркестрация становится средой выполнения, определяющей, какой агент действует, когда и в каких границах. Производители уже консервативно устанавливают эти границы.</p> <p>Согласно опросу IDC «2026 Agentic AI Functional Use», примерно 43% респондентов из производственной отрасли сообщают, что их агенты либо не обладают полномочиями по принятию решений, либо требуют одобрения человека для каждого решения. Только 8,5% допускают полную автономию по любому критически важному вопросу. В то же время 62,5% сообщают, что расширение автономии агентов находится в стадии активного рассмотрения.</p> <p>Устранение этого разрыва — это та работа, которую должна выполнить оркестрация.</p> <h3>Почему последовательность не является необязательной</h3> <p>Моделирование отдает приоритет точности прогнозирования и экспериментам в автономном режиме. Оркестрация отдает приоритет задержке, надежности и интеграции с системами управления и выполнения. Объединение их в единую программу обычно означает, что один набор требований уступает другому, и редко бывает очевидно заранее, какой именно.</p> <p>Доверие не предоставляется по запросу. Операторам и инженерам необходимы доказательства того, что модель отражает реальные условия работы предприятия, прежде чем они начнут действовать в соответствии с ее рекомендациями, и задолго до того, как они позволят агенту действовать от их имени. Трех ложных срабатываний за квартал обычно достаточно, чтобы операторы перестали открывать дашборд.</p> <p>Искушение перейти непосредственно к оркестрации понятно. Координация роботов, агентов ИИ и производственных систем обещает видимые операционные преимущества. Но без проверенного цифрового представления производства организации рискуют ускорить принятие решений, которым они еще не научились доверять.</p> <p>Программы, дающие результаты, начинаются с принятия операционного решения, а не с выбора технологии. Независимо от того, является ли целью выход годной продукции с первого раза, время переналадки, доступность активов или энергоемкость, это решение принимается в первую очередь. Что именно должен обеспечивать цифровой двойник?</p> <h3>От моделей мира к цифровым двойникам и физическому ИИ</h3> <p>По мере того, как производители готовятся к внедрению физического ИИ, различие между общим интеллектом и оперативным интеллектом становится все более важным.</p> <p>Модели мира дают системам ИИ широкое понимание того, как ведет себя физическая среда. Цифровые двойники обеспечивают промышленную специфику, которой не хватает этим моделям: геометрию предприятия, параметры процессов, логику управления и историю эксплуатации.</p> <p>Вместе они создают основу для более надежного физического ИИ. Модель мира может понимать, как ведут себя объекты и силы в целом, но цифровой двойник обеспечивает контекст, необходимый для определения того, является ли действие безопасным и эффективным на конкретном производстве, на конкретной линии, с конкретными материалами и ограничениями.</p> <h3>Что требуется для масштабирования</h3> <p>Ограничения должны быть согласованы между процессными и дискретными средами.</p> <p>Точность двойника зависит от точности потребляемых им данных. Без непрерывной синхронизации он превращается в устаревшее представление, которое обладает авторитетом модели, но не ее точностью.</p> <p>Безопасность становится все более важной по мере того, как двойники расширяют связность в операционных средах. Соединение инженерных моделей, систем ИИ и управления производством расширяет поверхность атаки и требует обеспечения безопасности на этапе проектирования для архитектуры, связности и управления.</p> <p>Работа также меняется по мере того, как двойники и агенты получают все больше возможностей принятия решений. Операторы и технические специалисты переходят от выполнения рутинных задач к контролю за системами, проверке рекомендаций и управлению исключениями. Это требует четкого определения ролей и путей эскалации, поскольку одних дополнительных часов обучения недостаточно для устранения этого пробела.</p> <p>Успешные программы цифровых двойников редко являются исключительной прерогативой ИТ-службы. Они требуют сотрудничества между операционными, инженерными, операционными группами, группами обработки данных и функциями управления ИИ. По мере того, как двойники эволюционируют из инженерных инструментов в платформы для принятия операционных решений, определение ответственности становится столь же важным, как и архитектура.</p> <h3>Вопрос, который стоит изучить производителям</h3> <p>Для руководителей операционных подразделений реальный вопрос заключается в том, достаточно ли развиты аспекты фундамента данных, проверки моделей, доверия операторов и управления, чтобы перейти на следующую ступень: от визуализации к автономному моделированию и далее к замкнутой системе оркестрации и к принятию агентами автономных решений.</p> <p>Переход на каждую следующую ступень должна быть обеспечен подтвержденными результатами на предыдущей.</p> <p>Программы, которые пропускают ступень, не движутся быстрее. Они застревают из-за отсутствия доверия модели, а доверие восстановить сложнее, чем исправить модель.</p> Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому … article https://www.itweek.ru/themes/detail.php?ID=235366 Wed, 19 Aug 2026 09:10:34 +0300 <p>ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий на ограниченной группе пользователей. Но в промышленной эксплуатации с нагрузкой дела обстоят иначе. По оценке IDC, глобальные расходы на ИИ-инфраструктуру в 2026 году <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/">достигнут</a> 487 млрд. долл., прибавив около 53% за год. Такой рост показывает простую вещь: инфраструктура становится одной из главных статей ИИ-бюджета, а не технической деталью на стороне ИТ.</p> <p>При этом сама по себе закупка мощностей ничего не гарантирует — можно купить дорогие карты и получить простои. Поэтому компании, которые выводят ИИ из пилота, начинают адаптировать не один сервер, а весь контур: от профиля нагрузки до метрик, безопасности и финансового учета.</p> <p>Рассмотрим, как адаптировать инфраструктуру под новые нагрузки и почему недостаточно просто приобрести GPU.</p> <h3>Сначала сценарий, потом железо</h3> <p>Выражение «ИИ-инфраструктура» звучит так, будто речь идет об одном типе нагрузки — но на деле под ним скрываются разные задачи: обучение модели с нуля, дообучение, классический ML, генерация эмбеддингов. И у каждой задачи — свои узкие места, например голосовому ассистенту важна низкая задержка ответа, а для аналитики критична стоимость обработки большого объема данных.</p> <p>Поэтому зрелые компании начинают с классификации сценариев. Они отвечают на несколько простых вопросов:</p> <ul> <li> кто будет пользоваться искусственным интеллектом;</li> <li> сколько запросов ожидается;</li> <li> насколько важна скорость первого ответа;</li> <li> какой объем контекста нужен;</li> <li> можно ли обрабатывать запросы пакетно;</li> <li> что происходит при задержке.</li> </ul> <p>Без этого закупка «железа под ИИ» превращается в лотерею — инфраструктура может и не выдержать реальный сценарий.</p> <h3>Не всем нужен собственный обучающий кластер</h3> <p>Многие компании по инерции думают об ИИ-инфраструктуре как о кластере для обучения моделей. На практике большинству организаций он не нужен — у них нет ни объема данных, ни задач, ради которых стоит учить модель с нуля.</p> <p>Для внутренних ассистентов, поиска по базе знаний, обработки обращений, подготовки документов и поддержки разработчиков лучше идти другим, более простым путем. Достаточно взять готовую модель, развернуть ее у себя или провайдера, подключить корпоративные данные и настроить инференс.</p> <p>«Спроектировать инференс-платформу» звучит не так эффектно, как «построить суперкомпьютер» — зато это ближе к реальным задачам бизнеса.</p> <h3>GPU недостаточно просто купить — нужно научиться использовать</h3> <p>Самая дорогая ошибка — считать, что проблема решается количеством карт. В действительности GPU часто простаивают, в то время как команды жалуются на нехватку мощностей.</p> <p>Это видно и по рынку: в отчете Cast AI за 2026 год средняя утилизация GPU в Kubernetes-кластерах <a href="https://cast.ai/reports/kubernetes-optimization-report/">составила</a> всего 5%. Проблема эта редко связана с плохой организацией — чаще всего она структурная. В Kubernetes GPU в большинстве случаев воспринимается как неделимая единица: приложение запросило карту — получило ее целиком, а использует только часть мощности. В итоге дорогое оборудование формально занято, а фактически не загружено.</p> <p>Компании решают этот вопрос несколькими способами, например делят карту на изолированные части или выбирают инференс-серверы, которые умеют эффективнее упаковывать запросы.</p> <h3>Карты без сети и хранилища тоже простаивают</h3> <p>ИИ-нагрузки быстро показывают, что GPU — лишь часть инфраструктуры. Если данные и веса модели не успевают подаваться на узел, карта ждет. Бизнес при этом платит за дорогое оборудование, которое не делает полезной работы.</p> <p>Для больших моделей это становится отдельной инженерной задачей. Модель на 70 млрд. параметров в FP8 может весить около 70 Гб, а флагманские модели — сотни гигабайт. Их нужно быстро доставлять, хранить, обновлять и переиспользовать между узлами.</p> <p>Поэтому инфраструктура под ИИ должна включать сеть, хранилище, интерконнект, параллельную файловую систему и механику доставки весов. Если этого не сделать, компания покупает не мощность, а дорогую очередь ожидания.</p> <h3>Обычные метрики не показывают качество ИИ-сервиса</h3> <p>Классический мониторинг приложений плохо описывает ИИ-нагрузку. Для <nobr>LLM-инференса</nobr> важны другие показатели: time to first token, inter-token latency, throughput, tokens per second, запросы в секунду и стоимость обработки. NVIDIA в документации по benchmarking для LLM отдельно <a href="https://docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html">выделяет</a> такие метрики как TTFT, ITL, TPS и end-to-end latency.</p> <p>Важно, что эти показатели нельзя оптимизировать для всех сценариев. Голосовому боту важен быстрый первый ответ, batch-аналитике — минимальная стоимость обработки. Поэтому зрелые команды задают SLO под конкретную ситуацию: для кого работает ИИ, какая задержка допустима, сколько компания готова платить за миллион токенов.</p> <h3>Модель нельзя встраивать напрямую в каждое приложение</h3> <p>Быстрый путь — подключить LLM прямо к монолиту или внутреннему порталу. На пилоте это удобно, однако в промышленной эксплуатации такой подход становится дорогим.</p> <p>Почему это происходит:</p> <ul> <li> становится сложнее переключить провайдера;</li> <li> приложение оказывается привязано к конкретной модели;</li> <li> почти невозможно нормально рассчитать расходы по командам;</li> <li> промпты и ответы выпадают из общего мониторинга.</li> </ul> <p>Рабочий вариант в таком случае — вынести работу с моделями в отдельный слой, ИИ-шлюз. Он становится единой точкой для квот, логирования, PII-фильтрации, кэширования, переключения моделей и контроля расходов.</p> <h3>RAG требует архитектуры доступа</h3> <p>RAG часто становится первым массовым корпоративным ИИ-сценарием: компания подключает документы, базы знаний, инструкции и хочет, чтобы сотрудники задавали вопросы на естественном языке. Однако вместе с пользой возникает и новый риск.</p> <p>Если права пользователя не участвуют в самом поисковом запросе, а фильтрация происходит уже после извлечения документов, векторная база превращается в канал переноса информации между отделами — быстрый, удобный и не оставляющий следов в привычных журналах доступа. Надеяться на фильтрацию постфактум нельзя, так как она регулярно пропускает содержимое чужих документов в ответы.</p> <p>Именно поэтому в корпоративном RAG роль, права доступа и подразделение пользователя должны быть частью самого запроса к индексу. Если гарантировать это архитектурно не получается, корпус должен сужаться до публичных документов — сегодня других надежных и безопасных вариантов тут нет.</p> <h3>Стоимость нужно считать в токенах с первого дня</h3> <p>ИИ-инфраструктура меняет привычный финансовый учет ИТ. Раньше компания считала серверы, лицензии, облачные ресурсы и человеко-часы. В ИИ-сервисах новой единицей стоимости становится токен.</p> <p>На пилоте это легко недооценить — слишком мало пользователей и запросов. В промышленной эксплуатации растут конкурентность, длина контекста, число пользователей, резервирование и объем логирования. Стоимость начинает расти нелинейно.</p> <p>Подсчет токенов нужен с первого дня. Компания должна понимать, кто генерирует расходы, какие сценарии самые дорогие, где можно кэшировать ответы, где подойдет более дешевая модель, а где оправдана премиальная.</p> <h3>Платформа лучше разрозненных запусков</h3> <p>Один из частых антипаттернов — когда каждый отдел сам разворачивает модель. На старте это кажется отличной возможностью не тормозить команды, однако вскоре компания получает дублирование расходов, разный уровень безопасности, отсутствие прозрачности и несколько точек риска.</p> <p>Но зрелая схема устроена иначе. Есть единый платформенный слой: инфраструктура, ИИ-шлюз, квоты, аудит, мониторинг, безопасность и SLA. Продуктовые команды отвечают за свои сценарии — промпты, корпус знаний, качество ответов, бизнес-эффект.</p> <p>Отдельный признак зрелости системы — оценка качества, evals. Без «золотого» набора примеров и регрессионного прогона невозможно ответить на вопрос, стало ли лучше после смены промпта или модели — и таким образом решения принимаются лишь на ощущениях.</p> <p>Зрелые команды относятся к промпту как к артефакту релиза: он версионируется, выкатывается постепенно и откатывается при деградации. Важно тут то, что закладывать evals нужно с первого дня, так как задним числом их уже не собрать. Так искусственный интеллект становится частью корпоративной архитектуры, переставая быть набором локальных экспериментов.</p> <h3>Подведем итоги</h3> <p>Адаптация ИТ-инфраструктуры под ИИ-нагрузки начинается с понимания сценариев: кому нужен искусственный интеллект, как часто, на каких данных, с какими рисками и за какие деньги.</p> <p>Компании, которые проходят этот путь осознанно, проектируют управляемый контур — инференс-платформу, правильные метрики, ИИ-шлюз, безопасный RAG, подсчет токенов и единые правила для всех команд. Не нужно делать его максимальным, перегружать всем и сразу — достаточно контроля, ясности и обратимости, то есть готовности сменить модель или провайдера, когда профиль нагрузки изменится.</p> <p>#IMAGE_235367#</p> ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий … article Султан Рамазанов, директор по искусственному интеллекту Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235363 Tue, 18 Aug 2026 15:56:55 +0300 <p>Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX) и менеджера паролей Пассворк.</p> <p>Корректность совместной работы решений подтверждена сертификатом, выданным по результатам испытаний. Эта совместимость закрывает конкретную задачу заказчиков: организовать вход в менеджер паролей через уже действующую в компании систему усиленной аутентификации без создания отдельных учётных данных. Таким образом, пользователю не нужно запоминать ещё один пароль или носить отдельный токен для доступа к хранилищу — он проходит аутентификацию через сервис JaCarta Identity Provider (JIP), входящий в JMS4LX.</p> <p>JaCarta Management System 4LX для Linux — это система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами. В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) — провайдер аутентификации/авторизации в приложения с поддержкой протоколов SAML и OIDC. </p> <p>Пассворк — это российский корпоративный менеджер паролей и секретов с возможностью развёртывания на собственном сервере заказчика или в облаке. Решение предназначено для безопасного хранения, управления и совместного использования учётных данных внутри компаний. Пассворк поддерживает ролевую модель доступа, полный аудит действий, интеграцию со службами каталогов и системами мониторинга безопасности. Пассворк включён в Единый реестр российского программного обеспечения (№ 6147 от 13.01.2020) и сертифицирован ФСТЭК России по <nobr>4-му</nobr> уровню доверия (№ 5063 от 30.04.2026).</p> <p>«Заказчики, которые строят ИТ-инфраструктуру на отечественных решениях, должны быть уверены: продукты работают вместе корректно и без доработок. Сертификат даёт эту уверенность на уровне вендоров: совместимость Пассворка и JMS4LX зафиксирована документально, протестирована и будет поддерживаться», — прокомментировал Андрей Пьянков, генеральный директор «Пассворк».</p> <p>«Подтверждение совместимости JMS4LX и Пассворка позволяет заказчикам использовать уже существующую инфраструктуру аутентификации для доступа к менеджеру паролей. Для компаний, где JIP уже используется в качестве корпоративного SSO, это означает, что сотрудникам не нужно заводить отдельные учётные данные для Пассворка», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».</p> Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного … message https://www.itweek.ru/themes/detail.php?ID=235362 Tue, 18 Aug 2026 15:20:16 +0300 <p>Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии десктопного и мобильного клиентских приложений. Релиз завершает этап бета-тестирования и переводит продукт на новую ступень готовности. Обновление включает более 20 новых функций, реализованных в постоянном диалоге с пользователями: изменения коснулись календаря, редактора написания письма, доступа к учетным записям и новых функций безопасности.</p> <p>Релиз направлен на решение трех задач — ускорение совместной работы, повышение прозрачности коммуникаций и упрощение рутинных операций.</p> <p>Пользователи получили возможность делиться своим расписанием с внешними партнерами или клиентами через публичные ссылки — теперь для просмотра календаря не требуется создавать учетную запись. При командной работе доступ к календарям предоставляется с гибкой настройкой уровней прав, что делает планирование прозрачным и управляемым. Полноформатный планировщик событий позволяет детально настраивать встречи и мероприятия в интуитивно понятном интерфейсе. Реализована возможность редактировать или удалять отдельное событие внутри повторяющейся серии, не нарушая всю последовательность, а также отображать время начала серии непосредственно в календаре.</p> <p>Значительные улучшения затронули и почтовый редактор. Теперь в тело письма можно мгновенно вставлять изображения, файлы и таблицы прямо из буфера обмена, а также создавать и редактировать таблицы встроенными средствами. Функция отложенной отправки позволяет задать точную дату и время доставки письма, а проверка орфографии подчеркивает ошибки, помогая избегать опечаток. Статус отправленных сообщений помогают отслеживать уведомления о доставке и прочтении с возможностью выбора автоматического или ручного режима в настройках.</p> <p>Для совместной работы с почтой и учетными записями реализован ряд новых возможностей. Доступ к почтовым папкам коллег настраивается для совместной работы, а функция делегирования позволяет доверенным лицам отправлять письма, принимать, переносить или назначать встречи от имени другого сотрудника. При отправке можно выбрать имя, от которого будет отправлено письмо, что обеспечивает прозрачность для получателя. Также пользователи могут создавать псевдонимы для своих учетных записей, чтобы лучше структурировать входящий поток.</p> <p>В релизе появились важные инструменты для защиты аккаунтов. Пользователи теперь могут самостоятельно сменить пароль непосредственно из интерфейса приложения, а также настроить двухфакторную аутентификацию — это обеспечивает дополнительный уровень защиты от несанкционированного доступа, что критически важно для корпоративных коммуникаций.</p> <p>Одним из ключевых нововведений стал функционал создания локальных архивов. Теперь можно сохранять свои почтовые сообщения непосредственно на устройстве, обеспечивая офлайн-доступ и дополнительную сохранность данных. На текущий момент доступно создание архивов и вложенных подпапок, архивация одного письма и группы писем, ручная архивация всей папки через контекстное меню, автоархивация по настройкам, удаление архивов и папок в них, ответ на письма из архива, пересылка писем из архива, работа с метками в архивах.</p> <p>Повышению удобства повседневной работы также способствуют обновленный поиск адресатов, который предлагает наиболее релевантных получателей при вводе фамилии, настройки режима удаления писем — через корзину, напрямую или пометку письма как удаленного, а также редизайн карточки контакта с более структурированным отображением информации. Для ускорения навигации добавлены горячие клавиши и возможность открывать письмо в новом окне одним нажатием Enter. Производительность приложения в целом была улучшена: оно стало быстрее и отзывчивее.</p> <p>«Мы сфокусировались на том, что напрямую влияет на эффективность повседневной работы, — прокомментировал Борис Моисеев, директор департамента разработки CommuniGate Pro. — Возможность вставить таблицу из Excel, файл или изображение в письмо за секунду, открыть календарь внешнему партнеру без создания учетной записи или выполнить проверку орфографии при написании письма — это базовые инструменты, экономящие реальное время каждого сотрудника каждый день».</p> <p>Первый официальный релиз десктопного и мобильного приложений уже доступен пользователям с действующей лицензией.</p> Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии … message https://www.itweek.ru/themes/detail.php?ID=235361 Tue, 18 Aug 2026 09:27:05 +0300 <p><em>Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности с фабрикой о экономически эффективном массовом производстве их совков для уборки собачьих экскрементов, комфортных носков или мочалок. Идея массового производства может быть актуальна и для доставки ПО, пишет на портале </em><em>ZDNet</em> <em>независимый аналитик Джо Маккендрик.</em></p> <p>Представьте, что вы отправляете свой прототип — например, начальную версию приложения, написанную с помощью вайб-кодинга, — в сервис, который будет массово производить ваше решение в повторяемом автоматизированном режиме для распространения среди широкой аудитории. В этом и заключается обещание «фабрики ПО».</p> <p>В этой концепции нет ничего нового — она была очень популярна около двух десятилетий назад, когда разработка ПО стала более компонентной и повторяемой. Microsoft <a href="https://en.wikipedia.org/wiki/Software_factory_(Microsoft_.NET)">заговорила</a> о фабриках ПО еще в 2008 г. Идея на некоторое время затихла, но теперь она вернулась, подпитываемая быстрым созданием программного кода, генерируемого и управляемого искусственным интеллектом.</p> <p>До недавнего времени, даже при наличии автоматизации и практик DevOps, «кодирование создавало узкие места для многих организаций, — говорит Мориц Плассниг, генеральный директор CloudBees. — Приходилось нанимать больше инженеров, но это было очень сложно и дорого».</p> <h3>Сегодняшняя фабрика ПО построена на моделях ИИ</h3> <p>Благодаря возможностям кодирования базовых моделей ИИ и связанных с ними агентов, концепция фабрики ПО возродилась — и сегодня серьезно рассматривается автоматизация жизненного цикла разработки ПО на уровне повторяющихся этапов. С помощью агентного кодирования «мы меньше ограничены в части кодирования», отмечает Плассниг. Оно также может повысить роль ИТ-специалистов: «Мастерство разработчиков никуда не денется, поскольку разработчики и инженеры переходят от написания кода к принятию решений о том, что будет создано и выпущено».</p> <p>Современная концепция фабрики ПО построена на основе моделей ИИ, представленных на рынке, — и эта концепция практически одинакова для всех моделей. «За последние полтора года многие компании, находящиеся на переднем крае использования агентов для автоматизации жизненного цикла разработки ПО, создавали одну и ту же машину и независимо друг от друга приходили к одному и тому же выводу о том, как эта машина должна выглядеть», — говорит Джеймин Уэст, инженер-разработчик и технологический евангелист.</p> <p>Среди компаний, создающих фабрики ПО, — такие светила современной агентной экономики, как Anthropic, Cognition, Cursor, Factory, Google, Github, OpenAI и Ramp. «Каждая из этих компаний пришла к одной и той же форме, — отмечает Уэст. — На данном этапе очень важно понимать, что это компании, находящиеся на передовой, и что формируется четкая закономерность в том, как они структурируют всю свою инженерную работу».</p> <p>По словам Пласснига, фабрика ПО служит способом быстрого воплощения идей: «Допустим, кто-то работает в службе поддержки клиентов, и у него возникает интересная идея, основанная на отзывах клиентов. Такой человек с идеей ПО может отправить ее на фабрику, где создается первая итерация. Далее специалисты по продуктам, инженеры и ИТ-специалисты изучают ее. Затем фабрика может снова взять ее и воплотить в жизнь. Это подобно тому, как в автоиндустрии появляется экспериментальный прототип, который потом передается на завод, который производит автомобили в больших масштабах».</p> <p>Фабрика ПО помогает решить проблему проверки и поддержки сотен тысяч строк кода, а также релизов, обновлений и модернизаций ПО, которые сегодня ежедневно происходят во многих организациях.</p> <p>«Вы хотите знать, действительно ли ПО работает, нет ли ошибок или хотя бы резкого роста частоты ошибок. Или, может быть, оно работает, но не превышает ли потребление памяти агентом желаемый уровень? Сегодня люди проверяют все эти оповещения, но если изменений будет в 100 раз больше, например, каждые несколько минут, система сломается. Мы дойдём до того момента, когда люди больше не смогут проверять, что работает, а что нет», — говорит Плассниг.</p> <h3>Как выглядит фабрика ПО?</h3> <p>Уэст описывает типичную фабрику, поддерживаемую базовыми моделями, как состоящую из шести компонентов:</p> <ol> <li><strong> Очередь.</strong> «Работа поступает в виде проблемы, а не промпта».</li> <li><strong> Плоскость управления.</strong> «Надежный уровень, а не ноутбук».</li> <li><strong> Песочница.</strong> «Одна на задачу. Уничтожается после ее завершения».</li> <li><strong> Запрос на слияние.</strong> «Единица вывода. Его получает человек».</li> <li><strong> Поток событий.</strong> «Отслеживает каждое действие. Прерывает его, не нарушая выполнение».</li> <li><strong> Надежная память.</strong> «Песочница выполняет каждый запуск. То, что не записано в файл, не сохраняется».</li> </ol> <p>Конечно, фабрики ПО, какими бы эффективными они ни были, не являются панацеей для внедрения передовых методов разработки ПО.</p> <p>«Сейчас уже не секрет, что генерация кода стала невероятно простой, — говорит Уэст. — Она теперь невероятно дешева. Но препятствием для многих компаний стала верификация. Убедиться, что агенты пишут код, очень легко. Но убедиться в правильности этого кода по-прежнему остается серьезной инженерной проблемой. И важно понимать, что создание фабрики ПО не означает, что вы просто отказываетесь от верификации или снижаете качество своей кодовой базы».</p> Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности … article https://www.itweek.ru/themes/detail.php?ID=235359 Tue, 18 Aug 2026 09:17:03 +0300 <p><em>За четыре года число поисковых запросов вокруг темы «ИИ как угроза» выросло примерно в 30 раз и к <nobr>2026-му,</nobr> по данным исследования Андрея Цая, вышло на первое место — обогнав даже запросы о защите самих ИИ-систем. Рассмотрим, насколько реальна эта угроза и что необходимо предпринять компаниям, чтобы ее отразить.</em></p> <h3>ИИ как орудие злоумышленников</h3> <p>На фоне развития искусственного интеллекта все чаще звучат разговоры о том, что ИИ может превратиться в инструмент злоумышленников. Однако слово «может» здесь уже не вполне уместно: ИИ становится рабочим инструментом в offensive security и способен выполнять часть задач, которые раньше требовали значительного объема ручной работы. Показателен пример XBOW — автономной системы для поиска и эксплуатации уязвимостей. В 2025 году XBOW поднялась на первое место американского рейтинга HackerOne, а позднее заняла первое место и в глобальном рейтинге платформы. При этом речь шла не о лабораторном тесте: система работала в реальных bug bounty-программах и отправляла отчеты об обнаруженных уязвимостях. Сам HackerOne отмечал выход XBOW на первое место американского рейтинга как пример того, что ИИ-системы уже способны эффективно находить определенные классы уязвимостей. Это не означает, что ИИ полностью заменил исследователя: например, команда XBOW проверяла отчеты перед отправкой в соответствии с правилами HackerOne. Но сам кейс хорошо показывает изменение масштаба и скорости работы: значительную часть поиска, проверки гипотез и валидации находок уже можно автоматизировать.</p> <p>Причина очевидна: ИИ хорошо справляется с интеллектуальной рутиной. Он может быстро обрабатывать большие объемы информации, находить закономерности, классифицировать данные и выполнять последовательности однотипных операций. И атака в этом смысле во многом похожа на другие сложные рабочие процессы. Значительная часть времени злоумышленника уходит на подготовку: сбор информации о цели, анализ инфраструктуры и технологий, поиск потенциально интересных объектов и проверку различных гипотез. Если часть этой работы передать ИИ, меняется сама экономика атаки: разведка, анализ и перебор вариантов становятся быстрее и дешевле, а один злоумышленник может выполнять объем работы, для которого раньше требовалось значительно больше времени.</p> <p>Необходимо также понимать, что скорость внедрения новых технологий у злоумышленников зачастую выше, чем в крупных организациях. Пока компания оценивает риски, согласовывает бюджет, выбирает модели и выстраивает процессы безопасного использования ИИ, атакующему достаточно получить доступ к публичному сервису или модели. Возникает асимметрия: стоимость автоматизации отдельных этапов атаки быстро снижается, тогда как стоимость полноценной защиты компании — нет. Поэтому основная угроза ИИ сегодня заключается не столько в появлении автономного «ИИ-хакера», сколько в росте производительности обычного злоумышленника.</p> <h3>Проще атака — больше желающих</h3> <p>Еще одна проблема заключается в том, что ИИ постепенно снижает порог входа в отдельные этапы кибератак. Часть задач, для которых раньше требовались специальные знания, теперь можно выполнять с помощью языковых моделей: собирать и анализировать информацию о цели, быстрее разбираться в незнакомых технологиях, модифицировать скрипты, готовить фишинговые сообщения или анализировать найденный код. Это не превращает человека без технических знаний в профессионального хакера, но сокращает разрыв между отсутствием компетенций и возможностью выполнить отдельные элементы атаки.</p> <p>Одновременно с этим появляются и новые классы атак на сами ИИ-приложения. Один из примеров — prompt injection (инъекция промптов), при которой злоумышленник через специально сформированные инструкции пытается изменить ожидаемое поведение системы. Например, если на корпоративном ресурсе работает интеллектуальный поиск или ИИ-агент, атакующий может попытаться заставить его проигнорировать исходные инструкции, обратиться к данным, которые не должны быть доступны пользователю, или выполнить нежелательное действие. Отдельно существуют jailbreak-техники, направленные на обход ограничений самой модели. Для экспериментов с такими атаками в ряде случаев действительно не требуется сложная инфраструктура: взаимодействие происходит через тот же интерфейс, которым пользуется обычный пользователь.</p> <p>Одновременно ИИ выступает как инструмент автоматизации для самого злоумышленника. Если раньше для подготовки определенной атаки требовалось самостоятельно изучать множество технических вопросов, теперь часть этой работы можно переложить на языковую модель: быстрее разобраться в технологии, получить объяснение незнакомого кода, подготовить или адаптировать отдельные фрагменты скриптов, систематизировать результаты разведки. Ограничения публичных моделей снижают возможности их прямого использования во вредоносных целях, однако злоумышленники постоянно экспериментируют и с техниками обхода таких ограничений.</p> <p>Для обхода ограничений могут использоваться изменение контекста запроса, ролевые сценарии, декомпозиция задачи на несколько внешне безобидных этапов и другие техники. Вместо прямого запроса пользователь может представить задачу как исследование, киберучение или анализ защищенности либо разбить ее на последовательность отдельных вопросов. Эффективность таких приемов зависит от конкретной модели и реализованных механизмов защиты, но для атакующего важен сам принцип: ИИ позволяет значительно быстрее проводить эксперименты и проверять множество вариантов.</p> <p>Еще сильнее меняется скорость работы. Если раньше сбор и изучение контекста для определенной атаки могли занимать дни, то автоматизированная система способна существенно сократить этот этап. В результате отдельные стадии атаки становятся проще, дешевле и лучше масштабируются. Высвободившееся время злоумышленник может потратить на более сложные действия, которые пока хуже поддаются автоматизации.</p> <p>Для бизнеса это неприятная тенденция, поскольку стоимость атаки снижается, но стоимость полноценной защиты от нее автоматически не уменьшается. Компании по-прежнему должны поддерживать инфраструктуру безопасности, контролировать доступы, анализировать события и защищать данные.</p> <h3>Shadow AI как источник риска внутри компании</h3> <p>Однако усиление внешнего атакующего — только одна сторона проблемы. ИИ одновременно меняет поверхность атаки внутри самой компании: сотрудники подключают публичные модели, генераторы кода, агентов и другие инструменты быстрее, чем служба безопасности успевает их обнаруживать и оценивать. Так возникает другая категория риска — Shadow AI (теневой ИИ).</p> <p>Термин появился по аналогии с давно известным Shadow IT (теневые ИТ) — ситуацией, когда сотрудники самостоятельно используют для рабочих задач программное обеспечение и сервисы, которые компания официально не разрешила и не контролирует. Например, сотруднику нужен удобный инструмент для хранения файлов, совместной работы или обработки документов, и он самостоятельно регистрируется во внешнем сервисе. С точки зрения сотрудника он просто выбрал удобный инструмент, а с точки зрения службы безопасности внутри компании появился неконтролируемый канал обработки корпоративных данных.</p> <p>С Shadow AI происходит похожая история. В компании может не быть понятных правил использования ИИ — какие сервисы разрешены, какие данные можно туда отправлять, какую информацию категорически запрещено загружать, какие инструменты допустимы для разработки и анализа. В результате сотрудники начинают самостоятельно выбирать открытые ИИ-сервисы и использовать их для рабочих задач.</p> <p>Главные риски здесь связаны с утечками данных. Сотрудник может работать с корпоративного компьютера или ноутбука в публичном ИИ-сервисе и передавать туда информацию, которую нельзя выводить за пределы компании. Причем он сам часто даже не задумывается, что создает риски утечки. Для него это просто удобный способ решить рабочую задачу.</p> <p>Допустим, сотрудник отдела продаж берет папку с документами по клиентам за прошлый год и загружает ее в ИИ с просьбой сформировать отчет, прогноз или маркетинговое предложение. На первый взгляд задача выглядит безобидной и даже полезной: сотрудник хочет быстрее проанализировать информацию, чтобы повысить продажи. Но вместе с запросом за пределы корпоративного контура уходит клиентская база: контактные данные, сведения о продажах, цены, скидки и другая коммерческая информация. В результате могут компрометироваться и персональные данные, и коммерческая тайна, и внутренняя информация о работе с клиентами.</p> <p>Традиционные средства контроля утечек данных остаются необходимой частью защиты, но в случае с ИИ их возможностей может быть недостаточно. Компании важно понимать не только то, какие данные передаются за пределы корпоративного контура, но и в какой ИИ-сервис они уходят, разрешен ли этот сервис конкретному сотруднику, идет ли речь о загрузке файла, отправке промпта или обращении к модели через API. Поэтому классические механизмы защиты приходится дополнять обнаружением ИИ-сервисов и контролем специфичных для них сценариев использования.</p> <p>У Shadow AI есть и техническая сторона. Внутри разработки могут появляться генераторы кода, различные модели, агенты и другие инструменты, которые сотрудники самостоятельно подключают к рабочим процессам. Проблема заключается в том, что качество и безопасность таких инструментов часто под вопросом. Один сотрудник может использовать модель для генерации кода, другой — подключить сторонний инструмент для автоматизации, третий — развернуть собственный сервис. При этом количество подобных решений может расти настолько быстро, что служба безопасности просто не успевает их обнаруживать и оценивать. А защищать то, что СБ не видит, технически невозможно. Если компания не знает, какими ИИ-инструментами пользуются сотрудники, она не может полноценно оценить риски, определить, какие данные через них проходят, и подобрать соответствующие средства защиты.</p> <p>Поэтому сама по себе политика запрета не решает проблему. Более того, жесткий запрет может сделать ситуацию менее прозрачной. Если сотруднику официально запрещено пользоваться ИИ, но инструмент необходим ему для работы, он с высокой вероятностью начнет искать собственное решение. В итоге компания формально может считать, что никакого ИИ у нее нет, тогда как сотрудники будут его использовать с личных устройств.</p> <p>Выход здесь — в создании контролируемой корпоративной среды для работы с ИИ. Если сотрудникам действительно нужны языковые модели, агенты или другие ИИ-инструменты, компания должна предоставить разрешенные способы их использования: определить перечень допустимых сервисов и моделей, правила работы с данными, механизмы доступа, журналирования и контроля. Это необязательно означает полный отказ от внешних ИИ-сервисов — важно, чтобы компания понимала, какие инструменты используются, какие данные в них передаются и на каких условиях они обрабатываются.</p> <p>Такая среда должна быть не только безопасной, но и удобной. Иначе запрет снова будет проигрывать удобству публичных инструментов. Сотрудник выбирает не по критерию безопасности. Он ищет способ быстрее выполнить свою работу. И если корпоративная система оказывается слишком неудобной, поиск обходных путей практически неизбежен.</p> <p>#IMAGE_235360#</p> За четыре года число поисковых запросов вокруг темы «ИИ как угроза» выросло примерно в 30 раз … article Светлана Газизова, владелец продукта по безопасности ИИ компании UserGate https://www.itweek.ru/themes/detail.php?ID=235358 Mon, 17 Aug 2026 19:08:47 +0300 <p>Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более 43 тыс. человек по 36 ролям и выяснила, что медианная зарплата специалистов уровня Senior в I квартале 2026 года вернулась к показателю трёхлетней давности. За полгода она снизилась на 17%, с 360 тыс. до 300 тыс. рублей после вычета налогов. </p> <p>Исследование охватывает семь замеров с I квартала 2023 года по I квартал <nobr>2026-го.</nobr> За это время российский ИТ-рынок прошёл полный цикл: от последовательного роста зарплат до их заметного снижения после пика III квартала 2025 года.</p> <p>Изменения затронули все грейды, за полгода медианная зарплата специалистов уровня Middle снизилась на 8%, с 250 тыс. до 230 тыс. рублей после вычета налогов. У Senior она сократилась на 17%, с 360 тыс. до 300 тыс. рублей, а у Lead — на 12%, с 450 тыс. до 395 тыс. рублей. При этом зарплаты Middle и Lead всё ещё немного превышают показатели начала 2023 года, тогда как медиана Senior полностью вернулась к уровню трехлетней давности.</p> <p>«Совпадение зарплатных показателей с уровнем 2023 года не означает, что рынок вернулся в прежнее состояние. За одинаковыми цифрами скрывается другая логика найма. Если раньше работодатели конкурировали за специалистов и расширяли зарплатные вилки, то теперь они точнее оценивают прикладную ценность каждой роли. Спрос сохраняется, но становится более избирательным: лучше всего удерживают позиции специалисты, чьи компетенции связаны с устойчивостью инфраструктуры, безопасностью и решением конкретных задач бизнеса.</p> <p>В этих условиях компаниям важно не только точнее нанимать специалистов, но и эффективнее развивать уже сформированные команды. Поэтому переход от HR Tech к People Tech, то есть от автоматизации отдельных HR-функций к управлению всем профессиональным путём сотрудника, становится одной из ключевых тем отраслевой дискуссии. Этот вопрос активно обсуждается в профессиональном сообществе, в том числе на конференциях для HR- и ИТ-лидеров. Бизнес стремится объединить подбор, адаптацию, обучение и оценку эффективности в единую систему, ориентированную на реальные задачи компании», — комментирует Иван Котковский, управляющий партнёр кадрового системного интегратора SENSE, сооснователь и член программного комитета ежегодного кэмпа PEOPLE TECH для HRD, CPO / CTO HR.</p> <p>Наиболее заметно снизились зарплаты в направлениях, которые активнее всего росли в <nobr>2024–2025 годах.</nobr> Одним из таких направлений стало Data & ML. Самую сильную коррекцию за полгода показали специалисты Data Quality уровня Lead: их медианная зарплата сократилась на 30%, с 400 тыс. до 280 тыс. рублей. Data Scientist Lead за тот же период потеряли 115 тыс. рублей, а Senior — 85 тыс. рублей.</p> <p>В то же время прикладные и инфраструктурные роли внутри Data & ML оказались устойчивее: медианная зарплата DBA Middle снизилась только на 3%, а ML Middle — на 7%. По мнению аналитиков SENSE, рынок стал строже оценивать не само владение ИИ-инструментами, а способность специалистов решать с их помощью конкретные задачи бизнеса.</p> <p>Заметный откат произошёл и в классическом backend. За полгода медианная зарплата Python Senior снизилась на 28%, с 360 тыс. до 260 тыс. рублей, а C#.Net Senior — на 26%, с 380 тыс. до 280 тыс. рублей. Зарплата Java Middle к I кварталу 2026 года вернулась к отметке 250 тыс. рублей, зафиксированной в начале <nobr>2023-го.</nobr> На динамику направления повлияли замедление найма и пересмотр ИТ-бюджетов в финансовом секторе, который долгое время оставался одним из основных заказчиков специалистов этого профиля.</p> <p>Существенную переоценку пережила и мобильная разработка. От собственных пиков III квартала 2024 года до I квартала <nobr>2026-го</nobr> медианные зарплаты iOS-разработчиков снизились на <nobr>19–37%</nobr> в зависимости от грейда, Android-разработчиков — на <nobr>19–31%.</nobr> Сильнее всего коррекция затронула специалистов уровня Middle.</p> <p>Наиболее устойчивыми оказались направления, спрос на которые связан с долгосрочными задачами бизнеса. После пика зарплаты архитекторов информационной безопасности снизились не более чем на 1%, а медианы DevSecOps сохранились на прежнем уровне. В направлении 1С зарплаты по четырём из шести исследованных ролей не изменились по сравнению с III кварталом 2025 года. Относительно небольшую коррекцию также показали Frontend, DevOps и SRE.</p> <p>При этом в период роста отдельные роли показали особенно заметную динамику. От начала наблюдений до своих максимальных значений медианные зарплаты бизнес-аналитиков уровня Middle выросли на 67%, системных аналитиков Middle — на 66%. Архитекторы информационной безопасности уровня Middle прибавили 50%, DBA Lead — 46%, а DBA Senior — 43%. Это показывает, что общая коррекция не отменила структурный спрос на отдельные компетенции, хотя после пика III квартала 2025 года динамика стала разнонаправленной.</p> Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более … message https://www.itweek.ru/themes/detail.php?ID=235355 Mon, 17 Aug 2026 11:50:26 +0300 <p>Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — очередного обновления платформы миграции и репликации данных. Ключевое новшество версии — поддержка аналитической СУБД для гибридных нагрузок Postgres Pro AXE с загрузкой в S3-совместимое хранилище, что открывает заказчикам новые сценарии для построения аналитических хранилищ. Также в релиз вошла функциональность по повышению производительности утилит, укреплению безопасности и переработке механизма интроспекции схем данных.</p> <p>Postgres ProGate предназначена для проектов миграции, разового переноса данных и непрерывной репликацей между СУБД. Продукт помогает автоматизировать ключевые этапы работы с данными: первичную загрузку, синхронизацию изменений в режиме, близком к реальному времени, и проверку корректности переноса.</p> <p>Главное новшество версии — поддержка аналитической СУБД AXE в качестве приёмника данных с возможностью загрузки в S3-совместимое хранилище. Это расширяет сценарии использования платформы для построения современных аналитических хранилищ и data lake-решений на базе экосистемы Postgres Professional.</p> <p>Также одним из наиболее стала полная переработка механизма интроспекции. Реализована асинхронная обработка, что заметно ускоряет интроспекцию схем с большим количеством таблиц. Добавлена поддержка проверки привилегий доступа к схемам и таблицам, а также проверки совместимости подключений для prosync, включая права на чтение таблиц, — результаты доступны через API. Улучшено автоматическое сопоставление схем и таблиц для задач трансфера на основе совпадения имён.</p> <p>Утилита procopy получила более гибкий контроль над параллельной обработкой задач. Добавлен параметр sub_task_count, определяющий, на сколько подзадач может разбиваться исходная задача копирования, при этом расчёт размера подзадач теперь выполняется автоматически, а параметр sub_task_rows переведён в статус deprecated. Появился флаг force_restart_task, позволяющий перезапускать задачи без очистки данных и без изменения идентификатора задачи — это удобно для регулярных переносов данных, например, снапшотов T-1.</p> <p>Кроме того, в procopy и prosync добавлен параметр disable_constraint_checks, который отключает проверку ограничений и пользовательских триггеров на время записи батча в целевую PostgreSQL-совместимую БД, что ускоряет загрузку в сценариях, где целостность гарантируется на стороне источника или последующей верификацией.</p> <p><nobr>CDC-репликация</nobr> стала стабильнее и быстрее. Добавлена опция single_loader, которая позволяет для конкретной таблицы принудительно использовать один загрузчик, обеспечивая последовательную обработку изменений для таблиц, связанных внешними ключами. Исправлена ошибка считывания записей с большими значениями SCN из онлайн-журналов Oracle. Устранено удержание WAL-файлов на источниках PostgreSQL при редких изменениях за счёт улучшения механизма продвижения слотов логической репликации. Повышена производительность применения изменений для Oracle.</p> <p>Добавлена фиксация блокировки учётной записи пользователя при превышении лимита неудачных попыток ввода пароля. Все компоненты системы переведены на Go 1.26.5, а Apache Thrift обновлён до версии v0.23.0 с устранением ранее обнаруженных уязвимостей.</p> <p>«Поддержка Postgres Pro AXE в качестве приёмника данных — это новый вектор развития продукта. Если раньше ProGate использовался преимущественно для миграции и репликации между операционными базами данных, то теперь платформа закрывает и сценарий поставки данных в аналитику с загрузкой в S3-совместимые хранилища. Это существенно расширяет область применения продукта и открывает нашим заказчикам возможность строить аналитические конвейеры на единой технологической платформе. В сочетании с переработанной интроспекцией, которая в разы ускоряет работу со схемами из сотен и тысяч таблиц, новыми опциями управления параллелизмом в procopy и усилением безопасности мы сделали серьёзный шаг в развитии платформы и дали нашим клиентам новые споособы решения своих бизнес-задач», — прокомментировал руководитель продукта Postgres ProGate Евгений Кривов.</p> Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — … message https://www.itweek.ru/themes/detail.php?ID=235352 Mon, 17 Aug 2026 09:43:07 +0300 <p><em>Искусственный интеллект делает более быстрым и простым извлечение конфиденциальной личной информации из обычных бизнес-данных. Вице-президент Gartner Барт Виллемсен объясняет порталу </em><em>InformationWeek</em><em>, почему это происходит и что должны делать руководители служб информационной безопасности (</em><em>CISO</em><em>).</em></p> <p>Правила регулирования конфиденциальности данных, например европейский GDPR и американские федеральные законы, такие как HIPAA, больше не достаточны для защиты персональных данных в эпоху ИИ.</p> <p>Gartner <a href="https://www.gartner.com/en/documents/7864881">прогнозирует</a>, что к 2029 г. большинство инцидентов, связанных с нарушением конфиденциальности, будут вызваны ИИ-выводами об отдельных лицах, а не прямым раскрытием личной информации, такой как имена, адреса и номера социального страхования.</p> <p>По словам Виллемсена, способность ИИ быстро распознавать образы означает, что злоумышленникам больше не нужно красть или покупать учетные данные, чтобы получить конфиденциальную информацию о людях. Анонимизация данных сама по себе не обеспечивает достаточной защиты, поскольку алгоритмы ИИ могут повторно идентифицировать людей или выводить конфиденциальные атрибуты из анонимизированных наборов данных.</p> <p>«Настоящей анонимизации не существует, за исключением фактического удаления данных. Атака на основе инференса очень эффективна, потому что она затрагивает всё, а не только непосредственно идентифицируемые репозитории», — говорит Виллемсен.</p> <p>По мере совершенствования генеративного ИИ и машинного обучения эти технологии могут выводить конфиденциальные личные характеристики — такие как состояние здоровья или поведенческие модели — из анонимизированных или агрегированных данных.</p> <p>«Современные модели могут восстанавливать личные данные, используя поведенческие модели, показатели использования и агрегированные записи транзакций. Например, ИИ может идентифицировать людей по данным о поездках, социальным сетям, рентгеновским снимкам, ЭКГ, МРТ, даже походке или практически любой комбинации из примерно трёх транзакций», — объясняет Виллемсен.</p> <p>Кроме того, по его словам, когда ИИ галлюцинирует или создает синтетические данные о людях, эти неверные данные могут вызывать реальные проблемы. Например, предвзятость и галлюцинации ИИ могут привести к неправомерному тюремному заключению и серьезным ошибкам в юридических исследованиях.</p> <p>Последствия выходят далеко за рамки нарушений конфиденциальности, считает Эндрю Обадиару, CISO компании Cobalt. «ИИ может определить состояние здоровья человека, его финансовое положение, влияние внутри организации или вероятность ответа на фишинговое письмо, не имея доступа к медицинской карте или кадровому делу», — говорит он.</p> <p>По его словам, данные, которые не кажутся конфиденциальными — такие как справочники сотрудников, отношения с поставщиками, активность в социальных сетях или взаимодействие с клиентами — могут стать ценными, когда ИИ связывает эти фрагменты. ИИ может использовать их для определения структуры подчиненности, администрирования систем, взаимоотношений между руководителями, полномочий по расходам или того, какой инженер отвечает за критически важную производственную систему. Затем злоумышленники могут использовать эти данные, чтобы сделать свои атаки гораздо более точными.</p> <p>«В результате фишинговые кампании становятся значительно более убедительными, компрометация корпоративной электронной почты происходит быстрее, вымогательство — более целенаправленным, а операции по вторжению — гораздо эффективнее, поскольку злоумышленник уже знает, кого атаковать, прежде чем отправить первое письмо», — поясняет Обадиару.</p> <p>Организациям необходимо начать задумываться не только о том, какие данные они собирают, но и о том, «что эти данные раскрывают, когда они объединяются, сопоставляются и интерпретируются все более совершенными системами ИИ», — добавляет он. И, из-за развития технологий ИИ, правила обеспечения конфиденциальности, которые исторически были сосредоточены на непосредственно идентифицируемых данных, должны также распространяться на косвенно или повторно идентифицируемый контент.</p> <p>«Сочетание данных, зарегистрированных где угодно, доступа к ним по всему миру (случайно или в результате злонамеренного взлома) и возможностей, доступных любому, кто хочет получить доступ к данным с помощью современных аналитических и генеративных ИИ-технологий, — вот что отличает сегодняшнюю ситуацию. Кроме того, организации практически не очищают данные, которые им больше не нужны», — говорит Виллемсен.</p> <p>По его словам, риск повторной идентификации данных существовал задолго до сегодняшнего бума ИИ, но ИИ значительно ускоряет этот процесс. Он ссылается на <a href="https://www.nature.com/articles/s41467-019-10933-3.pdf">исследование</a> 2019 г., проведенное специалистами в области науки о данных Люком Роше, Жюльеном М. Хендрикксом и Ивом-Александром де Монжуа, которые разработали генеративную графическую модель для повторной идентификации людей. «Используя нашу модель, мы обнаружили, что 99,98% американцев будут правильно идентифицированы в любом наборе данных с использованием 15 демографических атрибутов», — написали они.</p> <h3>ИИ усиливает угрозу повторной идентификации</h3> <p>По словам Обадиару, что изменилось с развитием ИИ, так это то, что теперь «скорость на стороне злоумышленников — и масштаб». «Пять лет назад создание подробных профилей тысяч потенциальных жертв было экономически нецелесообразным. Сегодня это не так», — отмечает он.</p> <p>Виллемсен обращает внимание на <a href="https://arxiv.org/pdf/2602.16800">исследование</a> 2026 г., проведенное инженерами Саймоном Лерменом, Даниэлем Палекой, Джошуа Свансоном, Майклом Аэрни, Николасом Карлини и Флорианом Трамером. Авторы обнаружили, что больше языковые модели (LLM) могут повторно идентифицировать людей, «используя только псевдонимизированные онлайн-профили и переписки, что сопоставимо с тем, что может выполнить опытный следователь за много часов работы».</p> <p>Примечательно пояснение авторов: «В каждой ситуации методы на основе LLM значительно превосходят классические базовые методы, достигая до 68% полноты при 90% точности по сравнению с почти 0% для лучшего метода без применения LLM. Наши результаты показывают, что практическая неопределенность, защищающая псевдонимных пользователей в Интернете, больше не действует и что модели угроз для конфиденциальности в Интернете необходимо пересмотреть».</p> <p>По словам Обадиару, лучшие атаки на основе инференса совсем не выглядят как атаки. «Злоумышленник может начать с LinkedIn, публичных документов, социальных сетей, украденных учетных данных, активности на GitHub и утечек маркетинговых баз данных. Ни один из этих наборов данных сам по себе не представляет особой ценности. Но ИИ выполняет сложную работу по их объединению», — отмечает он.</p> <p>По словам Виллемсена, чтобы снизить риски нарушения конфиденциальности, основанные на инференсе, CISO следует начать с обеспечения управления данными на протяжении всего их жизненного цикла и удаления данных, как только они перестанут приносить бизнес-ценность, которая оправдывала бы затраты и риски их защиты. «У данных есть жизненный цикл, и мы знаем, что хранить их вечно — это неразумно. Поэтому жестко запрограммируйте его конец», — советует он.</p> <h3>Шаги по устранению основанных на инференсе рисков от Gartner</h3> <p>По словам Виллемсена, для CISO защита от угроз, основанных на ИИ-инференсе, начинается с управления ИИ. Вот его советы:</p> <ul> <li><strong> Управление ИИ.</strong> Внедрите в разработку ИИ установление механизмов защиты конфиденциальности на этапе проектирования и регулярно оценивайте риски предвзятости или инференса.</li> <li><strong> Внедрение технологий повышения конфиденциальности (PET).</strong> PET — это «набор технологических инструментов», — говорит Виллемсен. Эти технологии защищают персональные данные, обрабатывая их в защищенном состоянии или в рамках «конфиденциальных вычислений». К PET относятся дифференциальная конфиденциальность, синтетические данные, машинное обучение с учетом конфиденциальности и гомоморфное шифрование, которое выполняет вычисления над зашифрованными данными без необходимости их предварительного расшифрования. PET могут свести к минимуму вероятность повторной идентификации ИИ отдельных лиц, даже если ИИ проанализирует данные.</li> <li><strong> Контроль жизненного цикла.</strong> Сбор данных должен ограничиваться основными потребностями бизнеса и включать контроль доступа. Данные следует удалять, как только они перестают быть полезными и/или их защита становится экономически нецелесообразной. Что касается управления данными, то Виллемсен советует проводить «последовательную и очень тщательную очистку».</li> <li><strong> Повышение кибербезопасности для угроз, основанных на ИИ.</strong> Организациям следует расширять свои традиционные подходы к кибербезопасности, уделяя приоритетное внимание расширенному мониторингу, обнаружению аномалий и возможностям планирования сценариев для выявления угроз, основанных на инференсе.</li> <li><strong> Прозрачность и человеческий контроль.</strong> Задокументируйте, где в сети организации уместно использование ИИ-инференса, регулярно проводите аудит систем ИИ и поддерживайте участие человека в проверке выводов, генерируемых ИИ, прежде чем допустить технологию действовать с конфиденциальными данными.</li> </ul> <p>«Не стоит недооценивать риски, связанные с различными типами ИИ, прежде чем использовать какой-либо из них», — заключает Виллемсен.</p> Искусственный интеллект делает более быстрым и простым извлечение конфиденциальной личной информации из обычных … article