# Чому AI-тести безпеки Irregular для великих лабораторій схибили > Red-team-стартап Irregular, що перевіряє безпеку моделей Meta, Anthropic і OpenAI, сам припустився методологічних помилок у власних оцінках, пише NYT. - Опубліковано: 25 серпня 2026 р. (2026-08-25T10:08:19.259522+00:00) - Розділ: Безпека AI - На основі публікації: [NYT](https://www.nytimes.com/2026/08/25/technology/irregular-ai-test-hacks.html) - Видання: AiiN (https://aiin.news) - URL: https://aiin.news/article?slug=%D1%87%D0%BE%D0%BC%D1%83-ai-%D1%82%D0%B5%D1%81%D1%82%D0%B8-%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B8-irregular-%D0%B4%D0%BB%D1%8F-%D0%B2%D0%B5%D0%BB%D0%B8%D0%BA%D0%B8%D1%85-%D0%BB%D0%B0%D0%B1%D0%BE%D1%80%D0%B0%D1%82%D0%BE%D1%80%D1%96%D0%B9-%D1%81%D1%85%D0%B8%D0%B1%D0%B8%D0%BB%D0%B8 --- Стартап Irregular, який проводить red-team тестування безпеки фронтирних моделей для Meta, Anthropic і OpenAI, сам припустився методологічних помилок у власних оцінках ризиків. Про це 25 серпня 2026 року повідомила The New York Times, розібравши, як тести компанії, покликані виловлювати небезпечні можливості AI-систем перед релізом, самі виявилися вразливими до збоїв. Irregular — один із небагатьох незалежних підрядників, яким великі AI-лабораторії довіряють перевірку моделей на здатність допомогти зі створенням кіберзброї, біологічної зброї чи інших небезпечних сценаріїв. Компанія працює з Meta, Anthropic і OpenAI одночасно, тобто її висновки впливають на рішення про реліз моделей одразу в кількох найвпливовіших лабораторіях світу. Саме тому будь-яка тріщина в методології такого підрядника — це не локальний технічний глюк, а питання довіри до всієї системи зовнішньої верифікації AI-безпеки: якщо перевіряючий помиляється, лабораторії й регулятори отримують хибне відчуття контролю над ризиком. ## Що саме виявила NYT? За даними [NYT](https://www.nytimes.com/2026/08/25/technology/irregular-ai-test-hacks.html), проблема полягала не в тому, що моделі виявилися небезпечнішими, ніж вважали лабораторії, а в тому, що самі тести Irregular виявилися ненадійним інструментом вимірювання цього ризику. Видання описує методологічні прогалини в оцінках компанії — тобто в тому, як саме вона ставить моделям завдання, інтерпретує відповіді та робить висновок «безпечно» чи «небезпечно». Це принципова відмінність. Помилка в самій моделі — проблема розробника. Помилка в тесті, який має цю модель перевірити, — проблема всієї індустрії, бо на основі таких тестів приймають рішення про те, чи випускати систему публічно. ## Чому оцінка небезпечних можливостей AI взагалі така крихка? Індустрія red-team тестування фронтирних моделей існує лише кілька років, і єдиного визнаного стандарту методології в ній досі немає. Кожна компанія — від внутрішніх safety-команд лабораторій до незалежних підрядників на кшталт Irregular — будує власні протоколи оцінки, часто закриті для зовнішнього аудиту. На нашу оцінку, це системний ризик галузі: коли оцінювач одночасно є комерційним постачальником послуги для лабораторії, яку він же й перевіряє, стимул визнати власну методологію недосконалою низький, а перевірити результати ззовні майже нікому. Додатковий фактор — самі фронтирні моделі змінюються швидше, ніж встигають дозрівати методи їх тестування: те, що спрацьовувало як надійний тест півроку тому, може давати хибні результати на новій версії моделі. ## Що це означає для лабораторій і для індустрії AI-безпеки? Для Meta, Anthropic і OpenAI ситуація незручна: усі троє публічно посилаються на незалежне red-team тестування як на доказ відповідального підходу до релізів. Якщо методологія підрядника, на якого спираються одразу кілька лабораторій, виявляється вразливою, під сумнівом опиняється не одна конкретна перевірка, а весь ланцюжок доказів, на який компанії посилаються перед регуляторами й користувачами. Це також стосується ширшої тенденції — лабораторії дедалі частіше передають AI-агентам і автономним системам більше прав і відповідальності, спираючись саме на red-team оцінки як на гарантію безпеки; наприклад, ми вже писали про те, як [ШІ-агенти отримують забагато прав](https://aiin.news/article?slug=приватність-під-загрозою-чому-ші-агенти-отримують-забагато-прав) без адекватного контролю. Крихка методологія оцінки ризиків робить таке розширення повноважень ще менш обґрунтованим. ## Що з цього варто винести AI-білдерам? Наша теза проста: жоден red-team звіт — ні внутрішній, ні від спеціалізованого підрядника — не варто сприймати як остаточний доказ безпеки моделі. Це один сигнал серед багатьох, а не сертифікат. - Не покладайтеся на єдиний зовнішній аудит безпеки — вимагайте відтворюваності методології, а не лише фінального вердикту. - Якщо ви впроваджуєте модель у продукт з підвищеними ризиками (агенти з доступом до систем, фінансові операції), закладайте власний шар моніторингу — незалежно від того, що каже red-team звіт постачальника. - Ставтеся до заяв лабораторій про «пройдені тести безпеки» як до маркетингового аргументу, а не технічної гарантії, поки методологія тесту не опублікована. ## Хто такий Irregular і чому його наймають топ-лабораторії? Irregular — компанія, що спеціалізується на red-team тестуванні фронтирних AI-моделей: перевіряє, чи можуть вони допомогти зі створенням кіберзброї, шкідливого коду чи інших небезпечних сценаріїв. Meta, Anthropic і OpenAI звертаються до таких незалежних підрядників, щоб отримати оцінку ризиків, відокремлену від внутрішніх команд, які розробляли саму модель. ## Чи означає це, що моделі Meta, Anthropic і OpenAI насправді небезпечніші, ніж заявлено? Із того, що описує NYT, це прямо не випливає: йдеться про методологічні недоліки самих тестів, а не про підтверджені нові небезпечні можливості моделей. Але це означає, що впевненість лабораторій у власних оцінках безпеки має менше підстав, ніж вони, ймовірно, транслюють публічно. --- Теги: AI, AIбезпека, Irregular, redteam, OpenAI, Anthropic Джерело: AiiN — https://aiin.news/article?slug=%D1%87%D0%BE%D0%BC%D1%83-ai-%D1%82%D0%B5%D1%81%D1%82%D0%B8-%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B8-irregular-%D0%B4%D0%BB%D1%8F-%D0%B2%D0%B5%D0%BB%D0%B8%D0%BA%D0%B8%D1%85-%D0%BB%D0%B0%D0%B1%D0%BE%D1%80%D0%B0%D1%82%D0%BE%D1%80%D1%96%D0%B9-%D1%81%D1%85%D0%B8%D0%B1%D0%B8%D0%BB%D0%B8. Цитуючи, посилайтесь на канонічний URL.