Как да докладвам AI инциденти?
За да докладваш AI инцидент правилно, ти трябва ясен процес: дефиниция на „инцидент“, канали за сигнализиране, бърза триаж/ограничаване на щетата, събиране на доказателства (логове, версии, вход/изход), уведомяване на правилните хора и след това post-mortem с конкретни превантивни мерки. Инцидентът не е „грешен отговор“, а събитие с реална или потенциална вреда.
Дори ако инструментът е „само вътрешен“, процесът е важен, защото инцидентите се разпространяват бързо през автоматизации, интеграции и копиране на съдържание в мащаб.
Въведение
AI системите грешат по различен начин от класическия софтуер: халюцинации, prompt injection, пристрастия, изтичане на данни, неочаквана деградация след промяна на данни. Затова „incident reporting“ не е бюрокрация, а механизъм за безопасност.
Рамки като NIST AI RMF насърчават управление на риск чрез измерване, мониторинг и реакция. В ЕС допълнително има регулаторен контекст: EU AI Act (поетапно приложим; основно от 2 август 2026) въвежда задължения за определени системи, включително около управление на риск, прозрачност и реакции при сериозни проблеми за високорискови приложения.
Бързата и честна реакция при AI инцидент е част от етичното използване на AI.
Стъпка 1: Дефинирай какво е AI инцидент във вашия контекст
Направи работеща дефиниция, например:
- Вреда за потребител (неправилен отказ/одобрение, финансови щети).
- Изтичане на лични/чувствителни данни (PII, търговска тайна).
- Нарушение на политика (генериране на забранено съдържание).
- Системна деградация (качество пада под праг, масови грешки).
- „Near miss“: почти инцидент, който е спрян навреме.
Добави severity нива (S1–S4), за да знаеш кога ескалацията е задължителна.
Стъпка 2: Назначи роли, канали и SLA за реакция
Минимално ти трябват:
- Incident commander (води реакцията).
- Технически owner (ML/инженер).
- Продукт/бизнес owner.
- Security/Privacy контакт (ако има данни).
Канали:
- Един „официален“ канал (ticket/форма), който всички знаят.
- Спешен канал (чат/телефон) за S1/S2.
Определи SLA: например S1 реакция до 15 минути, първи статус до 60 минути.
Стъпка 3: Събери минималния пакет доказателства
За да можеш да разследваш, събирай (и пази) следното:
- Timestamp, потребителски контекст (ако е позволено), среда (prod/staging).
- Вход: prompt/данни (с редактване на PII при нужда).
- Изход: пълен отговор/решение.
- Версии: модел, prompt/template, правила, индекс (при RAG), код.
- Логове: retrieval резултати, scores, latency, грешки.
Практика: направи „one-click export“ на incident bundle.
Стъпка 4: Триаж и ограничаване на щетата (containment)
Първата цел е да спреш вредата:
- Активирай kill switch или превключи към безопасен режим (fallback).
- Ако има leakage: блокирай достъпи, ротирай ключове, ограничѝ логове.
- Ако е халюцинация/политика: включи по-строги guardrails и модерация.
Не чакай root cause, за да ограничиш риска.
Стъпка 5: Комуникация и уведомяване
Комуникацията е част от доброто управление:
- Вътрешно: информирай заинтересованите (product, security, support).
- Към клиент: ако има влияние, дай честен статус и какво правиш.
- Към регулатор: ако домейнът е регулиран или е висок риск, провери задълженията и сроковете.
Важно: комуникацията трябва да е фактическа. Не обещавай „няма да се повтори“, ако още не знаеш причината.
Стъпка 6: Root cause analysis (RCA)
Структура за RCA:
- Какво точно се случи (timeline).
- Защо се случи (5 whys).
- Какво позволи да се случи (липса на тест, мониторинг, guardrail).
Чести причини при AI:
- data drift;
- промяна в preprocessing;
- неочакван prompt injection;
- нова версия на модел/доставчик;
- недостатъчен eval сет.
Стъпка 7: Корекция и превенция
След RCA добави конкретни „анти-повторение“ мерки:
- Нови тестове (golden set, safety tests, bias slices).
- Алерти и метрики (качество, токсичност, leakage).
- Промени в retrieval (филтри, reranking) при RAG.
- Процесни промени (ревю на промптове, промени по версии).
Стъпка 8: Post-mortem и учене
Направи кратък документ (вътрешен):
- Какво научихме.
- Какво променихме.
- Как ще измерим, че работи.
Фокусът е върху системата, не върху вината.
Стъпка 9: Severity матрица (за да не спорите в кризата)
Най-големият проблем при инциденти е, че хората спорят „колко е сериозно“ вместо да действат. Решението е проста матрица, която е предварително договорена. Пример (адаптирай към бизнеса):
- S1 (критичен): има/вероятно има значителна вреда за потребители; изтичане на чувствителни данни; масова грешка в ключова функция; потенциални регулаторни последици.
- S2 (висок): ограничена вреда или висок риск от ескалация; сериозен спад в качество; многократни нарушения на политика.
- S3 (среден): единични случаи без доказана вреда; открит „near miss“, който е спрян.
- S4 (нисък): козметични/UX дефекти, които не водят до вреда.
Сложи конкретни тригери: например „повече от N оплаквания за 1 час“, „leakage сигнал от DLP“, „toxicity score над праг“ и т.н.
Стъпка 10: Детекция и мониторинг (преди да стане инцидент)
Инцидентите обикновено са видими по сигнали, ако ги търсиш:
- Качество: sampling на отговори + човешка проверка, регресии по golden set.
- Безопасност: токсичност, PII leakage, jailbreak опити, забранени теми.
- Стабилност: latency, timeouts, rate на грешки, промяна в разпределенията (drift).
- Retrieval (при RAG): спад в hit rate на очаквани документи, промяна в top-k източници, необичайно ниски similarity scores.
Практика: дефинирай 5–10 аларми, които са наистина action-oriented. Ако имаш 100 аларми, ще ги игнорираш.
Стъпка 11: Регулаторен и правен слой (ЕС)
Тук целта не е да станеш юрист, а да знаеш кога да ескалираш. В ЕС контекстът през февруари 2026 г. е, че EU AI Act е поетапно приложим (основно от 2 август 2026). За определени системи, особено високорискови, се очаква по-строго управление на риск, проследимост и процеси за реакция при сериозни проблеми, включително докладване към компетентни органи при определени условия.
Отделно, ако инцидентът е свързан с лични данни, може да има задължения по GDPR (например при нарушение на сигурността на личните данни). Практично правило: при S1/S2 и при съмнение за PII leakage, включи security/privacy/юрист рано, не „след като се оправим“.
Чеклист: първите 60 минути при S1/S2
Мини tabletop упражнения (за тренировка)
Поне веднъж на тримесечие симулирай 30 минути реакция по сценарий:
- RAG prompt injection: външен документ кара системата да разкрива вътрешна политика.
- Масова халюцинация след обновяване на модел: 30% от отговорите съдържат измислени факти.
- Bias инцидент: модел за приоритизация системно понижава заявки от определен сегмент.
Таблетопът открива организационни дупки: липсващи роли, неясни канали, липса на логове, липса на kill switch.
Шаблон: AI incident report (минимум)
- Заглавие и severity
- Дата/час и среда
- Засегнати потребители/системи
- Симптом (какво се вижда)
- Възпроизводимост
- Evidence bundle (вход/изход/версии)
- Containment действия
- RCA (кратко)
- Корекции и превенции
Метрики за зрелост на управлението на инциденти
За да знаеш дали процесът работи, следи няколко прости метрики (не за „наказание“, а за подобрение):
- MTTD (mean time to detect): колко бързо разбирате, че има проблем.
- MTTR (mean time to recover): колко бързо ограничавате вредата и връщате функцията в нормален режим.
- % инциденти с пълен evidence bundle (вход/изход/версии).
- % инциденти, които водят до конкретна превантивна промяна (нов тест, аларма, guardrail).
- „Repeat rate“: дали един и същ клас инцидент се повтаря.
Ако MTTD е висок, проблемът е в мониторинга и сигналите. Ако MTTR е висок, проблемът е в kill switch, ролите или зависимостите.
Пример: какво съдържа един incident bundle
- request_id / conversation_id
- user сегмент (ако е позволено)
- prompt + system prompt версия
- retrieved docs (ID, score, metadata) при RAG
- model name + версия + параметри
- output + всички tool calls (ако има агенти)
- latency по стъпки
- flags (toxicity, PII, policy violations)
С такъв пакет можеш да възпроизведеш проблема и да го решиш за часове, вместо за дни.
Съвети за по-добри резултати
- Дръж версиониране: модел, данни, prompt, индекс.
- Логвай retrieval и правила, иначе RCA е невъзможен.
- Тествай „near miss“ случаи: те са евтиният урок.
- Тренирай екипа с „tabletop exercises“ (симулирани инциденти).
Пример: кратък попълнен инцидент (1 абзац)
S2 инцидент, 2026-02-10 09:12 UTC, prod: чатботът връща вътрешни линкове към страници, които не са за клиенти. Входът е невинен въпрос, но retriever-ът не филтрира по access_level след последна миграция на индекса. Containment: активиран е safe mode, който изключва RAG и връща „ще се свържем“. Доказателства: request_id, логове на retrieval с top-k документи, версия на индекса и конфигурацията. RCA: липса на regression тест за ACL филтър. Превенция: добавен тест за достъп, аларма за извличане на internal_only документи и ревю на migration чеклист.
Чести грешки, които да избягваш
- Да нямаш kill switch.
- Да нямаш ясна дефиниция за инцидент.
- Да не пазиш доказателства и версии.
- Да криеш проблема вместо да го управляваш.
Източници и актуалност (проверено февруари 2026)
- NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0) като рамка за риск и процеси.
- ISO/IEC 42001:2023: AI management system (AIMS) като организационна основа за политики, роли и контрол.
- Европейска комисия: AI Act timeline (поетапно прилагане и срокове).