Как да докладвам 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

  • Назначи incident commander и един канал за координация
  • Активирай containment: kill switch / safe mode / rollback
  • Замрази контекста: версии на модел/промпт/индекс/код
  • Събери evidence bundle (вход/изход/логове)
  • Оцени дали има данни/PII или регулаторен риск
  • Подготви кратък статус: „какво знаем“ / „какво правим“ / „следващ update“
  • Запиши действията (timeline), за да не се губи информация

Мини tabletop упражнения (за тренировка)

Поне веднъж на тримесечие симулирай 30 минути реакция по сценарий:

  1. RAG prompt injection: външен документ кара системата да разкрива вътрешна политика.
  2. Масова халюцинация след обновяване на модел: 30% от отговорите съдържат измислени факти.
  3. 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 (поетапно прилагане и срокове).