Будівельна компанія з Познані вручну переглядала три портали закупівель щоранку. Дві людини витрачали разом 8-12 годин на тиждень на перевірку оголошень, читання СІВЗ та ухвалення рішення, які процедури взагалі варто аналізувати глибше. Попри це, вони пропустили три тендери, що відповідали їхньому профілю, протягом одного кварталу — кожен вартістю понад 2 млн злотих. Проблема була не в браку ресурсів, а у способі роботи: ручний пошук при 40-60 нових оголошеннях на день лише на одному порталі структурно ненадійний.
Моніторинг оголошень: як визначити тендерний профіль
Перш ніж агент почне моніторити, йому потрібен профіль відповідності. Профіль — це набір критеріїв: коди CPV, воєводства або географічний охоплення, вартість закупівлі (діапазон), замовники зі списку бажаних або виключених, ключові слова в назві та предметі закупівлі.
Профіль зберігається як документ JSON або запис у базі даних. Агент опитує API порталів (Платформа e-Zamówienia надає REST API) або парсить RSS/Atom кожні кілька годин. Кожне нове оголошення проходить через класифікатор відповідності: оцінка 0-100 на основі ваг, призначених критеріям. Оголошення нижче порогу (наприклад, нижче 60 балів) відсіюються. Вище порогу потрапляють до черги рев'ю з підсумком причин відповідності.
Ключовий принцип: класифікатор підказує, людина затверджує перехід до глибшого аналізу. Жоден автомат не подає пропозицію і не відхиляє процедуру без підтвердження.
Екстракція вимог із СІВЗ та ОПЗ
Специфікація Істотних Умов Закупівлі може налічувати 80-300 сторінок. Вона містить умови участі, критерії оцінки пропозицій, опис предмета закупівлі (ОПЗ), вимоги щодо персоналу, референцій, страхувань та термінів.
Пайплайн екстракції даних з тендерної документації працює в кілька кроків:
- Завантаження та парсинг: PDF/DOCX, завантажений з порталу, потрапляє до парсера. Для сканованих PDF потрібен OCR. Результат — чистий текст зі збереженою структурою розділів.
- Чанкінг та індексація: текст ділиться на фрагменти (500-800 токенів з оверлапом) та індексується у векторній базі. Деталі архітектури RAG — у статті про корпоративний GPT на базі знань.
- Структурована екстракція: модель LLM з structured output витягує поля: умови участі (оборот, досвід, персонал), термін подання пропозицій, критерії оцінки з вагами, формальні вимоги (завдаток, забезпечення), штрафні санкції та терміни виконання.
- Перевірка повноти: guardrails перевіряють, чи всі необхідні поля були витягнуті. Відсутні поля позначаються для ручного доповнення.
Точність екстракції для добре відформатованих СІВЗ становить 85-95%. Для сканованих або нестандартних документів вона падає до 65-80% і вимагає обов'язкового людського перегляду. Тут немає місця для сліпої довіри автоматиці.
Оцінка відповідності та ризиків
Після екстракції вимог агент порівнює їх з профілем компанії: чи виконуєте ви умови обороту, чи маєте необхідні референції, чи володієте персоналом із сертифікатами, затребуваними в ОПЗ.
Результатом є звіт про відповідність із розділами:
- Умови виконані: перелік вимог із доказами (номер референції, сертифіката).
- Умови невиконані або сумнівні: перелік недоліків із пропозицією, чи варто звертатися за роз'ясненнями до замовника.
- Контрактні ризики: штрафні санкції вище норми (наприклад, >20% вартості), стислі терміни виконання, відсутність права опції, умови розірвання.
- Питання для роз'яснення: неоднозначні фрагменти ОПЗ, які агент позначає як такі, що потребують тлумачення юристом або менеджером.
Весь звіт — це матеріал для ухвалення рішення, а не саме рішення. Останній крок завжди за людиною.
Етап тендеру, завдання ШІ та human-gate
#| Етап тендеру | Завдання ШІ | Human-gate (хто і що затверджує) |
|---|---|---|
| Моніторинг порталів | Класифікація оголошень за профілем компанії, фільтрація за порогом відповідності | Менеджер з продажу/PM: перехід до аналізу СІВЗ |
| Попередній аналіз СІВЗ | Екстракція: умови участі, критерії оцінки, терміни, штрафи | Юрист/PM: верифікація полів, позначених як неповні |
| Оцінка відповідності | Порівняння вимог з профілем компанії, перелік недоліків | Керівництво/PM: рішення про старт |
| Аналіз ризиків | Виявлення ризикових положень (штрафи, терміни, опції), скорінг ризиків | Юрист: перегляд положень з високим та критичним ризиком |
| Підготовка чеклісту | Генерація переліку документів для пропозиції з дедлайнами | Координатор пропозиції: повнота перед поданням |
| Моніторинг змін | Відстеження модифікацій СІВЗ та запитань/відповідей замовника | PM: оцінка впливу зміни на пропозицію |
Підготовка чеклісту пропозиції
Коли рішення про старт ухвалено, агент генерує чекліст документів, необхідних для подання пропозиції: формуляр пропозиції, перелік робіт/послуг, докази референцій (назви, вартості, дати), поліс ОСЦПВ, виписку з КРС/ЄДР, сертифікати персоналу, завдаток.
До кожного пункту призначено проміжний термін (за скільки днів до дедлайну його потрібно підготувати) та внутрішній власник. Список потрапляє до системи управління завданнями через інтеграцію (наприклад, n8n з Jira або Basecamp). Те саме інструмент моніторить відповіді замовника на запитання до СІВЗ та оновлює чекліст, коли замовник змінює вимоги.
Більше про автоматизацію потоків із зовнішніми системами — у статті про інтеграцію ШІ з системами ERP.
Як цей пайплайн працює з конфіденційними даними
СІВЗ та тендерна документація — це публічні дані, тут немає RODO з боку замовника. Але ваші корпоративні документи (референції, поліси, дані персоналу), що проходять через систему, вже є корпоративними та потенційно персональними даними.
Кілька принципів, яких слід дотримуватися:
- Self-hosting або договір доручення: якщо документ містить персональні дані працівників (CV для пропозиції, персональні сертифікати), обробка зовнішнім LLM вимагає договору доручення (ст. 28 RODO) або моделі self-hosted. Стаття про корпоративний GPT на базі знань пояснює, коли self-hosting економічно виправданий.
- PII masking: імена, номери PESEL, контактні дані в документах працівників мають бути замасковані перед відправкою до хмарної моделі.
- Аудитний слід: кожен згенерований аналіз СІВЗ має логуватися з датою, версією моделі та оператором, який його затвердив. Це вимога AI governance та захист у разі оскарження конкурентом.
Інструмент blueprint агента допомагає спроектувати архітектуру з належним розподілом прав доступу та логуванням.
Спробуйте: reasoning наживо
#FAQ
#Чи може ШІ самостійно подати пропозицію в тендері?
Ні. Подача пропозиції — це юридична дія з електронним підписом та юридичною відповідальністю. Системи ШІ в тендерах працюють як аналітична підтримка: моніторять, екстрагують, оцінюють та генерують чеклісти. Рішення про подання пропозиції, підписання формуляра та надсилання документів завжди належить уповноваженій фізичній особі. Human-oversight тут є непохитною вимогою.
Яка типова точність екстракції вимог із СІВЗ?
Для добре відформатованих документів PDF (нативних, не сканів) точність екстракції ключових полів становить 85-95%. Для сканованих або нестандартних документів вона падає до 65-80%. У будь-якому випадку поля, позначені як «неповні» або «низька впевненість», потребують людського перегляду перед використанням у рішенні про старт.
Скільки коштує впровадження такої системи?
Вартість впровадження пайплайну моніторингу та аналізу СІВЗ зазвичай становить 15 000-60 000 злотих нетто, залежно від кількості інтегрованих порталів, складності тендерного профілю та ступеня інтеграції з існуючими системами. Річні витрати на утримання (інференція, векторна база, моніторинг) становлять 800-3 000 злотих на місяць при обсязі 20-100 процедур. Калькулятор ROI допоможе оцінити повернення інвестицій для вашого обсягу.
Чи працює система з Платформою e-Zamówienia та TED?
#Платформа e-Zamówienia (ezamowienia.gov.pl) надає REST API з можливістю фільтрації за CPV, замовниками та датою публікації. TED (Tenders Electronic Daily) пропонує OpenData API. BZP (Бюлетень публічних закупівель) вимагає парсингу RSS або HTML-сторінок. Кожен портал має власну структуру даних, тому пайплайну потрібні окремі адаптери для кожного порталу — це стандартний елемент впровадження, а не перешкода.
Як ШІ обробляє зміни в СІВЗ після публікації оголошення?
Замовники часто модифікують СІВЗ або публікують відповіді на запитання виконавців. Агент моніторить зміни в документації конкретної процедури (опитуючи API або відстежуючи сторінку оголошення) та генерує diff: що змінилося, які поля чеклісту це стосується та чи впливає зміна на рішення про старт. PM або координатор пропозиції отримує алерт із описом зміни та рекомендацією перегляду. Рішення про оновлення пропозиції залишається за людиною. Більше шаблонів обробки змін — у статті про класифікацію та маршрутизацію звернень ШІ.