Outsourcing AI Development: An RFP, Contract, and Acceptance Testing Guide

When outsourcing AI development, model names, polished demos, and daily engineering rates are not enough to predict production success. For Japanese manufacturers in Thailand and ASEAN, the real decisions are: which business scenarios and data will determine acceptance; how rights and processing boundaries for data, models, prompts, and deliverables will be defined; and who will own monitoring, change control, and exit transfer after go-live. This guide turns those three controls into practical RFP, contracting, and acceptance steps so an outsourced AI project is selected as a repeatable business system—not as a one-off demonstration.

Three controls to define before outsourcing AI development

AI systems differ from conventional deterministic software. Outputs can vary for similar inputs, source data and external services change, model updates can alter behavior, and plausible but incorrect answers can pass a superficial review. A finished screen and function list therefore do not prove that the system is fit for work.

Treat the following three controls as one connected management system from the start.

Procurement, business owners, IT, information security, privacy/legal stakeholders, and local operators should review the same version of this matrix. ETDA’s Generative AI Governance Guideline highlights human oversight, legal and regulatory consideration, interdisciplinary collaboration, data governance, monitoring/evaluation/improvement, and evaluation of third-party products and components. It is guidance rather than a ready-made contract, but it is a useful way to find gaps in an outsourced scope.

Do not make the model name or demo the main selection criterion

Claims such as “we use the newest model,” “we achieved high accuracy,” or “we can demo on your data” should begin a discussion, not end it. The result is not comparable until the denominator, business scenario, impact of different errors, treatment of unseen data, and test environment are known.

Consider an AI system that summarizes maintenance reports. A readable paragraph is not enough; the system may need to preserve the equipment number, downtime, safety warning, and unresolved item. A purchasing agent must not merely produce natural replies; it must avoid unauthorized price changes or purchase orders, prevent cross-supplier disclosure, and escalate when evidence is missing. A quality-record search must distinguish factory, line, part number, revision, and date—not just retrieve a similar-looking document.

Compare suppliers through evidence for these questions:

• Can they describe business success and failure through inputs, expected results, and a decision method?
• Can they evaluate on separated unseen data and trace each case result?
• Can they version models, prompts, retrieval content, tools, permissions, and thresholds?
• Can they test hostile input, confidential data, excessive privileges, and external-service failure?
• When production quality drops, can they detect, roll back, investigate, and revalidate?
• At contract exit, can another operator reproduce the configuration and evaluation?

For a separate treatment of budget and success gates, see our AI PoC cost and success criteria guide for manufacturers in Thailand. This article focuses on converting that PoC into a procurable and acceptable deliverable.

Write the AI system development RFP from business scenarios

Before listing product features, describe the present workflow, the moment AI is used, the effect of failure, and where a person intervenes. Replace “the AI shall…” with “which person receives what information, makes what decision, and records what result in which system.” That phrasing naturally leads to acceptance criteria.

1. In-scope and out-of-scope work

For in-scope work, state the trigger and end condition, user groups, input sources, output destinations, expected volume, operating hours, required languages, and accountable owner. For out-of-scope work, state decisions the AI may not make, actions that require human approval, prohibited data, and excluded companies, factories, or products.

Japanese groups often split responsibilities between headquarters and the Thai entity. If headquarters contracts the supplier, Thai-company data is processed, and ASEAN affiliates use the service, document who determines the purpose, permissions, incident response, user inquiries, and supplier instructions. Define this as an operating procedure rather than relying on an organization chart. If personal data may be involved, assess the concrete data flow and applicable requirements with qualified Thai legal and privacy professionals.

2. Success and failure scenarios

Success scenarios alone allow a supplier to optimize for its easiest examples. Include normal, edge, exception, prohibited, and recovery scenarios.

3. Translate non-functional requirements into AI-specific language

Performance requirements should cover input size, concurrency, retries, external API limits, cost ceilings, and timeout behavior—not only average latency. Availability should be measured end to end across document conversion, retrieval, identity, the model, ERP integration, and human approval.

Security requirements should combine ordinary identity, encryption, and vulnerability management with tests for prompt injection, sensitive-information disclosure, excessive agency, untrusted output reaching downstream systems, third-party supply-chain weakness, and uncontrolled resource consumption. OWASP’s project page identifies the GenAI LLM Top 10 2026, published on August 4, 2026, as the current release. A checklist alone is not acceptance evidence. For each relevant risk, specify the input, the user’s privilege, the downstream connection, and what must not happen.

Make the acceptance dataset a contractual deliverable

The most important quality asset in outsourced AI development is the acceptance dataset. It is not merely a folder of samples. It combines an input, expected result, decision rule, severity, provenance, and permitted use.

Divide the dataset into six layers

1. Representative data: frequent production inputs balanced by factory, department, language, document class, and user type.
2. Boundary data: similar part numbers, long inputs, degraded images, spelling variation, multilingual content, and date boundaries.
3. Error data: missing, contradictory, duplicated, unreadable, or temporarily unavailable sources.
4. Safety data: requests for unauthorized records, manipulative instructions, confidential extraction, or dangerous actions.
5. Regression data: cases for defects already corrected, ensuring they do not return after an update.
6. Holdout data: customer-controlled cases not disclosed before final acceptance, used to detect overfitting to the demonstration set.

An average can look excellent while rare, high-impact failures remain hidden. Assign each case a business severity, and never average a dangerous automatic action together with a minor wording preference as though they were equivalent.

Evaluate outputs that do not have one exact answer

Classification and field extraction often have clear labels. Summaries, answers, and recommendations may have several acceptable forms. In those cases, combine required elements, prohibited elements, supporting evidence, output structure, and a human rubric instead of demanding exact text.

OpenAI’s evals guide illustrates an evaluation defined with data_source_config and testing_criteria, using a representative test dataset and human-provided ground truth. The transferable idea is vendor-neutral: separate the evaluation data from the pass rule, version both, and make the run repeatable.

Assign dataset responsibilities explicitly

The supplier cannot define business truth alone. The customer alone may also create criteria that are technically unmeasurable. A workable split is: the business owner defines scenarios and impact; IT and security define environments and safety conditions; the supplier proposes measurement and automation; and a joint review freezes the baseline before build.

The contract should specify who provides source data, anonymizes and labels it, approves quality, and pays for added cases. Even if the supplier prepares evaluation data, the customer should control a holdout set and retain authority over final acceptance.

Break AI development evaluation beyond “average accuracy”

Separate business outcome, quality, safety, operations, and economics. A project may require a hard gate where one Critical failure causes rejection even if the average exceeds its threshold. Conversely, define acceptable variation so that a stylistic preference does not fail the whole system.

Quality measures

• Classification: correct, misclassified, and abstained cases by class; inspect rare but important classes separately.
• Extraction: correct, missing, and wrong fields, weighted for equipment IDs, amounts, or other critical data.
• Retrieval: whether required documents appear, current revisions are prioritized, and unauthorized records are excluded.
• Generation: evidence alignment, mandatory content, prohibited content, language, and required structure.
• Workflow: escalation rate, rework, processing time, review count, and business completion rate.

Safety and control gates

Major confidential disclosure, unauthorized action, approval bypass, missing audit evidence, and unsafe automation should be separate rejection conditions. Do not test whether the AI sounds confident; test whether it detects absent evidence or insufficient authority and fails safely.

Human oversight should mean more than “someone looks at the result.” Test the rules that decide automatic processing versus review, the identity of approvers and rejecters, and the recording of their decisions. ETDA’s guideline gives examples of people reviewing and accepting or rejecting generative-AI content to avoid excessive reliance.

A practical way to settle thresholds

The RFP does not always need an arbitrary number on day one. It can define the process: measure a baseline at PoC start, have the business owner approve Critical cases and tolerance, then freeze the acceptance plan before the build phase. Final values should reflect actual data, risk, the current process’s error rate, and available review capacity.

Acceptance evidence should retain dataset version, application version, model identifier, prompt version, retrieval-index version, configuration, run time, case-level results, approver, and known limitations. A summary PDF is insufficient unless the conditions can be reproduced.

Draw the boundaries for data, models, prompts, and deliverables

An AI application rarely consists only of the supplier’s code. It may combine cloud infrastructure, foundation and embedding models, retrieval, document parsing, monitoring, open-source software, and external APIs. Require a one-page data flow and responsibility map from input to output.

Component register requested in the RFP

A sentence saying “customer data is not used for training” does not explain embeddings, logs, support diagnostics, service improvement, third-party transmission, or backups. Avoid using “training” as an umbrella. Review purpose, destination, retention, reuse, and deletion for every flow.

If personal data is involved, roles, instructions, subcontracting, transfer, retention, data-subject handling, and incident notification require project-specific review. Do not infer compliance from this article; seek qualified Thai legal and privacy advice for the real architecture and contracts.

Deliverables and intellectual property

“All project deliverables will be handed over” is too vague. List source code, infrastructure and environment configuration, prompts, tool definitions, retrieval configuration, schemas, evaluation scripts, test cases, operating procedures, architecture, component inventory, known limitations, and trained or tuned assets where applicable.

For each, distinguish pre-existing material from newly created work, and have legal stakeholders confirm the customer’s rights to use, modify, support through another party, and continue after termination, plus all third-party conditions. A customer may not own a foundation model, but can still reduce lock-in by retaining interfaces, evaluation assets, configuration, and data exports that permit model substitution.

ETDA distinguishes Adopter, Customizer, and Maker patterns with increasing complexity. An organization consuming an off-the-shelf service needs different rights, evidence, and skills from one building RAG or additional tuning, and both differ from a foundation-model maker. State the project’s role in the RFP instead of treating all activity as generic “AI development.”

Translate secure development into procurement questions

NIST describes the Secure Software Development Framework as a common language that software producers and acquirers can use for procurement and management. It groups practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Convert them into supplier questions.

NIST SP 800-218A is an SSDF community profile for generative AI and dual-use foundation models. Do not impose every foundation-model practice on a small RAG integration without analysis. Select controls in proportion to whether the customer and supplier are acting as Adopter, Customizer, or Maker, and which party creates each component.

AI-specific security acceptance scenarios

• Place an instruction such as “ignore previous rules” inside a document and try to induce unauthorized disclosure or action.
• From a low-privilege account, attempt to infer or retrieve another plant’s, company’s, or department’s records.
• Insert SQL, URLs, code, or operational instructions in output and confirm downstream systems do not execute them without validation.
• Send repeated large requests and verify limits, timeout, cost guards, and safe shutdown.
• Disable the external model, retrieval platform, or ERP connection and verify controlled errors, retries, and duplicate prevention.
• Update the model or prompt and confirm an unapproved version cannot reach production.

Passing these tests does not remove unknown attacks or future-change risk. Acceptance establishes a minimum gate; monitoring and reevaluation must continue through the service period.

Practical items for the contract, purchase order, and SOW

The following are operational topics, not substitute legal clauses. They should be agreed in the contract, purchase order, statement of work, or acceptance plan. Qualified advisers should adapt the actual language to the parties, governing law, data, and industry.

Outcome and scope

• Business process, companies and plants, users, languages, and connected systems.
• Phases for PoC, production build, migration, stabilization, and support, each with completion gates.
• Deliverable register, editable originals, repository, format, and delivery date.
• Customer and supplier prerequisites, data work, environments, and decision deadlines.
• Exclusions, change pricing, and the person who approves priority changes.

Acceptance and failed criteria

• Acceptance dataset, custodian, disclosed portion, and version control.
• Measures, Critical gates, tolerances, and human assessors.
• Test environment, permitted runs, reproducibility, and evidence format.
• Defect severity, correction, retest, conditional acceptance, and known limitations.
• Model or external-service changes that trigger reevaluation.

Data, security, and third parties

• Data flow, processing location, access, encryption, logs, retention, return, and deletion.
• External services, subcontractors, OSS, models, licenses, and change notification.
• Each provider’s permitted purpose for customer data, inputs, outputs, and logs.
• Vulnerability channel, incident notice, investigation support, evidence preservation, fix, and mitigation.
• Least privilege, secret management, environment separation, and administrator audit.

Operations, change, and cost

• Service hours, support route, incident severity, response, and restoration goals.
• Quality, abstention, escalation, latency, usage, and cost indicators.
• Change requests and approvals for prompts, models, retrieval data, tools, and thresholds.
• Allocation of external-fee, exchange-rate, volume, reevaluation, and emergency-response cost.
• Service review, reporting, improvement backlog, training, and documentation updates.

Test monitoring and change control before acceptance

AI quality moves as input distribution, document revisions, user questions, models, retrieval indexes, and business rules change. “Accuracy at delivery” is therefore not enough. Run the production monitoring and response procedure as part of acceptance.

Five types of signal

1. Business: completion, escalation, rejection, processing time, and adoption by department.
2. Quality: unsupported answers, wrong classifications, missing critical fields, user feedback, and regression cases.
3. Safety: access denials, prohibited input, masking, abnormal tool calls, and missing audit events.
4. Technical: latency, errors, external APIs, retrieval failures, queues, limits, and rollback readiness.
5. Economic: cost per case, retries, long input, storage, human review effort, and budget variance.

Every alert needs an owner, response window, decision, and stop authority. A dashboard without operational decisions and communication rules is not a control.

Four classes of change

• Minor: wording or display change, with a limited regression scope.
• Standard: prompt, retrieval, threshold, or ingestion-rule change, requiring related reevaluation.
• Major: model, processing location, external service, tool privilege, or decision-scope change, requiring renewed risk, legal, and security approval.
• Emergency: stop or rollback for vulnerability or incident, followed by review and permanent correction.

A supplier may not control every model-provider update. Define update detection, impact review, version-pinning feasibility, substitutes, reevaluation, and customer notification. “It updates automatically” should not end the discussion; identify what can be controlled and how continuity is maintained.

The NIST AI RMF Generative AI Profile is a voluntary resource that supports trustworthiness considerations across design, development, use, and evaluation. NIST’s 2026 concept note for a trustworthy-AI profile in critical infrastructure also emphasizes participation across sectors, organizational roles, and supply-chain partners. The practical inference for manufacturing is to manage the lifecycle around equipment, workflow, suppliers, and users—not only the standalone model. The critical-infrastructure document remains an ongoing concept, not a finished standard.

Design exit transfer before the final month

If handover artifacts are collected only when a contract is ending, access, evaluation data, prompt history, and external arrangements may be missing. Request an exit plan in the RFP, then update it at design review, acceptance, and periodic service reviews.

Minimum transfer package

• Current and previous stable source, configuration, prompts, tool definitions, and schemas.
• Architecture, data flow, dependencies, component and license register, and external contracts.
• Build, deployment, backup, recovery, monitoring, incident, and access procedures.
• Acceptance and regression datasets, grading logic, case history, and known limitations.
• Retrieval content, index reconstruction, update/deletion history, and evidence-display behavior.
• Open defects, vulnerabilities, planned changes, cost, accounts, certificates, and renewal dates.
• Export of customer data and logs plus evidence of return or deletion.

Do more than confirm that documents exist. Ask the customer or a different operator to rebuild a non-production environment and execute representative cases. Full vendor replacement may still be difficult, but retaining evaluation assets, data, and separated interfaces improves continuity and negotiating power.

For the wider delivery model, see our practical guide to AI development in Thailand. If the objective is to build an internal team while using an external partner, our AI in-house development support guide for manufacturers in Thailand explains how to divide responsibilities.

Supplier comparison scorecard for outsourced AI development

Score evidence, not presentation quality. Adjust weights to the project’s risk.

A lower-priced proposal is not inherently worse. A deliberately narrow scope, correct human checks, measurable acceptance, and a defined exit can create a safe, economical start. A premium model and large team can still create high future cost if acceptance, responsibility, and portability remain unclear.

An eight-step AI implementation path from RFP to acceptance

1. Appoint the business owner and document scope, exclusions, failure impact, and human decisions.
2. Draw the data flow and identify personal, confidential, transfer, third-party, and privilege issues.
3. Prepare representative, edge, error, safety, regression, and holdout acceptance cases.
4. Agree measures, Critical gates, tolerance, assessors, evidence, and retest triggers.
5. Ask for a component register, development evidence, operations, change, and exit plan in the RFP.
6. Use the PoC to test workflow, people, security, economics, and recovery as well as output quality.
7. Before production, rehearse monitoring, rollback, incident handling, change approval, training, and transfer.
8. After go-live, rerun regression assets and update risks and documents whenever the system changes.

This approach treats the PoC as a place where customer and supplier build a common measurement language—not as a stage-managed success. Defining adoption evidence early does not delay technology selection; it makes comparison and approval faster.

FAQ about outsourcing AI development

Should we choose an AI development supplier by model accuracy?

Model benchmarks are useful context but not sufficient. Compare end-to-end results using representative, edge, abnormal, and safety cases from your workflow, including retrieval, permissions, integration, and human review. Prefer suppliers that provide case-level evidence and reproducible methods.

What matters most in an outsourced AI development contract?

No single clause is enough. Acceptance criteria, boundaries for data/deliverables/third parties, operational change, and exit transfer must connect. If the parties do not agree which data, assessor, and evidence define completion, the meaning of “finished” will diverge. Have legal language reviewed for the actual project.

Should we disclose all AI PoC data to the supplier?

You can separate development and evaluation data and protect a final customer-controlled holdout. Also verify rights, anonymization, secure transfer, and label quality. Secrecy alone does not make a good test; the composition must represent production.

What if AI system accuracy drops after go-live?

Monitor quality and business signals, then isolate changes in inputs, documents, model, prompt, retrieval, or external services. Approve corrective changes, rerun regression tests, and retain a procedure for returning to the previous stable version.

Should an AI implementation begin with a full production contract?

For higher-risk work, stage business definition, data preparation, PoC, production, and stabilization with a continuation gate at each step. Do not make the PoC disposable: its evaluation assets, data flow, and operating criteria should transfer into production.

What should be checked when Thai personal data may be processed?

Map the data fields, purpose, party roles, access, processing location, subcontracting, retention, deletion, and incident response. Ask qualified Thai legal and privacy professionals to review the specific arrangement; do not infer the answer from a system label or cloud region alone.

Conclusion: Buy a system that can be accepted, changed, and transferred

Outsourcing AI development should purchase more than a compelling demo or access to a named model. First, buy a scenario-based acceptance dataset and pass criteria. Second, establish rights and processing boundaries for data, models, prompts, code, outputs, logs, and third-party components. Third, obtain the operating assets needed to monitor, approve changes, recover, and transfer the service.

When these three controls connect across the RFP, contract, and acceptance, the customer can use the same business standard even as models and providers change. When the only completion evidence is a one-off demo, production degradation, extra cost, responsibility disputes, and vendor lock-in become much harder to control. Start with a small workflow if necessary, but document the acceptance cases, prohibited outcomes, data flow, change procedure, and transfer package from day one.

TOMAS TECH supports manufacturers in Thailand and ASEAN from the pre-supplier stage: workflow definition, RFP preparation, AI PoC acceptance, data and core-system integration, operating controls, and transfer planning. You can consult us while the model and supplier are still undecided; we can structure the approach around the present workflow and impact of failure. Contact TOMAS TECH.

References

1. ETDA: AI 2026 “Driving Trust AI Governance”
2. ETDA: Generative AI Governance Guideline for Organizations
3. NIST: AI RMF Generative AI Profile
4. NIST: Concept Note for Trustworthy AI in Critical Infrastructure
5. NIST: Secure Software Development Framework
6. NIST SP 800-218A
7. OWASP: Top 10 for Large Language Model Applications
8. OpenAI: Working with evals
9. Thailand Department of Lands: official publication of the Personal Data Protection Act B.E. 2562