AI In-House Development Support in Thailand: A 90-Day Guide to Building Internal Capability
AI in-house development support helps a company move beyond vendor-dependent proofs of concept and build the ability to improve AI safely on its own. For a Thailand operation, that does not mean eliminating every external provider. It means keeping decisions about business value, data, access, evaluation, change and risk inside the company while using outside specialists where they add genuine expertise or speed.
What AI in-house development really means
An in-house AI capability is not measured by how much code employees write or whether every model runs on company-owned infrastructure. It exists when a business owner can decide which problem is worth solving, what quality is acceptable, which risks are unacceptable and when a system should stop. The internal team must control the evaluation set, data permissions, operating procedures, release decisions and history of design choices.
This definition changes how support should be purchased. The supplier’s output is not simply a working demo. It includes reusable test cases, documented permissions, reproducible configuration, maintainable code, operational playbooks, decision records and explicit exit criteria. External experts may remain available for difficult architecture or security work, but the customer can decide when that expertise is needed and whether the resulting work is acceptable.
OpenAI’s 2026 enterprise research describes recurring patterns such as establishing culture before tooling, treating governance as an enabler, owning business outcomes rather than merely consuming AI, prioritizing quality before scale and protecting work that requires human judgment. These observations come from enterprise interviews and should not be treated as a universal causal formula. They do, however, challenge the idea that distributing licenses is the same as adopting AI.
Another OpenAI report found that its top 10% of monthly enterprise users, described as frontier firms, generated 8.3 times more output tokens per active user than typical firms. The figure is a proxy for depth of use; it is not evidence that productivity or ROI was 8.3 times higher. A sound internalisation programme therefore does not chase token volume. It develops repeatable workflows connected to real business context and governed tools.
Outsourced, co-managed or in-house: choosing the operating model
The decision is not a binary choice between outsourcing everything and building everything internally. The right boundary depends on urgency, internal talent, data sensitivity, operational maturity and the cost of a wrong answer.
| Model | Internal responsibility | External responsibility | Best fit | Main risk |
|---|---|---|---|---|
| Outsourced-led | Business requirements and acceptance | Design, development and early operations | Fast access to scarce expertise | Knowledge and evaluation logic may remain with the supplier |
| Co-managed | Priorities, data, evaluation and first-line operation | Architecture, difficult implementation and coaching | Planned transition toward internal ownership | Ambiguous roles can create accountability gaps |
| In-house-led | Product ownership, design, development and operation | Specialist review, training or audit | Stable team and mature operating platform | Hiring cost and key-person dependence can be underestimated |
For many companies in Thailand, co-management is the practical starting point. A local business owner defines the process and acceptance criteria, a regional or headquarters IT team governs security and shared platforms, and a support partner helps establish architecture and evaluation. Routine knowledge updates may move to the local team, higher-risk changes may require joint review, and platform changes may remain with regional IT.
Measure progress by the range of changes the company can safely make, not by a nominal percentage of technology ownership. Can the internal team update instructions, refresh knowledge, add users, create evaluation cases, diagnose a first-line incident and perform a rollback? The answers show which capability should be transferred next.
Start with a bounded workflow and measurable success
“Deploy generative AI” is too broad to manage. Break the ambition into workflows with identifiable inputs, decisions, outputs and owners: triaging customer enquiries, retrieving maintenance history, checking quotation requirements or drafting a quality report. Early candidates are frequent, have examples of good outcomes and allow a qualified person to detect errors. A task where an error may directly affect safety or a material contractual decision is a poor early automation target if expert review is unavailable.
Success criteria should cover several layers:
- Business outcome: cycle time, rework, lead time or resolution rate
- Quality: accuracy, evidence, completion of mandatory fields and language quality
- Safety: prevention of unauthorised disclosure, appropriate refusal and auditability
- Adoption: sustained use, exceptions, support demand and human override rate
- Capability transfer: the share of evaluation, configuration, release and first-line support completed internally
Launch counts and usage counts are insufficient evidence of value. OpenAI Academy’s Workflow Adoption Planner recommends a limited launch and tracking quality, human overrides, exceptions, support needs and user experience, with explicit criteria to continue, revise, pause, stop or expand. Baseline the current process before building; otherwise the team cannot distinguish genuine improvement from enthusiasm around a new tool.
Build a lean AI CoE and a clear RACI
An AI Centre of Excellence does not need to be a large central department. It needs visible decision paths across business, IT, data, security, privacy, compliance and learning. In Thailand, requirements, meetings and operating instructions may span Thai, English and Japanese. Specify the authoritative language for requirements, evaluation data, runbooks and incident communication rather than assuming translation will resolve ambiguity.
A lean structure includes an executive sponsor, business product owner, AI or IT lead, data owner, security/privacy representative and local champion. One person may cover more than one role, but accountability must remain explicit.
| Activity | Business Owner | AI/IT Lead | Data Owner | Security/Privacy | Local Champion | Support Partner |
|---|---|---|---|---|---|---|
| Select workflow and KPIs | A/R | C | C | C | C | C |
| Approve data use and quality | C | C | A/R | C | C | C |
| Design and implement | C | A | C | C | I | R |
| Build evals and acceptance tests | A | C | C | C | R | R |
| Approve access and residual risk | I | R | C | A | I | C |
| Train users and support adoption | A | C | I | C | R | C |
| Release, pause or stop | A | R | C | C | C | C |
| Accept handover and exit | A | R | C | C | R | C |
Here, A means accountable, R responsible, C consulted and I informed. During the first 90 days, shift selected R roles from the partner to the company. Evaluation maintenance, routine knowledge updates, identity administration and first-line incident handling are often suitable early transfer targets.
OpenAI’s ChatGPT Enterprise admin quickstart similarly calls for owners and admins, launch scope, identity, SSO/SCIM, groups or role-based access and security controls before broad deployment, followed by analytics and impact surveys. The sequence—ownership, identity, access and measurement before scale—is useful even when another product is selected.
Thailand-specific considerations: language, data and governance
A factory may use Thai work instructions, English equipment manuals and Japanese approval documents. A multilingual model alone is not enough. Terminology, abbreviations, units, dates, politeness and approval expressions vary by language and site. Build native evaluation cases from questions people really ask instead of translating a Japanese master set mechanically.
For data, document what is sent to the AI service, where it is processed or stored, what appears in logs, who can inspect it, how long it is retained and how it is deleted. Classify personal data, customer confidential information, designs and potentially export-controlled material. Define permitted, conditionally permitted and prohibited uses for each workflow.
ETDA’s Generative AI Governance Guideline for Organizations discusses benefits and limitations alongside privacy, data security and impacts on employees and society. It favours balanced deployment with stakeholder participation. The NIST AI Risk Management Framework is a voluntary framework for incorporating trustworthiness into AI design, development, use and evaluation; its Generative AI Profile adds considerations specific to generative systems. These resources provide useful structure, but neither substitutes for legal advice.
The World Bank’s Thailand Digital Data Infrastructure Roadmap notes growing cloud and AI adoption and investment while identifying gaps in skills, governance, interoperability and institutional coordination that can limit benefits. Accordingly, an AI implementation consultation should cover the data owner, sharing rules, integration method and local operating capability—not only the application interface.
Specific obligations under Thailand’s PDPA or cross-border data rules depend on the data, purpose and contractual relationships. This article is a practical management guide, not legal advice. Confirm the applicable requirements with qualified privacy and legal professionals.
A 90-day roadmap for an internal AI capability
Ninety days is not a promise to complete “enterprise AI”. It is a controlled period in which one or two workflows can be tested for value and risk while the internal team learns to run the next improvement cycle. Each phase needs continuation and stop criteria.
Days 1–15: discovery and baseline
Observe the work, interview users, measure current time and rework, inventory data and classify risk. Name the person who will review AI output. Create an initial evaluation set from good outputs, bad outputs, exceptions and prohibited behaviour. Deliverables include a workflow map, baseline, data inventory, initial RACI, risk register and evaluation plan.
Do not begin development until the sponsor approves the bounded scope and stop conditions. This prevents a prototype from quietly expanding into unapproved departments or data sources.
Days 16–35: safe prototype and evaluation design
Build a minimum prototype with limited connections. Test common, difficult and refusal cases. For open-ended drafting, combine mandatory elements, prohibited elements, evidence checks, style requirements and human scoring. When retrieval is involved, test permission inheritance and source correctness as well as relevance.
If the solution needs internal knowledge, data freshness and access control should be designed before broad ingestion. Our related guide, Enterprise RAG implementation in Thailand, explains permission-aware retrieval, multilingual evaluation and acceptance in more detail.
Days 36–60: limited operation and workplace learning
Run with a small user group in an environment close to production. Keep a qualified human in the review path and record overrides, exceptions and support questions. Add failures to the evaluation set each week. Diagnose whether the cause is the model, prompt, source data, permissions, workflow or interface rather than reflexively editing the prompt.
Internal staff must now perform real work: configuration changes, evaluation runs, release notes and first-line diagnosis. The partner moves from doing the task to observing, reviewing and coaching it.
Days 61–75: operating model and role-based learning
Define monitoring, alerts, support channels, change requests, approval, rollback and incident communication. Separate routine operation, monthly quality review and material change. Training must include workflow-specific examples, prohibited data, verification methods and the reporting path for errors—not just generic prompting tips.
Our guide to AI training for manufacturing teams in Thailand describes a role-based approach for executives, business owners, users and technical operators. The goal is not to turn everyone into a developer; it is to give each role the judgment needed to use or govern the system.
Days 76–90: acceptance, handover and decision
Freeze the evaluation set and run acceptance tests for quality, safety, operation and capability transfer. Have internal staff perform routine changes and first-line incident response without the partner taking over. Categorise gaps as further improvement, reduced scope, conditional operation or stop.
The final decision is continue, revise, pause, stop or expand. Do not approve production simply because the calendar reached day 90. If expanding, confirm that evaluation assets, access patterns and operating templates can be reused for the next workflow.
How to compare AI enablement partners
Compare providers on transferability and verifiability, not presentation polish. Ask every bidder the same questions and request examples of work products or methods where confidentiality permits.
| Criterion | Question to ask | Strong signal | Warning signal |
|---|---|---|---|
| Business discovery | How will you narrow the problem and define exclusions? | Observation, baseline and named owner | Immediate focus on a model or product |
| Evaluation | How will quality and safety be measured? | Common, difficult and refusal cases; regression tests | Judging by a demo impression |
| Data and access | How will identity, RBAC, logs and retention work? | Starts from current platform and data classes | Proposes bulk ingestion without classification |
| Multilingual delivery | How will Thai, English and Japanese be evaluated? | Native workplace cases and local review | Translation of one master set only |
| Capability transfer | Who learns what, and when? | Pairing, exercises and operating rehearsals | Documentation handed over on the final day |
| Change control | How are changes approved and reversed? | Risk-tiered paths and recorded tests | Uncontrolled production edits |
| Deliverables | How are code, settings and evals delivered? | Repository, format and acceptance criteria are specific | A vague promise of a “complete set” |
| Exit criteria | When can support be reduced? | Internal demonstration against objective criteria | Permanent managed service assumed |
| Commercial clarity | What triggers additional cost? | Assumptions, boundaries and change process are explicit | Ongoing cost after PoC is unclear |
Vendor certifications may be useful evidence of platform knowledge, but they do not prove coaching ability or a willingness to transfer ownership. Consider relevant workflow experience, evaluation discipline, security collaboration, teaching ability and the handover plan together.
RFP and contract: specify outputs, rights, security and exit
An RFP should describe the workflow, acceptance tests, responsibility boundary and transfer target—not just a list of features. Include uncertainty so bidders can state their assumptions.
At minimum, cover:
- Workflow, users, languages, locations and business owner
- Baseline, desired outcome and minimum quality and safety thresholds
- Available and prohibited data, identity, access and logging requirements
- Existing cloud, network, applications and operational constraints
- In-scope and out-of-scope work, customer dependencies and assumptions
- Evaluation, acceptance, resilience, performance and security testing
- Delivery format for code, configuration, prompts, evals and documents
- Treatment of new IP, pre-existing assets, open source and third-party services
- Pairing, training, handover, support and exit criteria
- Change requests, price impact and end-of-contract data return or deletion
The contract should clarify whether customer data can be used for training or service improvement, which subprocessors and APIs are involved, ownership of custom code and generated assets, vulnerability response, log retention, incident notification and termination assistance. Applicable legal interpretation depends on the facts and jurisdiction, so obtain professional review.
Compare cost by component: discovery, data readiness, identity and permissions, prototype, evaluation set, integration, monitoring, training, change management and support. A cheap demo that excludes evaluation and transfer may create a larger cost at production. An over-engineered first phase may commit funds before value is established.
Evals turn subjective impressions into repeatable decisions
Generative outputs can vary, so “it looks good” is not an acceptance test. Evals use real work cases and stable criteria to compare changes. Include normal cases, spelling variations, incomplete or conflicting information, outdated documents, unauthorised requests, malicious input, unanswerable questions and mixed-language content.
| Evaluation layer | Example | Measure | Acceptance question |
|---|---|---|---|
| Task quality | Correct evidence and mandatory fields | Accuracy, completion, citation validity | Are material errors within tolerance? |
| Safety | Refusal and access enforcement | Disclosure count, appropriate refusal rate | Were all high-risk cases reviewed? |
| Operation | Response, failure and recovery | Latency, failure rate, recovery time | Do monitoring and escalation work? |
| Human collaboration | Review, override and exceptions | Override rate, review time, exception rate | Does the tool preserve human judgment? |
| Multilingual quality | Terms, units and context | Pass rate by language, critical mistranslations | Has a qualified speaker approved each language? |
| Capability transfer | Change, test and release | Internal completion rate, procedural deviations | Can the company rehearse without the partner? |
An evaluation set is a living operating asset. Add cases from incidents, overrides and support questions. Run regression tests when the model, prompt, knowledge, retrieval settings or connected tools change. Record what improved and what regressed.
Design monitoring and change control before launch
Production introduces changing data, permissions, usage, external service incidents and model updates. Monitor availability, latency, errors, volume and cost, but also sample quality, refusals, access violations, overrides and support demand. Do not retain every conversation indefinitely: define the purpose, viewing rights, masking and retention period.
Tier changes by risk. A wording correction or FAQ addition may follow an internal checklist. A data connection or permission change needs IT and data-owner review. A model change or expansion of autonomous action requires broader approval and security involvement. For each release, preserve the reason, author, evaluation result, approver and rollback method.
An agent that sends emails, creates orders or modifies records needs stronger controls than a read-only assistant: least privilege, action-specific permission, human approval, audit logging, transaction limits and an emergency stop. Connecting AI to context and tools creates value only when clear authority, review and governance are added at the same time.
Train by role and practise real exceptions
Generic prompt training is not an internalisation programme. Executives need investment and risk judgment; business owners need workflow selection and acceptance design; users need verification and escalation; IT needs identity, monitoring and change control; developers need evaluation-driven improvement.
Give local champions enough authority to support colleagues in Thai, collect recurring failures and propose improvements to the central team. Assess practical work: discovering an error, escalating it, running an evaluation and releasing a low-risk change. A quiz alone does not show operational capability.
Transfer should progress through explanation, paired work, internal leadership and supplier observation. Record why a design was selected and which alternatives were rejected. Videos and runbooks help, but decision history is what allows a successor to handle exceptions rather than merely follow a happy path.
Agree deliverables, acceptance criteria and graduation conditions
Without exit criteria, “coaching support” can continue indefinitely. Define what the company must demonstrate before support is reduced and review progress monthly.
| Deliverable | Example acceptance criterion | Example graduation condition |
|---|---|---|
| Workflow and KPI definition | Owner approves baseline and decision method | Company assesses the next candidate using the same template |
| Architecture and data flow | Connections, storage, access and services are reproducible | Internal IT explains impact of a proposed change |
| Code, settings and prompts | Versioned repository, README and environment differences exist | Internal staff releases a routine change alone |
| Evaluation set and results | Common, difficult, refusal and multilingual cases rerun successfully | Company adds cases and runs regression tests |
| Security and risk record | Risk, control, residual risk and approver are named | Internal forum assesses a change risk |
| Operations and monitoring | Normal, incident, stop and recovery procedures are rehearsed | Internal team passes first-line response exercise |
| Training and skills matrix | Role-based exercises and pass criteria exist | Each role has a trained primary and backup |
| Decision log | Choices, alternatives, assumptions and review triggers are recorded | A successor can explain key design decisions |
Graduation does not require the company to solve every specialist problem alone. It can continue buying independent security review or advanced model evaluation. The essential capability is deciding what to commission, accepting the result and preserving the assets if the provider changes.
Common failure patterns in AI internalisation
Treating a finished PoC as a finished operating capability
A demo validates part of a value hypothesis. It does not prove access control, monitoring, exceptions, support or training. Separate PoC exit criteria from production acceptance and require an operational rehearsal.
Transferring prompt techniques but not diagnosis
Quality depends on data, retrieval, user interface, workflow, permission, model and review design. If the company cannot identify which layer caused a failure, it cannot improve the system safely.
Naming one part-time “AI person”
One person rarely owns business knowledge, technical design, data permission and risk acceptance. A small RACI, separation between business and IT accountability, and trained backups reduce key-person risk.
Measuring usage instead of outcomes
High usage may coexist with extra checking and rework. Track workflow outcomes, quality, safety, review burden and capability transfer together.
Calling translation a multilingual strategy
Factory terms, units, product names and approval language are contextual. Use representative cases and approval by local business users for every operating language.
Defining exit conditions at the end
Transfer time becomes difficult to protect once the supplier is embedded in daily operation. Put internal demonstration dates and support-reduction criteria into the initial plan.
How to think about cost and value
There is no responsible universal price for AI in-house development support. Scope, data readiness, integration, identity, languages, evaluation depth, training and operational requirements materially change the work. Ask what capability and reusable asset each cost item buys.
Make assumptions transparent when estimating value. For illustration only, if 30 employees each have 20 hours per month of AI-assistable work, the assumed reduction is 15%, and labour is valued at THB 600 per hour, the estimated time is 30 × 20 × 15% = 90 hours, or THB 54,000 per month. This is neither a market benchmark nor a performance promise. Deduct support, cloud, API, operation, human review and training costs, and consider quality or lead-time effects separately.
Internalisation may also create option value: the next workflow can reuse evaluation templates, permission patterns, runbooks and training content. That benefit only exists when reuse is deliberately designed and accepted as a deliverable.
FAQ about AI in-house development support
What is AI in-house development support?
It is a structured engagement in which specialists help a company design, build, evaluate, govern and operate AI while transferring decision and operating capability to internal staff. It does not require eliminating all external expertise.
What can an AI enablement partner cover?
Possible scope includes workflow discovery, data assessment, RFP preparation, prototyping, evaluation design, integration, governance, role-based training, operations and handover. The key is to state what the company will own during each phase and when responsibility transfers.
Does internal AI development require a full-time CoE?
Not necessarily. A lean cross-functional group can work if business ownership, IT, data, security and local adoption responsibilities are explicit and the team can make operating decisions.
How should proposals be compared?
Break price and scope into discovery, data, prototype, evaluation, integration, monitoring, training, change management and support. Compare identical deliverables and acceptance criteria rather than relying on unverified market-price claims.
Can an AI solution reach production in 90 days?
A bounded workflow and user group may reach controlled production readiness, but data quality, integration, security review and stakeholder availability can change the timeline. Acceptance evidence, not the date, should determine launch.
What should be checked for Thailand PDPA?
Map purpose, data classes, processing and storage locations, third parties, access, logs, retention and deletion. Actual legal obligations depend on the circumstances; obtain qualified advice rather than treating this article as a legal opinion.
When has the company graduated from support?
A useful signal is that internal staff can add evaluation cases, run regression tests, release routine changes and handle first-line incidents using accessible assets and decision records. Specialist support may continue where it is genuinely needed.
Conclusion: define the capability that stays inside the company
When selecting AI in-house development support, look beyond PoC speed and feature count. Ask whether evaluation assets, permission design, operating procedures, training, decision history and graduation criteria will stay with your team. In Thailand, multilingual work, data governance and the transfer of authority to local staff deserve explicit design. A bounded 90-day programme with a baseline lets leaders decide whether to expand, revise or stop using evidence rather than optimism.
TOMAS TECH can support early-stage scope definition, RFP preparation, a 90-day PoC and an internal capability-transfer plan. If you are still deciding what should remain in-house and where specialist support is appropriate, contact our team for a practical discussion.
References
- OpenAI: From assistance to execution: How enterprises put AI to work
- OpenAI: How enterprises are scaling AI
- OpenAI Help Center: ChatGPT Enterprise admin quickstart
- OpenAI Academy: Workflow adoption planner
- NIST: AI Risk Management Framework
- NIST: Generative Artificial Intelligence Profile
- ETDA: Generative AI Governance Guideline for Organizations
- World Bank: Thailand Digital Data Infrastructure Roadmap
