Автоматизация compliance-аудита: RAG-система с мониторингом изменений

Разработка AI для compliance: где ломается ручной аудит

Нормативная база обновляется быстрее, чем служба compliance успевает её прочитать. Поправка вступает в силу, а чек-лист проверки — нет: аудитор идёт по прошлой редакции, потому что новую ещё не разнесли по пунктам. Чем больше юрисдикций и внутренних регламентов, тем шире разрыв, и людьми он не закрывается — штат растёт линейно, а объём требований быстрее.

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

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

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

Эффекты автоматизации: скорость реакции и полнота проверок

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

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

Каждый пункт считаем на тех же данных, что были до внедрения, — иначе это впечатление, а не эффект. Если метрика не двигается, разбираем причину и меняем правила отбора.

Режимы работы системы проверки: сравнение подходов

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

Почему в рабочем контуре чаще остаётся гибрид

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

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

Этапы внедрения: от разбора норм до передачи в эксплуатацию

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

1. Разбор требований. Собираем регламенты, внутренние политики и прошлые предписания, разбираем их на проверяемые утверждения. Отдельно помечаем нормы, которые формализуются правилом, и оценочные, где решение остаётся за человеком.

2. Разметка корпуса документов. Формируем эталонные пары «фрагмент — вердикт аудитора», включая пограничные случаи и расхождения трактовок. Набор становится мерой качества решения и базой для будущих проверок.

3. Схема обработки. Определяем, как документ делится на смысловые блоки с сохранением нумерации пунктов, как ищется ответ и как к каждому выводу прикладывается ссылка на норму и версию документа.

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

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

6. Передача и обучение. Отдаём регламент обновления корпуса, инструкции для аудиторов и порядок разбора ошибок; команду заказчика учим добавлять новые нормы и правила самостоятельно.

Что передаём на руки: конфигурации, регламенты, документация

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

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

Комплект ведётся как живой документ: правки конфигураций и правил доступа проходят через ту же процедуру согласования, что и изменения системы, поэтому описания не расходятся с фактическим состоянием.

Кейс: проверка договоров и внутренних регламентов

Как выглядела работа до

Юридический отдел согласовывал партию из 400 договоров поставки. Три юриста читали тексты параллельно и сверяли каждый с внутренними регламентами и типовыми условиями: на партию уходило около трёх недель, а расхождения между проверяющими доходили до 18% замечаний. Один специалист пропускал пункт, другой его находил, стороны заново спорили о трактовке, часть замечаний дублировалась, часть терялась в переписке.

Что изменили

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

Что стало с метриками

Та же партия из 400 договоров проходит проверку за два дня вместо трёх недель. Доля расхождений между проверяющими снизилась с 18% до 4%: спорные пункты помечаются одинаково, а разбор идёт только по действительно неоднозначным условиям. Покрытие — 100% пунктов вместо ручной выборки, при этом юрист тратит время на 10–15 спорных мест, а не на чтение документа целиком.

Чем отличается поиск по базе знаний от правил на ключевых словах?

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

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

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

Технические сомнения, которые снимаем до старта

Сомнения по таким системам предсказуемы, и в разработке AI для compliance мы снимаем их до старта, а не в процессе внедрения. Ниже — то, что чаще всего проверяют на этапе оценки.

Откуда гарантия, что система не выдумывает нормы?

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

Нормативка меняется — что с индексом?

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

Сколько данных нужно для оценки?

Для пилота хватает одного тематического блока и 30–50 реальных вопросов с эталонными ответами. Этого достаточно, чтобы измерить точность поиска и понять, нужна ли донастройка модели.

Что с ответственностью после передачи?

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

Обсудим задачу: что нужно для оценки и плана работ

Чем конкретнее исходные данные, тем меньше допущений в оценке проекта и тем точнее план работ. Ниже — минимальный набор, который снимает 80% неопределённости и позволяет считать сроки по реальному объёму, а не по вилке. Если часть пунктов отсутствует — не страшно, зафиксируем их как допущения и проверим на первом этапе.

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

По этому набору мы возвращаемся с оценкой и планом: этапами, составом работ, точками контроля и тем, что понадобится от вашей стороны на каждом из них.