AI-агент для заполнения веб-форм и тендерных заявок
Десятки внешних порталов — государственные и корпоративные площадки, каждая со своим набором полей, лимитами на длину строки, обязательными вложениями и правилами именования файлов. Данные при этом лежат в учётной системе, вложениях к письмам и папках на сетевом диске, а не в одном месте. Перенос данных в формы вручную занимает часы на одну заявку и почти всегда приносит расхождение с источником.
Цена ошибки выше, чем кажется: пропущенный обязательный файл, реквизит с опечаткой или дата в неверном формате — и заявка возвращается на доработку либо отклоняется формально, ещё до оценки по существу. Когда тендерные заявки готовят в последний день, времени на перепроверку не остаётся — часть заявок не уходит вовсе.
AI-агент меняет схему: он разбирает структуру конкретной формы, сопоставляет поля с источниками в учётной системе (1С, выгрузки, реестры), подтягивает нужные сканы и справки, проверяет обязательность и заполняет форму. Человек остаётся на подтверждении перед отправкой — то есть на решении, а не на переносе.
Автоматизация заявок снимает рутину со специалиста: вместо ручного заполнения веб-форм он проверяет готовый черновик. При этом AI-агент работает с теми формами, которые есть — дорабатывать чужие площадки под себя не нужно. Ниже разбираем, как это устроено и что остаётся под контролем заказчика.
Что меняется в процессе подготовки заявок и коммерческих данных
До внедрения заявка собиралась вручную: специалист открывал учётную систему, переносил карточку компании, банковские данные и позиции в форму заказчика, затем вычитывал всё построчно. На один лот уходили часы, а при потоке из десятков заявок работа шла в спешке. Агент снимает механическую часть — сбор и перенос данных, — а человеку остаётся проверка.
Реквизиты перестают быть источником возвратов. Расхождения в наименовании, ИНН, КПП, адресе и банковских данных — самая частая причина, по которой заявку отправляют на доработку. Агент берёт значения из одного справочника, проверяет контрольные суммы и подставляет поле с указанием источника, поэтому несоответствие видно до отправки, а не после замечания комиссии.
Нагрузка на ключевого специалиста меняется качественно. Раньше копированием и сверкой занимался самый опытный сотрудник — тот, кто нужен на ценовой части и технических требованиях. Теперь его время уходит на содержательные разделы, а рутинная сборка идёт параллельно по нескольким заявкам.
Предсказуемость подачи растёт: у каждой заявки есть статус, перечень незаполненных полей и напоминание о сроке. Пропуск срока подачи перестаёт быть рядовым риском — заявка собирается заранее и лежит готовой к отправке, остаётся принять решение по цене и условиям.
Эффект считаем по четырём величинам: время на одну заявку, доля возвратов из-за расхождений в реквизитах, число заявок на специалиста и доля поданных в срок. Их снимаем на старте и повторяем после внедрения, чтобы результат был измеримым, а не декларативным.
Режимы работы AI-агента: автономный и с подтверждением
Режим работы — это не галочка в настройке, а разный уровень доверия к данным и разная цена ошибки. Агент извлекает значения из карточки поставщика, коммерческого предложения и уставных документов, сопоставляет их с полями формы и дальше действует по одному из трёх сценариев: заполняет сам и отправляет, готовит черновик на контроль перед отправкой или только подсказывает оператору.
| Режим | Как ведёт себя агент | Когда подходит | Ограничения |
|---|---|---|---|
| Автономный режим | Заполняет форму и отправляет заявку без участия человека, спорные поля закрывает значением по умолчанию | Массовые однотипные заявки, площадки с предсказуемой формой, данные уже выверены | Ошибка уходит в отправленную заявку; нужны журнал действий и правила отката |
| Заполнение с подтверждением | Готовит черновик целиком, подсвечивает поля с низкой уверенностью, отправляет после подтверждения оператора | Тендеры с ценой и юридически значимыми формулировками, новые площадки | Требует времени оператора — минуты на заявку |
| Подсказки оператору | Форму не трогает, предлагает значение рядом с полем и ссылку на источник | Незнакомые формы, разовые закупки, обучение на новых типах документов | Скорость полностью зависит от оператора |
Выбор режима задаёт уровень доверия к данным, а не удобство интерфейса: если источники противоречат друг другу, агент не должен молча выбирать значение. Поэтому режимы назначаются посекционно — реквизиты и контакты можно отдать автономному режиму, а ценовое предложение и декларации держать на подтверждении. Смена режима не требует переписывать сценарий: правила наследуются от типа поля, а журнал фиксирует, какое значение и из какого документа подставлено.
Как проходит внедрение: этапы инженерной работы
Начинаем не с настройки модели, а с инвентаризации: агент не заполнит поле, если неизвестно, откуда брать значение и по какому правилу его нормализовать. Поэтому работа идёт последовательно — от аудита форм к опытной эксплуатации, и на каждом этапе остаётся артефакт, который можно проверить.
- Аудит форм и источников данных. Собираем все формы и тендерные площадки, разбираем структуру полей, обязательность и ограничения формата. Параллельно фиксируем источники: реквизиты, карточки товаров, прайсы, сканы документов, переписку по заявке.
- Карта полей. Сопоставляем каждое поле формы с источником и правилом извлечения: тип данных, нормализация дат и адресов, единицы измерения, что считается допустимым значением.
- Настройка сценариев заполнения. Описываем логику: что заполняется автоматически, где нужна проверка человеком, как агент ведёт себя при отсутствии данных — оставляет поле пустым или запрашивает уточнение.
- Проверка на тестовых заявках. Прогоняем сценарии на накопленных заявках и сверяем с эталоном: доля полей, заполненных верно с первого раза, какие расхождения повторяются. Ошибки правим в карте полей, а не в отдельном ответе.
- Опытная эксплуатация. Агент работает в режиме подсказки: готовый вариант видит оператор и подтверждает его. Так набирается статистика по формам, которые не попали в тестовый набор.
- Передача в эксплуатацию. Отдаём документацию по карте полей, регламент её обновления при изменении форм и инструкцию для операторов. После передачи правки в сценариях команда заказчика вносит сама.
Конфигурации, правила доступа и регламенты после внедрения
Внедрение заканчивается не демонстрацией, а передачей комплекта артефактов, по которым систему можно эксплуатировать и развивать без нас. Ниже — то, что физически остаётся у заказчика в его контуре и репозитории.
- Настройки агента и схемы разметки полей — конфигурации по каждому типу формы: обязательные поля, источники значений, проверки перед отправкой.
- Правила доступа и роли пользователей — матрица «роль → действие → область данных»: кто запускает заполнение, кто подтверждает отправку, кто видит черновики.
- Журнал действий — по каждой заявке: кто инициировал, что агент подставил автоматически, что оператор исправил вручную, чем закончилась отправка.
- Регламент работы с формами — порядок обработки очереди, правила эскалации при отклонении и точки, где обязательна проверка человеком.
- Инструкция для оператора — сценарии разбора ошибок разметки, повторного запуска, корректировки источника данных и обращения в поддержку.
- Схема интеграций и план отката — задействованные системы, порядок хранения ключей, возврат к ручному режиму без потери заявок.
- Порядок сопровождения — обновление правил и версий, периодичность проверки качества разметки, ответственные по зонам.
Передача занимает один-два рабочих сеанса с вашей командой — дальше систему ведёт внутренний инженер или администратор, а мы подключаемся только к изменениям логики.
Кейс: заполнение тендерных заявок на потоке
Тендерный отдел холдинга с восемью направлениями ведёт поток заявок на поставку оборудования и услуг. До внедрения каждая заявка собиралась вручную: специалист открывал форму площадки, переносил реквизиты из карточки контрагента, искал актуальные сертификаты в сетевой папке и вписывал характеристики из каталога. На одну заявку уходило 35–50 минут, а на пике сезонного спроса отдел обрабатывал лишь часть приглашений — остальные закрывались по сроку подачи.
Что изменили в схеме работы
Основные потери были не в наборе текста, а в повторных заявках: большинство позиций уже подавалось в других лотах, но собиралось заново с нуля. Мы разобрали формы площадок на поля и связали их с внутренним справочником — реквизиты, сертификаты и характеристики берутся из одного источника с контролем версии и срока действия. Агент подставляет данные в форму, помечает поля без подтверждённого значения и отдаёт заявку на проверку: без подтверждения специалиста отправка не уходит. По каждой позиции сохраняется профиль, и повторная подача собирается из истории — меняются только условия лота.
Метрики до и после
Итоги кейса внедрения зафиксировали так: время на заявку — с 35–50 минут до 5–7, доля отклонений по формальным причинам — с 12% до 2%. Поток вырос с 30 до 90 заявок в неделю при том же составе тендерного отдела, потому что снялась не скорость печати, а повторная сборка одних и тех же данных. Отдельно проверяли связку с Единой информационной системой в сфере закупок: расхождения между карточками ушли, так как источник реквизитов теперь один.
Что делать, если формы на порталах часто меняются?
Агент не привязывается к жёстким координатам и порядку полей — он опирается на смысловые признаки: подпись, подсказку, тип ввода, соседние метки и структуру блока. Переименование поля, перестановка секций или смена разметки не ломают заполнение: сопоставление пересчитывается на лету по совокупности признаков, а не по одному зашитому правилу.
Карта полей — отдельный слой описания, а не код: в ней указано, какой реквизит заявки соответствует каждому полю, какие форматы и правила проверки применяются. Обновление карты полей после правки портала занимает минуты и не требует пересборки решения — меняется описание, сам агент остаётся тем же.
После заполнения агент проходит форму повторно: сверяет внесённые значения с исходными данными, проверяет маски, обязательные и скрытые поля, реакцию формы на ввод. Расхождения не уходят как есть — поле помечается и отдаётся на ручную проверку, а не заполняется наугад.
Обновление описания полей ведём мы как часть решения: отслеживаем изменения разметки на подключённых порталах, фиксируем их и переносим в карту полей. Заказчику не нужно держать инженера, который вручную переписывает правила после каждой правки на стороне портала.
Каждое действие остаётся в журнале: видно, какое поле распознано, что подставлено и что проверено. Устойчивость к правкам портала получается предсказуемой — вместо гонки за меняющейся формой вы получаете процесс, который восстанавливается за один цикл проверки.
Технические сомнения и ограничения решения
Точность здесь — измеряемая величина: агент подставляет значения, извлечённые из ваших документов, и не додумывает отсутствующее. Каждое поле хранит ссылку на фрагмент-источник, поэтому проверяющий видит, откуда взялась цифра. На моделях уровня OpenAI доля полей, принятых без правки, настраивается под конкретный набор форм, а не берётся из общей статистики.
Насколько точно агент заполняет поля?
Числа, даты и суммы проходят проверку формата и диапазона, текстовые поля сверяются со справочником допустимых значений. Если в документе два противоречащих значения или поле не найдено — оно остаётся пустым и уходит в очередь на проверку человеком, а не заполняется догадкой.
Как обрабатываются вложения и табличные приложения?
Вложения разбираются на текст и таблицы: строки сопоставляются с позициями заявки, файлы прикрепляются с сохранением имени и порядка. Если площадка принимает только определённый формат, документ конвертируется, а исходник остаётся в черновике заявки для сверки.
Какие доступы к данным нужны решению?
Отдельная учётная запись с правом только на подачу заявок и токен с ограниченным сроком действия. Доступа к внутренним системам, переписке и базам агент не получает, а журнал действий показывает, какой документ читался и какое поле заполнено.
Что происходит при прерванном заполнении?
Черновик заявки сохраняется после каждого подтверждённого шага вместе с ключом идемпотентности. Повторный запуск продолжает с последнего шага, а не с начала, поэтому дубли на площадку не уходят, а незаполненная заявка не отправляется вовсе.
Обсудим задачу: с чего начать работу
Первая встреча — рабочая, а не презентационная. Разбираем, какие формы и заявки заполняются у вас сейчас, кто этим занят и на каких полях чаще всего возникают ошибки. Чтобы разговор был предметным, достаточно прислать образцы документов и доступ к тестовому контуру — остальное уточняем по ходу.
- Перечень входных данных: 5–10 примеров уже заполненных форм (PDF, DOCX, XLSX), пустые шаблоны и внутренние инструкции по заполнению, если они есть.
- Карта источников значений: откуда AI-агент берёт данные — карточка компании, реестры, прошлые заявки, справочники. Отмечаем, что доступно машиночитаемо, а что придётся приводить в порядок.
- Правила и ограничения: обязательные поля, требования к форматам значений и проверки, которые заявка не проходит при расхождении.
- Сценарии отказа: что агент делает, когда данных нет или они противоречивы — оставляет поле пустым, помечает для человека или запрашивает уточнение.
- План работ: этапы от разбора шаблонов до сдачи, с точками, где вы видите промежуточный результат.
- Оценка сроков: от чего зависит длительность — число типов форм, качество справочников, сложность внешних порталов.
- Границы пилотного запуска: один тип формы или одно подразделение, чтобы проверить точность на реальных данных до масштабирования.
- Критерии приёмки: доля полей, заполняемых без правок, и порядок учёта ошибок.
По итогам встречи вы получаете короткий документ: перечень входных данных, план работ по этапам, оценку сроков и согласованные границы пилота. Опишите задачу — вернёмся с оценкой и планом.
