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