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=235421 Thu, 27 Aug 2026 10:38:03 +0300 <p><em>Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале </em><em>BigDataWire</em> <em>Сохам Мазумдар, соучредитель и генеральный директор WisdomAI.</em></p> <p>На протяжении многих лет аналитические команды помогали организациям разобраться в своих данных. Они создавали дашборды. Они создавали отчеты. Они создавали конвейеры обработки данных. Они разрабатывали определения, документировали метрики и помогали руководителям отвечать на вопросы о том, что происходит внутри компании.</p> <p>Теперь сотрудники компаний все чаще обращаются к ChatGPT, Claude, Copilot и другим системам на основе ИИ вместо того, чтобы напрямую открывать дашборды. Вместо того, чтобы самостоятельно работать с инструментами отчетности, они задают вопрос и ждут ответа.</p> <p>Когда сотрудник запрашивает информацию с дашборда, тот выдает ему метрику. Когда сотрудник обращается к ИИ-помощнику, тот интерпретирует информацию, объединяет данные из нескольких систем, применяет логику и выдает заключение.</p> <p>Но кто-то все равно должен определить, верен ли ответ, и эта ответственность все чаще ложится на аналитические команды.</p> <h3>Традиционное управление решало другие задачи</h3> <p>На протяжении большей части современной эпохи работы с данными управление было сосредоточено на вопросах доступа, происхождения данных, определений и доверия. Организациям нужно было знать, кто имеет доступ к данным, откуда поступает информация, как определяются метрики и на какие отчеты можно полагаться при принятии решений.</p> <p>Для решения этих проблем появились каталоги данных, инструменты отслеживания происхождения данных, платформы для документирования и системы управления. Они помогли организациям обеспечить согласованность во все более сложных средах обработки данных и повысили уверенность сотрудников в информации, которой они пользовались каждый день.</p> <p>Эта система работала, потому что окончательное решение оставалось за людьми. Аналитики и бизнес-руководители отвечали за интерпретацию информации, учет контекста и определение того, как данные должны влиять на принятие решений. Система управления была создана для того, чтобы обеспечить людям доступ к достоверной информации. Она не была предназначена для оценки того, как ПО обрабатывает эту информацию.</p> <h3>Агенты создают новую проблему в сфере управления</h3> <p>Одно из самых распространенных заблуждений в сфере корпоративного ИИ заключается в том, что управление — это в первую очередь проблема доступа. Логика кажется разумной: если у агента есть доступ к нужным системам и данным, он должен быть в состоянии выдать правильный ответ.</p> <p>К сожалению, доступ и точность — это не одно и то же.</p> <p>В отличие от традиционных аналитических инструментов, агенты не просто извлекают информацию. Они интерпретируют ее, объединяют сигналы из нескольких систем, применяют бизнес-логику и генерируют рекомендации, которые все больше влияют на решения и действия.</p> <p>Это значит, что агент может получить доступ к абсолютно достоверной информации и все равно прийти к неверному выводу.</p> <p>Данные о клиенте могут быть точными. Прогноз продаж может быть актуальным. Финансовые показатели могут быть корректно определены. Тем не менее, агент может неправильно комбинировать эти входные данные, неправильно понимать контекст, в котором они используются, или непоследовательно применять бизнес-логику.</p> <p>Многие организации полагают, что управление заканчивается, как только будут установлены необходимые разрешения и подключены нужные источники данных. На самом деле эти элементы управления определяют только то, к какой информации агент может получить доступ. Они не определяют, правильно ли агент интерпретирует эту информацию.</p> <p>Традиционные системы управления никогда не были разработаны для решения этой проблемы. Разрешения не предотвращают неправильного толкования, отслеживание происхождения не гарантирует разумного обоснования, а документация не обеспечивает последовательного выполнения.</p> <p>Поскольку организации внедряют агентов во все большее число рабочих процессов, им нужен способ оценить не только то, что может видеть система ИИ, но и то, можно ли доверять выводам, которые она делает.</p> <h3>Аналитические группы становятся ИИ-рецензентами</h3> <p>Кто-то должен выявлять повторяющиеся сбои, сопоставлять результаты с реальностью и определять, повышается или снижается надежность с течением времени.</p> <p>Эта работа, естественно, ложится на плечи аналитиков.</p> <p>Они уже понимают, что лежит в основе данных, как определяются показатели, откуда берется бизнес-логика и как информация перемещается по организации. Не менее важно, что они понимают, как должен выглядеть правильный ответ и где наиболее вероятно возникновение ошибок.</p> <p>По мере того как ИИ становится все более важной частью доступа сотрудников к информации, аналитические группы берут на себя обязанности, которые все больше напоминают обеспечение качества. Они проверяют результаты, оценивают надежность, расследуют сбои, отслеживают согласованность и выявляют условия, которые заставляют агентов выдавать неверные результаты.</p> <p>Исторически сложилось так, что аналитические группы отвечали за то, чтобы дашборды и отчеты точно отражали бизнес. ИИ расширяет зону их ответственности. Тем же командам теперь предлагается оценить, дают ли агенты, вторые пилоты и аналитические системы на базе ИИ ответы, заслуживающие такого же уровня доверия.</p> <h3>Управление выходит за рамки данных</h3> <p>Большинство программ управления были построены вокруг контроля доступа к информации. Цель состояла в том, чтобы обеспечить сотрудникам доступ к необходимым им данным, сохраняя при этом согласованность, безопасность и доверие во всей организации.</p> <p>ИИ ставит перед ними другую задачу. Агент может иметь доступ к нужным системам, нужным данным и нужным разрешениям, но при этом выдавать неполный, противоречивый или просто неправильный ответ.</p> <p>Это смещает фокус управления за пределы контроля доступа и управления данными. Организациям необходимо иметь представление о том, как ведут себя агенты, насколько последовательно они применяют бизнес-логику и остаются ли результаты, которые они генерируют, надежными с течением времени.</p> <p>Организация, которая не может доверять выводам, сделанным ее системами ИИ, не решила проблему управления просто потому, что базовые данные хорошо управляются. По мере того как агенты все глубже интегрируются в бизнес-процессы, надежность, валидация и контроль становятся не менее важными, чем прослеживаемость происхождения, права доступа и документация.</p> <h3>Переход от управления данными к управлению ИИ</h3> <p>Профессия аналитика уже претерпела несколько серьезных трансформаций: от отчетности и бизнес-аналитики к самообслуживанию в аналитике и современным платформам данных. ИИ порождает еще одну трансформацию.</p> <p>По мере того как агенты все активнее участвуют в предоставлении сотрудникам доступа к информации, организациям становятся нужны люди, которые смогут оценивать надежность, расследовать сбои и определять, заслуживают ли доверия результаты работы ИИ. Аналитические команды хорошо подходят для выполнения этой задачи, поскольку они уже разбираются в данных, бизнес-логике и операционном контексте, лежащих в основе ответов, которые выдают эти системы.</p> <p>На протяжении многих лет их роль заключалась в том, чтобы помогать людям принимать более взвешенные решения на основе данных. Теперь они все чаще отвечают за то, чтобы системы ИИ могли делать то же самое.</p> Аналитические группы становятся экспертами в области искусственного интеллекта, пишет на портале BigDataWire Сохам … article https://www.itweek.ru/themes/detail.php?ID=235419 Thu, 27 Aug 2026 09:05:07 +0300 <p><em>Сегодня ИИ, а точнее машинное обучение (ML), все глубже встраивается в управление доставкой, помогая прогнозировать спрос и опоздания, рассчитывать сроки и оптимизировать процессы. Разбираемся, какие задачи последней мили уже можно передать алгоритмам и почему главным преимуществом логистических платформ становится не сам искусственный интеллект, а качество накопленных данных и возможности прогнозирования.</em></p> <h3>От автоматизации к планированию и прогнозу</h3> <p>Переход от простой автоматизации к прогнозному управлению доставкой происходил постепенно. По мере накопления данных и развития технологий логистические системы стали решать все более сложные задачи. Условно этот процесс можно разделить на два этапа.</p> <p><strong>Цифровизация доставки.</strong> Этот этап связан прежде всего с автоматизацией рутинных операций. Системы научились распределять заказы между курьерами, строить маршруты, рассчитывать предполагаемое время доставки (ETA), объединять несколько заказов в одну цепочку и пересчитывать параметры при изменении ситуации. Это позволило сократить объем ручной работы и снизить зависимость процессов от диспетчера.</p> <p><strong>Прогнозное управление. </strong>Здесь системы начинают не только обрабатывать текущую ситуацию, но и прогнозировать дальнейшее развитие событий. Например, модели машинного обучения анализируют историю заказов и оценивают будущий спрос в конкретной зоне и временном интервале. Это позволяет бизнесу заранее планировать количество курьеров и адаптировать ресурсы к ожидаемой нагрузке, что особенно важно для доставки последней мили, где спрос распределяется неравномерно. Количество заказов в пятницу вечером и утром буднего дня может отличаться в несколько раз. Если курьеров недостаточно, увеличивается нагрузка и растет риск опозданий. Если их слишком много, появляются простои, а стоимость выполнения одного заказа увеличивается.</p> <p>И ценность ML заключается не в самом прогнозе, а в возможности использовать его для принятия операционных решений. В частности, чем точнее компания понимает будущую нагрузку, тем эффективнее может распределять ресурсы и поддерживать баланс между стоимостью доставки и качеством сервиса.</p> <p>При этом прогнозирование дает бизнесу еще одну возможность: проверять решения до их внедрения. На основе накопленных данных можно моделировать различные сценарии работы доставки и смотреть, как изменение отдельных параметров повлияет на результат. Например, при расширении зоны доставки можно рассчитать необходимое количество курьеров, изменение их загрузки и возможное влияние нового радиуса на стоимость заказа и сроки.</p> <p>Такие тесты позволяют проверять гипотезы на виртуальной модели, не экспериментируя сразу на реальных заказах и клиентах. В результате управление доставкой постепенно переходит от реактивного подхода, когда бизнес исправляет уже возникшую проблему, к проактивному, когда последствия решения можно оценить заранее.</p> <h3>Динамическая маршрутизация</h3> <p>Еще одна важная задача в управлении последней милей связана с построением маршрутов. Здесь важно уточнить, что сама маршрутизация не является задачей искусственного интеллекта. В ее основе лежат алгоритмы оптимизации, а модели машинного обучения могут использоваться для более точного прогнозирования отдельных параметров, которые учитываются при расчетах.</p> <p>Современная система должна учитывать не только расстояние между точками, но и временные интервалы доставки, доступность и загрузку курьеров, зоны обслуживания, приоритеты заказов и другие ограничения. При этом исходные условия постоянно меняются. Поступают новые заказы, один курьер задерживается, другой освобождается раньше, меняется время готовности заказа.</p> <p>Поэтому маршрут не формируется один раз на всю смену. Система пересчитывает его по мере поступления новых данных и помогает перераспределять заказы между исполнителями. <nobr>ML-модели</nobr> могут дополнять этот процесс, например повышая точность расчета ожидаемого времени доставки (ETA).</p> <p>Для бизнеса результат такой оптимизации выражается в конкретных показателях, таких как сокращение простоев и лишнего пробега, более равномерная загрузка курьеров и соблюдение заявленных сроков доставки.</p> <h3>Опоздания под контролем</h3> <p>Еще одно направление, где машинное обучение может быть полезно, связано с прогнозированием опозданий. В традиционной модели проблема становится очевидной, когда курьер уже выбился из графика или клиент не получил заказ в обещанное время. <nobr>ML-модели</nobr> позволяют оценить риск задержки заранее, анализируя накопленные данные и текущие параметры доставки. Причины при этом могут быть совершенно разными. Одни возникают внутри самого процесса, когда, например, заказ поздно собрали, задержали на упаковке или не успели передать исполнителю. Другие возникают из-за форс мажорных обстоятельств и их невозможно полностью исключить организационными мерами. Например, на движение курьера могут повлиять авария, перекрытие дороги, проверка сотрудниками полиции и т. д.</p> <p>Задача алгоритмов в такой ситуации не в том, чтобы исключить все форс-мажоры, а в том, чтобы как можно раньше увидеть отклонение и минимизировать его последствия. Если система получает актуальные данные о ходе доставки, она может пересчитать ETA, изменить последовательность выполнения заказов или перераспределить часть нагрузки между исполнителями.</p> <p>В результате бизнес получает возможность управлять отклонением «на лету», еще до того, как оно превратится в опоздание для клиента. И чем раньше будет обнаружен риск, тем больше вариантов остается для корректировки ситуации и сохранения заявленного уровня сервиса.</p> <h3>Где заканчивается работа алгоритма</h3> <p>По мере развития технологий все больше операционных задач можно автоматизировать. Система способна распределять заказы между курьерами, пересчитывать маршруты, рассчитывать ETA и выявлять риск отклонения от заданных сроков. Однако это не означает, что управление доставкой можно полностью передать алгоритмам.</p> <p>Ключевые правила по-прежнему определяет бизнес. Компания решает, какие зоны обслуживать, какие временные интервалы предлагать клиентам, какие заказы считать приоритетными и какой уровень сервиса поддерживать. Алгоритмы работают внутри этих ограничений и помогают находить оптимальное решение в конкретной ситуации.</p> <p>При этом автоматизация постепенно освобождает сотрудников от значительной части рутинных операций. Им уже не нужно вручную распределять каждый заказ, постоянно перестраивать маршруты или отслеживать движение каждого курьера. Эти задачи система может выполнять самостоятельно в рамках заданных правил.</p> <p>В результате роль человека не сокращается, а меняется. Чем больше типовых операций берет на себя технология, тем больше внимания сотрудник может уделять задачам более высокого уровня, анализировать показатели, искать причины отклонений, проверять гипотезы, менять правила работы системы и продумывать новые сценарии. Алгоритмы в этом смысле не заменяют специалиста, а позволяют ему перейти от ручного управления процессом к работе с решениями и развитием доставки.</p> <h3>Качество и полнота данных выходят на первый план</h3> <p>Когда набор технологических возможностей у логистических платформ становится сопоставимым, различия начинают формироваться на уровне данных. Одна и та же модель может показывать разную точность в зависимости от того, на какой информации она обучалась и с какими сценариями сталкивалась раньше.</p> <p>При этом большой объем данных сам по себе не гарантирует хороший результат. Важны их качество, полнота, актуальность и разнообразие. Чем лучше данные отражают реальные процессы доставки и возможные отклонения, тем надежнее модель работает в новых ситуациях.</p> <p>Особенно заметно это при моделировании сценариев. Чтобы оценить последствия изменения зоны доставки, нагрузки или доступного курьерского ресурса, недостаточно знать только среднее количество заказов. Чем полнее система видит историю операций и взаимосвязь разных параметров, тем ближе результаты виртуального теста к тому, что произойдет в реальных условиях.</p> <p>И в отличие от отдельных технологий, накопленную историю операций невозможно быстро скопировать или приобрести. Она формируется со временем, поэтому именно данные постепенно становятся одним из ключевых активов логистических платформ и определяют качество работы <nobr>ML-моделей.</nobr></p> <h3>Что дальше</h3> <p>Следующий этап развития технологий управления доставкой будет связан не столько с расширением функционала, сколько с повышением точности уже существующих решений. По мере накопления данных модели смогут лучше учитывать особенности спроса, загрузку и поведение курьеров, а также отклонения, возникающие в разных сценариях доставки.</p> <p>При этом полностью автономное управление последней милей пока остается скорее перспективой, ведь слишком многое здесь зависит от нестандартных ситуаций, которые требуют оценки и вмешательства человека. Поэтому задача технологий — не исключить его из процесса, а взять на себя расчеты и значительную часть операционных решений, сохранив за специалистом контроль в ситуациях, где алгоритма недостаточно.</p> <p>В результате развитие ML в логистике будет определяться не количеством новых функций с маркировкой ИИ, а тем, насколько точно технологии работают с реальными процессами и улучшают конечный результат. И ценность таких решений будет измеряться конкретными показателями, насколько они помогают сокращать опоздания и простои, поддерживать качество сервиса и снижать стоимость доставки.</p> <p>#IMAGE_235420#</p> Сегодня ИИ, а точнее машинное обучение (ML), все глубже встраивается в управление доставкой, помогая … article Денис Сокольников, технический директор компании “Мастер Деливери” https://www.itweek.ru/themes/detail.php?ID=235401 Thu, 27 Aug 2026 00:00:00 +0300 <p>Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих интеграций, доработок, миграции данных и поддержки. Разбираем, где компании чаще всего ошибаются и что стоит проверить до старта проекта.</p> <p>Российский бизнес продолжает вкладывать в цифровизацию все больше денег. По предварительной <a href="http://issek.hse.ru/mirror/pubs/share/1132489160.pdf">оценке</a> ИСИЭЗ НИУ ВШЭ, затраты на развитие цифровой экономики в России в 2025 году составили 7,1 трлн. рублей, это на 6,5% больше, чем годом ранее. Только внутренние затраты организаций на создание, распространение и использование цифровых технологий оцениваются в 4,5 трлн. рублей. За пять лет эта сумма выросла примерно вдвое. Причем 87,5% расходов крупных и средних организаций на цифровые технологии в 2024 году финансировались из собственных средств.</p> <p>В 2026 году расходы продолжают расти. В исследовании Apple Hills Digital, Selectel, Cloud.ru и VK Tech 65% опрошенных российских компаний <a href="https://apple-hills.com/ru/reports/cloud-consumption-trends-2025">сообщили</a>, что увеличили ИТ-бюджеты: 48% подняли их в пределах 15%, еще 17% более чем на 15%. Исследование охватило 419 компаний из разных отраслей и 27 глубинных интервью с ИТ-руководителями.</p> <p>То есть вопрос уже не столько в том, готов ли российский бизнес тратить деньги на цифровизацию. Готов. Другой вопрос: сколько из этих денег действительно должно было быть потрачено.</p> <p>Компания может согласовать систему за 20 млн. рублей, успешно провести тендер и даже уложиться в смету. А потом обнаружить, что отдельно нужны интеграции, миграция данных, переделка нескольких внутренних сервисов, обучение сотрудников, дополнительная инфраструктура и команда, которая будет развивать продукт после запуска.</p> <p>Иногда проблема обнаруживается еще позже: система работает, но не дает эффекта, ради которого ее создавали.</p> <p>Это не редкий сценарий. Оператор ИТ-решений ОБИТ в 2025 году <a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/">проанализировал</a> более 100 входящих запросов от компаний среднего и крупного бизнеса с оборотом от 2 млрд. рублей. В выборку вошли промышленность, ритейл, ИТ и телеком, логистика. Почти в каждом втором случае компании приходили с запросом на повторный проект или доработку после предыдущего неудачного внедрения. Самыми частыми причинами стали недооценка стоимости владения, проблемы интеграции и неправильный выбор решения.</p> <p>Разберем ошибки, из-за которых цифровизация становится дороже, чем могла бы быть.</p> <h2>Ошибка 1. Цифровизировать компанию отдельными проектами</h2> <p>У компании появляется CRM. Потом ERP. Отдельно развивается мобильное приложение. Маркетинг подключает систему лояльности, HR работает в своей системе, финансы в своей. Где-то появляется BI, затем AI-сервис. Каждый проект можно защитить отдельно. У каждого есть заказчик, задача, бюджет. Иногда все они даже работают нормально.</p> <p>Через несколько лет обнаруживается другая проблема: весь этот набор плохо работает как единая система. Одни и те же данные хранятся в нескольких местах. У одного клиента разные ID. Часть информации синхронизируется автоматически, часть переносится вручную. Новая функция в мобильном приложении требует изменений в трех внутренних системах. Замена CRM неожиданно затрагивает продажи, приложение, аналитику и программу лояльности. Так появляется тот самый зоопарк ИТ-систем.</p> <p>В III Всероссийском опросе по цифровой трансформации Comindware, Artezio и РУССОФТ 60% участников <a href="https://www.comindware.ru/blog/investitsii-v-tsifrovizatsiyu-v-rossii-vyrosli-v-poltora-raza/amp/">сообщили</a>, что проводят отдельные проекты цифровизации, но не имеют общей стратегии. Еще 18% сказали, что такой стратегии нет вообще. 80% компаний используют разрозненные интеграции между информационными системами, а в единой цифровой среде работают только 12%.</p> <p>У этой проблемы уже вполне материальные последствия. К2Тех <a href="https://k2.tech/press_releases/opros-k2teh-68-kompanij-ne-vidyat-czelostnuyu-kartinu-biznesa-iz-za-zooparka-it-sistem/">опросил</a> более 300 руководителей и ИТ-специалистов средних и крупных российских компаний. 68% респондентов сообщили, что из-за зоопарка решений не могут получить целостную картину данных. 47% сталкиваются с высокими скрытыми затратами на поддержку разрозненных систем, еще 33% говорят о техническом долге, который мешает развитию.</p> <p>Проблема тут не в количестве программ. У крупной компании их и не может быть две или три. Вопрос в том, как устроены связи между ними и понимает ли компания, каким должен быть ее ИТ-ландшафт через несколько лет.</p> <p>Допустим, отделу продаж действительно нужна новая система. Помимо вопроса «Решает ли она нашу задачу?» стоит задать еще один: «Что произойдет со всей инфраструктурой после ее появления?». Новая система может дать локальный эффект сейчас, но заметно увеличить стоимость любых изменений потом.</p> <p>Что проверить до следующего внедрения? Нужно хотя бы на верхнем уровне понимать:</p> <ul> <li> какие системы новый продукт заменяет, а какие дополняет;</li> <li> какие данные он будет получать и передавать;</li> <li> где будет храниться мастер-версия данных;</li> <li> сколько новых интеграций появится;</li> <li> не придется ли хранить еще одну копию уже существующей информации;</li> <li> от каких систем и подрядчиков новый продукт будет зависеть;</li> <li> можно ли будет заменить его через несколько лет без перестройки половины ИТ-ландшафта.</li> </ul> <p>Здесь полезна архитектурная схема не только текущего состояния, но и целевого. Иначе цифровой контур формируется не потому, что его кто-то таким спроектировал, а потому что проекты запускались один за другим.</p> <h2>Ошибка 2. Не решить заранее, какой результат должен дать проект</h2> <p><strong>«</strong>Запустить CRM до декабря» звучит как цель. «Разработать приложение» тоже. Как и «автоматизировать оформление заказа», «внедрить AI» или «перевести сотрудников в новую систему». Только все это цели проекта, а не бизнеса.</p> <p>Русская школа управления в 2025 году <a href="https://uprav.ru/blog/55-rukovoditeley-nazyvayut-vysokuyu-stoimost-glavnym-barerom-tsifrovizatsii-biznesa/">опросила</a> руководителей и HR-специалистов российских компаний. 55% назвали одним из главных барьеров цифровизации высокую стоимость внедрения. Но на втором месте оказался гораздо более интересный ответ: <em>35% не понимают эффекта от цифровых решений</em>. Еще 29% назвали сопротивление сотрудников, 27% недостаток компетенций у руководителей, 26% сложности ИТ-инфраструктуры.</p> <p>Проблема становится заметна после релиза. Проект завершили. Система работает. Как понять, что несколько миллионов были потрачены не зря? <br/> Если до начала работы компания не измеряла текущий процесс, ответа может и не быть. </p> <p>Например, смысл нового личного кабинета может быть не в самом факте его появления, а в том, чтобы больше клиентов решали свои вопросы без обращения в поддержку.</p> <p>У автоматизации документооборота задача может состоять в сокращении срока согласования с пяти дней до одного. У нового внутреннего сервиса — в том, чтобы операция, которая занимала у сотрудника 20 минут, выполнялась за пять. А у мобильного приложения — не обязательно в росте установок. Возможно, важнее доля пользователей, дошедших до покупки или снижение нагрузки на офлайн-канал.</p> <p>Поэтому еще до разработки хорошо зафиксировать три вещи: что происходит сейчас. Например, обработка одной заявки занимает 40 минут. Что хотим получить. Например, 15 минут. Как и когда будем это измерять.</p> <p>Без первой точки сравнения можно получить красивый продукт, хорошие отзывы внутри команды и ни одного доказательства, что бизнес стал работать лучше. Еще хуже, когда KPI цифровизации выбирается из технических показателей. Количество функций, число релизов или процент готовности проекта мало говорят о результате для компании. Система может быть написана без критических ошибок, запущена в срок и полностью соответствовать техническому заданию. И одновременно быть неудачным бизнес-проектом.</p> <h2>Ошибка 3. Считать бюджет внедрения, а не реальную стоимость владения</h2> <p>Это одна из самых приземленных ошибок, потому что ее легко увидеть в деньгах. В <a href="https://obit.ru/press-center/news/polovina-it-proektov-provalivaetsya-iz-za-proschetov-na-starte/">исследовании</a> ОБИТ 61% проблемных проектов были связаны с недооценкой стоимости владения ИТ-решением. Компании не полностью учитывали стоимость интеграции, дальнейшего обслуживания и обучения сотрудников. В 48% случаев возникали сложности интеграции с существующей инфраструктурой, в 35% выбранное решение не соответствовало фактическим требованиям бизнеса.</p> <p>По оценке ОБИТ, доработки и исправления после неудачного внедрения могут потребовать еще <nobr>10-30%</nobr> от первоначального бюджета. В отдельных случаях перезапуск проекта требует вложений, сопоставимых с первоначальными или даже вдвое большими.</p> <p>Если компания говорит, что внедрение стоит 15 млн. рублей, стоит уточнить, что именно входит в эти 15 млн.:</p> <ul> <li>Только разработка? </li> <li>Разработка и лицензии? </li> <li>А интеграции? </li> <li>Миграция данных? </li> <li>Изменения в действующих системах? </li> <li>Инфраструктура? </li> <li>Информационная безопасность? </li> <li>Переходный период, когда старое и новое решение работают параллельно?</li> <li> Обучение? </li> <li>Поддержка? </li> <li>Развитие продукта через год? </li> <li>Стоимость сотрудников заказчика, которые будут участвовать в проекте?</li> </ul> <p>Цифровой продукт редко заканчивает потреблять деньги в день релиза. Поэтому сравнивать варианты только по стоимости разработки не очень полезно.</p> <p>Условный проект может выглядеть так:</p> <ul> <li>15 млн. рублей стоит разработка и внедрение;</li> <li>еще 2 млн. потребовали доработки интеграций; </li> <li>1,5 млн. ушли на подготовку и миграцию данных из смежных ИС; </li> <li>1 млн. на переход и обучение;</li> <li>2,5 млн. на поддержку и доработки первого года.</li> </ul> <p>Мы получили уже 22 млн. вместо 15 млн. Это не среднерыночный расчет и не прогноз для любого проекта, а просто иллюстрация того, насколько по-разному могут выглядеть «стоимость разработки» и «сколько бизнес реально потратил на изменение». Поэтому разумнее считать совокупную стоимость владения (ТСО) хотя бы на несколько лет.</p> <p>Иногда более дорогой продукт на этапе покупки оказывается дешевле в эксплуатации. А иногда дешевое коробочное решение через два года обрастает таким количеством доработок, что стоимость его поддержки становится отдельной строкой бюджета.</p> <h2>Ошибка 4. Сначала выбрать технологию, а потом искать ей задачу</h2> <p>Еще несколько лет назад бизнес хотел блокчейн. Сейчас хочет AI. Между ними были супераппы, low-code, микросервисы и много чего еще. Фраза «нам нужно внедрить AI» сама по себе ничего не говорит о том, что компании нужно сделать. То же относится к CRM, ERP, мобильному приложению или отечественной замене зарубежной системы.</p> <p>В анализе ОБИТ 35% проблемных внедрений были связаны с тем, что выбранное решение не соответствовало фактическим бизнес-требованиям. В числе причин компания называет недостаточное тестирование продукта до внедрения и незрелость самого решения. Отдельно эта проблема проявилась во время импортозамещения.</p> <p>Т1 и РУССОФТ <a href="https://t1.ru/media/news/issledovanie-it-kholdinga-t1-i-russoft-spros-na-rossiyskie-it-resheniya-opredelyaetsya-strategiey-ra">исследовали</a> 78 российских компаний с фокусом на крупный бизнес. Среди серьезных препятствий при переходе на отечественные системы компании называли высокую стоимость новых продуктов, проблемы совместимости с текущей инфраструктурой и недостаточную функциональную зрелость части российских аналогов.</p> <p>Одновременно 54% респондентов уже включают миграцию на российские технологии в стратегию развития собственных информационных систем. Только 14% рассматривают импортозамещение исключительно как вынужденную реакцию на внешние обстоятельства.</p> <p>В исследовании РБК и Ростелекома среди 308 руководителей российских компаний 36,7% <a href="https://rtkit.rbc.ru/">назвали</a> одной из проблем импортозамещения интеграцию отечественных решений с существующими системами, 32,5% долгие сроки внедрения.</p> <p>То есть задача «заменим зарубежную систему на российскую» сама по себе тоже может оказаться слишком узкой. Если компания все равно вынуждена менять критичный кусок ИТ-ландшафта, логично сначала посмотреть, нужен ли ей точный цифровой аналог старого процесса. Возможно, за годы работы изменился сам бизнес, появились лишние этапы, а некоторые функции старого продукта уже никому не нужны.</p> <p>Поэтому порядок лучше разворачивать следующим образом: сначала проблема → затем целевой процесс → требования → ограничения текущей архитектуры → возможные решения → выбор между готовым продуктом, доработкой и собственной разработкой</p> <p>Не обязательно каждый раз писать новую систему. И не обязательно сразу раскатывать выбранное решение на всю компанию. Если технология новая, интеграций много, а процессы критичные, пилот часто дешевле большого запуска. На ограниченной группе пользователей можно проверить реальные сценарии, производительность, интеграции и ограничения продукта. Это намного лучше, чем обнаружить их после миграции нескольких тысяч сотрудников.</p> <p>После анализа проблемных проектов ОБИТ тоже рекомендует предварительное тестирование и пилотирование, а миграцию критичных систем проводить поэтапно.</p> <h2>Ошибка 5. Автоматизировать старый процесс, не задаваясь вопросом, нужен ли он таким вообще</h2> <p>Когда компания готовит требования к новой системе, самый простой способ их получить — описать текущую работу. Есть пять этапов согласования? Переносим пять этапов в систему. Сотрудник четыре раза вводит одни и те же данные? Сделаем ему четыре красивые формы. Раньше документ отправляли на почту руководителю? Теперь будет кнопка «Отправить руководителю». Формально это цифровизация. Но процесс остался прежним.</p> <p>Здесь есть показательный пример из финансового сектора. В исследовании Ассоциации ФинТех при участии К2Тех 70% компаний <a href="https://k2.tech/press_releases/67-finansovyh-kompanij-rf-vklyuchili-perehod-na-rossijskie-resheniya-v-svoi-strategii-razvitiya/">сообщили</a>, что в ходе трансформации ИТ-архитектуры провели аудит и пересмотр значимой части бизнес-процессов. Более 80% организаций отметили положительные эффекты такой перестройки: повышение эффективности, большую гибкость, создание задела для развития и работу с накопленным техническим долгом.</p> <p>Конечно, финансовый сектор нельзя автоматически переносить на весь российский бизнес. Но сам подход показателен: смена технологий становится поводом пересмотреть процесс, а не просто перенести его в новую систему.</p> <p>· До автоматизации полезно буквально нарисовать процесс как есть: что сейчас делает клиент, сотрудник и система. Затем нарисовать должно быть. И к каждому действию задать неприятный вопрос: </p> <ul> <li>А зачем оно вообще существует? </li> <li> Почему заявка должна пройти три согласования? </li> <li> Почему данные повторно вводятся руками? </li> <li> Почему менеджер переносит информацию из одной программы в другую? </li> <li> Почему человек принимает решение, которое полностью определяется набором формальных правил?</li> <li> Почему клиент должен заполнять то, что компания уже о нем знает?</li> <li> Какие этапы после цифровизации должны не ускориться, а исчезнуть?</li> <li> Если раньше сотрудник заполнял Excel, а теперь заполняет новую корпоративную систему и на всякий случай продолжает вести тот же Excel, то бизнес не очень много выиграл.</li> </ul> <h2>Ошибка 6. Недооценить интеграции, данные, безопасность и аварийные сценарии</h2> <p>На презентации новый продукт обычно выглядит отдельно. Есть красивые экраны приложения, новый личный кабинет, CRM или внутренняя платформа. В реальной ИТ-инфраструктуре ничего отдельно не существует.</p> <p>Мобильному приложению нужно получить пользователя из одной системы, остаток из другой, цены из третьей, историю заказов из четвертой, принять платеж через внешнего провайдера и вернуть результат в ERP. <br/> И здесь начинается та часть проекта, которую бизнес не всегда видит на старте. </p> <p>У ОБИТ сложности интеграции были причиной проблем в 48% проанализированных проектов. Компания отмечает, что они приводили не только к дополнительным затратам, но и к рискам простоев бизнес-процессов.</p> <p>У Comindware 80% участников исследования работают с разрозненными интеграциями.</p> <p>У К2Тех 74% опрошенных видят решение проблемы несогласованных данных в сквозной интеграции систем и создании единого контура управления данными. Интересно, что бизнес не обязательно хочет выбрасывать существующий ИТ-ландшафт: 46% компаний называют приоритетом оптимизацию текущих систем без масштабных инвестиций.</p> <p>То есть еще до интерфейсов полезно нарисовать карту интеграций и данных:</p> <ul> <li>Откуда приходит каждый тип информации?</li> <li> Какая система считается источником истины?</li> <li> Кому разрешено менять данные?</li> <li> Как часто они синхронизируются? </li> <li> Что происходит, если две системы содержат разные значения?</li> <li> Что будет, если внешнее API не отвечает?</li> <li> А если запрос был отправлен дважды?</li> <li> Как система восстановит операцию после сбоя?</li> <li> Кто увидит ошибку и кто будет ее разбирать?</li> <li> Вот эти вопросы часто влияют на стоимость проекта сильнее, чем количество экранов.</li> </ul> <strong>Отдельно стоит проверить, что будет при сбоях.</strong> <p>Цифровизация делает бизнес быстрее, но заодно сильнее связывает операции с технологиями. Если раньше недоступность одного сервиса мешала части сотрудников, после автоматизации сбой может остановить всю цепочку.</p> <p>КРОК в исследовании 70 ИТ-руководителей крупных и крупнейших российских компаний <a href="https://www.croc.ru/press_releases/issledovanie-krok-90-kompanij-apk-i-52-ritejlerov-stali-bolshe-tratit-na-it-v-2025-godu/">отметил</a>, что в 2025 году заметно вырос фокус на резервировании и отказоустойчивости. Среди инфраструктурных проблем 36% респондентов называли отсутствие резервного ЦОДа, необходимость зеркалировать резервные копии, дублировать сети и сервисы. Поэтому до запуска стоит проверять не только happy path, где все работает как задумано.</p> <ul> <li>Что произойдет, если платежный сервис недоступен два часа?</li> <li> Если упала CRM?</li> <li> Если внешняя система отвечает десять секунд вместо одной?</li> <li> Если в Black Friday нагрузка выросла в несколько раз?</li> <li> Если мобильное приложение работает, а один из внутренних сервисов нет?</li> </ul> <p>Хорошая архитектура предусматривает не только полную работоспособность, но и управляемую деградацию. Пользователь по возможности должен сохранить хотя бы часть сценариев, а бизнес понимать, как система вернется в штатный режим.</p> <p><strong>И безопасность нельзя добавлять последним пунктом перед релизом. </strong></p> <p>Исследования показали, что крупные российские компании назвали соответствие высоким требованиям информационной безопасности главным критерием выбора ИТ-партнера, а кибербезопасность остается одним из основных направлений ИТ-инвестиций российского бизнеса.</p> <p>Но безопасность влияет не только на выбор подрядчика. Она может заметно поменять архитектуру, способ хранения данных, процессы авторизации, интеграции, инфраструктуру и стоимость разработки. Если требования ИБ появляются после того, как продукт уже почти готов, часть работы иногда приходится делать заново.</p> <h2>Ошибка 7. Решить, что legacy обязательно нужно переписать</h2> <p>Старому коду легко назначить виноватого. Если релизы идут медленно, разработчики жалуются на монолит, документации мало и вокруг системы накопилось много странных решений, появляется естественное желание: давайте перепишем все нормально. Иногда это правда правильный вариант. Но возраст системы сам по себе еще не бизнес-проблема.</p> <p>Опираясь на данные вышеуказанных исследований, 78% российских компаний, использующих облачные технологии, сохраняют legacy-системы. У 14% legacy составляет больше половины ИТ-портфеля. 46% участников называют одним из главных приоритетов оптимизацию существующих систем без масштабных инвестиций. В исследовании КРОК более 30% респондентов говорили о необходимости обновления оборудования и работы с legacy. Тут нет противоречия. Потому что legacy можно модернизировать по-разному.</p> <p>Допустим, старое ядро работает стабильно, содержит критическую бизнес-логику и справляется с нагрузкой. Но у него плохие интеграции. Тогда иногда разумнее оставить ядро и построить нормальный API-слой.</p> <p>Если тормозит один модуль, можно вынести его. Если система мешает независимым релизам, разделить наиболее проблемные компоненты. Если высокая стоимость поддержки связана с конкретной частью кода, провести рефакторинг именно там.</p> <p>Полная замена тоже возможна, но тогда бизнесу стоит понимать, что именно он покупает за стоимость переписывания:</p> <ul> <li>Будут быстрее запускаться функции?</li> <li> Снизится стоимость поддержки?</li> <li> Уйдут ограничения по нагрузке?</li> <li> Станет проще находить разработчиков?</li> <li> Исчезнут риски безопасности?</li> <li> Можно будет подключать новые продукты?</li> <li> Если на эти вопросы нет ответа, то проект под названием «перепишем все с нуля» легко превращается в очень дорогой способ получить почти то же самое.</li> </ul> <p>Особенно рискован big bang, когда старая система выключается, а новая должна одномоментно заменить все функции. Чем критичнее продукт, тем разумнее рассматривать поэтапную миграцию, когда часть функций или пользователей переводится последовательно и у команды остается возможность проверить систему на реальной работе.</p> <p>Иногда хороший результат технического аудита звучит не как «вам нужно 30 млн. рублей на новый продукт», а как «эту часть вообще не трогаем».</p> <h2>Ошибка 8. Сначала внедрить AI, а потом разбираться с данными</h2> <p>С AI проблема качества данных стала гораздо заметнее. Можно купить хороший инструмент прогнозирования, подключить BI, внедрить AI-ассистента или модель для автоматического принятия решений. Но если клиент хранится в трех системах под разными идентификаторами, справочники не совпадают, часть данных вводится вручную, а происхождение цифры в отчете никто не может объяснить, новая технология это не исправит. Она будет работать с тем, что ей дали.</p> <p>51% компаний сохраняют внедрение AI среди ключевых приоритетов. Одновременно 68% респондентов говорят, что не получают целостной картины данных из-за разрозненного ИТ-ландшафта.</p> <p>В исследовании КРОК качество входных данных и отсутствие формальных регламентов названы среди факторов, которые мешают масштабированию технологических инициатив.</p> <p>Отдельно Strategy Partners <a href="https://strategy.ru/research/research/polovina-promyshlennyh-predpriyatij-ispytyvaet-deficit-chelovecheskih-resursov-i-kompetencij-dlya-raboty-s-dannymi/">исследовала</a> работу с данными на российских промышленных предприятиях. В 56% компаний ручной ввод остается распространенным способом сбора данных. Только у четверти есть отдельное подразделение для работы с данными, еще у 36% выделен специалист по аналитике. Среди основных барьеров компании называют нехватку людей, компетенций и технических ресурсов.</p> <p>Это особенно важный момент для AI-проектов, потому что там качество исходной информации напрямую связано с качеством результата.</p> <p>До запуска стоит разобраться:</p> <ul> <li> где хранится мастер-версия данных;</li> <li> кто является их владельцем;</li> <li> кто отвечает за качество;</li> <li> есть ли дубли;</li> <li> насколько информация полная и свежая;</li> <li> как изменяются справочники;</li> <li> можно ли понять происхождение конкретного значения;</li> <li> какие данные вообще нельзя использовать в выбранном сценарии;</li> <li> кто отвечает за ошибку, если автоматическая система приняла неправильное решение.</li> </ul> <p>Если у компании три разных значения одного показателя в трех системах, AI не создаст магическим образом правильное. Есть риск, что появится просто четвертый вариант.</p> <h2>Ошибка 9. Считать, что цифровизация закончилась в день релиза</h2> <p>Команда несколько месяцев или лет делает систему. Проходит приемка. Проект закрывают. На презентации появляется зеленый статус «внедрено». А сотрудники продолжают пользоваться Excel. Или переносят часть данных вручную. Или нашли способ обходить новый процесс, потому что старый быстрее. Или система используется, но время выполнения операции не уменьшилось.</p> <p>Технический запуск еще не означает, что произошло изменение бизнеса.</p> <p>В исследовании Т1 и РУССОФТ сопротивление сотрудников новым системам отметили 79,5% представителей крупных компаний. В исследовании Русской школы управления эту проблему отметили 29% респондентов.</p> <p>Разница в цифрах большая, потому что исследования изучали разные выборки и сценарии. Т1 и РУССОФТ рассматривали крупный бизнес и переход на отечественные системы, РШУ шире спрашивала о цифровизации управленческих процессов. Но обе работы показывают, что технология сама по себе не заставляет людей изменить способ работы.</p> <p>И здесь легко дать неправильный совет: «нужно лучше обучать сотрудников». Обучение нужно, но сначала стоит проверить сам продукт. Если раньше сотрудник выполнял пять действий, а после внедрения системы делает восемь, сопротивление не обязательно связано с консерватизмом. Если новая программа работает медленнее старой, человек будет искать обходной путь. Если данные нужно вводить и в старую, и в новую систему, он продолжит вести Excel. Если продукт не учитывает реальные исключения из процесса, сотрудники быстро построят вокруг него собственный параллельный процесс в почте и мессенджерах.</p> <p>Поэтому после релиза важно измерять не только технические показатели. Да, нужны uptime, количество ошибок и SLA. Но параллельно стоит смотреть:</p> <ul> <li> какая доля сотрудников действительно работает в новой системе;</li> <li> какую часть процесса они проходят в ней полностью;</li> <li> сколько ручных операций осталось;</li> <li> сколько времени занимает задача;</li> <li> изменилась ли частота ошибок;</li> <li> не продолжают ли сотрудники вести параллельные таблицы;</li> <li> как часто им приходится обходить систему;</li> <li> изменился ли бизнес-показатель, ради которого все начиналось.</li> </ul> <p><strong>Цифровизация заканчивается тогда, когда изменился процесс и появился измеримый результат для бизнеса.</strong></p> <p>Именно поэтому сложный цифровой продукт почти никогда нельзя воспринимать как объект, который один раз разработали и забыли. Меняется бизнес, появляются новые требования, интеграции, регуляторика, нагрузка. Продукту приходится меняться вместе с ними.</p> <h2>Что проверить до того, как утвердить бюджет</h2> <p>Ошибки из этой статьи могут выглядеть очень разными, но большинство можно обнаружить до начала большой разработки. Перед запуском проекта полезно честно ответить хотя бы на несколько групп вопросов.</p> <p><strong>Бизнес</strong><strong>:</strong></p> <ul> <li>Какую проблему мы решаем?</li> <li> Сколько она стоит компании сейчас? </li> <li> Какой показатель должен измениться после запуска?</li> <li> Знаем ли мы его текущее значение?</li> <li> Как поймем через полгода, что проект сработал?</li> </ul> <p><strong>Процесс</strong><strong>:</strong></p> <ul> <li>Нужно ли вообще автоматизировать процесс в его нынешнем виде?</li> <li> Какие этапы можно убрать?</li> <li> Какие действия должен перестать делать человек?</li> <li> Не создаем ли мы цифровую копию старой бюрократии?</li> </ul> <p><strong>ИТ-ландшафт</strong><strong>:</strong></p> <ul> <li>Какие системы затронет новый продукт?</li> <li> Сколько интеграций потребуется?</li> <li> Где находится источник истины для каждого типа данных?</li> <li> Что придется доработать в существующих системах?</li> <li> Что будет, если одна из интеграций перестанет работать?</li> </ul> <p><strong>Деньги</strong><strong>:</strong></p> <ul> <li>Посчитана стоимость разработки или полная стоимость владения?</li> <li> Учтены ли миграция данных, инфраструктура, интеграции и обучение?</li> <li> Как будет финансироваться поддержка?</li> <li> Кто будет развивать систему после первого релиза?</li> <li> Сколько решение будет стоить компании через три года?</li> </ul> <p><strong>Технология</strong><strong>:</strong></p> <ul> <li>Почему выбран именно этот класс решений?</li> <li> Смотрели ли мы альтернативы?</li> <li> Нужна ли собственная разработка?</li> <li> Можно ли доработать существующий продукт?</li> <li> Нужно ли действительно полностью переписывать legacy?</li> <li> Можно ли сначала проверить гипотезу на пилоте?</li> </ul> <p><strong>Риски</strong><strong>:</strong></p> <ul> <li>Что произойдет при пиковой нагрузке?</li> <li> Как работает система при частичной недоступности сервисов?</li> <li> Есть ли план поэтапной миграции и возможность отката?</li> <li> Учтены ли требования информационной безопасности в архитектуре, а не только перед релизом?</li> <li> Какие данные система получает и можно ли им доверять?</li> </ul> <p><strong>Пользователи</strong><strong>:</strong></p> <ul> <li>Участвовали ли реальные сотрудники или клиенты в проверке сценариев?</li> <li> Станет ли им проще выполнять задачу?</li> <li> Не придется ли пользоваться старой и новой системой одновременно?</li> <li> Как мы измерим реальное использование продукта после запуска?</li> </ul> <p>Если на значительную часть этих вопросов пока нет ответа, возможно, компании еще рано проводить тендер на разработку.</p> <p>Иногда первым этапом должен стать не дизайн приложения и не оценка программистами количества часов, а обследование: разбор процессов, архитектуры, интеграций, данных, технического долга, требований безопасности и экономики будущего решения.</p> <p>Такой этап тоже стоит денег. Но его задача как раз в том, чтобы не выяснять самые дорогие особенности проекта тогда, когда контракт уже подписан, команда работает, а половина бюджета потрачена.</p> <p>Цифровизация обходится дорого не только тогда, когда разработчики ошибаются в коде. Гораздо больше денег можно потерять раньше: выбрать не ту задачу, не посчитать владение, добавить еще одну систему в уже сложный ландшафт или автоматизировать процесс, который стоило сначала переделать.</p> <p>И чем крупнее проект, тем дороже становится вопрос, который бизнес не задал себе на старте.</p> <p> #IMAGE_235402#</p> Цифровизация должна сокращать издержки и ускорять бизнес, но иногда происходит наоборот: новая система требует дорогих … article Владимир Белозеров, заместитель коммерческого директора компании KODE https://www.itweek.ru/themes/detail.php?ID=235416 Wed, 26 Aug 2026 17:10:38 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI платформы. Обновление позволяет снизить нагрузку на администраторов системы и сократить количество ручных действий за счет гибкой настройки индикаторов SLA и копирования блоков рабочих процессов, а также упрощает работу с записями в связанных списках благодаря добавлению поддержки массового редактирования.</p> <p>Ключевое изменение версии 1.35.0 — более гибкая настройка индикаторов SLA. Теперь параметры расчёта индикации — момент запуска отсчёта, момент превышения срока, рабочее расписание и часовой пояс — можно определять не только вручную, но и на основании данных из связанных с обращением записей. </p> <p>Такая функциональность полезна в территориально распределённых компаниях. Например, сроки по заявке нужно считать по графику той площадки, которая обслуживает сотрудника: у сотрудника указан город, у города — обслуживающая площадка, у площадки — свой рабочий календарь и часовой пояс. Раньше под каждый календарь приходилось заводить отдельный индикатор, клиенты компании сообщали о <nobr>10–15</nobr> копиях одного и того же SLA. Теперь достаточно одного индикатора: он проходит по цепочке связей и охватывает нужные параметры сам. Календарь — только один из параметров, по тому же механизму задаются часовой пояс и обе временны́е точки. При этом источником служит любая связанная с обращением запись, то есть под контекст подстраивается не отдельный сценарий, а расчёт SLA целиком.</p> <p>Второе значимое улучшение — добавление возможности копирования блоков в редакторе рабочих процессов. Администраторы теперь могут копировать блок действий в текущие процессы, а также другие рабочие процессы, сохранив все параметры настройки. Новая функциональность заметно ускоряет настройку процессов и сокращает количество ошибок при настройке.</p> <p>Дополнительно были расширены возможности массового редактирования: теперь редактирование поддерживается не только в основных списках записей, но и в связанных списках. Администраторы и агенты поддержки могут быстро вносить одинаковые изменения сразу в несколько записей, без необходимости переходить в отдельное представление списка.</p> <p>«Мы сознательно сосредоточились на участках, где у администраторов больше всего рутины: гибкие SLA и переиспользование блоков рабочих процессов. Для нас стоимость владения системой — отдельное направление развития в каждом релизе. Мы считаем, что платформа должна дешеветь в сопровождении по мере роста конфигурации, не наоборот. Ведь именно от нагрузки, связанной с поддержкой системы, зависит, сколько времени и ресурсов команда клиента сможет потратить на ее развитие», — прокомментировал Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG.</p> <p>Помимо новой функциональности, в версии 1.35.0 устранён ряд дефектов, включая проблемы с контейнерами, уязвимости безопасности и ошибки в работе индикаций. </p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила версию 1.35.0 Low-code GenAI платформы. Обновление … message https://www.itweek.ru/themes/detail.php?ID=235415 Wed, 26 Aug 2026 17:09:06 +0300 <p>Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное, безопасное и системное использование инструментов генеративного ИИ для проектов по интеграции данных и разработке дата-продуктов. Новый подход призван перевести корпоративные ИИ-эксперименты из режима точечного применения в управляемый процесс с прозрачными расчетами, которые опираются на отслеживаемые данные и дают контролируемый результат. </p> <p>Методология предназначена для компаний, которые уже используют или планируют использовать <nobr>LLM-инструменты</nobr> и ИИ-агентов в разработке решений по управлению данными. </p> <p>В ее основе лежит концепция Data Governance, переосмысленная с учетом современных возможностей генеративного ИИ. Дата-продукты являются разновидностью программного обеспечения, однако обладают целым рядом особенностей, требующих отдельной методики разработки. В традиционной разработке основной фокус сосредоточен на функциях продукта: интерфейсе, бизнес-логике, пользовательских сценариях, фронтенде и бэкенде. В случае с дата-продуктами он направлен преимущественно на сами данные — их происхождение, определения, взаимосвязи, контекст и правила интерпретации. </p> <p>Ключевая задача методологии — сделать так, чтобы данным можно было верить. В корпоративной среде недостаточно получить цифру, которая выглядит правдоподобно. Важно понимать, из каких источников она получена, по каким правилам рассчитана, какие исходные данные использовались, кто отвечает за определения, можно ли воспроизвести расчет и т.п. Качество данных особенно важно для бизнес-аналитики, управленческой и регуляторной отчетности.</p> <p>Ошибка в одном показателе или неоднозначность в трактовке данных может привести к неверным руководящим решениям, в том числе стратегическим, а также к претензиям со стороны надзорных органов.</p> <p>Предложенный подход включает ряд ключевых этапов:</p> <ul> <li>оценку текущей зрелости компании в работе с данными и ИИ-инструментами;</li> <li>адаптацию методологии к конкретным бизнес-реалиям и ИТ-ландшафту;</li> <li>определение функциональной архитектуры будущей системы;</li> <li>анализ уже существующих инструментов Data Governance, каталогов, глоссариев и средств контроля качества данных;</li> <li>выявление недостающих элементов;</li> <li>выбор инструментов для поддержки целевого процесса;</li> <li>запуск пилотного проекта по созданию дата-продукта по новой методике;</li> <li>формирование контекстного и семантического слоя для уже существующих источников.</li> </ul> <p>Методология вводит понятие опорного слоя и придает ему особое значение. Опорный слой включает в себя онтологию и семантику, а также так называемый контур доверия. Без него невозможно обеспечить единое понимание бизнес-понятий, метрик и правил интерпретации данных на уровне всей компании. Именно опорный слой должен стать связующим элементом между бизнес-смыслом, источниками данных, методиками расчета показателей и ИИ-инструментами, которые участвуют в разработке, а в дальнейшем, и потреблении данных.</p> <p>Методология также предполагает бережное отношение к уже сделанным компанией инвестициям. Если у нее есть каталоги данных, бизнес-глоссарии, инструменты контроля качества или другие элементы Data Governance, их не нужно заменять автоматически. В них уже накоплены метаданные, определения и управленческий контекст. Задача состоит в том, чтобы встроить существующие активы в новую архитектуру, определить недостающие элементы и обеспечить совместимость старого и нового подходов.</p> <p>«Есть иллюзия, что с помощью ИИ можно в считанные минуты сгенерировать нужное приложение, имея только бизнес-идею. На самом деле это не так просто, особенно в отношении дата-продуктов. Крайне важно определить для ИИ „смысл“ данных компании, погрузить его в контекст. В противном случае есть серьезный риск получить „черный ящик“, корректность и безопасность работы которого невозможно проверить. Наша методология объясняет, как сформировать грамотную среду управления данными и построить взаимодействие с ИИ так, чтобы дата-продукты были предсказуемыми, прозрачными и воспроизводимыми и как результат, давали корректную аналитику», — прокомментировала Лариса Малькова, управляющий директор практики «Данные и прикладной ИИ» Axenix.</p> Компания Axenix сообщила о создании первой в России методологии, позволяющей организациям выстроить эффективное … message https://www.itweek.ru/themes/detail.php?ID=235414 Wed, 26 Aug 2026 17:04:43 +0300 <p>Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие решения на базе ИИ: постоянное взаимодействие с технологией дает им комплексное представление о ее возможностях, ограничениях и влиянии на рынок труда. Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил прогнозные оценки более 500 таких организаций, полученные в рамках Мониторинга разработки и применения технологий искусственного интеллекта и цифровой трансформации бизнеса.</p> <p>В работе с информацией направление изменений зависит от характера выполняемых задач. Спрос на базовые навыки, связанные с вводом данных и подготовкой документации, будет в целом снижаться (сокращение прогнозируют 45% организаций, рост — 25%), а на аналитические компетенции — расти (36% против 27% прогнозирующих снижение). ИИ автоматизирует рутинные операции, однако постановка задач, интерпретация выводов и принятие решений сохранятся за специалистами.</p> <p>Для ИТ-навыков оценки влияния ИИ оказались неоднозначными. Снижение спроса на навыки программирования прогнозируют 30% организаций, рост — 29%, стабильность — 34%. Автоматизация части работы с кодом может сдерживать найм, однако усложнение программных продуктов и интеграция ИИ-моделей одновременно повышают потребность в технической экспертизе. Востребованность навыков установки и защиты компьютерных систем оценивается более определенно: роста спроса ожидают 38% респондентов, снижения — лишь 11%. Вероятно, увеличение объема генерируемого ИИ кода и применение технологии для кибератак повышают потребность в квалифицированном контроле, настройке и защите систем.</p> <p>В менеджменте центр тяжести будет смещаться от администрирования к стратегии и лидерству. Снижение управленческих рутин прогнозируют 35% организаций, рост — 26%. При этом повышения востребованности стратегического мышления и навыков управления процессами ожидают 41% респондентов, лидерства и мотивации — 36%; снижение спроса на эти навыки предполагают лишь 6 и 4% соответственно. Документооборот, календарное планирование и контроль отчетности поддаются автоматизации, тогда как выбор приоритетов, разрешение конфликтов, мотивация команды и формирование среды доверия остаются за руководителями.</p> <p>Для рабочих профессий уязвимость перед ИИ зависит прежде всего от степени стандартизации операций и разнообразия условий труда. В обследовании сопоставлялись навыки разного уровня квалификации — от вождения и обслуживания оборудования до сортировки, погрузки, сборки и строительства. Наиболее высок риск снижения спроса на сортировку и упаковку: сокращение прогнозируют 29% организаций, рост — 16%. Значительно устойчивее монтаж и ремонт оборудования (снижение ожидают только 6%, рост — 24%) и строительство (снижение — 8%; две трети респондентов предполагают сохранение или рост спроса). В отношении вождения оценки разделились: 21% ожидают сокращения востребованности, 22% — повышения. Повторяющиеся операции в стабильных условиях легче передать роботизированным системам, тогда как работа в изменчивой среде пока требует человеческой адаптивности. В долгосрочной перспективе развитие робототехники и автономных систем будет расширять границы автоматизации.</p> <p>Высокой устойчивостью к ИИ-автоматизации обладают человекоориентированные компетенции: уход за людьми, оказание медицинских услуг, коммуникации, сотрудничество, консультирование, креативность. Наименее уязвимы навыки, основанные на командной работе, общении, доверии и физическом присутствии: снижение спроса на них прогнозируют лишь <nobr>9–13%.</nobr> Более неоднозначно оценивается креативность: роста ее востребованности ожидают 28% респондентов, снижения — 23%. С одной стороны, ИИ уже способен генерировать тексты и изображения, с другой — снижает порог входа в креативную деятельность, беря на себя технические задачи и тем самым создавая возможности для новых замыслов и подходов.</p> <p>Изменения профессиональных компетенций затронут большинство профессий. Риски и возможности, которые несет ИИ, определяются не статусом профессии или уровнем квалификации работников, а содержанием выполняемых задач. Повторяющиеся стандартизированные задачи, которые можно описать с помощью инструкций и алгоритмов, в перспективе будут переданы ИИ, а необходимые для их выполнения навыки потеряют ценность. Одновременно увеличится спрос на компетенции более высокого порядка, связанные с принятием решений в условиях неопределенности, лидерством, командной работой, обеспечением безопасности. Итоговый баланс оценок подтверждает этот сдвиг: верхние позиции заняли стратегическое управление, лидерство и мотивация, установка и защита компьютерных систем, нижние — документирование информации, сортировка и упаковка, простые административные задачи.</p> Какие навыки ИИ повышает в цене, а какие — снижает? Раньше других это могут оценить организации, создающие … message https://www.itweek.ru/themes/detail.php?ID=235413 Wed, 26 Aug 2026 17:04:31 +0300 <p><em>Рост инвестиций в развитие российских софтверных компаний, который достигал примерно <nobr>30-35%</nobr> в 2024 году, в 2025 году сменился их сокращением на 37%. Абсолютная величина совокупных инвестиций уменьшилась с ₽575 млрд. до ₽360 млрд.</em></p> <p>В условиях отсутствия других полноценных источников инвестиций почти вся прибыль предприятий, специализирующихся на разработке ПО, направляется на развитие, поэтому увеличение налоговой нагрузки неизбежно привело к сокращению инвестиционной активности. Напомним, что с 1 января 2025 года был введен НДС для малых компаний, использующих УСН, а вместо нулевого налога на прибыль для аккредитованных ИТ-компаний введена ставка в размере 5%.</p> <p>Математически само по себе увеличение отчислений в бюджет могло дать сокращение только на <nobr>5-10%.</nobr> На увеличение налоговой нагрузки наложилось снижение темпов роста спроса из-за высокой ставки ЦБ РФ и ряда других факторов. В результате продажи компаний-разработчиков ПО росли медленнее их затрат, а это привело к снижению рентабельности софтверного бизнеса.</p> <p><strong>Основные показатели, характеризующие инвестиционную активность в софтверной индустрии в <nobr>2024-2026</nobr> годах</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2024 г.</p> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Отношение совокупных инвестиций к совокупному обороту софтверных компаний</p> </td> <td> <p>23,5%</p> </td> <td> <p>12,8%</p> </td> <td> <p>13,0%</p> </td> </tr> <tr> <td> <p>Объем инвестиций</p> </td> <td> <p>₽575 млрд</p> </td> <td> <p>₽360 млрд</p> </td> <td> <p>₽425 млрд</p> </td> </tr> <tr> <td> <p>Доля опрошенных компаний, сообщивших о привлечении инвестиций</p> </td> <td> <p>47,2%</p> </td> <td> <p>38,0%</p> </td> <td> <p>35,3%</p> </td> </tr> <tr> <td> <p>Доля внешнего финансирования <br/> в общем объеме инвестиций </p> </td> <td> <p>19,3%</p> </td> <td> <p>17,7%</p> </td> <td> <p>19,0%</p> </td> </tr> <tr> <td> <p>Доля опрошенных компаний, сообщивших о наличии внешних инвестиций</p> </td> <td> <p>27,4%</p> </td> <td> <p>25,5%</p> </td> <td> <p>25,1%</p> </td> </tr> <tr> <td> <p>Общий объем внешних инвестиций</p> </td> <td> <p>₽110 млрд</p> </td> <td> <p>₽64 млрд</p> </td> <td> <p>₽81 млрд</p> </td> </tr> </tbody> </table> <p>Ассоциация РУССОФТ проводила в 2025 году экспресс-опросы софтверных компаний с целью моделирования изменения ряда показателей финансового состояния бизнеса при сохранении всех льгот и при частичном лишении налоговых послаблений. Результаты этих опросов показали, что увеличение налоговой нагрузки негативно отразится прежде всего на объеме инвестиций. При нынешних условиях в софтверной индустрии существует прямая корреляция совокупной прибыли софтверных компаний и совокупных вложений в их развитие. Поскольку совокупная чистая прибыль по итогам 2025 года сократилась примерно на треть, то и почти аналогично снизился объем инвестиций в софтверной индустрии.</p> <p>С 1 января 2026 года было введено еще одно изменение в налоговой политике — страховые взносы для аккредитованных ИТ-компаний увеличились примерно вдвое (с 7,6% до 15%). С учетом того, что <nobr>60-80%</nobr> затрат софтверных компаний приходится на фонд оплаты труда, дополнительные отчисления существенно сокращают прибыль при прочих равных условиях. Тем не менее, результаты опроса показывают сдержанный оптимизм.</p> <p>Расчеты на основании планов опрошенных компаний на 2026 год дают рост совокупных инвестиций на 18%. Предположительно выручка увеличится на 17%, чуть возрастет доля внешнего финансирования (с 17,7% до 19,0%), а дополнительные отчисления в пенсионный и социальные фонды частично компенсирует снижение темпов роста средней зарплаты. Прибавка на 18% отражает скорее самый оптимистический сценарий. Реалистичный же предполагает меньший прирост. При этом нельзя исключить и сокращение инвестиций.</p> <p>Показатель удовлетворенности респондентов имеющимся объемом инвестиций, как правило, очень низкий. Опрашиваемые компании в течение нескольких лет видели перспективы окупаемости при вложениях, которые должны были быть в <nobr>2-3</nobr> раза больше фактических. Произошедший в 2021 году инвестиционный бум привел к тому, что потребность в инвестициях в индустрию была удовлетворена намного лучше, чем в предыдущие годы — на 58%. В 2022 году произошел рост показателя удовлетворенности респондентами объемами финансовых вложений до 63%, но этот год был особенным: из-за высокой степени неопределенности не столько выросли вложения, сколько снизилась в них потребность. В 2023 году показатель удовлетворенности снизился до 51%, а в 2024 году — до 42%. Уменьшение этого показателя при росте объема инвестиций говорит о том, что потребность в инвестициях росла быстрее, чем объем инвестиций в развитие софтверных компаний, что было объяснимо на фоне активной реализации процесса импортозамещения ПО.</p> <p>По итогам 2025 года показатель удовлетворенности в инвестициях уменьшился еще больше. По всем опрошенным компаниям фактические вложения составили менее четверти от требуемых (23,5%). Если опираться на ожидания опрошенных компаний, то в 2026 году этот показатель должен повыситься, но все же останется очень низким — 27,2%.</p> <p>Удовлетворенность в объеме инвестиций ниже у продуктовых компаний в сравнении с сервисными, что объясняется их потребностью в разработке собственного программного продукта, что занимает длительное время.</p> <h3>Распределение стабильно</h3> <p>По итогам 2024 года доля собственных инвестиций софтверных компаний составила 77,3%. В 2025 году изменение этого показателя оказалось незначительным. В 2026 году имеются надежды на небольшое увеличение внешнего финансирования (прежде всего, государственного), но структура инвестиций в целом ожидается неизменной при допущении незначительных колебаний.</p> <p><strong>Распределение объема инвестиций в индустрию программного обеспечения по источникам финансирования (по итогам <nobr>2024-2026 годов)</nobr></strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2024 г.</p> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Собственные вложения (реинвестиции из прибыли)</p> </td> <td> <p>77,3%</p> </td> <td> <p>76,8%</p> </td> <td> <p>74,8%</p> </td> </tr> <tr> <td> <p>Дополнительные вложения учредителей</p> </td> <td> <p>3,5%</p> </td> <td> <p>5,6%</p> </td> <td> <p>6,2%</p> </td> </tr> <tr> <td> <p>Полученные от заказчиков/клиентов средства, которые пошли на развитие (создание новых тиражируемых решений или новых версий уже существующих решений)</p> </td> <td> <p>15,7%</p> </td> <td> <p>13,85%</p> </td> <td> <p>14,4%</p> </td> </tr> <tr> <td> <p>Государственное финансирование (без участия частных инвесторов), включая гранты и субсидирование льготного кредитования</p> </td> <td> <p>1,9%</p> </td> <td> <p>1,6%</p> </td> <td> <p>4,3%</p> </td> </tr> <tr> <td> <p>Вложения сторонних частных инвесторов (в т. ч. фондовый рынок, венчурные фонды, включая созданные с участием государства)</p> </td> <td> <p>0,4%</p> </td> <td> <p>2,15%</p> </td> <td> <p>0,3%</p> </td> </tr> <tr> <td> <p>Другие источники</p> </td> <td> <p>1,2%</p> </td> <td> <p>—</p> </td> <td> <p>—</p> </td> </tr> </tbody> </table> <p>Если при анализе данных по распределению инвестиций между собственными и привлеченными средствами по итогам 2025 года к собственным средствам добавить инвестиции со стороны учредителей, то эта доля увеличится до 82,4%. Следовательно, на все источники внешнего финансирования приходится 17,6%. Годом ранее этот показатель был равен 19,2%.</p> <p>Вложения сторонних частных инвесторов обеспечивают 2,15% общего объема инвестиций, а годом ранее они составляли 0,4%. Однако делать вывод о каком-то росте активности частных инвесторов пока преждевременно. При единичных случаях привлечения внешних инвесторов очень велико влияние случайных факторов. Рост до 2,15% в 2025 году обеспечила одна компания, участвовавшая в опросе. Без учета ее данных такого роста не будет. К тому же, в 2026 году ожидается возвращение участия внешних источников инвестиций к прежнему уровню.</p> <h3>Самые привлекательные</h3> <p>При делении компаний на категории выяснилось, что у компаний с выручкой менее ₽375 млн. в 2025 году имелась бОльшая доля внешних инвестиций в общем объеме вложений, чем у компаний большего размера. Аналогичное преимущество имелось у небольших предприятий по итогам 2024 года. Соотношение общего объема вложений к обороту у них также выше, чем у компаний с выручкой более ₽375 млн.</p> <p>Продуктовая модель предполагает бОльшую инвестиционную привлекательность в сравнении с сервисной. Однако доля внешнего финансирования в общем объеме инвестиций в <nobr>2024-2025</nobr> годах была выше именно у сервисных компаний. Это, скорее всего, связано с меньшими рисками для внешних инвесторов из-за более коротких сроков окупаемости, и с более низкой рентабельностью, а значит меньшим объемом наличия у них собственных средств для инвестиций.</p> <p>Если по итогам 2024 года соотношение объема инвестиций в развитие относительно оборота были выше у компаний, которые работают только в России в сравнении с предприятиями, имеющими продажи за рубежом, то по итогам 2025 года произошло выравнивание показателей у этих двух категорий компаний.</p> <p><strong>Данные об инвестициях по категориям опрошенных компаний по итогам 2025 года</strong> </p> <table> <tbody> <tr> <td> </td> <td> <p>Объем инвестиций <br/> по отношению к обороту </p> </td> <td> <p>Сообщили <br/> о наличии инвестиций <br/> в 2025 г.,% опрошенных компаний </p> </td> <td> <p>Доля внешнего финансирования во всём объеме инвестиций</p> </td> <td> <p>Сообщили <br/> о наличии внешнего финансирования в 2025 г.,% опрошенных компаний </p> </td> </tr> <tr> <td> <p><strong>Все опрошенные компании</strong></p> </td> <td> <p>13,8%</p> </td> <td> <p>38,0%</p> </td> <td> <p>9,9%</p> </td> <td> <p>25,5%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Размер компаний</strong></p> </td> </tr> <tr> <td> <p>Оборот <br/> менее ₽375 млн </p> </td> <td> <p>24,2%</p> </td> <td> <p>35,7%</p> </td> <td> <p>19,4%</p> </td> <td> <p>24,2%</p> </td> </tr> <tr> <td> <p>Оборот <br/> более ₽375 млн </p> </td> <td> <p>13,1%</p> </td> <td> <p>43,8%</p> </td> <td> <p>8,9%</p> </td> <td> <p>28,8%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Модель бизнеса</strong></p> </td> </tr> <tr> <td> <p>Продуктовая</p> </td> <td> <p>15,0%</p> </td> <td> <p>42,6%</p> </td> <td> <p>8,6%</p> </td> <td> <p>23,6%</p> </td> </tr> <tr> <td> <p>Сервисная</p> </td> <td> <p>6,8%</p> </td> <td> <p>31,8%</p> </td> <td> <p>22,4%</p> </td> <td> <p>28,0%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Наличие экспортных доходов</strong></p> </td> </tr> <tr> <td> <p>Не присутствовали <br/> за рубежом в 2025 г. </p> </td> <td> <p>14,8%</p> </td> <td> <p>33,9%</p> </td> <td> <p>11,5%</p> </td> <td> <p>26,3%</p> </td> </tr> <tr> <td> <p>Присутствовали <br/> за рубежом в 2025 г. </p> </td> <td> <p>12,5%</p> </td> <td> <p>39,5%</p> </td> <td> <p>9,8%</p> </td> <td> <p>18,6%</p> </td> </tr> <tr> <td colspan="5"> <p><strong>Местоположение головного офиса</strong></p> </td> </tr> <tr> <td> <p>Москва</p> </td> <td> <p>14,3%</p> </td> <td> <p>39,7%</p> </td> <td> <p>17,2%</p> </td> <td> <p>23,8%</p> </td> </tr> <tr> <td> <p>Петербург</p> </td> <td> <p>13,2%</p> </td> <td> <p>38,8%</p> </td> <td> <p>10,8%</p> </td> <td> <p>24,5%</p> </td> </tr> <tr> <td> <p>Другие города</p> </td> <td> <p>13,6%</p> </td> <td> <p>37,1%</p> </td> <td> <p>7,1%</p> </td> <td> <p>26,6%</p> </td> </tr> </tbody> </table> Рост инвестиций в развитие российских софтверных компаний, который достигал примерно 30-35% в 2024 году … message https://www.itweek.ru/themes/detail.php?ID=235407 Wed, 26 Aug 2026 09:27:29 +0300 <p><em>Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки мультиоблачного искусственного интеллекта, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Диверсификация поставщиков облачных услуг для поддержки стратегии ИИ может принести свои плоды, но если CIO и CTO не сохранят контроль, они рискуют сделать данные неуправляемыми.</p> <p>По мере того, как рабочие нагрузки ИИ распространяются по все более разнообразной технологической экосистеме, конфиденциальные данные и операционный контекст перемещаются вместе с ними, отмечает Брайан Груттадауриа, CTO по гибридным облакам Hewlett Packard Enterprise. «Реальная цена разрастания поставщиков заключается не только в дополнительной сложности; это фрагментация данных, контекста, управления и контроля именно в тот момент, когда ИИ больше всего от них зависит», — говорит он.</p> <p>Диверсификация поставщиков в рамках мультиоблачной стратегии требует распределения рабочих нагрузок между несколькими облачными провайдерами. Она в основном используется для минимизации зависимости от поставщика, повышения отказоустойчивости и резервирования, а также оптимизации затрат и производительности. К сожалению, в сочетании с ИИ диверсификация поставщиков может внезапно превратиться в настоящий ад.</p> <h3>Признаки неправильной диагностики проблемы</h3> <p>Слишком многие организации рассматривают мультиоблачный ИИ как архитектурную проблему, тогда как на самом деле это организационная и финансовая проблема, считает Джесси Дин, CIO компании TDI Security, занимающейся управлением кибербезопасностью. «Из-за страха перед привязкой к поставщику и слабого управления компании разбрасывают данные и модели по нескольким облакам», — отмечает он. Это может привести к размыванию инженерного кадрового потенциала и увеличению долгосрочных затрат. ИТ-руководителям необходимо все тщательно продумать, чтобы устранить фундаментальные недостатки. «Приоритизация единой стратегии стандартизации данных и приверженность основной облачной среде для размещения данных являются ключом к снижению технической сложности и затрат», — полагает Дин.</p> <p>По словам Ха Хоанг, CIO компании Commvault, риск заключается не в том, что организации полагаются на несколько облаков, поскольку у многих из них есть веские причины для этого. «Риск заключается в том, что каждое облако превращается в собственную экосистему ИИ с различными моделями, конвейерами данных, политиками управления и инструментами для разработчиков», — предупреждает она.</p> <p>Как и многие ИТ-руководители, Хоанг считает, что ИИ принесет наибольшую пользу, когда сможет безопасно получать доступ к надежным корпоративным данным и работать согласованно в масштабе всего бизнеса. Если данные фрагментированы, а политики безопасности различаются в каждом облаке, организации могут получить разрозненных агентов, дублирование инвестиций и непоследовательные бизнес-результаты. «Мультиоблачная среда должна быть обдуманным архитектурным решением, а не случайным результатом независимого выбора технологий», — говорит она.</p> <p>Наиболее явным признаком чрезмерной диверсификации поставщиков является то, что данные и рабочие нагрузки больше не являются последовательно видимыми или управляемыми в разных средах, отмечает Груттадауриа. «Если ИТ-служба не может видеть и контролировать актив, независимо от того, где он находится — в облаке, локально или на периферии, — это признак того, что архитектура переросла возможности управления», — предупреждает он.</p> <h3>Поиск пути выхода из ловушки мультиоблачного ИИ</h3> <p>Ответ на вопрос о том, как избежать ловушки мультиоблачного ИИ, заключается в создании единой ткани данных, охватывающей облако, локальные системы и периферию, формируя единое операционное пространство имен вместо набора разрозненных хранилищ данных, считает Юрий Губин, технический директор компании DataArt, занимающейся разработкой ПО и ИТ-консалтингом. «Когда данные, рабочие нагрузки и ИИ используют общую основу, они остаются видимыми, управляемыми и переносимыми независимо от того, где они работают», — говорит он. Это позволяет организациям внедрять инновации от разных поставщиков, не беря на себя бремя мультивендорной сложности.</p> <p>Начните с управления, а не с технологий, советует Хоанг: «Определите небольшое количество утвержденных платформ ИИ, установите общие стандарты безопасности и идентификации и рассматривайте корпоративные данные как общий актив, а не как нечто, принадлежащее отдельным облакам или бизнес-подразделениям». ИТ-руководители также должны проектировать решения с учетом переносимости там, где это имеет смысл с точки зрения бизнеса. «Это не означает, что каждая рабочая нагрузка должна свободно перемещаться между облаками, но это означает избегание ненужной привязки по основным возможностям ИИ», — поясняет она. Это обеспечит гибкость, которая может создать конкурентное преимущество.</p> <h3>Не забывайте о бизнес-целях</h3> <p>Лучшая профилактика — это создание корпоративной операционной модели ИИ до того, как внедрение ИИ начнет масштабироваться, полагает Хоанг. «Каждая новая платформа ИИ должна соответствовать общим стандартам безопасности, доступа к данным, наблюдаемости, управления и контроля затрат», — говорит она. Также важно обеспечить, чтобы каждая инвестиция в ИИ была связана с измеримым бизнес-результатом. Цель состоит не в том, чтобы поддерживать каждую модель или каждого облачного провайдера; цель состоит в том, чтобы обеспечить бизнес-результаты с наименьшей операционной сложностью.</p> Путь к диверсификации поставщиков обещает быть многообещающим — если только не стать жертвой ловушки … article https://www.itweek.ru/themes/detail.php?ID=235399 Wed, 26 Aug 2026 00:00:00 +0300 <p>ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если <a href="https://www.itweek.ru/themes/detail.php?ID=235254">система получает доступ к корпоративным данным</a>, выполняет действия и запускает процессы, ей действительно нужны права, ограничения и понятная зона ответственности. Так появляются ИИ-аналитики, ИИ-юристы, ИИ-рекрутеры, ИИ-разработчики.</p> <p>Проблемы возникают, когда саму <a href="https://www.itweek.ru/ai/article/detail.php?ID=235377">ИИ-систему</a> начинают выстраивать по принципам привычной оргструктуры. Такой подход понятен, потому что проще встроить нового исполнителя в уже сложившуюся модель работы, чем сразу пересматривать способ ее организации. Но по мере роста числа агентов становится заметно, что фиксированные цифровые роли подходят не для всех задач. И здесь возникает вопрос — а действительно ли ИИ нужна собственная «должность»?</p> <h3>Почему ролевая модель плохо масштабируется</h3> <p>Ролевая модель хорошо работает, пока задачи выполняют люди. У каждого сотрудника есть свой набор компетенций, полномочий и доступов, который формируется под конкретную функцию. Поэтому знания и ответственность естественно закрепляются за отдельными ролями.</p> <p>С ИИ эта логика работает иначе. Ему не обязательно задавать только одну специализацию и ограничивать круг задач. Где-то системе могут понадобиться договоры, юридические правила и история взаимодействия с клиентом, где-то — техническая документация, финансовые показатели и данные из нескольких корпоративных систем. Нужный контекст и инструменты можно подключать непосредственно под задачу.</p> <p>Когда эту возможность не учитывают, количество цифровых ролей начинает расти. Под отдельные функции создаются самостоятельные агенты, хотя на практике несколько из них могут работать с одними данными, обращаться к тем же системам и частично дублировать друг друга. Различаться при этом они будут инструкциями.</p> <p>В одном из наблюдаемых нами кейсов на первом этапе ИИ-трансформации компания создавала узкоспециализированных агентов под отдельные роли. По мере их роста стало заметно, что функции начинают пересекаться, а часть агентов фактически дублирует друг друга. Тогда в систему добавили мастер-агента, который анализировал существующую структуру, менял инструкции, перераспределял задачи и проектировал новые роли. После одного из аудитов он объединил дублирующиеся функции и существенно сократил количество агентов.</p> <p>Этот пример хорошо показывает ограничение ролевого подхода: отдельная специализация оправдана там, где действительно нужны свои полномочия, инструменты или правила работы. Но создавать постоянную цифровую «должность» под каждую новую функцию необязательно.</p> <h3>От должности — к задаче</h3> <p>Альтернативный подход — строить работу вокруг конкретной задачи. Под нее система получает нужный набор контекста: инструкции, данные, правила, корпоративные знания и инструменты. Для следующей задачи этот набор может быть другим.</p> <p>Меняется и вопрос, который задает бизнес. Не «какого цифрового сотрудника нам создать?», а «какой результат нужно получить и что потребуется системе для его достижения?».</p> <p>Такая логика меняет и работу с корпоративными знаниями. Если у каждого агента собственные инструкции и правила, по мере роста системы становится сложнее следить за их актуальностью и полнотой. Одно изменение может затронуть сразу несколько цифровых ролей. В едином контуре знания не закрепляются за конкретным агентом: нужные правила, инструкции, данные и инструменты подключаются в зависимости от задачи.</p> <p>Но корпоративный контекст — это не только регламенты и базы знаний. Такие документы описывают установленный порядок работы, тогда как на практике он может отличаться. Представим, что по регламенту счет на оплату должен пройти проверку, согласование и затем уйти в бухгалтерию. В реальности часть счетов возвращается из-за ошибок, для крупных сумм требуется дополнительное согласование, а некоторые документы проходят по другому маршруту.</p> <p>Различаться может и выполнение отдельных операций внутри одного процесса. Один сотрудник сразу сверяет данные в учетной системе, другой сначала ищет договор, затем проверяет карточку контрагента и только после этого возвращается к счету. Результат один, но последовательность действий и трудозатраты разные.</p> <p>Для ИИ эти нюансы особенно важны. Если фактический порядок работы отличается от формального описания, система рискует опираться на неполную модель процесса и автоматизировать сценарий, который не учитывает часть реальной работы. Поэтому такие расхождения нужно сначала выявить.</p> <p>Для этого используют аналитику бизнес-операций (Task Mining) и аналитику бизнес-процессов (Process Mining). Task Mining показывает, как сотрудники выполняют отдельные операции на компьютере: какие действия совершают и в какой последовательности работают с системами. Process Mining позволяет увидеть реальные маршруты процесса, задержки, возвраты и отклонения между этапами. Для ИИ эти данные могут стать важнейшим источником контекста наряду с классическими регламентами, правилами и корпоративными знаниями.</p> <h3>ИИ должен менять процесс</h3> <p>Когда понятно, как выполняется процесс на самом деле, возникает следующий вопрос — нужно ли автоматизировать его в существующем виде?</p> <p>Представим процесс, который проходит через пять подразделений. Один сотрудник анализирует обращение, второй проверяет документы, третий оценивает риски, четвертый готовит решение, пятый формирует ответ. Можно создать столько же ИИ-агентов и автоматизировать операции на каждом этапе.</p> <p>Работа ускорится, но сам процесс останется прежним. Между этапами сохранятся передачи, повторные проверки, согласования и ожидание. ИИ будет быстрее выполнять существующую схему вместе с действиями, которые могли появиться из-за прежнего распределения функций между людьми.</p> <p>Поэтому перед автоматизацией важно посмотреть на процесс целиком и определить, какие этапы действительно нужны для получения результата. Часть проверок можно объединить, часть передач убрать, а некоторые действия могут вообще потерять смысл. При наличии необходимых доступов и интеграций ИИ может сам собрать данные, провести стандартные проверки, подготовить результат и подключить человека там, где требуется экспертное решение или ответственность.</p> <p>В таком случае эффект дает не столько скорость выполнения отдельных операций, сколько изменение самого процесса. Сокращается количество передач, ручных действий и промежуточных этапов, которые раньше были необходимы из-за устройства работы.</p> <p>Именно здесь появляется потенциал для существенного роста производительности с учетом возможностей ИИ.</p> <h3>Управлять нужно результатом</h3> <p>Если работа строится вокруг задачи, количество агентов само по себе мало о чем говорит. Сто цифровых сотрудников не делают компанию автоматически эффективнее десяти. Иногда большое количество ролей означает лишь то, что существующую оргструктуру почти без изменений воспроизвели в ИИ-системе.</p> <p>Поэтому смотреть стоит на результат: сколько времени теперь занимает процесс, как изменилась стоимость выполнения задачи, какую часть операций система закрывает самостоятельно и где по-прежнему требуется участие человека.</p> <p>Сама оргструктура при этом остается. Она нужна, чтобы закреплять ответственность и полномочия между людьми. Но логика работы ИИ не обязана повторять эту схему: задача может проходить через систему без искусственного деления на цифровые должности и передаваться сотруднику только в тех точках, где его участие действительно необходимо.</p> <p>Для руководителя меняется и объект контроля. Важно понимать, как распределена работа между человеком и ИИ, по каким правилам действует система, где проходят границы ее самостоятельности и какой результат это дает бизнесу.</p> <p>#IMAGE_235400#</p> ИИ-агентов все чаще воспринимают как полноценных цифровых сотрудников. Это вполне логично: если система получает доступ … article Александр Бочкин, генеральный директор “Инфомаксимум” https://www.itweek.ru/themes/detail.php?ID=235404 Tue, 25 Aug 2026 18:45:56 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата проанализировал уровень использования цифровых технологий в крупных и средних организациях (без учета субъектов малого предпринимательства) в 2025 г.</p> <p>В 2025 г. цифровые технологии использовали порядка 84% крупных и средних организаций — больше, чем годом ранее.</p> <p>Базовым условием распространения цифровых технологий является доступ к интернету. Фиксированным подключением пользуются почти четыре из пяти организаций (78%), мобильным интернетом — почти две из пяти (39%).</p> <p>Информационно-коммуникационную инфраструктуру наряду с доступом к интернету характеризуют использование операционных систем с открытым исходным кодом (например, Linux) и наличие серверов. В 2025 г. такие операционные системы применяли 24% крупных и средних организаций, серверы имели 37%.</p> <p>Среди цифровых технологий наиболее востребованы цифровые платформы и облачные сервисы, за ними следуют геоинформационные системы. Каждая десятая из обследованных организаций внедрила RFID-технологии; чуть меньше — Интернет вещей и технологии сбора, обработки и анализа больших данных. Каждая двадцатая применяла технологии искусственного интеллекта для решения производственных задач. Промышленные роботы, аддитивные технологии и цифровые двойники в силу своей специфики распространены меньше — в <nobr>1–2%</nobr> крупных и средних организаций.</p> <p>Ключевым барьером для использования передовых цифровых технологий — решений для сбора, обработки и анализа больших данных, искусственного интеллекта и Интернета вещей — как и в предыдущие годы, остаются высокие затраты: их отмечает каждая вторая организация. Каждая третья указывает на отсутствие массивов данных и недостаточное развитие ИКТ-инфраструктуры; в среднем каждая четвертая — на нехватку средств для привлечения квалифицированных кадров, обладающих навыками работы с такими технологиями.</p> <p>Наряду с ресурсными ограничениями ряд организаций сообщили об отсутствии потребности в этих технологиях. Это свидетельствует о том, что темпы внедрения зависят не только от объема необходимых вложений, но и от готовности организаций пересматривать бизнес-процессы. Поэтому такие решения распространяются постепенно и прежде всего там, где дают измеримый эффект.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического … message https://www.itweek.ru/themes/detail.php?ID=235403 Tue, 25 Aug 2026 18:43:34 +0300 <p>Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если сравнивать их с зарубежными решениями того класса, с которыми российские разработчики сами сопоставляют свои LLM, российские модели по-прежнему могут стоить существенно дороже.</p> <p>Российские разработчики заметно снизили стоимость использования языковых моделей по сравнению с октябрем 2025 года.</p> <p>Наиболее сильное снижение произошло у GigaChat. Стоимость GigaChat Lite снизилась с 0,20 до 0,065 рубля за 1 тыс. токенов — на 67,5%. В линейке GigaChat Pro цена сократилась с 1,50 до 0,50 рубля — на 66,7%.</p> <p>В линейке Яндекса снижение было меньше. YandexGPT Pro стоила 1,20 рубля за 1 тыс. токенов, модель старшего поколения YandexGPT Pro 5.1 — 0,80 рубля, то есть на 33% меньше. Стоимость YandexGPT Lite не изменилась и составляет 0,20 рубля.</p> <p>В 2026 году российские разработчики также расширили линейки более доступными моделями. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за 1 тыс. генерируемых токенов. В коммерческой линейке GigaChat стоимость Lite-модели составляет 0,065 рубля за 1 тыс. токенов.</p> <p>Снижение цен можно объяснить тем, что российские разработчики постепенно сокращают прежнюю ценовую премию и приближают тарифы к мировому рынку. На это косвенно указывает стоимость доступа к одним и тем же зарубежным моделям через российские облачные платформы.</p> <p>Так, DeepSeek V4 Flash напрямую стоит 0,0375 рубля за 1 тыс. входных и 0,112 рубля за 1 тыс. генерируемых токенов. Через Yandex AI Studio — 0,30 и 0,50 рубля соответственно, то есть в 8 и 4,5 раза дороже.</p> <p>У Cloud.ru разрыв меньше: DeepSeek V4 Pro стоит напрямую 0,112 рубля за 1 тыс. входных и 0,337 рубля за выходные токены, через Cloud.ru — 0,183 и 0,732 рубля, или примерно в 1,6 и 2,2 раза дороже.</p> <p>Эти показатели не позволяют рассчитать реальную маржинальность провайдеров. Публичные тарифы не раскрывают себестоимость инфраструктуры, условия развертывания моделей и коммерческие расходы. Однако они показывают, насколько различается ценовая премия за доступ к одной и той же модели через разных поставщиков инфраструктуры.</p> <p>Снижение тарифов само по себе не означает, что российские LLM стали самыми доступными. Для оценки их ценовой конкурентоспособности российские модели сравнили не с наиболее новыми и дорогими frontier-решениями, а с зарубежными моделями, которые сами разработчики выбирали в качестве ориентиров для своих релизов.</p> <p>При запуске YandexGPT 5.1 Pro Яндекс сравнивал ее с GPT-4.1. Сейчас YandexGPT 5.1 Pro стоит 0,80 рубля за 1 тыс. входных и генерируемых токенов, тогда как GPT-4.1 — около 0,17 рубля за входные и 0,68 рубля за генерируемые.</p> <p>В результате YandexGPT 5.1 Pro обходится примерно в 4,7 раза дороже GPT-4.1 по входным токенам и примерно на 17% дороже по выходным.</p> <p>Еще заметнее разница у Alice AI LLM, которую разработчик сопоставляет с DeepSeek V3.1. Alice AI LLM стоит 0,50 рубля за 1 тыс. входных и 1,20 рубля за 1 тыс. генерируемых токенов. DeepSeek V3.1 по официальному тарифу стоила около 0,048 и 0,143 рубля соответственно. Таким образом, российская модель обходится примерно в 10,5 раза дороже по входным и в 8,4 раза — по исходным токенам.</p> <p>Alice AI LLM Flash позволяет провести еще одно такое сравнение. Яндекс сопоставляет ее с GPT-5.4 mini. Alice AI LLM Flash стоит 0,10 рубля за 1 тыс. входных и 0,20 рубля за генерируемые токены, GPT-5.4 mini — около 0,064 и 0,383 рубля соответственно.</p> <p>То есть Alice AI LLM Flash примерно в 1,6 раза дороже по входным токенам, но почти в два раза дешевле по выходным. Это показывает, что конечная экономика зависит не только от модели, но и от структуры конкретной задачи — соотношения объема входного контекста и генерации.</p> <p>Сравнение актуальных тарифов показывает, что наиболее низкую цену на мировом рынке по-прежнему в значительной степени задают китайские модели.</p> <p>DeepSeek V4 Flash стоит около 0,0375 рубля за 1 тыс. входных и 0,112 рубля за выходные токены, DeepSeek V4 Pro — 0,112 и 0,337 рубля соответственно. GLM-5 стоит 0,08 и 0,27 рубля, Qwen 3.8 Max — 0,17 и 0,511 рубля.</p> <p>В этом же нижнем ценовом диапазоне находятся европейский Mistral Large 3 — 0,04 рубля за входные и 0,13 рубля за выходные токены, а также GPT-5.4 mini — около 0,064 и 0,383 рубля.</p> <p>Из российских решений ближе всего к нижней части диапазона находятся GigaChat Lite с ценой 0,065 рубля за 1 тыс. токенов и Alice AI LLM Flash с тарифами 0,10 рубля за вход и 0,20 рубля за выход.</p> <p>Старшие российские модели стоят заметно дороже: GigaChat Pro — 0,50 рубля за 1 тыс. токенов, GigaChat 2 Max — 0,65 рубля, YandexGPT Pro 5.1 — 0,80 рубля. Alice AI LLM стоит 0,50 рубля за входные и 1,20 рубля за выходные токены.</p> <p>Высокая стоимость больше не является обязательным признаком frontier-модели.</p> <p>В верхней части диапазона остаются Claude Fable 5 с ценой около 0,80 рубля за 1 тыс. входных и 4 рубля за генерируемые токены, а также GPT-5.6 Terra — около 0,34 и 1,53 рубля соответственно.</p> <p>Однако на рынке США появляются более дешевые альтернативы сопоставимого высокого класса. Один из показательных примеров Grok с заметно более низкой стоимостью, чем у ряда решений OpenAI и Anthropic.</p> <p>Ценовое давление на наиболее дорогие LLM идет уже не только со стороны китайских разработчиков. Конкуренция усиливается и внутри американского сегмента. Новые игроки предлагают сопоставимый уровень возможностей в сложных логических задачах, программировании и агентных сценариях при более низкой стоимости инференса.</p> Стоимость российских языковых моделей за последний год снизилась до 67%, согласно исследованию Nodul. Однако если … message https://www.itweek.ru/themes/detail.php?ID=235398 Tue, 25 Aug 2026 10:15:42 +0300 <p>13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия, посвященная поиску баланса между сокращением затрат и поддержанием эффективности в крупных компаниях. Мероприятие прошло в седьмой раз подряд и было организовано системным интегратором и разработчиком ИТ‑решений DCLogic.</p> <p>В дискуссии также приняли участие ведущие эксперты ИТ‑рынка — представители ИТ‑вендоров и дистрибьюторов, а также руководители и специалисты крупного бизнеса, которые поделились практическими кейсами и отраслевыми наблюдениями. Модератором сессии выступил Сергей Козырь, генеральный директор Digital Advisers, который структурировал обсуждение и помог раскрыть ключевые аспекты темы.</p> <p>Эксперты обозначили конкретные инструменты, позволяющие enterprise‑компаниям оптимизировать ИТ‑расходы: переход на гибкие модели оплаты (включая подписочные сервисы), запуск пилотных проектов для быстрой проверки гипотез и масштабирования только доказавших эффективность решений. Особый акцент был сделан на измеримости ценности — внедрение технологий, теперь обосновывают через четкие метрики и экономический эффект, что помогает исключить нецелевые траты.</p> <p>Также выделили ключевые векторы применения ИИ в enterprise‑сегменте: компании делают ставку на интеграцию генеративного ИИ в существующие ИТ‑контуры для сокращения рутинных операций при сохранении безопасности данных, активно развивают внутренние компетенции по созданию ИИ‑агентов, чтобы снизить зависимость от дорогостоящих внешних разработок, и при этом также привязывают внедрение ИИ технологий к измеримым бизнес‑результатам.</p> <p>Важной частью дискуссии стали экспертные оценки. Сергей Козырь отметил: «С одной стороны, сегодня бизнес сталкивается с серьезными вызовами: у многих компаний наблюдается невыполнение планов. С другой — происходит сокращение бюджетов и доступных возможностей. При этом объем задач для ИТ‑подразделений не уменьшается, а зачастую даже растет — особенно в условиях оптимизации».</p> <p>Евгений Шелестюк, генеральный директор DCLogic, добавил: «За последние два месяца мы заметили резкий сдвиг в запросах клиентов. Если раньше компании стремились наращивать капитал и повышать стоимость бизнеса, то сейчас главный тренд — переход на подписочную модель, чтобы снизить единовременные затраты.</p> <p>Клиенты хотят платить меньше „в моменте“ и получать решения в формате сервиса: аренда серверов, доступ к облачным ресурсам, помесячная оплата — фактически это аналог рассрочки».</p> <p>Участники также выделили важность системного подхода: аудит ИТ‑инфраструктуры, прозрачное бюджетирование и дорожные карты позволяют выявлять избыточные процессы и выбирать оптимальные решения. Дополнительным рычагом экономии стало применение готовых интеграционных инструментов (коннекторов, типовых решений), сокращающих стоимость и сроки проектов. Отдельно эксперты рассмотрели эволюцию рисков — от классической ИБ к комплексному подходу, включающему и физическую защиту объектов, и корректную работу с данными.</p> <p>Представленные на дискуссии практики дают рынку готовые ориентиры: компании могут применять описанные механизмы для снижения издержек, ускорения окупаемости ИТ‑проектов и формирования устойчивой стратегии развития. Такой подход позволяет не просто сокращать бюджет, а перераспределять ресурсы на наиболее результативные направления, сохраняя конкурентоспособность в меняющихся условиях.</p> 13 августа 2026 года в рамках деловой программы бизнес‑регаты IT SAILING DAY 2026 состоялась панельная дискуссия … message https://www.itweek.ru/themes/detail.php?ID=235396 Tue, 25 Aug 2026 09:20:24 +0300 <p><em>Угроза «SaaS-апокалипсиса» упускает из виду более широкую картину. Хотя большинство комментариев сосредоточены на снижении доходов от модели, основанной на использовании рабочих мест (прогнозируя, что агенты искусственного интеллекта положат конец лицензиям на ПО), это лишь один из девяти критически важных факторов, способствующих кардинальным изменениям, пишут в корпоративном блоге вице-президенты и главные аналитики </em><em>Forrester</em> <em>Крейг Ле Клер и Тед Шадлер.</em></p> <p>Будучи глобальной исследовательской компанией, оценивающей весь технологический ландшафт, Forrester создала AI Disruption Model — модель анализа влияния ИИ на основе данных. Эта модель, построенная на исследованиях Forrester и общедоступной информации, отсеивает лишнюю информацию, обеспечивая прозрачность рыночных изменений и всеобъемлющую основу для прогнозирования будущего.</p> <p>Forrester AI Disruption Model оценивает 17 категорий технологий и услуг, охватывающих более 200 рынков. Данная модель анализирует структурную динамику рынка по девяти ключевым факторам, включая взаимозаменяемость ИИ, трудоемкость, коммерческую модель, поддержку агентных рабочих нагрузок, затраты на переход и регуляторные барьеры. Главный вывод очевиден: влияние ИИ не будет распределено равномерно. В то время как некоторые рынки и поставщики сталкиваются с серьезными трудностями, другие готовы к историческому ускорению.</p> <p> #IMAGE_235397#</p> <p>Мы разделили рынки на четыре категории: подверженные дестабилизации (disrupted), нейтрально реагирующие (neutral), подверженные балансу факторов (contested) и обеспечивающие ускорение (accelerated):</p> <ul> <li> Рынки, подверженные дестабилизации — здесь ИИ воспроизводит свою основную ценность. Если ИИ может сделать что-то, что может сделать человек или существующий программный продукт, он это сделает. Поставщики и сервис-провайдеры в этой категории сталкиваются с ценовым давлением, сокращением рабочих мест и коммодитизацией своих основных возможностей или наборов функций. Наиболее серьезно дестабилизирующие факторы, связанные с ИИ, затрагивают трудоемкие сегменты, такие как внедрение технологий, разработка ПО на заказ, креативные услуги и корпоративное обучение. Эти рынки находятся под огромным давлением, поскольку ИИ берет на себя функции, ранее выполнявшиеся экспертами-людьми.</li> <li> Нейтрально реагирующие рынки — здесь ценность не является преимущественно информационной. Если поставщики и сервис-провайдеры предлагают физические возможности, ориентированные на регулируемые рынки или защищенные высокими затратами на смену поставщика, они менее подвержены влиянию перехода на ИИ. Эти факторы сдерживают прогресс ИИ и обеспечивают стабильность ценности.</li> <li> Рынки, подверженные балансу факторов — готовые к ускоренному развитию. Поставщики и сервис-провадеры на таких рынках видят баланс обеспечивающих нейтральное реагирование и ускорение факторов, позволяющий перейти к ускоренному развитию. Они не будут сидеть сложа руки и ждать, пока их вытеснят, а перенаправят инвестиционный капитал и НИОКР на поддержку агентных рабочих нагрузок, данных, доверия и суверенитета. Поставщики в этой категории могут позитивно внедрять ИИ в свои платформы, но сталкиваются с проблемами реализации, капитала и трудовых ресурсов.</li> <li> Рынки, обеспечивающие ускорение — здесь продают все, что требуется для работы с ИИ. Поставщики инфраструктуры, данных, моделей, интеграции или возможностей обеспечения доверия являются основой агентных рабочих процессов — и будущими опорами бизнеса, основанного на ИИ. Спрос на их предложения напрямую зависит от уровня внедрения ИИ: чем больше специализированных ИИ-агентов и целевых агентных систем развертывают предприятия, тем больше технологий продают эти поставщики.</li> </ul> <p>Задача для покупателей корпоративных технологий, поставщиков и сервисных компаний — понять, как ИИ меняет рынки. Независимо от того, являетесь ли вы покупателем, стремящимся оптимизировать свой технологический портфель, или поставщиком, защищающим свою долю рынка и будущее, Forrester AI Disruption Model предлагает схему, необходимую для понимания этого сдвига.</p> <p>Покупатели корпоративных технологий могут использовать эту модель с целью защиты инвестиций при закупках, изолируя устаревшие, обремененные долгами инструменты, чтобы направить инвестиции масштабируемым, готовым к использованию агентных систем поставщикам. Для поставщиков технологий и сервис-провайдеров модель предлагает действенную дорожную карту, позволяющую оценить риски, защитить основной доход и переориентироваться на долгосрочный рост, прежде чем устаревшие модели исчерпают себя.</p> Угроза «SaaS-апокалипсиса» упускает из виду более широкую картину. Хотя большинство комментариев сосредоточены … article https://www.itweek.ru/themes/detail.php?ID=235394 Tue, 25 Aug 2026 09:06:47 +0300 <p>Скорость работы за последний год выросла у всех, кто подключил к процессам ИИ-инструменты. Вместе со скоростью выросла и вероятность того, что ошибка уйдет в производство незамеченной: проверять результат стало некогда, а иногда некому.</p> <p>Рассмотрим, как бизнесу выстроить систему верификации и почему ответственность за решение остается на человеке при любой степени автоматизации.</p> <h3>60% компаний работают с нейросетями без регламента</h3> <p>Требование повышать эффективность сегодня стоит перед большинством компаний, и ИИ-инструменты выглядят самым доступным способом это требование выполнить. Там, где раньше задача занимала день, после подключения нейросети уходит несколько часов. Поэтому внедрение идет в десятки процессов одновременно, при этом, часто без предварительной перестройки процессов.</p> <p>Побочный эффект такого темпа уже заметен. Проверка результата занимает время, которое как раз и хотели сэкономить, поэтому часть шагов начинает выпадать: цифры не сверяются с источником, формулировки принимаются в том виде, в каком их выдала модель, спорные места дорабатываются реже. Углы срезаются постепенно и почти незаметно для самой команды.</p> <p>Безопаснее всего ускоряться там, где ошибка обходится сравнительно дешево. Такой подход сохраняет выигрыш в скорости и снимает основной риск, поэтому имеет смысл закрепить его как процедуру. Пока что такая процедура есть у меньшинства: около 60% организаций <a href="https://pohodu.media/tenevoj-ii-kak-bezopasno-rabotat-s-nejrosetjami-v-kompanii/">не имеют</a> формализованных правил работы с нейросетями, при том что 26% сотрудников используют их регулярно и еще 35% периодически. Сотрудник в такой ситуации сам решает, какой сервис выбрать, какие данные туда отправить и насколько тщательно нужно проверять ответ.</p> <p>Отсутствие правил само по себе не создает проблему, пока результат работы модели остается корректным. Но когда модель ошибается, а ошибка выглядит достоверно и уходит дальше по цепочке без проверки, бизнес сталкивается с серьезными рисками. Именно такие случаи сейчас доходят до публичных разбирательств и показывают, во что обходится компании непроверенный ответ.</p> <h3>Модель выдумывает ссылки, компания платит штраф</h3> <p>Ярче всего проблема ИИ-галлюцинаций проявилась в юридической сфере. Причина в том, что каждая ссылка в документе проверяется второй стороной и судом, поэтому выдуманная норма обнаруживается почти всегда. Модель выдает ее с точной формулировкой и номером дела, но при проверке выясняется, что документа не существует.</p> <p>В базе таких случаев к июлю 2026 года <a href="https://www.kommersant.ru/doc/8799829">накопилось</a> 1725 дел из 35 стран с 5169 некорректными ссылками. История дошла и до российских судов: весной 2026 года арбитражный суд <a href="https://ziam.moscow/publikatsii/sud-oshtrafoval-kompaniyu-za-ispolzovanie-ii-pri-podgotovke-kassatsionnoy-zhaloby/">оштрафовал</a> компанию на 50 тысяч рублей за ссылки на несуществующую судебную практику, квалифицировав это как обман суда.</p> <p>Принципиальная деталь этого решения касается любого бизнеса. Суд не выяснял, придумал ссылки человек или модель, поскольку ответственность за поданный документ несет тот, кто его подписал. Инструмент, с помощью которого документ готовился, на распределение ответственности не влияет.</p> <p>В работе с нейросетями важно помнить, что модель подстраивается под задачу пользователя и стремится дать ответ, который выглядит подходящим, поэтому недостающие детали достраиваются правдоподобно. Скорость развития моделей на эту особенность влияет слабо: случаи с выдуманными ссылками продолжают накапливаться быстрее, чем годом раньше. Проверка результата поэтому переходит из разряда желательных процедур в обязательные.</p> <h3>Ответственность нельзя разделить с инструментом</h3> <p>Подпись под решением всегда ставит человек, и это единственная точка, где ответственность фиксируется юридически. Вина при разборе распределяется между сотрудником, который принес решение, и руководителем, который его согласовал. Модель в этой схеме места не занимает ни при каком раскладе.</p> <p>По этой причине, если специалист согласовал решение, не разобравшись в предметной области, проблема лежит исключительно в его экспертизе. Ответственность за результат остается ровно там же, где была до появления нейросетей, поэтому требования к пониманию сути задачи растут вместе со скоростью ее выполнения.</p> <h3>Как посчитать цену ошибки в своей компании</h3> <p>Почти ни у одной компании сейчас нет понимания, во сколько ей обходится конкретная ошибка. Однако ее стоит посчитать в потраченных часах, деньгах, потерянных клиентах и репутационных издержках, чтобы оценивать риски трезво. Так, три дня неудачного эксперимента укладываются в допустимую потерю, поскольку компания теряет только время команды, а ошибка в клиентских данных, в расчете себестоимости или в юридическом документе стоит несопоставимо дороже.</p> <p>Шкала собирается из трех шагов. Сначала все процессы раскладываются по уровню критичности, от свободных экспериментов до задач, где ошибка стоит компании контракта. Затем на каждый уровень назначается лимит эксперимента в днях и деньгах, а для самых критичных задач вводится обязательная проверка вторым человеком. Отдельным списком фиксируются задачи, результат которых вообще не принимается без ревью.</p> <p>Такая шкала позволяет компании ускоряться с пониманием всей ответственности. Там, где ошибка обходится дешево, команда может работать на полной скорости и учиться на неудачных попытках. Там, где ошибка стоит дорого, часть скорости сознательно отдается за контроль, причем решение об этом принимается заранее и не зависит от загрузки конкретного дня.</p> <h3>К работе руководителя добавилась проверка результата</h3> <p>Раньше от руководителя требовались экспертиза и накопленный опыт. Теперь к ним добавилась обязательная верификация того, что принес сотрудник вместе с инструментом. Задача эта постоянная, поскольку объем проходящих через руководителя решений вырос вместе с общей скоростью работы.</p> <p>Чтобы проверять, руководитель обязан понимать принцип работы модели и знать конкретные места, где она может допустить ошибку: выдуманные ссылки и цитаты, подгонка ответа под ожидание, потеря контекста в длинных задачах. Рядовому сотруднику допустимо этого не знать, но руководителю такой пробел непозволителен, поскольку именно он ставит подпись.</p> <p>По уровням это разворачивается в понятную схему. Линейный менеджер отвечает за верификацию на своем участке, руководитель департамента — за корректность процессов внутри направления, топ-менеджмент определяет зоны, где риск неприемлем, на уровне всей компании.</p> <h3>С чего начать внедрение нейросетей в бизнес-процессы</h3> <p>Все перечисленное сводится к нескольким процедурам, которые компания способна завести своими силами за месяц. Порядок здесь имеет значение: сначала описывается организационная часть процессов, потому что без нее непонятно, что и с какой тщательностью проверять, и затем детализируется техническая.</p> <p><strong>Организационная часть:</strong></p> <ul> <li> Разложить процессы по уровню критичности и зафиксировать, во сколько компании обходится ошибка на каждом из них.</li> <li> Назначить ответственного за проверку на каждом уровне, от линейного руководителя до топ-менеджмента.</li> <li> Ввести правило обязательной проверки фактов, цифр и ссылок в документах, которые уходят за пределы компании.</li> <li> Установить лимит эксперимента в днях и деньгах для задач с низкой критичностью.</li> <li> Составить список задач, результат которых не принимается без проверки человеком.</li> </ul> <p><strong>Техническая часть:</strong></p> <ul> <li> Собрать базу скиллов, тулов и плагинов с правилами работы ИИ-агента для разных этапов процесса. Каждый этап работы получает свой набор инструкций, который определяет, на какие данные агент опирается, какой результат считается корректным и какие действия недопустимы.</li> <li> Настроить процесс ревью, при котором решения, выданные агентом, проверяет другой агент.</li> <li> Запустить рефлексию по итогам ревью: агент разбирает собственные ошибки и определяет, на каком шаге и почему инструкция сработала неверно.</li> <li> Скорректировать работу агента по результатам ревью, чтобы та же ошибка не воспроизводилась на следующих задачах.</li> </ul> <p>Разумеется, скорость работы остается конкурентным преимуществом, и компании, которые откажутся от нее из осторожности, проиграют тем, кто научился работать быстро. Смысл шкалы критичности в том, что она показывает, где можно двигаться на полной скорости без оглядки и где стоит потратить лишний час на проверку. Без такой разметки команда либо тормозит везде одинаково, либо везде одинаково рискует.</p> <p>Технология при этом развивается быстрее, чем компании успевают выстраивать вокруг нее процессы. Верификация становится постоянной частью работы руководителя, благодаря которой ускорение всех процессов возможно. Компании, которые отстраивают эти процессы, получают возможность внедрять новые инструменты без пауз и рисков, которые несут незамеченные ошибки.</p> <p>#IMAGE_235395#</p> Скорость работы за последний год выросла у всех, кто подключил к процессам ИИ-инструменты. Вместе … article Олег Строкатый, руководитель направления контроля качества ”Битрикс24” https://www.itweek.ru/themes/detail.php?ID=235393 Mon, 24 Aug 2026 17:07:41 +0300 <p>По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО среди значимых облачных инцидентов выросла на 15 процентных пунктов — с 10% до 25%. За полгода доля выросла в 2,5 раза, при этом абсолютное число значимых инцидентов, связанных с цепочками поставок, более чем удвоилось.</p> <p>Рост связан с тем, что современная разработка опирается на большое число внешних компонентов и автоматизированных процессов, которым компания вынуждена доверять. Даже относительно небольшой корпоративный продукт зависит от внешних библиотек, пакетов, расширений среды разработки, систем сборки и репозиториев. Каждый такой компонент связан с учетными записями сопровождающих, токенами доступа и автоматизированными процессами публикации. Компрометация одного аккаунта сопровождающего, токена публикации или элемента CI/CD может дать злоумышленнику штатный канал доставки вредоносного кода в корпоративную сборку. Вредоносный пакет устанавливается штатным менеджером зависимостей, измененный компонент попадает в сборку, а похищенный токен используется в легитимном CI/CD-процессе. Для средств сетевого контроля установка пакета, обращение CI/CD к репозиторию или публикация артефакта часто выглядят как обычная работа команды разработки.</p> <p>В первой половине 2026 года подобные кампании затрагивали сразу несколько экосистем, включая npm, PyPI, Composer, расширения Visual Studio Code, плагины Jenkins и AUR. В одном из эпизодов компрометация единственной учетной записи разработчика позволила внедрить вредоносные изменения более чем в 140 пакетов. В других случаях атакующие получали контроль над аккаунтами сопровождающих и публиковали измененные версии сразу сотен компонентов. Масштаб такой операции зависит от числа организаций, которые автоматически получают обновления скомпрометированного проекта через привычный процесс установки зависимостей.</p> <p>Отдельную роль играет кража секретов разработчиков. Вредоносный пакет может использоваться как средство первоначального доступа, после чего атакующие извлекают персональные токены GitHub, ключи облачных платформ, учетные данные реестров пакетов или переменные окружения из систем сборки. Эти данные могут открыть доступ к следующему уровню инфраструктуры: приватным репозиториям, облачным ресурсам, контейнерным реестрам или системам сборки. В исследованных кампаниях украденные токены применялись повторно через несколько недель после первоначальной компрометации, причем часть такой активности, по оценкам исследователей, могла относиться уже к другим группам. В одном из эпизодов злоумышленники заявляли о доступе примерно к четырем тысячам частных репозиториев. Такой сценарий требует не только удалить вредоносный пакет, но и отозвать или заменить учетные данные, которые могли быть похищены во время его выполнения.</p> <p>Структура атак через цепочки поставок в 2026 году складывается из нескольких связанных сценариев. Первый строится вокруг компрометации открытого пакета или аккаунта его сопровождающего. Второй затрагивает CI/CD и позволяет менять сборки, кэши либо workflow без прямого доступа к конечному приложению. Еще один распространенный путь проходит через учетные данные разработчиков, когда первоначальное заражение используется для перехода в облачную инфраструктуру или внутренние репозитории. Отдельно развиваются атаки через плагины и расширения инструментов разработки. Такие инструменты особенно ценны для злоумышленника, если они имеют доступ к секретам, сборке или корпоративным сервисам. Расширение IDE работает внутри среды, где разработчик уже авторизован в корпоративных сервисах, а Jenkins-плагин или компонент сборочного конвейера может взаимодействовать с инфраструктурой от имени сервисной учетной записи.</p> <p>В результате граница между компрометацией поставщика и атакой на конечную компанию становится менее очевидной. Организация может не иметь уязвимого публичного сервиса и при этом получить вредоносный код через обновление зависимости. Другой сценарий начинается за пределами ее инфраструктуры, когда атакующий похищает токен сотрудника у разработчика стороннего продукта, а затем использует этот доступ уже против облачных ресурсов клиента. Для бизнеса последствия такого проникновения выходят за рамки заражения отдельной рабочей станции. При наличии широких прав у сервисных аккаунтов атакующий получает возможность читать секреты, менять содержимое репозиториев, воздействовать на процессы сборки и переходить к другим облачным проектам.</p> <p>При оценке отраслевого распределения инцидентов, связанных с цепочками поставок, наиболее высокая доля приходится на технологические компании и разработчиков ПО — около 34% случаев. Финансовый сектор формирует еще 21%, интернет-ритейл и другие цифровые торговые площадки — 16%, промышленность — 14%, компании из сферы профессиональных и корпоративных услуг — около 9%. На остальные отрасли приходится порядка 6%. Такая структура связана прежде всего с интенсивностью использования сторонних компонентов. У технологических компаний больше открытых зависимостей, репозиториев и автоматизированных сборочных процессов, финансовые организации активно используют внешние программные продукты и интеграции, а в ритейле и промышленности риск дополнительно расширяют многочисленные подрядчики, облачные сервисы и специализированное ПО. В этих условиях компрометация одного поставщика может затронуть сразу несколько организаций, которые используют общий пакет, плагин или компонент сборочной инфраструктуры.</p> <p>Риск усиливается, когда управление зависимостями отделено от управления доступом и секретами. Команда может проверять уязвимости библиотек, но не отслеживать, кому разрешена их публикация и какие права имеет CI/CD после установки нового компонента. В другой организации защищен репозиторий исходного кода, однако сервисный токен сборочной системы имеет административные полномочия в облаке. Именно через такие связи атака выходит за пределы исходной точки: один похищенный секрет может дать доступ к следующему сервису, а затем — к другим учетным данным и системам. Один похищенный секрет превращается в доступ к следующему сервису, а оттуда к другим учетным данным и системам.</p> <p>Для снижения риска компаниям следует контролировать всю цепочку доверия от исходного кода и зависимостей до CI/CD и развертывания в продуктивной среде. Новые зависимости имеет смысл проверять до включения в сборку, а недавно опубликованные версии не устанавливать автоматически без дополнительной верификации. Для критичных проектов оправдан период задержки перед использованием новой версии пакета, поскольку часть вредоносных публикаций удаляется вскоре после обнаружения. Доступ CI/CD следует ограничивать минимально необходимыми действиями, долгоживущие токены заменять короткоживущими учетными данными, а секреты разработчиков регулярно проверять на утечки и аномальное применение. Отдельного контроля требуют изменения владельцев пакетов, публикация новых версий, отключение защиты веток и действия сервисных аккаунтов за пределами обычного профиля.</p> <p>Практический приоритет — ограничить последствия компрометации одного элемента цепочки. Организация должна исходить из того, что популярная зависимость, аккаунт сопровождающего или токен разработчика могут быть скомпрометированы, и заранее ограничивать их возможности. Чем меньше полномочий получает такой компонент после попадания внутрь процесса разработки, тем ниже вероятность того, что одна вредоносная публикация даст атакующему доступ сразу к репозиториям, облачным ресурсам и корпоративным данным.</p> По оценке специалистов компании «Информзащита», в первом полугодии 2026 года доля атак через цепочки поставок ПО … message https://www.itweek.ru/themes/detail.php?ID=235392 Mon, 24 Aug 2026 17:02:39 +0300 <p>Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для корпоративной инфраструктуры. Ключевыми направлениями развития релиза стали разграничения прав доступа администраторов, совместимость со SpaceVM 7, а также совершенствование инструментов администрирования, поддержки многоуровневой PKI и сценариев управления <nobr>VDI-средой.</nobr></p> <p>В состав релиза вошли Space Dispatcher 6.2.0, Space Gateway 1.8.1, Space Client 3.8.1 для Linux и Space Client 3.8.2 для Windows. Space VDI 6.2.0 совместима с платформами виртуализации SpaceVM 6.5.9 и SpaceVM 7.0.2.</p> <p>В Space VDI 6.2.0 реализована балансировка пользовательских подключений в мультишлюзе Space Gateway. Решение позволяет объединить несколько шлюзов в единый контур удалённого доступа и распределять нагрузку между ними при подключении пользователей.</p> <p>Мультишлюз Space Gateway предназначен для инфраструктур с большим числом удалённых пользователей. Балансировка подключений между шлюзами помогает масштабировать контур удалённого доступа и эффективнее использовать вычислительные и сетевые ресурсы.</p> <p>Space Dispatcher — управляющий компонент платформы получил существенное развитие в новом релизе Space VDI. В версии 6.2.0 реализована поддержка многоуровневой инфраструктуры открытых ключей, а инструменты работы с сертификатами получили дальнейшее развитие в интерфейсе и административных сценариях платформы. Это расширяет возможности интеграции Space VDI с корпоративной PKI и делает управление сертификатами более удобным в рамках единого контура администрирования.</p> <p>В новой версии также добавлены инструменты для разграничения прав доступа администраторов для управления на уровне пулов с помощью пользовательской роли «Модератор», развиты механизмы обновления компонентов, расширены административные сценарии и усовершенствована работа со службами каталогов, событиями и параметрами безопасности. В совокупности эти изменения повышают гибкость управления средой виртуальных рабочих мест и делают эксплуатацию платформы более предсказуемой в инфраструктурах с высокими требованиями к надёжности и управляемости.</p> <p>Отдельное внимание в релизе уделено развитию сценариев предоставления корпоративных приложений. В документации Space VDI появился новый раздел с рекомендациями по работе с пулами приложений, которые позволяют предоставлять пользователям доступ к отдельным приложениям без развёртывания полноценного виртуального рабочего стола. Такой подход помогает точнее настраивать пользовательские сценарии и более гибко организовывать доступ к прикладным системам.</p> <p>«Space VDI изначально создавалась как отечественная платформа с собственной технологической базой и глубокой интеграцией компонентов экосистемы Space. Такой подход позволяет нам обеспечивать предсказуемое развитие продукта, стабильную совместимость между компонентами и долгосрочную поддержку заказчиков в проектах импортозамещения. Мы видим высокий спрос на VDI со стороны коммерческих компаний и государственных организаций, поэтому продолжаем последовательно развивать инструменты администрирования и безопасности платформы. Новые возможности Space VDI 6.2.0 помогают заказчикам проще масштабировать инфраструктуру виртуальных рабочих мест, сохраняя высокий уровень управляемости среды и удобство её эксплуатации», — отметил Руслан Белов, директор по продукту Space VDI компании «ДАКОМ М». </p> <p>Для заказчиков в открытой документации продукта подготовлены рекомендации по обновлению и миграции компонентов Space Dispatcher с учетом особенностей используемой инфраструктуры. При переходе на Space VDI 6.2.0 необходимо соблюдать матрицу совместимости компонентов экосистемы Space и выполнять обновление в рекомендованной последовательности.</p> Компания «ДАКОМ М» (бренд Space) выпустила Space VDI 6.2.0 — новую версию платформы виртуальных рабочих мест для … message https://www.itweek.ru/themes/detail.php?ID=235391 Mon, 24 Aug 2026 16:53:15 +0300 <p>Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет искать ответы в корпоративных документах, а также выполнять аналитические задачи. Платформа рассчитана в первую очередь на крупные и средние компании с повышенными требованиями к информационной безопасности и суверенитету данных.</p> <p>В крупных компаниях информация, необходимая для принятия решений, как правило распределена между разными источниками. Документы и регламенты хранятся в корпоративных порталах и СЭД, данные о клиентах — в CRM, финансовые показатели — в учетных системах, а часть информации остается в файлах и у отдельных экспертов. </p> <p>Чтобы получить аргументированный ответ на вопрос, сотрудникам приходится тратить время на длительный поиск, переключаться между системами, вручную сводить данные из разных систем. NaviCortex объединяет корпоративные источники в единое рабочее пространство и позволяет взаимодействовать с ними в едином интерфейсе.</p> <p>В отличие от классических систем интеллектуального поиска, которые работают по схеме «запрос — поиск по документам — ответ», новое решение «Навикон» построено на агентной архитектуре. Получив задачу, ИИ-агент самостоятельно разбивает ее на этапы, определяет необходимые источники, обращается к корпоративным системам, выполняет расчеты и проверяет результат. При сложных запросах отдельные части задачи могут передаваться специализированным агентам, а дополнительная проверка позволяет сверять числа, периоды и другие необходимые данные. </p> <p>Например, на вопрос о текущей задолженности клиента и возможности продолжать отгрузки платформа может одновременно получить сумму задолженности из ERP, проверить финансовую политику компании в базе знаний и уточнить статус клиента в CRM. В результате пользователь получает единый ответ, а не набор ссылок на три разные системы. По тому же принципу платформа сопоставляет показатели из разрозненных источников, готовит аналитические справки, проверяет требования регламентов или собирает информацию для управленческой отчетности.</p> <p>Платформа не только находит информацию и отвечает на вопросы, но и выполняет работу по запросу пользователя. Агент пишет и запускает код в изолированной песочнице, рассчитывает показатели, строит таблицы и графики — а результат формирует в виде готового документа, таблицы или презентации. Для загрузки собственных файлов и дальнейшей работы с ними пользователям доступно персональное защищенное пространство.</p> <p>NaviCortex можно интегрировать с ERP, CRM, WMS, СЭД, корпоративными порталами, базами данных и другими системами через API. Заказчики, в свою очередь, могут специализированных агентов для отдельных сотрудников, подразделений и сценариев без переработки всей системы.</p> <p>Отдельное внимание разрабочик уделил вопросам корпоративной безопасности. Платформа учитывает права конкретного пользователя при обращении к документам и информационным системам, контролирует входящие запросы и ответы, фиксирует действия в журнале аудита и изолирует пользовательские песочницы. Решение может быть развернуто внутри закрытого контура компании, работать по гибридной модели или размещаться в облаке российского провайдера. При локальном развертывании данные и генерацию ответов можно оставить в инфраструктуре заказчика.</p> <p>«Сейчас корпоративный ИИ часто сводится к чат-боту, который умеет искать информацию в базе документов. Но реальные вопросы бизнеса устроены сложнее: для ответа нужно взять данные из нескольких систем, сопоставить их с внутренними правилами, что-то рассчитать, проверить результат, а иногда — сразу подготовить документ. Именно под такие задачи мы создавали NaviCortex. Наша цель — дать сотруднику ИИ-инструмент, который понимает контекст бизнеса компании и способен самостоятельно пройти путь от вопроса до готового результата», — прокомментировал Илья Народицкий, директор по стратегическим инновациям компании «Навикон».</p> <p>Продукт оптимизирован для работы на русском языке и поддерживает модели с открытым исходным кодом, которые можно размещать в инфраструктуре заказчика. Клиент получает доступ к исходному коду платформы и может развивать и кастомизировать решение самостоятельно или с поддержкой «Навикон». </p> <p>Платформа подойдет компаниям с большим объемом внутренней информации и разветвленным ИТ-ландшафтом. В частности, организациям из регулируемых сфер — финсектора, фармацевтики, пищевой промышленности и ритейла.</p> Системный интегратор и разработчик «Навикон» вывел на рынок агентную ИИ-платформу NaviCortex. ИТ-решение позволяет … message https://www.itweek.ru/themes/detail.php?ID=235390 Mon, 24 Aug 2026 09:48:45 +0300 <p><em>Инструменты кодирования с использованием искусственного интеллекта ускоряют работу отдельных специалистов, но большие запросы на слияние (pull requests, </em><em>PR</em><em>), слабые методы измерения и устаревшие процессы сдерживают производительность и уверенность инженеров, отмечают опрошенные порталом </em><em>The</em> <em>New</em> <em>Stack</em> <em>эксперты.</em></p> <p>ИИ отлично справляется с тем, чтобы ускорить работу отдельных людей, но окружающие системы затем снова всё замедляют. Этот результат — или, скорее, его отсутствие — усиливается размером компании и размером PR. До такой степени, что, хотя инвестиции в ИИ в большинстве компаний увеличились в 28 раз, показатели скорости разработки остаются на прежнем уровне и даже снижаются. Таковы результаты недавно опубликованного исследования DX «State of AI Impact in Engineering», в котором оцениваются инженерные организации по таким параметрам, как скорость, эффективность, качество и влияние.</p> <p>«Это вызывает беспокойство, потому что, когда затраты выросли в 28 раз — и стали буквально единственным экспоненциально выросшим показателем — а скорость не растет экспоненциально, мы не выпускаем экспоненциально больше ПО», — сетует Джастин Реок, заместитель технического директора DX.</p> <p>В то время как расходы на ИИ продолжают стремительно расти, коэффициент инноваций — соотношение усилий инженеров, затрачиваемых на разработку новых функций, с затратами на техническое обслуживание, рутинную работу и операционные издержки — остается неизменным. Это означает, что, согласно отчету DX, ИИ не освобождает время инженеров для разработки интересных бизнес-решений.</p> <p>Почему же индустрия тратит так много денег на агентные и ​​ИИ-инструменты для разработчиков, одновременно проводя сокращения штата, и все это безрезультатно?</p> <h3>Имеет ли место тенденция к ухудшению опыта разработчиков?</h3> <p>«Возможно, мы все еще находимся в переломном моменте, когда большая часть сэкономленного времени по-прежнему тратится на технический долг, на задачи из бэклога, которые не обязательно помечены как новые функции», — говорит Реок, который все еще надеется, что разрыв между затратами и выгодами от ИИ — это всего лишь проблемы роста. «Но с точки зрения опыта разработчиков меня также беспокоит выявленное в отчете конкретное противоречие между поддерживаемостью кода и уверенностью в изменениях», — добавляет он.</p> <p>Эти два фактора составляют основу индекса опыта разработчиков (Developer Experience Index, DXI):</p> <ul> <li><strong> Поддерживаемость кода:</strong> я чувствую себя комфортно, внося изменения в код; я понимаю код, который передо мной.</li> <li><strong> Уверенность в изменениях:</strong> я уверен, что, выпустив код в продакшн, я ничего не сломаю.</li> </ul> <p>Традиционно, как объясняет Реок, поддерживаемость кода и уверенность в изменениях положительно коррелируют, поскольку первая делает инженеров более уверенными в выпуске кода в продакшн. «ИИ упрощает понимание того, что перед вами, и даже внесение в это изменений. Но уверенность в изменениях сейчас находится в отрицательной зоне, — говорит он. — Мы стали больше бояться выпускать код. Мы можем легче понимать, поддерживать, просматривать код и вносить в него изменения. Но мы меньше доверяем тому, что выпускаем».</p> <p>Это обходится еще дороже. По словам Реока, за каждый пункт улучшения DXI приходится платить десятью часами работы каждого инженера в год. Это впервые, когда в масштабах всей отрасли наблюдается снижение этого показателя на два пункта.</p> <h3>Является ли ИИ неподходящим инструментом для крупных организаций?</h3> <p>Как показывает исследование DX, небольшие организации тратят больше средств на ИИ и получают от него больше пользы, в то время как традиционные софтверные компании с трудом получают какую-либо отдачу от инвестиций.</p> <p>Мартин Дэвидсон, технический директор микроконсалтинговой компании a2bic.ai, и его соучредитель, обладающие в общей сложности <nobr>80-летним</nobr> опытом, доводят ситуацию до крайности: они могут управлять командами ИИ-агентов, выполняющих работу 100 инженеров начального и среднего уровня. «Небольшим организациям не приходится платить издержки нелинейной координации и коммуникации, которые увеличиваются с ростом размера организации. Вспомните мифический человеко-месяц: каналы связи растут как n(n−1)/2, поэтому у команды из 10 человек 45 каналов накладных расходов, — объясняет Дэвидсон. — Трое из этих людей фактически нужны только для согласования действий. Но как только остаётся один или два человека, затраты на коммуникации исчезают. По мере сокращения среднего звена управления отпадает необходимость в ежемесячных общих собраниях на всех уровнях организации».</p> <p>По его словам, в средних и крупных организациях пытаются внедрить — или «впихнуть» — ИИ в существующие системы, охватывающие людей, процессы и технологии. Но ИИ — это фундаментальный технологический и операционный сдвиг парадигмы. Это то, что он называет проблемой обновления, когда некоторые из этих структур больше не соответствуют своему назначению.</p> <p>«Это нельзя переделать. У нас есть процессы и структуры, которые были разработаны, когда написание кода было дорогостоящим делом. Сейчас это уже не так — написание кода по сути бесплатно, но мы всё ещё цепляемся за старые структуры. А они недешевы, — продолжает Дэвидсон. — Структуры компании похожи на здания — в какой-то момент вы понимаете, что они больше не соответствуют своему назначению, и их нужно снести и выстроить заново».</p> <p>Конечно, это не новая проблема. Это та же самая логика, которая удерживала подавляющее большинство предприятий от полного перехода в облако.</p> <p>«Возможно, победителями станут не те компании, которые успешно трансформируются. Возможно, победителями станут те, кто начнет все с чистого листа, без каких-либо ограничений. Это трудно сделать, если вы работаете в устаревшей организации. И, вероятно, еще более трудно, если вы ею управляете», — отмечает Дэвисон.</p> <p>К счастью, ИИ очень хорошо распознает закономерности, что делает его очень полезным для разгадывания тайн унаследованных систем, их миграции в облако и переписывания.</p> <h3>ИИ усугубляет разрастание кода</h3> <p>Конечно, многие команды и их промпты игнорируют общепринятые шаблоны достижения успеха, в том числе тот факт, что уменьшение размера пакета способствует более стабильным релизам. В отчете DX говорится, что в июле 2025 г. средний размер PR составлял 42 строки кода, а годом позже — 72 строки.</p> <p>Кроме того, из всех показателей DXI, измеренных за последний квартал, больше всего пострадал показатель поэтапной разработки — когда инженеры работают над небольшими, поэтапными изменениями. «Такая разработка дает множество преимуществ в дальнейшем: откат изменений, меньше проверок, более понятная документация, улучшенные модульные тесты и так далее», — отмечает Реок.</p> <p>Не только DX выявляет эти тревожные тенденции. В новом отчете LinearB о разрыве в производительности ИИ-разработки 253 организации ранжированы по использованию ИИ на четыре категории. Исследование показывает, что меньший размер PR напрямую связан с более успешным внедрением ИИ. У «элитных организаций», входящих в 10% лучших, средний размер PR — менее 100 строк кода, в то время как у организаций из нижней части списка — им «недостает фокуса» — PR составляют более 228 строк кода.</p> <h3>Можно ли улучшить то, что не измеряется?</h3> <p>Исследования DX и LinearB по измерению количественного и качественного опыта разработчиков основаны на собственных данных, полученных от организаций, использующих их продукты, поэтому ни один из этих результатов не отражает полной картины. На самом деле, ситуация в остальной части отрасли может быть гораздо хуже.</p> <p>Согласно отчету LeadDev «AI Impact Report 2026», только 31% опрошенных команд вообще измеряют влияние ИИ. Исследователи определили эти измерения следующим образом:</p> <ul> <li> реальное повышение производительности;</li> <li> риск безопасности;</li> <li> сохранение основных инженерных навыков;</li> <li> управление агентным ИИ;</li> <li> реструктуризация команды;</li> <li> наем и обучение младших специалистов.</li> </ul> <p>Среди организаций, которые фактически начали внедрять инструменты для разработчиков на основе ИИ, согласно отчету LeadDev, 70% теперь описывают себя как внедрившие их «широко или полностью», и только 26% сообщают, что ИИ повысил производительность инженеров более чем на 25%. Эти 26%, как уточняет Майкл Хилл, управляющий редактор LeadDev и автор отчета, включают в себя респондентов, полагающихся на интуицию, а не только на подтвержденные данные.</p> <p>«Оптимизм в отношении производительности (26% отмечают значительный рост) и разрыв в измерениях (только 31% фактически отслеживает его) — это два отдельных результата, полученные на основе ответов на два разных вопроса», — отмечает он, а это значит, что «большинство людей, сообщающих о росте, не могут это доказать».</p> <p>Как известно, нельзя улучшить то, что не измеряешь. Но даже у тех, кто проводит измерения, результаты вызывают беспокойство.</p> Инструменты кодирования с использованием искусственного интеллекта ускоряют работу отдельных специалистов, но большие … article https://www.itweek.ru/themes/detail.php?ID=235389 Mon, 24 Aug 2026 09:25:14 +0300 <p><em>В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как улучшить результаты и снизить затраты на ИИ-инициативы, одновременно защитив корпоративный бренд? В конце концов, высшее руководство все чаще называет внедрение ИИ основным поводом для сокращения штата на 20% и более. Советы директоров и инвесторы компаний оказывают сильное давление на исполнительных руководителей, требуя показать финансовые и ощутимые выгоды от масштабных инвестиций в ИИ, которые обходятся крупным предприятиям более чем в 10 млн. долл. в год, пишет на портале </em><em>BigDataWire</em> <em>Кумар Гошвами, соучредитель и генеральный директор Komprise.</em></p> <p>В целом, пока сложно продемонстрировать окупаемость инвестиций в ИИ. Исследование MIT Research показало, что 95% пилотных проектов генеративного ИИ не приносят измеримой финансовой отдачи, а Gartner прогнозирует, что более 40% проектов агентного ИИ будут отменены к концу 2027 г.</p> <p>Хотя существует множество факторов, объясняющих низкую рентабельность инвестиций и высокий уровень неудач, качество данных является постоянным препятствием, на которое указывают аналитики. Индустрия ИИ до сих пор фокусировалась на уровне рассуждений, в то время как уровню подготовки данных уделялось сравнительно меньше внимания.</p> <p>Более того, подготовка данных часто обсуждается в терминах «последней мили»: разбить документы на фрагменты, сгенерировать вложения, загрузить векторную базу данных, построить конвейер поиска. Это предполагает, что к моменту попадания в конвейер данные чистые, классифицированные, управляемые и релевантные, но это в значительной степени не соответствует действительности. Исследования снова и снова показывают, что организации сталкиваются с проблемами, связанными с разрозненностью, управлением и общим качеством данных. Опрос Databricks показал, что только 37% руководителей считают свои приложения генеративного ИИ готовыми к внедрению в производство.</p> <p>Этот разрыв — проблема «первой мили» ИИ: поиск данных, их понимание, классификация и определение того, что вообще не должно попадать в модель.</p> <h3>Проблема неструктурированных данных для ИИ</h3> <p>Если вы спросите поставщика облачных услуг или платформы LLM, как использовать неструктурированные данные, они почти всегда начнут с того, что посоветуют вам загрузить файлы в хранилище S3 или в озеро-хранилище (lakehouse) данных. Однако этот подход быстро меняется, поскольку объем файловых и объектных данных неуклонно растет, а затраты и риски безопасности для ИИ увеличиваются.</p> <p>Неструктурированные данные, которые составляют от 80 до 90% новых корпоративных данных, растут примерно в три раза быстрее, чем структурированные данные, и теперь являются исходным материалом, необходимым для каждой корпоративной ИИ-инициативы. Тем не менее, большинство ИТ-команд по-прежнему не могут сказать вам, где все это хранится, каково его содержимое или как безопасно использовать это в ИИ.</p> <p>Проблема обработки больших объемов неструктурированных данных многогранна, она охватывает следующее:</p> <ul> <li> файловые хранилища NAS, накопленные за многие годы, и объектные хранилища, распределенные по облачным провайдерам;</li> <li> миллиарды разнообразных файлов: документы, отсканированные PDF-файлы, чертежи САПР, архивы электронной почты, мультимедийные файлы, данные приборов и многое другое;</li> <li> широко распространены дубликаты, «осиротевшие», тривиальные и «зомби», или «мертвые» данные, засоряющие хранилище и ухудшающие видимость;</li> <li> несогласованная структура папок и отсутствие структуры, контекста и богатых метаданных, что затрудняет обнаружение и организацию неструктурированных данных;</li> <li> большая часть этих данных трудно поддается запросам, поскольку они не хранятся в базе данных, разбросаны по разрозненным хранилищам и имеют мало идентифицирующих характеристик.</li> </ul> <h3>Объяснение проблемы «первой мили»</h3> <p>Для подготовки данных к использованию в ИИ необходимо выполнить несколько критически важных этапов предварительной обработки: индексирование в хранилищах разных производителей, обнаружение, очистка и удаление дубликатов, классификация путем обогащения и извлечения метаданных, обнаружение конфиденциальных данных и включение политик управления и безопасности в рабочие процессы обработки данных для ИИ.</p> <p>Эта проблема выявлена ​​в исследовании Komprise «2026 State of Unstructured Data Management», согласно которому классификацию и маркировку неструктурированных данных назвали своей главной проблемой при подготовке данных для ИИ 56% директоров по ИТ-инфраструктуре, по сравнению с 41% годом ранее. Управление и безопасность заняли второе место с 46%.</p> <p>Причина этой проблемы «первой мили» заключается в том, что ИИ эволюционировал от массовых потребительских чат-ботов до стратегических, крупномасштабных корпоративных инициатив с использованием корпоративных данных.</p> <ul> <li><strong>Миф об «песочнице» ИИ.</strong> До недавнего времени большинство корпоративных ИИ-проектов представляли собой изолированные эксперименты или небольшие проверки концепций. При обработке 500 корпоративных документов их можно вручную выбрать, загрузить в хранилище данных и запустить конвейер RAG. Однако с расширением применения ИИ на более крупные задачи это не масштабируется для рабочих нагрузок, которые могут включать 100 000 или более файлов, с неизвестным процентом файлов, не подходящих для данной задачи.</li> <li><strong>Миф о векторной фильтрации.</strong> Существует устойчивое предположение, что векторная база данных автоматически отфильтрует избыточный или устаревший контент. На практике, если у компании есть десяток версий одних и тех же устаревших документов, разбросанных по различным системам хранения, поиск пользователя выдаст несколько противоречащих друг другу версий в одном и том же запросе. ИИ-инженеры не учитывают, что подача огромного количества устаревших, избыточных или низкокачественных данных в модель ИИ приводит к сильным иллюзиям, медленному времени ответа на запросы и раздуванию счетов за токены.</li> <li><strong>Отсутствие инструментов управления на уровне файлов.</strong> Традиционные инструменты хранения данных были созданы для администраторов хранилищ и предназначены для резервного копирования, многоуровневого хранения и архивирования, а не для развертывания рабочих процессов обработки данных для специалистов в области науки о данных. Не хватает инструментов для безопасной и эффективной доставки чистых, организованных файлов из устаревших корпоративных файловых хранилищ в конвейеры обработки данных. В эти рабочие процессы необходимо интегрировать средства управления соответствием нормативным требованиям в отношении использования данных путем выявления конфиденциальных и регулируемых данных и принятия соответствующих мер при необходимости.</li> <li><strong>Экономика владения.</strong> Бизнес-приложения, такие как CRM, ERP и системы взаимодействия с клиентами, влияющие на выручку, имеют финансовую историю и поддержку руководства, поэтому они бюджетируются. Неструктурированные данные в основном находятся в другой бюджетной строке: ИТ-инфраструктура и системы хранения, центр затрат без влияния на доходы. Поиск дубликатов, устаревших или регулируемых файлов, по общему мнению, является более сложной инженерной задачей, но у нее нет бизнес-спонсора в отличие от новой функции CRM. Однако ИТ-команды сейчас понимают, что ИИ зависит от высококачественных, управляемых данных, а подготовка данных требует значительных бюджетных затрат.</li> </ul> <h3>Lakehouse не решает проблему</h3> <p>ИИ повысил важность озера-хранилища данных — архитектуры, сочетающей в себе недорогое хранение в озере данных с управлением уровня хранилища данных. Тем не менее, у lakehouse есть ограничения, когда речь идет о курировании неструктурированных данных для ИИ.</p> <p>Во-первых, lakehouse по-прежнему требует размещения необработанных данных где-то, прежде чем уровень управления сможет с ними работать. Большинство реализаций следуют поэтапной схеме, часто называемой «медальонной архитектурой», размещая необработанные данные в «бронзовом» слое, прежде чем они будут очищены и структурированы. Для строк, извлеченных из CRM, этот шаг обходится недорого. Для петабайтов файловых данных, распределенных по локальным NAS-серверам, нескольким облачным хранилищам и периферийным точкам, это не так, а большие объемы уже являются нормой.</p> <p>Во-вторых, инструменты, созданные для перемещения данных на платформы, такие как ETL и ELT, не были разработаны для больших наборов неструктурированных данных, распределенных по разрозненным хранилищам.</p> <p>Это обосновывает подход «нулевого перемещения»: индексировать и классифицировать данные там, где они хранятся, отфильтровывать избыточные, устаревшие, тривиальные (ROT) данные до их перемещения и перемещать только управляемое подмножество, необходимое для рабочей нагрузки. Lakehouse — прекрасное место назначения. Но требует предварительного решения о том, что там должно находиться.</p> <h3>Переход к нулевой фазе</h3> <p>Финансовые затраты на перемещение всего — это только половина проблемы. Другая половина проявляется в том, что производит система ИИ: ввод в модель низкокачественного или дублирующегося контента, как правило, приводит к заведомо неверному ответу. Существуют также затраты на управление. Контроль доступа на уровне файлов существует не просто так, и когда необработанные данные копируются целиком в новую среду, эти средства контроля не всегда переносятся вместе с ними.</p> <p>Разбивка на фрагменты, синтаксический анализ и векторные вложения по-прежнему необходимы, но они относятся к концу процесса. Нам нужен нулевой этап перед ними: найти, какие данные существуют и где, классифицировать их по содержимому и конфиденциальности, отфильтровать нерелевантные данные и обеспечить соблюдение правил управления и доступа до того, как какие-либо данные будут перемещены в модель или озеро-хранилище данных.</p> <p>Вот как развиваются рабочий процесс и набор инструментов для конвейеров обработки данных ИИ:</p> <ul> <li> инструменты обнаружения и классификации для поиска контента в разрозненных хранилищах;</li> <li> платформы управления неструктурированными данными для метаданных, политик и перемещения;</li> <li> уровни управления и контроля доступа для обеспечения безопасности и отслеживания происхождения данных;</li> <li> инструменты синтаксического анализа, оптического распознавания символов и обогащения для преобразования файлов в пригодный для использования контент;</li> <li> уровни поиска и векторного представления для обслуживания рабочей нагрузки ИИ.</li> </ul> <p>В дальнейшем ИТ- и дата-командам необходимо рассматривать индексирование, поиск и классификацию данных как инфраструктуру, а не как второстепенный аспект. Это позволит организациям эффективно отсеивать дубликаты файлов, неавторитетные и нерелевантные данные, одновременно учитывая специфические требования к данным, которые не подпадают под действие нормативных требований и правил безопасности.</p> <p>Предприятия, которые преодолеют барьер «первой мили», в конечном итоге будут передавать меньше данных в ИИ, экономя на токенах, хранении, вычислительных ресурсах и затратах на передачу данных, обеспечивая при этом доступность только необходимых для конкретного сценария использования данных.</p> <p>Предприятиям, которые хотят, чтобы ИИ работал в масштабе с достижимой окупаемостью инвестиций, в первую очередь необходимо ответить на вопрос: «Где хранятся наши неструктурированные данные, что в них содержится и как мы можем обеспечить их доставку с соблюдением принципов управления?», а не «Какую модель встраивания нам следует использовать?».</p> В мире корпоративного искусственного интеллекта назревает проблема, и ИТ-руководители сталкиваются с дилеммой. Как … article https://www.itweek.ru/themes/detail.php?ID=235388 Fri, 21 Aug 2026 10:03:49 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического обследования Росстата анализирует динамику и структуру затрат крупных и средних организаций (без учета субъектов малого предпринимательства) на внедрение и использование цифровых технологий в 2025 г.</p> <p>В 2025 г. организации направили на внедрение и использование цифровых технологий почти 5,9 трлн руб., что в текущих ценах на 11,8% выше показателя 2024 г.</p> <p>Основные статьи расходов — ПО (лицензии, SaaS, разработка, доработка, адаптация), на которое пришлось 37% анализируемых затрат, и ИКТ-оборудование (приобретение, аренда, обслуживание, модернизация, ремонт) с долей 27%.</p> <p>Расходы на ПО выросли на 13,7%, во многом за счет увеличения заказной разработки.</p> <p>Общий объем затрат на оборудование практически сохранился на уровне 2024 г. (-0,9%), при этом расходы на приобретение ИКТ-оборудования снизились (-10,2%), прежде всего в сегменте вычислительной техники, что объясняется как высокой базой 2024 г. (годом ранее отмечался рост затрат на четверть), так и сложностями с импортом, в том числе из-за возникшего в 2025 г. дефицита серверов и оперативной памяти на мировом рынке. Одновременно в 1,5 раза вырос объем затрат на аренду вычислительных мощностей (IaaS).</p> <p>Наиболее высокими темпами росли расходы на базы данных и цифровой контент: при доле всего 3,3% в структуре затрат за год они увеличились в 1,7 раза.</p> <p>Более половины анализируемых затрат приходится на сферу ИТ и связи (36%) и финансовый сектор (23,1%). В 2025 г. вложения выросли как в этих, так и в большинстве других отраслей— всего в 16 из 18. Расходы в госуправлении, здравоохранении, оптовой и розничной торговле увеличились на <nobr>20–22%,</nobr> в ИТ и связи, финансовом секторе, обрабатывающей промышленности, профессиональной и научно-технической деятельности, на транспорте — на <nobr>11–14%.</nobr></p> <p>Основную часть затрат на цифровые технологии организации покрыли за счет собственных средств (86,6%). Доля бюджетных составила 12,3%, заемных и прочих привлеченных средств — немногим более 1%.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе данных сплошного статистического … message https://www.itweek.ru/themes/detail.php?ID=235387 Fri, 21 Aug 2026 09:09:39 +0300 <p>Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0. Обновление фокусируется на улучшении управляемости групповыми политиками, расширении поддержки отечественных операционных систем с мандатно-ролевым доступом и повышении отказоустойчивости распределённых инфраструктур.</p> <p>Одним из центральных улучшений стало отображение LDAP-структуры непосредственно в интерфейс управления групповыми политиками. Теперь администраторы видят полную иерархию организационных подразделений с привязанными и наследуемыми политиками в режиме реального времени. Это упрощает навигацию по каталогу и позволяет назначать групповые политики напрямую на нужное подразделение без дополнительных переходов между модулями. Всё это ускоряет работу администратора и снижает риск ошибок при настройке.</p> <p>В схему LDAP-каталога добавлены новые классы объектов и атрибуты, необходимые для работы с мандатно-ролевым доступом (МРД) в Astra Linux Special Edition (релизы «Смоленск» и «Воронеж»). Благодаря этому MULTIDIRECTORY теперь полностью совместима с требованиями по защите информации, предъявляемыми к системам в государственных и регулируемых отраслях. Обновление позволяет централизованно управлять учётными записями и политиками безопасности в инфраструктурах, где используются сертифицированные версии Astra Linux с МРД.</p> <p>Для распределённых и высоконагруженных инфраструктур реализована динамическая балансировка запросов между контроллерами домена в отказоустойчивой конфигурации. Система учитывает состояние healthcheck каждого контроллера и автоматически перенаправляет запросы на доступные узлы. Это позволяет разворачивать MULTIDIRECTORY в отказоустойчивом кластере, обеспечивая бесперебойную работу инфраструктуры даже при выходе отдельных компонентов из строя.</p> <p>В новой версии устранён ряд критических ошибок, влияющих на стабильность и совместимость системы. Исправлены BER-обёртка для LDAP Controls, логика определения namingContexts в rootDSE и обработка удаления атрибутов в Modify Request — теперь операция не чувствительна к регистру. Устранены ошибки в генерации файлов init.sls в результирующих политиках, очистке тома Salt Master от устаревших политик и ожидании готовности сервисов Kerberos.</p> <p>Обновление MULTIDIRECTORY 3.2.0 превращает службу каталогов в отказоустойчивое решение для распределённых инфраструктур, которое обеспечивает соответствие регуляторным требованиям и стабильность работы в сертифицированных контурах защиты информации.</p> Компания МУЛЬТИФАКТОР, российский разработчик ИТ- и ИБ-решений, выпустила версию службы каталогов MULTIDIRECTORY 3.2.0 … message https://www.itweek.ru/themes/detail.php?ID=235384 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Новое исследование «</em><em>Scaling</em> <em>AI</em> <em>agents</em> <em>with</em> <em>trustworthy</em> <em>data</em><em>» от MIT Technology Review и Google Cloud подтверждает, что эффективное внедрение искусственного интеллекта начинается с надежного фундамента данных и современных методов управления данными.</em></p> <p>Отчет основан на опросе 300 директоров по данным и аналитике, CIO, CTO, директоров по ИИ, а также руководителей отделов продуктов, ИТ, данных и ИИ в различных отраслях.</p> <p>#IMAGE_235385#</p> <p>Основные выводы из исследования:</p> <ul> <li>Большинство организаций (83%) сообщили об использовании агентного ИИ, при этом 73% используют его для ограниченного числа сценариев. Только каждая десятая организация использует его широко.</li> <li> Хотя 100% респондентов заявили, что планируют использовать агентный ИИ в течение следующих двух лет, только около половины респондентов доверяют точности и релевантности результатов работы агентов ИИ.</li> <li> Исследование также показало, что в среднем инструментам агентного ИИ доступны около 45% данных компании, при этом избранная группа респондентов, называемая «лидерами в области данных», предоставляет ИИ доступ к более чем 70% своих данных. Другие сообщают о предоставлении доступа к 30% или менее своих данных.</li> <li> В отчете успех и доверие лидеров в области данных к агентному ИИ объясняются прочным фундаментом данных, в то время как другие организации сообщают о проблемах, связанных с устаревшими системами.</li> </ul> <p>«Мы должны предоставлять агентам доступ к данным безопасным и надежным способом, чтобы люди могли максимально эффективно использовать данные, зная, что они полностью надежны», — считает Раджприт Баджва, вице-президент Shopify по инженерии и инфраструктуре данных.</p> <p>В отчете упоминается группа компаний, которую называют «лидерами в области данных». Эти компании сообщают о большем успехе в использовании агентного ИИ и меньшем количестве ограничений данных со стороны устаревших систем. Хотя только около 50% респондентов доверяют своим агентам ИИ, 100% лидеров в области данных сообщили о доверии к точности и решениям своих агентов ИИ. В отчете говорится, что это «сильный показатель того, что надежный ИИ требует надежного фундамента данных».</p> <p>За пределами группы лидеров в области данных 66% респондентов заявили, что устаревшие системы ограничивают их возможности масштабирования агентного ИИ, а 68% заявили, что устаревшие системы замедляют скорость работы агентов. Среди других проблем — недостаток контекста и унификации данных (40% респондентов опроса Teradata/Wakefield «Why Agentic AI Stalls Enterprise» сообщили об тех же проблемах, несмотря на наличие надежных моделей ИИ).</p> <p>«Организации стремительно переходят к операционной модели, в основе которой лежит ИИ. Теперь ИИ учитывается при принятии каждого бизнес-решения, в каждом рабочем процессе и при любых инвестициях. Без четкой приверженности ИИ на уровне всего предприятия организациям будет сложно в полной мере реализовать его потенциал в масштабе предприятия», — говорит Карли Идоин, вице-президент-аналитик Gartner.</p> Новое исследование «Scaling AI agents with trustworthy data» от MIT Technology Review и Google Cloud подтверждает … message https://www.itweek.ru/themes/detail.php?ID=235382 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Зарубежные аудиторы ушли из России, но потребность в зрелой стратегии информационной безопасности никуда не исчезла. Теперь российским компаниям приходится одновременно развивать собственные команды, обращаться к локальным консультантам и превращать ИИ-агентов в персональных экспертов по кибербезопасности.</em></p> <p>После ухода из России крупнейших международных аудиторских компаний рынок информационной безопасности лишился не просто известных брендов. Вместе с ними ушел доступ к огромному массиву практического опыта, который формировался благодаря работе с компаниями из разных стран, отраслей и регуляторных сред.</p> <p>Российский рынок составляет около 2% мирового рынка ИТ и информационной безопасности. Поэтому локальные специалисты и консультанты объективно работают с меньшим количеством сценариев, бизнес-моделей и инцидентов. Именно клиентское покрытие давало зарубежным аудиторам ключевое преимущество: они могли переносить в проекты процессы и подходы, проверенные на международном уровне.</p> <p>Рост доли России с 2 до 4% мирового ИТ-рынка к 2030 году можно рассматривать не как прогноз, а как ориентир для отрасли. Однако для такого роста недостаточно увеличивать число технологий и специалистов. Российскому бизнесу нужны зрелые процессы, в том числе в информационной безопасности. После ухода международных аудиторов готового доступа к таким практикам стало меньше, поэтому компаниям приходится фактически заново собирать эту экспертизу — внутри собственных команд, с помощью российских консультантов и ИИ-агентов.</p> <p>Сегодня перед российским средним и крупным бизнесом стоит сложный вопрос: откуда брать зрелую экспертизу и на чем строить стратегию информационной безопасности, если прежние источники знаний стали недоступны?</p> <p>Единственного решения здесь нет. Компании могут использовать три подхода — внедрять ИИ-агентов, развивать собственные команды и привлекать российских аудиторов. Но по-настоящему жизнеспособная стратегия возникает только тогда, когда бизнес совмещает все три направления.</p> <h3>ИИ-агент может стать экспертом по кибербезопасности — но на его обучение потребуется время</h3> <p>Современный ИИ — это уже не просто приложение, в которое пользователь вводит запрос через браузер. Бизнес может приобрести специализированный сервис, подключенный через API к крупным языковым моделям и способный самостоятельно выбирать источники и инструменты для решения конкретной задачи.</p> <p>На основе такой системы можно создать персонального ИИ-эксперта по информационной безопасности.</p> <p>Для этого агенту необходимо предоставить максимально полную базу знаний: российскую и зарубежную профессиональную литературу, нормативные документы, методологии, отраслевые исследования, описания угроз и практические материалы. Чем больше релевантной информации получает система, тем точнее становятся ее рекомендации.</p> <p>При последовательном обучении через год такой агент сможет превратиться в полноценного помощника для команды информационной безопасности. Он сможет обращаться в том числе к источникам, находящимся за пределами России, анализировать международные практики и сопоставлять их с задачами конкретного бизнеса.</p> <p>ИИ-агент способен помочь компании определить основные риски, понять, какой аудит необходимо провести, какие данные собрать и какой информации не хватает для принятия решений. Он также может использоваться при подготовке рекомендаций и формировании первоначальной карты информационной безопасности.</p> <p>При этом ИИ не должен работать бесконтрольно. Вместе с агентами компании необходимо внедрять системы проверки их действий, результатов и доступа к корпоративной информации.</p> <h3>Одного универсального специалиста недостаточно: стратегия ИБ требует целой команды</h3> <p>Второй путь — развитие собственной экспертизы. Это наиболее устойчивый, но одновременно самый дорогой вариант.</p> <p>Построить стратегию информационной безопасности силами одного универсального специалиста невозможно. Для полноценной оценки рисков нужны сотрудники с разными компетенциями: специалисты по ИТ и информационной безопасности, финансисты, представители бизнеса и другие эксперты.</p> <p>Каждый из них отвечает за отдельную часть задачи. Технические специалисты оценивают инфраструктуру и средства защиты. Финансисты помогают рассчитать возможный ущерб и стоимость мероприятий. Представители бизнеса определяют, какие процессы и данные действительно критичны для компании.</p> <p>Формирование полноценной стратегической карты может занимать не менее трех лет. После этого ее необходимо ежегодно пересматривать и актуализировать с учетом изменений бизнеса, инфраструктуры и угроз.</p> <p>Для компании это означает необходимость постоянно содержать команду специалистов либо заново привлекать экспертов при каждом обновлении стратегии. Поэтому собственная экспертиза дает бизнесу независимость, но требует долгосрочных инвестиций в найм, обучение и сохранение команды.</p> <h3>Российские аудиторы остаются необходимы, хотя их опыт пока уступает международному</h3> <p>Третий вариант — обращаться к компаниям, которые продолжают работать в России.</p> <p>У локальных аудиторов меньше международного опыта, готовых сценариев и накопленных отраслевых практик, чем было у крупнейших зарубежных компаний. Кроме того, на российском рынке пока не так много организаций, готовых заказывать комплексную разработку стратегии информационной безопасности: такие проекты стоят дорого и требуют участия руководства.</p> <p>Тем не менее полностью отказаться от внешней экспертизы бизнес не может. Независимые консультанты позволяют посмотреть на инфраструктуру и процессы со стороны, выявить риски, которые внутренняя команда может не замечать, и проверить обоснованность уже принятых решений.</p> <p>Российские аудиторы становятся важной частью системы, но их работа должна дополняться внутренней экспертизой компании и возможностями ИИ.</p> <h3>Стратегия ИБ показывает не только как защищаться, но и сколько это будет стоить</h3> <p>Стратегия информационной безопасности строится вокруг трех базовых принципов: целостности, доступности и достоверности информации.</p> <p>Ее задача — определить, в каких областях компания подвержена рискам и к каким последствиям они могут привести.</p> <p>Например, бизнесу необходимо обеспечить доступность стратегически важных документов. Но эта доступность может быть нарушена по разным причинам: из-за отключения электроэнергии, отказа сервера, действий злоумышленников или порчи документов сотрудником.</p> <p>Стратегия позволяет последовательно ответить на несколько вопросов: какие сценарии возможны, насколько они вероятны, какой ущерб могут причинить и какие меры помогут их предотвратить.</p> <p>На основе этого компания определяет, сколько денег необходимо потратить на минимизацию каждого риска. При этом стратегия не предполагает, что бизнес должен закрыть абсолютно все угрозы. Некоторые риски можно принять, если стоимость защиты окажется выше потенциального ущерба.</p> <p>Поэтому стратегия отвечает не только на вопрос, как закрыть риск, но и нужно ли вообще это делать. В отдельных случаях эффективнее не покупать дополнительную систему защиты, а пересмотреть сам бизнес-процесс.</p> <h3>Бесплатное или корпоративное решение: выбор должен зависеть от задачи</h3> <p>Стратегия также помогает определить, какие специалисты требуются компании и в каком количестве. Для минимизации каждого риска нужен свой набор компетенций, причем эти специалисты необязательно должны работать в штате.</p> <p>Одновременно бизнес решает, какие системы целесообразно разработать самостоятельно, а какие — приобрести у внешнего поставщика.</p> <p>Особенно активно сейчас обсуждается выбор между бесплатными решениями с открытым исходным кодом и платными корпоративными продуктами. Однако сама по себе стоимость лицензии не должна становиться главным аргументом.</p> <p>Решение необходимо выбирать исходя из задачи, масштаба внедрения, количества пользователей и условий эксплуатации. Бесплатный продукт может оказаться подходящим для одного сценария, но потребовать значительных затрат на настройку, поддержку и контроль в другом.</p> <p>Стратегия информационной безопасности позволяет связать технологический выбор с реальными потребностями бизнеса, а не с модой или формальным требованием внедрить определенный класс решений.</p> <h3>Трехлетняя карта заранее показывает, что делать и какой бюджет закладывать</h3> <p>Результатом стратегической работы становится дорожная карта. Она определяет, какие мероприятия компания должна выполнить в первый, второй и последующие годы.</p> <p>Благодаря этому бизнес может заранее распределить бюджет, запланировать внедрение систем, обучение сотрудников, аудит процессов и привлечение внешних специалистов.</p> <p>Такая карта не является неизменным документом. Если компания выходит в новый сегмент, запускает продукты, перестраивает инфраструктуру или меняет бизнес-модель, стратегию информационной безопасности необходимо актуализировать.</p> <p>Защита должна развиваться вместе с бизнесом. Иначе даже качественно подготовленный документ через несколько лет перестанет соответствовать реальным процессам и угрозам.</p> <h3>В одиночку не сработает: российскому бизнесу придется объединить все три подхода</h3> <p>В текущих условиях российским компаниям не стоит выбирать между собственной командой, ИИ и внешними аудиторами. Все три подхода необходимо использовать одновременно.</p> <p>Бизнесу нужно развивать внутреннюю экспертизу, инвестировать в обучение специалистов и сохранять целостность команды. Параллельно следует внедрять ИИ-агентов, обучать их на российских и зарубежных источниках и создавать механизмы контроля за их действиями.</p> <p>Кроме того, компаниям необходимо пользоваться услугами российских аудиторов, которые могут независимо оценить процессы, инфраструктуру и принятые решения.</p> <p>Отдельное внимание следует уделять системам, предотвращающим утечки персональных данных, поскольку развитие ИИ и расширение цифровой инфраструктуры создают дополнительные риски для корпоративной информации.</p> <p>Уход международных аудиторов лишил российский рынок части накопленной экспертизы, но не сделал построение зрелой системы информационной безопасности невозможным. Совмещение внутренней команды, внешнего аудита и возможностей ИИ позволяет создать стратегию, которая будет учитывать реальные бизнес-риски, доступные ресурсы и долгосрочные цели компании.</p> <p>#IMAGE_235383#</p> Зарубежные аудиторы ушли из России, но потребность в зрелой стратегии информационной безопасности никуда … article Сергей Крюков, генеральный директор exploitDog (НИР) https://www.itweek.ru/themes/detail.php?ID=235370 Fri, 21 Aug 2026 00:00:00 +0300 <p><em>Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители демонстрируют реальный прогресс в решении проблем масштабирования и коррекции ошибок. Существуют реалистичные планы по выпуску квантовых компьютеров, которые могут принести коммерческую выгоду. Но эта выгода будет неравномерной, проявляясь в конкретных классах высокоприоритетных задач и в разные временные горизонты. Технологическим руководителям необходимо практическое понимание того, где и когда квантовые вычисления, вероятно, будут иметь значение, пишет в корпоративном блоге Дэвид Мутер, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>Квантовые компьютеры — это другие, а не более быстрые компьютеры</h3> <p>Квантовые компьютеры — это не суперкомпьютеры с большей вычислительной мощностью, как это часто изображается в новостях. Классические компьютеры основаны на булевой логике, физически реализуемой в соответствии с уровнем напряжения в полупроводниках. Квантовые компьютеры основаны на линейной алгебре и интерференционных картинах, которые возникают из-за волновой природы квантовых объектов. Это делает квантовые вычисления принципиально иными, подходящими для других типов задач.</p> <p>Какие это типы задач? Речь идёт о задачах, связанных с экспоненциально растущим числом комбинаций, физическими системами квантового уровня или вероятностными результатами, которые трудно эффективно моделировать на классических системах. Примеры: оптимизация портфеля, молекулярное моделирование, открытие новых материалов, логистические маршруты, моделирование электрических сетей и некоторые формы стохастического анализа рисков.</p> <p>Что это значит? Если задачу можно решить классическим методом, она будет решаться классическим методом и впредь. Это также означает, что квантовые компьютеры станут компонентами более широкого вычислительного конвейера, решая вычислительные задачи, которые классические компьютеры не могут решить, а для остальных задач будут использоваться классические методы.</p> <p>Таким образом, квантовые вычисления не будут развиваться как самостоятельная платформа. Квантовые компьютеры будут гибридными, сочетая классические вычисления с квантовыми в единой системе. Поставщики, которые сделают квантовые вычисления доступными благодаря гибридным средам выполнения и интеграции с классическими вычислениями, станут главными лидерами рынка.</p> <h3>Ценность квантовых вычислений эволюционирует в избирательную коммерческую значимость</h3> <p>В краткосрочной перспективе состояние рынка по-прежнему будет определяться экспериментами. Прогресс будет достигнут за счет улучшения коррекции ошибок, совершенствования алгоритмов и более четкого понимания того, какие аппаратные средства масштабируемы. Наиболее неотложным приоритетом для бизнеса в это время будет безопасность. Организациям следует ускорить планирование постквантовой криптографии, поскольку достижения как в области квантового оборудования, так и в оптимизации алгоритма Шора для снижения требуемой вычислительной мощности квантовых вычислений приближают наступление «Дня квантовых вычислений» (Q-Day).</p> <p>В долгосрочной перспективе квантовые вычисления станут коммерчески значимыми, но избирательно. Они не станут повсеместным ускорителем для всех корпоративных технологий, как компьютеры, с которыми мы выросли. Скорее, это будет высокоточный инструмент для специализированных рабочих нагрузок. Наибольшие возможности будут сосредоточены в таких отраслях, как медико-биологические науки, химическая промышленность, материаловедение, финансовые услуги, логистика, производство и энергетика.</p> <h3>Оценивайте потенциал квантовых вычислений по соответствию рабочей нагрузке</h3> <p>Как и в случае с любой технологией, способ оценки квантовых вычислений заключается в определении того, какие бизнес-задачи обладают характеристиками, которые делают эту технологию потенциально полезной. Наиболее подходящие рабочие нагрузки, как правило, связаны с вычислительной сложностью, основанной на многомерной линейной алгебре, — это, например, оптимизация, молекулярное или физическое моделирование и вероятностное моделирование. Наименее подходящие рабочие нагрузки — это те, для которых уже существуют хорошие решения в классических системах или которые имеют большую сложность данных.</p> <p>Понимание перспектив и ограничений квантовых вычислений поможет организациям избежать как упущенных возможностей из-за чрезмерной самоуспокоенности, так и погони за ложными результатами, вызванной ажиотажем. Некоторым отраслям следует начать структурированное исследование уже сейчас, поскольку долгосрочный потенциал роста может проявиться раньше, чем ожидается. Другим следует отслеживать прогресс и избегать спекулятивных инвестиций до тех пор, пока прогресс в квантовых исследованиях не покажет более четкую совместимость рабочих нагрузок.</p> Квантовые вычисления перешли из разряда теоретического любопытства в категорию инженерной реальности. Производители … article https://www.itweek.ru/themes/detail.php?ID=235386 Thu, 20 Aug 2026 11:38:42 +0300 <p>В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов. Рынок совершает переход от систем, которые отвечают на запросы, к системам, которые действуют самостоятельно — от генеративного к агентному ИИ. Владимир Лебедев, директор по развитию бизнеса сервис-провайдера M1Cloud, рассказал, как трансформируется облачная инфраструктура для использования ИИ-агентов.</p> <p>Глобальный рынок агентного ИИ, по оценкам Stratistics MRC, в этом году достигнет $10,3 млрд и будет расти до $207,6 млрд к 2034 году при среднегодовом темпе роста 45,6%. По данным PwC, 88% руководителей планируют увеличить бюджеты на ИИ именно ради агентных сценариев, а Gartner прогнозирует, что к концу 2026 года 40% корпоративных приложений будут оснащены специализированными ИИ-агентами (против менее 5% в 2025 году). Агентный ИИ — это принципиально иная парадигма. Автономные агенты планируют действия, обращаются к корпоративным API, делегируют задачи другим ИИ-системам и выполняют многошаговые сценарии с минимальным участием человека. Человек смещается из позиции исполнителя в позицию супервайзера.</p> <p>За взрывным ростом внедрения ИИ-агентов скрывается фундаментальная проблема: корпоративная инфраструктура к этому не готова. По данным Google Cloud, 83% организаций заявляют о необходимости срочной модернизации мощностей для поддержки промышленного агентного ИИ.</p> <p>Запрос, который раньше генерировал один ответ, теперь запускает каскад из сотен действий. В отличие от пакетной обработки — чтение баз данных, межсервисное взаимодействие, координацию агентов. Каждое действие потребляет токены, генерирует сетевой трафик и требует ресурсов для логирования. Агентам нужна память о контексте и прогрессе. Каждый лишний шаг в цепочке вызовов умножает задержку, что требует от провайдера высочайшей скорости интерконнекта и оптимизированных сетей. Возникает феномен «инференс-налога» (inference tax) — скрытых затрат на вывод данных и разрастание хранилищ, с которыми уже столкнулись 62% технических руководителей (по данным Google Cloud).</p> <p>Российский рынок следует глобальному тренду, но со своей спецификой. Совместное исследование Apple Hills Digital, VK Tech, Cloud.ru и Selectel показывает, что 46% отечественных компаний уже используют или тестируют ИИ в облаке, а 27% клиентов провайдеров уже применяют облачных ИИ-агентов. Бюджеты на ИИ увеличили 35% компаний, опередив по темпам роста даже кибербезопасность. Если при классическом обучении моделей затраты относительно предсказуемы, то агентный ИИ генерирует расходы экспоненциально. Без автоматического мониторинга и управления каскадными вызовами компании рискуют столкнуться с тем, что до трети (а в случае с агентами — и больше) облачного бюджета будет сожжено впустую на неоптимальные маршруты агентов и простаивающие stateful-контейнеры.</p> <p>В новых реалиях облачный провайдер перестает быть просто поставщиком вычислительных мощностей и становится стратегическим партнером. Только облако способно обеспечить экономически обоснованную эластичность под непредсказуемые пиковые нагрузки агентных систем, избавляя бизнес от необходимости покупать дорогостоящее железо, которое устаревает за полтора года. Помимо этого, облако становится единой платформой для управления и безопасности: когда сотни автономных агентов получают доступ к корпоративным данным, централизованный аудит, управление правами и MLOps. Зрелый провайдер берет на себя роль FinOps-консультанта, помогая оптимизировать «инференс-налог»: распределяя нагрузку между CPU (для оркестрации), GPU (для тяжелого инференса) и специализированными ускорителями, а также настраивая автоматическое масштабирование stateful-сред.</p> В 2026 году искусственный интеллект наконец перешел от создания контента к выполнению реальных бизнес-процессов … message https://www.itweek.ru/themes/detail.php?ID=235380 Thu, 20 Aug 2026 09:43:39 +0300 <p>Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и скорость. Сначала — через сервис-ориентированную архитектуру (SOA), затем — через «серебряную пулю» микросервисов.</p> <p>Это обещание звучало заманчиво: распилите монолит на крошечные независимые сервисы, общающиеся по вебу, и вы будете выкатывать функционал бизнесу за пару дней силами изолированных команд. Маркетинговый хайп победил инженерный рассудок.</p> <p>Сегодня за ширмой «современного стека» скрывается суровая реальность: тотальный паралич Time-To-Market (TTM), астрономический технический долг и кратные финансовые потери.</p> <h2>Архитектурные заблуждения и подмена понятий: ООП наизнанку</h2> <p>В чём фундаментальный просчет концепции микросервисов в их массовом исполнении? В том, что базовые принципы проектирования программного обеспечения — инкапсуляцию, слабую связность и объектно-ориентированный подход — попытались насильно перенести на уровень сети.</p> <p>Архитекторы «новой волны» решили, что микросервис — это изолированный объект, а сетевой HTTP/REST-запрос — это просто вызов метода. Индустрия проигнорировала законы физики. Если вызов метода в едином адресном пространстве оперативной памяти (In-Memory Call) занимает наносекунды и абсолютно надежен, то сетевой вызов между мелкогранулированными компонентами занимает уже миллисекунды. А сама сеть к тому же по определению ненадежна.</p> <p>Ирония судьбы — в том, что в эпоху расцвета классической SOA те же промышленные платформы, от enterprise-решений ведущих вендоров до систем с открытым исходным кодом на .NET, Java или Python, технически предоставляли абсолютно те же преимущества, которые сегодня приписывают исключительно микросервисам.</p> <p>Архитектурные возможности изначально позволяли объединить отдельные прикладные компоненты и интеграционные адаптеры в изолированные крупногранулированные сервисы в соответствии с границами доменной области. Внутри этого домена компоненты взаимодействовали в едином адресном пространстве оперативной памяти (In-Memory), а платформы великолепно масштабировались горизонтально за счет логических экземпляров среды выполнения в составе одной или нескольких операционных систем.</p> <p>В какой-то момент в индустрии перестали соблюдать базовые принципы SOA-архитектуры, забыв, что микросервисы — это не более чем подмножество SOA.</p> <p>Вместо того чтобы наводить порядок в границах доменной области, разработчики объявили проверенные подходы «тяжелыми» и ушли в микросервисный веб. Они упустили из виду, что этот самый веб — про переносимость, и вся его прелесть проявляется тогда, когда речь идет об интеграции разнородных систем, развернутых на принципиально разных платформах, когда речь идет об интероперабельности.</p> <p>Физическая изоляция (сеть и контейнеризация) стала защитой от низкой культуры и дисциплины разработки. Если вы не умеете инкапсулировать код в логические модули, сеть заставит вас сделать это силой. Но цена такого принуждения оказалась непомерной для бизнеса.</p> <h2>Подмена понятий: из песочницы разработки в промышленную эксплуатацию</h2> <p>Чтобы понять, как мы оказались в этой точке, нужно вспомнить историю развития технологий разработки. Весь этот технологический стек — контейнеризация, платформы оркестрации и автоматизированные CI/CD-пайплайны — изначально задумывался исключительно как инструментарий для высвобождения рабочего времени разработчика.</p> <p>В частности, изоляция сред в контейнерах была введена в процесс разработки как ответ на вечное проклятие: «на моей машине всё работало». Она была нужна, чтобы программист мог мгновенно развернуть готовое локальное окружение.</p> <p>Платформы оркестрации контейнеров создавались в недрах технологических гигантов для утилизации пустующих серверов дата-центров и быстрой подготовки эфемерных тестовых сред под нужды команд автоматизации. Эти инструменты создавались для «песочниц», прототипирования и автоматизации рутины. Никто не проектировал их под высоконагруженные транзакционные контуры, требующие промышленной надежности.</p> <p>Трагедия современной ИТ-индустрии в том, что инструмент быстрой лепки временных сред ошибочно приняли за стандарт. Архитекторы перенесли логику «песочницы» на боевые контуры транзакционных систем финансового и промышленного секторов. В результате бизнес получил хрупкую распределенную систему, где стабильность решения принесена в жертву сиюминутному удобству локального написания кода.</p> <h2>Великое заблуждение: архитектура системного ПО в транзакционном бизнесе</h2> <p>Микросервисная архитектура родилась не на предприятиях непрерывного цикла и не в банках с их высокоинтенсивными рабочими нагрузками. Она появилась в недрах цифровых гигантов (Netflix, Amazon, SoundCloud), у которых вообще не было чужих систем и разных поставщиков. Они контролировали 100% своего стека и писали всё с нуля.</p> <p>В этих условиях все сервисы изначально взаимодействовали на одном «языке» (JSON/REST), и трансформировать форматы данных было просто не нужно. Внедрение сложных интеграционных шин в такую однородную среду принесло бы только лишние накладные расходы.</p> <p>Но главное — характер их работы. Микросервисы в их каноническом виде — это архитектура уровня системного ПО управления ресурсами. Условная транзакция в облачном провайдере или стриминговом сервисе запускает длительный, асинхронный процесс. Например, развертывание виртуальной машины из ISO-образа. Этот процесс занимает десятки секунд или минуты. Пользователь готов ждать.</p> <p>На этом фоне 10 миллисекунд сетевых задержек, возникающих при взаимодействии между мелкогранулированными системными сервисами (один выделяет диск, другой вешает IP), — это не более чем математическая погрешность. Там действительно не нужна интеграционная транзакционная «молотилка».</p> <p>Но когда, например, в вакансиях «инновационного финтеха» для Core-системы со строгой OLTP-нагрузкой фигурируют микросервисы и оркестраторы — это признак тотального непонимания физики процессов. Финтех-операция должна выполняться синхронно, атомарно и за миллисекунды. И здесь 15 миллисекунд сетевых издержек на каждый шаг цепочки (запрос в сервис баланса, запрос в антифрод, запрос в лимиты) — это архитектурный приговор.</p> <p>Система тратит время не на полезную работу (изменение пары байт в СУБД), а на ожидание ответов по сети, обработку HTTP-заголовков и обеспечение консистентности данных (Eventual Consistency), которая в транзакционных системах недопустима по определению.</p> <h2>Иллюзия Time-To-Market: быстро на старте, паралич на финише</h2> <p>Главный аргумент в пользу микросервисов — это ускорение TTM. И на этапе разработки системы с нуля эта иллюзия действительно работает. Написать один мелкий сервис, который выполняет одну конкретную функцию, можно за пару дней. Руководство и бизнес-заказчик аплодируют стоя.</p> <p>Проблемы начинаются, когда система разрастается до сотен мелкогранулированных ИТ-сервисов, общающихся преимущественно по Web/HTTP. Бизнес же мыслит сквозными ценностями, а не микрофункциями. И когда для реализации одной новой бизнес-функциональности (например, внедрения нового типа лояльности) требуется одновременно изменить контракты в <nobr>5-7</nobr> разных микросервисах, начинается ад:</p> <ol> <li> <strong>Паралич взаимодействия команд:</strong> нужно согласовать изменения API с пятью независимыми командами. Продуктовый TTM падает до нуля, утопая в бесконечных созвонах, а также в согласованиях контрактов в спецификациях и задачах.</li> <li><strong>Интеграционный тупик:</strong> вместо релиза одной кнопкой компания получает сложнейшие распределенные релизные циклы. Архитектура превращается в распределенный монолит — худшее из обоих миров, выпуск релиза которого происходит дольше и болезненнее, чем в крупногранулированной SOA-архитектуре двадцать лет назад.</li> </ol> <h2>Облачный грабеж и трехкратный «инфраструктурный налог»</h2> <p>Когда ИТ-директора обосновывали переход на микросервисы, главным экономическим аргументом был отказ от «вендорской иглы» — коммерческих лицензий за процессорные ядра или вычислительные узлы, выделенные под прикладное решение. Обещание звучало как финансовое освобождение: «Мы уйдем на свободное программное обеспечение (Open Source), перенесем всё в облако и будем платить только за реальное потребление».</p> <p>Но на серьезных нагрузках микросервисная архитектура дает <strong>2-3-кратный рост расходов бюджета</strong>. Этот «финансовый пылесос» состоит из трех главных составляющих:</p> <ul> <li> <strong>Память и процессоры.</strong> В микросервисах каждому крошечному сервису нужно выделить сотни мегабайт оперативной памяти просто на прогрев его собственного изолированного окружения. Транзакция превращается в каскад из <nobr>10-15</nobr> сетевых вызовов, где до <nobr>40-60%</nobr> мощности процессора тратится на постоянную сериализацию и десериализацию JSON, шифрование TLS и перекладывание байтов по сетевым стекам. Чтобы переварить ту же нагрузку, приходится покупать в 2,5 раза больше вычислительных ядер (vCPU). Умножьте это на сотни сервисов и на зоны доступности. Как итог: бизнес платит за гигабайты памяти и процессорное время, которые вообще не используются для выполнения прикладной логики. В то же время транзакция в крупногранулированном сервисе — это просто передача ссылки на объект в памяти, не требующая выделения дополнительной памяти и процессорного времени на сериализацию и десериализацию.</li> <li> <strong>Скрытый «убийца» — сетевой трафик.</strong> Чтобы обеспечить высокую доступность, экземпляры микросервисов размазываются по разным дата-центрам (зонам доступности). Облачные провайдеры жестко тарифицируют каждый гигабайт трафика между зонами доступности (Inter-AZ). В рамках единого крупногранулированного сервиса этот трафик был бесплатным (внутри хоста); в микросервисах счета за внутриоблачную сеть часто превышают стоимость самих процессоров.</li> <li> <strong>Инфраструктурные надстройки как величайший обман.</strong> Пытаясь уйти от концепции интеграционных шин, ИТ-архитекторы заявили, что связь теперь «бесплатная». Но когда сетью стало невозможно управлять, индустрия придумала концепцию Service Mesh. Вместо одной центральной шины компания получила тысячи микрошин в виде прокси-приложений (sidecar) для каждого контейнера. Эксплуатация таких решений в крупных проектах показывает, что эти прокси съедают от 20 до 50% всей оперативной памяти и до 30% CPU всего вычислительного кластера. Бизнес просто перенаправил миллионы из одного кармана в другой — в пользу облачных провайдеров.</li> </ul> <h2>Практика против моды: опыт технологических лидеров</h2> <p>Для тех, кто считает эти расчеты «теоретическим ретроградством», индустрия приготовила серию сокрушительных прецедентов от компаний, чьи масштабы нагрузок не подлежат сомнению.</p> <h3>Amazon Prime Video: отрезвление изнутри</h3> <p>Самый громкий удар по микросервисной религии нанесла сама компания Amazon — создатель главной облачной инфраструктуры планеты.</p> <p>Инженеры команды Amazon Prime Video, спроектировав распределенную систему мониторинга качества видеопотоков по «модному учебнику», столкнулись с финансовой катастрофой при попытке масштабирования. Изначальная архитектура опиралась на оркестрацию через AWS Step Functions и бессерверные вычисления AWS Lambda. Архитектурный просчет заключался в том, что компоненты пайплайна (медиаконвертер и детектор дефектов) обменивались терабайтами тяжелых сырых видеокадров, постоянно сохраняя и скачивая их через промежуточное дисковое хранилище Amazon S3.</p> <p>В результате система уперлась в потолок производительности всего на 5% от целевой мощности: компания моментально уперлась в лимиты AWS Step Functions по количеству переходов между состояниями (state transitions) в секунду, а счета за Tier-1 API-запросы к S3 и сетевую сериализацию кратно превысили стоимость самого компюта.</p> <p>Инженеры Amazon полностью переписали архитектуру, объединив все три распределенных компонента в единое монолитное приложение, развернутое в контейнерах Amazon ECS. Вместо пересылки тяжелых фреймов по сети через S3, этапы конвейера стали обмениваться данными напрямую в оперативной памяти (In-Memory) в рамках одного процесса. Результат: <strong>затраты на инфраструктуру снизились на 90%</strong>, а ограничения масштабируемости исчезли.</p> <h3>Shopify: битва за скорость «выкатки фич»</h3> <p>Гигант мировой интернет-торговли Shopify, обрабатывающий миллионы транзакций, вовремя остановил тотальное дробление систем. Архитекторы обнаружили, что мелкогранулированность и распределенность разрушили границы контекстов, вызвав тяжелейший межкомандный паралич: для банального изменения логики скидок или корзины приходилось синхронно переписывать контракты API в шести независимых командах и репозиториях.</p> <p>Shopify официально провозгласил верность концепции «Маджестик Монолита» (Majestic Monolith), но вместо хаотичного «комка грязи» они планомерно реорганизуют кодовую базу в строго изолированный «<strong>Модульный монолит» (Modular Monolith)</strong>.</p> <p>Используя разработанный ими инструмент статического анализа Packwerk (в связке с софтверными контрактами Sorbet), компания жестко контролирует границы бизнес-доменов на уровне абстракции кода. Все модули находятся в едином репозитории и разворачиваются вместе, что избавляет инженеров от сетевой бюрократии, сохраняет строгую ACID-консистентность базы данных, но при этом изолирует зоны ответственности команд и сокращает TTM в разы.</p> <h3>Segment (Twilio): тупик мелкозернистой изоляции</h3> <p>Платформа сбора данных Segment изначально создала отдельный микросервис и отдельную очередь для интеграции с каждым внешним партнером (Mixpanel, Salesforce, Google Analytics и др.). В итоге их ИТ-ландшафт превратился в распределенный ад из более чем <strong>140 разрозненных сервисов и 140 отдельных репозиториев</strong>.</p> <p>Из-за постоянных обновлений общих библиотек и латания рассинхронизированных зависимостей (Dependency Hell) разработчики тратили 80% времени на поддержание жизнедеятельности инфраструктуры и RabbitMQ-очередей, а развитие продукта полностью остановилось. Сотни простаивающих контейнеров впустую сжигали базовые CPU-квоты облака.</p> <p>В итоге Segment осуществила радикальный шаг: объединила код всех 140 интеграций обратно в один монолитный Go-бинарник, получивший кодовое имя Centrifuge. Маршрутизация трафика по конечным партнерам стала осуществляться через внутрипроцессную таблицу диспетчеризации в оперативной памяти. Это мгновенно сократило расходы на серверы, драматически подняло утилизацию CPU и полностью ликвидировало ад управления зависимостями, вернув продуктивность продуктовым командам.</p> <h2>Ад оркестрации: почему сложные платформы автоматизации противопоказаны для High Load</h2> <p>Разрубив систему на тысячи кусков, компании выбрали в качестве главного инструмента управления тяжелые платформы оркестрации контейнеров. Но они стали стандартом де-факто для высоких нагрузок абсолютно незаслуженно. Для систем с экстремальными транзакционными нагрузками и жесткими требованиями к задержкам (low-latency) избыточный слой контейнерной оркестрации противопоказан:</p> <ul> <li> <strong>Сетевой пирог виртуализации.</strong> В таких средах сетевой трафик проходит сквозь бесконечные слои абстракций — виртуальные интерфейсы, оверлейные сети, прокси-таблицы ядра и инфраструктурные шлюзы. В транзакционном High Load подобная избыточность превращается в критическое узкое место. Сетевой диспетчер или аппаратный балансировщик эпохи классической SOA распределял трафик по экземплярам приложений практически со скоростью железа.</li> <li> <strong>Борьба за ресурсы.</strong> Оркестратор пытается динамически управлять ресурсами на уровне ядра операционной системы, ничего не зная о процессах и внутренних механизмах управления памятью самого прикладного решения (например, о «сборке мусора»). В итоге планировщик инфраструктуры и внутренний диспетчер приложения начинают «драться» за процессорное время, вызывая жесткое удушение (throttling) CPU и непредсказуемые задержки (latency spikes) прямо посреди финансовой транзакции.</li> <li> <strong>Сложность вместо надежности.</strong> Системы оркестрации создавались для управления тысячами эфемерных веб-компонентов, которые могут безболезненно падать каждую секунду. Но серьезная финтех-платформа или система управления предприятием состоит из стабильных, тяжеловесных сервисов, хранящих состояние (Stateful). Разворачивать под них сложнейшие распределенные оркестраторы — это чистая подмена понятий, увеличивающая аварийность системы из-за человеческого фактора и сложности конфигурации.</li> </ul> <h2>Назад к здравому смыслу: эволюционная реабилитация SOA</h2> <p>Признание краха мелкогранулированных микросервисов вовсе не означает, что индустрия должна в панике откатиться к неделимым монолитам. Выход из этого тупика лежит в возврате к классической, фундаментальной концепции SOA, но переосмысленной на новом технологическом витке:</p> <ol> <li><strong>Крупная гранулярность.</strong> Сервис должен быть крупным. Не «сервис генерации PDF», а «Сервис расчетно-кассового обслуживания». Он объединяет в себе весь бизнес-домен. Внутри него компоненты общаются в оперативной памяти. Сетевая граница проводится только там, где бизнес-процессы действительно разделены организационно (например, интеграция систем разных поставщиков, где SOA и её интеграционные паттерны исторически незаменимы).</li> <li><strong>Отделение бизнес-домена от интеграционного слоя.</strong> Мы берем из SOA проверенную интеграционную логику, но не тащим логику бизнес-домена на централизованную шину. Её задача — выполнять исключительно трансформацию, обогащение и маршрутизацию сообщений. Она выступает просто умным почтальоном для потока данных, связывая системы разных поставщиков.</li> <li><strong>Изоляция без посредников.</strong> Для изоляции рабочей нагрузки не нужны тяжелые контейнерные движки с централизованными демонами управления, являющиеся классической единой точкой отказа и узким местом производительности. Настоящая изоляция крупного SOA-сервиса реализуется через легковесные инструменты нового поколения, работающие по принципу <em>daemonless</em> (без демона) и в режиме <em>rootless</em> (без прав суперпользователя) — такие как Podman. Контейнер в такой схеме запускается как обычный, изолированный процесс Linux, управляемый напрямую ядром ОС (через стандартный systemd). Это дает предсказуемость среды (Infrastructure as Code) и скорость железа без инфраструктурных накладных расходов оркестраторов.</li> </ol> <h2>Вывод для бизнеса</h2> <p>Эра микросервисного романтизма завершается. Компании, считающие свои деньги, больше не могут позволить себе оплачивать трехкратный инфраструктурный налог. Побеждает здравый инженерный расчет.</p> <p>Классическая SOA, очищенная от бюрократии старых инструментов и усиленная легковесной daemonless-контейнеризацией, возвращает себе статус эталонной архитектуры. Она дает ровно то, что обещали, но не смогли дать микросервисы: прогнозируемый TTM, контролируемый техдолг и адекватные затраты на железо. Настоящий High Load всегда покоится на уровне операционной системы и железа, а не на уровне абстракций оркестраторов.</p> <p>#IMAGE_235381#</p> Двадцать лет назад ИТ-индустрия пообещала бизнесу гибкость и скорость. Сначала — через сервис-ориентированную … article Дмитрий Гаврилов, основатель ООО “Открытые Технологии Виртуализации” https://www.itweek.ru/themes/detail.php?ID=235377 Thu, 20 Aug 2026 00:00:00 +0300 <p><em>Компании продолжают вкладывать миллионы в нейросети, но всё чаще признают: результата нет. Разбираемся, почему пилоты не доходят до внедрения и что стоит изменить в подходе к ИИ уже сейчас.</em></p> <p>За последние два года искусственный интеллект прошел путь от модной новинки до строки в бюджете почти каждой крупной компании. Однако чем больше денег уходит на пилоты, тем острее встает вопрос: а где, собственно, отдача? По <a href="https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/">данным</a> MIT NANDA, около 95% корпоративных ИИ-пилотов так и не доходят до измеримого финансового эффекта, а по <a href="https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence">оценке</a> Gartner, довольны окупаемостью инвестиций менее 30% руководителей при среднем чеке проекта около 1,9 млн. долл.</p> <p>Похожая картина и в России. По <a href="https://www.vedomosti.ru/global-ideas/articles/2026/06/02/1202053-vnedrenie-ii-biznes">данным</a> издания «Ведомости», 95% отечественных компаний пока не окупают инвестиции в ИИ-технологии, хотя 40% называют искусственный интеллект главным трендом цифровизации. Проблема почти никогда не в самой технологии — модели давно умеют решать прикладные задачи. Проблема кроется в том, как компании выбирают, запускают и оценивают такие проекты.</p> <h3>Почему пилоты не долетают до результата</h3> <p>Первая причина — путаница между желанием попробовать технологию и реальной выгодой от ее внедрения. Аналитики фиксируют эффект «рабочего мусора»: сотрудники <a href="https://www.kommersant.ru/doc/8632735">массово генерируют</a> ИИ-контент, который выглядит готовым, но требует переделки. Формально ИИ внедрен, но по факту он просто перекладывает работу с одного этапа на другой. В результате вместо сокращения издержек компания получает двойную нагрузку: сначала сотрудник тратит время на формулировку запроса, затем — на проверку и доработку сгенерированного результата, а выгода от автоматизации сводится к нулю.</p> <p>Вторая причина — данные и процессы. Российские аналитики <a href="https://www.cnews.ru/news/top/2026-03-24_biznes_svernul_ili_zamorozil">отмечают</a>: около 90% проектов по генеративному ИИ в отечественных компаниях откладываются или закрываются не из-за качества моделей, а из-за неструктурированных данных и хаотичных регламентов, в которые нейросеть просто не вписывается. Внедрять ИИ в процесс, где нет единого источника данных и нет ответственного за результат, — заведомо неэффективно и не приведет к ожидаемому результату.</p> <p>Третья причина — отсутствие стратегии и метрик. Согласно <a href="https://www.cnews.ru/news/top/2025-12-19_bolshinstvo_rossijskih_kompanij">исследованию</a> МТС Web Services, лишь 26% российских компаний, закладывающих бюджет на ИИ, имеют четкую стратегию внедрения. Без понятных критериев успеха невозможно оценить окупаемость, а значит, проект существует скорее «для галочки», чем для бизнеса, и при первом же аудите бюджета или смене фокуса его свернут, списав затраты в убыток.</p> <h3>Российская специфика: дорогие эксперименты и дефицит мощностей</h3> <p>К управленческим проблемам добавляется инфраструктурная. По <a href="http://reg.ru/company/news/12957">нашим данным</a>, спрос на облачные GPU-мощности в России за первое полугодие 2026 года вырос на 507% год к году: число новых подключений увеличилось на 160%, а ежемесячная активность пользователей — на 260%. При этом дефицит высокопроизводительных ускорителей для обучения крупных моделей сохраняется: сроки поставки востребованных карт достигают <nobr>36-52 недель.</nobr> По оценке <a href="https://www.comnews.ru/content/245257/2026-05-14/2026-w20/1008/vychislitelnyy-tupik-pochemu-rossiyskiy-ii-ostaetsya-bez-moschnostey">отраслевых экспертов</a>, совокупный разрыв в вычислительных мощностях между Россией и США измеряется сотнями раз, а весь российский рынок GPU-ускорителей для ИИ в 2025 году составил около 62,7 млрд. руб. — сумма, за которую крупные технологические экономики покупают буквально в разы больше вычислений.</p> <p>На практике это означает, что покупка собственного оборудования под эксперимент зачастую экономически нерациональна: один ускоритель уровня NVIDIA H200 стоит <nobr>30-40 тыс.</nobr> долл., а полноценный сервер с восемью GPU — 300 тыс. долл. и выше, при том что жизненный цикл карты — всего <nobr>2-3 года.</nobr> Компании, которые закладывают капитальные затраты на GPU в пилот, который может не взлететь, изначально закладывают в проект избыточный риск и одну из причин будущей низкой окупаемости.</p> <h3>От ROI одной нейросети — к экономике процесса</h3> <p>Ключевая ошибка, которую совершают почти все, — считать окупаемость самого ИИ-инструмента, а не изменения, которое он должен принести бизнесу. Исключение — ситуация, когда инструмент создается не для внутреннего использования, а как продукт для продажи на рынок: тогда его собственная окупаемость действительно становится главной метрикой. Поэтому рекомендуется считать не отдельный ROI (Return on Investment, коэффициент окупаемости инвестиций) чат-бота или копилота, а влияние на сквозной процесс — от заявки клиента до закрытия сделки, — и переходить к новой модели расчета: юнит-экономике с ИИ-агентами, где единицей измерения становится не человеко-час, а количество сценариев, закрытых без участия человека.</p> <p>На практике счет выглядит так. Сначала выбирается единица процесса — например, заявка клиента, доведенная от обращения до решения, — и фиксируется ее сегодняшняя стоимость: сумма человеко-часов, инструментов и накладных расходов, деленная на число закрытых единиц за период. Дальше внедряется ИИ-агент, и считается новая стоимость единицы — расходы на инфраструктуру и лицензии (или расходы на подписку или токены) плюс время сотрудников, которое еще нужно на контроль и разбор исключений. Разница до и после, умноженная на объем процесса, и есть реальная экономика проекта, а не абстрактный процент высвобожденного времени. Отдельно стоит следить за долей сценариев, закрытых без участия человека: если она растет от месяца к месяцу, изменение действительно масштабируется.</p> <h3>Что делать прямо сейчас</h3> <p>Универсального рецепта нет, но есть несколько работающих принципов.</p> <ul> <li><strong>Считать метрику до старта, а не после. </strong>Пропишите одну фразу с цифрой и сроком — например, «сократить время обработки заявки с 4 часов до 40 минут за 3 месяца», и отдельно укажите, в каком экономическом эффекте это должно выразиться: например, в снижении затрат на найм дополнительных сотрудников, росте лояльности клиентов или увеличении среднего чека. Назначьте человека, который отвечает именно за эти показатели, а не за факт запуска проекта.</li> <li><strong>Начинать с малого и наращивать масштаб. </strong>Берите один конкретный процесс, а не весь отдел целиком, и давайте пилоту <nobr>4-6</nobr> недель на одной команде. Если показатель из первого пункта сдвинулся — расширяйте на соседние процессы, если нет — меняйте гипотезу, а не бюджет.</li> <li><strong>Заниматься данными и процессами, а не только моделью.</strong> Перед запуском проверьте на практике: сможет ли сотрудник за один день найти все данные, нужные для этого сценария, в одном месте, а не в трех разных системах и переписке. Если нет — сначала наведите порядок здесь, а не в выборе модели или ИИ-инструментов.</li> <li><strong>Работать с командой, а не только с технологией. </strong>Назначьте внутри команды человека, который отвечает за процесс, и обсудите с сотрудниками до запуска, какие задачи берет на себя ИИ и что остается за ними: это снимает страх замены и превращает пилот в общий эксперимент, а не в решение, спущенное сверху.</li> <li><strong>Не привязывать пилот к покупке оборудования.</strong> Один из вариантов — арендовать готовую инфраструктуру с почасовой оплатой: специализированные ИИ-платформы уже дают доступ и к GPU-серверам, и к готовым инференс-движкам, и к инструментам для разработки и автоматизации без необходимости собирать всё самостоятельно. Так эксперимент можно закрыть без потерь, если гипотеза не подтвердится, или быстро масштабировать, если она сработала.</li> </ul> <p>Наконец, стоит возвращаться к проекту не только на старте, а регулярно: сверять метрики каждые несколько месяцев и честно решать, масштабировать решение, дорабатывать или закрывать проект, а не держать его в статусе вечного пилота. И, главное, считать не окупаемость нейросети саму по себе, а то, как она меняет весь процесс целиком, — именно здесь чаще всего и находится реальная экономика, которую пропускают 70% руководителей, разочарованных в ИИ сегодня.</p> <p> #IMAGE_235378#</p> Компании продолжают вкладывать миллионы в нейросети, но всё чаще признают: результата нет. Разбираемся, почему пилоты … article Евгений Мартынов, директор по информационным технологиям Рег.облака https://www.itweek.ru/themes/detail.php?ID=235369 Thu, 20 Aug 2026 00:00:00 +0300 <p><em>Организации должны переосмыслить не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать, считают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Проблема клиента с предоставленной ему услугой передается агенту искусственного интеллекта после первоначального общения с чат-ботом. Агент проверяет официальную документацию, в которой четко указано, что в ситуациях такого типа применяется политика A — так что именно эту политику агент применяет и здесь.</p> <p>Это довольно распространенная ситуация, с которой регулярно сталкиваются многие предприятия. Кроме того, многие компании надеются, что использование ИИ-агента может повысить производительность.</p> <p>Однако такого повышения производительности не произойдет, если корпоративная база знаний, на которую опирается агент, будет неполной, неверной или устаревшей. Например, в приведенном выше сценарии представьте, что отдел продаж в течение нескольких месяцев уже придерживается политики В, но не обновил официальную документацию. У них может быть некий документ, объясняющий это изменение и новую политику, но он невидим для агентов ИИ, если не является частью базы знаний, к которой они могут получить доступ.</p> <p>В результате агент уверенно принимает неверное решение для данного клиента. Однако это не ошибка агента, а недостаток системы организационных знаний. Агенты ИИ не создают проблем со знаниями, но они выявляют проблемы, с которыми сталкиваются организации.</p> <h3>Готовность к использованию людьми не означает готовность к использованию ИИ</h3> <p>Часто организации полагают, что самой большой проблемой при переходе агентов ИИ от пилотов к производству является совершенствование самой модели. Но более серьезное препятствие часто носит более приземленный характер, говорит Кубер Шарма, старший директор UiPath по маркетингу продуктов для корпоративного ИИ и автоматизации. «Разрыв, который я чаще всего наблюдаю между пилотом и производственным внедрением ИИ-агентов, заключается не в модели. Дело в знаниях», — поясняет он. Организации разрабатывают ИИ-агентов для действий на основе документации, но затем обнаруживают, что документация не была для этого подготовлена. Вместо этого, по словам Шармы, она был создана для людей, которые могут читать между строк, консультироваться с коллегой или применять контекст.</p> <p>За время своего существования организация тратит значительное количество времени и энергии на написание документации для сотрудников: руководств по интранету, внутренних вики, документов о политиках, соглашений об обслуживании клиентов, брошюр о продукции и т. д. Какими бы важными они ни были, эти документы часто бывают неполными. Например, документ может еще не быть обновлен, чтобы отразить новую политику или процедуру или изменения в отраслевых или государственных нормативных актах.</p> <p>Когда люди используют эту документацию для поддержки своей работы, они могут выявить пробелы или несоответствия и предоставить важный контекст для их устранения. Интерпретируя неоднозначность и консультируясь с коллегами, они могут найти информацию, которую документация не охватывает, или решить, что конкретный документ больше не актуален.</p> <p>Но по мере того, как организации заменяют или дополняют агентами ИИ рабочую деятельность, осуществляемую людьми, они все больше сталкиваются с проблемами из-за неоднозначности документации. ИИ не способен обеспечить контекст или интерпретацию неполных баз знаний, которые могут обеспечить люди, и это приводит к проблемам, когда агенты сталкиваются с противоречивыми политиками, использованием электронной почты или чата в качестве документации, недокументированными исключениями или крайними случаями, дублированием документации и устаревшими практиками.</p> <p>Даже если документация точна, ее формат может стать препятствием. Файлы, хранящиеся в формате PDF, в наборах слайдов, графических материалах или специализированных учебных пакетах, могут содержать ценные институциональные знания, но без их дополнительной доработки агенты ИИ не смогут их анализировать и строить свои действия на их основе.</p> <p>Чтобы добиться успеха, агентам ИИ требуется четкая организационная память, а не институциональная интуиция и неполная документация.</p> <h3>Институциональные знания выходят за рамки официальных документов</h3> <p>Для некоторых организаций обновление официальной документации может ограничиваться обновлением нескольких ключевых PDF-файлов. Это важно, но база знаний предприятия включает в себя гораздо более широкий спектр документов и информации. Утверждения, решения, исключения, пути эскалации, бизнес-контекст, эволюция политик и неформальные практики — все это также является институциональной информацией, даже если она не отражена в официальной документации.</p> <p>Чтобы сделать институциональные знания доступными для агентов ИИ, часто требуется нечто большее, чем просто указать им на существующие файлы. По словам Джеймса Крэнвелла, руководителя отдела продуктов компании 5app, бóльшая часть корпоративного контента была создана для людей, а не для систем ИИ. Часто специалисты организации в предметной области загружают свои знания в документы Word, наборы слайдов, графики или PDF-файлы, иногда используя специфический для компании жаргон, сокращения и аббревиатуры, которые агентам ИИ трудно интерпретировать. Поэтому по мере того, как организации внедряют все больше агентов ИИ, стандартизация и структурирование их ресурсов знаний становится все более важной задачей.</p> <p>Крэнвелл не понаслышке знаком с этой проблемой. Недавно его команда создала ИИ-агент, способный анализировать пакеты электронного обучения SCORM, чтобы пользователи могли переходить к определенному разделу курса, а не извлекать сам файл курса. Этот опыт подтверждает, что организациям часто приходится адаптировать свои существующие ресурсы знаний, прежде чем агенты ИИ смогут эффективно их использовать.</p> <p>Успешное включение других источников институциональных знаний в базу знаний, используемую агентами ИИ, гарантирует, что эти агенты смогут более успешно интегрироваться в рабочие процессы предприятия. Чем больше у агента будет доступа к политикам, процедурам и другой информации, на основе которой он принимает решения, тем более информированными и точными будут эти решения, и тем лучше агент сможет не просто извлекать информацию, но и продуктивно применять ее на практике.</p> <p>По словам Шармы, знания, необходимые для работы агента, должны быть не только всеобъемлющи, но и конкретны. Не надейтесь на то, что существующий организационный контекст будет ему понятен, советует он. Вместо этого в документах должно быть четко указано, что они охватывают, а что нет, кому они принадлежат и когда они в последний раз проверялись и валидировались. Такой уровень конкретики помогает агентам ИИ отличать авторитетную информацию от устаревших или неполных рекомендаций.</p> <h3>Когда институциональные знания устаревают</h3> <p>Все большее число организаций полагаются на ИИ-агентов, которые берут на себя работу, ранее выполнявшуюся людьми. По данным McKinsey, 88% организаций в настоящее время используют ИИ для выполнения по крайней мере одной бизнес-функции, по сравнению с 78% годом ранее. И, согласно PwC, 79% опрошенных говорят, что агенты ИИ уже внедряются на их рабочих местах.</p> <p>По мере того как эти агенты будут становиться все более распространенными, будут возникать и проблемы, связанные с использованием ими устаревшей, неполной или неверной базы знаний. Когда это происходит, проблема выходит за привычные рамки: если сотрудник сбит с толку документацией, с которой он знакомится, то он может, по крайней мере, обсудить это с коллегой или использовать для интерпретации свои суждения и прошлый опыт. Неэффективные или неправильные решения, принимаемые агентами ИИ из-за плохой документации, приводят к неправильной маршрутизации, неправильным утверждениям или отказам, несогласованному взаимодействию с клиентами и, возможно, тысячам автоматизированных действий, которые не должны были выполняться.</p> <p>Как только агент начинает действовать на основе неполной информации, возникают вопросы подотчетности, что делает управление особенно важным. Организации, которые успешно справляются с этой задачей, рассматривают управление знаниями не как документирование, а как часть операционной модели агента ИИ, говорит Шарма. Когда агент выдает неверный результат, команды должны знать, кому принадлежат знания, лежащие в его основе, когда они проверялись в последний раз и почему агент полагается на них.</p> <p>Надежное управление базой знаний, на основе которой принимаются агентные решения, может смягчить некоторые из этих проблем. Организациям следует прояснить ряд вопросов, касающихся информации, которую агенты ИИ используют для принятия решений:</p> <ul> <li> Кому принадлежат данные знания?</li> <li> Кто обновляет их? Как часто?</li> <li> Кто рассматривает и утверждает изменения?</li> <li> Когда документ или его часть устаревают, кто и как их удаляет?</li> <li> Когда официальная документация меняется, кто проводит аудит агентов ИИ, чтобы убедиться в понимании ими изменений?</li> </ul> <p>Без этих ответов организации рискуют разработать системы, автоматизирующие принятие неверных решений. «Агент уверенно выдает неверный ответ, основываясь на неверном источнике. Это хуже, чем отсутствие ответа. Это сбой системы управления, одобренный ИИ», — сказал Шарма.</p> <p>Ответы на эти вопросы и понимание всеми заинтересованными лицами важности согласования этих ответов с базой знаний компании помогут избежать проблем с документацией при внедрении ИИ-агентов. Цель состоит в том, чтобы официальные знания, подготовленные для агентов, всегда были актуальными, четко сформулированными, авторитетными, структурированными, управляемыми и объяснимыми.</p> <h3>Убедитесь, что корпоративный источник истины готов к использованию ИИ</h3> <p>Организации могут беспокоиться о том, что ИИ-агент не сможет должным образом разобраться в их бизнесе, но первым шагом должно стать обеспечение понимания бизнесом самого себя.</p> <p>Агенты ИИ не могут восполнить недостающий контекст или информацию так, как это могут сделать сотрудники. Они не могут согласовать противоречивые документы, вывести неписаные правила или признать, что «все знают», что процедура изменилась. Они принимают решения на основе институциональных знаний, предоставляемых организациями, и выявляют все слабые места или пробелы в этих знаниях. Предприятие, осознающее недостаточность своей базы знаний, получает неожиданную выгоду от того, что ему приходится сталкиваться с накопившимися несоответствиями и исправлять их, а также создавать систему управления, которая позволит ему продвигаться вперед с использованием более совершенной модели поддержания этих знаний.</p> <p>Подготовка институциональных знаний для ИИ — это задача управления контентом в дополнение к управленческому процессу. Организациям все чаще приходится переосмысливать не только то, что они документируют, но и то, как они структурируют, поддерживают и представляют эти знания, чтобы автоматизированные системы могли надежно их использовать.</p> Организации должны переосмыслить не только то, что они документируют, но и то, как они структурируют … article https://www.itweek.ru/themes/detail.php?ID=235376 Wed, 19 Aug 2026 14:24:22 +0300 <p>Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — решения для управления кластерами, расположенными в разных ЦОД, а также мажорной версии 3.0 встроенного модуля для развертывания сервисов в облаке Basis Automation Studio. Ключевыми изменениями релизов стали переработанная ролевая модель доступа пользователей, обновленная архитектура развертывания сервисов, новые инструменты управления ресурсами и углубление интеграции платформы с другими решениями экосистемы «Базис».</p> <p>Платформа Basis Dynamix Cloud Control предназначена для управления через единый портал частными и публичными облаками, построенными на базе различных платформ виртуализации — Basis Dynamix Enterprise, Basis Dynamix Standard, VMware vSphere и РУСТЭК.</p> <p>На смену встроенной ролевой модели в Basis Dynamix Cloud Control 5.6 пришла новая гибкая модель разграничения доступа, что позволяет администратору назначать права в точном соответствии с полномочиями пользователей. Переход на новую модель выполняется автоматически при обновлении инсталляции продукта: права пользователей мигрируют в новую структуру без ручной перенастройки. Вместе с новой моделью администраторы получили более удобные инструменты для работы с ролями, включая их клонирование — при копировании переносятся уровни доступа, права доступа и правила фильтрации исходной роли.</p> <p>В новой модели предусмотрены встроенные роли по умолчанию, готовые к использованию без дополнительной настройки. Поддерживается управление жизненным циклом пользовательских ролей для точечного предоставления необходимых прав на различные объекты. При архивировании учетной записи вместе с объектами доступа снимаются все связанные роли.</p> <p>В релизе 5.6 была существенно расширена функциональность сегментов Basis Dynamix Standard. Пользователям получили новые возможности, ранее уже доступные в других сегментах: поддержка сетей, роутеров, балансировщиков нагрузки, профилей безопасности и внешних систем хранения данных. Логика построения виртуальной сети стала более гибкой: маршрут по умолчанию на роутере создается автоматически, если пользователь не задал собственный. При этом в конфигурациях с несколькими роутерами разрешены удаление последнего порта роутера и отключение сети от роутера.</p> <p>Для облачных сегментов Basis Dynamix Enterprise в новом релизе была добавлена поддержка сервиса резервного копирования на базе Basis Virtual Protect — решения компании «Базис» для управления жизненным циклом резервных копий виртуальных машин. Администратор может подключить настроенный сервис к одному или нескольким сегментам Basis Dynamix Enterprise, для которых должны быть доступны инструменты резервного копирования. </p> <p>Автоматическая синхронизация изменений виртуальной инфраструктуры сегментов Basis Dynamix Enterprise дополнена операциями со снапшотами — созданием, восстановлением и удалением. Синхронизация в фоновом режиме помогает администратору поддерживать согласованность виртуальной инфраструктуры между платформой виртуализации и решением Basis Dynamix Cloud Control, что важно, например, при выполнении сервисных действий с серверами и дисками.</p> <p>Наконец, реализовано взаимодействие Basis Dynamix Cloud Control с платформой виртуализации Basis Dynamix Enterprise через учетную запись Basis Virtual Security — решения компании «Базис», предназначенного для защиты виртуальной инфраструктуры. </p> <p>В новом релизе Basis Dynamix Cloud Control особое внимание было уделено контролю над объёмом предоставляемых ресурсов, обеспечению предсказуемого потребления и оптимизации затрат. На уровне виртуального центра обработки данных (ВЦОД) введены лимиты и механизм согласования выделяемых ресурсов, дающие администраторам предсказуемый контроль над потреблением в рамках отдельных ВЦОД.</p> <p>Для облачных сегментов на платформе Basis Dynamix Enterprise реализовано управление коэффициентом и режимом переподписки виртуальных процессоров (vCPU), что позволяет администратору гибко регулировать плотность размещения виртуальных машин. Коэффициент переподписки определяет, сколько ядер vCPU будет приходиться на одно ядро физического процессора и отдельно указывается для каждого физического сервера. При отсутствии ограничений Basis Dynamix Cloud Control будет использовать для запуска виртуальных серверов любые узлы с достаточными ресурсами. При включенном режиме строгой переподписки виртуальные серверы не будут запускаться на физических узлах, если у тех недостаточно свободных ядер vCPU.</p> <p>Basis Automation Studio — это модуль Basis Dynamix Cloud Control, который представляет собой среду автоматизации развёртывания приложений и сервисов. С его помощью администратор платформы может управлять жизненным циклом облачных сервисов, работать с шаблонами и компонентами, публиковать готовые сервисы на витрине и предлагать их пользователям.</p> <p>Для Basis Automation Studio 3.0 одним из наиболее важных изменений стала смена архитектуры — модуль переведен на отказоустойчивую архитектуру в кластере Kubernetes. Компоненты Basis Automation Studio, включая контейнеры оркестратора и базу данных, работают в конфигурации высокой доступности: при выходе из строя отдельного узла нагрузка автоматически перераспределяется на оставшиеся узлы, работа платформы не прерывается. Для хранения общих данных используется распределенное отказоустойчивое хранилище, для базы данных — управление средствами оператора Kubernetes.</p> <p>Наряду с отказоустойчивостью появилось горизонтальное масштабирование: количество экземпляров ключевых сервисов задается при развертывании, что позволяет наращивать производительность платформы под растущую нагрузку без изменения ее архитектуры.</p> <p>Еще одним важным новшеством Basis Automation Studio 3.0 стало появление динамических провайдеров, которые предоставляют возможность создания динамических типов данных при заказе сервиса. Благодаря этому модуль может обращаться к внешним системам и возвращать в форму заказа вместо статичных полей актуальные данные, вычисляемые по пользовательским сценариям в изолированной среде выполнения.</p> <p>Динамические провайдеры отображаются на карточке домена и проекта. Внутри них дополнительно добавлен программный интерфейс управления динамическими типами провайдера для запуска пользовательских скриптов.</p> <p>Как и в Basis Dynamix Cloud Control, в модуле Basis Automation Studio 3.0 была переработана ролевая модель. Права доступа теперь задаются на уровне отдельных API-методов, сгруппированных по управляемым сущностям. Каждая роль привязана к области видимости: платформе, домену или проекту, — которая определяет предельный набор доступных действий. Пользователь привязывается к одной области видимости, но ему можно назначить несколько ролей, в том числе стандартных — в таком случае права доступа суммируются.</p> <p>«Приоритетными направлениями развития нашей облачной платформы Basis Dynamix Cloud Control остаются расширение возможностей управления виртуальной инфраструктурой и повышение совместимости облачного решения с другими продуктами экосистемы „Базиса“. В релизе 5.6 мы сделали несколько значительных шагов в обоих направлениях. Что касается нашего решения для управления облачными сервисами, перевод Basis Automation Studio на новую k8s-архитектуру позволит перемещать рабочую нагрузку без остановки работы продукта. Кроме того, для удобства работы с модулем мы внедрили динамические провайдеры и расширили возможности графического интерфейса платформы», — отметил Дмитрий Сорокин, технический директор компании «Базис».</p> Компания «Базис» (входит в ГК «РТК-ЦОД») объявила о выходе обновления Basis Dynamix Cloud Control 5.6 — … message https://www.itweek.ru/themes/detail.php?ID=235375 Wed, 19 Aug 2026 14:20:12 +0300 <p>Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для своевременного выявления и реагирования на угрозы, связанные с компрометацией айдентити. Обновление расширяет сценарии применения многофакторной аутентификации, улучшает пользовательский опыт при работе в консоли администрирования и упрощает развертывание решения в корпоративной инфраструктуре.</p> <p>Сегодня для защиты корпоративной инфраструктуры недостаточно контролировать только доступ пользователя в систему. Не менее важно отслеживать дальнейшую активность учетных записей и своевременно реагировать на подозрительные действия. Эти возможности получили развитие в новой версии Indeed ITDR 2.2.</p> <p>Одно из ключевых нововведений в Indeed ITDR 2.2 — подтверждение дополнительного фактора входа с помощью одноразовых паролей (OTP), основанных на времени (time-based one-time passwords, TOTP). Обновление расширяет интеграцию с Indeed Access Manager и позволяет использовать существующую инфраструктуру аутентификации в сценариях Indeed ITDR.</p> <p>Поддержка ТOTP особенно актуальна для организаций с закрытыми инфраструктурами без доступа к внешним сетям, где использование push-уведомлений невозможно. Кроме того, пользователи могут применять сторонние приложения-аутентификаторы, поддерживающие стандарт TOTP.</p> <p>Ввод одноразового пароля выполняется через легковесное приложение, устанавливаемое на рабочих станциях под управлением Windows. Оно своевременно отображает запрос на подтверждение дополнительного фактора. В рамках дальнейшего развития продукта планируется добавить поддержку одноразовых паролей через SMS, электронную почту и физические носители.</p> <p>В версии 2.2 компания «Индид» значительно расширила возможности работы с журналом событий доступа. На странице «События» консоли администрирования появилась гибкая система фильтрации по пользователю, ресурсу, протоколу, IP-адресу и контроллеру домена. Также улучшен интерфейс фильтрации по времени возникновения события и оптимизировано хранение данных, что повышает производительность поиска.</p> <p>Обновленный интерфейс упрощает работу с Indeed ITDR и позволяет быстрее находить необходимые события при анализе подозрительной активности, расследовании инцидентов и оценке рисков безопасности. </p> <p>Другие изменения Indeed ITDR делают более удобным развертывание продукта в инфраструктурах, где интеграция с Indeed Access Manager не требуется.</p> <p>Компонент Indeed Key Server теперь можно установить на отдельный узел с помощью единого сценария установки. Это упрощает развертывание сервера в демилитаризованной зоне (DMZ) и избавляет администраторов от необходимости вручную изменять конфигурационные файлы.</p> <p>В новой версии расширен набор сценариев обнаружения атак. Indeed ITDR теперь выявляет такие техники, как Golden PAC и SAM Account Spoofing, что позволяет эффективнее обнаруживать попытки компрометации доменной инфраструктуры.</p> <p>Кроме того, улучшена совместимость с различными вариантами TLS-сертификатов, включая сертификаты LDAPS без расширения SAN, а также сертификаты с именем субъекта в формате Distinguished Name.</p> <p>«Мы последовательно улучшаем Indeed ITDR, расширяя сценарии внедрения продукта и добавляя новые возможности детектирования. Наша задача — помочь организациям своевременно реагировать на угрозы, связанные с учетными данными, не перестраивая существующую инфраструктуру. При этом для нас важно обеспечить удобство работы как для пользователей, так и для специалистов по информационной безопасности и администраторов. Последние обновления отражают наиболее частые пожелания, которые мы получаем в процессе внедрения наших продуктов», — отметил Лев Овчинников, руководитель продукта Indeed ITDR в компании «Индид».</p> Компания «Индид» выпустила новую версию Indeed Identity Threat Detection and Response (Indeed ITDR) 2.2 — продукта для … message https://www.itweek.ru/themes/detail.php?ID=235374 Wed, 19 Aug 2026 14:16:20 +0300 <p>Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением стал встроенный Remote Access VPN (RA VPN), который позволяет организовать защищенный удаленный доступ пользователей к корпоративной сети. Кроме того, в новой версии расширены возможности маршрутизации и построения отказоустойчивых сетей, усовершенствованы управление политиками безопасности и удобство эксплуатации продукта.</p> <p>PT NGFW продолжает развиваться как единая платформа сетевой безопасности для высоконагруженных и территориально распределенных инфраструктур. Главная функция версии 1.11, Remote Access VPN, обеспечивает безопасное удаленное подключение сотрудников к внутренним ИТ-ресурсам организации непосредственно средствами межсетевого экрана, без внедрения отдельного VPN-решения. Настройка и управление параметрами RA VPN также осуществляется из единого окна PT NGFW.</p> <p>Благодаря поддержке раздельного туннелирования, через VPN можно направлять только корпоративный трафик пользователей, оставляя доступ к публичным и облачным сервисам напрямую через Интернет. Это снижает нагрузку на VPN-шлюз и каналы связи, повышая скорость и комфорт работы сотрудников. При этом трафик удаленных пользователей проходит через полный стек механизмов защиты межсетевого экрана, то есть организация может применять к удаленным подключениям те же политики безопасности, что и к сетевому взаимодействию внутри корпоративной инфраструктуры. Аутентификация удаленных пользователей происходит через RADIUS-сервер, что делает возможным не только централизованное управление правами доступа, но и применение второго фактора.</p> <p>Помимо защищенного удаленного доступа, PT NGFW 1.11 получил ряд возможностей, ориентированных на потребности крупных компаний с высоконагруженными и распределенными сетями. Среди них — поддержка технологии ECMP (Equal Cost Multi-Path), которая позволяет одновременно использовать несколько равнозначных маршрутов для передачи трафика. Это помогает эффективнее использовать пропускную способность каналов связи и сохранять передачу трафика при отказе одного из них.</p> <p>Кроме того, PT NGFW 1.11 расширяет сценарии подключения удаленных площадок и список совместимых сетевых устройств за счет возможности создания туннелей GRE и GRE over IPsec, в том числе с применением динамической маршрутизации.</p> <p>Еще одной возможностью, востребованной в высокопроизводительных сетях и центрах обработки данных, стала поддержка Jumbo Frames — увеличенного размера Ethernet-кадров. Благодаря этому можно передавать большие объемы данных меньшим количеством пакетов, снижая накладные расходы на их обработку. Максимальный размер пакета можно настраивать как для всего устройства, так и для отдельных интерфейсов. В совокупности новые возможности маршрутизации, туннелирования и работы с трафиком позволяют адаптировать PT NGFW к более широкому спектру архитектур крупных корпоративных сетей.</p> <p>В новой версии также появились функции, направленные на повышение удобства повседневной эксплуатации PT NGFW. В частности, добавлена поддержка подстановочных символов (wildcards) при настройке URL-фильтрации, благодаря чему весь процесс становится для администраторов быстрее и проще. Управление маршрутизацией тоже стало комфортнее: пользователь может настроить профили проверки доступности узлов, и в случае необходимости трафик автоматически, без ручного вмешательства пользователя переключится на резервный канал.</p> <p>«Мы продолжаем развивать PT NGFW с учетом обратной связи от заказчиков и их ежедневного опыта эксплуатации продукта. Для нас важно, чтобы межсетевой экран одинаково эффективно решал и стратегические задачи, такие как организация защищенного удаленного доступа или построение масштабной отказоустойчивой сетевой архитектуры, так и повседневные задачи администратора — от настройки политик до диагностики и работы с журналами», — отметил Антон Кузнецов, CPO компании «ТризТех».</p> Компания «ТризТех» представила новую версию межсетевого экрана нового поколения — PT NGFW 1.11. Главным нововведением … message https://www.itweek.ru/themes/detail.php?ID=235373 Wed, 19 Aug 2026 14:10:57 +0300 <p>С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок. Для транспортных компаний это означает переход от бумажного документооборота к работе с электронными документами непосредственно на маршруте. Saby TMS позволяет оформлять и обрабатывать электронные транспортные документы и поддерживает удобный сценарий их подписания — с помощью Рутокен ЭЦП 3.0 NFC. Устройство Рутокен разработано и выпускается компанией «Актив».</p> <p>Раньше сотруднику, которому необходимо подписать ЭТрН КЭП, требовался компьютер или специальный переходник для подключения токена к смартфону. С Рутокен ЭЦП 3.0 NFC достаточно иметь смартфон с NFC и мобильное приложение Saby TMS.</p> <p>Сотрудник прикладывает Рутокен к смартфону и подписание документа происходит «на борту» устройства Рутокен, без копирования ключа подписи в память мобильного устройства. Такой сценарий особенно удобен водителям и экспедиторам, которым важно работать с документами прямо на маршруте, а не возвращаться в офис.</p> <p>«Для перевозчика важно, чтобы электронный документооборот не привязывал водителя к компьютеру или офису. Все действия с ЭТрН — от получения документа до его подписания — должны выполняться там, где происходит перевозка: на погрузке, выгрузке или в пути. Поддержка Рутокен ЭЦП 3.0 NFC в Saby TMS дает компаниям еще один удобный способ организовать такой мобильный сценарий и при этом использовать привычную КЭП», — отметил Денис Малышев, руководитель направления автоматизации логистики Saby TMS.</p> <p>«Мы видим тренд на мобильное подписание ЭТрН с использованием защищенных ключевых носителей. Рутокен ЭЦП 3.0 NFC позволяет перенести привычный сценарий работы с КЭП со стационарного компьютера на смартфон: достаточно приложить Рутокен к мобильному устройству с NFC для подписания документа. Совместимость с Saby TMS позволит использовать этот подход непосредственно в процессах грузоперевозок и дать бизнесу большую гибкость без компромиссов в безопасности», — поделился Анфимов Павел, заместитель директора по управлению продуктами, компания «Актив».</p> <p>В Saby TMS транспортные компании ведут основные документы — транспортные накладные, путевые листы, заказы на перевозку — прямо во время рейса.</p> <p>Для подписания через NFC понадобятся: смартфон с поддержкой NFC (iOS или Android), мобильное приложение Saby TMS и Рутокен ЭЦП 3.0 NFC с сертификатом и ключами электронной подписи.</p> С 1 сентября 2026 года электронные транспортные накладные (ЭТрН) становятся обязательными для большинства перевозок … message https://www.itweek.ru/themes/detail.php?ID=235372 Wed, 19 Aug 2026 13:09:40 +0300 <p><em>MWS Cloud (входит в МТС Web Services) проанализировала требования к вычислительной инфраструктуре для запуска ведущих мировых и российских больших языковых моделей. По оценке компании, средняя стоимость минимального набора ускорителей Nvidia для запуска одной модели выросла с 13,7 млн. рублей в 2025 году до 38,8 млн. рублей в 2026 году — в 2,8 раза.</em></p> <p>В анализ вошли популярные открытые модели, выпущенные весной и летом соответствующего года. Для 2025 года рассматривались Kimi K2, gpt-oss-120b, Gemma 3 27B, GLM-4.5V, Qwen3 235B и российская Cotype Pro 2. Для 2026 года — Kimi K3, Qwen3.5 397B, DeepSeek-V4-Pro, DeepSeek-V4-Flash, GLM-5.2, Gemma 4 и Cotype Pro 3.</p> <p>Расчёт сделан для минимального количества видеокарт, необходимого для запуска модели и обработки одного запроса максимального заявленного размера. В стоимость включены серверы с GPU и коммутаторы к ним.</p> <table> <tbody> <tr> <td> <p><strong>Год</strong></p> </td> <td> <p><strong>Наиболее популярный GPU</strong></p> </td> <td> <p><strong>Другие GPU</strong></p> </td> </tr> <tr> <td> <p>2025</p> </td> <td> <p>H100 — для трёх из шести моделей</p> </td> <td> <p>H200 — для двух моделей; A100 — для одной</p> </td> </tr> <tr> <td> <p>2026</p> </td> <td> <p>H200 — для трёх из семи моделей</p> </td> <td> <p>B300 — для двух моделей; H100 и A100 — ещё для двух</p> </td> </tr> </tbody> </table> <p><strong>Рейтинг моделей по стоимости запуска в 2025 году</strong></p> <table> <tbody> <tr> <td> <p><strong>Место</strong></p> </td> <td> <p><strong>Модель</strong></p> </td> <td> <p><strong>Количество параметров</strong></p> </td> <td> <p><strong>Минимальная конфигурация</strong></p> </td> <td> <p><strong>Стоимость</strong></p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>Kimi K2</p> </td> <td> <p>1 трлн (32 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 35 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>Qwen3</p> </td> <td> <p>235 млрд. (22 млрд. активных)</p> </td> <td> <p>4 × H200 141 Гб</p> </td> <td> <p>примерно 18 млн. рублей</p> </td> </tr> <tr> <td> <p>3</p> </td> <td> <p>GLM-4.5V</p> </td> <td> <p>106 млрд. (12 млрд. активных)</p> </td> <td> <p>минимум 4 × H100 80 Гб</p> </td> <td> <p>примерно 15 млн. рублей</p> </td> </tr> <tr> <td> <p>4</p> </td> <td> <p>Gemma 3</p> </td> <td> <p>27 млрд</p> </td> <td> <p>2 × H100 80 Гб</p> </td> <td> <p>примерно 7,5 млн. рублей</p> </td> </tr> <tr> <td> <p>5</p> </td> <td> <p>gpt-oss</p> </td> <td> <p>117 млрд. (5,1 млрд. активных)</p> </td> <td> <p>1 × H100 80 Гб</p> </td> <td> <p>более 3,5 млн. рублей</p> </td> </tr> <tr> <td> <p>6</p> </td> <td> <p>Cotype Pro 2</p> </td> <td> <p>32 млрд</p> </td> <td> <p>1 × A100 80 Гб</p> </td> <td> <p>примерно 3 млн. рублей</p> </td> </tr> </tbody> </table> <p><strong>Рейтинг моделей по стоимости запуска в 2026 году</strong></p> <table> <tbody> <tr> <td> <p><strong>Место</strong></p> </td> <td> <p><strong>Модель</strong></p> </td> <td> <p><strong>Количество параметров</strong></p> </td> <td> <p><strong>Минимальная конфигурация</strong></p> </td> <td> <p><strong>Стоимость</strong></p> </td> </tr> <tr> <td> <p>1</p> </td> <td> <p>Kimi K3</p> </td> <td> <p>2,8 трлн (104 млрд. активных)</p> </td> <td> <p>8 × B300 288 Гб</p> </td> <td> <p>примерно 80 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>Qwen3.5</p> </td> <td> <p>397 млрд. (17 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>DeepSeek-V4-Pro</p> </td> <td> <p>1,6 трлн (49 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>2</p> </td> <td> <p>GLM-5.2</p> </td> <td> <p>744 млрд. (около 40 млрд. активных)</p> </td> <td> <p>8 × H200 141 Гб</p> </td> <td> <p>примерно 55 млн. рублей</p> </td> </tr> <tr> <td> <p>5</p> </td> <td> <p>DeepSeek-V4-Flash</p> </td> <td> <p>284 млрд. (13 млрд. активных)</p> </td> <td> <p>1 × B300 288 Гб</p> </td> <td> <p>примерно 10 млн. рублей</p> </td> </tr> <tr> <td> <p>6</p> </td> <td> <p>Gemma 4</p> </td> <td> <p>31 млрд</p> </td> <td> <p>2 × H100 80 Гб</p> </td> <td> <p>примерно 7,5 млн. рублей</p> </td> </tr> <tr> <td> <p>7</p> </td> <td> <p>Cotype Pro 3</p> </td> <td> <p>27 млрд</p> </td> <td> <p>1 × A100 80 Гб</p> </td> <td> <p>примерно 3 млн. рублей</p> </td> </tr> </tbody> </table> <p>Новые LLM становятся более мощными: они лучше справляются со сложными задачами и могут учитывать больше информации в одном запросе. Однако для этого им требуется больше памяти и более производительные GPU. При этом растёт и стоимость самих видеокарт, поэтому развёртывание моделей обходится дороже.</p> <p>Отдельно MWS Cloud оценила возможные конфигурации на китайских ускорителях Huawei Ascend 910B. Возможность запуска на них подтверждена не для всех рассмотренных LLM: в выборке 2025 года подтверждение есть для трёх из шести моделей, в 2026 году — для пяти из семи.</p> <p>Среди моделей с подтверждённой или экспериментально подтверждённой поддержкой Huawei в 2025 году в среднем требовалось 10,7 ускорителя Ascend 910B, а в 2026 году — 13,6. Официальной цены на данные GPU нет, но, по оценкам, она может составлять от половины до двух третей стоимости сопоставимых GPU Nvidia.</p> <p>«Цены на GPU в России во многом зависят от мирового рынка: глобальная гонка в области ИИ увеличивает спрос на вычислительные мощности и поддерживает рост стоимости ускорителей. По данным исследования MWS Cloud, 47% респондентов ожидают удорожания GPU-ресурсов в ближайшие 12 месяцев, а 45% считают, что их значение для бизнеса будет расти. Развёртывать крупные модели на собственной инфраструктуре становится дороже, однако единого ценового предела, после которого рынок потеряет интерес к ИИ, нет: если покупка оборудования перестаёт окупаться, компании выбирают более компактные модели, оптимизируют вычисления или переходят в облако, где можно платить только за фактически используемые мощности. Один из индикаторов этого сдвига — рост облачного потребления ИИ-моделей: по оценке MWS Cloud, в первом полугодии 2026 года потребление китайских LLM российскими компаниями на платформах MWS GPT Model Hub и MWS GPT более чем в 11 раз превысило показатель за весь 2025 год», — отметил генеральный директор MWS Павел Воронин</p> MWS Cloud (входит в МТС Web Services) проанализировала требования к вычислительной инфраструктуре для запуска ведущих … message https://www.itweek.ru/themes/detail.php?ID=235371 Wed, 19 Aug 2026 11:57:58 +0300 <p><em>Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир, наблюдаемая в последние годы, в 2025 году имела продолжение — снова выявлено очевидное снижение продаж на рынках недружественных стран. А вот столь же очевидного увеличения реализации продуктов и услуг в дружественных странах пока не видно. В то же время, на переохлажденном российском ИТ-рынке с возросшей налоговой нагрузкой компаниям становится слишком тесно. В такой ситуации логично предположить их движение в тех направлениях, которые открыты для международной экспансии.</em></p> <p>Направление в сторону недружественных стран сложно назвать перспективным. При всем желании российских компаний-разработчиков ПО сохранить продажи в Европе и Северной Америке, западные политики без устали работают над созданием непреодолимых для них препятствий. Многие их задумки реализуются, хотя при этом западные страны лишают свои предприятия и граждан доступа к качественным услугам и продуктам.</p> <p>По итогам 2025 года продажи отечественных софтверных компаний на рынках недружественных стран сократились примерно на 40% до ₽70 млрд. Сейчас страны Европы и США обеспечивают 2,4% совокупной выручки всей индустрии разработки ПО. При этом доля компаний, имеющих продажи в недружественных странах, намного больше — 14,3% от всех опрошенных компаний. Для Европы этот показатель равен 9,9%, а для США и Канады — 8,8% (в 2024 г. было 14,2% и 11,4% соответственно).</p> <p>Однако дальнейший уход с рынков западных стран столь же массово, как в предыдущие годы, компании не планируют. Сохранить присутствие на рынке Северной Америки в 2026 году рассчитывает 9,2%, что чуть больше, чем было по итогам 2025 года. Не исключено, что шансы остаться на одном из крупнейших рынков мира повысились, когда респонденты увидели потепление отношений между Россией и США после встречи в Анкоридже. Такой же эффект произвела в свое время победа Дональда Трампа на американских президентских выборах. Он вступил в должность в январе 2025 года, и вскоре стало известно о планах его встречи с Президентом РФ В.В. Путиным, которая состоялась в августе. С Европой все было хуже, ведь от них шли сигналы только на еще больший разрыв.</p> <p>Продажи в дружественных странах дальнего зарубежья в 2025 году в рублях не изменились и составили примерно ₽170 млрд. При этом доля этих продаж в совокупной выручке софтверных компаний упала — с 6,8% до 6,1%. Укрепление российской национальной валюты по отношению к доллару не позволило нарастить выручку в рублевом выражении. Однако в долларовом выражении продажи в дружественные страны все же увеличились примерно на 10%. Это касается как всего экспорта софтверных компаний, так и их продаж на рынках дружественных стран.</p> <p>Ближнее зарубежье обеспечило по итогам 2025 года 10,2% совокупной выручки российских разработчиков ПО. Годом ранее его доля была чуть меньше — 9,8%. Продажи на постсоветском пространстве выросли примерно на <nobr>18-19%</nobr> в рублевом выражении (до ₽285 млрд) и примерно на 32% в долларах ($3,4 млрд). Указали на наличие продаж в этих странах 36,1% опрошенных компаний. На данный момент Ближнее зарубежье обеспечивает более половины экспорта российских софтверных компаний.</p> <p><strong>Распределение продаж российских софтверных компаний по группам рынков в <nobr>2021-2025</nobr> годы</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2021</p> </td> <td> <p>2022</p> </td> <td> <p>2023</p> </td> <td> <p>2024</p> </td> <td> <p>2025</p> </td> </tr> <tr> <td> <p>Россия</p> </td> <td> <p>52,5%</p> </td> <td> <p>65,6%</p> </td> <td> <p>76,2%</p> </td> <td> <p>78,6%</p> </td> <td> <p>81,3%</p> </td> </tr> <tr> <td> <p>Ближнее зарубежье</p> </td> <td> <p>13,45%</p> </td> <td> <p>11,5%</p> </td> <td> <p>10,2%</p> </td> <td> <p>9,8%</p> </td> <td> <p>10,2%</p> </td> </tr> <tr> <td> <p>Россия и Ближнее зарубежье</p> </td> <td> <p>65,95% </p> </td> <td> <p>77,1%</p> </td> <td> <p>86,35%</p> </td> <td> <p>88,4%</p> </td> <td> <p>91,5%</p> </td> </tr> <tr> <td> <p>Дальнее зарубежье:</p> </td> <td colspan="5"> </td> </tr> <tr> <td> <p>— недружественные страны (до 2022 г. «Западный мир»)</p> </td> <td> <p>25,25%</p> </td> <td> <p>12,5%</p> </td> <td> <p>7,6%</p> </td> <td> <p>4,8%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>— дружественные страны (до 2022 г. «Новые рынки»)</p> </td> <td> <p>8,8%</p> </td> <td> <p>10,4%</p> </td> <td> <p>6,05%</p> </td> <td> <p>6,8%</p> </td> <td> <p>6,1%</p> </td> </tr> </tbody> </table> <p>Согласно прогнозу, основанному на планах опрошенных компаний, по итогам 2026 года российские софтверные компании увеличат свое присутствие с реальными продажами почти на всех рынках. Предполагается, что даже в США будут продавать свои продукты и услуг больше компаний, чем было в 2025 году. Падение присутствия российских экспортеров прогнозируется только на рынке Европы. Прогнозируя расширение географии и рост экспорта, необходимо признать, что опыт предыдущих лет показывает, что ожидания компаний относительно роста экспорта часто оказываются несколько завышенными.</p> <p><strong>Присутствие российских компаний на зарубежных рынках в 2025 году с прогнозом на 2026 год, %</strong> <strong>опрошенных компаний</strong></p> <table> <tbody> <tr> <td> </td> <td> <p>2025 г.</p> </td> <td> <p>2026 г. (прогноз)</p> </td> </tr> <tr> <td> <p>Ближнее зарубежье</p> </td> <td> <p>36,1%</p> </td> <td> <p>40,5%</p> </td> </tr> <tr> <td> <p>Казахстан</p> </td> <td> <p>22,1%</p> </td> <td> <p>25,2%</p> </td> </tr> <tr> <td> <p>Белоруссия</p> </td> <td> <p>20,7%</p> </td> <td> <p>24,8%</p> </td> </tr> <tr> <td> <p>Узбекистан</p> </td> <td> <p>15,0%</p> </td> <td> <p>18,7%</p> </td> </tr> <tr> <td> <p>Европа (без России и Ближнего зарубежья)</p> </td> <td> <p>9,9%</p> </td> <td> <p>8,5%</p> </td> </tr> <tr> <td> <p>США/Канада</p> </td> <td> <p>8,8%</p> </td> <td> <p>9,2%</p> </td> </tr> <tr> <td> <p>Южная и Восточная Азия</p> </td> <td> <p>7,5%</p> </td> <td> <p>7,8%</p> </td> </tr> <tr> <td> <p>— Китай</p> </td> <td> <p>3,1%</p> </td> <td> <p>3,4%</p> </td> </tr> <tr> <td> <p>— Индия</p> </td> <td> <p>5,4%</p> </td> <td> <p>6,1%</p> </td> </tr> <tr> <td> <p>— Вьетнам</p> </td> <td> <p>1,7%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>— Индонезия</p> </td> <td> <p>2,0%</p> </td> <td> <p>3,1%</p> </td> </tr> <tr> <td> <p>Ближний Восток</p> </td> <td> <p>6,5%</p> </td> <td> <p>7,8%</p> </td> </tr> <tr> <td> <p>Южная и Центральная Америка</p> </td> <td> <p>2,7%</p> </td> <td> <p>3,1%</p> </td> </tr> <tr> <td> <p>Бразилия</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Мексика</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,0%</p> </td> </tr> <tr> <td> <p>Аргентина</p> </td> <td> <p>2,0%</p> </td> <td> <p>2,4%</p> </td> </tr> <tr> <td> <p>Африка</p> </td> <td> <p>3,1%</p> </td> <td> <p>3,7%</p> </td> </tr> <tr> <td> <p>Австралия/Новая Зеландия</p> </td> <td> <p>1,4%</p> </td> <td> <p>1,7%</p> </td> </tr> </tbody> </table> <p>Несмотря на все препятствия, по итогам 2026 г. зарубежные продажи российских софтверных компаний все же могут вырасти более чем на 10% в долларовом выражении (с учетом той выручки, которая может остаться за пределами России).</p> <p>Однако для достижения уровня мировой конкурентоспособности, требующего огромных инвестиций, доходов от российского рынка будет недостаточно, и к нему необходимо будет прибавить выручку экспорта, которая должна быть как минимум, в разы больше, чем текущий доход от зарубежных продаж. По результатам исследования РУССОФТ, в 2025 году объем зарубежных продаж составил $6,3 млрд, а по итогам 2026 г. может достигнуть $7 млрд. При имеющемся темпе роста преодолеть планку в $40 млрд. удастся не ранее 2040 года, а к этому времени нынешние ориентиры уже будут не актуальны.</p> <p>Для наращивания экспорта можно рассчитывать, в первую очередь, на рост продаж на Ближнем зарубежье. Однако, хотя потенциал этого рынка еще не исчерпан, он в любом случае не принесет десятки миллиардов долларов. Для сравнения, один только индийский рынок может обеспечить продажи на порядок больше, чем все постсоветское пространство. Перспективными для освоения являются также рынки стран АСЕАН, прежде всего — Индонезии и Вьетнама. Более активной работе на Ближнем Востоке может помешать война. Большой интерес представляют страны Латинской Америки, но транспортные расходы и риски освоения еще непознанных рынков слишком велики.</p> <p>Для обеспечения прорыва на рынках дружественных стран необходимо устранять проблемы экспортеров, вызванные повышением налоговой нагрузки, которая к тому же может и не дать дополнительных поступлений в бюджет. Необходимо также повышать эффективность государственной поддержки экспорта ПО и услуг по его разработке, которую сейчас сложно признать высокой. До сих пор он не является приоритетом ни одной государственной программы и потому не может пользоваться финансовыми мерами поддержки инструментов Российского экспортного центра (кредиты покупателям, страхование поставок и предоставление гарантий Росэксимбанка для экспортных поставок).</p> <p>Стоит отметить, что сейчас отсутствуют показатели эффективности государственной политики в области развития ИТ-экспорта, поэтому приходится делать только общие предположения. Опрос РУССОФТ в рамках ежегодного Исследования софтверной индустрии показывает, что компании, которые уже присутствуют на зарубежных рынках, оценивают «Стимулирование экспорта ИТ государственными структурами и институтами» в целом удовлетворительно, но не очень высоко, даже в сравнении с другими направлениями государственной поддержки. В 2025 году опрошенные компании в среднем оценили стимулирование экспорта государством на 3,15 балла по <nobr>5-балльной</nobr> системе, а при опросе в 2026 году этот показатель снизился до 3,01.</p> <p>Чтобы обеспечить рост зарубежных продаж до величины $40 млрд, необходимо начать со сбора полной информации о том, чего ждут экспортеры от государства и что их не устраивает. Затем уже формулировать или корректировать стратегию комплексной поддержки ИТ-экспорта, и прежде всего — признать экспорт ПО и услуг в качестве приоритета государственной поддержки экспорта в одной из Национальных программ развития.</p> <p>В принципе, проблемы на западных рынках в том или ином виде можно было предположить лет 15 назад, как и необходимость наращивания продаж в развивающихся странах для обеспечения технологического суверенитета. Не хватало стратегического видения и системного критического анализа. РУССОФТ в своих отчетах и пресс-релизах предлагал уделять больше внимания рынкам развивающихся стран, начиная с 2008 года. Современная ситуация толкает нас к тому, чтобы совместными усилиями с государственными структурами сформулировать стратегию развития экспорта софтверной индустрии и ИТ-экспорта в целом и закрепить за Россией статус одного из мировых технологических лидеров.</p> Географическая переориентация российских компаний-разработчиков ПО с недружественного на дружественный мир … message https://www.itweek.ru/themes/detail.php?ID=235368 Wed, 19 Aug 2026 09:30:08 +0300 <p><em>Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому, что организации пытаются перейти к оркестрации до того, как моделирование заслужит операционное доверие, пишет в корпоративном блоге Сара Ли, старший директор </em><em>IDC</em> <em>по исследованиям ИТ-стратегий в производстве.</em></p> <p>Цифровые двойники превращаются из инструментов визуализации в операционную основу физического искусственного интеллекта на производственном участке, и этот термин теперь охватывает две возможности, которые часто рассматриваются как одно целое. <em>Моделирование</em> подтверждает изменения до того, как они достигнут производства. <em>Оркестрация</em> координирует выполнение в реальном времени машинами, системами ИИ и работниками.</p> <p>Какую возможность производитель создаст первой и насколько она будет обоснована, прежде чем перейти ко второй, часто определяет масштабируемость программы.</p> <p>Согласно отчету IDC «Industry Market Trends: Worldwide Manufacturing, 2026», примерно 57% производственных предприятий имеют инициативы в области ИИ, застрявшие на стадии проверки концепции, при этом менее половины демонстрируют измеримые результаты.</p> <p>Программы реализации цифровых двойников находятся в той же ситуации.</p> <h3>Моделирование: проверка изменений до того, как они достигнут производственного цеха</h3> <p>В этой роли цифровые двойники моделируют поведение процессов, производительность оборудования и конфигурации продукции, сочетая физические и основанные на данных модели, а также гибридные подходы, объединяющие инженерный опыт с операционными данными. Традиционная аналитика объясняет, что уже произошло. Моделирование позволяет производителям изучить, что может произойти дальше — это становится все более важным, поскольку автоматизация и роботизация повышают стоимость неудачных изменений.</p> <p>Сценарии применения различаются в зависимости от отраслевой структуры. Процессные производства моделируют отдельные технологические операции и переходы между партиями — прогнозируют производительность линий отбеливания на целлюлозно-бумажных комбинатах, моделируют загрязнения теплообменников на химических заводах или симулируют ферментацию в производстве напитков. Дискретные производства работают на уровне ячеек и линий: виртуальный ввод в эксплуатацию роботизированных ячеек до прибытия оборудования на место, балансировка времени такта при сборке смешанных моделей и генерация синтетических данных для обучения моделей визуального контроля.</p> <p>Возможности одинаковые, единицы анализа разные. Программы, заимствующие эталонную архитектуру с не той стороны этого разделения, как правило, застревают на структуре данных задолго до того, как застрянут на моделировании.</p> <h3>Оркестрация: превращение интеллекта в скоординированные действия</h3> <p>В этой роли цифровые двойники объединяют данные реального времени с датчиков, контрольных систем и систем управления производственными процессами для координации решений между машинами, агентами ИИ и работниками. Области применения включают координацию парков автономных мобильных роботов (AMR) и автоматизированных транспортных средств (AGV), динамическое балансирование производственных линий, управление энергетическими нагрузками в системах коммунального хозяйства и диспетчеризацию мероприятий по техническому обслуживанию или контролю качества в зависимости от изменяющихся условий.</p> <p>По мере внедрения агентного ИИ в производственную среду оркестрация становится средой выполнения, определяющей, какой агент действует, когда и в каких границах. Производители уже консервативно устанавливают эти границы.</p> <p>Согласно опросу IDC «2026 Agentic AI Functional Use», примерно 43% респондентов из производственной отрасли сообщают, что их агенты либо не обладают полномочиями по принятию решений, либо требуют одобрения человека для каждого решения. Только 8,5% допускают полную автономию по любому критически важному вопросу. В то же время 62,5% сообщают, что расширение автономии агентов находится в стадии активного рассмотрения.</p> <p>Устранение этого разрыва — это та работа, которую должна выполнить оркестрация.</p> <h3>Почему последовательность не является необязательной</h3> <p>Моделирование отдает приоритет точности прогнозирования и экспериментам в автономном режиме. Оркестрация отдает приоритет задержке, надежности и интеграции с системами управления и выполнения. Объединение их в единую программу обычно означает, что один набор требований уступает другому, и редко бывает очевидно заранее, какой именно.</p> <p>Доверие не предоставляется по запросу. Операторам и инженерам необходимы доказательства того, что модель отражает реальные условия работы предприятия, прежде чем они начнут действовать в соответствии с ее рекомендациями, и задолго до того, как они позволят агенту действовать от их имени. Трех ложных срабатываний за квартал обычно достаточно, чтобы операторы перестали открывать дашборд.</p> <p>Искушение перейти непосредственно к оркестрации понятно. Координация роботов, агентов ИИ и производственных систем обещает видимые операционные преимущества. Но без проверенного цифрового представления производства организации рискуют ускорить принятие решений, которым они еще не научились доверять.</p> <p>Программы, дающие результаты, начинаются с принятия операционного решения, а не с выбора технологии. Независимо от того, является ли целью выход годной продукции с первого раза, время переналадки, доступность активов или энергоемкость, это решение принимается в первую очередь. Что именно должен обеспечивать цифровой двойник?</p> <h3>От моделей мира к цифровым двойникам и физическому ИИ</h3> <p>По мере того, как производители готовятся к внедрению физического ИИ, различие между общим интеллектом и оперативным интеллектом становится все более важным.</p> <p>Модели мира дают системам ИИ широкое понимание того, как ведет себя физическая среда. Цифровые двойники обеспечивают промышленную специфику, которой не хватает этим моделям: геометрию предприятия, параметры процессов, логику управления и историю эксплуатации.</p> <p>Вместе они создают основу для более надежного физического ИИ. Модель мира может понимать, как ведут себя объекты и силы в целом, но цифровой двойник обеспечивает контекст, необходимый для определения того, является ли действие безопасным и эффективным на конкретном производстве, на конкретной линии, с конкретными материалами и ограничениями.</p> <h3>Что требуется для масштабирования</h3> <p>Ограничения должны быть согласованы между процессными и дискретными средами.</p> <p>Точность двойника зависит от точности потребляемых им данных. Без непрерывной синхронизации он превращается в устаревшее представление, которое обладает авторитетом модели, но не ее точностью.</p> <p>Безопасность становится все более важной по мере того, как двойники расширяют связность в операционных средах. Соединение инженерных моделей, систем ИИ и управления производством расширяет поверхность атаки и требует обеспечения безопасности на этапе проектирования для архитектуры, связности и управления.</p> <p>Работа также меняется по мере того, как двойники и агенты получают все больше возможностей принятия решений. Операторы и технические специалисты переходят от выполнения рутинных задач к контролю за системами, проверке рекомендаций и управлению исключениями. Это требует четкого определения ролей и путей эскалации, поскольку одних дополнительных часов обучения недостаточно для устранения этого пробела.</p> <p>Успешные программы цифровых двойников редко являются исключительной прерогативой ИТ-службы. Они требуют сотрудничества между операционными, инженерными, операционными группами, группами обработки данных и функциями управления ИИ. По мере того, как двойники эволюционируют из инженерных инструментов в платформы для принятия операционных решений, определение ответственности становится столь же важным, как и архитектура.</p> <h3>Вопрос, который стоит изучить производителям</h3> <p>Для руководителей операционных подразделений реальный вопрос заключается в том, достаточно ли развиты аспекты фундамента данных, проверки моделей, доверия операторов и управления, чтобы перейти на следующую ступень: от визуализации к автономному моделированию и далее к замкнутой системе оркестрации и к принятию агентами автономных решений.</p> <p>Переход на каждую следующую ступень должна быть обеспечен подтвержденными результатами на предыдущей.</p> <p>Программы, которые пропускают ступень, не движутся быстрее. Они застревают из-за отсутствия доверия модели, а доверие восстановить сложнее, чем исправить модель.</p> Многие программы реализации цифровых двойников заходят в тупик не только из-за качества модели, но и потому … article https://www.itweek.ru/themes/detail.php?ID=235366 Wed, 19 Aug 2026 09:10:34 +0300 <p>ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий на ограниченной группе пользователей. Но в промышленной эксплуатации с нагрузкой дела обстоят иначе. По оценке IDC, глобальные расходы на ИИ-инфраструктуру в 2026 году <a href="https://www.idc.com/resource-center/blog/ai-infrastructure-spending-caps-historic-year-at-90-billion-in-q4-2025-2029-spending-to-eclipse-1-trillion/">достигнут</a> 487 млрд. долл., прибавив около 53% за год. Такой рост показывает простую вещь: инфраструктура становится одной из главных статей ИИ-бюджета, а не технической деталью на стороне ИТ.</p> <p>При этом сама по себе закупка мощностей ничего не гарантирует — можно купить дорогие карты и получить простои. Поэтому компании, которые выводят ИИ из пилота, начинают адаптировать не один сервер, а весь контур: от профиля нагрузки до метрик, безопасности и финансового учета.</p> <p>Рассмотрим, как адаптировать инфраструктуру под новые нагрузки и почему недостаточно просто приобрести GPU.</p> <h3>Сначала сценарий, потом железо</h3> <p>Выражение «ИИ-инфраструктура» звучит так, будто речь идет об одном типе нагрузки — но на деле под ним скрываются разные задачи: обучение модели с нуля, дообучение, классический ML, генерация эмбеддингов. И у каждой задачи — свои узкие места, например голосовому ассистенту важна низкая задержка ответа, а для аналитики критична стоимость обработки большого объема данных.</p> <p>Поэтому зрелые компании начинают с классификации сценариев. Они отвечают на несколько простых вопросов:</p> <ul> <li> кто будет пользоваться искусственным интеллектом;</li> <li> сколько запросов ожидается;</li> <li> насколько важна скорость первого ответа;</li> <li> какой объем контекста нужен;</li> <li> можно ли обрабатывать запросы пакетно;</li> <li> что происходит при задержке.</li> </ul> <p>Без этого закупка «железа под ИИ» превращается в лотерею — инфраструктура может и не выдержать реальный сценарий.</p> <h3>Не всем нужен собственный обучающий кластер</h3> <p>Многие компании по инерции думают об ИИ-инфраструктуре как о кластере для обучения моделей. На практике большинству организаций он не нужен — у них нет ни объема данных, ни задач, ради которых стоит учить модель с нуля.</p> <p>Для внутренних ассистентов, поиска по базе знаний, обработки обращений, подготовки документов и поддержки разработчиков лучше идти другим, более простым путем. Достаточно взять готовую модель, развернуть ее у себя или провайдера, подключить корпоративные данные и настроить инференс.</p> <p>«Спроектировать инференс-платформу» звучит не так эффектно, как «построить суперкомпьютер» — зато это ближе к реальным задачам бизнеса.</p> <h3>GPU недостаточно просто купить — нужно научиться использовать</h3> <p>Самая дорогая ошибка — считать, что проблема решается количеством карт. В действительности GPU часто простаивают, в то время как команды жалуются на нехватку мощностей.</p> <p>Это видно и по рынку: в отчете Cast AI за 2026 год средняя утилизация GPU в Kubernetes-кластерах <a href="https://cast.ai/reports/kubernetes-optimization-report/">составила</a> всего 5%. Проблема эта редко связана с плохой организацией — чаще всего она структурная. В Kubernetes GPU в большинстве случаев воспринимается как неделимая единица: приложение запросило карту — получило ее целиком, а использует только часть мощности. В итоге дорогое оборудование формально занято, а фактически не загружено.</p> <p>Компании решают этот вопрос несколькими способами, например делят карту на изолированные части или выбирают инференс-серверы, которые умеют эффективнее упаковывать запросы.</p> <h3>Карты без сети и хранилища тоже простаивают</h3> <p>ИИ-нагрузки быстро показывают, что GPU — лишь часть инфраструктуры. Если данные и веса модели не успевают подаваться на узел, карта ждет. Бизнес при этом платит за дорогое оборудование, которое не делает полезной работы.</p> <p>Для больших моделей это становится отдельной инженерной задачей. Модель на 70 млрд. параметров в FP8 может весить около 70 Гб, а флагманские модели — сотни гигабайт. Их нужно быстро доставлять, хранить, обновлять и переиспользовать между узлами.</p> <p>Поэтому инфраструктура под ИИ должна включать сеть, хранилище, интерконнект, параллельную файловую систему и механику доставки весов. Если этого не сделать, компания покупает не мощность, а дорогую очередь ожидания.</p> <h3>Обычные метрики не показывают качество ИИ-сервиса</h3> <p>Классический мониторинг приложений плохо описывает ИИ-нагрузку. Для <nobr>LLM-инференса</nobr> важны другие показатели: time to first token, inter-token latency, throughput, tokens per second, запросы в секунду и стоимость обработки. NVIDIA в документации по benchmarking для LLM отдельно <a href="https://docs.nvidia.com/nim/benchmarking/llm/latest/metrics.html">выделяет</a> такие метрики как TTFT, ITL, TPS и end-to-end latency.</p> <p>Важно, что эти показатели нельзя оптимизировать для всех сценариев. Голосовому боту важен быстрый первый ответ, batch-аналитике — минимальная стоимость обработки. Поэтому зрелые команды задают SLO под конкретную ситуацию: для кого работает ИИ, какая задержка допустима, сколько компания готова платить за миллион токенов.</p> <h3>Модель нельзя встраивать напрямую в каждое приложение</h3> <p>Быстрый путь — подключить LLM прямо к монолиту или внутреннему порталу. На пилоте это удобно, однако в промышленной эксплуатации такой подход становится дорогим.</p> <p>Почему это происходит:</p> <ul> <li> становится сложнее переключить провайдера;</li> <li> приложение оказывается привязано к конкретной модели;</li> <li> почти невозможно нормально рассчитать расходы по командам;</li> <li> промпты и ответы выпадают из общего мониторинга.</li> </ul> <p>Рабочий вариант в таком случае — вынести работу с моделями в отдельный слой, ИИ-шлюз. Он становится единой точкой для квот, логирования, PII-фильтрации, кэширования, переключения моделей и контроля расходов.</p> <h3>RAG требует архитектуры доступа</h3> <p>RAG часто становится первым массовым корпоративным ИИ-сценарием: компания подключает документы, базы знаний, инструкции и хочет, чтобы сотрудники задавали вопросы на естественном языке. Однако вместе с пользой возникает и новый риск.</p> <p>Если права пользователя не участвуют в самом поисковом запросе, а фильтрация происходит уже после извлечения документов, векторная база превращается в канал переноса информации между отделами — быстрый, удобный и не оставляющий следов в привычных журналах доступа. Надеяться на фильтрацию постфактум нельзя, так как она регулярно пропускает содержимое чужих документов в ответы.</p> <p>Именно поэтому в корпоративном RAG роль, права доступа и подразделение пользователя должны быть частью самого запроса к индексу. Если гарантировать это архитектурно не получается, корпус должен сужаться до публичных документов — сегодня других надежных и безопасных вариантов тут нет.</p> <h3>Стоимость нужно считать в токенах с первого дня</h3> <p>ИИ-инфраструктура меняет привычный финансовый учет ИТ. Раньше компания считала серверы, лицензии, облачные ресурсы и человеко-часы. В ИИ-сервисах новой единицей стоимости становится токен.</p> <p>На пилоте это легко недооценить — слишком мало пользователей и запросов. В промышленной эксплуатации растут конкурентность, длина контекста, число пользователей, резервирование и объем логирования. Стоимость начинает расти нелинейно.</p> <p>Подсчет токенов нужен с первого дня. Компания должна понимать, кто генерирует расходы, какие сценарии самые дорогие, где можно кэшировать ответы, где подойдет более дешевая модель, а где оправдана премиальная.</p> <h3>Платформа лучше разрозненных запусков</h3> <p>Один из частых антипаттернов — когда каждый отдел сам разворачивает модель. На старте это кажется отличной возможностью не тормозить команды, однако вскоре компания получает дублирование расходов, разный уровень безопасности, отсутствие прозрачности и несколько точек риска.</p> <p>Но зрелая схема устроена иначе. Есть единый платформенный слой: инфраструктура, ИИ-шлюз, квоты, аудит, мониторинг, безопасность и SLA. Продуктовые команды отвечают за свои сценарии — промпты, корпус знаний, качество ответов, бизнес-эффект.</p> <p>Отдельный признак зрелости системы — оценка качества, evals. Без «золотого» набора примеров и регрессионного прогона невозможно ответить на вопрос, стало ли лучше после смены промпта или модели — и таким образом решения принимаются лишь на ощущениях.</p> <p>Зрелые команды относятся к промпту как к артефакту релиза: он версионируется, выкатывается постепенно и откатывается при деградации. Важно тут то, что закладывать evals нужно с первого дня, так как задним числом их уже не собрать. Так искусственный интеллект становится частью корпоративной архитектуры, переставая быть набором локальных экспериментов.</p> <h3>Подведем итоги</h3> <p>Адаптация ИТ-инфраструктуры под ИИ-нагрузки начинается с понимания сценариев: кому нужен искусственный интеллект, как часто, на каких данных, с какими рисками и за какие деньги.</p> <p>Компании, которые проходят этот путь осознанно, проектируют управляемый контур — инференс-платформу, правильные метрики, ИИ-шлюз, безопасный RAG, подсчет токенов и единые правила для всех команд. Не нужно делать его максимальным, перегружать всем и сразу — достаточно контроля, ясности и обратимости, то есть готовности сменить модель или провайдера, когда профиль нагрузки изменится.</p> <p>#IMAGE_235367#</p> ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий … article Султан Рамазанов, директор по искусственному интеллекту Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235363 Tue, 18 Aug 2026 15:56:55 +0300 <p>Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного управления JaCarta Management System 4LX для Linux (JMS4LX) и менеджера паролей Пассворк.</p> <p>Корректность совместной работы решений подтверждена сертификатом, выданным по результатам испытаний. Эта совместимость закрывает конкретную задачу заказчиков: организовать вход в менеджер паролей через уже действующую в компании систему усиленной аутентификации без создания отдельных учётных данных. Таким образом, пользователю не нужно запоминать ещё один пароль или носить отдельный токен для доступа к хранилищу — он проходит аутентификацию через сервис JaCarta Identity Provider (JIP), входящий в JMS4LX.</p> <p>JaCarta Management System 4LX для Linux — это система централизованного управления средствами аутентификации и электронной подписи, защищёнными носителями информации, аппаратными OTP/U2F-токенами и программными аутентификаторами. В её состав входят высокопроизводительный сервер аутентификации JaCarta Authentication Server (JAS), сервис Aladdin 2FA и JaCarta Identity Provider (JIP) — провайдер аутентификации/авторизации в приложения с поддержкой протоколов SAML и OIDC. </p> <p>Пассворк — это российский корпоративный менеджер паролей и секретов с возможностью развёртывания на собственном сервере заказчика или в облаке. Решение предназначено для безопасного хранения, управления и совместного использования учётных данных внутри компаний. Пассворк поддерживает ролевую модель доступа, полный аудит действий, интеграцию со службами каталогов и системами мониторинга безопасности. Пассворк включён в Единый реестр российского программного обеспечения (№ 6147 от 13.01.2020) и сертифицирован ФСТЭК России по <nobr>4-му</nobr> уровню доверия (№ 5063 от 30.04.2026).</p> <p>«Заказчики, которые строят ИТ-инфраструктуру на отечественных решениях, должны быть уверены: продукты работают вместе корректно и без доработок. Сертификат даёт эту уверенность на уровне вендоров: совместимость Пассворка и JMS4LX зафиксирована документально, протестирована и будет поддерживаться», — прокомментировал Андрей Пьянков, генеральный директор «Пассворк».</p> <p>«Подтверждение совместимости JMS4LX и Пассворка позволяет заказчикам использовать уже существующую инфраструктуру аутентификации для доступа к менеджеру паролей. Для компаний, где JIP уже используется в качестве корпоративного SSO, это означает, что сотрудникам не нужно заводить отдельные учётные данные для Пассворка», — прокомментировал Станислав Винарский, менеджер по развитию бизнеса JMS/JAS/JIP, «Аладдин».</p> Компании «Аладдин» и «Пассворк» подтвердили совместимость своих продуктов — корпоративной системы централизованного … message https://www.itweek.ru/themes/detail.php?ID=235362 Tue, 18 Aug 2026 15:20:16 +0300 <p>Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии десктопного и мобильного клиентских приложений. Релиз завершает этап бета-тестирования и переводит продукт на новую ступень готовности. Обновление включает более 20 новых функций, реализованных в постоянном диалоге с пользователями: изменения коснулись календаря, редактора написания письма, доступа к учетным записям и новых функций безопасности.</p> <p>Релиз направлен на решение трех задач — ускорение совместной работы, повышение прозрачности коммуникаций и упрощение рутинных операций.</p> <p>Пользователи получили возможность делиться своим расписанием с внешними партнерами или клиентами через публичные ссылки — теперь для просмотра календаря не требуется создавать учетную запись. При командной работе доступ к календарям предоставляется с гибкой настройкой уровней прав, что делает планирование прозрачным и управляемым. Полноформатный планировщик событий позволяет детально настраивать встречи и мероприятия в интуитивно понятном интерфейсе. Реализована возможность редактировать или удалять отдельное событие внутри повторяющейся серии, не нарушая всю последовательность, а также отображать время начала серии непосредственно в календаре.</p> <p>Значительные улучшения затронули и почтовый редактор. Теперь в тело письма можно мгновенно вставлять изображения, файлы и таблицы прямо из буфера обмена, а также создавать и редактировать таблицы встроенными средствами. Функция отложенной отправки позволяет задать точную дату и время доставки письма, а проверка орфографии подчеркивает ошибки, помогая избегать опечаток. Статус отправленных сообщений помогают отслеживать уведомления о доставке и прочтении с возможностью выбора автоматического или ручного режима в настройках.</p> <p>Для совместной работы с почтой и учетными записями реализован ряд новых возможностей. Доступ к почтовым папкам коллег настраивается для совместной работы, а функция делегирования позволяет доверенным лицам отправлять письма, принимать, переносить или назначать встречи от имени другого сотрудника. При отправке можно выбрать имя, от которого будет отправлено письмо, что обеспечивает прозрачность для получателя. Также пользователи могут создавать псевдонимы для своих учетных записей, чтобы лучше структурировать входящий поток.</p> <p>В релизе появились важные инструменты для защиты аккаунтов. Пользователи теперь могут самостоятельно сменить пароль непосредственно из интерфейса приложения, а также настроить двухфакторную аутентификацию — это обеспечивает дополнительный уровень защиты от несанкционированного доступа, что критически важно для корпоративных коммуникаций.</p> <p>Одним из ключевых нововведений стал функционал создания локальных архивов. Теперь можно сохранять свои почтовые сообщения непосредственно на устройстве, обеспечивая офлайн-доступ и дополнительную сохранность данных. На текущий момент доступно создание архивов и вложенных подпапок, архивация одного письма и группы писем, ручная архивация всей папки через контекстное меню, автоархивация по настройкам, удаление архивов и папок в них, ответ на письма из архива, пересылка писем из архива, работа с метками в архивах.</p> <p>Повышению удобства повседневной работы также способствуют обновленный поиск адресатов, который предлагает наиболее релевантных получателей при вводе фамилии, настройки режима удаления писем — через корзину, напрямую или пометку письма как удаленного, а также редизайн карточки контакта с более структурированным отображением информации. Для ускорения навигации добавлены горячие клавиши и возможность открывать письмо в новом окне одним нажатием Enter. Производительность приложения в целом была улучшена: оно стало быстрее и отзывчивее.</p> <p>«Мы сфокусировались на том, что напрямую влияет на эффективность повседневной работы, — прокомментировал Борис Моисеев, директор департамента разработки CommuniGate Pro. — Возможность вставить таблицу из Excel, файл или изображение в письмо за секунду, открыть календарь внешнему партнеру без создания учетной записи или выполнить проверку орфографии при написании письма — это базовые инструменты, экономящие реальное время каждого сотрудника каждый день».</p> <p>Первый официальный релиз десктопного и мобильного приложений уже доступен пользователям с действующей лицензией.</p> Разработчик платформы унифицированных корпоративных коммуникаций CommuniGate Pro объявил о выходе первой публичной версии … message https://www.itweek.ru/themes/detail.php?ID=235361 Tue, 18 Aug 2026 09:27:05 +0300 <p><em>Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности с фабрикой о экономически эффективном массовом производстве их совков для уборки собачьих экскрементов, комфортных носков или мочалок. Идея массового производства может быть актуальна и для доставки ПО, пишет на портале </em><em>ZDNet</em> <em>независимый аналитик Джо Маккендрик.</em></p> <p>Представьте, что вы отправляете свой прототип — например, начальную версию приложения, написанную с помощью вайб-кодинга, — в сервис, который будет массово производить ваше решение в повторяемом автоматизированном режиме для распространения среди широкой аудитории. В этом и заключается обещание «фабрики ПО».</p> <p>В этой концепции нет ничего нового — она была очень популярна около двух десятилетий назад, когда разработка ПО стала более компонентной и повторяемой. Microsoft <a href="https://en.wikipedia.org/wiki/Software_factory_(Microsoft_.NET)">заговорила</a> о фабриках ПО еще в 2008 г. Идея на некоторое время затихла, но теперь она вернулась, подпитываемая быстрым созданием программного кода, генерируемого и управляемого искусственным интеллектом.</p> <p>До недавнего времени, даже при наличии автоматизации и практик DevOps, «кодирование создавало узкие места для многих организаций, — говорит Мориц Плассниг, генеральный директор CloudBees. — Приходилось нанимать больше инженеров, но это было очень сложно и дорого».</p> <h3>Сегодняшняя фабрика ПО построена на моделях ИИ</h3> <p>Благодаря возможностям кодирования базовых моделей ИИ и связанных с ними агентов, концепция фабрики ПО возродилась — и сегодня серьезно рассматривается автоматизация жизненного цикла разработки ПО на уровне повторяющихся этапов. С помощью агентного кодирования «мы меньше ограничены в части кодирования», отмечает Плассниг. Оно также может повысить роль ИТ-специалистов: «Мастерство разработчиков никуда не денется, поскольку разработчики и инженеры переходят от написания кода к принятию решений о том, что будет создано и выпущено».</p> <p>Современная концепция фабрики ПО построена на основе моделей ИИ, представленных на рынке, — и эта концепция практически одинакова для всех моделей. «За последние полтора года многие компании, находящиеся на переднем крае использования агентов для автоматизации жизненного цикла разработки ПО, создавали одну и ту же машину и независимо друг от друга приходили к одному и тому же выводу о том, как эта машина должна выглядеть», — говорит Джеймин Уэст, инженер-разработчик и технологический евангелист.</p> <p>Среди компаний, создающих фабрики ПО, — такие светила современной агентной экономики, как Anthropic, Cognition, Cursor, Factory, Google, Github, OpenAI и Ramp. «Каждая из этих компаний пришла к одной и той же форме, — отмечает Уэст. — На данном этапе очень важно понимать, что это компании, находящиеся на передовой, и что формируется четкая закономерность в том, как они структурируют всю свою инженерную работу».</p> <p>По словам Пласснига, фабрика ПО служит способом быстрого воплощения идей: «Допустим, кто-то работает в службе поддержки клиентов, и у него возникает интересная идея, основанная на отзывах клиентов. Такой человек с идеей ПО может отправить ее на фабрику, где создается первая итерация. Далее специалисты по продуктам, инженеры и ИТ-специалисты изучают ее. Затем фабрика может снова взять ее и воплотить в жизнь. Это подобно тому, как в автоиндустрии появляется экспериментальный прототип, который потом передается на завод, который производит автомобили в больших масштабах».</p> <p>Фабрика ПО помогает решить проблему проверки и поддержки сотен тысяч строк кода, а также релизов, обновлений и модернизаций ПО, которые сегодня ежедневно происходят во многих организациях.</p> <p>«Вы хотите знать, действительно ли ПО работает, нет ли ошибок или хотя бы резкого роста частоты ошибок. Или, может быть, оно работает, но не превышает ли потребление памяти агентом желаемый уровень? Сегодня люди проверяют все эти оповещения, но если изменений будет в 100 раз больше, например, каждые несколько минут, система сломается. Мы дойдём до того момента, когда люди больше не смогут проверять, что работает, а что нет», — говорит Плассниг.</p> <h3>Как выглядит фабрика ПО?</h3> <p>Уэст описывает типичную фабрику, поддерживаемую базовыми моделями, как состоящую из шести компонентов:</p> <ol> <li><strong> Очередь.</strong> «Работа поступает в виде проблемы, а не промпта».</li> <li><strong> Плоскость управления.</strong> «Надежный уровень, а не ноутбук».</li> <li><strong> Песочница.</strong> «Одна на задачу. Уничтожается после ее завершения».</li> <li><strong> Запрос на слияние.</strong> «Единица вывода. Его получает человек».</li> <li><strong> Поток событий.</strong> «Отслеживает каждое действие. Прерывает его, не нарушая выполнение».</li> <li><strong> Надежная память.</strong> «Песочница выполняет каждый запуск. То, что не записано в файл, не сохраняется».</li> </ol> <p>Конечно, фабрики ПО, какими бы эффективными они ни были, не являются панацеей для внедрения передовых методов разработки ПО.</p> <p>«Сейчас уже не секрет, что генерация кода стала невероятно простой, — говорит Уэст. — Она теперь невероятно дешева. Но препятствием для многих компаний стала верификация. Убедиться, что агенты пишут код, очень легко. Но убедиться в правильности этого кода по-прежнему остается серьезной инженерной проблемой. И важно понимать, что создание фабрики ПО не означает, что вы просто отказываетесь от верификации или снижаете качество своей кодовой базы».</p> Самый частый вопрос, который венчурные капиталисты задают начинающим предпринимателям: есть ли у них договоренности … article https://www.itweek.ru/themes/detail.php?ID=235359 Tue, 18 Aug 2026 09:17:03 +0300 <p><em>За четыре года число поисковых запросов вокруг темы «ИИ как угроза» выросло примерно в 30 раз и к <nobr>2026-му,</nobr> по данным исследования Андрея Цая, вышло на первое место — обогнав даже запросы о защите самих ИИ-систем. Рассмотрим, насколько реальна эта угроза и что необходимо предпринять компаниям, чтобы ее отразить.</em></p> <h3>ИИ как орудие злоумышленников</h3> <p>На фоне развития искусственного интеллекта все чаще звучат разговоры о том, что ИИ может превратиться в инструмент злоумышленников. Однако слово «может» здесь уже не вполне уместно: ИИ становится рабочим инструментом в offensive security и способен выполнять часть задач, которые раньше требовали значительного объема ручной работы. Показателен пример XBOW — автономной системы для поиска и эксплуатации уязвимостей. В 2025 году XBOW поднялась на первое место американского рейтинга HackerOne, а позднее заняла первое место и в глобальном рейтинге платформы. При этом речь шла не о лабораторном тесте: система работала в реальных bug bounty-программах и отправляла отчеты об обнаруженных уязвимостях. Сам HackerOne отмечал выход XBOW на первое место американского рейтинга как пример того, что ИИ-системы уже способны эффективно находить определенные классы уязвимостей. Это не означает, что ИИ полностью заменил исследователя: например, команда XBOW проверяла отчеты перед отправкой в соответствии с правилами HackerOne. Но сам кейс хорошо показывает изменение масштаба и скорости работы: значительную часть поиска, проверки гипотез и валидации находок уже можно автоматизировать.</p> <p>Причина очевидна: ИИ хорошо справляется с интеллектуальной рутиной. Он может быстро обрабатывать большие объемы информации, находить закономерности, классифицировать данные и выполнять последовательности однотипных операций. И атака в этом смысле во многом похожа на другие сложные рабочие процессы. Значительная часть времени злоумышленника уходит на подготовку: сбор информации о цели, анализ инфраструктуры и технологий, поиск потенциально интересных объектов и проверку различных гипотез. Если часть этой работы передать ИИ, меняется сама экономика атаки: разведка, анализ и перебор вариантов становятся быстрее и дешевле, а один злоумышленник может выполнять объем работы, для которого раньше требовалось значительно больше времени.</p> <p>Необходимо также понимать, что скорость внедрения новых технологий у злоумышленников зачастую выше, чем в крупных организациях. Пока компания оценивает риски, согласовывает бюджет, выбирает модели и выстраивает процессы безопасного использования ИИ, атакующему достаточно получить доступ к публичному сервису или модели. Возникает асимметрия: стоимость автоматизации отдельных этапов атаки быстро снижается, тогда как стоимость полноценной защиты компании — нет. Поэтому основная угроза ИИ сегодня заключается не столько в появлении автономного «ИИ-хакера», сколько в росте производительности обычного злоумышленника.</p> <h3>Проще атака — больше желающих</h3> <p>Еще одна проблема заключается в том, что ИИ постепенно снижает порог входа в отдельные этапы кибератак. Часть задач, для которых раньше требовались специальные знания, теперь можно выполнять с помощью языковых моделей: собирать и анализировать информацию о цели, быстрее разбираться в незнакомых технологиях, модифицировать скрипты, готовить фишинговые сообщения или анализировать найденный код. Это не превращает человека без технических знаний в профессионального хакера, но сокращает разрыв между отсутствием компетенций и возможностью выполнить отдельные элементы атаки.</p> <p>Одновременно с этим появляются и новые классы атак на сами ИИ-приложения. Один из примеров — prompt injection (инъекция промптов), при которой злоумышленник через специально сформированные инструкции пытается изменить ожидаемое поведение системы. Например, если на корпоративном ресурсе работает интеллектуальный поиск или ИИ-агент, атакующий может попытаться заставить его проигнорировать исходные инструкции, обратиться к данным, которые не должны быть доступны пользователю, или выполнить нежелательное действие. Отдельно существуют jailbreak-техники, направленные на обход ограничений самой модели. Для экспериментов с такими атаками в ряде случаев действительно не требуется сложная инфраструктура: взаимодействие происходит через тот же интерфейс, которым пользуется обычный пользователь.</p> <p>Одновременно ИИ выступает как инструмент автоматизации для самого злоумышленника. Если раньше для подготовки определенной атаки требовалось самостоятельно изучать множество технических вопросов, теперь часть этой работы можно переложить на языковую модель: быстрее разобраться в технологии, получить объяснение незнакомого кода, подготовить или адаптировать отдельные фрагменты скриптов, систематизировать результаты разведки. Ограничения публичных моделей снижают возможности их прямого использования во вредоносных целях, однако злоумышленники постоянно экспериментируют и с техниками обхода таких ограничений.</p> <p>Для обхода ограничений могут использоваться изменение контекста запроса, ролевые сценарии, декомпозиция задачи на несколько внешне безобидных этапов и другие техники. Вместо прямого запроса пользователь может представить задачу как исследование, киберучение или анализ защищенности либо разбить ее на последовательность отдельных вопросов. Эффективность таких приемов зависит от конкретной модели и реализованных механизмов защиты, но для атакующего важен сам принцип: ИИ позволяет значительно быстрее проводить эксперименты и проверять множество вариантов.</p> <p>Еще сильнее меняется скорость работы. Если раньше сбор и изучение контекста для определенной атаки могли занимать дни, то автоматизированная система способна существенно сократить этот этап. В результате отдельные стадии атаки становятся проще, дешевле и лучше масштабируются. Высвободившееся время злоумышленник может потратить на более сложные действия, которые пока хуже поддаются автоматизации.</p> <p>Для бизнеса это неприятная тенденция, поскольку стоимость атаки снижается, но стоимость полноценной защиты от нее автоматически не уменьшается. Компании по-прежнему должны поддерживать инфраструктуру безопасности, контролировать доступы, анализировать события и защищать данные.</p> <h3>Shadow AI как источник риска внутри компании</h3> <p>Однако усиление внешнего атакующего — только одна сторона проблемы. ИИ одновременно меняет поверхность атаки внутри самой компании: сотрудники подключают публичные модели, генераторы кода, агентов и другие инструменты быстрее, чем служба безопасности успевает их обнаруживать и оценивать. Так возникает другая категория риска — Shadow AI (теневой ИИ).</p> <p>Термин появился по аналогии с давно известным Shadow IT (теневые ИТ) — ситуацией, когда сотрудники самостоятельно используют для рабочих задач программное обеспечение и сервисы, которые компания официально не разрешила и не контролирует. Например, сотруднику нужен удобный инструмент для хранения файлов, совместной работы или обработки документов, и он самостоятельно регистрируется во внешнем сервисе. С точки зрения сотрудника он просто выбрал удобный инструмент, а с точки зрения службы безопасности внутри компании появился неконтролируемый канал обработки корпоративных данных.</p> <p>С Shadow AI происходит похожая история. В компании может не быть понятных правил использования ИИ — какие сервисы разрешены, какие данные можно туда отправлять, какую информацию категорически запрещено загружать, какие инструменты допустимы для разработки и анализа. В результате сотрудники начинают самостоятельно выбирать открытые ИИ-сервисы и использовать их для рабочих задач.</p> <p>Главные риски здесь связаны с утечками данных. Сотрудник может работать с корпоративного компьютера или ноутбука в публичном ИИ-сервисе и передавать туда информацию, которую нельзя выводить за пределы компании. Причем он сам часто даже не задумывается, что создает риски утечки. Для него это просто удобный способ решить рабочую задачу.</p> <p>Допустим, сотрудник отдела продаж берет папку с документами по клиентам за прошлый год и загружает ее в ИИ с просьбой сформировать отчет, прогноз или маркетинговое предложение. На первый взгляд задача выглядит безобидной и даже полезной: сотрудник хочет быстрее проанализировать информацию, чтобы повысить продажи. Но вместе с запросом за пределы корпоративного контура уходит клиентская база: контактные данные, сведения о продажах, цены, скидки и другая коммерческая информация. В результате могут компрометироваться и персональные данные, и коммерческая тайна, и внутренняя информация о работе с клиентами.</p> <p>Традиционные средства контроля утечек данных остаются необходимой частью защиты, но в случае с ИИ их возможностей может быть недостаточно. Компании важно понимать не только то, какие данные передаются за пределы корпоративного контура, но и в какой ИИ-сервис они уходят, разрешен ли этот сервис конкретному сотруднику, идет ли речь о загрузке файла, отправке промпта или обращении к модели через API. Поэтому классические механизмы защиты приходится дополнять обнаружением ИИ-сервисов и контролем специфичных для них сценариев использования.</p> <p>У Shadow AI есть и техническая сторона. Внутри разработки могут появляться генераторы кода, различные модели, агенты и другие инструменты, которые сотрудники самостоятельно подключают к рабочим процессам. Проблема заключается в том, что качество и безопасность таких инструментов часто под вопросом. Один сотрудник может использовать модель для генерации кода, другой — подключить сторонний инструмент для автоматизации, третий — развернуть собственный сервис. При этом количество подобных решений может расти настолько быстро, что служба безопасности просто не успевает их обнаруживать и оценивать. А защищать то, что СБ не видит, технически невозможно. Если компания не знает, какими ИИ-инструментами пользуются сотрудники, она не может полноценно оценить риски, определить, какие данные через них проходят, и подобрать соответствующие средства защиты.</p> <p>Поэтому сама по себе политика запрета не решает проблему. Более того, жесткий запрет может сделать ситуацию менее прозрачной. Если сотруднику официально запрещено пользоваться ИИ, но инструмент необходим ему для работы, он с высокой вероятностью начнет искать собственное решение. В итоге компания формально может считать, что никакого ИИ у нее нет, тогда как сотрудники будут его использовать с личных устройств.</p> <p>Выход здесь — в создании контролируемой корпоративной среды для работы с ИИ. Если сотрудникам действительно нужны языковые модели, агенты или другие ИИ-инструменты, компания должна предоставить разрешенные способы их использования: определить перечень допустимых сервисов и моделей, правила работы с данными, механизмы доступа, журналирования и контроля. Это необязательно означает полный отказ от внешних ИИ-сервисов — важно, чтобы компания понимала, какие инструменты используются, какие данные в них передаются и на каких условиях они обрабатываются.</p> <p>Такая среда должна быть не только безопасной, но и удобной. Иначе запрет снова будет проигрывать удобству публичных инструментов. Сотрудник выбирает не по критерию безопасности. Он ищет способ быстрее выполнить свою работу. И если корпоративная система оказывается слишком неудобной, поиск обходных путей практически неизбежен.</p> <p>#IMAGE_235360#</p> За четыре года число поисковых запросов вокруг темы «ИИ как угроза» выросло примерно в 30 раз … article Светлана Газизова, владелец продукта по безопасности ИИ компании UserGate https://www.itweek.ru/themes/detail.php?ID=235358 Mon, 17 Aug 2026 19:08:47 +0300 <p>Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более 43 тыс. человек по 36 ролям и выяснила, что медианная зарплата специалистов уровня Senior в I квартале 2026 года вернулась к показателю трёхлетней давности. За полгода она снизилась на 17%, с 360 тыс. до 300 тыс. рублей после вычета налогов. </p> <p>Исследование охватывает семь замеров с I квартала 2023 года по I квартал <nobr>2026-го.</nobr> За это время российский ИТ-рынок прошёл полный цикл: от последовательного роста зарплат до их заметного снижения после пика III квартала 2025 года.</p> <p>Изменения затронули все грейды, за полгода медианная зарплата специалистов уровня Middle снизилась на 8%, с 250 тыс. до 230 тыс. рублей после вычета налогов. У Senior она сократилась на 17%, с 360 тыс. до 300 тыс. рублей, а у Lead — на 12%, с 450 тыс. до 395 тыс. рублей. При этом зарплаты Middle и Lead всё ещё немного превышают показатели начала 2023 года, тогда как медиана Senior полностью вернулась к уровню трехлетней давности.</p> <p>«Совпадение зарплатных показателей с уровнем 2023 года не означает, что рынок вернулся в прежнее состояние. За одинаковыми цифрами скрывается другая логика найма. Если раньше работодатели конкурировали за специалистов и расширяли зарплатные вилки, то теперь они точнее оценивают прикладную ценность каждой роли. Спрос сохраняется, но становится более избирательным: лучше всего удерживают позиции специалисты, чьи компетенции связаны с устойчивостью инфраструктуры, безопасностью и решением конкретных задач бизнеса.</p> <p>В этих условиях компаниям важно не только точнее нанимать специалистов, но и эффективнее развивать уже сформированные команды. Поэтому переход от HR Tech к People Tech, то есть от автоматизации отдельных HR-функций к управлению всем профессиональным путём сотрудника, становится одной из ключевых тем отраслевой дискуссии. Этот вопрос активно обсуждается в профессиональном сообществе, в том числе на конференциях для HR- и ИТ-лидеров. Бизнес стремится объединить подбор, адаптацию, обучение и оценку эффективности в единую систему, ориентированную на реальные задачи компании», — комментирует Иван Котковский, управляющий партнёр кадрового системного интегратора SENSE, сооснователь и член программного комитета ежегодного кэмпа PEOPLE TECH для HRD, CPO / CTO HR.</p> <p>Наиболее заметно снизились зарплаты в направлениях, которые активнее всего росли в <nobr>2024–2025 годах.</nobr> Одним из таких направлений стало Data & ML. Самую сильную коррекцию за полгода показали специалисты Data Quality уровня Lead: их медианная зарплата сократилась на 30%, с 400 тыс. до 280 тыс. рублей. Data Scientist Lead за тот же период потеряли 115 тыс. рублей, а Senior — 85 тыс. рублей.</p> <p>В то же время прикладные и инфраструктурные роли внутри Data & ML оказались устойчивее: медианная зарплата DBA Middle снизилась только на 3%, а ML Middle — на 7%. По мнению аналитиков SENSE, рынок стал строже оценивать не само владение ИИ-инструментами, а способность специалистов решать с их помощью конкретные задачи бизнеса.</p> <p>Заметный откат произошёл и в классическом backend. За полгода медианная зарплата Python Senior снизилась на 28%, с 360 тыс. до 260 тыс. рублей, а C#.Net Senior — на 26%, с 380 тыс. до 280 тыс. рублей. Зарплата Java Middle к I кварталу 2026 года вернулась к отметке 250 тыс. рублей, зафиксированной в начале <nobr>2023-го.</nobr> На динамику направления повлияли замедление найма и пересмотр ИТ-бюджетов в финансовом секторе, который долгое время оставался одним из основных заказчиков специалистов этого профиля.</p> <p>Существенную переоценку пережила и мобильная разработка. От собственных пиков III квартала 2024 года до I квартала <nobr>2026-го</nobr> медианные зарплаты iOS-разработчиков снизились на <nobr>19–37%</nobr> в зависимости от грейда, Android-разработчиков — на <nobr>19–31%.</nobr> Сильнее всего коррекция затронула специалистов уровня Middle.</p> <p>Наиболее устойчивыми оказались направления, спрос на которые связан с долгосрочными задачами бизнеса. После пика зарплаты архитекторов информационной безопасности снизились не более чем на 1%, а медианы DevSecOps сохранились на прежнем уровне. В направлении 1С зарплаты по четырём из шести исследованных ролей не изменились по сравнению с III кварталом 2025 года. Относительно небольшую коррекцию также показали Frontend, DevOps и SRE.</p> <p>При этом в период роста отдельные роли показали особенно заметную динамику. От начала наблюдений до своих максимальных значений медианные зарплаты бизнес-аналитиков уровня Middle выросли на 67%, системных аналитиков Middle — на 66%. Архитекторы информационной безопасности уровня Middle прибавили 50%, DBA Lead — 46%, а DBA Senior — 43%. Это показывает, что общая коррекция не отменила структурный спрос на отдельные компетенции, хотя после пика III квартала 2025 года динамика стала разнонаправленной.</p> Кадровый системный интегратор SENSE провёл исследование динамики зарплат российских ИТ-специалистов на основе данных более … message https://www.itweek.ru/themes/detail.php?ID=235355 Mon, 17 Aug 2026 11:50:26 +0300 <p>Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — очередного обновления платформы миграции и репликации данных. Ключевое новшество версии — поддержка аналитической СУБД для гибридных нагрузок Postgres Pro AXE с загрузкой в S3-совместимое хранилище, что открывает заказчикам новые сценарии для построения аналитических хранилищ. Также в релиз вошла функциональность по повышению производительности утилит, укреплению безопасности и переработке механизма интроспекции схем данных.</p> <p>Postgres ProGate предназначена для проектов миграции, разового переноса данных и непрерывной репликацей между СУБД. Продукт помогает автоматизировать ключевые этапы работы с данными: первичную загрузку, синхронизацию изменений в режиме, близком к реальному времени, и проверку корректности переноса.</p> <p>Главное новшество версии — поддержка аналитической СУБД AXE в качестве приёмника данных с возможностью загрузки в S3-совместимое хранилище. Это расширяет сценарии использования платформы для построения современных аналитических хранилищ и data lake-решений на базе экосистемы Postgres Professional.</p> <p>Также одним из наиболее стала полная переработка механизма интроспекции. Реализована асинхронная обработка, что заметно ускоряет интроспекцию схем с большим количеством таблиц. Добавлена поддержка проверки привилегий доступа к схемам и таблицам, а также проверки совместимости подключений для prosync, включая права на чтение таблиц, — результаты доступны через API. Улучшено автоматическое сопоставление схем и таблиц для задач трансфера на основе совпадения имён.</p> <p>Утилита procopy получила более гибкий контроль над параллельной обработкой задач. Добавлен параметр sub_task_count, определяющий, на сколько подзадач может разбиваться исходная задача копирования, при этом расчёт размера подзадач теперь выполняется автоматически, а параметр sub_task_rows переведён в статус deprecated. Появился флаг force_restart_task, позволяющий перезапускать задачи без очистки данных и без изменения идентификатора задачи — это удобно для регулярных переносов данных, например, снапшотов T-1.</p> <p>Кроме того, в procopy и prosync добавлен параметр disable_constraint_checks, который отключает проверку ограничений и пользовательских триггеров на время записи батча в целевую PostgreSQL-совместимую БД, что ускоряет загрузку в сценариях, где целостность гарантируется на стороне источника или последующей верификацией.</p> <p><nobr>CDC-репликация</nobr> стала стабильнее и быстрее. Добавлена опция single_loader, которая позволяет для конкретной таблицы принудительно использовать один загрузчик, обеспечивая последовательную обработку изменений для таблиц, связанных внешними ключами. Исправлена ошибка считывания записей с большими значениями SCN из онлайн-журналов Oracle. Устранено удержание WAL-файлов на источниках PostgreSQL при редких изменениях за счёт улучшения механизма продвижения слотов логической репликации. Повышена производительность применения изменений для Oracle.</p> <p>Добавлена фиксация блокировки учётной записи пользователя при превышении лимита неудачных попыток ввода пароля. Все компоненты системы переведены на Go 1.26.5, а Apache Thrift обновлён до версии v0.23.0 с устранением ранее обнаруженных уязвимостей.</p> <p>«Поддержка Postgres Pro AXE в качестве приёмника данных — это новый вектор развития продукта. Если раньше ProGate использовался преимущественно для миграции и репликации между операционными базами данных, то теперь платформа закрывает и сценарий поставки данных в аналитику с загрузкой в S3-совместимые хранилища. Это существенно расширяет область применения продукта и открывает нашим заказчикам возможность строить аналитические конвейеры на единой технологической платформе. В сочетании с переработанной интроспекцией, которая в разы ускоряет работу со схемами из сотен и тысяч таблиц, новыми опциями управления параллелизмом в procopy и усилением безопасности мы сделали серьёзный шаг в развитии платформы и дали нашим клиентам новые споособы решения своих бизнес-задач», — прокомментировал руководитель продукта Postgres ProGate Евгений Кривов.</p> Российский разработчик систем управления базами данных Postgres Professional объявил о выходе Postgres ProGate 1.4.0 — … message https://www.itweek.ru/themes/detail.php?ID=235352 Mon, 17 Aug 2026 09:43:07 +0300 <p><em>Искусственный интеллект делает более быстрым и простым извлечение конфиденциальной личной информации из обычных бизнес-данных. Вице-президент Gartner Барт Виллемсен объясняет порталу </em><em>InformationWeek</em><em>, почему это происходит и что должны делать руководители служб информационной безопасности (</em><em>CISO</em><em>).</em></p> <p>Правила регулирования конфиденциальности данных, например европейский GDPR и американские федеральные законы, такие как HIPAA, больше не достаточны для защиты персональных данных в эпоху ИИ.</p> <p>Gartner <a href="https://www.gartner.com/en/documents/7864881">прогнозирует</a>, что к 2029 г. большинство инцидентов, связанных с нарушением конфиденциальности, будут вызваны ИИ-выводами об отдельных лицах, а не прямым раскрытием личной информации, такой как имена, адреса и номера социального страхования.</p> <p>По словам Виллемсена, способность ИИ быстро распознавать образы означает, что злоумышленникам больше не нужно красть или покупать учетные данные, чтобы получить конфиденциальную информацию о людях. Анонимизация данных сама по себе не обеспечивает достаточной защиты, поскольку алгоритмы ИИ могут повторно идентифицировать людей или выводить конфиденциальные атрибуты из анонимизированных наборов данных.</p> <p>«Настоящей анонимизации не существует, за исключением фактического удаления данных. Атака на основе инференса очень эффективна, потому что она затрагивает всё, а не только непосредственно идентифицируемые репозитории», — говорит Виллемсен.</p> <p>По мере совершенствования генеративного ИИ и машинного обучения эти технологии могут выводить конфиденциальные личные характеристики — такие как состояние здоровья или поведенческие модели — из анонимизированных или агрегированных данных.</p> <p>«Современные модели могут восстанавливать личные данные, используя поведенческие модели, показатели использования и агрегированные записи транзакций. Например, ИИ может идентифицировать людей по данным о поездках, социальным сетям, рентгеновским снимкам, ЭКГ, МРТ, даже походке или практически любой комбинации из примерно трёх транзакций», — объясняет Виллемсен.</p> <p>Кроме того, по его словам, когда ИИ галлюцинирует или создает синтетические данные о людях, эти неверные данные могут вызывать реальные проблемы. Например, предвзятость и галлюцинации ИИ могут привести к неправомерному тюремному заключению и серьезным ошибкам в юридических исследованиях.</p> <p>Последствия выходят далеко за рамки нарушений конфиденциальности, считает Эндрю Обадиару, CISO компании Cobalt. «ИИ может определить состояние здоровья человека, его финансовое положение, влияние внутри организации или вероятность ответа на фишинговое письмо, не имея доступа к медицинской карте или кадровому делу», — говорит он.</p> <p>По его словам, данные, которые не кажутся конфиденциальными — такие как справочники сотрудников, отношения с поставщиками, активность в социальных сетях или взаимодействие с клиентами — могут стать ценными, когда ИИ связывает эти фрагменты. ИИ может использовать их для определения структуры подчиненности, администрирования систем, взаимоотношений между руководителями, полномочий по расходам или того, какой инженер отвечает за критически важную производственную систему. Затем злоумышленники могут использовать эти данные, чтобы сделать свои атаки гораздо более точными.</p> <p>«В результате фишинговые кампании становятся значительно более убедительными, компрометация корпоративной электронной почты происходит быстрее, вымогательство — более целенаправленным, а операции по вторжению — гораздо эффективнее, поскольку злоумышленник уже знает, кого атаковать, прежде чем отправить первое письмо», — поясняет Обадиару.</p> <p>Организациям необходимо начать задумываться не только о том, какие данные они собирают, но и о том, «что эти данные раскрывают, когда они объединяются, сопоставляются и интерпретируются все более совершенными системами ИИ», — добавляет он. И, из-за развития технологий ИИ, правила обеспечения конфиденциальности, которые исторически были сосредоточены на непосредственно идентифицируемых данных, должны также распространяться на косвенно или повторно идентифицируемый контент.</p> <p>«Сочетание данных, зарегистрированных где угодно, доступа к ним по всему миру (случайно или в результате злонамеренного взлома) и возможностей, доступных любому, кто хочет получить доступ к данным с помощью современных аналитических и генеративных ИИ-технологий, — вот что отличает сегодняшнюю ситуацию. Кроме того, организации практически не очищают данные, которые им больше не нужны», — говорит Виллемсен.</p> <p>По его словам, риск повторной идентификации данных существовал задолго до сегодняшнего бума ИИ, но ИИ значительно ускоряет этот процесс. Он ссылается на <a href="https://www.nature.com/articles/s41467-019-10933-3.pdf">исследование</a> 2019 г., проведенное специалистами в области науки о данных Люком Роше, Жюльеном М. Хендрикксом и Ивом-Александром де Монжуа, которые разработали генеративную графическую модель для повторной идентификации людей. «Используя нашу модель, мы обнаружили, что 99,98% американцев будут правильно идентифицированы в любом наборе данных с использованием 15 демографических атрибутов», — написали они.</p> <h3>ИИ усиливает угрозу повторной идентификации</h3> <p>По словам Обадиару, что изменилось с развитием ИИ, так это то, что теперь «скорость на стороне злоумышленников — и масштаб». «Пять лет назад создание подробных профилей тысяч потенциальных жертв было экономически нецелесообразным. Сегодня это не так», — отмечает он.</p> <p>Виллемсен обращает внимание на <a href="https://arxiv.org/pdf/2602.16800">исследование</a> 2026 г., проведенное инженерами Саймоном Лерменом, Даниэлем Палекой, Джошуа Свансоном, Майклом Аэрни, Николасом Карлини и Флорианом Трамером. Авторы обнаружили, что больше языковые модели (LLM) могут повторно идентифицировать людей, «используя только псевдонимизированные онлайн-профили и переписки, что сопоставимо с тем, что может выполнить опытный следователь за много часов работы».</p> <p>Примечательно пояснение авторов: «В каждой ситуации методы на основе LLM значительно превосходят классические базовые методы, достигая до 68% полноты при 90% точности по сравнению с почти 0% для лучшего метода без применения LLM. Наши результаты показывают, что практическая неопределенность, защищающая псевдонимных пользователей в Интернете, больше не действует и что модели угроз для конфиденциальности в Интернете необходимо пересмотреть».</p> <p>По словам Обадиару, лучшие атаки на основе инференса совсем не выглядят как атаки. «Злоумышленник может начать с LinkedIn, публичных документов, социальных сетей, украденных учетных данных, активности на GitHub и утечек маркетинговых баз данных. Ни один из этих наборов данных сам по себе не представляет особой ценности. Но ИИ выполняет сложную работу по их объединению», — отмечает он.</p> <p>По словам Виллемсена, чтобы снизить риски нарушения конфиденциальности, основанные на инференсе, CISO следует начать с обеспечения управления данными на протяжении всего их жизненного цикла и удаления данных, как только они перестанут приносить бизнес-ценность, которая оправдывала бы затраты и риски их защиты. «У данных есть жизненный цикл, и мы знаем, что хранить их вечно — это неразумно. Поэтому жестко запрограммируйте его конец», — советует он.</p> <h3>Шаги по устранению основанных на инференсе рисков от Gartner</h3> <p>По словам Виллемсена, для CISO защита от угроз, основанных на ИИ-инференсе, начинается с управления ИИ. Вот его советы:</p> <ul> <li><strong> Управление ИИ.</strong> Внедрите в разработку ИИ установление механизмов защиты конфиденциальности на этапе проектирования и регулярно оценивайте риски предвзятости или инференса.</li> <li><strong> Внедрение технологий повышения конфиденциальности (PET).</strong> PET — это «набор технологических инструментов», — говорит Виллемсен. Эти технологии защищают персональные данные, обрабатывая их в защищенном состоянии или в рамках «конфиденциальных вычислений». К PET относятся дифференциальная конфиденциальность, синтетические данные, машинное обучение с учетом конфиденциальности и гомоморфное шифрование, которое выполняет вычисления над зашифрованными данными без необходимости их предварительного расшифрования. PET могут свести к минимуму вероятность повторной идентификации ИИ отдельных лиц, даже если ИИ проанализирует данные.</li> <li><strong> Контроль жизненного цикла.</strong> Сбор данных должен ограничиваться основными потребностями бизнеса и включать контроль доступа. Данные следует удалять, как только они перестают быть полезными и/или их защита становится экономически нецелесообразной. Что касается управления данными, то Виллемсен советует проводить «последовательную и очень тщательную очистку».</li> <li><strong> Повышение кибербезопасности для угроз, основанных на ИИ.</strong> Организациям следует расширять свои традиционные подходы к кибербезопасности, уделяя приоритетное внимание расширенному мониторингу, обнаружению аномалий и возможностям планирования сценариев для выявления угроз, основанных на инференсе.</li> <li><strong> Прозрачность и человеческий контроль.</strong> Задокументируйте, где в сети организации уместно использование ИИ-инференса, регулярно проводите аудит систем ИИ и поддерживайте участие человека в проверке выводов, генерируемых ИИ, прежде чем допустить технологию действовать с конфиденциальными данными.</li> </ul> <p>«Не стоит недооценивать риски, связанные с различными типами ИИ, прежде чем использовать какой-либо из них», — заключает Виллемсен.</p> Искусственный интеллект делает более быстрым и простым извлечение конфиденциальной личной информации из обычных … article https://www.itweek.ru/themes/detail.php?ID=235351 Mon, 17 Aug 2026 09:20:51 +0300 <p><em>Корпоративные озера-хранилища данных (</em><em>data</em> <em>lakehouse</em><em>) эволюционируют. Изначально предназначенные в первую очередь для консолидации данных для аналитики, сегодня озера-хранилища данных стали операционной основой для агентного искусственного интеллекта, предоставляя надежные, управляемые и данные реального времени, необходимые интеллектуальным агентам для рассуждений и действий, пишет в корпоративном блоге Ноэль Юханна, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>По мере того, как ИИ переходит от генерации инсайтов к выполнению бизнес-процессов, организациям необходимо переосмыслить ожидания от своей lakehouse-платформы. Эта эволюция переопределяет оценку поставщиков, приоритизируя готовность к ИИ, доверие, открытость и операционный интеллект, а не производительность хранения и запросов.</p> <h3>Новые возможности lakehouse поддерживают сценарии использования агентного ИИ</h3> <p>Чтобы помочь организациям справиться с этим сдвигом, в отчете «Forrester Wave: Data Lakehouses, Q3 2026» представлена оценка 14 ведущих поставщиков lakehouse. Она отражает меняющуюся роль озер-хранилищ в эпоху ИИ и определяет возможности, которые будут отличать платформы, способные поддерживать агентный ИИ корпоративного масштаба. Хотя традиционные возможности управления данными остаются важными, в отчете ясно показано, что готовые к будущему озера-хранилища должны также служить исполнительным уровнем для приложений, управляемых ИИ.</p> <p>Ключевые выводы из отчета заключаются в следующем:</p> <ul> <li> <strong>Lakehouse</strong> <strong>становится исполнительным уровнем для агентного ИИ.</strong> Озеро-хранилище больше не ограничивается хранением и предоставлением данных для аналитики. Кроме этого оно должно постоянно предоставлять надежный, управляемый контекст реального времени, который агенты ИИ могут использовать для рассуждений, принятия решений и действий. Этот сдвиг коренным образом меняет подход организаций к оценке поставщиков. Вместо того чтобы отдавать приоритет только возможностям хранения, покупатели должны оценивать, насколько эффективно озеро-хранилище данных поддерживает ИИ-нативные рабочие нагрузки, операции в режиме реального времени и интеграцию с корпоративными экосистемами ИИ.</li> <li><strong> Доверие является основой готового к ИИ озера-хранилища данных.</strong> Поскольку агенты ИИ все чаще принимают автономные решения, недостатки в качестве, управлении, отслеживании происхождения или безопасности данных становятся рисками выполнения, а не аналитическими ограничениями. Организациям следует отдавать приоритет lakehouse-платформам, которые включают в себя управление данными, автоматическое отслеживание их происхождения, детальный контроль доступа, непрерывный мониторинг качества данных и обеспечение соблюдения политик в качестве основных возможностей платформы.</li> <li><strong> Открытые архитектуры имеют решающее значение для долгосрочного успеха ИИ. </strong>ИИ быстро развивается, требуя от организаций интеграции множества моделей, фреймворков оркестрации, облачных сред и сервисов данных. Озера-хранилища, построенные на основе открытых форматов таблиц, совместимых стандартов метаданных, расширяемых API и обмена данными без копирования, обеспечивают необходимую гибкость для адаптации, одновременно снижая зависимость от поставщика. При оценке поставщиков следует учитывать совместимость экосистем и архитектурную открытость как стратегические отличительные черты, а не как дополнительные функции.</li> <li><strong> Обеспечение использования ИИ является новым конкурентным преимуществом </strong><strong>lakehouse</strong><strong>-платформ.</strong> Хранение данных, масштабируемость и производительность запросов уже стали обязательными условиями. Сегодня отличительными чертами озер-хранилищ являются предоставление контекста реального времени, семантический интеллект, нативные векторные возможности и готовые к использованию ИИ сервисы данных, которые позволяют автономным агентам извлекать, анализировать и действовать на основе корпоративных данных. Организациям следует оценивать поставщиков на основе того, насколько эффективно их платформы поддерживают ИИ, поскольку эта возможность будет определять ценность для предприятий и конкурентное преимущество следующего поколения платформ данных.</li> </ul> <h3>Apache Fluss — новое lakehouse-нативное потоковое хранилище</h3> <p>Фонд Apache Software Foundation (ASF), глобальный центр разработки ПО с открытым исходным кодом, объявил о том, что Apache Fluss стал проектом верхнего уровня (TLP).</p> <p>Apache Fluss — это опенсорсная система потокового хранения для аналитики реального времени и ИИ. Она предоставляет уровень данных реального времени для lakehouse, объединяя потоковые данные, постоянно обновляемые таблицы и исторические данные lakehouse посредством общей абстракции таблиц. Fluss интегрируется с вычислительными движками, включая Apache Flink и Apache Spark, а также с открытыми lakehouse-форматами, включая Apache Paimon, Apache Iceberg, Apache Hudi и Lance.</p> <p>«Архитектура Lakestream от Fluss объединяет потоки данных с данными lakehouse, обеспечивая lakehouse возможности режима реального времени и одновременно сокращая дублирование данных и сложность конвейера обработки. Она доказала свою эффективность в масштабе основных производственных нагрузок электронной коммерции Alibaba, Это побудило нас открыть исходный код и передать Fluss в ASF. Я надеюсь, что Fluss станет открытой основой данных для озер-хранилищ реального времени и будет способствовать развитию аналитики и ИИ в открытой экосистеме данных», — сказал Фэн Ван, руководитель Open Data Platform в Alibaba Cloud.</p> Корпоративные озера-хранилища данных (data lakehouse) эволюционируют. Изначально предназначенные в первую очередь для … article https://www.itweek.ru/themes/detail.php?ID=235349 Fri, 14 Aug 2026 15:23:21 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие передний край глобальной исследовательской повестки. Среди выделенных по итогам 2025 года 890 фронтиров самые высокие значения индекса значимости у тематик, связанных с решением экологических проблем, цифровой трансформацией и психическим здоровьем человека.</p> <p>Климатическая повестка выходит за рамки прогнозирования изменений температуры. Исследования также охватывают поведение людей, оценку рисков и адаптацию к новым условиям, что требует объединения естественных и общественных наук. Одновременно меняется сам подход к взаимодействию с природой: антропоцентрическая парадигма, ставящая во главу угла интересы человека, постепенно уступает место экоцентрической.</p> <p>Рост городского населения и расширение урбанизированных территорий меняют структуру землепользования, усиливают нагрузку на природные ресурсы. Важным инструментом адаптации и планирования территорий становятся геоинформационные системы. В городах формируются локальные климатические эффекты, включая острова тепла и изменение режима осадков, повышается уязвимость к экстремальным погодным явлениям. Смягчать эти эффекты могут экосистемные услуги — секвестрация углерода, фильтрация загрязнителей и регулирование гидрологического режима. Гидротермальная карбонизация органических отходов позволяет получать энергетически ценные продукты и богатые углеродом материалы, что способствует развитию экономики замкнутого цикла.</p> <p>Необходимость снизить негативное воздействие на окружающую среду стимулирует развитие возобновляемой и водородной энергетики. Дальнейшее развитие топливных элементов и электролизеров во многом зависит от создания эффективных катализаторов. Наиболее перспективными считаются наночастицы благородных металлов, а более доступными альтернативами — оксиды никеля и кобальта и карбиды железа. В солнечной энергетике разрабатываются фотоэлектрические элементы нового поколения, в частности перовскитные и тандемные структуры, а также прозрачные проводящие покрытия.</p> <p>Для решения сложных задач уже недостаточно только наращивать вычислительные мощности: требуется одновременно собирать данные, моделировать процессы и управлять ими. В 2025 году заметно усилилась синергия вычислительных и измерительных технологий.</p> <p>ИИ из инструмента анализа превращается в технологию действия. Обработка данных переносится на периферию (edge) — непосредственно в устройства, датчики и локальные модули. В основе систем периферийного ИИ лежит машинное обучение, позволяющее интерпретировать разнородные и зашумленные данные без обращения к облачным центрам.</p> <p>В интеллектуальные системы управления все чаще встраивают нейросети, например для координации групп автономных роботов или управления роботизированными манипуляторами. Широко применяется глубокое обучение, позволяющее работать с неструктурированными данными и оперативно реагировать на изменения.</p> <p>Чем сложнее модели, тем важнее регуляризация. В критических областях применения ИИ особенно высоки требования к устойчивости моделей и способности точно обрабатывать новые данные. Например, медицинские диагностические системы должны надежно работать для пациентов, чьи демографические характеристики отличаются от представленных в обучающей выборке.</p> <p>Разработки на стыке ИИ и физики сокращают путь сигнала от регистрации до его интерпретации. Усиливать и стабилизировать сигналы позволяют резонаторные технологии, применяемые в высокочувствительных радиочастотных и сенсорных устройствах. Так, фотонные «электронные носы» на основе массивов микрорезонаторов формируют уникальный «оптический отпечаток» анализируемой смеси, а локальный ИИ-интерфейс распознает его непосредственно на чипе.</p> <p>Спектроскопия, выделенная в самостоятельный фронтир, позволяет увидеть то, что прежде оставалось скрытым. В 2025 г. коллаборация BASE в ЦЕРН впервые продемонстрировала применение крайне значимой для изучения асимметрии материи и антиматерии когерентной спектроскопии квантовых переходов спина одиночного антипротона. В прикладной сфере поверхностно-усиленная рамановская спектроскопия (SERS) на наночастицах позволяет регистрировать сигналы отдельных молекул и в комбинации с ИИ-анализом спектров разрабатывать методы цитологической диагностики.</p> <p>В классических дисциплинах такой объединенный инструментарий обеспечивает переход от наблюдения к целенаправленному управлению процессами на микро- и наноуровне. В физике совершенствуются методы управления светом, электрическими сигналами, магнитными состояниями и квантовыми эффектами, которые используются в системах спутниковой связи и навигации, жидкокристаллических дисплеях, кремниевых фотонных устройствах и голографическом хранении данных. В химии сочетание измерений и моделирования поддерживает молекулярный дизайн: изучение процессов гидрогенизации и динамики адсорбции в нестационарных условиях помогает создавать материалы и катализаторы с заданными свойствами. Такие разработки способствуют миниатюризации оптических чипов, росту скорости обработки информации и плотности ее записи.</p> <p>Крупный блок ведущих фронтиров образуют исследования в области развития человеческого потенциала и связанные с поддержанием здоровья как человека, так и животных. Их общая черта — внимание к раннему выявлению рисков: от молекулярных и клеточных изменений до механизмов психических расстройств и факторов развития ребенка.</p> <p>В биомедицине и ветеринарии биомаркеры позволяют отслеживать изменения задолго до появления выраженных клинических признаков, обеспечивая переход от симптоматической к ранней, точной и персонализированной диагностике. Анализ сывороточных биомаркеров помогает выявлять воспалительные процессы, метаболические нарушения, опухоли, повреждения тканей и др. Другой фронтир связан с антиоксидантами, подавляющими свободнорадикальное окисление, которое может запускать и усиливать различные патологические процессы.</p> <p>Одна из центральных тематик этого блока — ментальное здоровье. Возрастает значение исследований, направленных на выявление биологических, психологических и средовых механизмов формирования психических расстройств, а также факторов, способствующих сохранению психологической устойчивости. Профилактика ментальных расстройств затрагивает и сферу воспитания детей, согласно результатам исследований, качество связи родителя с ребенком в раннем возрасте оказывает прямое влияние на метилирование ДНК и формирование архитектуры нейронных сетей мозга. Эта проблематика имеет не только медицинское, но и социальное, экономическое и демографическое значение, поскольку ментальное здоровье во многом определяет уровень качества жизни человека.</p> <p>Карта ведущих научных фронтиров отражает поиск системных ответов на глобальные вызовы. Сохранение планеты становится фокусом экологических исследований, работы в области биомедицины направлены на повышение качества жизни человека, фундаментальную основу новых решений обеспечивают биология, физика и химия, цифровые технологии расширяют возможности измерения и управления. Перечень фронтиров может служить ориентиром при выборе тем исследований и определении приоритетов поддержки науки и технологий.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие … message https://www.itweek.ru/themes/detail.php?ID=235347 Fri, 14 Aug 2026 10:25:07 +0300 <p><em>Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться в людей, зная, что те уйдут, — и что это говорит о рынке IT-кадров?</em></p> <p>Хороший DevOps-инженер готовится к докладу на конференции — шлифует слайды, прогоняет демо. Он еще не знает, что через два месяца уволится. Не потому что плохо платили или надоело — просто выступил, к нему подошли, предложили больше. Это не провал HR, а нормальная механика рынка, в которой облачные провайдеры играют специфическую роль — они растят специалистов, которых потом хотят все.</p> <h3>Рынок сжался — но не для всех</h3> <p>В 2025 году вакансий для айтишников стало на 26% меньше, чем годом ранее. Казалось бы, передышка для работодателей. Но облачные провайдеры её не почувствовали: клиентская база росла, крупный бизнес ускорял переход в облако, и спрос на опытных инженеров оставался высоким. По <a href="https://www.techtarget.com/whatis/feature/Tech-job-market-statistics-and-outlook">данным </a>TechTarget, 87% технических директоров по-прежнему говорят, что не могут найти нужных специалистов.</p> <p>Проблема структурная. Технологические навыки устаревают примерно за 2,5 года, а университеты обновляют программы куда медленнее. Система подготовки кадров просто не рассчитана на такую скорость изменений — и отрасль давно научилась справляться с этим своими силами.</p> <h3>Как устроена карьерная труба</h3> <p>В провайдерской среде есть устойчивая модель, которую внутри индустрии неформально называют «трубой». Специалист приходит с минимальными навыками — в техподдержку, на дежурную смену, в администрирование. Работает на больших объемах и разнообразных задачах. Постепенно растёт. Через несколько лет из него получается инженер с реальной экспертизой.</p> <p>Если посмотреть на DevOps-инженеров в облачных командах, то 9 из 10 — те, кто проросли внутри компании, а не пришли готовыми. Это не случайность и не особенность одного провайдера. Это общая логика отрасли: в отличие от BigTech, где специалист приходит уже сформированным под конкретную задачу, провайдерская среда по природе своей многоуровневая. Здесь есть ступеньки, на которых можно учиться в процессе работы — и это работает.</p> <h3>Чем облако привлекает инженера</h3> <p>Объяснять выбор в пользу провайдера только деньгами — упрощение. Суть в характере работы.</p> <p>DevOps в корпоративном IT обслуживает одну команду, настраивает один пайплайн, работает по гайдам. Задача решена — переключается на следующую, примерно такую же. В облачном провайдере задача другая: не развернуть инфраструктуру для своей команды, а создать сервис, который потом будет предоставляться тысячам клиентов в автоматизированном режиме. Это ближе к разработке, чем к эксплуатации. Другой уровень сложности, другое мышление.</p> <p>Именно поэтому опыт из облака ценится на рынке: инженер, проработавший в провайдере, приходит в BigTech с насмотренностью и навыками, которые там сложно получить иначе. Рынок это подтверждает — по <a href="https://enigmai.ru/salary/devops/devops-salary-2026/">данным</a> Enigma Intelligence, наиболее востребованными в <nobr>2025-2026</nobr> годах стали специалисты в Platform Engineering и DevSecOps, то есть именно в том, чем занимаются облачные команды каждый день.</p> <h3>Когда специалист уходит</h3> <p>Конференции стали обязательной частью профессиональной жизни инженера. Выступить с докладом — значит показать экспертизу, прокачать личный бренд, поделиться опытом с сообществом. Всё это так. Но у этой медали есть обратная сторона: человек всё о себе рассказал, экспертизу показал, контакты на последнем слайде оставил. Хедхантерам остается только подойти после секции.</p> <p>Однажды так мы потеряли одного из сильных инженеров: выступил с докладом, познакомился с нужным человеком и через два месяца принял оффер. Обидно? Отчасти. Неожиданно? Нет. Такова механика открытого рынка — и мы сами участвуем в ней с обеих сторон.</p> <p>Переходы между провайдерами — обычная история. Специалисты идут туда, где больше объёмы, интереснее задачи, выше зарплата. Это работает в обе стороны. Главное — понимать, что удержать человека силой невозможно, а вот создать среду, из которой не хочется уходить, — вполне.</p> <p>К слову, к клиентам инженеры уходят редко — и это не случайно. В облачном провайдинге специалист не привязан к конкретному заказчику: с ним работает команда, контакты ситуативны, личного коннекта, который мог бы перерасти в оффер, почти не возникает. Это механика аутсорс-разработки, не провайдинга.</p> <h3>Рынок труда: от голода к насыщению</h3> <p>Ещё полтора года назад картина была другой. Вакансия могла висеть полгода — и ни одного подходящего кандидата, даже при конкурентной зарплате. Дефицит ощущался физически: планы запуска продуктов сдвигались, нагрузка на команды росла.</p> <p>С лета 2025 года ситуация изменилась. Крупные компании начали тихие сокращения: официальных объявлений нет, но мидлы с именитым бэкграундом появились на рынке. Параллельно в BigTech заработала механика «банки» — когда проект закрывается, команду не распускают сразу, а дают несколько месяцев на поиск места внутри. Кто не находит — выходит на рынок.</p> <p>Итог: рынок соискателя превратился в рынок работодателя. Вакансии закрываются быстрее, а зарплатная гонка утихает. 47% IT-специалистов <a href="https://www.newstaff.ru/trendy-najma-it-specialistov-v-2025-godu-chto-menyaetsya-na-rynke/">называют</a> главным фактором при выборе работы гибкий формат и возможность роста — зарплату ставят на первое место только 18%. Для провайдеров, которые исторически делают ставку на развитие сотрудников, — это сигнал в нужную сторону.</p> <h3>Что дальше</h3> <p>Рост облачного рынка в России замедляется: <nobr>35-40%</nobr> несколько лет назад, около 29% в 2024 году, прогноз на <nobr>2026-й —</nobr> порядка 24%. При таком замедлении найм тоже будет сжиматься. Компании, которые в период бума набирали людей «с запасом», сейчас пересматривают ФОТ и смотрят, что команды реально делают.</p> <p>Но структурная история с «трубой» никуда не денется — и в этом, пожалуй, главное. Провайдеры продолжат выращивать специалистов снизу, потому что иначе не работает. Готовых инженеров с нужным стеком на рынке не хватало и не будет хватать, особенно с учётом того, что автоматизация убирает начальные позиции и подпитка снизу для всей отрасли постепенно иссякает.</p> <p>На Западе это уже институализировалось: Microsoft запустила Datacenter Academy, AWS строит партнёрства с техническими школами через Workforce Accelerator — провайдеры сами пишут учебные программы, поставляют оборудование для лабораторий, финансируют стипендии. В России этот путь только начинается.</p> <p>Инженер, который вырос в провайдере и ушел к конкуренту или в BigTech, — это не только потеря. Он знает продукт изнутри, иногда рекомендует его клиентам, иногда возвращается. Это другая форма лояльности. И она тоже работает.</p> <p>#IMAGE_235348#</p> Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться … article Сергей Рыжков, руководитель онлайн-продаж и аналитики Рег.облака https://www.itweek.ru/themes/detail.php?ID=235345 Fri, 14 Aug 2026 10:08:55 +0300 <p><em>Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» задачу, но реальным ограничением для их внедрения станет корпоративный контроль — смогут ли технологические руководители проверять действия агентов, управлять их использованием и сохранять бизнес-смысл в условиях фрагментации, пишет в корпоративном блоге Фарам Медхора, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Фрагментация — это реальность работы ERP-систем: согласно исследованию Forrester «Enterprise Applications Software Survey 2026», только 7% лиц, принимающих решения по ERP на предприятиях, используют только один экземпляр системы. В сложной многоэкземплярной инфраструктуре агенты будут наследовать региональные варианты, приобретенные системы и противоречивые определения, что выявит недостатки управления, которые технологические руководители могли терпеть во времена, когда автоматизация оставалась под контролем человека.</p> <p>Если технологические руководители хотят начать пожинать плоды агентных ERP-систем, им не стоит начинать с каталога агентов. Вместо этого им следует начать с модели управления, чтобы понять, насколько они смогут подтвердить, оценить и защитить автономность с помощью переносимости.</p> <p> #IMAGE_235346#</p> <h3>Контроль за доказательствами: верификация — это новый скоростной лимит ERP</h3> <p>Агентная ERP создает проблему контроля. Каждое действие агента требует подтверждения: кто его одобрил, какая учетная запись его выполнила, какие данные были использованы и кто несет ответственность за результаты, когда действия агента достигают этапов проводок, сверки или закрытия.</p> <p>Эта проблема контроля затрагивает наиболее уязвимые места в большинстве ERP-систем: управление данными, контроль и безопасность. Согласно нашим данным, 65% пользователей ERP оценивают точность данных как сложную проблему, и 64% говорят то же самое о безопасности и соответствии нормативным требованиям. Риски уже очевидны. Уязвимость BodySnatcher (CVE-2025-12420) показала, как некорректная аутентификация агентов может позволить осуществлять привилегированное подмену личности в ServiceNow, а дело Moffatt против Air Canada (2024) подтвердило, что компании (а не поставщик) остаются ответственными за предоставленную ИИ информацию о клиентах.</p> <p>Агентную ERP-систему следует рассматривать в первую очередь с точки зрения обеспечения контроля, а во вторую — с точки зрения автоматизации. Сегментируйте автономность по классам транзакций: расширяйте возможности консультативных агентов сейчас, требуйте полной отслеживаемости для контролируемого выполнения и откладывайте автономное выполнение до тех пор, пока команды не смогут доказать ответственность за исключения, предоставить аудиторские доказательства и возможность отката.</p> <p>Для этого вам потребуется перейти к стандартизированному ядру, которое вы откладывали, поскольку агенты будут усиливать вариативность процессов, данных и контроля. Вам также потребуется сначала провести каждого кандидата на автоматизацию через стандартизацию, и если вы не можете его стандартизировать, это означает, что вы не можете его безопасно автоматизировать.</p> <h3>Контроль за ценой: счетчик — это новый контроль объема работ</h3> <p>Ценообразование ERP-систем движется в сторону моделей, основанных на использовании, кредитных пулах и многоуровневых счетчиках. Это переносит риск с прайс-листа поставщика на ваш текущий тариф. Большинство CIO по-прежнему договариваются о продлении как о фиксированных затратах, но эта привычка устареет по мере роста использования агентов. Как только агенты начнут применяться в повседневной работе, использование может превысить бюджетные рамки. Фактически, 30% руководителей, принимающих решения в сфере корпоративного SaaS, уже отмечают непредсказуемость ценообразования на основе использования как проблему.</p> <p>Мы уже видим, как контроль дает сбой. Uber исчерпала свой бюджет на ИИ за несколько месяцев после того, как применение Claude Code широко распространилось среди инженеров. Salesforce учитывает использование Agentforce через Flex Credits с учетом превышения лимитов. Покупатели RISE with SAP колеблются, когда не могут самостоятельно отслеживать лицензирование и использование.</p> <p>Это означает, что технологические руководители никогда не должны подписывать соглашения об использовании агентной ERP без телеметрии со стороны покупателя, жестких ограничений, триггеров превышения лимитов и сценариев потребления, смоделированных финансовыми специалистами. Помните, если поставщик контролирует и счетчик, и интерпретацию показаний счетчика, вы не контролируете программу.</p> <h3>Контроль за переносимостью: следующая проблема привязки к поставщику — семантическая</h3> <p>Перенос ваших данных к новому поставщику больше не является трудной задачей. Трудность заключается в том, чтобы разобраться, как старый поставщик определял ваш бизнес. Если ваши KPI, бизнес-сущности и связи данных построены вокруг модели одного поставщика, вы остаетесь привязанными к нему даже после миграции данных. Это то, что мы называем семантической зависимостью. Открытые стандарты, такие как MCP и Agent2Agent, которые могут снизить барьеры для подключения, теперь развиваются под эгидой Linux Foundation, но этого недостаточно (даже близко) для обеспечения переносимости сути бизнеса.</p> <p>Технологическим лидерам необходимо ознакомиться с новым термином: семантическая переносимость. В дальнейшем вам нужно будет включать семантическую переносимость в каждое продление контракта. Это означает требование прав на экспорт определений KPI, моделей сущностей и связей основных данных, прежде чем вы будете добавлять больше интеллектуальных функций в контекстный слой поставщика. Это крайне важно, потому что то, что вы не можете экспортировать сегодня, завтра станет вашей стоимостью перехода.</p> <h3>Масштабируйте операционную модель до развертывания агентов</h3> <p>Наиболее эффективные CIO не будут гнаться за самым эффектным помощником. Они сначала определят ответственность: кто утверждает агентов, кто отвечает за ожидания, кто контролирует бюджеты потребления и кто управляет семантикой. Именно с этой моделью будут работать ваши финансовые директора, аудиторы и клиенты.</p> Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» … article https://www.itweek.ru/themes/detail.php?ID=235343 Fri, 14 Aug 2026 09:57:10 +0300 <p>Доменная отрасль во многих странах постепенно интегрируется с системами цифровой идентификации. Государства рассматривают доменную инфраструктуру как часть общей системы кибербезопасности, устойчивости онлайн-сервисов и управления онлайн-активами. Россия также движется в этом направлении: с сентября 2026 года для доменов в зонах .ru, .рф и .su ключевые операции будут связаны с подтверждением администратора через ЕСИА.</p> <p>Рассмотрим, как меняется регулирование доменной отрасли в разных странах, как российский подход соотносится с международной практикой и что новые требования означают для бизнеса.</p> <h3>В России меняются правила регистрации доменов</h3> <p>С 1 сентября 2026 года вступают в силу новые правила регистрации и продления доменов в зонах .ru, .рф и .su. Администраторам потребуется обязательная идентификация через ЕСИА — систему авторизации на портале «Госуслуги». Изменения закреплены федеральным <a href="https://www.consultant.ru/document/cons_doc_LAW_523115/">законом № <nobr>569-ФЗ</nobr></a>.</p> <p>Новые требования распространяются на все категории администраторов. Физическим лицам и индивидуальным предпринимателям понадобится подтвержденная учетная запись на Госуслугах. Юридическим лицам необходимо зарегистрировать организацию на портале и назначить сотрудника с подтвержденными полномочиями для управления доменами. Иностранные граждане и компании также должны будут учитывать новые требования: пройти идентификацию через ЕСИА при наличии такой возможности либо заранее выбрать иную допустимую модель управления доменом. Некоторые регистраторы предлагают решение «Доверенный администратор» (trustee-сервис), которое позволяет управлять доменом в зонах .ru, .рф и .su без идентификации через Госуслуги. Домен регистрируется на российское юрлицо с подтвержденной записью в ЕСИА, а вы сохраняете полный контроль через свой личный кабинет.</p> <p>Обязанность указывать достоверные данные при регистрации доменов существовала и раньше: администраторы должны были предоставлять регистраторам актуальные паспортные, контактные и регистрационные данные. Однако проверка этой информации в значительной степени оставалась ручной и зависела от предоставленных документов.</p> <p>Теперь система предполагает цифровое подтверждение данных через государственную инфраструктуру идентификации. Это должно повысить прозрачность доменной среды, упростить установление владельцев интернет-ресурсов и усилить меры против мошеннических и противоправных онлайн-активностей.</p> <p>Для пользователей регистрация и продление доменов в стандартных сценариях также станут проще: часть данных будет автоматически заполняться на основе информации из ЕСИА без необходимости отдельно загружать документы и подтверждения. Но для компаний с неупорядоченным доменным портфелем новые правила могут выявить старые проблемы: домены, оформленные на бывших сотрудников, подрядчиков, старые юридические лица или аккаунты, к которым давно нет доступа.</p> <h3>Почему государства стали внимательнее к доменной инфраструктуре</h3> <p>Рост внимания к доменной отрасли напрямую связан с вопросами кибербезопасности. Домены регулярно используются в фишинговых атаках, распространении вредоносного ПО, мошеннических схемах и управлении ботнетами. Для атакующих домен остается удобной точкой входа: он помогает имитировать бренд, запускать поддельные лендинги, маскировать инфраструктуру и перенаправлять пользователей на вредоносные ресурсы.</p> <p>Проблема носит глобальный характер. По данным <a href="https://interisle.net/insights/phishing-landscape-2025-an-annual-study-of-the-scope-and-distribution-of-phishing">исследования</a> американской аналитической компании Interisle Consulting Group, в 2025 году количество доменов, использованных в фишинговых атаках по всему миру, превысило 1,5 млн., а общее число зарегистрированных фишинговых кампаний приблизилось к 2 млн.</p> <p>Российский сегмент интернета также сталкивается с ростом подобных угроз. По <a href="https://domainpatrol.ru/upload/iblock/676/kq5hwn3umunbtr2b21ndavh17ptw6is1/KO_2025_rus.pdf">данным</a> проекта «Доменный патруль» Координационного центра .RU/.РФ, в 2025 году в рунете заблокировали более 42 тыс. фишинговых сайтов и свыше 10 тыс. ресурсов, распространявших вредоносное ПО.</p> <p>На этом фоне государства рассматривают доменную инфраструктуру как часть системы цифровой устойчивости и кибербезопасности. Возможность быстро установить владельца интернет-ресурса позволяет оперативнее реагировать на инциденты, снижать масштабы злоупотреблений и выстраивать взаимодействие между регистраторами, ИБ-службами и правоохранительными органами.</p> <p>Еще один фактор — повышение прозрачности цифровой среды. Для регуляторов важно понимать, кто управляет ключевыми онлайн-активами внутри национального доменного пространства. Это позволяет снизить риски анонимного использования доменов в противоправной деятельности и сделать управление цифровой инфраструктурой более предсказуемым при взаимодействии бизнеса и государства. Для бизнеса эта логика тоже важна. Домен давно перестал быть просто адресом сайта: он связан с почтой, клиентским трафиком, рекламными кампаниями, API-интеграциями, SSL/TLS-сертификатами и доверием пользователей. Потеря контроля над доменом может привести не только к недоступности сайта, но и к сбоям в сервисах, утрате почтового контура или репутационному ущербу.</p> <h3>Какие модели идентификации действуют в разных странах</h3> <p>Подходы к идентификации владельцев доменов отличаются в зависимости от страны, однако почти все крупные юрисдикции движутся в сторону более прозрачной модели регулирования.</p> <p>В Евросоюзе изменения связаны с директивой NIS2, которая требует от регистраторов и реестров обеспечивать проверку и актуальность данных владельцев доменов. Речь идет не о централизованной государственной идентификации, а о повышении прозрачности доменной среды и снижении количества анонимных или недостоверных регистраций.</p> <p>Германия стала одной из первых стран, внедривших такие требования. Владельцы доменов должны подтверждать контактные данные, а при подозрительной активности регулятор или регистратор вправе запросить дополнительную верификацию. Европейская модель в большей степени носит риск-ориентированный характер: углубленная проверка обычно применяется при выявлении подозрительных действий или жалоб. В случае отказа от подтверждения данных домен может быть ограничен в обслуживании или заблокирован.</p> <p>Азиатские страны чаще используют более формализованные механизмы проверки личности или регистрационных данных. В Китае действует система real-name verification с обязательной проверкой документов владельца домена. В Индии регулирование также движется в сторону усиления KYC/e-KYC-процедур для доменных регистраций, в том числе на фоне судебной практики и обсуждения мер против фишинга и мошеннических сайтов.</p> <p>В ряде стран регулирование доменной отрасли строится вокруг принципа локального присутствия. Например, регистрация доменов в Австралии или Сингапуре может требовать локализации бизнеса, наличия национального регистрационного номера или использования trustee-сервисов, когда формальным администратором выступает местный регистратор, а фактическое управление остается за иностранной организацией.</p> <h3>Как устроена российская модель идентификации</h3> <p>Российская система идентификации администраторов доменов строится вокруг интеграции регистраторов с ЕСИА — Единой системой идентификации и аутентификации, используемой на портале Госуслуг.</p> <p>При регистрации или продлении домена администратор должен будет авторизоваться через Госуслуги и подтвердить свою учетную запись. Для физических лиц и индивидуальных предпринимателей потребуется подтвержденный аккаунт пользователя. Юридическим лицам необходимо зарегистрировать организацию в ЕСИА и назначить сотрудника с подтвержденными полномочиями для управления доменами.</p> <p>После авторизации сведения о владельце домена будут автоматически подтверждаться через государственную систему идентификации и передаваться регистратору в рамках установленного регулирования. Это позволит отказаться от значительной части ручных проверок и отдельной загрузки документов при стандартных сценариях регистрации и продления доменов.</p> <p>Российская модель сочетает элементы нескольких международных подходов, но при этом формирует собственную систему регулирования. В отличие от европейской модели, где углубленная проверка обычно применяется в ответ на подозрительную активность или жалобы, российский подход предполагает превентивную идентификацию администратора до выполнения ключевых операций с доменом.</p> <p>При этом российская система опирается не на новую отдельную процедуру, а на уже существующую цифровую инфраструктуру ЕСИА. Для пользователей это снижает количество ручных действий, а для регистраторов и государства создает более устойчивую модель подтверждения данных администратора домена.</p> <h3>Как администраторам доменов в компаниях подготовиться к новым правилам</h3> <p>До вступления новых требований остается немного времени, поэтому компаниям стоит провести аудит доменного портфеля и проверить текущую модель управления онлайн-активами.</p> <p>Бизнесу важно:</p> <ul> <li> собрать перечень всех доменов, используемых компанией</li> <li> проверить связанные элементы инфраструктуры: DNS-записи, SSL/TLS-сертификаты, почтовые настройки, редиректы, поддомены и домены рекламных кампаний;</li> <li> проверить, на кого зарегистрированы домены и актуальны ли данные администраторов;</li> <li> убедиться, что критически важные домены оформлены на юридическое лицо компании, а не на сотрудников, подрядчиков или внешних разработчиков;</li> <li> проверить, у кого есть доступ к учетным записям, через которые осуществляется управление доменами;</li> <li> зарегистрировать организацию в ЕСИА и определить сотрудников, ответственных за администрирование доменов;</li> <li> убедиться, что у ответственных сотрудников есть подтвержденные полномочия для работы через Госуслуги.</li> </ul> <p>Особое внимание стоит уделить доменам, зарегистрированным на бывших сотрудников или сторонних исполнителей. После запуска обязательной идентификации отсутствие прямого контроля над учетной записью администратора может осложнить продление домена, подтверждение данных или восстановление доступа к онлайн-ресурсам компании.</p> <p>Также стоит определить владельца процесса внутри компании. На практике доменами могут заниматься ИТ, ИБ, юристы, маркетинг и подрядчики, но при отсутствии единого ответственного доменный портфель быстро становится непрозрачным. Минимальный набор контроля — единый реестр доменов, регламент продления, порядок выдачи доступов, резервные контакты и регулярная проверка критичных доменных операций.</p> <p>Для бизнеса новые правила управления доменами — это повод проверить, кто фактически контролирует ключевые онлайн-адреса, где находятся доступы и можно ли без задержек подтвердить права на домен. Чем раньше компания проведет аудит доменного портфеля, тем ниже риск столкнуться с проблемами при продлении, изменении DNS-настроек или восстановлении доступа к онлайн-сервисам. В итоге подготовка к ЕСИА становится частью грамотного управления цифровой инфраструктурой — так же, как контроль учетных записей, сертификатов, почты и других критичных сервисов.</p> <p>#IMAGE_235344#</p> Доменная отрасль во многих странах постепенно интегрируется с системами цифровой идентификации. Государства … article Георгий Казаров, руководитель отдела доменов Руцентра https://www.itweek.ru/themes/detail.php?ID=235342 Thu, 13 Aug 2026 16:27:50 +0300 <p>MWS Cloud, входящая в МТС Web Services (MWS), проанализировала потребление китайских больших языковых моделей российскими компаниями на основе данных платформ MWS GPT Model Hub и MWS GPT. В первом полугодии 2026 года объём потребления более чем в 11 раз превысил показатель за весь 2025 год. Наиболее востребованными стали семейства Qwen, GLM и Kimi. Рынок предоставления LLM из облака в 2026 году достигнет почти 1,5 млрд рублей.</p> <p>В 2025 году на работу с китайскими генеративными моделями российские компании израсходовали 39,1 млрд токенов. В первом полугодии 2026 года потребление превысило 400 млрд токенов, увеличившись в 11,3 раза.</p> <p>Основными пользователями платформы являются представители крупного бизнеса. Они чаще всего применяют LLM для автоматизации клиентского взаимодействия: запускают чат-ботов для круглосуточной поддержки без участия оператора, генерируют и персонализируют маркетинговый контент — от текстов рассылок и описаний товаров до рекламных объявлений, — а также автоматизируют анализ обратной связи: выявляют тональность отзывов, категоризируют запросы и формируют сводные отчёты.</p> <p>Весь рынок LLM в России в 2026 году вырастет на 35% и составит порядка 19,6 млрд рублей. Облачный сегмент рынка, включающий предоставление доступа к LLM по модели SaaS и через API, в 2026 году достигнет почти 1,5 млрд рублей.</p> <p>На фоне растущего спроса и выхода новых моделей MWS Cloud почти вдвое расширила число больших языковых моделей в сервисе MWS GPT Model Hub, доведя их количество до 17. Главными пополнениями платформы стали GLM 5.2, опенсорс LLM от компании Z.AI, которая была признана лучшей LLM в агентских задачах. MWS Cloud стала первой компанией в России, развернувшей модель у себя в облаке. Кроме того, в сервисе появились первые модели распознавания речи (ASR) и синтеза речи (TTS), а также реранкеры для повышения качества поиска и RAG-пайплайнов. Сервис доступен в рамках платформы MWS Cloud Platform.</p> <p>Среди новых LLM — GLM 5.2, Kimi K2.6, Qwen3.6, Gemma 4, GPT OSS и другие. Каталог из 17 моделей даёт разработчикам возможность подбирать модель под конкретную задачу с учётом требований к качеству, скорости и стоимости. Все модели доступны через единый OpenAI-совместимый API, что упрощает интеграцию и переключение между ними.</p> MWS Cloud, входящая в МТС Web Services (MWS), проанализировала потребление китайских больших языковых моделей российскими … message https://www.itweek.ru/themes/detail.php?ID=235340 Thu, 13 Aug 2026 09:52:19 +0300 <p>Генеративный ИИ заметно изменил работу разработчиков. Создавать новый код стало проще и быстрее, чем когда-либо раньше. При этом потенциал генеративного ИИ в разработке уже подтверждается исследованиями. В ежегодном <a href="https://www.mckinsey.de/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value?utm_source">отчете</a> McKinsey «The State of AI» разработка программного обеспечения названа одной из областей, где технология быстрее всего переходит от экспериментов к практическому применению. Именно поэтому сегодня внимание постепенно смещается от вопросов внедрения к вопросам долгосрочных последствий такого ускорения.</p> <p>Но вместе с этим изменились и стимулы внутри разработки: во многих случаях написать новое решение оказывается проще, чем разобраться в существующем. Именно здесь начинает формироваться новый механизм накопления технического долга.</p> <p>Проблема заключается не в качестве генерации кода. Современные модели уже доказали свою эффективность: они ускоряют разработку, помогают быстрее реализовывать новые функции и снимают с инженеров значительную часть рутинной работы. Изменения происходят глубже. Вместе с ростом производительности меняется сама экономика инженерных решений. Написать новый код стало проще, тогда как понимание архитектуры, рефакторинг и сопровождение сложных систем не стали дешевле. В результате создать новую реализацию все чаще оказывается проще, чем развивать существующую.</p> <p>Рассмотрим, почему эта тенденция постепенно становится одним из ключевых факторов роста технического долга в эпоху генеративного ИИ.</p> <h3>Главный дефицит сместился</h3> <p>Долгое время одним из основных ограничений в разработке было создание кода. Генеративные модели существенно снизили стоимость этой работы. Сегодня многие задачи, которые раньше требовали значительных затрат времени, решаются за считанные минуты.</p> <p>Но вместе с этим изменился сам характер дефицита. Если раньше главным ограничением было написание кода, то сегодня все большую ценность приобретают понимание системы, проектирование архитектуры, ревью решений и анализ зависимостей между компонентами. Проще говоря, дефицитным становится не код, а способность понимать, как устроен продукт в целом.</p> <p>Это важное изменение. Потому что именно на уровне архитектуры принимаются решения, последствия которых определяют стоимость развития системы через несколько лет.</p> <h3>Изменилась экономика инженерных решений</h3> <p>Технический долг существовал всегда. Любой развивающийся продукт со временем накапливает компромиссы, временные решения и ограничения.</p> <p>Однако раньше разработчик чаще выбирал между двумя одинаково сложными вариантами: переработать существующую логику или написать новую. Сегодня этот баланс нарушен.</p> <p>Рефакторинг по-прежнему остается сложной задачей. Чтобы качественно изменить существующий механизм, необходимо понимать значительную часть системы, учитывать взаимосвязи между модулями и прогнозировать последствия изменений. Такие задачи требуют большого объема контекста и серьезного погружения в проект.</p> <p>Создать новое локальное решение значительно проще. Если появляется очередное бизнес-требование, зачастую быстрее написать отдельную реализацию, чем разбираться в существующей архитектуре. В моменте это выглядит рационально. Задача закрыта, сроки соблюдены, система продолжает работать.</p> <p>Именно поэтому технический долг редко возникает из-за плохих решений. Намного чаще он становится следствием решений, которые были логичны в конкретный момент времени.</p> <h3>Почему становится больше дублирующей логики</h3> <p>Эту тенденцию хорошо видно на крупных продуктах с большим количеством интеграций.</p> <p>Представим систему, в которой уже существует единый механизм работы с сетевыми запросами. Он отвечает за обработку ошибок, сериализацию данных, кеширование, поддержку различных версий API и другие инфраструктурные задачи.</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> <h3>Какие метрики становятся важнее скорости</h3> <p>Распространение генеративного ИИ заставляет по-новому смотреть и на оценку эффективности разработки.</p> <p>Количество написанного кода постепенно теряет смысл как показатель производительности. Схожий вывод <a href="https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/?utm_source">делают</a> и исследователи GitHub. В исследовании качества кода, созданного с помощью GitHub Copilot, авторы предлагают оценивать влияние ИИ не только через скорость разработки, но и через такие характеристики, как сопровождаемость, надежность и читаемость кода. Значительная часть этого объема может представлять собой будущий технический долг.</p> <p>Поэтому все большее значение приобретают другие показатели:</p> <ul> <li> стоимость изменений;</li> <li> объем ресурсов на сопровождение;</li> <li> количество инцидентов после релизов;</li> <li> скорость адаптации новых разработчиков;</li> <li> способность команды безопасно развивать существующую архитектуру.</li> </ul> <p>Именно такие метрики позволяют понять, становится ли продукт устойчивее или просто быстрее наращивает сложность. Не менее важно отслеживать, как изменения влияют на безопасность кода: увеличение числа локальных исключений и дублирующей логики постепенно усложняет аудит, сопровождение и поиск потенциальных уязвимостей.</p> <h3>Что в итоге</h3> <p>Генеративный ИИ не создает технический долг сам по себе. Он меняет условия, в которых принимаются инженерные решения. Создание нового кода становится дешевле. Понимание системы — нет.</p> <p>Поэтому главный вызов ближайших лет связан не с качеством генерации как таковым. Намного важнее сохранить архитектурную дисциплину в условиях, когда написать новую реализацию зачастую проще, чем разобраться в существующей.</p> <p>Чем активнее компании используют ИИ в разработке, тем большее значение будет иметь способность контролировать сложность систем. Именно она определит, станет ли ускорение разработки источником долгосрочного преимущества или приведет к накоплению проблем, которые придется решать уже следующим командам.</p> <p>#IMAGE_235341#</p> Генеративный ИИ заметно изменил работу разработчиков. Создавать новый код стало проще и быстрее, чем когда-либо раньше … article Султан Рамазанов, директор по искусственному интеллекту Umbrella IT