Отказ от «магии ИИ» в регулируемых отраслях

Финансы, медицина, КИИ требуют объяснимости.

Что произошло

Первые пилоты языковых моделей в банках, клиниках и на объектах критической инфраструктуры проходили по одному сценарию. Бизнес-подразделение показывало впечатляющую демонстрацию. Затем проект попадал к рискам, комплаенсу, службе безопасности или внутреннему аудиту, и там задавали вопросы, на которые демонстрация не отвечала. Почему модель дала именно этот ответ. Даст ли она такой же завтра. Кто отвечает, если ответ окажется неверным. Где это записано.

Пилоты либо останавливались, либо переходили в формат «игрушка для внутреннего пользования без последствий». Дело не в консерватизме регулируемых отраслей: в них уже существует дисциплина принятия решений — с документированными основаниями, ответственными лицами и аудиторским следом. Система, которая в эту дисциплину не встраивается, не может участвовать в принятии решений, какой бы сильной ни была модель внутри.

Сдвиг, который происходит сейчас, — переход от вопроса «какая модель лучше» к вопросу «какая архитектура позволяет проверить результат». Требование объяснимости из препятствия превратилось в техническое задание. Оказалось, что оно выполнимо — если объяснимость проектируется на уровне системы, а не ожидается от модели.

Как это устроено

Что спрашивает регулятор и аудитор

Вопросы регуляторов и аудиторов к системам с ИИ не новы — это те же вопросы, которые задаются к любому процессу принятия решений. Отличие в том, что для традиционных систем ответы на них очевидны из кода и регламентов, а для систем с языковой моделью их нужно обеспечить специально.

Вопрос	Что за ним стоит	Что должна обеспечить архитектура
На каком основании принято решение	Требование обоснованности: решение опирается на факты, а не на «мнение» модели	Ответ со ссылками на источники
Можно ли воспроизвести результат	Требование воспроизводимости для проверки	Журнал с версией модели, промптом, контекстом, источниками, параметрами
Кто несёт ответственность	Требование персональной ответственности	Человек в точке принятия решения с фиксацией его подтверждения
Какие данные использовались	Требования к обработке данных, тайне, категориям	Контроль состава данных на входе, фильтрация, журнал доступа
Что происходит при ошибке	Требование управляемости риска	Порядок обнаружения, эскалации, исправления, оценка последствий
Как система проверялась	Требование валидации перед применением	Набор проверочных случаев, метрики, повторная проверка при изменениях

Ни один из вопросов не касается устройства модели. Все они касаются устройства системы вокруг неё. Это и есть ключ: объяснимость достигается архитектурой.

Объяснимость как свойство архитектуры

Языковая модель сама по себе не объяснима в том смысле, который нужен аудитору. Просьба «объясни, почему ты так ответила» даёт правдоподобный текст, который может не иметь отношения к тому, как ответ был получен на самом деле.

Объяснимой должна быть система. Четыре свойства, которые её обеспечивают:

Ответ со ссылкой на источник. Модель не «знает» — она получает документы, найденные по запросу, и формирует ответ на их основе, указывая, откуда взято каждое утверждение. Проверяющий открывает источник и сверяет.
Разбиение на проверяемые шаги. Задача делится на этапы, у каждого из которых есть вход, выход и способ проверки. Ошибка локализуется в конкретном шаге, а не в «чёрном ящике».
Человек в критичных точках. Действия с необратимыми последствиями или влиянием на клиентов, пациентов, работу объектов выполняются после подтверждения ответственного лица.
Журнал. Всё, что нужно для воспроизведения и разбора, записывается автоматически и хранится по правилам организации.

Каждое из четырёх свойств — решение о конструкции системы, а не о выборе модели, и реализуется с любой моделью, включая открытые, развёрнутые в контуре.

Ответ со ссылкой на источник

Технически это архитектура поиска с дополнением контекста: запрос пользователя преобразуется в поиск по корпоративной базе знаний, найденные фрагменты передаются модели, модель формирует ответ строго на их основе. Такая архитектура известна как RAG, и её ценность в регулируемых отраслях — не в качестве ответов, а в проверяемости.

Три правила, которые превращают RAG из демонстрации в аудируемую систему:

Нет источника — нет ответа. Если в базе знаний не найдено релевантных документов, система сообщает об этом, а не отвечает из «общих знаний» модели. Это правило снимает основную часть рисков выдуманных фактов.
Источники версионируются. Ссылка ведёт на конкретную версию документа на момент ответа. Регламент изменился — старый ответ ссылается на старую версию, и это видно.
Поиск проверяется отдельно от генерации. Качество поиска — какие документы найдены по запросу — измеряется на наборе проверочных запросов независимо от того, что потом сделала модель. Большинство ошибок таких систем — ошибки поиска, а не генерации.

Векторное хранилище, например Qdrant, полнотекстовый поиск в PostgreSQL и модель на vLLM достаточны, чтобы весь путь от запроса до ответа проходил на инфраструктуре компании.

Разбиение на проверяемые шаги

Соблазн — дать модели задачу целиком: «прочитай обращение и подготовь ответ». Результат невозможно проверить иначе, чем перечитав всё заново. Альтернатива — конвейер из шагов, каждый из которых даёт проверяемый промежуточный результат.

Для обработки обращения это может выглядеть так: извлечь из текста структурированные поля (кто, о чём, какие документы приложены); классифицировать тип обращения по закрытому перечню; проверить обязательные условия детерминированными правилами, а не моделью; найти применимые регламенты; подготовить проект ответа со ссылками; передать на подтверждение.

Принцип распределения: всё, что можно проверить правилом, проверяется правилом. Модель применяется там, где нужна работа с естественным языком — извлечение, классификация, формулировка. Жёсткие ограничения — сроки, суммы, обязательные реквизиты, запреты — реализуются кодом, который аудитор может прочитать.

Каждый шаг имеет собственный набор проверочных случаев и метрику качества: ухудшение на одном шаге видно сразу и не маскируется остальными, а модель можно менять на одном шаге, не трогая остальные.

Человек в критичных точках и журнал

Точки, в которых обязателен человек, определяются не техническими соображениями, а последствиями. Отправка ответа клиенту, изменение записи в медицинской документации, изменение конфигурации объекта инфраструктуры, любое действие, которое нельзя отменить, — здесь система готовит, человек подтверждает. Подтверждение — не формальная кнопка: интерфейс показывает источники, промежуточные результаты и то, в чём система не уверена.

Журнал фиксирует для каждого случая: запрос, версию модели и её параметры, промпт, найденные источники с версиями, результаты каждого шага, итоговый ответ, кто и когда подтвердил, что изменил перед подтверждением. Журнал — это не логи приложения, а самостоятельная сущность с правилами хранения, доступа и неизменяемости, согласованными с безопасностью и аудитом.

Слабые места предсказуемы. Поиск возвращает нерелевантные документы, и модель строит убедительный ответ на неверном основании — поэтому качество поиска измеряется отдельно. База знаний содержит устаревшие документы — поэтому нужен процесс актуализации. Человек начинает подтверждать не глядя — поэтому интерфейс показывает основания, а подтверждения выборочно перепроверяются. Смена версии модели меняет поведение — поэтому проверочный набор прогоняется при каждом изменении.

Аудитор не спрашивает, как устроена модель. Он спрашивает, можно ли проверить результат и кто за него отвечает.

Как это выглядит на практике

Банк из первой сотни, обработка обращений. Подготовка проектов ответов на типовые обращения клиентов. Система извлекает суть обращения, классифицирует, находит применимые регламенты и тарифы, готовит проект со ссылками на пункты документов. Сотрудник видит проект, источники и отметки о неуверенности, редактирует и отправляет. Модель — в контуре банка. Внутренний аудит провёл выборочную проверку по журналу: для каждого ответа удалось восстановить основания. Скоринг и решения по кредитам в периметр проекта не входили.

Сеть клиник, документарная работа. Не диагностика — подготовка выписок, ответов на запросы страховых, сверка оформления документации с требованиями. Система работает с обезличенными данными там, где возможно, а доступ к данным пациентов — через права сотрудника. Каждый документ содержит ссылки на записи медицинской информационной системы, из которых взяты данные. Врач подтверждает. Проект согласован с ответственным за защиту персональных данных до старта.

Субъект КИИ, отчётность по инцидентам. В изолированной сети — модель на vLLM, база знаний из внутренних регламентов и истории инцидентов, без внешних подключений. Система помогает дежурному инженеру составить отчёт об инциденте: собирает данные из журналов мониторинга, находит похожие случаи, предлагает формулировки со ссылками на регламент. Никаких действий с оборудованием система не выполняет и не предлагает. Отчёт подписывает инженер.

Что это значит для российской компании

Регулируемые отрасли в России имеют собственные ограничения, которые определяют архитектуру раньше, чем выбор модели.

Финансовый сектор. Требования Банка России к операционной надёжности и защите информации, банковская тайна. Практическое следствие: данные клиентов не могут передаваться во внешние сервисы, модель размещается в контуре банка, доступ к данным — через существующую ролевую модель.

Медицина. Врачебная тайна и специальная категория персональных данных по 152-ФЗ — данные о здоровье. Следствие: обработка только с законным основанием, локализация, ограничение доступа, обезличивание там, где возможно. Любой сценарий, в котором модель влияет на медицинское решение, требует отдельной оценки, и начинать с него не следует.

Критическая информационная инфраструктура. Изолированные сети, требования к допуску, срок перехода значимых объектов на отечественные решения — 1 января 2028 года. Следствие: модель, хранилище, поиск — на отечественном или открытом стеке внутри изолированного сегмента. vLLM для модели, Qdrant или PostgreSQL для поиска, отечественная ОС — рабочая комбинация без внешних зависимостей.

Отдельного порядка сертификации систем с языковыми моделями пока нет, и бремя доказательства лежит на компании: внутренние регламенты, документированная архитектура, журнал, результаты проверок. По нашему опыту, аудит таких систем проходит легче, чем ожидалось, — вопросы аудитора совпадают с тем, что архитектура и так фиксирует.

Кадровая сторона: для таких систем нужны не «специалисты по ИИ», а люди, которые понимают процесс и регуляторные требования и умеют формулировать проверочные случаи, — сотрудники подразделений и внутреннего контроля. Их участие — условие, а не пожелание.

Что делать: пошагово

Выберите административный или документарный сценарий. Подготовка ответов, выписок, отчётов, сверка документов с требованиями. Не скоринг, не диагностика, не управление оборудованием. Критерий: ошибка системы обнаруживается человеком до наступления последствий.
Определите, кто подтверждает результат. Конкретная роль, конкретное действие в интерфейсе, конкретная ответственность. Если ответственного назвать не удаётся, сценарий не готов.
Соберите базу знаний с версионированием. Регламенты, тарифы, формы, инструкции — с владельцами, датами и процессом актуализации.
Спроектируйте конвейер шагов. Извлечение, классификация, проверка правилами, поиск, подготовка проекта, подтверждение. Для каждого шага — вход, выход, способ проверки, метрика.
Постройте проверочный набор вместе с экспертами подразделения. Десятки реальных случаев с эталонными результатами по каждому шагу. Без него нельзя сказать, работает ли система и не ухудшилась ли она после изменений.
Реализуйте журнал как отдельный компонент. Состав записи, хранение, доступ, неизменяемость — согласовать с безопасностью и аудитом до запуска.
Проведите репетицию аудита. Пригласите внутренний контроль до запуска, дайте ему журнал и попросите проверить десяток случаев. Замечания на этом этапе дешевле, чем после.
Запускайте с выборочным контролем подтверждений. Часть подтверждённых результатов перепроверяется независимо. Это защита от подтверждения «не глядя» и источник данных для улучшения.

Типичные ошибки

Начать со сценария с высокими последствиями. Скоринг, диагностика, управление объектом. Почему плохо: требования к проверке максимальны, а опыта построения проверяемых систем ещё нет. Что вместо: административные сценарии, на которых отрабатывается архитектура и аудит.
Объяснимость через самообъяснение модели. Почему плохо: текст «почему я так решила» не связан с тем, как решение получено, и аудитор это увидит. Что вместо: ссылки на источники, промежуточные результаты шагов, журнал.
Выбор модели по общим рейтингам. Почему плохо: рейтинги измеряют не то, что нужно вашему процессу, а сильная модель без проверяемой архитектуры не проходит аудит. Что вместо: выбор по результатам на вашем проверочном наборе при фиксированной архитектуре.
База знаний без владельцев. Почему плохо: устаревший регламент в базе даёт корректно оформленный, но неверный ответ со ссылкой. Что вместо: владелец и дата актуальности у каждого документа, процесс обновления.
Внешний API для пилота «на время». Почему плохо: данные ушли за периметр, и это уже нарушение, независимо от намерений. Что вместо: модель в контуре с первого дня, даже если она слабее.

Как понять, что вы на верном пути

Для любого ответа системы можно открыть источники и убедиться, что утверждения из них следуют.
Для любого случая из журнала можно восстановить: модель, промпт, контекст, шаги, кто подтвердил.
У каждого шага конвейера есть проверочный набор и метрика, и они прогоняются при любом изменении.
Ответственный за результат назван, а его подтверждение фиксируется и выборочно проверяется.
Данные не покидают контур, и это подтверждено службой безопасности, а не заявлено командой проекта.
Внутренний контроль участвовал в проекте до запуска и принял состав журнала.

Вопросы, которые нам задают

Не снижает ли проверяемая архитектура качество ответов? Ограничение «нет источника — нет ответа» уменьшает число ответов, но не их качество. В регулируемых отраслях отказ ответить — допустимый результат, а уверенный неверный ответ — нет.

Можно ли использовать внешние модели, если данные обезличены? Формально обезличивание меняет правовой режим данных, но доказать полноту обезличивания сложно, а ответственность за ошибку остаётся на компании. Для регулируемых отраслей мы рекомендуем модель в контуре: это снимает вопрос, а не создаёт аргументы для спора с регулятором.

Как убедить бизнес, что начинать нужно с документарных сценариев? Показать экономику: документарная работа занимает значительную часть времени квалифицированных сотрудников, и ускорение здесь измеримо и безопасно. Сценарий с высокими последствиями даёт больший эффект на бумаге, но его вероятность дойти до продуктива через аудит существенно ниже.

Возьмите один документарный процесс, в котором сотрудники тратят часы на поиск оснований и оформление, и спроектируйте для него конвейер с источниками и подтверждением. Пригласите внутренний контроль на первую же демонстрацию — его вопросы станут вашим техническим заданием.