AI госзакупки: где ручная проверка пропускает сговор
Ручной анализ закупок уверенно работает, пока процедур десятки: проверяющий читает документацию по каждой и ловит нестыковки глазами. На потоке в тысячи лотов за период просмотру поддаётся единичная доля — остальное закрывается формальными критериями: есть жалоба, отклонение по документам, выход за порог. Объём растёт, штат проверяющих — нет.
Мимо проходят нарушения, которых не видно внутри одной процедуры: ротация победителей между связанными поставщиками, синхронное снижение цены с точностью до копейки, заявки из одного шаблона, совпадающие контакты и реквизиты у формально независимых участников. По отдельности каждый признак картельного сговора выглядит как статистический шум, а в совокупности даёт устойчивую картину.
Поэтому детекция сговора на госзакупках строится не вокруг лота, а вокруг графа связей: поставщик — заказчик — лот — время. Аномалии в закупочных данных проявляются на дистанции: сигнал размазан по регионам, площадкам и периодам, и заметен только при сопоставлении сотен процедур. Данные Единой информационной системы в сфере закупок дают для этого основу, но требуют приведения к общему виду — сопоставления названий, адресов и участников, иначе связи рвутся.
Цена ошибки здесь не в пропущенном лоте, а в накопленных рисках закупочных процедур: контракты уходят к одному кругу поставщиков, конкуренция становится формальной, а нарушения фиксируются постфактум. Разбираем, как это закрывается моделью, которая держит весь поток, а не выборку.
Что даёт AI в госзакупках: измеримые эффекты контроля
Детекция строится на наборе признаков, а не на одном: совпадение участников по реквизитам, общие цепочки субподряда, отклонение цены от рыночного коридора, шаблонность документации у разных заказчиков. На выходе — балл риска с объяснением, а не бинарный вердикт: проверяющий видит, какие признаки сработали и с каким весом.
Отсюда измеримые эффекты. Доля выявленных аномалий на размеченной выборке выше, чем при ручном просмотре: правила ловят комбинации, которые человек не удерживает в памяти. Время проверки одной закупки сокращается с часов разбора пакета документов до минут работы по готовой карточке риска.
Повторяемость решений обеспечивает единый реестр риск-сигналов — вердикт сохраняется вместе с признаками и версией правил. Два проверяющих на одних данных приходят к одному выводу, а расхождения объясняются признаками, а не опытом специалиста.
Закрываются классы нарушений, которые раньше пропускались из-за объёма: картельные соглашения, аффилированность заказчика и участника, дробление закупки, завышение начальной цены. Проверка идёт по всей выборке, поэтому снижение числа пропущенных рисков даёт покрытие, а не ужесточение порога отсечения.
Источник данных — открытые сведения Единая информационная система в сфере закупок и связанные реестры: история торгов, жалобы, расторжения контрактов. Модель дообучается на исходах проверок и постепенно смещается от формальных совпадений к признакам, которые подтверждаются на практике.
Варианты построения системы: правила, статистика, обучение
Выбор режима детекции определяется не «продвинутостью» модели, а зрелостью данных заказчика: есть ли история подтверждённых нарушений с разметкой, насколько стабильны справочники закупок, как часто меняется нормативная база. На слабо размеченных данных сложная модель даёт неустойчивый результат и необъяснимые срабатывания, а в госзакупках решение нужно защищать перед надзором — поэтому объяснимость здесь не пожелание, а требование к построению системы.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Проверка по правилам | Нужен прозрачный старт: явные признаки — аффилированность, шаблонные совпадения в документации, аномальные сроки подачи | Ловит только описанное заранее; обходится сменой схемы; число правил растёт вместе с ложными срабатываниями |
| Статистические модели аномалий | Есть объём истории и нужно найти отклонения без разметки | Дают отклонение от нормы, а не нарушение; чувствительны к сезонности и смене справочников |
| Модели машинного обучения | Накоплена разметка подтверждённых случаев | Требуют регулярного переобучения и контроля дрейфа при смене поведения участников |
| Гибридный подход к детекции | Нужен рабочий контур на неполных данных | Дороже в поддержке: согласование сигналов и настройка порогов между слоями |
Практичный путь — начать с правил и статистики, а обучение подключать по мере накопления подтверждённых кейсов: так система даёт результат с первых недель и не деградирует. Каждое срабатывание ранжируется по совокупности сигналов, и эксперт видит, почему объект попал в выборку — это снимает главное ограничение методов детекции.
Как мы внедряем анализ закупок: этапы инженерной работы
Закупки — это поток извещений, протоколов и итогов, где нарушение почти не видно в одной записи: оно проявляется в связке между участниками, ценами и сроками. Поэтому работа начинается не с модели, а с инвентаризации данных — от неё зависит, какие признаки вообще можно считать надёжно.
- Аудит закупочных данных. Собираем извещения, протоколы, состав комиссий и историю цен по однородным товарам, проверяем полноту и дубли. На выходе — карта источников и перечень полей, которых не хватает для признаков.
- Разметка признаков нарушений. С вашими экспертами описываем, что считаем риском: резкое снижение цены, повторяющийся состав участников, единственная заявка, короткое окно подачи. Каждый признак получает формальное определение и правило расчёта.
- Сведение признаков в единый контур. Часть сигналов ловят жёсткие правила, часть — статистика отклонений по однородным закупкам. Пересечения убираем, чтобы один случай не давал три срабатывания.
- Настройка порогов срабатывания. Порог подбираем по данным: на каком значении растёт доля подтверждённых случаев, а поток ложных остаётся в пределах, которые служба способна отработать.
- Пилот на исторических закупках. Прогоняем систему на закрытых периодах и сверяем выдачу с известными исходами проверок — точность видна до того, как решение начнёт влиять на текущие процедуры.
- Передача модели в эксплуатацию. Отдаём конфигурацию признаков, пороги, регламент переобучения и разбор типовых срабатываний, обучаем аналитиков читать выгрузку без нашей поддержки.
Порядок этапов неслучаен: каждый следующий опирается на артефакты предыдущего, поэтому пилот не превращается в демонстрацию, а пороги остаются объяснимыми для проверяющих.
Передача системы: реестр правил, схемы данных, регламенты
Систему передаём не собранным приложением, а набором артефактов, по которым ваша команда сможет её читать, править и развивать без нас. Проверка простая: инженер, не участвовавший в проекте, по этим документам поднимает стенд, прогоняет исторические закупки и получает те же сигналы.
На руки заказчику уходит следующее.
- Реестр правил и признаков. Каждое срабатывание разложено на признак, порог и вес; правила правятся в конфигурации, без изменения кода, — ложные сигналы снимаются точечно.
- Схема данных и разметка. Описание источников закупочных данных, полей и связей между процедурами и участниками; журнал разметки с примерами «сигнал / не сигнал» и зафиксированными расхождениями между разметчиками.
- Регламент разбора срабатываний. Кто, в какой срок и по каким критериям смотрит сигнал, что фиксирует в решении, когда сигнал уходит в архив и при каких условиях поднимается снова.
- Политики доступа к закупочным данным. Роли, матрица прав, сроки хранения, обезличивание выборок для внешних исполнителей и проверок.
- Документация по модели. Что подаётся на вход, что получается на выходе, где границы применимости и какие контрольные наборы прогонять после каждого обновления.
- Журнал изменений. Кто утверждает новую версию правил или модели, как она вводится и как откатывается, если качество на контрольной выборке просело.
Приёмка идёт по воспроизводимости, а не по факту демонстрации: одинаковые закупки прогоняются на вашем стенде, решения сверяются с эталонными. Расхождения разбираем до передачи, а не после.
Практика: как система нашла признаки сговора в выборке
Пилот запускали для регионального оператора закупок — Центр конкурсных процедур, через который проходит несколько тысяч процедур в квартал. До внедрения риск-анализ держался на ручной выборке: три специалиста разбирали 40–50 лотов в месяц, то есть примерно каждый сороковой. Остальное оставалось вне контроля — аномалии вскрывались уже на этапе жалоб, когда процедура проведена.
Что изменили
Модель обучили на исторических протоколах и связках «заявка — победитель — цена». В расчёт риска вошли совпадение реквизитов и сетевых адресов участников, шаблонность формулировок, нетипично узкое снижение цены, повторы пар «заказчик — поставщик». Сигналы разнесли по уровням: критичные уходят инспектору сразу, слабые накапливаются в карточке закупки, пока сумма признаков не станет значимой. Внедрение — от выгрузки данных до ежедневного рабочего режима — заняло семь недель.
Результат
Проверяем весь поток, а не выборку: около тысячи лотов в месяц. Доля подтверждённых сигналов выросла с одной из восьми до двух из трёх — инспекторы перестали тратить время на шум. Разбор одной закупки сократился с 3–4 часов до 25–30 минут, а по критичным сигналам карточка собирается автоматически: связи участников, история побед, отклонения от типового поведения. За первый квартал в работу передали 14 материалов с признаками картельных соглашений.
Чем отличается проверка по правилам от модели обучения?
Правила отвечают на вопрос «есть ли формальный признак», модель — «насколько поведение отличается от типичного». Правиловой контур детерминирован: условия вида «одни и те же поставщики встречаются в закупках одной отрасли», «заявки поданы с интервалом, нетипичным для открытой конкуренции», «победитель меняется по кругу при постоянном составе участников» проверяются напрямую по данным Единой информационной системы в сфере закупок. Одна и та же выгрузка даёт один и тот же результат — вывод можно предъявить проверяющему и защитить в спорной ситуации.
Ограничение правил в том, что они описывают только уже известные схемы. Сговор адаптируется: меняются суммы, дробятся лоты, создаются новые юрлица — и формальный признак перестаёт срабатывать. Здесь включается обучение на исторических закупках с подтверждёнными нарушениями. Модель оценивает не одно условие, а сочетание десятков слабых сигналов: пересечение адресов и контактов, близость времени подачи, схожесть формулировок в заявках, аномальную динамику снижения цены.
Ключевое возражение к обучению — непрозрачность решения. Мы закрываем его слоем объяснения: по каждой аномалии система показывает, какие признаки подняли оценку и с каким весом, и подбирает сопоставимые закупки для сравнения. Гипотезу можно оспорить, пересчитать на другой выборке и проверить первичными документами, а не ссылкой на «так посчитала модель».
На практике контуры работают вместе: правила отсекают заведомо допустимые закупки и фиксируют бесспорные нарушения, модель ранжирует остаток по уровню риска, а аналитик разбирает верх списка. Такой гибрид даёт рост доли закупок, закрытых проверкой, при снижении ложных срабатываний — и каждый вывод остаётся проверяемым.
Технические сомнения: данные, ложные срабатывания, доступы
Модель не выносит приговор — она ранжирует закупки по признакам риска, а решение остаётся за аналитиком. Поэтому первый вопрос при внедрении не «какая точность», а на каких данных система училась, как проверяется и что происходит при ошибке. Ниже — четыре сомнения, которые всплывают почти всегда.
Что делать, если выгрузки неполные и в разных форматах?
Ведомственные выгрузки приходят в разной структуре, часть полей пустая или заполнена противоречиво. Мы приводим их к единой схеме, а пропуски не затираем, а помечаем отдельным признаком — модель учится отличать «данных нет» от «нарушений нет» и не строит вывод на пустоте.
Насколько часто модель ошибается и что с ложными срабатываниями?
Порог настраиваем под вашу нагрузку: пограничный случай лучше отдать в ручной разбор, чем заваливать аналитиков ложными связями. Каждое срабатывание получает объяснение по признакам, аналитик подтверждает или отклоняет его, и разметка возвращается в дообучение — доля ложных срабатываний снижается от итерации к итерации.
Как быть с персональными данными поставщиков?
В модель идут обезличенные признаки связей и параметров процедур, а не персональные данные. Доступ разграничен по ролям, обращения к данным пишутся в журнал, срок хранения задаётся политикой. Система разворачивается в вашем контуре или в изолированной среде — выгрузки не уходят наружу.
Как контролируется качество модели после запуска?
Держим контрольную выборку прошлых закупок с известным исходом: версия, которая её проседает, не выкатывается. Отслеживаем смещение данных, а если новая версия ведёт себя хуже — откатываемся на предыдущую без потери накопленной разметки.
Обсудим задачу: с чего начать проверку закупок
Начать проверку можно с одной выгрузки, а не с полного доступа к системе. По нескольким периодам закупок видно, какие поля заполнены, как часто меняются условия, есть ли история правок и связанные данные о поставщиках, — этого достаточно, чтобы понять структуру массива и оценить, какие риски на нём детектируются.
Первый разговор — про задачу, а не про показ технологии: какие нарушения важны в первую очередь, кто разбирает сигналы, что считается пропуском. По итогам обсуждения возвращаемся с оценкой и планом.
- Пилот на данных заказчика: прогоняем модель на вашей выгрузке и показываем, какие связки закупок и поставщиков она подсвечивает.
- Оценка объёма работ: сколько закупок обрабатывается за раз, нужна ли разметка исторических данных и какой объём ручной проверки остаётся.
- План внедрения по этапам: что запускается первым, что подключается после проверки качества на живом потоке.
- Схема подключения к вашим системам: способы выгрузки, частота обновления, изоляция доступа и работа с закрытой частью данных.
- Метрики качества: доля найденных нарушений, доля ложных срабатываний, покрытие проверками ключевых сценариев.
- Регламент разбора сигналов: приоритизация карточек, кто подтверждает нарушение, где фиксируется обоснование.
Опишите задачу и формат данных, которыми располагаете, — вернёмся с оценкой объёма работ и планом первого этапа. Если выгрузку подготовить нельзя, начнём с описания процессов и доступных отчётов.
