Предвидьте, как функция может не выполниться, к чему это приведёт, почему это возможно и какие проверенные средства контроля действительно снижают риск.
За одну минуту
FMEA — структурированный анализ потенциальных отказов до того, как они нанесут ущерб. Для каждой функции команда сохраняет причинную цепочку:
Функция → вид отказа → последствие → причина → предотвращение → обнаружение → действие → остаточный риск.
Оценки тяжести, возникновения и обнаружения помогают сравнивать риски, но не заменяют суждение. Одинаковое произведение оценок может скрывать принципиально разные профили риска.
Лучше всего для: новых и изменяемых процессов, продуктов, интеграций и ИИ-workflow, особенно перед расширением полномочий системы.
Избегайте, когда: нет определённой функции и границы, команда оценивает риск в одиночку или заполняет числа без доказательств и решений.
Проблема, которую решает метод
Команды часто обсуждают «риски» общими словами или реагируют только после инцидента. В ИИ-системах дополнительная опасность возникает, когда средняя точность скрывает редкий тяжёлый отказ, а «человек в контуре» называется контролем без проверки видимости доказательств, времени и полномочий.
FMEA связывает каждый риск с конкретной функцией, механизмом отказа и действующим контролем. Это превращает тревогу в приоритетный план инженерных и операционных изменений.
Когда использовать метод
- перед запуском нового процесса, продукта, интеграции или автоматизации;
- при существенном изменении модели, данных, прав или последовательности действий;
- когда отказ может повлиять на деньги, безопасность, права или доверие;
- для проектирования контроля человеческого решения и исключений;
- после инцидента, чтобы расширить анализ на соседние возможные отказы;
- при сравнении вариантов архитектуры и контрольных барьеров.
Когда не использовать метод
- как универсальное доказательство безопасности;
- вместо анализа уже произошедшей первопричины;
- для одной итоговой оценки без причинной цепочки;
- если участники не знают реальный процесс и последствия;
- чтобы автоматически считать низкую частоту отсутствием риска;
- для публикации чувствительных сценариев угроз или персональных данных.
Необходимые данные
- система, граница, функции и ожидаемые результаты;
- затронутые стороны и возможные последствия;
- исторические дефекты, инциденты, near-miss и исключения;
- причины из процесса, данных, модели, интерфейса и полномочий;
- действующие средства предотвращения и обнаружения;
- правила оценок и приоритета;
- владельцы действий, сроки и критерии проверки;
- версии модели, наборы тестов, rollback и мониторинг эксплуатации.
Пошаговый процесс
1. Определите границу и функции
Опишите, что система должна делать, для кого и при каких условиях. Разбейте общий процесс на функции с наблюдаемыми выходами.
2. Сформулируйте виды отказов
Для каждой функции спросите: как она может не выполниться, выполниться частично, слишком поздно, не для того объекта или без необходимого разрешения?
3. Запишите последствия
Опишите ближайший и конечный эффект для клиента, сотрудника, организации и внешней стороны. Тяжесть относится к последствиям, а не к впечатлению от причины.
4. Найдите причины и механизмы
Отделяйте причину от вида отказа. В ИИ-workflow проверяйте качество и репрезентативность данных, контекст, интеграцию, prompt injection, дрейф, версию, интерфейс, права и организационные условия.
5. Зафиксируйте существующие средства контроля
Предотвращение мешает причине создать отказ. Обнаружение выявляет отказ или опасное условие до последствия. Планируемое действие ещё не является средством контроля.
6. Оцените и расставьте приоритеты
Применяйте согласованные определения тяжести, возникновения и обнаружения. Просматривайте измерения отдельно, особенно высокую тяжесть и слабый контроль, даже если итоговое произведение невелико.
7. Спроектируйте действия
Предпочитайте устранение причины и независимые барьеры. Для каждого действия назначьте владельца, срок, требуемые доказательства и способ проверки.
8. Проверьте остаточный риск
Меняйте оценку только после внедрения и подтверждения эффективности. После обновления модели, данных или процесса пересматривайте затронутые строки FMEA.
Взгляд через ИИ-автоматизацию
Для ИИ-систем недостаточно записать «галлюцинация» или «ошибка модели». Свяжите отказ с функцией и действием: неверно выбран получатель платежа, пропущен срочный запрос, раскрыто запрещённое поле, рекомендация исполнена без разрешения.
«Человек в контуре» работает как обнаружение только если:
- видны исходные доказательства и важные поля, а не только summary;
- есть время, компетентность и право остановить действие;
- интерфейс не подталкивает к автоматическому одобрению;
- измеряется эффективность проверки и утомление;
- низкая уверенность и исключения имеют отдельный маршрут;
- модель и проверка не разделяют один и тот же скрытый отказ.
Визуальная модель
Текстовая альтернатива: функция может отказать из-за причин процесса, данных или модели и вызвать последствие. Предотвращение и обнаружение снижают риск; проверка человеком, управляемое действие и подтверждение замыкают цикл.
Интерактивный пример
Ситуация
ИИ-помощник готовит возврат денег. Проверяющий видит краткое описание, но не исходный запрос, подтверждённую сумму и реквизиты получателя. После одобрения платёж отправляется автоматически.
Разбор
Функция: вернуть правильную сумму правильному клиенту. Вид отказа: платёж отправлен неверному получателю. Возможные причины: устаревший идентификатор, неверное сопоставление, неполный контекст. Последствия: финансовый ущерб, утечка данных, спор и потеря доверия.
Текущая человеческая проверка слаба: доказательства скрыты, а право одобрения связано с исполнением. Более сильные меры — независимая проверка владения реквизитами, лимиты, разделение подготовки/утверждения/исполнения, показ первичных данных и обязательный hold для несоответствий. Остаточный риск пересчитывается только после теста этих контролей.
Заметки фасилитатору
- Соберите владельца процесса, исполнителей, инженера, риск/безопасность и представителя затронутых пользователей.
- Пишите функцию глаголом и измеримым объектом.
- Не смешивайте причину, отказ и последствие в одной фразе.
- Просите доказательство для каждой оценки и контроля.
- Разбирайте высокую тяжесть отдельно от итогового балла.
- Проверяйте независимость контрольных барьеров.
- Фиксируйте версию системы и триггер повторного анализа.
Ожидаемый выпуск
- граница, функции и затронутые стороны;
- перечень видов отказа и последствий;
- причинные механизмы процесса, данных и модели;
- существующие меры предотвращения и обнаружения;
- обоснованные оценки и приоритеты;
- действия, владельцы, сроки и доказательства проверки;
- остаточный риск и решение о запуске;
- мониторинг, триггеры пересмотра и rollback.
Распространённые ошибки
- заполнять таблицу без межфункционального обсуждения;
- превращать вид отказа в общую формулировку риска;
- считать планируемое действие уже работающим контролем;
- ранжировать только по произведению оценок;
- считать отсутствие инцидентов в маленьком пилоте доказательством безопасности;
- называть любую человеческую проверку сильным контролем;
- не пересматривать FMEA после изменения модели или данных.
Контрольный список качества
- Граница и функции сформулированы конкретно.
- Причины, виды отказа и последствия разделены.
- Учтены затронутые стороны и редкие тяжёлые эффекты.
- Существующие контролы описаны как реально действующие механизмы.
- Оценки опираются на определения и доказательства.
- Высокая тяжесть не скрыта итоговым произведением.
- Человеческая проверка имеет данные, время и право остановки.
- Контроли по возможности независимы.
- Остаточный риск меняется только после проверки.
- Назначены мониторинг, пересмотр и rollback.
Шаблон
Рабочий шаблон FMEA в личном кабинете сохраняет функции, причинные цепочки, оценки, контрольные барьеры, действия и доказательства остаточного риска.
Проверка знаний
Команда снизила оценку обнаружения сразу после записи действия в план. Что неверно?
A. Ничего: план немедленно меняет риск.
B. Остаточный риск меняется только после внедрения и проверки.
C. Обнаружение всегда должно равняться тяжести.
D. У действия не должно быть владельца.
Ответ: B. Обещанный контроль пока ничего не предотвращает и не обнаруживает.
Связанные инструменты
- Контекст процесса: картирование потока
- Проверка причин: анализ первопричин, анализ Парето
- Проектирование контроля: защита от ошибок
- Проверка изменений: PDCA/PDSA
- Не путать с: отчётом об инциденте, общим реестром рисков или доказательством безопасности
Источники
- AIAG/VDA. FMEA Handbook. Официальный каталог AIAG (откроется в новой вкладке).
- SAE International. J1739: Potential Failure Mode and Effects Analysis (откроется в новой вкладке).
- SAE International. ARP5580: Recommended FMEA Practices for Non-Automobile Applications (откроется в новой вкладке).
- NIST. Artificial Intelligence Risk Management Framework 1.0 (откроется в новой вкладке).
- NIST. Generative Artificial Intelligence Profile (откроется в новой вкладке).
Источники проверены 3 августа 2026 года.