понедельник, 10 августа 2026 г.

Влияние ИИ на ERP

Предисловие


В статье в блоге под заголовком «Корпоративное бизнес-программное обеспечение и проблема запутанного хамелеона» Грег Литтл и Аарон Джаффе из компании Palantir утверждают, что, хотя определенный уровень стандартизации ERP-систем, несомненно, полезен, чрезмерная опора на подход «делать по правилам» может привести к упущенным возможностям, подавлению инноваций в продуктах и разочарованию клиентов.

Согласно прогнозам Palantir, традиционные ERP-системы быстро превращаются в обузу, поскольку их неустанное стремление к стандартизации посредством программного обеспечения может подавлять дифференциацию и инновации, даже несмотря на то, что революция в области искусственного интеллекта ставит эти качества на первое место. Потому что новый, стремительно развивающийся мир бизнеса, в который мы все сейчас вступаем, будет существенно отличаться от того, что происходит вокруг нас сегодня: более интеллектуальные цепочки поставок, сокращение сроков разработки продукции, неограниченный выбор для клиентов и кардинально иные организационные структуры, рабочие процессы, приоритеты и желаемые результаты.

Кроме того, у клиентов, будь то корпоративные клиенты или частные лица, будет больше выбора, возможностей и рычагов влияния, чем когда-либо прежде, — а это ставит во главу угла гибкость, адаптивность, скорость и инновации в бизнесе. Как говорится в блоге Palantir, почти все они в значительной степени несовместимы с традиционными ERP-системами, что приводит к крайне опасным несоответствиям между тем, чего хотят эти клиенты, и тем, что может предложить компания, использующая традиционные ERP-системы.

Ядро ERP-системы было спроектировано как стандартизированное, стабильное и надежное. Оно стало основой для финансов, управления персоналом, закупок и цепочки поставок — местом, где обеспечивались соответствие нормативным требованиям и подотчетность. ERP-система рассматривала каждый бизнес-процесс как нечто, что можно стандартизировать для каждой организации в рамках единой структуры. Если ядро ERP выходит из строя, то рушится все. Но где-то на этом пути защита этого ядра все чаще означала жертвование гораздо более важными вещами: идентичностью организации, ее дифференцированными процессами и способами, которыми она действительно создает ценность. Более глубокая проблема заключается в том, что традиционное корпоративное программное обеспечение было построено на жесткой логике, которая рассматривает каждую организацию как одинаковую. Традиционный подход ERP решал проблему стандартизации, но при этом подавлял уникальность. Именно в этой уникальности — будь то отличительная бизнес-модель, преимущество в цепочке поставок или реальность миссии — и заключается конкурентное преимущество. Уникальность — это не ошибка, которую программное обеспечение должно исправлять; это особенность, которая позволяет вам оставаться впереди.

Поскольку темпы изменений достигают беспрецедентных скоростей, этот важнейший баланс — где следует стандартизировать, а где выделяться заметными и уникальными способами — быстро станет решающим фактором в определении победителей и проигравших в зарождающейся экономике искусственного интеллекта.

Старая поговорка — бизнес должен адаптироваться к программному обеспечению — имела смысл, когда препятствиями были код, масштаб данных и инфраструктура. Жесткое программное обеспечение в сочетании с последовательной реализацией с помощью консультантов и системных интеграторов было залогом успешной цифровизации. Но мы больше не живем в этом мире. Сегодня надежность и адаптивность больше не конкурируют друг с другом; они могут сосуществовать — организации могут быстро и гибко развивать свои возможности, обеспечивая при этом стабильность.

Влияние ИИ на ERP


Вопрос не в том, повлияет ли ИИ на привычную парадигму ERP, а в том, насколько радикально и быстро произойдет этот сдвиг.

Генеративный искусственный интеллект и агентные системы быстро выходят за рамки автоматизации задач в системах планирования ресурсов предприятия (ERP) и начинают реструктуризацию корпоративных операций. Решения, изначально разработанные на основе ИИ и часто создаваемые в виде сетей автономных агентов, работают поверх традиционных корпоративных приложений, автоматизируя принятие решений и координируя процессы от начала до конца.

Компании, первыми внедрившие ERP-системы с поддержкой ИИ, уже получают конкурентное преимущество, сообщая об улучшении показателей EBIT на 5% и более; исследования McKinsey также показывают, что компании, успешно использующие ИИ и реализующие стратегии, ориентированные на рост, с большей вероятностью сообщают об улучшении прибыльности и увеличении доли рынка. В сфере внедрения ERP-систем наши исследования показывают, что агенты на основе искусственного интеллекта потенциально могут сократить трудозатраты на внедрение ERP-систем как минимум на 50% и уменьшить продолжительность программы вдвое. Повышение производительности больше не является линейным процессом и не пропорционально человеческим ресурсам.

Поставщикам ERP-систем, разработчикам инструментов, системным интеграторам, стартапам в области ИИ и клиентам следует задуматься о том, как развиваться, и рассмотреть пять потенциальных способов, с помощью которых ИИ может изменить ERP-системы, чтобы проложить путь к миру ERP, управляемому ИИ.

1. Искусственный интеллект изменит современную архитектуру ERP-систем


В радикальном подходе ERP в том виде, в котором она существует сейчас, перестаёт существовать. Агенты искусственного интеллекта воспроизводят возможности ERP, создавая и оптимизируя процессы на лету. Данные хранятся в микросервисах, а не в больших таблицах, а логика приложений становится товаром, разрабатываемым агентами. Это видение соответствует рыночному сценарию, известному как «SaaSpocalypse».

На другом конце спектра находятся те, кто утверждает о необходимости стабильной базовой инфраструктуры. Хотя агенты ИИ будут выполнять процессы ERP, фундаментальная архитектура ERP — включая ее данные, прикладные уровни и даже интерфейсную часть — остается критически важной для обеспечения надежности, возможности аудита, соответствия требованиям и удобства использования. Без этой базовой инфраструктуры организации рискуют столкнуться с хаотичной ситуацией, когда количество агентов и настроек будет расти, что подорвет масштабируемость.

В действительности, взаимодействие внутри предприятия будет смещаться от транзакций, осуществляемых через экраны, к агентам искусственного интеллекта, которые будут выступать посредниками, принимать решения и выполнять действия. В этом сценарии самые большие изменения коснутся видимости и центра управления ERP-системы. Логика приложений по-прежнему будет обеспечивать соблюдение бизнес-правил, структуры данных будут гарантировать согласованность, а системы учета будут обеспечивать возможность аудита, но пользователи не будут напрямую взаимодействовать с ними. ERP-система станет «безголовой», но эта новая архитектура не ограничивается лишь разделением бэкэнда и фронтенда. Она определяется несколькими характеристиками:

  • Управление процессом создания ценности: измерение ценности становится ключевой архитектурной возможностью. Автономные решения требуют непрерывной оценки воздействия. Внедрение телеметрии и обратной связи позволяет организациям количественно оценивать ценность и определять, какие агенты и процессы масштабируются.
  • Агентная операционная модель: архитектура и операционная модель становятся неразделимыми. Агентная операционная модель станет новым уровнем поверх системной основы, обеспечивающим выполнение рабочих процессов и принятие решений в различных областях и системах.
  • Процессы, расширяющие возможности человека: роль конечных пользователей переосмысливается. Вместо выполнения транзакций конечные пользователи будут взаимодействовать с агентами для определения намерений, проверки результатов и вмешательства в случае возникновения исключений. В результате организациям потребуется меньше специалистов по транзакциям, но больше профессионалов, способных сочетать экспертные знания в бизнесе с навыками работы с ИИ, управлять производительностью агентов и постоянно совершенствовать логику принятия решений.
  • Корпоративная бизнес-онтология: модели данных эволюционируют от статических схем к динамическим бизнес-онтологиям. Искусственный интеллект обеспечивает семантические слои, кодирующие бизнес-контекст как внутри, так и за пределами баз данных ERP. Операционная система на основе ИИ управляет этими онтологиями, позволяя агентам рассуждать в разных областях и преобразовывать намерения в согласованные действия.
  • Чистые базовые приложения и основа данных: ядро ​​ERP-систем остается неизменным. И в будущем они будут оставаться ядром ERP-систем.

Пять уровней современной архитектуры планирования ресурсов предприятия (ERP)


В основании находятся чистое ядро ​​и база данных, которые выступают в качестве надежной системы учета и основы для транзакций.

Далее следует бизнес-онтология, обеспечивающая общий семантический слой для всех областей.

В середине находятся процессы, выполняемые людьми и агентами, где люди задают намерения, а ИИ их реализует.

Выше находится агентная операционная модель, в которой агенты ИИ координируют решения и рабочие процессы.

На самом верху, охватывая все уровни, находится управление созданием ценности, измеряющее и направляющее ценность в режиме реального времени.

Постановка целей, обратная связь и аналитические данные распространяются по всей системе.

Переход к такой архитектуре не произойдет в одночасье. Он требует четкого понимания того, где традиционные процессы ERP-систем как услуги (SaaS) и их пользовательские интерфейсы по-прежнему соответствуют своему назначению, а где подходы, основанные на искусственном интеллекте, уже способны создавать превосходную ценность. Этот гибридный подход не только позволяет организациям немедленно получить выгоду, но и поддерживает более чистое ядро ​​ERP-системы.

Хронология эволюции систем планирования ресурсов предприятия (ERP) от транзакционно-ориентированных систем учета к платформам принятия решений, основанным на искусственном интеллекте и управляемым агентами.

В 1960-х и 1970-х годах существовали системы управления запасами без реальной интеграции данных, а логика была изолирована по функциям.

В 1980-х годах появились системы планирования — такие как планирование материальных потребностей и планирование производственных ресурсов — наряду с первыми шагами в направлении интеграции.

В 1990-х и 2000-х годах интегрированные ERP были созданы как единый источник достоверной информации.

В 2010-х годах появились ERP в реальном времени и облачные ERP с чистым ядром и API, позволяющими создавать лучшие в своем классе экосистемы.

В 2020-х годах наблюдается движение к компонуемым ERP с расширением возможностей ИИ и API-ориентированными, модульными, компонуемыми архитектурами.

В будущем ожидается появление ERP, основанных на искусственном интеллекте и управляемых агентами; ERP-система останется основной системой учета, основанной на бизнес-процессах с использованием искусственного интеллекта, а взаимодействие с системой переместится на семантический уровень и уровень ИИ.

2. Компании продолжат инвестировать в модернизацию ERP-систем


Если агенты станут новым интерфейсом ERP-системы, смогут ли предприятия оставаться на «достаточно хорошей» устаревшей архитектуре и позволить агентам создавать более эффективные бизнес-процессы и аналитику на базе ERP?

Этот сценарий заманчив. Он позволил бы компаниям сэкономить сотни миллионов долларов на трансформации ERP-систем и высвободить ресурсы для сосредоточения инвестиций на наиболее прибыльных областях. Однако такое будущее маловероятно. Роботизированная автоматизация процессов (RPA) служит предостережением. Внедренная поверх устаревших систем, RPA позволила компаниям быстро добиться результатов на периферии, но структурные проблемы, связанные с процессами и данными, остались в ядре. Агентный ИИ мощнее RPA, но может столкнуться с аналогичным ограничением, когда предприятиям потребуется масштабируемость, контроль и согласованность.

Агентный ИИ существенно расширяет возможности наложений, поскольку он может быстрее, чем более ранние инструменты автоматизации, выводить, генерировать и адаптировать бизнес-логику. Однако компании, вероятно, не захотят использовать отдельные решения, созданные ИИ, для процессов, которые в значительной степени являются стандартными, потенциально с отсутствием отслеживаемости, в отличие от проверяемой системы учета. Они также не захотят управлять критически важной инфраструктурой без поддержки поставщика. А разработчики ERP-систем, скорее всего, предпочтут создать «чистую» ERP-систему, изначально разработанную с использованием ИИ, чем использовать устаревшие ERP-системы в качестве основы и оптимизировать их для множества сценариев интеграции (например, несколько экземпляров ERP от разных поставщиков в одной компании).

На данный момент имеет смысл продолжать обдуманно инвестировать в модернизацию ERP-систем. Инвестиции в улучшенную базу данных всегда будут способствовать масштабированию ИИ в будущем. Но этот сценарий усиливает давление на поставщиков и интеграторов ERP-систем с целью резкого сокращения стоимости и продолжительности трансформаций ERP.

3. Внедрение ERP-систем будет в два раза быстрее и дешевле


Долгое время экономические аспекты масштабных модернизаций ERP-систем представляли собой сложную задачу. Согласно данным McKinsey о стоимости ERP-систем, большинство крупных предприятий тратят от 100 миллионов до 1 миллиарда долларов на миграцию своих ERP-систем. Основную часть составляют единовременные затраты на внедрение, обычно достигающие многократной величины по сравнению со стоимостью подписки. Стремясь сбалансировать затраты и ценность, клиенты ERP-систем выбирают один из двух путей миграции. В одном случае они используют миграцию ERP в качестве катализатора трансформации бизнеса, перестраивая бизнес-процессы и свою операционную модель, чтобы сосредоточиться на бизнес-ценности. По нашему опыту, период окупаемости часто составляет от четырех до пяти лет. В другом случае они решают осуществить перенос системы — если поставщики предлагают такой путь миграции — соглашаясь на более скромную первоначальную модернизацию за счет меньшей бизнес-ценности. Некоторые сочетают оба подхода.

Искусственный интеллект кардинально меняет экономику программ ERP, позволяя компаниям лучше выявлять и отслеживать возможности получения выгоды, одновременно сокращая стоимость и продолжительность программ как минимум в два раза.

Агентный ИИ может сократить ручной труд в программах планирования ресурсов предприятия тремя способами:
  • агентное проектирование и разработка,
  • агентное тестирование,
  • подготовка к агентному обучению.

Каждому способу присущи:
  • необходимые входные данные для фабрики ИИ,
  • выходные данные агентного ИИ,
  • способы вовлечения людей,
  • воздействие ИИ.

Для агентного проектирования и разработки компания вводит существующие процессы, стандартные лучшие практики разработки программного обеспечения и бенчмарки. Агентный ИИ создает целевое состояние и автоматически настраивает систему за несколько дней, перестраивая рабочие процессы и внедряя логику ценности по умолчанию. Люди, тем временем, определяют направление работы ИИ, проверяют результаты и управляют изменениями. Этот процесс сокращает время проектирования и разработки с шести-девяти месяцев до двух-трех месяцев.

Для агентного тестирования компания вводит целевые процессы, документацию и пользовательский код. Затем агентный ИИ непрерывно генерирует, выполняет и проверяет тестовые примеры в масштабе и автоматически обнаруживает, диагностирует и устраняет проблемы. Люди контролируют качество и обрабатывают нестандартные ситуации, что приводит к сокращению трудозатрат примерно на 80%.

Для подготовки к обучению агентов компании вводят целевые процессы, оценки возможностей и конфигурацию системы, а в ответ получают обучение на основе ролей и автоматические внутрисистемные инструкции. Искусственный интеллект также постоянно улучшает контент на основе поведения пользователей, в то время как люди утверждают контент, созданный ИИ, и контролируют его внедрение. Этот процесс может сократить необходимые трудозатраты на 90%.

Первые экспериментальные исследования показывают, что системы искусственного интеллекта на основе агентов смогут с высокой точностью рекомендовать целевые процессы и проектные решения в течение нескольких дней. Эти рекомендации могут быть внедрены в ERP-системы посредством автоматической настройки, что снова обеспечит участие человека в обеспечении качества. Миграция данных, тестирование, документирование, обучение — все эти традиционно выполняемые вручную задачи будут в значительной степени автоматизированы с помощью агентов. В этой среде управление изменениями станет основным ограничивающим фактором в планах трансформации ERP-систем в будущем, поскольку пользователей ERP-систем по-прежнему необходимо вовлекать в этот процесс.

4. Поставщики ERP-систем могут восстановить контроль над экосистемой ERP


Поскольку ИИ берет на себя все больше задач, клиенты ERP-систем будут ожидать, что эффективность будет передана им. Эта тенденция уже наблюдается в сфере сопровождения приложений, где, согласно анализу McKinsey, ожидания клиентов относительно ежегодного повышения эффективности работы поставщиков примерно удвоились. В крупных ERP-программах предприятия находятся в затруднительном положении: конечно, они хотели бы сократить затраты за счет ИИ, но большинство воздерживаются от масштабных экспериментов из-за связанных с этим рисков и вероятного сопротивления изменениям. Большинство больше заинтересованы в проверенных решениях.

В результате системные интеграторы в основном по-прежнему применяют проверенную модель внедрения, выборочно дополняя ее сценариями использования ИИ, а не стремясь к радикальному пересмотру подхода. Однако появляющиеся стартапы, ориентированные на ИИ, предлагают возможности внедрения ERP-систем с использованием ИИ: сопоставление существующих процессов с целевыми моделями, чтение пользовательского кода и его сопоставление с новым стандартом ERP, а также создание в рамках проекта ERP офиса управления проектами с использованием ИИ, который фокусируется на улучшении функционирования инструментов ИИ. Некоторые из этих стартапов, вероятно, быстро масштабируются. Однако они сосредоточены на отдельных сценариях использования в цикле разработки ERP-системы, оставляя возможность для интеграции различных возможностей.

Поставщики ERP-систем находятся в наилучшем положении для того, чтобы заполнить этот пробел комплексными решениями. В предыдущих поколениях ERP-систем они в основном фокусировались на программном обеспечении и механизмах миграции, в то время как партнерская экосистема создавала инструменты миграции, подробные руководства и даже отраслевые шаблоны. Хотя это, безусловно, расширило охват ERP-решений среди клиентов по всему миру, это также привело к значительной разнице в качестве предоставления услуг. Только 25–35% крупных технологических программ достигают целевого показателя EBITDA и денежного потока, в то время как 65–80% превышают запланированный бюджет или сроки. Поставщики ERP-систем заинтересованы в более дешевой, быстрой и качественной доставке. Теперь у них есть возможность предложить клиентам и партнерам комплексное решение для развертывания и миграции, поддерживаемое искусственным интеллектом, что позволяет им восстановить контроль над качеством предоставляемых услуг.

В перспективе поставщики ERP-систем, вероятно, увеличат инвестиции в модернизацию своих подходов к внедрению и инструментов с использованием ИИ. Они могут приобретать и интегрировать наиболее перспективные стартапы, что позволит им контролировать агентский уровень над цепочками инструментов и сквозную интеграцию, сохраняя при этом партнерские отношения с избранными ведущими поставщиками инструментов. В долгосрочной перспективе наибольшую конкуренцию будут представлять поставщики агентских решений, которые стремятся работать на протяжении всего жизненного цикла трансформации и на платформах разных поставщиков.

5. В сфере ERP-систем подход к созданию ценности сместится от разработки собственных решений к их приобретению


Как только возможности искусственного интеллекта стали очевидны, предприятия начали гонку за внедрением сценариев использования. Они также столкнулись с проблемами, связанными с неопределенностью пилотных проектов, и ограничениями подхода, основанного на сценариях использования, по сравнению с трансформацией предметной области. Поставщики ERP-систем также стремились выйти на рынок со сценариями использования, но зачастую их масштабы были слишком малы, чтобы оказать измеримое влияние на прибыль. В результате клиенты ERP-систем продолжали создавать собственные решения, часто при поддержке поставщиков услуг и платформ, которые предоставляют свои собственные агентские или информационные платформы и модель проектирования с опережающим развертыванием.

Такой подход обеспечивает большую гибкость: компании могут выбрать любую задачу и применить к ней ИИ. Для дифференциации процессов — например, в коммерческой сфере — они могут получить конкурентное преимущество на рынке. Однако в масштабах ERP-систем, где целевой функцией большинства процессов является стандартизация, а не дифференциация, такой подход нежизнеспособен.

Задача поставщиков ERP-систем и их партнеров по решениям — значительно ускорить вывод на рынок комплексных решений на основе встроенного искусственного интеллекта. Для успешного выполнения этой задачи необходимо несколько предварительных условий:

  • Применение подхода «с чистого листа». Вместо автоматизации отдельных этапов существующих сквозных процессов, поставщикам ERP-систем следует переосмыслить процессы и целые области с помощью агентного ИИ. Базовая структура данных и бизнес-логика могут быть в значительной степени повторно используемыми, но поток процессов полностью изменится. Например, многократные итерации согласования сверху вниз и снизу вверх в процессах планирования можно заменить механизмом ИИ, который предоставляет усовершенствованную версию планов, учитывающую исторические данные, стратегию компании и отраслевые показатели.
  • Обеспечение четкой измеримости влияния на прибыль и убытки для клиентов. С помощью контроля за выполнением управленческих задач устанавливаются базовые показатели и целевые значения, а также отслеживается влияние операционных улучшений на прибыль и убытки.
  • Внедрение решения на основе ИИ в полном объеме. Обеспечение простого развертывания ИИ и интегрированного пользовательского опыты, охватывающего как функции ИИ, так и традиционные функции.
  • Обеспечение простоты коммерческой модели использования возможностей ИИ. Клиенты должны иметь возможность легко оценивать и отслеживать стоимость потребляемых ИИ-решений.
  • Обеспечение возможности взаимодействия агентов в ERP-системе с агентами за пределами экосистемы ERP-системы конкретного поставщика. Такой открытый подход будет более привлекательным для клиентов, которые не захотят делать ставку на изолированные системы искусственного интеллекта.

Для поставщиков ERP-систем стратегически важно предоставлять решения, интегрированные с искусственным интеллектом. Работая вместе с клиентами и партнерами, они могут внедрять инновации в следующее поколение ERP-систем, усовершенствованных с помощью ИИ. Это позволит клиентам сосредоточить разработку решений на основе ИИ на тех бизнес-возможностях, где они действительно смогут выделиться.

Хотя масштабы изменений сложно предсказать, очевидно, что участникам экосистемы ERP необходимо переосмыслить свои модели предоставления услуг и решения, чтобы оставаться конкурентоспособными. Клиенты ERP, в свою очередь, должны быть в курсе последних тенденций, экспериментировать с новыми возможностями искусственного интеллекта и быть открытыми к переосмыслению устоявшихся подходов к ERP.

Идет гонка за совершенствованием возможностей искусственного интеллекта и расширением перспектив создания ценности — до тех пор, пока не произойдет следующее прорывное технологическое достижение.

Источник


Конец ERP в том виде, в каком мы его знаем? Пять способов, которыми ИИ меняет ERP-системы. 11 мая 2026 г. Статья. Бьёрнар Йенсен; Дарвин Дино; Флориан Бауэр; Джо Боден.

The end of ERP as we know it? Five ways AI is disrupting ERP. May 11, 2026 Article

https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/the-end-of-erp-as-we-know-it-five-ways-ai-is-disrupting-erp

четверг, 6 августа 2026 г.

AGI

Что и как скоро приведет нас к AGI.

Из Телеграмм-канала "Data secrets"

Сейчас индустрия ИИ перестала быть про один понятный вектор развития. Если раньше все сводилось к масштабированию моделей, то теперь одновременно развиваются несколько конкурирующих подходов – и главный вопрос уже не когда, а за счет чего именно мы придем к AGI.

Мы попробовали разложить, куда именно движется индустрия, через новый режим «Исследовать» в Алиса AI: когда она проводит многоэтапное исследование, делает десятки поисковых запросов, читает источники, сравнивает, синтезирует – и выдает подробный отчет. Вот, какой получился срез:

* AGI больше не один путь, а конкуренция парадигм. Индустрия ушла от идеи «просто масштабируем LLM и все получится». Сейчас параллельно развиваются четыре основных направления – сами LLM, world models, агентные системы и RL. И главный вопрос уже не когда, а какая комбинация этих подходов выстрелит.

* LLM тащат, но им явно не хватает понимания мира. Поэтому экспертное сообщество расколото: одни считают, что достаточно просто продолжать масштабировать LLM, другие – что без принципиально новой архитектуры (ставки тут в основном на world models) мы упремся в потолок.

* Ставка индустрии – на гибрид. Ни один из подходов сам по себе не выглядит достаточным для AGI. Консенсус постепенно смещается к идее системы, где LLM отвечает за знания и язык, world models – за понимание реальности, агенты – за действие, а RL – за обучение через опыт. Если это сложится, то горизонт появления AGI – где-то между 2030-ми и 2040-ми.

Ни один из текущих подходов не выглядит самодостаточным – все они закрывают только часть того, что мы называем интеллектом. Чем быстрее растут модели, тем очевиднее становится, что масштаб сам по себе не решает проблему понимания.

воскресенье, 2 августа 2026 г.

Перспективы российского рынка ERP плюс про ответственность в гибридном предприятии

Перспективы российского облачного рынка: гибридные архитектуры и конкуренция за качество

Ключевые мысли статьи (https://kodeks.ru/news/read/perspektivy-rossiiskogo-oblacnogo-rynka-gibridnye-arxitektury-i-konkurenciia-za-kacestvo) относительно ERP:


1. ERP — в авангарде критически важных облачных нагрузок


Предприятия, особенно в промышленности и крупном корпоративном сегменте, начали активно переносить в облачную инфраструктуру свои самые чувствительные системы. ERP-системы прямо названы в числе первых в этом списке.

«…предприятия активно переводят в облако критически важные системы — ERP, аналитические платформы, цифровые производственные сервисы. Такой подход требует от инфраструктуры высокой отказоустойчивости, зрелых механизмов информационной безопасности и управления».



2. Гибридная архитектура — безальтернативная модель для ERP


Ключевой вывод статьи о гибридных облаках имеет прямое отношение к ERP. Крупные компании не уходят в чистое публичное облако, а строят гибридные ландшафты, чтобы совместить требования безопасности, экономики и законодательства. Для ERP это означает, что наиболее критичные модули могут оставаться on-premise, а связанные с ними аналитические сервисы, песочницы или фронт-офисные блоки — выноситься в облако.

«Большинство крупных компаний не пойдут в чистый public cloud. Они строят и будут строить гибридные архитектуры — не из стратегических соображений, а из необходимости одновременно учитывать безопасность, экономику, производительность и соответствие законодательству».



3. Переход от «облака как хостинга» к готовым бизнес-сценариям


Для ERP-систем это означает, что заказчику всё чаще нужен не просто виртуальный сервер для 1С или SAP, а комплексное решение: среда для разработки доработок, резервная площадка для аварийного восстановления, аттестованный контур безопасности и т.д. Конкуренция за ERP-клиентов будет идти на уровне этих готовых сценариев, а не цены за vCPU.

«Выигрышную позицию займут поставщики, предлагающие готовый бизнес-сценарий: не просто виртуальные машины, а среду разработки, резервную площадку, защищённый контур, платформу для работы с данными…»



4. Приоритеты заказчика: контроль и возможность доработки (особенно важно для ERP)


В условиях импортозамещения и унаследованных сильно кастомизированных систем, для заказчиков ERP критична возможность глубокой доработки и контроля над системой. Статья подчеркивает, что российские облачные провайдеры и вендоры способны обеспечить более высокую скорость адаптации под локальные требования, чем глобальные гиганты. Для ERP, где каждая компания десятилетиями дописывает уникальную логику, это сильный аргумент в пользу локальных игроков.

«…для многих заказчиков приоритетом являются контроль, возможность доработки, сопровождение и практическая полезность… Локальная адаптация под локальные требования — сильная сторона российского рынка».



5. Инфраструктурный фундамент для ERP-революции


Статья напоминает, что развитие облачных ERP и загрузка их ИИ-инструментами упирается в физическую ёмкость ЦОДов. Перенос тяжелых ERP-систем требует значительных вычислительных ресурсов и энергомощностей, рост спроса на которые пока опережает предложение. Это сдерживающий фактор, который напрямую затрагивает темпы миграции ERP в облако.

«Спрос на облака и ИИ растёт намного быстрее, чем ёмкость ЦОДов. … Именно в инфраструктуру упирается развитие облачного рынка в России».



Резюме по ERP: Статья видит будущее ERP в облаке как неотъемлемую часть гибридной ИТ-инфраструктуры крупного бизнеса. Это уже не вопрос «переносить или нет», а задача выбора провайдера, который обеспечит не просто вычислительные мощности, а целостную, безопасную и адаптируемую платформу для работы критически важных систем предприятия. Ключевым полем конкуренции за ERP-ландшафты становится качество сервиса, экспертиза и способность закрывать сложные бизнес-сценарии «под ключ».


https://kodeks.ru/news/read/perspektivy-rossiiskogo-oblacnogo-rynka-gibridnye-arxitektury-i-konkurenciia-za-kacestvo

* * *

Кому принадлежит результат? Ответственность в гибридном предприятии

https://www.techtarget.com/searcherp/feature/Who-owns-the-outcome-Accountability-in-the-hybrid-enterprise

ERP-системы в статье показаны не как решение проблемы, а как часть парадокса: они одновременно и помогают отслеживать работу, и создают иллюзию контроля, не решая вопрос реальной ответственности.

1. ERP создаёт «галочную ответственность» (checkbox ownership)

ERP-системы отлично справляются с отслеживанием формальных состояний задач (начато, в работе, завершено). Но они жестко следуют предопределённым «счастливым путям» (happy paths). В реальности 70-80% процессов имеют отклонения, которые ERP не учитывает. В итоге сотрудник формально «поставил галочку» в ERP, но реальная логика решения осталась за бортом системы, не управляема и не видна.

2. ERP не фиксирует «соединительную ткань» работы

Главная проблема с точки зрения ERP: она является системой учёта (system of record), но фиксирует только то, что в неё явно внесли. Реальная работа, распределение ответственности и ключевые решения часто происходят вне ERP:

* Обсуждения в Slack / Teams
* Правки в Excel-файлах
* Электронные письма с уточнениями
* Заметки в блокнотах

В результате, когда происходит сбой, ERP покажет, кто закрыл наряд-заказ, но не покажет, кто принял ошибочное решение в чате. Человек становится «API» между несвязанными системами.

3. Связность ≠ подотчётность (Connectivity is not accountability)

Современные ERP развёрнуты в гибридной среде, охватывают подразделения, страны и облака. Они созданы для связывания рабочих процессов, но не для назначения владения результатом. Вы можете иметь единую ERP, но ответственность за исполнение будет размыта между отделами, временными зонами и системами. ERP фиксирует факт передачи данных, но не факт принятия решения.

4. Парадокс видимости в ERP

ERP создаёт иллюзию полной видимости: менеджер видит статусы, отчёты и дашборды. Однако эта видимость обманчива, потому что ERP показывает лишь то, что было залогировано, а не то, что человек реально сделал. Это порождает ложное чувство контроля у руководства.

5. Слабое место ERP — точки передачи (handoff points)

Статья прямо указывает: когда инцидент в системе CRM (например, жалоба клиента) требует действия в SAP (отгрузка, пересчёт), а владельца процесса чётко не назначено, ответственность исчезает. ERP не умеет управлять такими межсистемными стыками. В офисе эти стыки сглаживались «быстрым разговором у кулера»; в гибридной среде с ERP этого нет.

6. ERP подменяет собой менеджмент, но не заменяет владельца решения

ERP всё чаще берёт на себя функции, которые раньше выполняли менеджеры: принуждение к workflow, назначение задач (автоматически), создание аудиторского следа. Это полезно, но риск в том, что ERP начинает диктовать структуру ответственности, и люди следуют системе, а не логике бизнеса. В результате появляется «владелец задачи в ERP», но нет владельца решения (decision owner) — человека с реальными полномочиями сказать «да» или «нет».

Главный вывод для ERP-специалистов:

Внедрение ERP само по себе не решает проблему подотчётности в гибридном предприятии. Более того, ERP может маскировать отсутствие реальной ответственности за «галочками» в системе. Для реального исправления ситуации нужно не настраивать ERP дальше, а явно определять права принятия решений на стыках и дополнять ERP аудитом «невидимой» работы, которая происходит вне её.

среда, 29 июля 2026 г.

Линус Торвальдс о использовании ИИ - перепечатка заметки

Перепечатка заметки

Линус Торвальдс высказался об использовании ИИ: «Форкайте ядро или уходите»

  
 1 комментарий
 
55860
 

https://xakep.ru/2026/07/17/torvalds-about-ai/

Создатель Linux Линус Торвальдс (Linus Torvalds) заявил, что разработчикам, которые выступают категорически против использования ИИ, придется смириться, уйти или создать собственный форк ядра. По его словам, Linux не станет очередным «анти-ИИ-проектом», а решения будут приниматься исходя из технических критериев, а не из страха перед новыми инструментами.

Поводом для заявления послужила дискуссия в списке рассылки для разработчиков ядра. Участники обсуждали Sashiko — агентную ИИ-систему для ревью кода Linux. Создатели Sashiko протестировали систему на старых версиях ядра, и она нашла 53,6% багов, которые разработчики позднее исправили. Однако Sashiko может генерировать и ложные отчеты об уязвимостях, доля которых составляет около 20%.

Противники подобных инструментов опасаются, что автоматизированные отчеты создадут огромную нагрузку на мейнтейнеров и могут спровоцировать их выгорание. В обсуждении даже процитировали недавнее заявление организации Software Freedom Conservancy, в котором опенсорсное сообщество призывали поддерживать разработчиков, полностью отвергающих генеративный ИИ.

Однако Торвальдс занял жесткую позицию. Создатель Linux написал:

«Это как раз тот случай, когда я готов совершенно однозначно настаивать на своем как главный мейнтейнер. Linux не относится к анти-ИИ-проектам. Если у кого-то с этим проблемы, он может поступить в духе open source и сделать форк. Или просто уйти».

Торвальдс подчеркнул, что никого не заставляют применять LLM, однако запрещать другим использовать такие инструменты тоже не получится:

«Мы не принуждаем никого использовать [LLM-инструменты]. Но я буду решительно игнорировать людей, которые пытаются запретить их использование остальным».

По мнению Торвальдса, ИИ следует воспринимать как обычный рабочий инструмент:

«ИИ — такой же инструмент, как и другие, которыми мы пользуемся. И совершенно очевидно, что он полезен. Возможно, еще год назад это было не так очевидно, но сегодня этот вопрос уже закрыт. Тот, кто сомневается, явно просто не пользовался ИИ сам».

При этом Торвальдс признает, что ИИ может создавать дополнительную нагрузку на мейнтейнеров и регулярно находит «неприятные и постыдные баги». Однако он пишет, что игнорировать новую технологию просто бессмысленно.

«Решение заключается не в том, чтобы засунуть голову в песок и во весь голос петь: "Ла-ла-ла, я ничего не слышу", как, похоже, делают некоторые. Нужно добиться того, чтобы LLM-инструменты помогали мейнтейнерам, а не вредили им».

Нынешняя позиция заметно отличается от слов Торвальдса, сказанных в октябре 2024 года. Тогда он называл 90% происходящего вокруг ИИ маркетинговым хайпом и заявлял, что намерен попросту игнорировать эту тему. Однако в январе 2026 года он уже экспериментировал с вайбкодингом и рассказывал, что написал на Python инс­тру­мен­т для генера­ции циф­ровых аудиооэф­фектов с помощью Google Antigravity.

Теперь Торвальдс подчеркивает, что не считает нынешние ИИ-системы идеальными, но напоминает, что люди тоже далеки от совершенства:

«ИИ не идеален. Но, черт возьми, любой, кто указывает на проблемы ИИ, должен одновременно посмотреть в зеркало и указать на самого себя. Потому что естественный интеллект тоже хорош далеко не всегда».

По словам Торвальдса, Linux остается в первую очередь технологическим проектом. Социальная сторона open source важна, но это побочный эффект, а не главная цель.

«В сообществе разработчиков ядра мы занимаемся open source, потому что это позволяет создавать лучшие технологии, а не по религиозным убеждениям. Поэтому мы принимаем решения прежде всего исходя из технических критериев, а не из страха перед новыми инструментами». 

суббота, 25 июля 2026 г.

Пример галлюцинаций ИИ для создания ботнетов - перепечатка статьи

Перепечатка статьи

Атака HalluSquatting использует галлюцинации ИИ для создания ботнетов

  
 Комментарии
 
3148
 

https://xakep.ru/2026/07/15/hallusquatting/

Специалисты из Тель-Авивского университета, Израильского технологического института и компании Intuit продемонстрировали атаку HalluSquatting. Она строится на склонности ИИ-ассистентов «выдумывать» адреса репозиториев и других ресурсов. Эксперты показали, что атакующий может заранее зарегистрировать такой несуществующий адрес, дождаться подключения ИИ-агента и добиться выполнения вредоносного кода на машине пользователя.

Исследователи объясняют, что для эксплуатации большинства промпт-инжектов нужен прямой контакт с жертвой. Например, злоумышленник скрывает вредоносные инструкции в письме, приглашении календаря, комментарии или логе, а затем должен каким-то образом доставить зараженный контент пользователю. HalluSquatting работает иначе, и в этом случае сам ИИ-агент приходит на вредоносный ресурс, поэтому такую атаку можно масштабировать без массовых рассылок и выбора целей.

Название HalluSquatting расшифровывается как adversarial hallucination squatting — сквоттинг, основанный на состязательных галлюцинациях. В целом атака напоминает тайпосквоттинг, но здесь атакующему нужно предугадать не человеческую опечатку, а адреса, которые LLM чаще всего «придумывают» в ходе обработки запросов на клонирование репозитория или установку навыка.

Затем злоумышленник регистрирует «выдуманное» имя на GitHub или в каталоге навыков и размещает там копию популярного проекта. В README или конфигурации атакующий может спрятать промпт-инжект с командой, вынуждающей ИИ установить бэкдор или ревер-шелл. В результате, когда ИИ-ассистент галлюцинирует и «придумывает» этот адрес, он попадает в ловушку, в итоге выполняя инструкции злоумышленника.

Исследователи протестировали атаку на Cursor, Cursor CLI, Gemini CLI, Windsurf, GitHub Copilot, Cline, OpenClaw, ZeroClaw и NanoClaw. Во всех случаях им удалось добиться выполнения кода (в экспериментах использовались безопасные тестовые пейлоады).

По данным специалистов, проблема затрагивает базовые модели Gemini 2.5 Flash, Gemini 2.5 Pro, GPT-5.1, GPT-5.2, Sonnet 4.5 и Opus 4.5. Их галлюцинации оказались предсказуемыми и часто повторялись. К примеру, обнаружилось, что LLM склонны генерировать адреса вида repo-name/repo-name, принимая название проекта за имя владельца аккаунта.

Исследователи отмечают, что чаще всего подобные ошибки возникают с новыми и трендовыми проектами, которые отсутствовали в обучающих данных LLM. Так, для проектов, опубликованных до 2019 года, средний показатель галлюцинирования составлял лишь 0,9%, тогда как для репозиториев, созданных в 2025 году — уже 92,4%. В итоге при клонировании репозиториев пиковая доля галлюцинаций достигала 85%, а при установке навыков — 100%.

Авторы HalluSquatting предупреждают, что атака может стать механизмом для доставки малвари на множество независимых систем. Зараженные машины в итоге можно объединить в ботнет для DDoS-атак или майнинга криптовалюты, а также использовать в массовых вымогательских кампаниях. В отличие от традиционных ботнетов, в этом случае хакерам не потребуется использовать уязвимости, слабые пароли и так далее. Малварь будет устанавливать сам ИИ-агент, имеющий доступ к командной строке.

Разработчиков затронутых ИИ-инструментов предупредили о проблеме до публикации исследования, а часть деталей атаки пока решили не раскрывать. В качестве защитной меры специалисты советуют заставлять ИИ-агентов сначала искать и проверять нужный ресурс, а уже затем переходить к скачиванию. Также не рекомендуется запускать ИИ-инструменты в автоматическом режиме без подтверждения команд, ведь любой адрес, предложенный LLM, нельзя считать достоверным.

Отметим, что недавно о похожей технике атак под названием phantom squatting писали специалисты компании Palo Alto Networks. Суть этой проблемы заключается в том, что злоумышленники могут регистрировать несуществующие домены, которые «придумывают» LLM, а затем размещать на них фишинговые страницы и малварь.

В свою очередь, атака phantom squatting похожа на описанные еще в 2025 году атаки типа slopsquatting, в ходе которых хакеры создают вредоносные пакеты в PyPI или npm, используя названия, которые «выдумывают» ИИ-модели. Причем эта схема уже применялась злоумышленниками на практике в кампании PhantomRaven, когда малварь разместили в 126 пакетах npm, которые в итоге установили более 86 000 раз.


* * *


Злоумышленники регистрируют домены, «придуманные» ИИ

  
 Комментарии
 
11664
 

https://xakep.ru/2026/07/06/phantom-squatting/


Эксперты компании Palo Alto Networks обнаружили новую технику атак, которой дали название phantom squatting. Злоумышленники регистрируют несуществующие домены, которые «придумывают» LLM, а затем размещают на них фишинговые страницы и малварь. В результате пользователь попадает на опасный сайт не через фишинговое письмо или вредоносную рекламу, а через ИИ-инструмент, которому доверяет.

Чтобы оценить масштаб проблемы, исследователи задали двум неназванным ИИ-моделям 685 339 вопросов о 913 известных брендах из технологического, финансового, медицинского, государственного и других секторов. В ответ модели предоставили специалистам 2,1 млн ссылок, причем системы анализа киберугроз уже считали 13 229 их этих адресов вредоносными. То есть ИИ напрямую рекомендовал пользователям заведомо опасные ресурсы. Еще около 250 000 доменов, порожденных галлюцинациями ИИ, были свободны, и зарегистрировать их мог любой желающий.

Исследователи отмечают, что недавно зарегистрированные домены удобны для атак, поскольку еще не успели заработать плохую репутацию. Черным спискам и защитным системам требуется время, чтобы обнаружить вредоносную активность, поэтому к моменту блокировки такого домена пользователь может успеть перейти на сайт по рекомендации ИИ.

Подчеркивается, что модели не могли почерпнуть странные адреса из обучающих данных, и домены возникали из-за языковых паттернов самих LLM. Причем разные модели часто придумывали одинаковые адреса в ответ на один и тот же вопрос, а повышение «креативности» модели лишь увеличивало количество галлюцинаций. Специалисты пишут, что это «структурное свойство архитектуры LLM, которое невозможно исправить».

В одном случае система Palo Alto Networks предсказала, что модели «придумают» домен, похожий на адрес онлайн-маркетплейса национальной почтовой службы. Обе изученные модели действительно стабильно генерировали этот адрес при любых настройках температуры. Через 23 дня злоумышленник зарегистрировали этот домен и развернули там фишинг-кит Montana Empire.

Поддельный сайт в режиме реального времени копировал настоящую витрину маркетплейса и похищал данные банковских карт и переводов, а также информацию о документах, удостоверяющих личность. Операторы малвари могли вручную подтверждать одноразовые коды, введенные жертвами, через бота в Telegram. При этом сохранившиеся на сервере файлы и логи свидетельствуют о том­, что преступники создавали малварь с помощью ИИ-ассистента.

В другом случае исследователи заметили «выдуманный» домен почтовой службы за 51 день до его регистрации. Позже на этом домене появился точный клон официального сайта с фальшивой оценкой 4,8 звезды и заявлением о более чем двух миллионах пользователей. Ресурс распространял вредоносное приложение для Android.

Прочие вредоносные домены имитировали банки в ОАЭ и странах Европы, а также сайты для спортивных ставок, которые были ориентированы на пользователей из Бангладеш.

Phantom squatting очень похож на описанные в 2025 году атаки типа slopsquatting, при которых преступники создают вредоносные пакеты в PyPI или npm, используя названия, которые «выдумывают» ИИ-модели. Именно эта схема применялась злоумышленниками в кампании PhantomRaven, когда малварь скрыли в 126 пакетах npm, которые в итоге установили более 86 000 раз.


* * *

Новые атаки типа слопсквоттинг строятся на «галлюцинациях» ИИ


https://xakep.ru/2025/04/14/slopsquatting/


Эксперты предупреждают о новом типе атак на цепочку поставок, получившем название слопсквоттинг (slopsquatting). Такие атаки становятся возможны благодаря широкому применению генеративных ИИ-инструментов для кодинга, так как модели склонны к «галлюцинациям» и могут придумывать несуществующие пакеты.

Впервые термин слопсквоттинг был предложен ИБ-исследователем Сетом Ларсоном (Seth Larson) и родственен слову «тайпсквоттинг». В отличие от тайпсквоттинга, слопсквоттинг связан не с эксплуатацией опечаток, а с тем фактом, что злоумышленники могут создавать вредоносные пакеты в PyPI или npm, используя названия, которые часто «выдумывают» ИИ-модели.

Опубликованное в конце марта исследование, посвященное изучению «галлюцинаций» ИИ, показало, что примерно в 20% случаев (576 000 сгенерированных примеров кода на Python и JavaScript) рекомендуемые искусственным интеллектом пакеты не существовали.

Причем ситуация выглядит хуже для опенсорсных LLM (CodeLlama, DeepSeek, WizardCoder и Mistral), а коммерческие инструменты, такие как ChatGPT-4, галлюцинируют примерно в 5% случаев, что тоже совсем немало.

Исследователи отметили, что количество уникальных имен таких несуществующих пакетов превысило 200 000, причем 43% из них постоянно появлялись в ответах LLM при похожих промптах, а 58% повторялись хотя бы один раз из десяти.

Отмечается, что 38% названий несуществующих пакетов явно были вдохновлены настоящими пакетами, 13% были результатом опечаток, а остальные 51% являлись полностью вымышленными.

Схема атаки с использованием слопсквоттинга

Хотя пока нет никаких признаков того, что злоумышленники уже взяли на вооружение новый тип атак, исследователи из компании Socket предупреждают, что «галлюцинации» в названиях пакетов встречаются часто, регулярно повторяются и выглядят семантически правдоподобно, что можно легко применить во вредоносных целях.

«В целом 58% “галлюцинаций” повторялись более одного раза. Это свидетельствует о том, что большинство “галлюцинаций” — не просто случайный шум, а повторяющиеся артефакты того, как модели реагируют на определенные промпты, — объясняют исследователи Socket. — Такая повторяемость повышает их ценность для злоумышленников, облегчая выявление жизнеспособных целей для слопсквоттинга, просто наблюдая за результатами работы моделей даже на небольших выборках».

Единственным способом снижения рисков в данном случае является проверка имен пакетов вручную. Также всегда стоит помнить о том, что любой пакет, упомянутый ИИ, может не существовать в реальности и не быть безопасным.

Также специалисты рекомендуют использовать сканеры зависимостей, lockfile и проверки хешей для установления связи пакетов с известными и надежными версиями.

Кроме того, отмечается, что снижение «температуры» ИИ помогает снизить количество галлюцинаций, что тоже следует учитывать всем вайб-кодерам. Однако запускать и развертывать созданный ИИ код в любом случае рекомендуется только после тестирования в безопасной и изолированной среде.


* * *


Кампания PhantomRaven: в npm загрузили более 100 пакетов с инфостилерами



https://xakep.ru/2025/10/30/phantomraven/

С августа 2024 года, в рамках кампании PhantomRaven в npm загрузили 126 вредоносных пакетов, которые суммарно скачали более 86 000 раз. Кампанию обнаружили специалисты Koi Security, которые пишут, что атаки осуществлялись благодаря малоизвестной особенности npm, которая позволяет обходить защиту и детектирование.

Подчеркивается, что на момент публикации отчета около 80 вредоносных пакетов все еще были активны.

Специалисты объясняют, что злоумышленники используют механизм удаленных динамических зависимостей (Remote Dynamic Dependencies, RDD). Обычно разработчик видит все зависимости устанавливаемого пакета — они загружаются из доверенной инфраструктуры npm. Однако RDD позволяет пакетам автоматически подтягивать код с внешних URL, причем даже по незашифрованному HTTP-каналу. При этом в манифесте пакета отображается ноль зависимостей.

Когда разработчик запускает npm install, вредоносный пакет незаметно подгружает пейлоад с контролируемого атакующими сервера и сразу выполняет его. Никакого взаимодействия с пользователем не требуется, а инструменты статического анализа не замечают происходящее.

«PhantomRaven показывает, насколько изощренными могут быть атакующие при эксплуатации слепых зон в традиционных средствах защиты. Удаленные динамические зависимости просто невидимы для статического анализа», — говорят исследователи.

Отмечается, что малварь загружается с сервера при каждой установке пакета, а не кешируется. Это открывает возможности для таргетированных атак: злоумышленники могут проверять IP-адрес запроса и отправлять безобидный код ИБ-исследователям, отдавать вредоносный код для корпоративных сетей, специализированные пейлоады для облачных сред.

После заражения малварь тщательно собирает информацию о системе жертвы:

  • переменные окружения с конфигурациями внутренних систем разработчика;
  • токены и учетные данные для npm, GitHub Actions, GitLab, Jenkins и CircleCI;
  • всю среду CI/CD, через которую проходят изменения кода от разных разработчиков.

Украденные токены могут использоваться для атак на цепочки поставок и внедрения вредоносного кода в легитимные проекты. Кража данных организована с избыточностью, сразу тремя методами: HTTP GET с данными в URL, HTTP POST с JSON и через WebSocket-соединения.

Специалисты пишут, что многие вредоносные пакеты маскируются под инструменты GitLab и Apache.

Отдельную роль в этой кампании играет слопсквоттинг (slopsquatting), то есть эксплуатация галлюцинаций ИИ. Дело в том, что разработчики часто спрашивают у LLM-ассистентов, какие пакеты лучше использовать для того или иного проекта. ИИ-модели нередко выдумывают несуществующие, но правдоподобно выглядящие названия. Операторы PhantomRaven отслеживают такие галлюцинации и регистрируют пакеты с этими именами. В итоге жертвы сами устанавливают малварь, следуя рекомендациям LLM.

Разработчики LLM пока не понимают точных причин этих галлюцинаций и не умеют строить модели, которые их не допускают, чем и пользуются злоумышленники.

Исследователи напоминают, что не стоит полагаться на LLM при выборе зависимостей, а также следует внимательно проверять названия пакетов и их источники, устанавливая только пакеты проверенных вендоров.