Questo documento è fornito in inglese; fa fede la versione inglese.
How ScoutTide uses AI
These features use a large language model provided by the AI services listed on the sub-processors page. Two rules hold everywhere it is used: AI output is always labelled, and tender data itself is never generated. Titles, deadlines, buyers and values come verbatim from the official source.
1. Matching: the relevance judge
For each organisation, the model reads the new tenders and forum posts closest to your products: a tender reaches it when it reads like one of your products and also carries one of its phrases, falls in one of its categories or comes from one of its countries, or when it is among the very closest to a product. Each plan has a daily number of these AI reviews, closest first; a row past it is listed as Not AI-checked until a later day’s reviews reach it. The model reads each one against your product profile and answers with a 0–100 score, a few topic tags, the poster's intent (on discussions) and a one-line reason. That is what the AI score chips on the queue are. The reason is always shown, on the chip's tooltip and on the tender page, because a score with no why is a black box.
When the model judges a keyword match to be different work, the tender is not deleted: it moves to AI filtered, with the model's reason, and Put back restores it permanently. A human's overrule always outranks the model, and an overruled row is never re-judged.
2. Translation
Foreign-language notices arrive with an English title, and on the tender page an English body and a short bullet summary. Every translated title carries a from [language] chip; the translated body is labelled as a machine translation; and the original text is always one click away. The summary is labelled as an AI summary where it appears.
3. Building your profile from your website
When you paste your company's web address, the model reads the site's text and proposes products: name, summary and the keywords a buyer would use. Every proposal must quote a verbatim excerpt of your own site that names it (a claim the site never made is dropped, not shown), and nothing is saved until you approve it on the review screen. Figures the model could not find on your site are removed rather than guessed at.
4. Reading tender documents
On tenders you engage with, the model reads the buyer's own documents and lists the stated requirements, each with a verbatim quote from the document, so you can check the claim against its source in place.
5. Turning your products into searches
To find public discussions about what you sell, the model is asked once per product category for the names, synonyms and acronyms people use for it. Those terms become the web and forum searches on your Feeds page, where you can see, switch off or delete each one. The answer is shared by every organisation in the same category and is reviewed by our team.
6. Expanding your keywords into other languages
Tenders are published in many languages, so the model translates your product keywords into the main languages of the sources, so a French or Polish tender for what you sell is found too. The added terms are used only for finding candidates; the model's relevance judgement above still decides what reaches your queue.
What is not AI
Deadlines, buyers, values and links are the official source's own data. The viability flag comes from fixed rules, not a model. Contract-award history is the public record. Outcome and win-rate numbers are arithmetic over what your team recorded. The queue's “learning” from Not-a-lead is pattern counting on titles. It is deterministic, inspectable and reversible, not a model.
What the model sees
Model calls carry the notice's public text and, for matching, your organisation's product profile. Documents are read only for tenders your team engages with. Which companies run the models, and where, is listed in the privacy policy and on the sub-processors page. Model output can be wrong; you are responsible for reviewing anything before you rely on it or send it.