OpenAI 17 серпня 2026 року оголосила про розформування команди, яка контролювала ризики, повʼязані з розвитком власних AI-систем компанії. За даними AIN.ua, компанія поки не розкрила ні точну назву підрозділу, ні кількість людей, яких зачепило рішення, ні те, кому саме перейдуть їхні функції.

Для компаній, що будують продукти поверх GPT-моделей, це не просто кадрова новина. Команди контролю ризиків усередині лабораторій — це внутрішній механізм, який теоретично має право загальмувати чи заблокувати реліз моделі, якщо тестування показує непередбачувану поведінку. Коли такий підрозділ зникає або змінює форму, ринок читає це як сигнал про те, куди компанія спрямовує пріоритети на найближчий продуктовий цикл.

Ймовірно, за нашою оцінкою, рішення повʼязане радше з черговим переглядом організаційної структури, ніж з відмовою від напрямку безпеки як такого, — OpenAI вже робила подібні кроки раніше. Але це припущення, а не факт: офіційного пояснення причин розформування компанія не надала.

Що саме відомо про рішення OpenAI?

Відомо небагато: OpenAI розформувала команду, що відповідала за оцінку ризиків, повʼязаних з розвитком власного AI, і зробила це без розгорнутого публічного пояснення. Джерело не наводить ні заяв керівництва, ні коментарів колишніх співробітників команди — це різко контрастує з попередніми випадками, коли розпуск подібних підрозділів супроводжувався публічними листами й заявами про звільнення.

Це вже не вперше — чому OpenAI регулярно розпускає команди контролю ризиків?

Це вже щонайменше третій випадок за два роки, коли OpenAI реорганізовує підрозділ, повʼязаний з контролем ризиків штучного інтелекту. У травні 2024 року компанія розформувала команду Superalignment, яку очолювали Ілля Суцкевер (Ilya Sutskever) та Ян Лейке (Jan Leike) — обидва звільнилися, публічно заявивши, що напрямок безпеки почав програвати конкуренції за обчислювальні ресурси всередині компанії.

У жовтні 2024-го, після відходу дослідника Майлза Брандейджа (Miles Brundage), OpenAI розформувала команду AGI Readiness, розподіливши її функції між іншими підрозділами.

Патерн повторюється: команда з мандатом на контроль ризиків формується, працює обмежений час, а потім розчиняється в загальній структурі компанії саме в момент, коли темпи релізів прискорюються. Це не доводить, що безпека системно нехтується, — але доводить, що структурна стабільність команд контролю ризиків в OpenAI низька, а це саме той параметр, який варто відстежувати незалежно від офіційних заяв.

Що це означає для тих, хто будує продукти на GPT-моделях?

Для розробників і компаній, що інтегрують API OpenAI, головний практичний висновок — не покладатися на внутрішню safety-команду постачальника як на єдиний запобіжник у своєму продукті. Модель, яка пройшла внутрішню оцінку ризиків сьогодні, завтра може оновитися разом зі структурою, що цю оцінку проводила.

• Для продуктів у регульованих галузях (медицина, фінанси, юридична сфера) варто вести власне red-teaming тестування, а не спиратися лише на system card постачальника.
• Варто моніторити зміни в Preparedness Framework та подібних публічних документах OpenAI — розпуск команди контролю ризиків підвищує ймовірність, що методологія оцінки моделей також зміниться.
• При виборі постачальника моделі для критичних застосунків має сенс закладати план Б — можливість швидко переключитися на іншого провайдера, якщо політика безпеки зміниться без попередження.

Висновок AiiN: чому довіра до постачальника — не стратегія безпеки

Наша теза проста: чим частіше велика AI-лабораторія реорганізує власні команди контролю ризиків, тим менше сенсу зовнішнім командам розглядати ці підрозділи як гарантію. Безпека продукту, побудованого на чужому API, не може залежати від оргструктури постачальника, яка змінюється частіше, ніж релізний цикл самих моделей. Для AI-білдерів це аргумент на користь власного шару перевірки — незалежно від того, як називається команда всередині OpenAI цього кварталу.

Чи означає розпуск команди відмову OpenAI від безпеки AI?

Прямих доказів цього немає. AIN.ua не наводить заяв компанії про зміну пріоритетів у безпеці, а сам факт реорганізації підрозділу не еквівалентний відмові від контролю ризиків — функції могли просто перерозподілити.

Яку команду саме розформувала OpenAI?

Джерело не називає конкретної назви команди чи її керівників — відомо лише, що підрозділ відповідав за контроль ризиків, повʼязаних з розвитком власного AI компанії.

Що робити компаніям, які вже інтегрували OpenAI API?

Продовжувати роботу без паніки, але додати незалежну перевірку критичних сценаріїв використання власними силами й стежити за оновленнями публічної документації OpenAI щодо оцінки ризиків моделей.