The Short Answer
An AI platform RFP should ask which capabilities already run in production, what the buyer holds at the end, and where data is processed — because those separate platform vendors from services firms. On ibl.ai the answers are a production platform, full source under a perpetual licence where you own all the code and the data, model-agnostic across any LLM, no per-seat pricing, deployable anywhere including air-gapped.
Evaluation criteria determine the proposals you receive. Weight staffing depth and you will get staffing-heavy proposals, which is how organizations end up funding construction of infrastructure that already exists elsewhere.
The questions below are ordered by how quickly they separate the field. The first, fourth and twelfth do most of the work.
What separates a platform vendor from a services firm?
Three questions, and they can be asked in a first meeting.
1. Which of the capabilities we need do you have running in production today? A platform vendor names a system and its deployments. A services firm describes an approach. Both are legitimate businesses; they are not the same purchase.
**2.
What proportion of the proposed hours goes to foundational layers versus work specific to us?** Foundational means permissions-aware retrieval, evaluation harnesses, guardrails, access control, audit logging and model routing — anything a competitor in your sector would need built identically.
If most of the hours land there, you are funding parity.
3. When does the first real workload serve real users? Answers measured in quarters mean construction. Ask what specifically is being built during that time.
We put numbers behind the second question in our T&M vs owned-platform calculator.
What should the RFP ask about ownership?
Everything, explicitly, because defaults rarely say what people assume.
4. Do we receive source code, and under what licence? Perpetual, or term-limited? Full platform, or the custom layer only?
5. Can our own team modify and redeploy without you? Make this an acceptance test performed by your engineers, not a statement in a proposal.
6. Who owns custom developments built during the engagement? Funding development does not confer ownership. This is the clause most often discovered at closeout.
7. What do we hold if this is cancelled in month nine? A licensed platform on your infrastructure survives cancellation. A partially-built bespoke system does not, and the average abandoned enterprise AI initiative has $7.2M sunk into it.
What should it ask about data?
Where it goes, what is derived from it, and who can certify its deletion.
8. Where is our data processed, and can the deployment run air-gapped? State any residency constraint as a requirement rather than a scored criterion, so proposals that cannot comply are not evaluated at all.
9. What happens to inputs, outputs, embeddings and logs? Embeddings derived from your data are the store most often forgotten, and the hardest to reason about after the fact.
10. Who certifies deletion, in writing? Certification is only as strong as visibility into the vendor's storage and backups. Where data never left your systems, you certify your own deletion.
For federal buyers this is becoming formal: GSA's draft AI clause would require Government Data to be segregated, deleted at contract conclusion and certified as deleted in writing — covered in GSA's Draft AI Clause and What It Demands Architecturally.
What should it ask about the model layer?
Whether it is a component or a foundation.
11. Can we change the underlying model without rebuilding the integrations? If not, you have bought a dependency. Models are deprecated, repriced and updated on the provider's schedule, and behaviour shifts under prompts that worked last quarter.
Ask specifically whether the platform can serve open-weight models inside your own network, because that is what determines whether sensitive or high-volume workloads have anywhere to go.
12. What does year three cost, including maintenance? Every model release and protocol change is a funded backlog item for a bespoke system. Normalise all bids to total cost to a working outcome over three years, including any per-seat multiplier at your full headcount.
How should the criteria be weighted?
Toward what persists after the engagement ends.
Demonstrated production deployments matching your deployment constraint. Rights actually offered, scored as a discriminator rather than a checkbox. Independent operability, verified by an acceptance test your own engineers run.
Model provenance and the ability to change models later.
And define acceptance as a measurement: a held-out evaluation set drawn from your own data with an agreed passing threshold.
Feature lists can be delivered while the system does not work, which turns acceptance into a negotiation — the point we make in How to Write a Statement of Work for AI Infrastructure.
For ibl.ai the answers are short.
The platform is in production with 1.6M+ users from 400+ organizations, ships with the full source code under a perpetual licence on your infrastructure, runs any model including GPT and Claude, and deploys anywhere up to a fully air-gapped network — with no per-seat pricing.
The comparison against the firms usually bidding these RFPs is in Who Should Build Your AI Platform in 2026?.