--- md_version: 2 title: "Explainable AI: почему «черный ящик» не работает для бизнес-решений" description: "Интерпретируемость модели, объяснение прогноза и юридическое обоснование решения — разные задачи. Разбираем статью 16 закона № 152-ФЗ, EU AI Act и минимальный контур контроля." canonical: "https://tesstech.ru/blog/explainable-ai-pochemu-chernyy-yashchik-ne-rabotaet-dlya-biznes-resheniy/" markdown: "https://tesstech.ru/blog/explainable-ai-pochemu-chernyy-yashchik-ne-rabotaet-dlya-biznes-resheniy/index.md" published: "2026-06-24" modified: "2026-09-08" author: "Tess Technology" organization: "ООО ТЕСС ТЕХНОЛОДЖИ" language: "ru-RU" category: "Технологии и AI" direction: "technology-ai" tags: ["Искусственный интеллект","Аналитика","Big Data","Цифровая экономика"] image: "https://tesstech.ru/upload/iblock/2eb/73ni7zdigausws85tkblqms7i3uwi592.PNG" original_source: "https://tesstech.ru/info/articles/biznes-sovety/explainable-ai-pochemu-chernyy-yashchik-ne-rabotaet-dlya-biznes-resheniy/" related_service: title: "Системная ИИ-трансформация" url: "https://tesstech.ru/services/ai-transformation/" related_articles: - title: "AutoGPT, CrewAI, LangGraph: какой фреймворк AI-агентов выбрать для аналитики" url: "https://tesstech.ru/blog/autogpt-crewai-langgraph-kakoy-freymvork-ai-agentov-vybrat-dlya-analitiki/" markdown: "https://tesstech.ru/blog/autogpt-crewai-langgraph-kakoy-freymvork-ai-agentov-vybrat-dlya-analitiki/index.md" - title: "NLP для анализа клиентских отзывов: практическое руководство" url: "https://tesstech.ru/blog/nlp-dlya-analiza-klientskikh-otzyvov-prakticheskoe-rukovodstvo/" markdown: "https://tesstech.ru/blog/nlp-dlya-analiza-klientskikh-otzyvov-prakticheskoe-rukovodstvo/index.md" - title: "Real-time аналитика для B2B: как выбрать допустимую задержку" url: "https://tesstech.ru/blog/real-time-analitika-dlya-b2b-kak-vnedrit-bez-bolshikh-zatrat/" markdown: "https://tesstech.ru/blog/real-time-analitika-dlya-b2b-kak-vnedrit-bez-bolshikh-zatrat/index.md" sources: - "https://ips.pravo.gov.ru/api/ips/legislation/document?baseid=None&hash=98490812b3409e2a8d78a11ca9010f434ea3d9250a11dbbdb78690cd5551bdd6" - "https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai" --- # Explainable AI: почему «черный ящик» не работает для бизнес-решений Объяснимость требуется не каждой модели в одинаковом объеме. Для подсказки следующего товара и для решения, влияющего на кредит, найм или доступ к услуге, последствия ошибки различаются. Требования к объяснению определяются сценарием, данными, ролью человека и тем, кто будет использовать результат. **Три разных задачи под одним словом** Интерпретируемость описывает, насколько человек может понять устройство модели. Локальное объяснение показывает, какие признаки повлияли на конкретный прогноз. Объяснение решения включает более широкий контекст: какие данные использовали, какое правило применили после прогноза, кто утвердил действие и как его можно оспорить. SHAP или список значимых признаков закрывает только часть задачи. Если модель формирует балл, а итоговый отказ возникает из последующего бизнес-правила, объяснять нужно всю цепочку. **Глобальное, локальное и контрфактическое объяснение** Глобальное объяснение описывает общую логику модели: какие группы признаков влияют на результат, где качество ниже и в каких данных модель обучалась. Локальное относится к одному прогнозу. Контрфактическое показывает, какое допустимое изменение входа могло бы привести к другому результату. Эти формы отвечают разным пользователям. Команде управления риском нужна общая картина и ограничения. Оператору — причина конкретного сигнала. Человеку, которого затронуло решение, — понятное основание и доступный путь пересмотра. Один и тот же график вклада признаков редко подходит всем трем аудиториям. **Что уже регулируется в России** В России нет единого горизонтального закона об искусственном интеллекте, построенного по модели EU AI Act. Автоматизированные решения при этом попадают под действующие нормы. Статья 16 закона № 152-ФЗ регулирует решения, основанные исключительно на автоматизированной обработке персональных данных, если они создают юридические последствия для человека или затрагивают его права и законные интересы. Для скоринга, найма и других чувствительных процессов нужно проверить состав данных, правовое основание, роль человека, способ уведомления и порядок оспаривания. EU AI Act применяется по установленной сфере действия, а не по самому факту иностранного партнерства. Для конкретной системы проверяют, выводится ли она на рынок ЕС, используется ли в ЕС, кто выступает поставщиком и оператором и к какой категории риска относится сценарий. Правовой вывод требует анализа фактической схемы использования. **Что должен уметь бизнес-контур** Первый уровень — воспроизводимость. Для решения должны сохраняться версия модели, версия признаков, входные данные, правила после модели и время расчета. Без этого невозможно восстановить причину результата. Второй уровень — понятное объяснение для роли. Дата-сайентисту нужны распределения и вклад признаков. Риск-менеджеру — связь с политикой и лимитами. Клиенту или сотруднику — ясное описание факторов и доступного порядка пересмотра без раскрытия коммерческой тайны сверх требуемого объема. Третий уровень — проверка устойчивости. Команда смотрит, меняются ли объяснения после небольших изменений входа, не используются ли прокси чувствительных признаков и одинаково ли работает процедура для разных групп. **Как выбрать метод** Линейная модель или небольшое дерево могут быть достаточно прозрачными сами по себе. Для сложных ансамблей и нейросетей применяются локальные и глобальные методы объяснения. Они тоже имеют ограничения: объяснение может быть нестабильным, зависеть от фоновой выборки и создавать убедительную картинку без причинного смысла. Выбор метода фиксируется в протоколе проверки. Там указывают пользователя объяснения, решение, допустимую задержку, ограничения метода и тесты стабильности. Для решений с существенными последствиями полезно сравнить сложную модель с более простой базовой и проверить, оправдывает ли прирост качества потерю прозрачности и рост стоимости контроля. **Где объяснение может ввести в заблуждение** Метод объяснения строит приближение к поведению модели. Он не доказывает причинность и не гарантирует, что признак допустимо использовать. Высокий вклад почтового индекса может отражать географию, доход или историческое смещение данных. Технический отчет должен отмечать такие прокси и показывать тесты по релевантным группам. Стабильность тоже проверяется. Если небольшое изменение несущественного поля полностью меняет объяснение при близком прогнозе, использовать его для спорного решения опасно. Команда тестирует несколько методов и фиксирует версию библиотеки, фоновые данные и параметры. **Приемка системы у поставщика** В договор и программу испытаний стоит включить выгрузку входных данных и версии модели для конкретного решения, описание ограничений метода, время построения объяснения и формат журнала. Заказчик должен иметь возможность воспроизвести спорный случай в контролируемом контуре. Отдельно проверяется роль человека. Кнопка «подтвердить» не превращает автоматизированное решение в содержательный ручной контроль, если сотрудник не видит оснований, не может изменить результат или отвечает за недостижимый срок обработки. **Эксплуатационный контроль** После запуска полезно отслеживать точность модели, долю решений на ручном пересмотре, причины отмены автоматического результата, стабильность объяснений и обращения пользователей. Эти данные показывают, где описание модели расходится с реальным процессом. **Минимальный пакет перед запуском** - карта данных и признаков; - описание модели и ограничений применимости; - журнал версии модели и решения; - тесты качества по релевантным группам; - локальное объяснение для спорного случая; - процедура ручного пересмотра; - владелец инцидента и срок ответа. **Источники** - [Официальный текст закона № 152-ФЗ, статья 16](https://ips.pravo.gov.ru/api/ips/legislation/document?baseid=None&hash=98490812b3409e2a8d78a11ca9010f434ea3d9250a11dbbdb78690cd5551bdd6) - [Европейская комиссия: нормативная база EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) Техническая объяснимость, юридическое уведомление и управленческая ответственность связаны, но не заменяют друг друга. Рабочая система должна показывать всю цепочку от данных до действия. ## Услуга по теме [Системная ИИ-трансформация](https://tesstech.ru/services/ai-transformation/) — Находим процессы, где ИИ дает измеримый результат, и сопровождаем пилот до внедрения. ## Материалы по теме - [AutoGPT, CrewAI, LangGraph: какой фреймворк AI-агентов выбрать для аналитики](https://tesstech.ru/blog/autogpt-crewai-langgraph-kakoy-freymvork-ai-agentov-vybrat-dlya-analitiki/index.md) - [NLP для анализа клиентских отзывов: практическое руководство](https://tesstech.ru/blog/nlp-dlya-analiza-klientskikh-otzyvov-prakticheskoe-rukovodstvo/index.md) - [Real-time аналитика для B2B: как выбрать допустимую задержку](https://tesstech.ru/blog/real-time-analitika-dlya-b2b-kak-vnedrit-bez-bolshikh-zatrat/index.md)