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=235444 Wed, 02 Sep 2026 10:10:22 +0300 <p><em>За тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но ни один из них не менял расстановку сил так быстро, как генеративный ИИ. Раньше между появлением нового класса атак и его массовым применением проходили годы: злоумышленникам нужно было время, квалификация и инфраструктура. Сегодня этот барьер обрушился. Написать фишинговое письмо на безупречном русском, собрать досье на жертву, сгенерировать вариант вредоносного кода, обходящий сигнатурный детектор, — всё это стало доступно человеку без глубокой технической подготовки и занимает минуты, а не недели. </em><em>Рассмотрим, </em><em>к</em><em>ак эволюционировали методы кибератак с появлением ИИ</em><em>.</em></p> <p>Масштаб перемен уже поддаётся измерению. По данным отчёта Bugcrowd Inside the Mind of a Hacker, к концу 2025 года 82% исследователей (в том числе действующих не по правилам; против 64% в <nobr>2023-м)</nobr> применяли ИИ в своей работе. Искусственный интеллект перестал быть экзотикой в арсенале атакующего и стал рабочим инструментом по умолчанию.</p> <p>Эволюцию «наступательного» ИИ удобно разложить на три волны, которые не сменяют, а наслаиваются друг на друга.</p> <h3>Три этапа взросления атакующих нейросетей</h3> <p>Первая волна — автоматизация рутины. Здесь ИИ не принимает решений, а масштабирует то, что человек и так делал руками: генерирует тексты фишинга, переводит их на десятки языков без характерных ошибок, пишет шаблоны, парсит открытые источники. Это уже полностью реальность и массовая практика. Стоимость подготовки убедительной атаки упала на порядок, а качество — выросло.</p> <p>Вторая волна — ассистирование в сложных задачах. ИИ становится «вторым пилотом» атакующего: помогает разобраться в незнакомом коде, предлагает варианты эксплуатации уязвимости, адаптирует полезную нагрузку под конкретное окружение, ведёт разведку и приоритизирует цели. Решение по-прежнему за человеком, но скорость и охват растут кратно. Именно на этом этапе мы находимся сейчас.</p> <p>Третья волна — автономное принятие решений. Это агентные системы, которые получают цель («получить доступ к сегменту сети») и самостоятельно строят цепочку действий: разведка → выбор вектора → эксплуатация → закрепление → латеральное перемещение, реагируя на обратную связь от среды без участия оператора. Полноценных автономных атакующих агентов «в дикой природе» пока единицы, и они несовершенны, но направление обозначено предельно чётко. Именно к этому сценарию защиты нужно готовиться уже сегодня, а не когда он станет мейнстримом.</p> <h3>Что случилось с классическими векторами</h3> <p>Важно понимать: генеративный ИИ не создал новых классов атак. Фишинг, социальная инженерия и вредоносное ПО были и двадцать лет назад. ИИ изменил их экономику и качество.</p> <ul> <li><strong>Фишинг</strong>. Раньше защитой служили сами письма: корявый язык, нелепые обращения, кривая верстка — «маркеры мошенника», которым учили сотрудников. Генеративные модели эти маркеры стёрли. Показателен рубеж, зафиксированный в сети детектирования Hoxhunt: несколько лет доля писем с признаками ИИ-генерации держалась ниже 5%, а в декабре 2025 года подскочила примерно в 14 раз — до 56% всех выявленных атак. Изменилась и экономика: по оценкам, приводимым в индустриальных отчётах, LLM сократили время подготовки убедительной кампании с примерно 16 часов ручной работы до нескольких минут, а затраты на массовую рассылку упали примерно на 95%. Письмо теперь грамотное, персонализированное под должность и контекст получателя, а массовая кампания легко превращается в тысячи уникальных вариантов, каждый из которых обходит фильтры по «шаблонности».</li> <li><strong>Социальная инженерия</strong><strong>.</strong> Здесь качественный скачок дали дипфейки. Хрестоматийный пример — инцидент с инженерной компанией Arup в начале 2024 года: сотрудника финансового отдела в Гонконге убедили провести 15 переводов на общую сумму около 25 млн. долл. после видеозвонка, на котором все «руководители», включая финансового директора, были сгенерированы ИИ. И это не единичный случай: по оценке Surfshark на основе AI Incident Database, совокупные потери от дипфейк-мошенничества к концу прошлого года достигли порядка 1,56 млрд. долл., причём более 1 млрд. пришлось только на 2025 год. Опаснее всего то, что человек здесь беззащитен по природе: в контролируемых исследованиях качественные видео-дипфейки люди правильно распознают лишь примерно в четверти случаев. Доверие к «знакомому лицу и голосу» из защитного механизма превратилось в вектор атаки.</li> <li><strong>Вредоносное ПО</strong><strong>.</strong> ИИ ускорил разработку и, что опаснее, — вариативность. Полиморфный код, который на каждой итерации меняет структуру, сохраняя функциональность, генерируется теперь программно и в промышленных объёмах. Для сигнатурного детектирования это тяжёлый удар: сигнатура ловит известное, а машина производит бесконечный поток «нового».</li> <li><strong>Пентест.</strong> Автоматизация многих этапов внешнего и внутреннего тестирования на проникновение с помощью нейросетей значительно сокращает время от обнаружения уязвимого ресурса до получения доступа во внутреннюю инфраструктуру. Разница и преимущество опытного оператора с нейростью перед специалистом без такого инструмента сразу заметны. Там, где человеческий глаз и подход могут не заметить сложную уязвимость, ИИ может показать новый вектор или атаку, находя решение даже в самых сложных условиях.</li> </ul> <p>#IMAGE_235448#</p> <p>Как показывает <a href="https://www.first.org/blog/20260615-vulnerability-forecast-update">The 2026 Vulnerability Forecast Update</a>, в этом году ожидается 66 000 новых публичных CVE, что на 46,3% выше первоначального прогноза в 2026 году. Это на 37% больше по сравнению с <nobr>2025-м,</nobr> в котором нашли <a href="https://www.stingrai.io/blog/vulnerability-statistics-2026">48 185 CVE</a>, и на 20% больше чем в <nobr>2024-м</nobr> (40 009 CVE). По прогнозу заметна высокая динамика, и с помощью нейросетей теперь обнаруживают намного больше новых <nobr>0-day</nobr> уязвимостей.</p> <h3>Гонка вооружений: где был переломный момент</h3> <p>Противостояние атакующих и защитных алгоритмов — не новость. ML в антивирусах и системах обнаружения вторжений применяется больше десяти лет: поведенческий анализ, классификаторы вредоносных файлов, детекторы аномалий появились задолго до нынешнего хайпа. Массовый разворот защиты в сторону ИИ произошёл в конце <nobr>2010-х,</nobr> когда EDR- и NGAV-решения сделали машинное обучение стандартом, а не экзотикой.</p> <p>Настоящий перелом наступил в <nobr>2022-2023 годах,</nobr> с выходом больших языковых моделей в широкий доступ. До этого преимущество в автоматизации было скорее на стороне защиты — у неё было больше ресурсов и данных. Генеративный ИИ впервые дал атакующему инструмент такой же мощности, что и у обороняющегося, и почти бесплатно. Симметрия нарушилась: порог входа в качественную атаку упал быстрее, чем успела адаптироваться защита. Именно этот разрыв мы сейчас и наблюдаем.</p> <h3>Какие задачи атакующие уже делегируют машине</h3> <p>Если рассмотреть по отдельности каждый из этапов проникновения с точки зрения атакующего, ИИ сегодня применяется почти в каждом из них:</p> <ul> <li> <strong>Разведка (recon).</strong> Сбор и категоризация больших объемов данных по компании из открытых источников, составление карты внешнего периметра, анализ утечек и построение профилей сотрудников. То, что раньше отнимало у аналитка дни, модель делает за десятки минут.</li> <li> <strong>Активная эксплуатация</strong>. Пентест-агенты позволяют проанализировать каждый из обнаруженных ресурсов как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, и все это автоматически.</li> <li><strong>Социальная инженерия.</strong> Генерация фишинга и приманок. Уникальные письма, поддельные страницы, легенды для переписки — под конкретную жертву и её контекст. Сюда же относятся дипфейки: голос и видео для обхода процедур подтверждения личности и «звонка руководителя».</li> <li><strong>Разработка и мутация ПО.</strong> Написание и обфускация полезной нагрузки, генерация полиморфных вариантов, адаптация под окружение.</li> <li><strong>Полноценная имитация атакующего.</strong> Пентест-агенты позволяют проанализировать сайт как если бы это делал реальный злоумышленник — использовать инъекции, анализировать поведение приложения на различные запросы, обнаруживать сложные цепочки уязвимостей, генерация proof-of-concept под свежие багии помощь в написании эксплойтов, и все это автоматически.</li> </ul> <p>Отдельно — обход защиты. Генеративные модели используются для мимикрии под легитимный трафик: вредоносная активность «размазывается» так, чтобы статистически не отличаться от нормального поведения пользователя или приложения, а команды управления прячутся в обычных на вид запросах. Это прямая атака на детекторы аномалий, построенные на «отклонении от нормы».</p> <h3>Как ИИ работает на стороне защиты: SOC, SIEM, поведенческий анализ</h3> <p>Хорошая новость в том, что те же технологии усиливают и оборону — причём защита научилась применять ИИ раньше и системнее.</p> <p>В современных SOC и SIEM-системах машинное обучение решает главную боль аналитика — шум. Классические корреляционные правила генерируют тысячи срабатываний, большинство из которых ложные. <nobr>ML-модели</nobr> строят поведенческий базлайн (UEBA, анализ поведения пользователей и сущностей): что для конкретного аккаунта, сервера или сервиса является нормой по времени, объёму, географии, набору действий. Отклонение от этого профиля — сигнал, даже если формально ни одно сигнатурное правило не сработало. Именно так ловятся атаки, у которых нет известной сигнатуры.</p> <p>По эффективности для сложных угроз можно выделить несколько подходов:</p> <ul> <li> <strong>Обучение без учителя (кластеризация, детекторы аномалий)</strong> — для zero-day и незнакомых атак, где нет размеченных примеров. Модель ищет не «известное плохое», а «непохожее на нормальное».</li> <li><strong> Графовые модели и анализ последовательностей</strong> — для APT и латерального перемещения. Продвинутая целевая атака растянута во времени и складывается из событий, каждое из которых по отдельности выглядит безобидно. Увидеть её можно только как цепочку — граф связей между хостами, аккаунтами и процессами.</li> <li><strong> Рекуррентные и трансформерные архитектуры</strong> — для анализа временных рядов событий и выявления аномального контекста в потоке логов.</li> <li><strong> Модели на данных цепочки поставок</strong> — для атак через доверенных поставщиков, где вредоносный код приходит легитимным каналом обновления и требует анализа отклонений в самом артефакте, а не в сети.</li> </ul> <p>Ни один из этих методов не самодостаточен. Работает ансамбль: сигнатуры закрывают известное дёшево и точно, ML — неизвестное и поведенческое. И это окупается: по данным отчёта IBM Cost of a Data Breach 2025, организации, широко применяющие ИИ и автоматизацию в безопасности, обнаруживают и локализуют инциденты заметно быстрее и с ощутимо меньшими издержками, чем те, кто этого не делает.</p> <p>Предиктивные модели угроз пытаются ответить на вопрос «где ударят следующим». Они анализируют профиль организации, её поверхность атаки, историю инцидентов в отрасли, активность конкретных группировок и приоритизируют риски: какие активы и какие уязвимости с наибольшей вероятностью станут целью.</p> <p>Дефицит кадров в ИБ — структурная проблема, и здесь ИИ даёт ощутимый эффект. Системы SOAR (оркестрация, автоматизация и реагирование) берут на себя рутину: обогащение инцидента данными, первичную сортировку, изоляцию заражённого хоста, блокировку индикатора компрометации по готовому сценарию (playbook). Языковые модели добавляют к этому автоматическое резюмирование инцидента и черновики отчётов.</p> <p>Смысл не в том, чтобы заменить аналитика, а в том, чтобы он занимался расследованиями, а не перекладыванием тикетов. Когда 80% типовых срабатываний обрабатывается автоматически, у человека высвобождается время на то, что машине пока не по силам, — сложные, нестандартные, целевые атаки. Тут важно предостеречь: полная автоматизация реагирования без контроля человека опасна, потому что автономный ответ на ложный или спровоцированный сигнал сам становится вектором атаки — злоумышленник может намеренно заставить защиту «выстрелить себе в ногу».</p> <h3>Цикл «атака — защита», когда с обеих сторон ИИ</h3> <p>Мы движемся к ситуации, где и атакующий, и обороняющийся — это алгоритмы, соревнующиеся в скорости адаптации. Атакующая модель генерирует вариант, обходящий детектор; защитная — учится его ловить; атакующая — генерирует следующий. Цикл, который раньше измерялся месяцами, сжимается до дней и часов, а на этапе исполнения — до секунд. По данным CrowdStrike, среднее «время прорыва» (от первичной компрометации до первого латерального перемещения) в 2025 году составило 29 минут — на 65% быстрее, чем годом ранее, а рекордный показатель — 27 секунд; передача доступа от брокера первичного доступа к операторам вымогательского ПО, по данным Mandiant, сжалась до 22 секунд. Тот же CrowdStrike фиксирует рост ИИ-опосредованных атак примерно на 89% год к году.</p> <p>Кто выигрывает в такой гонке? Тот, у кого качественнее данные и быстрее петля обратной связи. И здесь у защиты есть структурное преимущество, о котором часто забывают: обороняющийся видит свою инфраструктуру целиком, а атакующий — только снаружи и по частям. Это преимущество работает при одном условии — если защита действительно видит всё. Слепые зоны — забытые тестовые серверы, теневые облачные сервисы, неучтённые VPN-точки, старые поддомены — обнуляют его. Автоматизированный сканер злоумышленника найдёт их за часы, и никакой продвинутый SOC не защитит актив, о существовании которого он не знает.</p> <p>Именно поэтому фундамент защиты в эпоху ИИ — это полная и непрерывная видимость поверхности атаки.</p> <h3>Что будет через 5<strong>-</strong>10 лет</h3> <p>Прогнозировать в ИБ на десять лет — сложно, но тренды достаточно устойчивы, чтобы обозначить контур. ИИ — полезный инструмент, который уже активно используется защитниками, но он не спасёт там, где нет базовой кибергигиены. Сначала база — классические процессы сканирования. Для них использование агентских систем — пустая трата токенов. А дальше — не бояться экспериментировать, решать свои задачи.</p> <p>Атаки станут агентными и автономными. Значительная часть операций — от разведки до эксплуатации — будет выполняться без прямого участия человека, а атаки станут по-настоящему массово-персонализированными: индивидуальный подход к каждой жертве при промышленном масштабе.</p> <p>Скорость выйдет на первый план. Ключевой метрикой станет не «есть ли у вас защита», а «за сколько вы обнаруживаете и реагируете». Человек останется в контуре принятия стратегических решений, но операционную скорость будут задавать машины с обеих сторон.</p> <p>Доверие к цифровому контенту продолжит расти. Дипфейки сделают верификацию личности отдельной инженерной дисциплиной. Пароля и даже голоса будет недостаточно — потребуются криптографические и поведенческие методы подтверждения.</p> <p>Защита консолидируется. Контроль периметра, SIEM, XDR и SOAR срастутся в единые экосистемы, где данные о поверхности атаки становятся общим контекстом для решений. Рынок уже движется к модели непрерывного управления экспозицией угроз (Continuous Threat Exposure Management) — от разовых проверок к постоянному мониторингу.</p> <p>Генеративный ИИ — это усилитель, и он укрепляет обе стороны. Проиграет не тот, у кого нет ИИ, а кто продолжает жить в логике реактивной защиты: узнавать о проблеме постфактум и проверять периметр по расписанию. Важно принять новую реальность, где всё меняется каждый день и с обеих сторон работают машины, построить защиту как непрерывный процесс, а не разовое действие. Технологии здесь скорее вторичны. Первична дисциплина видеть всё и вовремя.</p> <p>#IMAGE_235445#</p> За тридцать лет индустрия информационной безопасности пережила несколько технологических сдвигов, но ни один … article Давид Ордян, основатель и генеральный директор METASCAN https://www.itweek.ru/themes/detail.php?ID=235443 Wed, 02 Sep 2026 09:51:39 +0300 <p><em>Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией на практике, но хорошая новость заключается в том, что специалисты могут его преодолеть, сосредоточившись на тщательных исследованиях и убедительных сценариях использования в производстве, сообщает портал </em><em>ZDNet</em><em>.</em></p> <p>Согласно отчету глобальной контентной и технологической компании Thomson Reuters «2026 Future of Professionals Report», до 91% сотрудников заявляют, что их организации не в полной мере используют потенциал ИИ.</p> <p>Исследование, основанное на глобальном опросе 1800 специалистов из различных секторов, показывает растущий разрыв между амбициями в области ИИ и реальностью, что становится все более серьезной проблемой, отмечает Кирсти Рот, операционный директор Thomson Reuters.</p> <p>Полтора года назад сотрудники с энтузиазмом экспериментировали с ИИ, а их руководители с готовностью поддерживали эти исследования. Сегодня ситуация изменилась. Специалисты тратят токены на использование ИИ, а их руководители обеспокоены ростом расходов на ИТ. Учитывая, что исследования MIT показывают, что 95% проектов в области ИИ не приносят пользы, неудивительно, что компании начинают сомневаться.</p> <h3>ИИ крайне фрагментирован и раздроблен</h3> <p>«Люди начинают понимать, что эти технологии стоят больших денег, и они пока не обязательно видят от них пользу, — говорит Рот. — И поэтому разговор сводится к классическому вопросу управления изменениями: „Хорошо, у нас есть все эти технологии и все эти инструменты, но как мы можем реально изменить наши процессы и способы работы, чтобы быть более эффективными?“».</p> <p>Новые развивающиеся технологии, от агентных моделей ИИ до инструментов глубокого исследования, будут продолжать проникать в бизнес. Как считает генеральный директор Boomi Стив Лукас, общее положение дел в области ИИ крайне фрагментировано и раздроблено: «Сейчас профессионалы знакомятся со множеством терминов — передовые модели, частные модели, доменные модели, модели с открытыми весами, агентные структуры, агентные механизмы и агентные циклы — которые не существовали еще несколько месяцев назад, не говоря уже о нескольких годах».</p> <p>Рот, опираясь на исследование своей фирмы и личный опыт, предлагает компаниям и их специалистам, получающим выгоду от ИИ, сосредоточиться на двух областях: тщательных исследованиях и надежных сценариях использования в производстве.</p> <h3>Поддержка тщательных исследований</h3> <p>Профессионалы, принявшие участие в опросе, четко понимают, что должны делать их инструменты ИИ: защищать конфиденциальные данные (96%), обосновывать результаты авторитетным контентом (94%) и предоставлять объяснимые и обоснованные рассуждения (90%). Однако двое из пяти специалистов (41%), использующих ИИ в своей работе, отмечают, что у них нет доступа к высококачественным инструментам.</p> <p>Согласно исследованию, даже при наличии ИИ-стратегии ее реализация часто отстает. Чуть более трети (35%) специалистов в компаниях, имеющих четко определенную ИИ-стратегию, говорят, что этот подход не проявляется в их повседневной работе.</p> <p>По словам Рот, одно из объяснений — это то, что она называет «инструментальным взрывом» («tool blast»), когда организации навязывают сотрудникам широкий спектр ИИ-сервисов без четкого понимания бизнес-результатов. «Я слышала, как люди говорят: „Мне дали все это. Но что я должен с этим делать?“ Слишком многие компании не понимают, какие инструменты должны использовать сотрудники. Я думаю, что в этом случае очень трудно увидеть рост, за исключением того, что ваши затраты на ПО значительно возрастут», — отмечает она.</p> <p>Согласно <a href="https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure">прогнозу</a> Gartner, 40% предприятий к 2027 г. сократят использование или выведут из эксплуатации автономных агентов ИИ из-за опасений по поводу их ценности.</p> <p>Рот говорит, что вдумчивые бизнес-руководители ищут действенные решения на основе ИИ для сложных задач, предоставляя специалистам возможность изучать новые технологии, не принимая на себя слишком большого риска. Это то, что она делает в Thomson Reuters, где, по ее словам, придерживаются непредвзятого подхода к генеративному ИИ. «Если у вас появляется классный инструмент, и вы работаете в отделах маркетинга, продаж или программирования, и хотите его попробовать, мы позволим вам это сделать», — поясняет она.</p> <p>Рот отмечает, что вместо того, чтобы ориентироваться на целевые показатели затрат, компания поощряет людей тестировать инструменты ИИ и искать лучшие способы работы. «Мы говорим людям: „Вот инструменты. Переосмыслите, что вы можете сделать“, — рассказывает она. — Конечно, некоторые показывают себя лучше, чем другие, а некоторым требуется больше подсказок и помощи. Но мы поощряем людей думать о том, что эти инструменты могут сделать в современном мире. И этот подход, похоже, хорошо работает».</p> <p>Важным элементом этой стратегии, по мнению Рот, является четкое определение того, какие инструменты приносят пользу, а какие нет, и в последнем случае — прекращение исследований. «На начальном этапе мы пробовали всё подряд в течение примерно шести недель. Можно было получить лицензию практически на всё, что угодно, дать возможность своей команде поэкспериментировать с этим, в зависимости от того, в какой сфере вы работаете, — говорит она. — Мы тестировали результаты, и если они были хорошими, мы внедряли это в других командах. А если результаты были плохими, мы прекращали это и двигались дальше. Поэтому я думаю, что стратегия доступа и экспериментирования на раннем этапе действительно важна».</p> <h3>Определение надежных сценариев использования в производстве</h3> <p>По словам Рот, компании, опережающие конкурентов в области генеративного и агентного ИИ, — это те, кто превращает исследования в сервисы производственного уровня, в то время как отстающие этого не делают.</p> <p>«Успешные фирмы сейчас начинают говорить: „Хорошо, мы выбрали этот инструмент, и мы будем его использовать, и поэтому мы изменим наши бизнес-процессы, чтобы работать по-новому“, и тогда вы начинаете видеть улучшения и экономию», — говорит она, делая важное уточнение: «Однако по-прежнему кажется, что большинство компаний находятся на начальной стадии. Думаю, те, кто преуспевает, очень точно определяют свои сценарии использования».</p> <p>В Thomson Reuters конкретные сценарии использования сосредоточены на пяти ключевых областях: разработка ПО, поддержка и обеспечение успеха клиентов, маркетинг, редакционная и контентная деятельность, а также основные технологические операции.</p> <p>«Конечно, мы хотели бы улучшить работу каждого, и мы сделаем все возможное, — говорит Рот. — Но это пять основных областей, где мы видим наибольший прогресс, и им уделяется наибольшее внимание». Инструменты ИИ для этих областей отыскиваются, тестируются и внедряются, а затем измеряется их эффективность. Сегодня 87% сотрудников Thomson Reuters активно используют инструменты ИИ в своей повседневной работе.</p> <p>Итак, как выглядит успешное внедрение генеративного и агентного ИИ в масштабах всей организации, и как это изменило повседневную практику сотрудников?</p> <p>Рот приводит в пример службы поддержки клиентов и продаж, где сотрудники могут использовать внутреннюю платформу ИИ компании, известную как Open Arena, и передовую модель Claude.</p> <p>Вместо того чтобы тратить часы на сбор информации от торговых представителей и из платформы Salesforce, сотрудники могут использовать утвержденные сервисы ИИ для получения ответов на запросы за считанные секунды. «В этом новом мире вы можете написать запрос в Claude, чтобы получить эту информацию; он может составить вам сводку, понять, каковы ключевые возможности, где могут быть какие-либо риски для данного клиента, или обращался ли он недавно в службу поддержки и был чем-то недоволен, и вы можете гораздо быстрее хорошо подготовится к встрече», — рассказывает она.</p> <p>Сотрудники Thomson Reuters также используют ИИ для исследования рынка, составления документов и отслеживания прибыльности продуктов и услуг.</p> <p>Главное, что усвоила Рот при внедрении ИИ в производство, накопив за последние несколько лет немалый опыт внедрения ИИ в операционную реальность глобального коллектива из 27 тыс. человек, — это то, что бизнес-руководители должны усердно работать над преодолением страхов профессионалов.</p> <p>«Люди не любят перемен. Ключевым моментом на раннем этапе было разъяснение сути ИИ, а затем оставалось лишь дать людям возможность поэкспериментировать и, надеюсь, перестать бояться новых технологий, — говорит она. — Сейчас мы достигли гораздо более зрелого уровня, и, учитывая то, что нам удалось внедрить, я думаю, что направление развития и последовательность действий одинаково важны».</p> Исследования указывают на разрыв между амбициями в области искусственного интеллекта и реальной ситуацией … article https://www.itweek.ru/themes/detail.php?ID=235442 Tue, 01 Sep 2026 14:05:39 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne ITAM. Обновление сокращает время инвентаризации оборудования, позволяет учитывать активы не только по складам, но и по конкретным офисам и кабинетам, а также избавляет финансовые службы от ручных расчетов при работе с затратами в разных валютах.</p> <p>Ключевым нововведением версии 1.8.0 стала возможность подключения сканера штрихкодов при проведении инвентаризации склада. Ранее в системе была реализована инвентаризация с помощью камеры мобильного телефона — теперь к задаче можно подключить внешний сканер, который считывает штрихкод с инвентарным номером актива. Это ускоряет обход крупных складов: сканер считывает метки быстрее и точнее камеры телефона, а данные сразу сверяются со списком активов и попадают в ведомость инвентаризации без ручного переноса.</p> <p>Дополнительно в системе появился новый тип задачи — инвентаризация по расположению. Она позволяет пересчитывать активы не по складам, а по фактическому месту их использования — конкретному офису, этажу или кабинету, даже если по учету оборудование числится за разными складами. Это особенно удобно для компаний с распределенной сетью офисов: можно провести точечную проверку одного подразделения, не запуская инвентаризацию всего склада.</p> <p>В 1.8.0 автоматизирован расчет совокупных затрат на актив с учетом конвертации валют. Раньше, если затраты на актив фиксировались в разных валютах, посчитать реальную стоимость владения оборудованием можно было только вручную, сводя данные в отдельных таблицах. Теперь система автоматически складывает все затраты по активу и автоматически приводит их к единой валюте по актуальному курсу. Финансовые и ИТ-руководители получают точную картину затрат на актив без дополнительных расчетов и могут быстрее принимать решения о ремонте, замене или списании оборудования.</p> <p>«Когда данные о том, где стоит актив и сколько он реально стоит, хранятся в одной системе, ИТ-отдел начинает говорить с финансами на одном языке. Решения о ремонте, замене или списании принимаются на цифрах, а не на ощущениях. Именно так выглядит зрелый подход к управлению ИТ-активами», — отметил Руслан Шарипов, генеральный директор SimpleOne, корпорация ITG.</p> <p>SimpleOne ITAM 1.8.0 уже доступна для действующих клиентов компании. Новые пользователи могут запросить демонстрацию продукта на сайте SimpleOne.</p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.8.0 системы управления ИТ-активами SimpleOne … message https://www.itweek.ru/themes/detail.php?ID=235441 Tue, 01 Sep 2026 09:51:32 +0300 <p>С 1 сентября вступает в силу норма об идентификации администраторов доменов в зонах .ru, .рф и .su через портал «Госуслуги» (ЕСИА). Однако в крупнейшем корпоративном регистраторе Руцентре по состоянию на 27 августа процедуру прошли лишь 42,2% администраторов, а в самом массовом регистраторе Рег.ру — 25,7% пользователей. Юридические лица могут пройти идентификацию только у одного регистратора в России — Руцентра.</p> <p>Компания по управлению онлайн-активами Руцентр провела исследование безопасности доменной инфраструктуры российских компаний. Одной из ключевых тем стал уровень готовности к идентификации через ЕСИА, которая вводится с 1 сентября 2026 года согласно Федеральному закону от 29.12.2025 № <nobr>569-ФЗ.</nobr> В крупнейших игроках рынка идентификацию прошли меньше половины пользователей — в Руцентре 43% администраторов, а в Рег.ру лишь 26,7%. Ежедневно эти цифры прирастают на несколько процентных пунктов. Совокупно эти два регистратора занимают долю в 68% Рунета. Основные сложности связаны с несовпадением данных — многие домены оформлены на устаревшие данные, вымышленные имена, бывших сотрудников и фрилансеров. </p> <p>Ключевым барьером для прохождения идентификации остается многолетняя практика регистрации корпоративных доменов на физические лица. В 2026 году в зоне .ru на долю физических лиц приходится 72,7% доменов, в зоне .рф — 82,9%. При этом среди топ-5000 полезных для пользователей сайтов Рунета на физлица зарегистрировано 32% ресурсов. В случае увольнения администратора или его недоступности компания рискует остаться без возможности продлить или перенести критически важный онлайн-актив. </p> <p>Важно отметить, что нормативно-правовые акты, разъясняющие формат применения новой нормы закона, еще не приняты. Закон устанавливает новый порядок регистрации, при котором регистрировать домены смогут только регистраторы из специального перечня. Порядок включения регистраторов в перечень будет определен Правительством Российской Федерации в ближайшее время. Координационный центр доменов .RU/.РФ уведомил регистраторов, что работа аккредитованных регистраторов продолжится по действующим правилам до включения в перечень, либо до 18 января 2027 года. Это означает, что ограничения на операции с доменными именами для администраторов, еще не прошедших идентификацию, с 1 сентября пока применяться не будут.</p> <p>Наряду с регуляторными изменениями эксперты Руцентра зафиксировали рост внешних киберугроз, связанных с брендовым фишингом. 38,5% компаний столкнулись с появлением сайтов-имитаторов, еще 35,9% — со сканированием доменной инфраструктуры и попытками перехвата управления. Это подтверждается и ростом объема Whois-запросов к доменам почти вдвое — до 95 млн. за полугодие, из которых 83 млн. пришлись именно на корпоративные домены. Чаще всего мишенями атак становятся крупные онлайн-площадки. Злоумышленники целенаправленно собирают данные о владельцах ресурсов для последующего фишинга или перехвата управления. В то же время защита учетных записей администраторов остается слабым звеном. Доля пользователей с включенной двухфакторной аутентификацией составляет лишь <nobr>15-16%.</nobr></p> <p>Дополнительным системным риском стал массовый отзыв иностранных SSL/TLS-сертификатов. С июня по август 2026 года удостоверяющие центры отозвали 6 997 сертификата, из которых 4677 — от GlobalSign. Причина — введение санкционных проверок клиентов по требованию международного консорциума CA/Browser Forum. Доля российских сертификатов в зоне .ru составляет менее 1%, как и доля устройств с установленными отечественными корневыми сертификатами. После отзывов активные сертификаты Национального удостоверяющего центра выросли на 7,7% за неделю, а Технического центра Интернет — в 4,5 раза с начала июня 2026 года.</p> <p>Руцентр провел исследование безопасности доменной инфраструктуры российских компаний уже во второй раз. Предыдущее исследование было выпущено в сентябре 2025 года. В 2026 году к созданию исследования присоединилась компания Технический центр Интернет, технический оператор российской национальной доменной зоны верхнего уровня, которая предоставила дополнительные данные о ситуации на рынке SSL/TLS-сертификатов. Как и в прошлый раз исследование содержит две части, включающие количественный и качественный анализ. Методология построена на анализе системных метрик и операционных показателей, отражающих состояние защищенности онлайн-активов на уровне всего доменного рынка в Российской Федерации. В опросе принимали участие представители ИТ- и ИБ-подразделений компаний, преимущественно из сегмента крупного бизнеса, — почти 40% компаний с численностью свыше 1000 сотрудников. Сбор и обработка данных проводились экспертами Руцентра в августе 2026 года.</p> С 1 сентября вступает в силу норма об идентификации администраторов доменов в зонах .ru, .рф и .su через … message https://www.itweek.ru/themes/detail.php?ID=235439 Tue, 01 Sep 2026 09:42:15 +0300 <p>Российский рынок частных облаков последние несколько лет активно смещается в сторону OpenStack — как альтернативы ушедшим вендорам и как основы для построения отечественных платформ. OpenStack давно перестал быть экзотикой для узкого круга энтузиастов, ведь на нём сегодня строятся частные облака у операторов, банков и промышленных компаний, которым нужен контроль над инфраструктурой без привязки к одному вендору. Но у этого перехода есть обратная сторона, о которой на старте проекта задумываются реже, чем стоило бы: облако на OpenStack нужно не только развернуть, но и потом годами обновлять, своевременно реагируя на выявленные бреши в безопасности, устанавливая новые релизы компонентов и удовлетворяя требования регуляторов. И если сам факт перехода на OpenStack давно перестал быть новостью, то вопрос «а как это облако вообще обновлять, когда придёт время» у большинства эксплуатирующих команд до сих пор упирается в ручной труд, дефицитную экспертизу и риск простоя. То есть проблема не в том, чтобы просто поднять OpenStack, а в том, чтобы удерживать его в рабочем и безопасном состоянии на протяжении всего жизненного цикла. Разберёмся, почему обновление OpenStack остаётся сложной инженерной задачей, какие этапы этого процесса можно автоматизировать и какие ограничения необходимо заложить в механизм обновления, чтобы автоматизация сама не стала источником риска.</p> <h2> Проблема, о которую спотыкается почти каждый оператор облака </h2> <p>OpenStack принято хвалить за гибкость и открытость, но за кулисами этой гибкости стоит один из самых болезненных процессов в жизненном цикле облачной платформы — обновление. В отличие от монолитных систем, OpenStack — это фреймворк из полутора-двух десятков взаимозависимых сервисов (Keystone, Nova, Neutron, Cinder, Glance, Placement и т. д.), каждый со своей базой данных, своими миграциями схемы, своим порядком запуска и своими требованиями к совместимости версий API. Обновить такую систему не значит «поставить новую версию пакета». Это значит провести десятки взаимосвязанных операций в строго определённой последовательности, не нарушив по пути ни одну зависимость.</p> <p>Именно поэтому в большинстве продуктивных инсталляций OpenStack обновление до сих пор остаётся ручной, экспертной и тревожной процедурой, а не рутинной операцией.</p> <h2>Что именно усложняет обновление OpenStack</h2> <p>Если разложить проблему на составляющие, получится примерно такой список (и он актуален независимо от того, разворачивается ли OpenStack «руками», через Ansible-плейбуки или через Kubernetes-операторы):</p> <ul> <li><strong>Порядок и зависимости сервисов.</strong> Часть компонентов должна обновляться раньше других — например, Keystone и Placement обычно идут в начале цепочки, а сервисы, зависящие от их API, следом. Ошибка в порядке приводит к рассинхронизации версий API между сервисами и падению запросов.</li> <li><strong>Миграции баз данных.</strong> Каждое обновление тянет за собой миграции схем в базах Nova, Neutron, Cinder и других сервисов. Некоторые миграции требуют «миграции данных без остановки» ещё на текущей версии — если этот шаг пропущен, обновление может завершиться с повреждением данных.</li> <li><strong>Простой сервисов управления и, в худшем случае, сетей и вычислительных ресурсов пользователей.</strong> Даже при аккуратном планировании слой управления обычно недоступен часть времени обновления. Плохо спроектированный процесс способен зацепить и вычислительные ресурсы пользователей — то есть повлиять на уже работающие виртуальные машины и пространство пользователей.</li> <li><strong>Непредсказуемое поведение при сбое посередине процесса.</strong> Полноценный откат обновления OpenStack на предыдущую версию сама по себе нетривиальная и рискованная операция: схемы БД уже частично мигрированы, часть контейнеров и конфигураций уже обновлена, и «просто вернуть как было» технически далеко не всегда возможно. Поэтому куда важнее другое качество процесса — способность вовремя остановиться в момент сбоя, не разрушив кластер, и точно показать администратору, на каком шаге и что пошло не так, вместо того чтобы продолжать обновление вслепую или бросить систему в непонятном промежуточном состоянии.</li> <li><strong>Человеческий фактор и разрыв компетенций.</strong> Классический процесс обновления — это последовательность команд в CLI, правка YAML-файлов инвентаря и конфигурации, запуск плейбуков с нужными флагами в нужном порядке. Уровень экспертизы, который для этого требуется, есть далеко не в каждой команде эксплуатации, а дефицит сертифицированных OpenStack-инженеров на рынке — известная проблема.</li> <li><strong>Долгий цикл патчинга безопасности.</strong> Когда обновление — это рискованный процесс и многочасовая процедура, а не «нажал кнопку и забыл», критические обновления безопасности откладываются дольше, чем следовало бы. Разрыв между выходом патча и его применением в продуктиве — это прямой риск для периметра.</li> <li><strong>Дрейф конфигурации между средами.</strong> В компаниях с несколькими окружениями (dev/test/prod) ручные обновления быстро приводят к тому, что конфигурации расходятся, и то, что сработало на тесте, ломается в проде именно из-за незамеченного отличия.</li> </ul> <h2>Как эти проблемы решаются (или не решаются) в разных реализациях OpenStack</h2> <p>Здесь стоит сразу отметить: экосистема способов развернуть OpenStack довольно широкая, и подход к обновлению принципиально различается в зависимости от выбранного инструментария.</p> <ul> <li> <strong>Kolla-Ansible</strong> (в том числе на связке с Docker или Podman) разворачивает сервисы в контейнерах и обновляет их через Ansible-плейбуки (kolla-ansible upgrade). Классически это <nobr>CLI-процедура:</nobr> инженер вручную правит globals.yml, инвентарь, версии тегов образов и запускает плейбук, понимая, что происходит на каждом шаге. Вынос процесса в CI/CD позволяет сделать обновление воспроизводимым и версионируемым, а также сократить количество ручных операций. Но сам по себе CI/CD не снимает требования к квалификации специалиста. Кто-то по-прежнему должен понимать структуру пайплайна, интерпретировать результаты выполнения отдельных стадий и принимать решение при ошибках. Поэтому автоматизация исполнения и автоматизация принятия решений при обновлении — это разные задачи.</li> <li> <strong>OpenStack-Ansible (OSA)</strong> концептуально близок к Kolla-Ansible, но использует <nobr>LXC-контейнеры</nobr> или venv вместо Docker/Podman-образов. Процесс обновления так же построен на плейбуках и так же требует ручного сопровождения и экспертизы.</li> <li> <strong>TripleO / director-based установки</strong> (классический подход Red Hat OpenStack Platform до недавних версий) добавляют ещё один слой сложности — undercloud и overcloud обновляются отдельно, а сам процесс исторически считался одним из самых трудоёмких в экосистеме.</li> <li> <strong>Charmed OpenStack от Canonical</strong> на базе Juju ближе всего к идее «графического» управления жизненным циклом: Juju GUI позволяет визуально управлять обновлением charms, что снижает порог входа по сравнению с чистым CLI, хотя полноценной автоматизации «в один клик» с предварительными проверками и остановкой на проблемном шаге это тоже не даёт из коробки.</li> <li><strong>MicroStack / Sunbeam</strong> (тоже Canonical, snap-based) упрощают обновления до команды snap refresh, но это решение ориентировано на небольшие и edge-инсталляции, а не на полномасштабные продуктивные облака.</li> <li><strong>Kubernetes-нативные подходы</strong> (OpenStack-Helm, Airship, а также коммерческий Mirantis OpenStack for Kubernetes) выигрывают за счёт того, что опираются на нативные механизмы Kubernetes — поэтапное обновление, readiness/liveness probes, helm rollback. Именно в этом сегменте чаще всего встречаются продукты с полноценным веб-интерфейсом управления обновлениями, потому что Kubernetes-примитивы изначально спроектированы для автоматизации подобных процессов.</li> </ul> <p>Общий вывод, к которому подводит этот обзор, хочется сформулировать следующим образом. Проблема «обновление зависит от инженера с CLI» и проблема «обновление недоступно как самообслуживаемая операция» — это два разных уровня, и решаются они не одним и тем же шагом. Вынос процесса в CI/CD (как в случае с GitLab у связки Kolla-Ansible/Podman) решает первую: обновление становится воспроизводимым, версионируемым и не требует ручных команд в терминале. Но оно не решает вторую — запустить и проконтролировать пайплайн по-прежнему может только тот, кто ориентируется в GitLab, а не в продукте, которым он управляет. Поэтому интерфейс с кнопкой запуска сам по себе ещё не делает обновление автоматизированным. Существеннее то, какие проверки выполняются до старта, как система учитывает зависимости компонентов, может ли она остановить процесс при ошибке и насколько подробно сообщает администратору о состоянии инфраструктуры. Именно эти механизмы определяют, можно ли передать часть решений от инженера автоматике.</p> <h2>Что должно скрываться за кнопкой автоматического обновления</h2> <p>Автоматизация обновления OpenStack не сводится к переносу последовательности команд из CLI в CI/CD. Пайплайн может выполнять подготовленные операции, фиксировать стадии и сохранять результаты их выполнения. Но сам по себе он не определяет, какие действия допустимы в текущем состоянии инфраструктуры, в какой последовательности их выполнять и когда процесс необходимо остановить.</p> <p>Поэтому поверх исполнительного слоя нужна логика, которая учитывает зависимости сервисов OpenStack, совместимость версий, состояние узлов и результаты проверок после каждого этапа. Иначе автоматизируется только запуск команд, а принятие решений по-прежнему остается на инженере.</p> <p>При этом важно разделять два разных процесса: обновление хостовой операционной системы и переход на новую версию самого OpenStack. Внешне они похожи, но предъявляют разные требования к последовательности операций и допустимому уровню параллелизма.</p> <h3>Патчинг хостовой ОС: ротация узлов</h3> <p>При установке пакетов и обновлений безопасности на контроллерах и гипервизорах можно использовать принцип последовательной ротации.</p> <p>Контроллер выводится в режим обслуживания, получает обновления, при необходимости перезагружается и возвращается в кластер. Только после проверки его состояния процесс переходит к следующему узлу. Пока один контроллер обслуживается, остальные продолжают обрабатывать запросы, что позволяет сохранить доступность управляющего слоя.</p> <p>Для гипервизоров возможна другая схема: обновление по одному узлу или группами в пределах зоны доступности. Размер такой группы должен учитывать доступный запас вычислительных ресурсов. Перед обслуживанием с гипервизора переносятся виртуальные машины, сам узел выводится из эксплуатации, обновляется и после проверки возвращается в строй.</p> <p>Одновременно выводить в обслуживание все гипервизоры одной зоны доступности нельзя. Поэтому механизм автоматизации должен ограничивать уровень параллелизма и учитывать, достаточно ли оставшихся ресурсов для размещения нагрузки.</p> <p>Такая схема особенно важна для установки обновлений безопасности. Ее задача не просто ускорить патчинг, а формализовать операции, которые при ручном выполнении зависят от последовательности действий конкретного инженера: миграцию нагрузки, перевод узла в обслуживание, установку обновлений, перезагрузку и проверку его состояния перед переходом к следующему этапу.</p> <h3>Обновление версии OpenStack: почему поэтапность не всегда означает меньший риск</h3> <p>При переходе между версиями OpenStack логика сложнее. До начала обновления нужно определить, поддерживается ли переход между исходным и целевым релизами. Для этого может использоваться заранее подготовленная матрица совместимости, учитывающая версии компонентов и допустимые маршруты обновления.</p> <p>Отдельный вопрос — порядок обновления контроллеров. Интуитивно безопасной кажется последовательная схема, при которой узлы переводятся на новую версию один за другим. Однако для конкретной архитектуры такой подход необходимо проверять с учетом совместимости API и компонентов. Если часть сервисов уже работает на новой версии, а часть остается на старой, может возникнуть период, когда управляющий слой работает в несогласованном состоянии.</p> <p>Поэтому последовательность операций должна определяться не универсальным принципом «обновлять по одному», а особенностями конкретного релиза и архитектуры развертывания.</p> <p>Не менее важен контроль состояния системы во время перехода. До старта должны выполняться системные проверки. После критических операций необходимо проверять работоспособность компонентов. Если очередная проверка не пройдена, дальнейшие действия следует остановить и зафиксировать этап, на котором возникла ошибка.</p> <p>Для OpenStack такой сценарий зачастую безопаснее попытки автоматически вернуть всю систему в исходное состояние. Если часть схем баз данных уже мигрирована, а некоторые компоненты обновлены, полноценный откат может оказаться отдельной сложной и рискованной процедурой. Поэтому от механизма автоматизации требуется прежде всего контролируемая остановка и точная диагностика.</p> <p>Очередность обновления контроллеров и гипервизоров также должна учитывать зависимости между управляющим и вычислительным слоями. Переход вычислительных узлов на новую версию следует начинать только после того, как управляющий слой приведен в согласованное состояние. После этого гипервизоры можно обновлять по одному или группами, предварительно освобождая их от пользовательской нагрузки.</p> <h3>Что именно нужно автоматизировать</h3> <p>При оценке механизма обновления OpenStack важно смотреть не только на инструмент, который исполняет команды. Ansible, CI/CD или Kubernetes позволяют автоматизировать значительную часть технических операций, но сами по себе не определяют, можно ли выполнять конкретное обновление в текущем состоянии инфраструктуры.</p> <p>Более высокий уровень автоматизации появляется там, где формализована логика принятия решений: проверяется допустимость перехода между версиями, учитывается состояние компонентов, контролируется размер одновременно обслуживаемой группы узлов, соблюдается очередность между управляющим и вычислительным слоями, а дальнейшие действия блокируются при возникновении ошибки.</p> <p>Именно поэтому перенос команд из терминала в пайплайн решает только часть задачи. Он делает процесс воспроизводимым и версионируемым, но не заменяет механизм управления жизненным циклом облачной платформы.</p> <h3>Что должен видеть администратор</h3> <p>Способ запуска обновления вторичен. Это может быть CLI, CI/CD или графический интерфейс. Гораздо важнее, какую информацию получает администратор до начала процесса и во время его выполнения.</p> <p>До старта обновления должны быть понятны текущие версии компонентов, доступный целевой релиз, результаты предварительных проверок и ограничения выбранного сценария. Во время обновления необходимы данные о текущем этапе, состоянии узлов и возникших ошибках.</p> <p>Задача интерфейса в данном случае не в том, чтобы скрыть сложность OpenStack за одной кнопкой. Он должен дать администратору понятную точку управления процессом, тогда как правила последовательности, совместимости и безопасной остановки должны соблюдаться автоматически.</p> <h3>От чего зависит длительность обновления</h3> <p>Продолжительность обновления нельзя свести к одному нормативному значению. Она зависит от числа узлов, состава компонентов, объема миграций, пользовательской нагрузки и расстояния между исходным и целевым релизами.</p> <p>Последовательный переход между соседними релизами, как правило, требует меньше промежуточных изменений. Если же обновление затрагивает несколько релизов, приходится учитывать больше изменений в компонентах, схемах баз данных и конфигурациях.</p> <p>Отдельно в технологическое окно закладывается время на освобождение гипервизоров от нагрузки, миграцию виртуальных машин, обслуживание узлов и проверки после обновления. Поэтому задача автоматизации состоит не только в сокращении общей продолжительности процедуры. Не менее важно сделать состав операций и их последовательность предсказуемыми, чтобы окно обслуживания можно было планировать заранее.</p> <h3>Почему обновление нужно тестировать заранее</h3> <p>Автоматизация не отменяет предварительной подготовки обновления. Для каждого поддерживаемого перехода необходимо проверить совместимость компонентов, миграции баз данных, последовательность операций и работу основных сценариев после установки новой версии.</p> <p>Чем больше расстояние между исходным и целевым релизами, тем больше промежуточных изменений приходится учитывать. Поэтому наличие новой версии OpenStack еще не означает, что на нее можно безопасно перейти из любого предыдущего состояния.</p> <p>Для эксплуатации это означает, что маршрут обновления должен быть заранее определен и протестирован. Автоматический механизм затем воспроизводит уже проверенную последовательность, контролируя состояние системы на каждом критическом этапе.</p> <h2>Когда обновление OpenStack действительно можно считать автоматизированным</h2> <p>Кнопка запуска сама по себе еще не делает обновление автоматическим. За ней может находиться тот же набор команд, который раньше инженер последовательно выполнял вручную.</p> <p>Более зрелый подход начинается с автоматизации не только исполнения, но и части решений. Система проверяет состояние инфраструктуры до старта, учитывает совместимость версий и зависимости компонентов, ограничивает потенциально опасный параллелизм, контролирует результат отдельных операций и прекращает дальнейшие действия, если состояние системы отклоняется от ожидаемого.</p> <p>При этом полностью исключить инженерную экспертизу невозможно. OpenStack остается сложной распределенной системой, а нестандартные ошибки могут требовать ручной диагностики. Задача автоматизации в другом: убрать из регулярного процесса повторяющиеся операции и решения, которые можно формализовать, снизить зависимость результата от ручных действий и оставить специалистам действительно нестандартные ситуации.</p> <p>Поэтому зрелость механизма обновления определяется не количеством операций, сведенных к одному нажатию, а тем, насколько предсказуемо система проходит штатный сценарий и насколько управляемо ведет себя при возникновении ошибки. По мере роста OpenStack-инфраструктуры такая автоматизация становится частью управления ее жизненным циклом, поскольку без нее увеличиваются трудозатраты на эксплуатацию и зависимость от ручных операций.</p> <p> #IMAGE_235440#</p> Российский рынок частных облаков последние несколько лет активно смещается в сторону OpenStack — как альтернативы … article Кирилл Острогожский, архитектор компании ITKey https://www.itweek.ru/themes/detail.php?ID=235438 Tue, 01 Sep 2026 09:20:51 +0300 <p><em>Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку объем телеметрических данных в ближайшие два года вырастет на порядок, конвейеры наблюдаемости становятся контрольным звеном, сообщает портал </em><em>The</em> <em>New</em> <em>Stack</em><em>.</em></p> <p>По мере того как компании переходят от экспериментов с ИИ к запуску автономных агентов в производственной среде, возникает проблема, связанная с инфраструктурой: растущие расходы на телеметрию. Недетерминированные, итеративные агенты, способные генерировать данные со скоростью машин, гораздо сложнее поддаются мониторингу, а расходы на них спрогнозировать гораздо сложнее, чем в случае с обычными приложениями.</p> <p>Многие компании испытывают трудности с выделением и обоснованием расходов на телеметрию. Согласно <a href="https://www.prnewswire.com/news-releases/new-apica-research-agentic-ai-poised-to-trigger-9-5x-telemetry-data-explosion-leaving-most-enterprises-exposed-302789312.html">опросу</a> более 300 руководителей в сфере корпоративных ИТ в Северной Америке и Западной Европе, проведенному Omdia/Informa TechTarget по заказу Apica, 59% организаций уже прекратили или отложили внедрение ИИ-агентов из-за расходов на мониторинг.</p> <p>Чаще всего это происходит при внедрении ИИ-агентов в критически важных областях: например, в сферах кибербезопасности, соблюдения нормативных требований и выявления мошенничества. По мере роста расходов на мониторинг, проекты по внедрению ИИ-агентов далеко не всегда закрываются по инициативе инженерных команд. Чаще всего их закрывает финансовый отдел.</p> <p>Энди Манн, директор по продуктам и технологиям Apica, недавно стал свидетелем того, как это произошло в одном крупном банке. Организация не смогла точно определить свои затраты на программы ИИ. «Они поняли, что не могут позволить себе продолжать в том же духе, поэтому у них не было другого выбора, кроме как отменить некоторые программы ИИ, — рассказывает он. — Я уже сталкивался с такими вещами, потому что ИИ-проекты легко съедают типичные бюджеты».</p> <p>Последствия огромны. По мере того, как люди, финансирование и ресурсы мониторинга перенаправляются на новые рабочие нагрузки ИИ, другие подразделения бизнеса начинают страдать. Манн говорит, что он видит перебои в работе, простои и атаки с проникновением, а средства защиты от DDoS-атак конкурируют за одни и те же ресурсы.</p> <p>Исследование Apica также выявило эту проблему. Только за последний год на большинстве предприятий (54%) объем телеметрии утроился, причем 43% этого роста приходится на рабочие нагрузки ИИ/машинного обучения, что, безусловно, является основным фактором. Предприятия вынуждены бороться с этим кризисом, поскольку их расходы на наблюдаемость растут. Они сообщают, что тратят в среднем 3,17 млн. долл. на обеспечение наблюдаемости, причем эта цифра растет на 28% в годовом исчислении и предела этому росту не видно. Неудивительно, что 83% опрошенных считают ИИ-наблюдаемость главным приоритетом на ближайший год.</p> <h3>Грядущая волна может оказаться катастрофической</h3> <p>При появлении нового облачного сервиса, базы данных или приложения нагрузка на систему мониторинга и объем телеметрических данных обычно увеличиваются на относительно предсказуемую величину. Но сейчас компании прогнозируют, что в течение двух лет объем телеметрических данных вырастет в среднем в 9,5 раза. Около 44% организаций ожидают, что объем телеметрических данных вырастет в <nobr>6-100 раз.</nobr></p> <p>«Представьте, что ваш счет по кредитной карте или чек из супермаркета выросли почти на порядок. Это уже не просто увеличение. Это не плавный рост, а стремительный взлет, и это вызывает панику», — говорит Манн.</p> <p>Причина в том, что работа агента — это не то же самое, что отдельный запрос к приложению. Задача службы поддержки может включать в себя трассировку верхнего уровня, несколько вызовов модели, операции извлечения данных, вызовы инструментов, повторные попытки и циклы. Но если агент делегирует работу другому агенту, это добавляет в трассировку еще одну ветвь.</p> <p>Каждая модель может генерировать данные о токенах, задержках, затратах и поставщиках, а каждый вызов инструмента создает собственные записи об аргументах, результатах, статусе и последующих действиях. Идентификаторы, такие как <em>tool_name</em>, <em>agent_id</em> и <em>trace_id</em>, также создают избыточность данных, из-за чего их сложнее агрегировать и дороже индексировать, и затраты растут на каждом этапе.</p> <p>Это создает ощутимый разрыв между амбициями в области ИИ и готовностью инфраструктуры. Несмотря на то, что 35% компаний заявляют о широком внедрении агентного ИИ, эксплуатация и управление такими системами сильно отличаются от того, что было раньше. Почти две трети компаний лишь в некоторой степени готовы к таким изменениям. В отличие от обычных приложений, агенты могут вызывать множество моделей и инструментов, повторно выполнять задачи или расширять рабочий процесс непредсказуемым образом, из-за чего сложно спрогнозировать затраты на обеспечение производительности и мониторинг.</p> <h3>От огромных затрат на телеметрию до уровня контроля на входе</h3> <p>По словам Манна, решение заключается в том, чтобы вмешаться на более ранних этапах. «Нельзя бесконечно отправлять практически бесполезные данные на дорогостоящую центральную аналитическую платформу или платформу хранения данных, потому что нет смысла анализировать данные, которые говорят о том, что все в порядке, — говорит он. — Как можно раньше подключите конвейер к сборщикам данных и управляйте ими на уровне источника».</p> <p>Традиционные платформы наблюдаемости ориентированы на сбор данных, их прием, хранение и индексацию, а затем анализ. Такая модель подходила для рабочих процессов, управляемых людьми и анализируемых с помощью дашбордов, но для агентного ИИ необходимо принимать решения до того, как телеметрия дойдет до наиболее затратных частей стека.</p> <p>Архитектура, ориентированная на конвейер, позволяет отбирать повторяющиеся успешные события, сохраняя при этом данные о сбоях, повторных попытках, нарушениях политик и аномально медленных трассировках. Она позволяет дополнять записи данными об агенте, сеансе, модели, инструменте, токене и предполагаемой стоимости, удалять конфиденциальные запросы и идентификаторы, а также агрегировать метрики и долгосрочные записи и отправлять их в места назначения с разными профилями затрат и хранения.</p> <p>Компактная метрика или выборка могут отражать обычный успешный вызов инструмента, в то время как при неудачном вызове сохраняется родительская трассировка, сведения об ошибке, история повторных попыток и контекст безопасности. Цель состоит в том, чтобы сохранить информацию, необходимую для объяснения поведения агента, сократив при этом объем избыточных данных и ограничив объем индексируемой информации.</p> <p>Агентам также необходим контекст на уровне миллисекунд для принятия автономных решений. Обработка телеметрии в непосредственной близости от источника позволяет организациям быстро выявлять ситуации, когда происходит слишком много повторных попыток, чрезмерное количество циклов использования инструментов или аномально высокий расход токенов, не дожидаясь, пока данные будут собраны и проиндексированы централизованно.</p> <p>Без контроля на уровне источника компании рискуют передавать фрагментированные и ненужные телеметрические данные на платформы, которые взимают плату за каждый дополнительный гигабайт, индекс и сохраненную запись.</p> <h3>Архитектура, которая отделяет победителей от проигравших</h3> <p>Трудно не заметить, насколько выгоден подход, при котором переосмысливается конвейер сбора телеметрических данных. Использующие его компании на 50% лучше подготовлены к росту объемов данных, связанному с агентным ИИ. Именно внедрение такого подхода выделяет зрелые организации, использующие агентный ИИ, на фоне конкурентов: такие организации на 80% реже сталкиваются с проблемами, связанными с операционными расходами, которые мешают их конкурентам.</p> <p>Решение заключается в том, чтобы перенести аналитические функции на более ранние этапы. Вместо того чтобы рассматривать платформу наблюдаемости как универсальный инструмент, компании могут принимать решения о том, какие телеметрические данные использовать, еще до того, как они попадут на платформу, — отфильтровывая ненужную информацию, выделяя то, что действительно важно, и маршрутизируя данные в соответствии с их ценностью и назначением. Это означает, что в дорогостоящие системы хранения и анализа будет поступать меньше данных, а та информация, которая все же попадет в эти системы, будет более полезной и доступной в режиме реального времени.</p> <p>Важно отметить, что речь не идет о полном отказе от платформ наблюдаемости, на которые уже полагаются компании. Речь идет о том, чтобы создать перед ними более интеллектуальный контрольный слой, который будет решать, какие данные заслуживают обработки, куда их следует направлять и сколько это будет стоить.</p> <p>Существующие платформы наблюдаемости по-прежнему играют важную роль. «Конвейер не может делать все, но он может взять на себя первичную обработку данных, — говорит Манн. — Вы по-прежнему работаете с крупными аналитическими платформами, но при этом экономите деньги, снижаете риски и повышаете эффективность соблюдения нормативных требований».</p> <p>Согласно исследованию Apica, контрольный конвейер, базовые метрики и сервисы подготовки данных позволяют снизить совокупную стоимость владения на 40% по сравнению с унаследованными платформами наблюдаемости. Разумеется, фактическая экономия будет зависеть от объемов телеметрии, политики хранения данных, правил выборки, решений по маршрутизации, действующих контрактов и доли данных, которые можно обработать до приема в систему.</p> <p>Сейчас самое время пересмотреть архитектуру. Около 68% компаний планируют в течение следующих шести месяцев оценить изменения в своей системе наблюдаемости, а почти четверть из них заявляют, что существующие отношения с поставщиками не будут играть существенной роли при принятии этих решений. Следующий этап развития системы наблюдаемости будет связан с умением справляться с тем, что ИИ будет «выбрасывать» в инфраструктуру.</p> <p>Это означает, что конвейер больше нельзя рассматривать как систему, которая просто перемещает телеметрические данные из пункта А в пункт Б. Он становится управляющим слоем для все более автономной и требовательной к данным среды.</p> <p>Организации, которые создадут инфраструктуру, готовую к работе с агентным ИИ, смогут снизить затраты на наблюдаемость и повысить эффективность управления рисками. Манн не считает, что у платформенных инженеров и SRE-команд есть большой выбор. «Это уже становится решением на уровне совета директоров, — говорит он. — В конечном счете, это выбор того, насколько разумно вы можете позволить себе вести свой бизнес».</p> Финансовые, а не инженерные аспекты губят проекты по внедрению агентного искусственного интеллекта. Поскольку … article https://www.itweek.ru/themes/detail.php?ID=235436 Mon, 31 Aug 2026 18:03:03 +0300 <p>Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное на выявление наиболее востребованных направлений использования платформенных решений в ключевых отраслях России в 1 полугодии 2026 года. Данные были получены по итогам анализа проектной практики STAQ за 1 полугодие 2026 года.</p> <p>По данным анализа проектов и клиентских запросов STAQ за январь-июнь 2026 года наиболее активно платформенные решения применялись в трёх ключевых отраслях: промышленное производство, розничная торговля и транспорт. Помимо этих индустрий, можно выделить строительство и управление инфраструктурными объектами, добывающую промышленность, телекоммуникации, агропромышленный комплекс и финансовый сектор. В этих сегментах платформы востребованы прежде всего для управления заявками и инцидентами, контроля эксплуатации оборудования, координации выездных сотрудников и соблюдения SLA. </p> <p>Существуют важные причины востребованности платформ в данных отраслях. Первая причина — высокая стоимость простоев и операционных ошибок. Остановка производственной линии, кассового оборудования, склада или транспортного узла быстро приводит к прямым финансовым потерям, нарушению графиков и снижению качества обслуживания. Вторая причина — большое число распределенных процессов. Предприятиям нужно одновременно управлять оборудованием, заявками, сотрудниками, выездными бригадами и подрядчиками на сотнях объектов. Третья причина — переход от разрозненной автоматизации к единому цифровому контуру. Компании стремятся связать существующие ERP, WMS, POS, MES, SCADA, IoT-системы и внутренние базы данных без полной перестройки ИТ-ландшафта.</p> <p>На промышленных предприятиях платформенные решения чаще всего использовались по следующим направлениям: управление производственными заданиями и сменной отчетностью, техническое обслуживание и ремонт оборудования, мониторинг технологических параметров с использованием IoT и SCADA, управление качеством, инцидентами и отклонениями. Отдельное направление — задачи, которые традиционно относят к контуру MES: сменные задания, отчётность по выпуску, регистрация отклонений и контроль исполнения на уровне цеха. </p> <p>По данным аналитиков STAQ, в среднем по проектам, применение платформ на производственных предприятиях в 1 полугодии 2026 года позволило в сравнении с показателями до внедрения: сократить затраты на внеплановые ремонты на 21%, уменьшить количество незапланированных простоев на 28%, ускорить реакцию на выявленные дефекты на 16%. Данные начали использоваться не только для отчетности. Система автоматически формирует задачу при обнаружении отклонения, назначает ответственного, контролирует срок выполнения и сохраняет результат.</p> <p>Основными направлениями использования платформ в розничной торговле стали: централизация заявок от магазинов и других торговых объектов, обслуживание касс, холодильников, торговых автоматов и инженерных систем, управление мерчандайзерами, техническими специалистами и подрядчиками, контроль SLA, наличия товаров и качества обслуживания торговых точек. Вместо обращений по телефону, электронной почте и в мессенджерах торговая сеть получает единую точку входа. Заявки автоматически распределяются по региону, типу проблемы, приоритету и компетенции исполнителя. В одном из проектов STAQ была централизована обработка заявок более чем из 300 магазинов. В сравнении с периодом до внедрения сроки исполнения заявок сократились на 30%, количество случаев отсутствия товара из-за отказов оборудования уменьшилось на 50%, более 20% заявок стали обрабатываться без участия человека, а среднее число заявок, закрываемых одним диспетчером за смену, выросло на 60%.</p> <p>В транспортно-логистической отрасли платформы применялись для управления техническим состоянием транспорта и инфраструктуры, планирования ТОиР и внеплановых ремонтов, диспетчеризации и контроля исполнения рейсов, обработки ИТ- и инфраструктурных инцидентов, управления подрядными перевозчиками и соблюдения SLA. В одном из проектов STAQ для крупной логистической компании количество инцидентов, влияющих на операционные процессы, сократилось на 47%, выполнение SLA по критичным системам достигло 94%, а простои стоек регистрации уменьшились на 62%. Интеграция с ERP также позволила ускорить закупку запасных частей на два дня. Основной результат использования платформ для транспортно-логистической отрасли — сокращение незапланированных остановок и переход от ручной диспетчеризации к управлению на основании данных.</p> <p>Во 2 полугодии 2026 года STAQ ожидает сохранения спроса на платформенные решения со стороны промышленности, ритейла и логистики, но при более консервативном отношении к ИТ-бюджетам: в приоритете будут проекты с измеримой и быстрой окупаемостью, а повестка сместится с роста выручки на сокращение операционных затрат. Изменится характер проектов: компании будут чаще переходить от автоматизации отдельного процесса к тиражированию решений на несколько площадок. Основными направлениями развития станут: предиктивное обслуживание оборудования на основе IoT-данных, применение ИИ для классификации заявок, выявления отклонений и поддержки диспетчеров, объединение производственных, эксплуатационных и сервисных процессов на одной платформе. Кроме того, компании осуществят более глубокую интеграцию с ERP, WMS, POS, MES и SCADA. </p> <p>«В 1 полугодии 2026 года платформенный подход вышел за рамки простой замены бумажных процессов цифровыми. Компании используют платформы как операционный контур, который связывает оборудование, сотрудников, подрядчиков и управленческую аналитику. Мы видим, что ожидания от предиктивной аналитики и ИИ сегодня опережают готовность данных: пока не выстроен учёт оборудования, заявок и истории ремонтов, модели не на чем обучать. Поэтому ближайший этап для большинства компаний — не новые технологии, а качество эксплуатационных данных», — отметил Евгений Гусев, генеральный директор STAQ.</p> Аналитический центр проекта STAQ, предназначенного для цифровизации бизнес-процессов, провел исследование, направленное … message https://www.itweek.ru/themes/detail.php?ID=235435 Mon, 31 Aug 2026 18:01:51 +0300 <p>Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась в российской корпоративной практике. По оценке экспертов «Кросстеха», до 90% сотрудников организаций используют личные устройства для решения рабочих задач. Внедрение BYOD или отдельных элементов концепции выгодно бизнесу, так как позволяет сократить расходы на оборудование и создать более комфортные условия работы для сотрудников. При этом зачастую внедрение происходит без должной подготовки, что потенциально может привести к серьезным инцидентам информационной безопасности. Около 70% организаций внедряют этот подход с ошибками, создавая дополнительные киберриски, которые могут приводить к утечкам данных и другим инцидентам информационной безопасности безопасности</p> <p>Главная ошибка — попытка управлять чужой техникой через крайности. Первая крайность — полная вседозволенность. Когда компания не задает правил, менеджер скачивает договор на личный смартфон, чтобы доработать его вечером дома. Если этот телефон потеряется в такси или попадет в руки ребенку, который случайно установит вредоносную игру, корпоративная тайна мгновенно станет публичной. </p> <p>Вторая крайность — тотальная слежка и гиперопека. Когда отдел безопасности требует установить на личный ПК программы, которые отслеживают все действия пользователя, сотрудники воспринимают это как вторжение в личную жизнь. В ответ возникает «Теневое ИТ»: вместо разрешенных каналов специалисты начинают тихо пересылать рабочие документы в личные мессенджеры и сторонние хранилища, полностью скрывая эти процессы от компании.</p> <p>«Адекватный путь внедрения BYOD строится не на полном контроле устройства, а на понятном разделении личного и рабочего пространства. Главный принцип — компании должно быть важно только то, как обрабатываются ее данные, а не то, чем занимается человек в свое свободное время на своем устройстве», — говорит Егор Норкин, архитектор ИБ компании «Кросстех».</p> <p>Наиболее эффективный подход к BYOD строится на трех ключевых мерах: изоляции рабочего контура на личных устройствах, разграничении доступа к критичным системам и прозрачных правилах взаимодействия. На смартфонах рабочая среда прячется в зашифрованный контейнер, исключающий утечки и позволяющий точечно удалить данные компании при увольнении. Для домашних ПК организуется защищенный доступ через выделенные рабочие столы без прямой связи с внутренней сетью, а все требования к технике, компенсации и технической поддержке фиксируются в понятном регламенте. </p> <p>«ИБ сегодня — это баланс между сохранностью данных, бизнес-целями и комфортом людей. Бизнес всегда в приоритете, но рабочие процессы должны быть устроены так, чтобы они не были уязвимы. BYOD — отличная концепция, если решить это уравнение правильно. Сделать личную технику сотрудников безопасной абсолютно реально: достаточно грамотно оценить риски, разграничить корпоративный контур и уходить в крайности», — отметил Егор Норкин.</p> Концепция Bring Your Own Device (BYOD), когда сотрудники работают с личных гаджетов, окончательно закрепилась … message https://www.itweek.ru/themes/detail.php?ID=235434 Mon, 31 Aug 2026 12:42:28 +0300 <p>Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM. Система адаптирована для широкой линейки ARM-оборудования — от российских процессоров «Байкал» до популярных одноплатных компьютеров.</p> <p>РЕД ОС под ARM может применяться при создании встраиваемых систем, IoT-устройств, учебных стендов и серверных решений, требующих энергоэффективности. Использование единой операционной системы на всех типах устройств позволяет унифицировать ИТ-инфраструктуру предприятия, упростить администрирование и сократить расходы на поддержку.</p> <p>Образы РЕД ОС 8.0.3 для ARM доступны для скачивания на официальном сайте РЕД ОС.</p> <p>Совместимость РЕД ОС с архитектурой ARM продолжает расширяться. В новом релизе дополнен перечень поддерживаемых одноплатных компьютеров, востребованных на рынке.</p> <p>Функциональность образов РЕД ОС 8.0.3 полностью идентична версии для архитектуры x86_64. Полный список изменений и нововведений, вошедших в релиз РЕД ОС 8.0.3, доступен на сайте РЕД ОС.</p> <p>Важным отличием от предыдущего релиза является то, что теперь в одном образе объединена поддержка сразу нескольких ARM-устройств. На этапе установки можно выбрать требуемое устройство, и система будет установлена с соответствующим устройству ядром Linux. «Из коробки» поддерживаются следующие устройства:</p> <ul> <li>платформы на базе процессоров Huawei Kunpeng и Ampere Altra;</li> <li>устройства от «Элпитех» на базе процессоров Байкал-М, а также Байкал-S;</li> <li>устройства от ГК «Аквариус» на базе процессора Байкал-М;</li> <li>устройства от «Гравитон» на базе процессора Байкал-М.</li> </ul> <p>Расширена поддержка популярных одноплатных платформ, широко используемых в образовании, робототехнике, промышленной автоматизации и IoT-проектах. В список поддерживаемых РЕД ОС устройств добавлены новые модели: Raspberry Pi 3+ и Orange Pi Zero 3. Кроме того, обновлены образы для уже поддерживаемых платформ: Raspberry Pi 4/5, ROCKPro64, Orange Pi Zero 2W, Orange Pi 3 LTS и Repka Pi 4 Optimal. </p> <p>Пользователям доступен выбор из нескольких вариантов окружения рабочего стола: KDE Plasma, MATE или GNOME. Также доступна минимальная конфигурация без графики.</p> <p>РЕД ОС 8 под ARM была сертифицирована ФСТЭК России в декабре 2025 года. Сертифицированная РЕД ОС 8 под ARM поддерживает платформы на базе процессоров Huawei Kunpeng и Ampere Altra и ряд устройств на процессоре Байкал-М. Ведется работа над расширением поддерживаемых устройств на архитектуре ARM в Сертифицированной редакции РЕД ОС 8.</p> <p>«РЕД ОС 8.0.3 для ARM — это качественное обновление продукта для распространенных в России ARM-устройств. Все образы полностью сохраняют функциональность, идентичную версии для x86_64, что открывает ещё больше сценариев использования. В дальнейшем мы продолжим расширять перечень поддерживаемых устройств и совершенствовать механизмы развёртывания, чтобы каждый пользователь мог найти оптимальное решение для своих задач», — отметил Рустам Рустамов, заместитель генерального директора РЕД СОФТ.</p> Компания «РЕД СОФТ» объявила о выпуске корректирующего релиза операционной системы РЕД ОС 8.0.3 для архитектуры ARM … message https://www.itweek.ru/themes/detail.php?ID=235433 Mon, 31 Aug 2026 12:40:41 +0300 <p><span>Компания</span><span> Axiom JDK (АО</span> <span>«Аксиом») представила исследование о</span> <span>том, как российские компании управляют версиями Spring Boot, планируют миграцию и</span> <span>оценивают риски после окончания публичной поддержки. Сегодня международная поддержка Spring недоступна российским заказчикам на</span> <span>стандартных условиях. При этом 55,8% Java-разработчиков не</span> <span>определили срок эксплуатации Spring без публичных обновлений, 61,2% отметили практическую ценность расширенной поддержки, но</span> <span>только 26,9% уже используют или готовы рассматривать</span> <span>её. В</span> <span>опросе приняли участие более 300 специалистов в</span> <span>области Java-разработки, 87,8% из</span> <span>которых регулярно используют Spring</span> <span>— самый распространённый фреймворк для разработки Java-приложений в</span> <span>России.</span></p> <p>Исследование отражает прежде всего ситуацию в крупном бизнесе и финансовой отрасли: 71,1% участников работают в организациях численностью более 1000 сотрудников, 56,1% представляют финтех. Таким образом, риски окончания поддержки Spring затрагивают не только команды разработки, но и Java-приложения, обеспечивающие ключевые процессы банков, крупных компаний и цифровых сервисов.</p> <p>Наиболее распространённым поколением остаётся Spring Boot 3.x: его используют 83,7% участников. Spring Boot 2.x продолжает применять 21,2%, Spring Boot 4.x — 26%. Близкую картину показывает исследование State of Java 2026 компании JUG Ru Group: версии 2.x используют 20,4% опрошенных пользователей Spring, 3.x — 73,1%, 4.x — 24,7%.</p> <p>Публичные обновления версий Spring Boot выпускаются ограниченное время — для промежуточных веток около 13 месяцев. После завершения этого периода компании должны перейти на новую версию, сопровождать используемую ветку самостоятельно или использовать коммерческую поддержку.</p> <p>В июне 2026 года завершился выпуск публичных обновлений для Spring Boot 3.5 — наиболее распространённого поколения среди участников исследования. Международная коммерческая поддержка Spring российским заказчикам на стандартных условиях недоступна после прекращения VMware и Broadcom продаж и сопровождения в России. Поэтому компаниям необходимо самостоятельно обеспечить источник исправлений и план перехода.</p> <p>Однако исследование показывает, что такой сценарий сформирован не везде. 53,5% участников не знали дату окончания поддержки Spring Boot 3.5, а 55,8% не определили допустимый срок эксплуатации версии без публичных обновлений, включая исправления безопасности.</p> <p>18,9 % участников сообщили, что работы по переходу на Spring Boot 4 уже выполняются или завершено, для 41% переход пока остается планом. 23,7 % респондентов не приняли решение. </p> <p>При этом 32,7% участников одновременно используют несколько поколений Spring Boot. Новые приложения могут уже работать на актуальной версии, тогда как действующие системы продолжают использовать 2.x и 3.x. Это увеличивает объём работ по контролю уязвимостей, совместимости и обновлений и не позволяет завершить миграцию одномоментно.</p> <p>Требования информационной безопасности назвали причиной обновления Java и связанных фреймворков 57,7% участников. Однако инициаторами изменений чаще становятся разработчики (63,5%), тогда как подразделения ИБ и AppSec указали 36,5%. Риск возникает, когда между выявлением уязвимости и внедрением исправления не назначен единый владелец процесса, не установлен срок реакции и не определён источник обновлений.</p> <p>Результаты согласуются с данными State of Java 2026 по поддержке Spring Boot. По оценке JUG Ru Group, 61,5% разработчиков самостоятельно обновляют зависимости, 34,9% проверяют совместимость, 27% анализируют уязвимости, 23,4% контролируют версии и сроки поддержки, 21,5% исправляют дефекты. Отказ от внешней поддержки не устраняет эти задачи — они переходят внутренним командам и конкурируют за ресурсы с развитием продуктов.</p> <p>Только 26,9% участников исследования Axiom JDK уже используют или готовы рассматривать коммерческую поддержку Spring Boot. При этом 61,2% отметили хотя бы одну её практическую ценность. Наиболее востребованы исправления безопасности после окончания публичной поддержки — 29,8%, сопровождение необходимых версий и помощь с миграцией — по 23,4%, закреплённые сроки реакции (SLA) — 20,5%, экспертные консультации — 20,2%. Даже среди участников, которые не рассматривают комплексную коммерческую поддержку, 43,4% готовы использовать ее под конкретные задачи, например, чтобы облегчить работу по поиску исправлений и миграции. </p> <p>«Spring лежит в основе большого числа приложений крупного бизнеса и финансового сектора. Окончание публичной поддержки становится проблемой в момент появления уязвимости, когда компании срочно требуется проверенное исправление. Если источник обновлений и ответственный за процесс не определены заранее, риски переходят из технической плоскости на уровень реальной работы бизнеса, информационной безопасности и бюджетов — растут затраты и нагрузка на команды разработки. Для каждой промышленной системы необходимо заранее установить срок эксплуатации версии, план миграции и порядок получения исправлений», — отметил Илья Сазонов, директор по продукту Axiom JDK (АО «Аксиом»)</p> Компания Axiom JDK (АО «Аксиом») представила исследование о том, как российские компании управляют версиями Spring … message https://www.itweek.ru/themes/detail.php?ID=235432 Mon, 31 Aug 2026 12:38:51 +0300 <p>Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы с данными: от анализа и корректировки показателей до автоматического формирования табличных отчетов. В новой версии low-code-платформы появилась возможность редактировать данные прямо в OLAP, а также настраивать итоговые строки и столбцы в OLAP-представлениях. Дополнительно были расширены возможности по работе с новыми электронными таблицами: стало возможно осуществить экспорт сразу при выполнении серверной процедуры в рамках выполнения алгоритма.</p> <p>Так, пользователи теперь могут не только анализировать данные, но и редактировать их непосредственно в представлении OLAP. Бизнес-администратор сам определяет сценарий работы: разрешить только открытие карточек объектов, только редактирование значений в таблице или использовать оба режима одновременно. Все необходимые настройки выполняются в карточке куба, позволяя вносить изменения без постоянного перехода из аналитического представления в карточки объектов и обратно.</p> <p>Также в OLAP-представлениях появилась настройка отображения итоговых строк и столбцов. Пользователь может выбрать необходимые вычисления для строк или столбцов — например, сумму, среднее, минимальное или другое значение. После применения настроек итоги сразу отображаются в таблице. Новый механизм помогает быстрее получать сводные показатели и анализировать данные без дополнительной обработки или экспорта информации во внешние инструменты.</p> <p>Еще одно изменение касается электронных таблиц. Теперь их можно автоматически экспортировать в формат XLSX прямо из алгоритмов. Для этого в платформе появились новые функции, которые позволяют сформировать файл, сохранить его в системе или использовать для дальнейшей автоматизированной обработки. Такой сценарий может применяться для регулярной отчетности, обмена данными с внешними системами и подготовки табличных документов по заданным правилам.</p> <p>«Новые возможности помогают сократить количество ручных операций при работе с аналитикой и отчетностью. Пользователь может получить сводные показатели непосредственно в OLAP-представлении, при необходимости скорректировать данные, а затем автоматически сформировать XLSX-файл. В результате весь процесс, от анализа информации до подготовки отчета, выполняется в рамках единого рабочего сценария», — отметила Ксения Золотарева, директор по продукту GreenData.</p> Компания GreenData, российский разработчик low-code-платформы, выпустила обновление, которое упрощает полный цикл работы … message https://www.itweek.ru/themes/detail.php?ID=235430 Mon, 31 Aug 2026 09:53:09 +0300 <p>Далеко не каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих backend-продуктов очередь на базе PostgreSQL проще и надежнее в эксплуатации. Используя FOR UPDATE SKIP LOCKED, advisory locks, transactional outbox и корректную модель повторной обработки, можно связать изменение бизнес-данных и постановку фоновой задачи в одной транзакции.</p> <p>В статье разбираю реализацию пула обработчиков на Go, конкуренцию между потребителями и нарастающую задержку перед повтором. Показываю, как работать с очередью необработанных сообщений, корректной остановкой и очисткой накопившихся записей. А ещё определяю границу, после которой очередь поверх Postgres перестаёт быть прагматичным решением и проигрывает специализированному брокеру сообщений — по пропускной способности, времени отклика и управляемости.</p> <h3>Проблема двух систем</h3> <p>Почти в каждом backend-продукте пользователь оформляет заказ. Системе нужно отправить письмо, сформировать отчёт и вызвать внешние API. Выполнять такую задачу прямо в HTTP-запросе не всегда разумно. Увеличивается время ответа, а пользовательский сценарий становится зависимым от внешних сервисов. Команда обычно пользуется привычным набором: Kafka, RabbitMQ или Redis.</p> <p>Появляется риск рассинхронизации. Заказ уже сохранён в базе, но сообщение в брокер не отправлено. Процесс завершился между двумя операциями. Или обратная ситуация: задача стала доступна воркеру до того, как связанные с ней данные были зафиксированы в базе. Это частный случай проблемы двойной записи. Изменение бизнес-данных и постановка фоновой задачи происходят в разных системах и не образуют одну транзакцию.</p> <p>Классическим ответом на эту проблему является использование паттерна «transactional outbox». Приложение в одной транзакции меняет бизнес-данные и пишет строку в служебную таблицу исходящих сообщений, а отдельный процесс читает её и доставляет сообщение в брокер. Атомарность восстановлена, свойства Kafka или RabbitMQ сохранены. Но в системе появляется ещё один компонент, который нужно писать, разворачивать и мониторить, а брокер по-прежнему остаётся в эксплуатации. Получается, что таблица в PostgreSQL всё равно нужна — вопрос лишь в том, служит она перевалочным пунктом или самой очередью.</p> <p>Можно пойти дальше и убрать брокер совсем. Если очередь живёт в том же PostgreSQL, что и бизнес-данные, то изменение заказа и постановка фоновой задачи — одна атомарная операция. В рамках операции либо произошло и то, и другое, либо ничего. Никакого зазора, в который может провалиться работа.</p> <h3>Одна строчка SQL вместо брокера</h3> <p>Вся конструкция опирается на обычную таблицу — назовём её «jobs». В ней хранится минимум: тип задачи, полезная нагрузка в JSON, статус, время, раньше которого задачу запускать не нужно, а также счётчик попыток. Постановка задачи — это простой INSERT (его можно выполнить в той же транзакции, что и изменение бизнес-данных). Такой процесс закрывает проблему двух систем из предыдущего раздела.</p> <p>Однако остается вопрос, как несколько параллельных Go-воркеров будут разбирать задачи, не выстраиваясь в очередь друг за другом? Ответ — конструкция <strong>FOR UPDATE SKIP LOCKED</strong>, появившаяся в PostgreSQL ещё в версии 9.5:</p> <p><em>SELECT id FROM jobs</em></p> <p><em>WHERE status = ’ready’ AND run_at <= now()</em></p> <p><em>ORDER BY run_at</em></p> <p><em>LIMIT 10</em></p> <p><em>FOR UPDATE SKIP LOCKED;</em></p> <p>Запрос выбирает готовые к запуску задачи и временно блокирует выбранные строки. Если другую задачу уже обрабатывает параллельный воркер, SKIP LOCKED не ждёт освобождения блокировки, а пропускает эту строку и переходит к следующей. Благодаря этому несколько воркеров могут работать одновременно, при этом они не забирают задачу дважды и не создают общую очередь ожидания.</p> <p>Далее воркер в короткой транзакции переводит задачи в статус обработки и фиксирует изменение. Затем он уже выполняет основную работу. Поэтому длительные операции не удерживают блокировки в базе и не мешают другим воркерам получать новые задачи.</p> <h3>Правила работы с очередью</h3> <p>Таблица задач и механизм SKIP LOCKED позволяют нескольким воркерам безопасно забирать работу без дублирования. Чтобы такую очередь можно было использовать в продакшене, нужно предусмотреть обработку сбоев. Если задача завершилась ошибкой, её не стоит сразу удалять. Обычно её возвращают в очередь с задержкой, увеличивая интервал между попытками. Это снижает нагрузку на временно недоступный внешний сервис. После заданного числа неудачных попыток задачу переводят в отдельный статус или хранилище для ручного разбора.</p> <p>Также необходимо учитывать и сбои самих воркеров. Если процесс получил задачу и завершился до окончания работы, она не должна остаться в статусе обработки навсегда. Для этого задаче дают ограниченное время обработки: когда оно истекает, другой воркер может взять её повторно. При штатной остановке воркер, наоборот, перестаёт брать новые задачи и завершает уже начатые.</p> <p>При такой модели возможны повторные запуски одной и той же задачи. Например, внешний API мог получить запрос, а воркер — завершиться до сохранения результата. Поэтому обработчики должны корректно переносить повторное выполнение. Например, не отправлять пуш-сообщение дважды или не создавать повторный платёж.</p> <p>Готовые библиотеки избавляют от необходимости реализовывать эти механизмы с нуля. Для Go можно рассмотреть библиотеки River, gue и другие решения поверх PostgreSQL. Выбор зависит от требований к автоматическим повторам и планированию задач, а также наблюдаемости и модели обработки.</p> <h3>Работает и на серьёзном масштабе</h3> <p>Очередь в PostgreSQL не ограничивается небольшими сервисами. Ее используют и высоконагруженные системы, если очередь проектируют и обслуживают как отдельный компонент.</p> <p>Например, для конкурентного получения задач в Я.Диске используется механизм FOR UPDATE SKIP LOCKED. Масштаб: десятки тысяч задач в секунду и сотни типов задач. Один из крупнейших сервисов рунета выбрал SQL-очередь, при том, что Kafka в компании тоже есть и используется там, где её свойства подходят лучше.</p> <p>Второй кейс — компания 37signals, создатели фреймворка Ruby on Rails, Basecamp и почтового сервиса HEY. В HEY отказались от Redis и перевели фоновые системы на очередь Solid Queue. Она обрабатывает около 20 млн. задач в сутки. Для этого используются 800 воркеров, четыре диспетчера и два планировщика на 74 виртуальных машинах. Очередь работает в отдельной базе данных, для которой выделены 32 CPU, 64 Гб памяти и 350 Гб диска. Solid Queue стал очередью по умолчанию в Ruby on Rails 8, а подход официально признан стандартом целой экосистемы.</p> <h3>Где начинаются проблемы</h3> <p>Очередь в PostgreSQL удобна, пока нагрузка на неё остаётся умеренной и предсказуемой. Но у подхода есть особенности, которые нужно учесть до запуска в продакшен.</p> <p>Первая особенность связана с частым изменением записей. Задача обычно создаётся, затем меняет статус, а после выполнения удаляется или архивируется. В PostgreSQL старые версии строк не исчезают сразу, их очищает механизм vacuum. Если он не успевает за потоком обновлений, таблица и индексы разрастаются, а запросы к очереди начинают работать медленнее. Поэтому для таблицы задач обычно настраивают отдельные параметры autovacuum, следят за размером таблицы и не хранят завершённые задачи.</p> <p>Вторая особенность касается механизма LISTEN/NOTIFY. Его суть в мгновенных уведомлениях, которыми удобно будить воркеров вместо периодического опроса таблицы. Компания Recall.ai в марте 2025 года получила из-за него три простоя: уведомления выполнялись в транзакциях, а на этапе COMMIT возникала конкуренция за глобальную блокировку, из-за чего коммиты фактически выстраивались в очередь. В PostgreSQL 19 обещают внедрить улучшения, которые уменьшают лишние пробуждения backend-процессов при NOTIFY, но это не отменит необходимости измерять поведение конкретной системы под нагрузкой.</p> <h3>Где проходит граница очередей</h3> <p>Интуитивно хочется провести границу и разделить применение очередей по реальной нагрузке. Но с большим опытом приходит понимание, что универсального порога по нагрузке нет. На практике значение имеют размер задач, число воркеров, индексы, частота повторных попыток и ресурсы самой базы.</p> <p>Гораздо важнее оценивать стоимость эксплуатации. Очередь на PostgreSQL удобна, пока использует существующую базу: те же бэкапы, мониторинг, инструменты диагностики и компетенции команды. Для многих прикладных задач этого достаточно — особенно, если очередь обслуживает фоновые операции одного приложения.</p> <p>Очереди «Яндекс Диска» и 37signals показывают, что PostgreSQL способен обрабатывать очень большой поток задач, но для этого очереди выделяют собственную базу, ресурсы, настройки обслуживания, мониторинг и т. д. У Диска очередь работает на шардированной базе с отдельной обвязкой, а в 37signals для Solid Queue используется выделенная база данных.</p> <p>Не менее важна семантика. Очередь в PostgreSQL — когда одному приложению нужно выполнить фоновую задачу. Если же одно событие должны независимо получать несколько сервисов, а историю нужно хранить и перечитывать — лучше подходит Kafka. Она рассчитана на хранение потока событий и независимое чтение разными группами потребителей.</p> <p>RabbitMQ уместнее, когда нужны готовые механизмы маршрутизации, подтверждения обработки и управления потоком сообщений. Эти возможности можно частично реализовать поверх таблицы в PostgreSQL, но тогда очередь постепенно превращается в собственный брокер, который нужно проектировать и сопровождать. RabbitMQ же предоставляет подтверждения обработки сообщений как встроенный механизм.</p> <p>Очередь на PostgreSQL не заменяет Kafka или RabbitMQ, но хорошо подходит для фоновых задач. Главный критерий выбора — не популярность или абстрактный предел по числу задач. В приоритете — какие свойства требуются системе и сколько будет стоить их эксплуатация.</p> <p>#IMAGE_235431#</p> Далеко не каждой системе необходим отдельный Kafka, RabbitMQ или специализированный message-брокер: для многих … article Роман Муковнин, старший инженер-программист WildBerries https://www.itweek.ru/themes/detail.php?ID=235429 Mon, 31 Aug 2026 09:44:38 +0300 <p><em>Опрошенные порталом </em><em>InformationWeek</em> <em>эксперты рассказывают о том, как </em><em>CIO</em> <em>могут помочь своим компаниям справиться с растущими и непредсказуемыми расходами на искусственный интеллект и сформировать бюджет, который будет приносить прибыль.</em></p> <p>Предприятиям не обойтись без расходов на ИИ. Но просто вкладывать деньги в эту технологию недостаточно для того, чтобы раскрыть ее потенциал в качестве инструмента повышения эффективности и роста доходов. Выделение бюджета на ИИ, который приносит реальную выгоду, является непростой задачей, поскольку CIO приходится учитывать расходы, которые не всегда очевидны.</p> <p><a href="https://assets.kpmg.com/content/dam/kpmgsites/xx/pdf/2026/06/global-ai-pulse-q2.pdf">Исследование</a> KPMG «Q2 2026 Global AI Pulse» показало, что только 35% организаций имеют полное представление о своих операционных расходах, связанных с ИИ. Эти организации в пять раз чаще сообщают о подтверждённой окупаемости инвестиций, чем те, у кого такой информации нет.</p> <h3>Почему расходы на ИИ сложно спрогнозировать</h3> <p>У предприятий нет чёткой схемы бюджетирования ИИ. Руководители компаний выясняют всё на ходу, а это значит, что неожиданностей и ошибок не избежать.</p> <p>«Очень легко столкнуться с непредвиденными расходами. И очень, очень сложно обеспечить структурированность и предсказуемость при масштабировании возможностей ИИ в крупной организации», — говорит Пол Блоуэрс, CIO компании Plante Moran, занимающейся аудитом, налогообложением, консалтингом и управлением активами.</p> <p>Расходы на ИИ не ограничиваются покупкой платформы или инструмента. Чтобы ИИ приносил пользу, ему нужна правильная основа, а для создания такой основы требуются инвестиции.</p> <p>«Вам нужен уровень данных, вам нужен уровень контекста, вам нужен уровень перевода. Кроме того, у вас будут уровень ИИ и уровень активации», — говорит Кристин Парк, директор по трансформации компании Branch, занимающейся мобильной аналитикой и диплинкингом. К этим базовым требованиям добавляются вопросы безопасности и управления, которые крайне важны.</p> <p>По словам Парк, в ее компании создание такой основы потребовало затрат на очистку баз данных и знаний. Кроме того, она наняла пару инженеров по автоматизации на основе ИИ, чтобы они помогали с рабочими процессами.</p> <h3>Затраты на внедрение ИИ не ограничиваются инструментами</h3> <p>При планировании бюджета на ИИ необходимо учитывать затраты на изменение методов работы сотрудников и способов выполнения самой работы.</p> <p>«Если вы закладываете в бюджет только стоимость инструмента, то, на мой взгляд, вас ждут проблемы, потому что нужно закладывать средства и на трансформацию, — говорит Парк. — Инструмент — это доступ, а трансформация — это переосмысление вашей работы».</p> <p>Переосмысление методов работы команд требует времени и денег. По словам Парк, это «сложный проект», который включает в себя изменения в реализации, конфигурации и рабочих процессах. «ИИ не решает всех проблем. ИИ — это инструмент», — отмечает она.</p> <h3>Затраты на использование ИИ сложно предсказать</h3> <p>Потребление по-прежнему является сложной частью головоломки бюджетирования ИИ. Цены на токены упали, но их использование резко возросло.</p> <p>«Каждый раз, когда выходит новая модель или новый сценарий использования внедряется в производственный процесс, потребление этих токенов растет все быстрее и быстрее, — говорит Блоуэрс. — Мы, CIO, сейчас становимся специалистами в области моделирования и ведения переговоров по токенам, но ситуация в этой сфере пока далека от стабильности».</p> <p>Он ожидает, что модели ценообразования на токены будут продолжать развиваться, а поставщики будут предлагать разные подходы.</p> <h3>ИИ увеличивает расходы</h3> <p>Предприятиям приходится не только самостоятельно решать вопрос с расходами на ИИ, но и учитывать, как инвестиции поставщиков в ИИ влияют на их затраты. Провайдеры SaaS-решений ищут способы встроить ИИ в свои продукты и монетизировать его, что приводит к росту цен.</p> <p>«Большинство ведущих поставщиков SaaS существенно повышают цены, чтобы реализовать свои планы по внедрению ИИ, — говорит Блоуэрс. — И можно с уверенностью сказать, что многие, если не большинство CIO, согласятся с тем, что эти цены растут еще до того, как будут внедрены зрелые функции ИИ, или до того, как мы сможем спрогнозировать, как будет выглядеть потребление внутри этих SaaS-инструментов и платформ».</p> <h3>Как бюджетируют ИИ</h3> <p>Учитывая, что затраты на ИИ так трудно предсказать, CIO начинают переосмысливать бюджетирование этой технологии. Для Парк это означает, что расходы на ИИ рассматриваются не как постоянная статья расходов, а как переменные затраты. «Это модель, основанная на потреблении. Это не фиксированная стоимость, как у SaaS», — поясняет она.</p> <p>Для компаний, которые не приложили достаточных усилий для создания прочной основы для инструментов и рабочих процессов ИИ, обсуждение бюджета может начаться с оценки затрат на создание всего с нуля. Эта основа очень важна. Опрос PwC «2026 Global CEO survey», в котором приняли участие 4454 топ-руководителя, показал, что организации с прочными основами, которые описываются как «ответственные платформы и технологические среды ИИ, обеспечивающие интеграцию в масштабах всего предприятия», имеют в три раза больше шансов получить «значимую финансовую отдачу».</p> <p>При планировании затрат на трансформацию предприятиям необходимо четко представлять, что означает интеграция ИИ для бизнеса. Парк утверждает, что чрезмерное внимание к показателям эффективности является ошибкой. «Мы действительно рассматриваем это как ключевой аспект исследований и разработок, потому что я не думаю, что ИИ должен быть инструментом повышения эффективности, — говорит она. — Я не считаю, что ИИ следует рассматривать как способ сокращения затрат на персонал. Я думаю, это неправильная формула».</p> <p>Независимо от того, какой путь выберут компании — повышения эффективности или внедрения инноваций, — им необходимо заложить в бюджет расходы на внедрение и использование ИИ. Дело не ограничивается покупкой ИИ-инструмента или платформы и требованием к сотрудникам их использовать. «Предоставить людям доступ — это еще не значит внедрить технологию», — говорит Парк.</p> <p>Конечно, по мере внедрения ИИ его использование — и затраты — могут расти. И бюджеты на ИИ должны учитывать этот рост.</p> <p>Блоуэрс вместе с другими руководителями работает над формированием бюджета своей компании на повседневное использование ИИ, в том числе инструментов для повышения производительности. «Мы планируем развивать этот подход по аналогии с FinOps: стимулировать внедрение, предоставлять сотрудникам возможность контролировать расходы, вводить ежемесячные лимиты с некоторыми поведенческими стимулами, — отмечает он. — Обучение само по себе является ключевым инструментом контроля затрат, а не просто способом ограничить потребление токенов».</p> <p>Они также занимаются определением сценариев использования ИИ для масштабирования. «Масштабирование немного проще контролировать с точки зрения затрат, планировать и прогнозировать, потому что мы централизуем процессы и они проходят через наши обычные бизнес-процессы и этапы жизненного цикла разработки ПО», — говорит Блоуэрс.</p> <p>ИИ, встроенный в SaaS-продукты, — это третья статья расходов, которой занимаются Блоуэрс и его коллеги. Это значит, что нужно обсуждать с поставщиками, как ИИ встраивается в уже имеющиеся у компании инструменты и как это влияет на цены при продлении контрактов.</p> <p>«Чтобы справиться с этой проблемой, мы настаиваем на том, чтобы наши партнеры-поставщики соглашались на наши условия, разрабатывали проактивные дорожные карты и оценивали влияние на наши прибыль и убытки, прежде чем соглашаться на предлагаемое ими ценообразование токенов», — говорит Блоуэрс.</p> <p>В компании Парк консолидация инструментов стала частью подхода к бюджетированию. «Вам нужно начать консолидировать инструменты, чтобы получить экономию», — говорит она.</p> <h3>Роль CIO в бюджетировании ИИ</h3> <p>CIO играет ключевую роль во внедрении и бюджетировании ИИ, но для этого ему необходимо взаимодействовать с другими руководителями высшего звена и членами совета директоров, чтобы определить, какую ценность они ожидают получить от ИИ и сколько готовы на это потратить.</p> <p>Поэтому особенно важным партнером является финансовый директор. «Нужно тесно сотрудничать с финансовыми директорами, — говорит Блоуэрс. — Честно говоря, здоровая критика в этом вопросе полезна. Финансовый директор выступает за тщательный контроль бюджета, связанного с ИИ».</p> <p>Давление на CIO не ограничивается контролем расходов. Генеральные директора и члены совета директоров также ожидают, что их ИТ-руководители будут управлять рисками, связанными с ИИ, и при этом не отставать от конкурентов.</p> <p>«Мы сталкиваемся с огромным сопротивлением в вопросах затрат, огромным сопротивлением в вопросах рисков и огромным давлением, требующим действовать быстрее и делать больше, чтобы не отставать, — отмечает Блоуэрс. — Роль CIO заключается в том, чтобы увязать все эти опасения в рамках нашей ИИ-стратегии и помочь найти баланс в этом вопросе».</p> Опрошенные порталом InformationWeek эксперты рассказывают о том, как CIO могут помочь своим компаниям справиться … article 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