Start with one brief every supplier can answer
This guide addresses partner selection after you have a plausible use case. It is not a ranking of Philippine vendors. The comparison method below is Kooya’s analysis; the cited sources establish risk-management context and one relevant Philippine privacy obligation. Apply the same questions to Kooya as to any other supplier.
For example, consider a hypothetical distributor that wants AI to draft a response to a delivery exception. The shared brief should identify the order system, approved policies, who may see customer details and who approves the response. A supplier proposing an internal drafting tool and one proposing autonomous customer messaging are bidding for different responsibilities. Their totals are not directly comparable.
- Write the start and end of the workflow, including the human decision that remains.
- List the actual integrations and the information the system may access.
- Describe representative English, Filipino or mixed-language inputs where relevant.
- Require suppliers to state exclusions, assumptions and work your own team must provide.
Require evidence at the level of the proposed work
NIST’s Generative AI Profile recommends acquisition due diligence that covers privacy, security, intellectual property and third-party risks. It also suggests contractual access to evaluate third-party processes. These are useful voluntary reference points, not Philippine vendor certification.[1]
Ask the proposed delivery team to walk through one comparable integration and explain its contribution. A polished case study is insufficient if it does not show which work the supplier actually performed. Where reference access is limited by confidentiality, accept a redacted architecture discussion or a controlled technical exercise; record what remains unverified.
Use three evidence labels in the comparison: demonstrated, documented but untested, and unresolved. A statement that a feature is on the roadmap belongs in the last category for today’s purchase. Do not silently score a promised feature as an available one.
Make data responsibility a selection gate
Section 14 of the Philippine Data Privacy Act allows subcontracting while keeping the personal information controller responsible for ensuring proper safeguards, preventing unauthorized use and complying with applicable processing requirements. The processor also has its own compliance duties. A supplier’s promise that it handles privacy is therefore not a substitute for the buyer’s assessment.[2]
As a procurement step, request a data-flow diagram covering application storage, model APIs, logging, analytics, backups and support access. Have your privacy and security owners assess it against the actual proposed processing before sharing operational personal data. A vendor’s headquarters address alone does not tell you where information travels.
- Identify which entities receive which data and for what purpose.
- Document retention, deletion, access controls and any proposed secondary use, including model training.
- Ask what changes if an upstream provider or hosting location changes.
- Use synthetic or appropriately prepared evaluation data while production access remains unapproved.
Compare the operating bill using the same assumptions
Kooya recommends asking each supplier to price the same normal-use and peak-use scenarios, with the same workflow boundaries. Treat them as estimates, not promises of future usage. Include implementation, integration maintenance, hosting, model usage, monitoring, human review, support and eventual migration.
For a Philippine buyer comparing a peso implementation fee with foreign-currency service charges, state the currency, exchange-rate assumption, quote validity and treatment of taxes separately. Ask who receives each upstream bill and who can inspect usage. A cheap proposal that excludes an essential connector may be less complete rather than more efficient.
Use cost per completed, acceptable workflow outcome as an additional comparison lens. Counting only messages can obscure retries, failed tasks and human correction. Do not invent a savings percentage: measure the existing process and the proposed workflow using the same definition of completion.
Agree how the supplier earns acceptance
Use a bounded paid evaluation to resolve the most consequential uncertainty: an integration, a language condition, a permission boundary or an operational handoff. Specify the deliverable, evaluation cases, reviewer, evidence to retain and the decision date in advance. The evaluation fee should buy a usable finding even if the answer is not to proceed.
Keep a small set of non-negotiable conditions separate from weighted preferences. For a drafting assistant, a wrong suggestion may be recoverable through review; access to another customer’s record may be an immediate stop. The thresholds are yours to set for the actual risk, not universal pass rates supplied by this article.
Use the AI pilot evaluation checklist to develop the detailed acceptance record for your selected scope.
- Record which cases were used for development and which were held back for evaluation.
- Review errors by consequence, not only an aggregate accuracy number.
- Decide who approves remediation and which failures require another test.
- Make the next commercial commitment depend on the agreed evidence.
Name the people responsible after launch
NIST’s AI RMF Core includes contingency planning for failures in high-risk third-party systems and clear organizational responsibilities. The referenced 1.0 framework is being revised, according to NIST’s current resource page; this article uses the published 1.0 outcomes as context, not a claim about a completed replacement.[3]
Translate responsibility into a concrete operating conversation. If the model changes behavior, who investigates? If a connector fails during a Philippine holiday, who receives the alert? If a customer-facing response must be withdrawn, who can stop the system? Ask for the support window, severity definitions, escalation contacts and distinction between acknowledging a ticket and restoring service.
A supplier can provide monitoring and engineering support without becoming the owner of your business decisions. Name an internal process owner who can approve changes, review exceptions and decide whether automation should remain active.
Test an exit before you need one
Ask for an example handover package and define the final deliverables in the agreement. Depending on the arrangement, these may include your data exports, configuration, evaluation cases, integration documentation and access-transfer instructions. Source-code ownership and rights to vendor components must be explicit; they are not automatic consequences of paying for implementation.
A usable export needs structure and context. Request a small sample and check whether another operator can understand its fields, identifiers and relationships. Document what cannot be transferred, what must be rebuilt, how long transition support lasts and how it is priced. This is a commercial design choice, not a guarantee that switching will be effortless.
Write a decision memo that survives the sales meeting
End with a short comparison using the same headings for every finalist: workflow fit, evidence, data handling, operating cost, acceptance, support and exit. Record failed gates before ranking preferences. For each unresolved item, name an owner and the evidence needed to close it.
In the distributor example, one supplier might demonstrate a good draft but omit the order-system connection; another might integrate successfully but fail an access-control case. Neither is ready for unconditional rollout. The useful decision is to commission a narrow correction, narrow the intended scope or stop—not to average the two problems away.
Select the supplier whose demonstrated scope and operating commitments match the job you are actually buying. Keep the signed brief and acceptance record alongside the proposal so the same decision can be understood after the sales team has left.