A construction company from Poznań manually reviewed three procurement portals every morning. Two employees spent a combined 8-12 hours weekly checking announcements, reading RFPs, and deciding which procedures were worth deeper analysis. Despite this, they missed three tenders matching their profile in a single quarter — each worth over PLN 2 million. The issue wasn’t resource scarcity but workflow: manual searching with 40-60 new announcements daily on a single portal is structurally unreliable.
Monitoring announcements: defining the tender profile
#Before an agent starts monitoring, it needs a fit profile. The profile is a set of criteria: CPV codes, voivodeships or geographic scope, contract value (range), preferred or excluded contracting authorities, keywords in the title and subject.
The profile is stored as a JSON document or database record. The agent queries portal APIs (Platforma e-Zamówienia provides a REST API) or parses RSS/Atom feeds every few hours. Each new announcement passes through a classifier for fit scoring: a 0-100 result based on weighted criteria. Announcements below the threshold (e.g., below 60 points) are discarded. Those above enter a review queue with a summary of fit reasons.
Key principle: the classifier suggests, the human approves progression to deeper analysis. No automation submits bids or rejects procedures without confirmation.
Extracting requirements from RFPs and ToRs
#Request for Proposal documents can span 80-300 pages. They include participation conditions, bid evaluation criteria, scope of work (ToR), personnel requirements, references, insurance, and deadlines.
The data extraction pipeline for tender documentation works in several steps:
- Download and parsing: PDF/DOCX files from the portal are fed into a parser. Scanned PDFs require OCR. The output is clean text with preserved section structure.
- Chunking and indexing: Text is split into segments (500-800 tokens with overlap) and indexed in a vector database. See the article on company GPT with knowledge base for RAG architecture details.
- Structured extraction: An LLM with structured output extracts fields: participation conditions (turnover, experience, personnel), bid submission deadline, evaluation criteria with weights, formal requirements (bid bond, security), contractual penalties, and delivery timelines.
- Completeness verification: Guardrails check if all required fields were extracted. Missing fields are flagged for manual completion.
Extraction accuracy for well-formatted RFPs is 85-95%. For scanned or non-standard documents, it drops to 65-80% and requires mandatory human review. Blind trust in automation has no place here.
Fit and risk assessment
#After extracting requirements, the agent compares them against the company profile: Can you meet turnover conditions? Do you have the required references? Do you have personnel with certifications specified in the ToR?
The result is a fit report with sections:
- Met conditions: List of requirements with evidence (reference number, certificate).
- Unmet or questionable conditions: List of gaps with suggestions on whether to seek clarifications from the contracting authority.
- Contractual risks: Penalties above norms (e.g., >20% of contract value), tight delivery timelines, lack of option rights, termination conditions.
- Clarification questions: Ambiguous ToR sections flagged for legal or commercial interpretation.
The entire report is decision material — not the decision itself. The final step always belongs to the human.
Tender stage, AI task, and human-gate
#| Tender Stage | AI Task | Human-gate (who and what approves) |
|---|---|---|
| Portal monitoring | Classify announcements against company profile, filter below fit threshold | Sales/PM: proceed to RFP analysis |
| Initial RFP analysis | Extraction: participation conditions, evaluation criteria, deadlines, penalties | Legal/PM: verify flagged incomplete fields |
| Fit assessment | Compare requirements against company profile, list gaps | Management/PM: go/no-go decision |
| Risk analysis | Detect risk clauses (penalties, timelines, options), risk scoring | Legal: review high and critical risk clauses |
| Checklist preparation | Generate list of bid documents with deadlines | Bid coordinator: completeness before submission |
| Change monitoring | Track RFP modifications and Q&A updates from the contracting authority | PM: assess impact of changes on bid |
Preparing the bid checklist
#Once the go decision is made, the agent generates a checklist of documents required for bid submission: bid form, work/service list, reference proofs (names, values, dates), liability insurance, KRS/CEIDG, personnel certificates, bid bond.
Each item is assigned a partial deadline (how many days before submission it must be ready) and an internal owner. The list is pushed to a task management system via integration (e.g., n8n with Jira or Basecamp). The same tool monitors contracting authority responses to RFP questions and updates the checklist when requirements change.
Learn more about automating workflows with external systems in the article on AI integration with ERP systems.
Handling sensitive data in this pipeline
#RFPs and tender documentation are public data — no GDPR applies on the contracting authority’s side. However, your company documents (references, insurance policies, personnel data) passing through the system are corporate and potentially personal data.
Key principles to follow:
- Self-hosting or data processing agreement: If documents contain employee personal data (CVs for bids, personal certificates), processing by an external LLM requires a data processing agreement (Art. 28 GDPR) or a self-hosted model. The article on company GPT with knowledge base explains when self-hosting is economically justified.
- PII masking: Names, PESEL numbers, contact details in employee documents should be masked before sending to a cloud model.
- Audit trail: Every generated RFP analysis should be logged with date, model version, and the operator who approved it. This is an AI governance requirement and a safeguard in case of competitor appeals.
The agent blueprint tool helps design an architecture with proper access controls and logging.
Try it: live reasoning
#FAQ
#Can AI independently submit a bid in a tender?
#No. Submitting a bid is a legal act requiring an electronic signature and legal responsibility. AI systems in tenders serve as analytical support: they monitor, extract, assess, and generate checklists. The decision to submit a bid, signing the form, and sending documents always belong to an authorized individual. Human-oversight is an uncompromisable requirement here.
What is the typical accuracy of requirement extraction from RFPs?
#For well-formatted PDFs (native, not scans), extraction accuracy for key fields is 85-95%. For scanned or non-standard documents, it drops to 65-80%. In all cases, fields marked as "incomplete" or "low confidence" require human review before use in the go/no-go decision.
How much does implementing such a system cost?
#The cost of deploying a tender monitoring and RFP analysis pipeline typically ranges from PLN 15,000 to 60,000 net, depending on the number of integrated portals, tender profile complexity, and integration depth with existing systems. Annual maintenance costs (inference, vector database, monitoring) are PLN 800-3,000 monthly for volumes of 20-100 procedures. The ROI calculator helps estimate returns for your volume.
Does the system work with Platforma e-Zamówienia and TED?
#Platforma e-Zamówienia (ezamowienia.gov.pl) provides a REST API with filtering by CPV, contracting authority, and publication date. TED (Tenders Electronic Daily) offers an OpenData API. BZP (Biuletyn Zamówień Publicznych) requires RSS or HTML page parsing. Each portal has a different data structure, so the pipeline needs separate adapters per portal — this is a standard deployment element, not an obstacle.
How does AI handle changes in RFPs after announcement publication?
#Contracting authorities often modify RFPs or publish answers to contractor questions. The agent monitors changes in the documentation for a given procedure (via API or tracking the announcement page) and generates a diff: what changed, which checklist items are affected, and whether the change impacts the go/no-go decision. The PM or bid coordinator receives an alert with the change description and a review recommendation. The decision to update the bid rests with the human. More patterns for handling changes in the article on AI ticket classification and routing.