AI-інцидент — це не лише outage. Це правдоподібна шкідлива відповідь, зайвий tool call, розкриття даних, неконтрольована вартість, повтор бізнес-дії або непомітне падіння якості.
Добрий план дає змогу виявити, обмежити, розслідувати й відновити систему, не чекаючи пояснення від агента.
Визначте AI-інцидент і тяжкість
Створіть рівні за наслідками: витік, зайва дія, пошкодження записів, шкода клієнту, регуляторний ризик, фінансова втрата, недоступність і втрата моніторингу.
Враховуйте near miss. Заблокована спроба використати зайве право підтверджує потребу контролю.
Призначте власників і контакти
Потрібні incident lead, технічний і бізнес-власник, security/privacy, комунікації та контакт постачальника. Визначте право зупинки й погодження запуску.
Runbook має бути доступний поза ураженим AI. Зберігайте залежності, data flow, escalation і rollback.
Виявляйте за технічними й бізнес-сигналами
Використовуйте моніторинг агентів: пропуск trace, зайвий інструмент, повтор запису, помилка схеми, стрибок вартості, затримки, якість і скасування людьми.
Повідомлення користувачів спрямовуйте в один intake із correlation ID.
Спочатку обмежте шкоду
Зупиніть небезпечну здатність, не обов'язково весь бізнес. Відкличте tool, увімкніть read-only, передайте чергу людям, знизьте ліміт або ввімкніть fallback.
Kill switch має бути зовнішнім. Збережіть докази до зміни конфігурації, якщо це не продовжує шкоду.
- Підтвердити й призначити severity.
- Зупинити або обмежити дії.
- Захистити акаунти, токени й дані.
- Зафіксувати last known good.
- Повідомити власників.
Збережіть докази й оцініть scope
Збережіть traces, логи, версії моделі й промпта, tools, права, входи, виходи, approvals, API response і зовнішні зміни.
Визначте записи, користувачів, період і рішення. Шукайте той самий патерн ширше першого випадку.
Відновлюйте контрольовано
Виправте дані з авторитетного джерела, змініть credentials за потреби, розгорніть перевірену версію та виконайте reconciliation. Почніть із canary або shadow.
Повторіть передзапускові evals. Запуск дозволено, коли причина контролюється, моніторинг активний і rollback доступний.
Перетворіть висновки на контроль
Розділіть trigger, root cause, failure контролю та impact. Призначте corrective actions, власників і строки. Додайте патерн до regression tests.
NIST SP 800-61r3 пов'язує response з Detect, Respond і Recover.
Повідомляйте факти
Укажіть відоме, scope, containment, дію клієнта та час оновлення. Юридичні повідомлення погоджуйте з фахівцями.
Згенероване резюме не має бути єдиним записом. Важливу комунікацію затверджує людина.
Невеликий інцидент, що покращив процес
Під час великої тримовної передачі API я знайшов пошкоджений UTF-8 символ після прийняття чернетки сервером. Публікація зупинилася, записи залишилися в draft для порівняння.
Я змінив передачу, повторно надіслав повні тіла, перечитав записи й вимагав нульову різницю за всіма 21 полями. Після публікації перевірив сторінки.
Виправлення стало постійним regression rule. Цінність була не в ручній правці, а в новому автоматичному контролі.
Питання та відповіді
Коли вмикати kill switch?
Коли продовження збільшує шкоду або критичний контроль ненадійний. Право й пороги задайте заздалегідь.
Чи треба вимикати весь AI?
Не автоматично. Обмежте уражену здатність і залежності, зберігши безпечну роботу.
Які докази важливі?
Траси, версії, права, tool calls, входи, виходи, approvals, API response і зовнішні зміни.
Хто дозволяє запуск?
Призначені бізнес- і технічний власники з security, privacy або legal за потреби.
Коли recovery завершено?
Стан звірено, причина контролюється, тести пройдено, моніторинг працює, комунікацію завершено, завдання відстежуються.
Операційний аркуш контролю
До погодження внесіть кожен контроль у таблицю: власник, доказ, поріг і дата наступної перевірки. Фраза «контролювати якість» не є виконуваною. Правило «операційний власник щопонеділка перевіряє частку суттєвих виправлень і ставить процес на паузу вище погодженого порога» можна перевірити.
Пов'яжіть контроль із наслідком для бізнесу. Якщо помилка схеми може пошкодити запис клієнта, опишіть containment і reconciliation. Якщо стрибок вартості пояснюється сезонним обсягом, задайте контекст проти хибної ескалації.
Версіонуйте промпти, схеми, політики, інструменти та зовнішні залежності. Результат без конфігурації неможливо відтворити. Винятки повинні мати причину, власника і строк завершення.
Відрепетируйте людський шлях. Власник має знайти докази, зупинити або обмежити workflow, увімкнути fallback і пояснити стан без прохання до AI діагностувати себе.