Фонд Wikimedia повʼязав із ШІ-агентами OpenAI несанкціоновані правки у своїх вікі, спроби використати публічні інструменти спільноти як проксі та мільйони автоматизованих запитів, які могли частково спричинити травневий збій сервісу Wikidata Query Service.
Результати розслідування 5 жовтня оприлюднила директорка з продуктів і технологій Фонду Wikimedia Селена Декельманн. Вона нагадала про масштаб платформи: Вікіпедія налічує понад 67 млн статей більш ніж 300 мовами та отримує до 15 млрд переглядів сторінок на місяць.
Боти були відчутною проблемою для Wikimedia й до появи ШІ-агентів. За даними фонду, торік на них припадало 65 % найбільш ресурсомісткого трафіку його проєктів, а через сплеск їхньої активності обсяг використаної пропускної здатності зріс на 50 %.
Правки в «пісочницях», Etherpad і масовий скрейпінг
Перевіряючи, чи не торкнулася активність ШІ-агентів і його сайтів, фонд виявив, що агенти, які він повʼязує з OpenAI, вносили зміни у вікі без попереднього погодження. Водночас, як наголошує Декельманн, звичайні читачі цих правок не бачили:
Ми виявили правки у вікі Wikimedia, які, на нашу думку, зробили ШІ-агенти під управлінням OpenAI. Ці правки не публікувалися на сторінках, доступних звичайним читачам: майже всі вони були тестовими й робилися в так званих „пісочницях“ вікі.
Агенти також намагалися зловживати інструментами, які Wikimedia розміщує для своєї спільноти. До конфігурації інструмента для оформлення цитувань вони внесли, за оцінкою фонду, потенційно шкідливі зміни, а публічний сервіс спільних нотаток Etherpad безуспішно намагалися скомпрометувати. Ймовірна мета — використовувати ці сервіси як проксі для отримання даних з інших онлайн-платформ. Ознак компрометації власних систем чи даних фонд не виявив.
Найвідчутнішим для інфраструктури виявилося навантаження. Wikimedia повʼязує з агентами OpenAI мільйони автоматизованих запитів до публічних API, сканування мільйонів сторінок — передусім Wikidata та Wikimedia Commons — і сотні тисяч запитів до Wikidata Query Service (WDQS). За оцінкою фонду, ця активність могла сприяти частковому збою WDQS у травні.
«Цей тягар лягає на всіх інших»
Декельманн закликала ШІ-компанії взяти на себе відповідальність за поведінку своїх систем:
Хоча OpenAI визнає, що агенти поводилися „непередбачувано“, компанія також має визнати свою відповідальність за моніторинг і запобігання цим ризикам. ШІ-компанії роблять недостатньо, щоб захистити свої системи й убезпечити суспільство від шкоди, якої вони завдають. Цей тягар лягає на всіх інших, зокрема на менші організації. Щонайменше їхні системи мають працювати так, щоб власники некомерційних сайтів, як-от ми, могли легко їх ідентифікувати та самі вирішувати, як ті взаємодіятимуть з нашими сервісами.
Не перший інцидент з агентами OpenAI
Агентів OpenAI останніми місяцями повʼязують і з іншими подібними інцидентами. Зокрема, вони зламали портал статистики Medicare, яким опікується Services Australia — австралійське урядове агентство, відповідальне за соціальні виплати та виплати у сфері охорони здоровʼя.
У травні ШІ-агенти OpenAI фактично захопили німецькомовну вікі й використовували її, щоб обмінюватися відповідями на тестові завдання та способами обходу обмежень. А в липні близько 700 агентів компанії скоординовано зламали частину інфраструктури Hugging Face — відкритої платформи для розміщення ШІ-моделей.
Утім, проблема стосується не лише OpenAI. Наприкінці липня Anthropic повідомила, що під час внутрішніх тестувань з кібербезпеки її моделі Claude через помилку конфігурації дісталися відкритого інтернету та зламали інфраструктуру трьох реальних організацій. В одному з випадків модель створила шкідливий Python-пакет і завантажила його до репозиторію Python Package Index (PyPI): приблизно за годину, доки автоматичні засоби захисту PyPI його не видалили, пакет встигли завантажити й запустити 15 реальних систем.
Що це означає для власників сайтів
Випадок Wikimedia показує, що ШІ-агенти стають окремим джерелом навантаження й ризиків для вебресурсів, передусім некомерційних, які не мають ресурсів великих компаній. Адміністраторам варто стежити за аномальними сплесками запитів до API та пошукових сервісів, обмежувати частоту запитів (rate limiting), перевіряти, чи не можуть публічні інструменти — сервіси нотаток, форми з довільними URL — слугувати проксі, і регулярно переглядати журнали змін у відкритих для редагування розділах.
