Оцінка, опублікована на arXiv 6 липня 2026 року, прогнала 302 перевірені на якість інциденти в Kubernetes через моделі з пошуковим доповненням і виміряла дві здібності окремо. Назвати сервіс-першопричину: правильно від 91,4% до 99,7% випадків. Обрати робочу дію з відновлення для інциденту, який щойно продіагностувала: від 36,8% до 60,3%. Між цими двома колонками лежить від сорока до п'ятдесяти п'яти пунктів, і ця відстань - найкорисніше число, опубліковане про AIOps цього року.
Це твердження про види роботи, а не про якість моделей. Модель добре читає і погано вирішує, і це ділить ринок на дві купи. Частина операційної роботи падає помітно, на очах у людини, яка її тримає. Частина падає, перетворившись на дію проти продакшну. AIOps заробляє гроші на першому виді й наразі є пасивом у другому, а більшість розчарувань на цьому ринку - від того, що його купують для другого після демо першого.
Кореляція алертів, дедуплікація і перша чернетка опису подій
PagerDuty продає свій AIOps-продукт як такий, що зрізає шум алертів аж до 91%. Прочитайте це поруч із опитуванням лютого 2026 року серед 1 039 фахівців із SRE, DevOps та IT-експлуатації, спонсорованим NeuBird, у якому 44% повідомили про збій за останній рік, пов'язаний із придушеними чи проігнорованими алертами. Кореляція, яка згортає сорок сповіщень в один інцидент, - це справжній виграш. Кореляція, яка тихо вирішує, яких сповіщень ви не побачите ніколи, - це те, як стаються ті 44%, і різницю між ними робить одне: чи можна перевірити саме групування.
Найсильніші випадки - ті, які людина може перевірити за секунди. Модель, яка читає історію деплоїв, зсув метрики і три потоки логів та пише чернетку опису інциденту, робить роботу, яку інакше о 3-й ночі робить хтось із поганою пам'яттю, а коли вона помиляється, докази лежать у тому самому абзаці. Пояснити, чому зрушив рахунок, - задача того самого типу, повна кореляцій, які людина помічає із запізненням на місяць, і State of FinOps 2026 від FinOps Foundation, випущений 19 лютого 2026 року на вибірці з 1 192 респондентів, що керують річними витратами понад 83 мільярди доларів, виявив: 98% з них тепер керують і витратами на ШІ, проти 31% двома роками раніше. Перетворити закритий інцидент на написаний runbook - ще краще: факти вже усталені, а найгірший результат - людина, яка виправляє одне речення.
AI code review в інфраструктурі ловить один клас помилок і сліпий до іншого
Veracode 2026 GenAI Code Security Report, опублікований 28 липня 2026 року, протестував понад 100 моделей і виявив, що середній показник проходження за безпекою застряг на 56%, піднявшись на один пункт з 55%. Приблизно 44% задач на генерацію вносили ризиковану вразливість, коли ніхто спеціально не просив про безпеку. Найкращий результат, GPT-5.5, дійшов до 68% - і все одно провалює одну задачу з безпеки з трьох.
Корисна частина - саме нерівномірність. Ці моделі проходили задачі на SQL-ін'єкції у 83% випадків і на криптографію у 87%, але на cross-site scripting лише у 15%, а на log injection - у 12%. AI-рев'ювер сильний там, де бачив тисячу розмічених прикладів, і майже сліпий деінде, і він не скаже вам, у якому режимі зараз перебуває. На diff'і infrastructure-as-code використовуйте його як другого читача для помилок, очевидних заднім числом: security group, відкрита на 0.0.0.0/0, зміна, яка насправді є заміною, а не оновленням. Не робіть його брамою: класи, які він пропускає, - це ті, під які ніхто не написав правила.
Автономне виправлення - там, де докази перестають підтримувати обіцянку
Те саме дослідження несе висновок, який має закрити розмову про self-healing ще на рік. Навіть коли модель правильно визначала і сервіс-першопричину, і тип збою, вона обирала непридатне виправлення в 39,5-62,0% тих інцидентів, які сама ж продіагностувала правильно. Діагноз не переноситься в дію. Прогноз Gartner від червня 2025 року про те, що понад 40% проєктів агентного ШІ будуть скасовані до кінця 2027 року, називав неадекватні контролі ризику поруч із вартістю - і бракує саме їх.
Планування потужностей падає зі спорідненої причини: модель видає впевнене число з тонких доказів, а впевнене число - це саме те, чого хоче нарада з планування. Стаття 14 Акту ЄС про штучний інтелект написана саме проти цього: вона вимагає, щоб людина-наглядач могла перервати високоризикову систему і зупинити її в безпечному стані, і називає упередження автоматизації тим, чому нагляд має протистояти.
Стеля витрат має стояти вище за білінг-консоль провайдера
У травні 2026 року автономному агенту видали необмежені облікові дані AWS і сказали просканувати порти DN42, аматорської мережі. Він підняв п'ять інстансів m8g.12xlarge по 48 vCPU кожен, плюс балансувальники навантаження та Lambda-функції, а потім раз за разом заново застосовував той самий шаблон CloudFormation. Оператор дізнався про це приблизно через 24 години зі списань із картки на загальну суму 6 531,30 USD - за workload, який, за оцінкою спільноти, помістився б на VPS за 5 USD на місяць. Пізніше AWS зменшив рахунок до 1 894 USD. Захистом, який спрацював, виявився кредит доброї волі.
Жоден бюджетний інструмент великих провайдерів цього б не зупинив, і всі три пишуть про це прямо. Amazon документує AWS Budgets як такі, що оновлюються до трьох разів на добу, причому кожне оновлення зазвичай відстає від попереднього на 8-12 годин - каденція, зроблена для людей, які роблять дорогі помилки по одній за раз. Microsoft заявляє, що перевищений поріг бюджету в Azure не впливає на ресурси й не зупиняє споживання, а дані про витрати зазвичай доступні протягом 8-24 годин. Google Cloud заявляє, що бюджет лише з алертами не обмежує автоматично ані використання, ані витрати. AWS постачає open-source рішення Budget Controls, яке спрацьовує на 90% бюджету, покриває чотири сервіси в одному регіоні й визнає, що storage і мережа продовжують накопичувати рахунок. Агенція з трьох людей, про яку писали в липні 2026 року, отримала списання AWS на 14 000 USD за один день - при звичайному місячному рахунку від 10 до 15 USD - після того, як зловмисники витягли статичні ключі з інстанса й витратили їх на виклики моделей Bedrock.
Наша відповідь - поставити ліміт там, де видаються облікові дані, а не там, де збирається рахунок. Витрати в Sencai відстежуються в момент, коли вони виникають, по провайдеру, проєкту та середовищу, з лімітами й бюджетами, які сигналізують ще під час накопичення, а не на білінговому циклі у 8-24 години. Автоматично діяти при перевищеному ліміті - це в нашому роадмапі, і воно ще не випущене, тож сьогодні облікові дані все одно відкликає людина. ШІ - єдиний бюджет, який ми можемо обмежити наперед: він купується в кредитах, а кредит - це фіксована сума грошей, а не кількість токенів, тож зміна ціни моделі рухає те, скільки токенів купує кредит, і ніколи те, скільки він вартий. Кожен платний персональний план має місячну квоту й жорстку стелю, встановлену як кратне до неї, тож скрипт, який зірвався з ланцюга, не може згенерувати необмежений рахунок. Runbook'и проходять через затвердження з тієї самої причини: модель пропонує, іменована людина виконує.
Слід аудиту, який може сказати, людина це зробила чи модель
Стаття 12(1) Акту ЄС про штучний інтелект вимагає, щоб високоризикові системи технічно дозволяли автоматичний запис подій протягом усього життєвого циклу системи, а стаття 26(6) вимагає від розгортачів зберігати ці логи щонайменше шість місяців, якщо інший закон не каже довше. Якщо ви плануєте під дату серпня 2026 року - виправте її. Регламент (ЄС) 2026/1744, Цифровий омнібус щодо ШІ, чинний з 27 липня 2026 року, переніс самостійні високоризикові системи за Додатком III на 2 грудня 2027 року, а вбудовані в продукти системи за Додатком I - на 2 серпня 2028 року. Дати посунулися; обов'язки - ні.
Операційна причина це будувати не має нічого спільного з дедлайном. Через шість місяців після інциденту питання стоїть так: зміну зробила людина чи модель, - і конфігурація, яка пише дії ШІ в одну систему, а людські в іншу, не відповість на нього без join'а, якому ніхто не довіряє. Ми відмовилися тримати два записи: дії моделі й дії людей лягають в один append-only слід. Sencai експортує його як CSV з entry_hash і prev_hash у кожному рядку, тож читач, який не вірить нам на слово, може перерахувати ланцюг самостійно. Поле, яке справді заслуговує на своє місце, - маленьке поле поруч з actor, яке каже, чи прийшла зміна від людини, чи від моделі, що витрачає квоту людини.
Правило, яке випадає з доказів, негламурне і тримається. Дозвольте моделі читати будь-що, зокрема й те, що вона читає погано, бо погане прочитання видно в абзаці, який вона написала. Дозвольте їй писати лише там, де іменована людина підписує зміну, а під нею лежить ліміт облікових даних - на випадок, якщо ця людина теж помиляється. Між сповіщенням провайдера на циклі у 8-24 години і кимось, хто читає пошту в будні, є димовий датчик і немає спринклера. В оператора DN42 був димовий датчик.