Procure evidence, not private-AI promises.
Use these 25 questions to define the workload, verify every data path, test human oversight, rehearse operations and compare the complete cost and exit route before signing.
Reviewed 23 August 2026
This is a reusable buyer checklist and a map to our public evidence. It is not legal advice, an audit opinion, a certification or a promise that one control fits every deployment.
What should private-AI procurement verify?
Verify the exact released product, the complete data and identity routes, quality on the buyer's real workload, meaningful human review, secure and recoverable operations, full lifecycle cost, contractual support and a workable exit. A local model answers only the hosting question.
Ask for an answer and its evidence
A confident statement is not evidence. Record the vendor answer, the artifact that proves it, who verified it, open exceptions and the date it must be reviewed again.
Workload and decision boundary
- Which exact task, users and business process are in scope?
- Which inputs, outputs, actions and uses are prohibited?
- What harm can a wrong, missing, biased or delayed output cause?
- Which accountable person reviews the output, using what procedure?
- What measurable result supports a go, change or stop decision?
Evidence: Approved use-case statement, data classification, risk owner, review procedure and acceptance thresholds.
Product, model and data routes
- Is the named product publicly released, and where is the verified acquisition path?
- Which model, version, licence and update source will run the workload?
- Where do prompts, documents, outputs, history, logs and backups travel and persist?
- Which vendor, customer and optional-provider services receive content or metadata?
- Can every external route be disabled and verified in the target environment?
Evidence: Release record, bill of materials, data-flow diagram, provider list, configuration export and observed network test.
Quality and human oversight
- What representative, edge, adversarial and misuse examples are tested?
- How are factual support, severe errors, refusals and unsupported answers measured?
- Can the reviewer inspect the source, citation or original input behind an answer?
- Does the reviewer have time, competence, authority and a non-AI fallback?
- Which model or prompt change triggers regression testing and renewed approval?
Evidence: Versioned test set, baseline, error analysis, reviewer records, escalation path and change-control criteria.
Security, operations and recovery
- How are users, administrators, API keys, scopes, quotas and revocation controlled?
- Who owns TLS, network exposure, storage encryption, secrets and hardening?
- Which content or metadata enters logs, telemetry, monitoring and support channels?
- How are backup, restore, rollback, offline updates and disaster recovery tested?
- What alert, incident, vulnerability and end-of-support processes apply?
Evidence: Architecture and responsibility matrix, access test, audit sample, runbooks, recovery result and support policy.
Commercial terms and exit
- Which users, devices, nodes, environments and commercial uses require a licence?
- What infrastructure, model, monitoring, backup, support, tax and people costs are excluded?
- What support hours, response targets, maintenance and upgrade rights are contracted?
- What can be exported, migrated, uninstalled or retained when the contract ends?
- Which renewal, price-change, termination, data-deletion and transition terms apply?
Evidence: Itemised quote, licence and support terms, assumptions, ownership map, export test and documented exit plan.
Requirements that can be tested
Adapt these clauses to the workload and your organisation's policy. Replace vague adjectives with an artifact, test or acceptance threshold.
The supplier shall identify the exact proposed product and version, lifecycle status, supported platforms and a verifiable acquisition path. Roadmap components shall be labelled separately and excluded from current capability scoring.
The supplier shall document every content and metadata route for local, customer-hosted, supplier-operated and optional third-party services, including storage, retention and disablement.
The proposed system shall be evaluated on a buyer-approved, representative test set with recorded versions, thresholds, severe-error analysis and a repeatable regression method.
The buyer shall define decisions that the system may support but not make. The operating procedure shall name accountable reviewers, escalation, override and non-AI fallback.
The response shall assign ownership for identity, API keys, TLS, network controls, models, secrets, monitoring, audit, retention, backup, recovery, incidents and updates.
The quote shall state all assumptions and exclusions. The contract shall state support scope, renewal and termination terms, exportable assets, deletion responsibilities and transition assistance.
Pause the purchase when evidence is missing
Roadmap sold as release
A screenshot, SKU, source repository or reserved store name is presented as an available product without a verified acquisition path.
“Private” without a data flow
The proposal says local or on-premises but does not identify licensing, telemetry, identity, update, support or optional-provider connections.
Demonstration treated as validation
Only selected prompts are shown; there is no representative test set, severe-error analysis, version record or regression threshold.
“Human in the loop” without authority
No reviewer is named, review time is not funded, source evidence is unavailable, or the person cannot override and stop the process.
One control generalised everywhere
A feature from one product or deployment is assumed across every app, server, model or organisation service without product-specific evidence.
Incomplete price presented as TCO
The estimate omits hardware or cloud infrastructure, model licences, people, monitoring, backup, support, tax, migration or exit work.
Four gates from candidate to controlled use
The sequence matters more than the calendar. Do not enter the next stage until its owner accepts the evidence and exceptions.
Scope accepted
Business and risk owners approve the workload, data, prohibited uses, accountable reviewer and measurable thresholds.
Technical evidence accepted
Product, data path, access, quality and infrastructure tests pass on the intended version and configuration.
Operations rehearsed
The team completes access revocation, alert handling, backup, restore, rollback, failure, incident and support exercises.
Purchase decision recorded
The approver records accepted limits, open gaps, owners, total cost, contract terms, rollback trigger and next review date.
Verify public facts before contacting sales
These pages separate public releases, implemented controls, customer configuration and known limitations. Private review can then focus on the exact deployment and unanswered questions.
The 14 current products, lifecycle status, platforms and verified acquisition channels. Private AI use cases
Workload, data-boundary, human-review and pilot guidance. Trust Centre
Current data paths, control scope, limitations, responsibilities and reporting guidance. AI Server operations guide
Metrics, usage, API-key practice, trusted proxies and hardening boundaries. Deployment planner
A reviewable topology and indicative cost model with assumptions and exclusions. Licensing and pricing
Free, Personal, Commercial and Enterprise paths, stores and entitlement boundaries.
Direct answers for an evaluation team
Should we start with an RFI, RFP or pilot?
Start with a short information request when the workload or market is unclear. Use an RFP when requirements and scoring are stable. Keep a workload pilot as an evidence gate before production commitment.
Is on-premises deployment enough to approve the system?
No. It can address a hosting or data-transfer requirement, but accuracy, permissions, model licence, access, monitoring, recovery, human oversight and legal suitability still need evidence.
Does a vendor certification make our use compliant?
No. A certification or assurance report has a defined entity, system, period and scope. Review that scope and then assess your workload, configuration and operating obligations separately.
How should proposals be scored?
Set mandatory gates first, then weight workload quality, boundary fit, operational evidence, usability, cost and contract terms. Do not let a high feature score offset a failed safety or data requirement.
Should the contract name a model?
Record the evaluated model and version, but also define the controlled process for replacements and updates. Freezing one model indefinitely can create a different maintenance and security risk.
Will Software Tailor answer our questionnaire?
Yes, for a defined product and deployment. Send the workload, architecture, deadline and requested evidence. We will distinguish public facts, customer-controlled configuration and items that need private review.
Turn one workload into a reviewable buying pack
Bring the use case, data classification, users, target boundary and acceptance thresholds. We can map public evidence, deployment assumptions and open questions without presenting roadmap work as released.