Илья Смирнов, «Северсталь»: «Как мы “научили” нейросеть методологии аудита: архитектура, этапы и обход ограничений»

Когда Николай Лавров упомянул про конкурс «Лидеры металлургИИ будущего», он рассказал о его масштабе и значении для компании. Для нашей команды этот конкурс стал не просто соревнованием, а реальным шансом воплотить идею, которая зрела давно. Мы решили, что ассистент для внутреннего аудита должен быть не просто набором промптов, а полноценным инструментом, объединяющим несколько направлений проверки. Как мы этого добились, с какими трудностями столкнулись и что из этого вышло – читайте ниже.

Полное название нашего проекта – «Ассистент по анализу проблем и рисков в бизнес-процессах». Изначально мы создали его в рамках конкурса, но сама идея появилась гораздо раньше. Долгое время нас сдерживали три фактора.

Конкурс стал для нас идеальным катализатором. Организаторы пообещали всем участникам обучение инструментам работы с ИИ и разработке ассистентов. Мы собрали команду из шести человек: я как промпт-инженер для написания скриптов автоматизации, двое опытных коллег из операционного аудита (они помогли с методологией), коллега из охраны труда и промбезопасности (с методологией и чек-листами по своей теме) и двое коллег из IT-аудитов. Таким образом, в одном ассистенте удалось объединить три направления: операционный аудит, IT-аудит и аудит ОТиПБ.

В процессе обучения мы детально освоили платформу «ДаВинчи» и смежные инструменты, в частности n8n – аналог Microsoft Power Automate. За несколько недель разработали прототип и методику тестирования, оценивали и дорабатывали каждую версию. После конкурса работа не прекратилась – мы продолжаем итеративно улучшать продукт.

В нашего ассистента зашит объемный мега-промпт, основанный на нескольких этапах проверки. Методология включает пять ключевых этапов.

Этап 1. Выявление и оценка рисков.

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

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

На выходе – перечень ключевых рисков процесса с их приоритизацией.

Этап 2. Описание бизнес-процесса.

Входные документы: интервью с исполнителями по процессу, блок-схемы и диаграммы процесса, должностные инструкции.

Ключевые действия: детальное описание бизнес-процесса, выявление существующих контролей и ответственных.

На выходе – схема бизнес-процесса и таблица «Шаг / Контроль / Ответственный / Документы».

Этап 3. Планирование проверки.

Входные документы: перечень ключевых рисков с первого этапа и схема процесса с контролями со второго.

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

На выходе – техническое задание на аудит, программа проверки со списком тестов, описание границ и методики тестирования.

Этап 4. Проведение проверки и выявление недостатков.

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

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

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

Этап 5. Формирование отчета.

Входные документы: все итоговые документы предыдущих этапов, ограничения и допущения аудита.

Ключевые действия: структурирование выводов, подготовка отчета, подготовка рекомендаций.

На выходе – сводный отчет по аудиту с выводами и рекомендациями.

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

Архитектура решения

Пользователь заходит в корпоративный мессенджер Synapse, может прикрепить файлы, отправить текстовый запрос или голосовое сообщение. Инструмент n8n управляет потоком данных: голосовое сообщение направляется в SyntX (сервис транскрибации) и возвращается в виде текста, файлы отправляются в OCR-сервис для распознавания и также возвращаются в текстовом виде.

Почему текст? Потому что все наши ассистенты на платформе «ДаВинчи» работают исключительно с текстовыми входными данными.

Далее текст поступает к двум ассистентам. Основной ассистент аудитора ведет пользователя по методологии операционного аудита, запрашивает необходимые документы, дает рекомендации. Вспомогательный ассистент-наблюдатель отслеживает, не появляются ли в процессе IT или ОТиПБ-риски. Если такие риски обнаруживаются, он обращается к корпоративной базе знаний за соответствующими рекомендациями и обогащает ими ответы основного ассистента.

Можно было бы объединить все функции в одного ассистента, но, во-первых, промпт получился бы просто огромным, а во-вторых, специализация для ассистентов оказалась очень полезной. Когда ассистент ограничен узким контекстом, его ответы получаются более четкими и сфокусированными.

Ответ возвращается в Synapse, и пользователь продолжает работу по намеченному процессу.

Сейчас наш корпоративный OCR-сервис для распознавания файлов пока не умеет работать со сканами – только с машиночитаемым текстом: Excel, Word, PDF. В планах – добавить распознавание сканов. Также планируем развивать базу знаний по IT и ОТиПБ – пока там только базовые вещи.

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

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

Я отправил голосовое сообщение с запросом о плане действий, и ассистент ответил, определив, на каком этапе мы находимся.

!Важно, что пользователь может начать работу с любого этапа – если обращается с середины процесса, ассистент запросит недостающую информацию с предыдущих шагов.

Ассистент попросил уточнить цель аудита, описать процесс и предоставить контекст. Я объяснил, что это повторный аудит (предыдущий проводился три года назад), цели – убедиться в отсутствии дублирования идей, что сотрудники, которые по долгу службы должны заниматься предложением идей (сотрудники бизнес-системы и Центра развития), не участвуют в фабрике идей, что баллы начисляются честно и отсутствуют злоупотребления. Я также сообщил, что в наличии есть СТО по фабрике идей и результаты прошлого аудита.

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

Я сообщил, что после предыдущего аудита появился новый регламент 2024 года, в который были внесены рекомендации по итогам проверки 2023 года. Приложил новый регламент и попросил проанализировать, все ли необходимые изменения были реализованы. Ассистент подробно ответил, что выполнено, что выполнено не до конца, а что не выполнено вовсе, и на основе этого анализа предложил план тестирования.

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

Мы перешли к этапу описания бизнес-процесса. Ассистент задал уточняющие вопросы, затем выдал итоговый документ с описанием шагов процесса, ответственных лиц и существующих контрольных процедур. В этот момент ИИ-наблюдатель зафиксировал IT-риски и передал соответствующую информацию основному ассистенту.

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

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

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

В результате ассистент выдал документ, полностью соответствующий нашей стандартной форме отчета.

Ограничения по объему и их обход

Ограничения по количеству обрабатываемых символов существуют и накладываются самими моделями. Например, у DeepSeek 3.2 это около 132 тысяч токенов, а лимит системного промпта составляет 20 тысяч символов. Именно поэтому нам пришлось разделить функциональность на двух ассистентов – IT- и ОТиПБ-тематика уже не помещалась в одного.

Однако, поскольку мы работаем на внутренней платформе, есть возможность гибко подходить к этим ограничениям. Можно договориться с разработчиками и увеличить системный промпт с 20 до 30 тысяч символов. Ограничения самой модели обойти сложнее, но, например, подключенный нами Qwen3-Coder, хотя и заточен больше под задачи программирования, имеет лимит в 1 миллион токенов, чего для аудиторских задач вполне достаточно.

Сегодня наш ассистент уже помогает проходить все этапы аудиторской проверки – от сбора рисков до генерации финального отчета. Но главные вопросы остаются: есть ли реальная польза от таких «софтовых» решений в масштабах гигантского холдинга? Стоит ли овчинка выделки? И что ждет аудиторов в мире, где рутину берет на себя ИИ? Об уроках, перспективах и роли человека – в заключительной части.

Илья Смирнов, старший менеджер управления внутреннего аудита, «Северсталь»