AI on your terms
Bid documents, prices and CVs are sensitive. BidderOps lets you choose where its AI runs: on your own OpenAI, Anthropic, Google or OpenRouter keys, or on a model running on hardware you control.
Bring your own keys
Use your organization’s own OpenAI, Anthropic, Google or OpenRouter account, under the terms you already have with that provider.
Or run models yourself
Point BidderOps at any OpenAI-compatible server, such as Ollama, LM Studio, vLLM or llama.cpp, and no AI vendor sees your prompts.
A model per feature
Keep sensitive work like CV extraction on a local model while research uses a cloud model that can search the web.
Where AI helps in BidderOps
Each of these features can use a different model, with its own editable instructions:
- Go/No-Go Advisor: recommends whether to pursue an opportunity.
- RFx Analyzer: extracts scope, evaluation criteria, milestones, dates and required documents from tender text.
- Discovery Boost: re-ranks sourced tenders against your bid profile.
- Portfolio Insights: summarizes win and loss patterns across your portfolio.
- Bid Intelligence and Deep Dive: research a single opportunity into a dossier on the project, people, competitors and partners.
- Pipeline Report: writes an executive briefing on the active pipeline.
- Experience Import: extracts references and CVs from documents.
The pipeline itself, discovery match scores and win probabilities are calculated without AI, so BidderOps is useful even before you configure a model.
How local models work
Run a server that exposes an OpenAI-compatible /v1 endpoint, paste its base URL (and an optional token) into Settings, refresh the model list, and assign a model to any feature. BidderOps then sends each request as a standard chat completion to that endpoint and nowhere else. There is no hidden fallback to a cloud provider.
BidderOps runs in the cloud, so your server has to be reachable from it: typically through a controlled tunnel into a private network. The documentation covers the options.
What stays where
Being precise about data flow matters more than a slogan:
- AI prompts go only to the provider or server you configure for that feature. With a local model, no AI vendor sees them.
- Your bid data (opportunities, documents, references and CVs) is stored in BidderOps, isolated to your organization at the database level, like any cloud application.
- Organizational memory, where enabled, uses an embedding model on the platform’s infrastructure rather than your server.
- Web research is not possible on local models, so bid intelligence reports they produce are marked as ungrounded. Point that feature at a cloud provider if you need current, cited facts.
BidderOps never uses your data to train AI models, as the Terms of Service and Privacy Policy set out.
Keys handled like secrets
Provider keys and local-server tokens are encrypted at rest with AES-256-GCM, using a key that is never stored in the database. They are used only on the server, never sent to the browser, shown only as masked placeholders, and can be set or replaced only by owners and admins.
Nothing hidden in the prompts
The documentation publishes the actual prompt templates and the data each feature sends, so your security team can review exactly what leaves BidderOps before you switch a feature on. Features like the go/no-go advisor and experience import are covered feature by feature.
Frequently asked questions
Which local model servers work with BidderOps?
Any server with an OpenAI-compatible /v1 endpoint, including Ollama, LM Studio, vLLM and llama.cpp.
Does BidderOps train AI models on our data?
No. The Terms of Service and Privacy Policy commit BidderOps to never using customer data to train or fine-tune AI models.
Can we mix cloud and local models?
Yes. Each AI feature is assigned its own model, so you can keep sensitive features on a local model and use a cloud model where web search matters.
What happens if our local server is unavailable?
The request fails rather than falling back to another provider. BidderOps only ever sends a feature’s requests to the endpoint configured for it.
Who can manage provider keys?
Only owners and admins can set, replace or remove provider keys and local-server credentials. Keys are write-only in Settings, so once saved they are never displayed again.