AI Use Disclosure

Bidwhistle OÜ · Registry code 17567745 · Sepapaja tn 6, 15551 Tallinn, Estonia
Version 1.0 · Effective 27 September 2026

1. Why we publish this

Most companies that put AI into a product tell you almost nothing about it. We would rather you knew: which parts of Bidwhistle use AI, which models sit behind them, what those models see, where they go wrong, and what we do about it. This document is our responsible-AI statement and our transparency notice under Article 50 of the EU AI Act. It is written to be read, not to impress — where something is not yet built, we say so rather than claim it.

2. Where AI is used in Bidwhistle

There are two AI surfaces in Bidwhistle — Olivia, who you talk to, and the Response Workspace, where you write a bid — plus the search and scoring that runs behind them.

We do not use AI to decide anything about you: not your eligibility, not your account, not your access. Section 5(e) explains that commitment.

3. Talking to Olivia

3.1 Olivia is an AI, and we say so. Olivia is a software system, not a person and not an employee. Our website presents her as an AI adviser wherever she appears, and our Terms of Service and Privacy Notice, which you accept at sign-up, say so too. She never claims to be a person. You do not have to work it out from how she sounds.

3.2 The voice and the face are generated. Olivia’s voice is synthesised by a text-to-speech model and her on-screen avatar is rendered by an avatar model, both provided by Anam. Neither is a recording of a real person, and neither is a clone of one. We do not clone any identifiable person’s voice, and we do not create or store voice embeddings, voiceprints or other derived voice data.

3.3 What happens to what you say. A spoken conversation goes through these steps:

If you type instead of speaking, step 2 does not happen; the rest is the same. Each provider receives only what it needs for its own step. Where Olivia has to look something up in our knowledge base, the question you asked also goes to Voyage AI to be turned into a vector, without any account identity attached to it (section 2).

3.4 Where the conversation is processed, and what is kept. This is the part of our stack we are least happy with, so here it is plainly.

Where your conversation with Olivia is processed is determined by our provider and may be the United States. The session recording — your audio and the avatar video — and the transcript are kept by that provider for no more than 30 days: the provider deletes recordings within 30 days, and once a session is 30 days old we delete it at the provider, which removes the transcript and anything left of the recording. They are not used to train models.

Anam does sell an EU-only region and a zero-data-retention option. Neither is available on the plan we currently hold: they are account entitlements, not settings we have failed to switch on. We tested both directly against the provider on 9 August 2026 and both were refused. We are working to move to a plan that lets us pin the processing region to the EU and switch retention off, and we will update this document when we do.

3.5 So yes, the session is recorded. Our website presents Olivia as an AI adviser wherever she appears, and the Terms of Service and Privacy Notice you accept at sign-up explain that her conversations are recorded by our provider and kept for up to 30 days. She never claims to be a person. If other people can be heard where you are, tell them too.

3.6 What we keep, as opposed to what our provider keeps. Our own systems record only that a session took place and how long it lasted, not what was said. You can show a live transcript on screen during the conversation; we do not keep a copy of it. We create no voice embeddings at all. Our Privacy Notice holds the retention table, and our sub-processors list (available on request at privacy@bidwhistle.com) records what each AI provider retains.

3.7 Olivia cannot do everything. She answers questions about tenders and about how to use the product. She cannot submit a bid for you, change your billing, or give you advice (section 7). If you would rather deal with a person, section 5(d) tells you how.

4. The Response Workspace

4.1 What it is. The Response Workspace is the part of Bidwhistle where you actually write a bid. You upload a tender pack and can then have it read and summarised, have answers drafted against the questions in it, have a requirement explained in ordinary language, and have a draft bid reviewed before you submit it.

4.2 Which model, and what it sees. The workspace runs on Anthropic. The model receives the document you upload, the bid text you write, and your company name. It does not receive your login details, your payment details or the rest of your account.

4.3 We do not keep the pack you upload. The document is passed through to the model and discarded. All we write down is a usage row — how much was processed and a reference to the request — with none of the content in it. The bid text you write is a different matter: that is saved in your account, because a workspace that forgot your bid would be useless. Our platform also keeps a short-lived request log that can briefly include small request and response bodies; our Data Retention Policy explains it and how long it lasts (ask at privacy@bidwhistle.com for a copy).

4.4 A tender pack is full of other people’s personal data. This is the part most people do not think about, so we would rather raise it than wait for it to become a problem.

A tender pack is not just a form. It often contains information about people — most obviously a TUPE schedule, which lists the staff currently doing the work for the incumbent supplier, with their names, job titles, salaries and how long they have worked there. We found one in a sample of twenty real packs taken from a public portal.

Those people are not our customers. They have no relationship with us, and they have no idea their details are about to be uploaded to a bid-writing tool. When you upload a pack, you are disclosing their personal data — to us, and through us to our model provider — and in law you are the controller of that disclosure.

So, before you upload:

• look at what is in the pack;
• take out or black out personal data we do not need in order to help you; and
• never upload special category data — health, racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic or biometric data, sex life or sexual orientation, or criminal records.

Our Terms of Service puts this in contract terms and backs it with your indemnity.

4.5 What we do to help, and where it stops. Three things happen when you upload a pack. Before you upload, we tell you that packs for staffed contracts usually include a list of the people currently doing the work — names, pay and start dates — and that we do not need it to find the buyer’s questions, so we leave it out. After you upload, you see every file in the pack, and only the ones you leave ticked are read — anything unticked never reaches the model. And files whose names look like staff records are listed unticked already, so they stay out unless you tick them yourself.

Here is where it stops, and we would rather tell you than let you assume it covers more than it does.

It is a default, not a lock. You can overrule us, and if you tick a staff record we will read it.

It reads file names, not what is inside them. If the buyer named the file “TUPE schedule”, we spot it. If they named it “Appendix 7”, we do not — it will be sitting there ticked like everything else.

It works on whole files. A TUPE schedule is often not its own file at all; it is an appendix inside a two-hundred-page invitation to tender, and if you tick that document the appendix goes with it.

So this makes an accidental disclosure less likely. It does not make it impossible. Your own read of the pack is still what protects the people named in it.

5. Our commitments

(a) We tell you when you are dealing with AI. Our website presents Olivia as an AI adviser wherever she appears, and the Terms of Service and Privacy Notice you accept at sign-up explain that her conversations are recorded by our provider and kept for up to 30 days. She never claims to be a person. Answers drafted for you in the Response Workspace are marked as drafted by Olivia. Fit scores are worked out by fixed rules, not AI (see section 2). We do not design interfaces that blur the line, and we do not give Olivia a backstory that implies she is a person.

(b) We do not train AI models on your data — and here is exactly what that does and does not cover.

We do not use Customer Data, Inputs or Outputs to train AI models. We do not train models ourselves, and we do not sell or share your data for anyone else to train on. That much is entirely within our control and we commit to it without qualification.

Our AI providers are a different question, and we would rather be precise about it than reassuring:

We will update this document and our sub-processors list as soon as we have the answers, and tell customers when we do. We hold no direct contract with Google for this model: it is reached through Anam, under Anam's own contract, so there is nothing for us to obtain in writing from Google and we do not assert a training, retention or location position for it. That is the weakest data commitment in our chain, and we say so rather than leaving it looking like an answer still on its way.

The first paragraph of this commitment appears in the same substance in our Terms of Service, Privacy Notice and Data Processing Agreement. The per-provider detail lives here and in our sub-processors list (available on request at privacy@bidwhistle.com), so you can check rather than trust.

(c) How AI output is marked. Visible labelling is part of the interface. Article 50(2) of the EU AI Act also requires synthetic audio and AI-generated text to carry marking in a machine-readable format so it can be detected as artificially generated. Text drafted in the Response Workspace carries the invisible watermark Anthropic adds to Claude’s writing. For Olivia’s voice and video, we are confirming with our suppliers how they are marked, and we will update this page when we have their answer.

(d) A human can always be reached. Email support@bidwhistle.com and a person will read it. We answer during business hours, 09:00–17:00 UK time, Monday to Friday, to the targets in our Service Level Agreement. You never have to get past Olivia to reach us and asking her for a human is not treated as a failure of the conversation.

(e) We do not make decisions about people using AI alone. No automated system decides whether you may use the Service, whether an account is suspended, whether a refund is due, or whether a report under our Acceptable Use Policy is upheld. Automated tooling may flag something for attention; a person decides, can explain the decision, and can change their mind.

6. What AI is good at here, and what it is not

6.1 What it does well. It summarises — turning a forty-page notice into something you can triage in twenty seconds. It ranks and filters — surfacing a handful of notices worth your attention out of the hundreds published each week. It explains — saying why a tender looked like a match for the profile you gave us, or what a requirement in a pack is actually asking for. It drafts — producing a first attempt at an answer to a tender question, which you then rewrite in your own voice. It answers navigational questions — where a field is, what a term means, how to set up an alert. For all of these it is genuinely useful, and much faster than doing it all yourself.

6.2 Where it goes wrong. Language models produce fluent, confident text whether or not it is correct. In this domain the specific failure modes are:

• Dates — closing dates, question deadlines, contract start dates. A model can transpose, misread a format, or carry over a date from a related notice.
• Values — contract values, lot values, thresholds. Currency, units and ranges are all easy to garble.
• Thresholds and eligibility — turnover requirements, insurance levels, certifications, framework membership. A summary may simplify a condition that is not simple.
• Scope — what is actually being bought, and which lots you could bid for.
• Withdrawal and amendment — a notice may have been corrected, extended or withdrawn since we ingested it.

6.3 It does not know what happened recently. A model’s knowledge stops at the end of its training data. Everything current that Olivia or a summary tells you about a tender comes from what we feed the model from our own index — so if a notice has changed at source since we ingested it, the model will not know.

6.4 Output is not unique to you. Similar inputs produce similar outputs, so another customer asking a similar question may receive much the same answer, and a drafted bid answer is not an original one. We do not promise exclusivity or originality in any Output.

6.5 Fit scores are estimates, not measurements. A fit score says something about how a tender relates to a profile. It says nothing about whether you are eligible, whether you will be shortlisted, or whether you will win.

7. No professional advice

7.1 Bidwhistle does not give legal, procurement, bid-writing, tax, financial or eligibility advice, and nothing the Service or Olivia produces is such advice or a substitute for it. If a decision has real consequences, take proper advice.

7.2 Nothing in the Service is a guarantee, prediction or assurance of any bid outcome, shortlisting, award or eligibility decision. Anyone who tells you a tool can promise you a win is selling you something.

7.3 Always check the original notice before you act. Only the notice published by the contracting authority — or, for the EU, the electronically signed notice in the Supplement to the Official Journal — is authoritative. Our summaries, scores, drafts and answers are a way to find, triage and start on notices, not a replacement for reading them.

8. Human review

8.1 What we expect of you. Treat AI Features as decision support. Before you bid, decide not to bid, commit resources or send anything to a buyer, check the material facts against the original notice. Do not paste an Output into a bid without reading it — that goes double for an answer drafted in the Response Workspace. Do not rely on an Output to decide whether you meet an eligibility condition.

8.2 What we review ourselves. We sample-check AI summaries, fit scores and extracted fields against the source notices, with particular attention to dates, values and thresholds. We read every report of a bad Output and investigate it. We watch for systematic errors — a source format we are parsing wrongly, a prompt that is mis-firing, a provider change that has shifted behaviour — because those affect everyone rather than one user.

8.3 What we do not do. We do not review every Output before you see it; nobody could, and we will not imply otherwise. We do not listen to live conversations with Olivia, and no person checks what the Response Workspace drafts for you before you see it.

9. How we govern AI

We are a very small company. What follows is a proportionate process that one organisation of our size can actually run, not a description of an AI ethics board we do not have. One person is accountable for these decisions.

9.1 Choosing a model provider. Before we adopt one we look at: where it processes data; what it retains and for how long, and whether retention can be switched off; whether it would use our data to train models, and whether we can prohibit that contractually; its data protection terms and transfer mechanism; its security documentation; and its track record for stability and notice of change. We prefer providers established or hosting in the EU, and we do not always manage it: our own ingestion and scoring pipeline runs in Germany and our alert email is delivered from Ireland, but the models behind Olivia and the Response Workspace sit outside the EU or may do. Section 3.4 and commitment 5(b) say where that leaves us.

9.2 What we check before a feature goes live. We run it over a set of real notices drawn from each source we ingest, and compare the Output against the source: are the dates right, are the values right, are there invented fields, does it fail safely when a notice is malformed? We check that the AI disclosure and labelling appear where they should, and how the feature behaves when a provider is slow or unavailable.

9.3 When a model changes. Model providers deprecate versions and ship new ones, sometimes at short notice. Before we move a feature to a different model or version we repeat the checks in clause 9.2. Where a change means a new sub-processor, or a materially different role for an existing one, we notify customers as described in our sub-processors list (available on request at privacy@bidwhistle.com), which is also honest about the cases where an AI provider gives us less than 30 days’ notice of its own changes.

9.4 When something goes wrong. If we find that a feature is producing systematically wrong Output, that an AI disclosure has failed to appear, or that a provider has had a security incident affecting data we sent it, we will disable or degrade the feature rather than leave it running, tell affected customers what happened and what we are doing, fix it, and record what we learned. Where a security incident involves personal data, our Data Processing Agreement and Privacy Notice govern what we tell you and when.

9.5 Reporting a problem with an AI output. Email support@bidwhistle.com with the Output, the tender reference, and what was wrong. Tell us the deadline if one is close, and we will prioritise. We also intend to provide a report control next to AI-generated content in the product.

9.6 What we publish, and how we got it. Each provider's position here is taken from that provider's own published terms and quoted. Where a position is adverse to you - Voyage AI's terms allow training on customer content unless the customer opts out - we state it in full rather than soften it. Where a provider's terms are silent on location or retention, we say so instead of guessing.

9.7 What we will not do. We will not add an AI feature because it is fashionable, will not use AI to make decisions about people, and will not describe a control we have not built.

10. EU AI Act

This section sets out our own assessment of our position under Regulation (EU) 2024/1689 (the EU AI Act). It is not legal advice, and no authority has assessed Bidwhistle.

10.1 What we are. We are a provider of an AI system: we develop Bidwhistle’s AI Features and place them on the market under our own name. We build on general-purpose models supplied by others; we do not develop or train those models ourselves.

10.2 We are not a high-risk AI system under Annex III. Annex III lists the high-risk areas: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and the administration of justice and democratic processes. Bidwhistle helps businesses find, assess and track published public tender opportunities. It does not evaluate people, allocate access to a service or benefit, or take part in the evaluation of bids by a contracting authority. It is also not a safety component of a regulated product under Article 6(1). On that basis we consider that the high-risk obligations do not apply to us.

10.3 Article 50(1) applies to us because Olivia is an AI system intended to interact directly with people. In practice this means we make sure you know Olivia is an AI before you use her: our website presents her as an AI adviser wherever she appears, our Terms of Service and Privacy Notice, which you accept at sign-up, say so, and she never claims to be a person.

10.4 Article 50(2) applies to us because the Service generates synthetic audio (Olivia’s voice) and AI-generated text (summaries, explanations and Olivia’s replies). In practice this means those Outputs must be marked in a machine-readable format and detectable as artificially generated, using a technique that is effective, interoperable, robust and reliable as far as technically feasible. Section 5(c) sets out where we are with this.

10.5 Our customers have obligations too. A customer who exposes Olivia or her Outputs to other people acts as a deployer, and Article 50(4) may require them to disclose that content is artificially generated. Our Acceptable Use Policy sets out what we require of customers who pass Outputs on, including keeping our labelling and marking intact.

10.6 Timing. The Article 50 transparency obligations applied from 2 August 2026. Systems already on the market before that date have until 2 December 2026 for some of the marking requirements. Bidwhistle launches after 2 August 2026, so we treat those obligations as applying to us from day one and take no benefit from the transitional period.

10.7 AI literacy. Article 4 requires providers and deployers to take measures to support the development of AI literacy among the people who operate their AI systems. In a company our size that means the person who builds and supports the Service is the person who has read the model documentation, run the checks in section 9, and knows where the system fails.

10.8 We keep this under review. Our assessment could change if we add a feature, if guidance from the Commission or the AI Office says otherwise, or if a national authority takes a different view. If it changes, we will update this document and tell customers.

11. UK position

The United Kingdom has no statutory equivalent of the EU AI Act’s transparency regime at present; AI is regulated there through existing law and sector regulators rather than a single AI statute. We have not waited to be told. We apply the same standard to our UK users voluntarily: the same AI disclosure, the same labelling, the same position on model training as section 5(b) sets out, and the same human route. If the UK introduces its own requirements, we will meet them and update this document.

12. Accessibility of AI disclosures

12.1 A disclosure only works if everyone can perceive it. The information that Olivia is an AI is given in text, on our website and in our Terms of Service and Privacy Notice, so it does not depend on hearing her.

12.2 The AI-generated labels in the Service are part of the page content, exposed to screen readers rather than drawn only as an image or shown only on hover.

12.3 You can use Olivia by typing instead of speaking, and you can show a live transcript of the conversation on screen while it runs. We do not keep a copy afterwards (see 3.6).

12.4 We write these disclosures in plain English, at the point you need them, rather than in a settings page you would have to go looking for. If any AI disclosure in the Service is hard for you to perceive or understand, tell us at support@bidwhistle.com and we will fix it - that is a bug, not a preference.

13. Changes to this AI Use Disclosure

13.1 We update this document when what we do changes: a new AI feature, a new model provider, a change in what a provider retains, or a change in the law. The current version is always at AI Use Disclosure, with its version number and effective date at the top.

13.2 Where a change is significant — a new AI feature, a new AI sub-processor, or a change to any commitment in section 5 — we will tell customers by email or in the Service. Corrections and clarifications are made without notice and recorded below.

14. How to contact us

Bidwhistle OÜ · Registry code 17567745 · Sepapaja tn 6, 15551 Tallinn, Estonia · https://www.bidwhistle.com

Related documents: our Terms of Service, Privacy Notice, Acceptable Use Policy, Data Processing Agreement, sub-processors list (available on request) and Service Level Agreement.

Back to the top