Автоматизация протоколов комиссии: как AI генерирует DOCX от черновика до подписания

Зачем автоматизировать протоколы закупочных комиссий

Секретарь тендерной комиссии тратит от 2 до 6 часов на один протокол оценки заявок. Ручной перенос баллов, копирование реквизитов, подгонка формулировок под требования 44-ФЗ — и всё это с риском ошибки, которая отправит документ на переделку.

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

Автоматическая генерация протоколов в DOCX снимает рутину и сокращает подготовку документа до минут. Разберём процесс по шагам: от загрузки заявок до подписания комиссией.

Проблема: почему ручное составление протоколов — узкое место

Секретарь комиссии собирает документ вручную: переносит данные из заявок, рассчитывает баллы по формулам из документации, формулирует обоснования, проверяет реквизиты. При 10–15 участниках объём рутинной работы измеряется часами.

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

• Опечатка в ИНН участника
• Неверная ссылка на пункт закона
• Арифметическая ошибка в расчёте баллов
• Некорректное обоснование отклонения заявки

Каждая из этих ошибок — потенциальная жалоба в ФАС и срыв сроков закупки. Для организаций с десятками процедур в месяц это системная проблема, а не единичный сбой.

Что такое автоматический протокол закупки

Автоматический протокол — это DOCX-документ, сгенерированный программой на основе структурированных данных заявок. AI-слой добавляет к шаблонной генерации интеллект:

• Извлечение данных из неструктурированных документов (PDF, сканы)
• Проверка участников по реестрам
• Расчёт баллов по формулам из документации закупки
• Генерация текстовых обоснований на естественном языке

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

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

Какие протоколы поддаются автоматизации

Закупочные процедуры по 44-ФЗ и 223-ФЗ предполагают несколько типов протоколов. Каждый из них поддаётся автоматизации, но с разной степенью сложности.

Протокол рассмотрения заявок

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

Обязательные поля:

• Номер и дата заседания комиссии
• Состав присутствующих членов комиссии (ФИО, должность, роль)
• Предмет закупки, номер извещения
• Перечень заявок с идентификационными номерами
• По каждой заявке: решение (допущен / отклонён) и обоснование

Что проверяется автоматически: наличие обязательных документов в составе заявки (лицензии, допуски СРО, выписки), соответствие предложения техническому заданию, правильность оформления. AI-система сверяет комплектность с чек-листом из документации и формирует заключение по каждому участнику.

Протокол оценки и сопоставления

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

Балльная система работает по формулам из постановления Правительства РФ № 2604 (для 44-ФЗ). Ценовой критерий — по формуле с отношением минимальной цены к предложенной. Квалификационные критерии — по шкалам, заданным в документации.

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

Итоговый протокол

Объединяет результаты рассмотрения и оценки в единый документ для конкурсных процедур. По сути — финальная сборка из двух предыдущих типов с добавлением итогового решения комиссии.

Архитектура решения: как устроен процесс генерации

Сквозной маршрут от исходных данных до готового DOCX состоит из четырёх этапов.

Этап 1. Загрузка и парсинг исходных данных

На вход системе поступают:

• Документация о закупке (извещение, ТЗ, проект контракта) — из неё извлекаются требования к участникам и критерии оценки
• Заявки участников — PDF, DOCX или структурированные данные с ЭТП
• Состав комиссии — ФИО, должности, роли (председатель, члены, секретарь)

Если заявки приходят в PDF, AI-модуль (OCR + LLM) извлекает данные: реквизиты, предложенные цены, подтверждающие документы. Для разработчиков это задача мультимодального парсинга: комбинация табличных данных, свободного текста и сканированных копий.

С точки зрения интеграции, данные с ЭТП (электронных торговых площадок) обычно доступны через API или в виде структурированных XML/JSON-выгрузок, что упрощает первый этап.

Этап 2. Валидация и проверка

Система автоматически проверяет:

• Комплектность заявки — сверка с чек-листом требований из документации
• Реквизиты участника — проверка ИНН, ОГРН по открытым реестрам (ЕГРЮЛ/ЕГРИП)
• Соответствие требованиям — наличие лицензий, допусков, опыта
• Отсутствие в реестре недобросовестных поставщиков (РНП)

Каждая проверка порождает структурированный результат: статус (пройдена / не пройдена / требует внимания) и текстовый комментарий. Именно эти результаты ложатся в основу обоснований в протоколе.

Для IT-менеджеров важно: этап валидации — наиболее регулируемая часть процесса. Логика проверок должна точно соответствовать требованиям закона и документации, поэтому она реализуется как детерминированный код, а не промпт к LLM.

Этап 3. Расчёт баллов и ранжирование

Алгоритм расчёта определяется типом процедуры и критериями из документации:

Ценовой критерий (для 44-ФЗ по ПП РФ № 2604):

Балл = (Цена_мин / Цена_участника) × Вес_критерия × 100

Где Цена_мин — минимальная предложенная цена среди допущенных участников.

Квалификационные критерии — оцениваются по шкалам. Например, опыт исполнения контрактов:

• 0 контрактов → 0 баллов
• 1–3 контракта → 30 баллов
• 4–10 контрактов → 70 баллов
• Более 10 → 100 баллов

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

Для разработчиков: расчётный модуль должен быть полностью детерминированным и аудитируемым. Каждый промежуточный результат сохраняется для возможной проверки. LLM на этом этапе не используется — только формулы.

Этап 4. Генерация DOCX

Финальный этап — сборка документа. Архитектурно это два подпроцесса:

1. Шаблонная генерация — структура документа, таблицы, реквизиты, подписи. Используется библиотека работы с DOCX (python-docx, docxtpl или аналоги). Шаблон содержит фиксированную структуру с плейсхолдерами.

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

Результат — DOCX-файл, готовый к проверке секретарём и подписанию членами комиссии.

Требования 44-ФЗ: что должно быть в протоколе

По ст. 48 Федерального закона № 44-ФЗ протокол обязан содержать:

Элемент	Источник данных	Автоматизация
Идентификационные номера заявок	ЭТП	Прямой перенос
Решение по каждой заявке (допуск/отклонение)	Результат валидации	Автоматическое формирование
Обоснование отклонения со ссылками на пункты закона и документации	AI-генерация	LLM + детерминированные правила
Значения по каждому критерию оценки	Расчётный модуль	Полностью автоматическое
Итоговый рейтинг участников	Расчётный модуль	Полностью автоматическое
Состав комиссии, дата, предмет закупки	Входные данные	Прямой перенос

Важно: по 223-ФЗ требования к составу протокола определяет положение о закупке конкретного заказчика. Базовая структура аналогична, но может включать дополнительные поля. Система должна поддерживать настраиваемые шаблоны.

Роль AI в обосновании решений

Генерация обоснований — та часть процесса, где AI приносит наибольшую ценность. Сравним два подхода:

Шаблонный подход (без AI):

«Заявка участника ООО "Ромашка" отклонена в связи с несоответствием требованиям документации.»

AI-подход:

«Заявка участника ООО "Ромашка" (ИНН 7712345678, идентификационный номер заявки 54321) отклонена на основании п. 3 ч. 5 ст. 48 Федерального закона № 44-ФЗ в связи с непредставлением в составе заявки действующей лицензии на осуществление деятельности по техническому обслуживанию медицинской техники, предусмотренной п. 2.3.1 документации о закупке (извещение № 0123456789012345).»

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

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

Технический стек: что нужно для реализации

Минимальный стек для системы генерации протоколов:

• Парсинг документов: OCR (Tesseract, облачные сервисы), PDF-парсеры (PyMuPDF, pdfplumber), LLM для извлечения структурированных данных
• Валидация: интеграции с ЕГРЮЛ/ЕГРИП (API ФНС), реестром недобросовестных поставщиков, внутренние правила проверки
• Расчётный модуль: детерминированная логика на Python/Java, покрытая тестами
• Генерация DOCX: python-docx, docxtpl, или серверный LibreOffice для сложной вёрстки
• LLM для обоснований: Claude API, GPT-4 или локальная модель — с чётким системным промптом и ограничениями
• Хранение и аудит: все промежуточные данные сохраняются для воспроизводимости результата

Для интеграции в существующую инфраструктуру заказчика система предоставляет REST API. Типичный сценарий: ЭТП или внутренняя СЭД вызывает endpoint с данными закупки, получает в ответ сгенерированный DOCX.

Workflow: от черновика до подписания

Полный цикл работы с автоматически сгенерированным протоколом:

1. Генерация черновика — система создаёт DOCX на основе данных заявок и документации
2. Проверка секретарём — секретарь просматривает документ, вносит правки при необходимости. Система подсвечивает места, требующие внимания (низкая уверенность парсинга, нестандартные ситуации)
3. Согласование с членами комиссии — документ направляется на review. Замечания фиксируются в системе
4. Финализация — секретарь вносит финальные правки, система регенерирует DOCX с учётом изменений
5. Подписание — документ подписывается членами комиссии (ЭЦП или на бумаге) и размещается в ЕИС

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

Выигрыш: цифры и эффекты

Метрика	Ручной процесс	С автоматизацией
Время подготовки протокола	2–6 часов	15–30 минут (включая проверку)
Типичные ошибки (реквизиты, расчёты)	Регулярно	Минимизированы
Единообразие обоснований	Зависит от секретаря	Стабильно высокое
Масштабируемость	Линейно с числом процедур	Не зависит от объёма

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

Ограничения и что учитывать

• LLM может ошибаться — обоснования требуют проверки человеком. Система должна маркировать участки с низкой уверенностью.
• Регуляторные изменения — формулы расчёта и требования к протоколам меняются. Обновление правил должно быть простым и не требовать переписывания кода.
• Качество входных данных — «мусор на входе — мусор на выходе». Сканы плохого качества, нестандартные форматы заявок снижают точность парсинга.
• Юридическая ответственность — ответственность за содержание протокола несёт комиссия, а не система. AI — инструмент, не замена человеческому решению.

Итог

Автоматизация протоколов закупочных комиссий — зрелая задача для AI-систем. Комбинация детерминированных расчётов, шаблонной генерации и LLM для текстовых обоснований позволяет сократить подготовку документа с часов до минут, снизить количество ошибок и обеспечить единообразие формулировок.

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

---

Подписывайтесь на наш канал: @vibelogia

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram