AI Adoption for SMEs: A Practical 90-Day Roadmap

AI adoption for SMEs should not begin with the most capable tool available. It should begin with a decision: which workflow will improve, who will own the outcome, what data may be used, and what evidence will justify continuing. This guide is written for small and midsize businesses operating in Thailand and Southeast Asia. It explains how to move beyond generative AI trials through readiness assessment, use-case selection, build-versus-buy boundaries, a 90-day pilot, RFP and acceptance tests, proportionate governance, and total-cost and ROI gates.

Why SME AI adoption stalls after a promising tool trial

An individual can start summarising or translating text with generative AI in minutes. A company cannot make the same activity operational without deciding how input data, incorrect answers, approval, access, cost, support, and staff handover will be managed. The gap between a trial and a repeatable business process is mainly an operating-design gap.

The OECD’s 2025 report on AI adoption by small and medium-sized enterprises notes that adoption remains lower among SMEs than among large firms. It identifies connectivity; data, algorithms and computing resources; skills; and finance as important enablers. This is not evidence that AI is unsuitable for SMEs. It means that the adoption path should match digital maturity and use-case complexity instead of copying a large-enterprise programme.

For Thailand, the World Bank’s Digital Data Infrastructure Roadmap describes digitally connected micro, small and medium enterprises while also identifying room to deepen the use of advanced analytics and automation. Skills, governance, interoperability, regulatory uncertainty, and access to data remain constraints. A July 2026 field update from Thailand’s depa AI Transformation programme reports use in shop management, customer data, accounting, process reduction, text-to-speech, smart meters, and smart CCTV. These are programme observations, not independent proof that every participant or use case achieved the same result.

Trials commonly stop for structural reasons:

• “Use AI” is the objective, with no defined business result.
• Teams test consumer tools without a boundary for permitted data.
• A demo looks convincing, but no baseline exists for time, errors, or rework.
• Nobody owns human review or the feedback loop when an output is wrong.
• API usage, integration, evaluation, training, and monitoring are absent from the budget.
• Responsibilities among management, process owners, IT, and vendors are unclear.
• Acceptance relies on adjectives such as “accurate,” “fast,” or “secure” rather than testable evidence.

The solution is not to write a huge AI strategy first. Select one workflow, fix the baseline and scope, define inputs, acceptance and stop conditions, and use 90 days to collect decision-quality evidence.

Assess AI readiness across five practical dimensions

ETDA’s AI Readiness Assessment uses 12 questions across five dimensions. Visible dimensions include strategy and organisational capability, people, data, and infrastructure. It is useful as a prompt for readiness discussions, not as a certification. For implementation, we can group the questions into strategy, process and people, data, infrastructure, and governance.

A company does not need a perfect score. Missing conditions must not invalidate the experiment. If an email-classification pilot lacks historical emails with agreed labels, create an evaluation set before comparing models. If the data is confidential, begin with minimised or anonymised samples and establish a separate approval gate for production-like data.

Do not turn readiness into a corporate score with no workflow context

“Our data is weak, so it is too early for AI” is too broad. “We already use cloud services, so we are ready” is equally broad. Drafting marketing copy from public information has a different data boundary and failure impact from helping prepare a quotation based on customer drawings.

For each candidate workflow, list the source data, the recipient of the output, the consequence of an error, the required response time, and the manual alternative. Readiness is then the set of conditions under which that particular workflow may safely enter a pilot—not a single label applied to the entire company.

Choose one generative AI workflow by value × feasibility × risk

The first AI adoption project should not merely promise high impact. It should be assessable within a bounded period. Comparing candidates on value, feasibility, and risk helps the team resist a spectacular but irrelevant demo.

Possible candidates include first-line enquiry classification, action extraction from meeting records, internal policy search, pre-quotation information collection, maintenance-record summarisation, and a quality-report draft. Their risk depends on industry and data. A draft is not automatically low-risk: the assigned reviewer must have enough time, volume capacity, and expertise to identify material errors.

Use scoring to record a discussion, not to replace judgement

A five-point value and feasibility scale and a five-point risk scale can be helpful, but the numbers are not inherently objective. Record why each score was chosen and obtain agreement from the process owner and IT or information-governance owner. Good first candidates usually meet five conditions:

1. A baseline can be collected over a period suited to the workflow.
2. Representative inputs and expected outputs are available.
3. Value can be tested while retaining human review.
4. The team can return to the current process if the pilot fails.
5. A successful pattern could later extend to an adjacent workflow.

The observation period should match the operating cycle. One instance is inadequate for monthly work, while high-volume daily work may reveal a pattern quickly. Include busy periods, difficult cases, languages, and customer segments in the evaluation data.

Where to start with generative AI: freeze the problem on one page

Before comparing products, write a one-page “use-case contract.” It creates a common reference for management, the process owner, IT, information governance, and vendors.

• Workflow and users in scope
• Current start point, end point, median, range, and rework
• Tasks assigned to AI and decisions retained by people
• Permitted data and prohibited data
• Expected output, mandatory fields, format, and language
• Acceptance metrics and minimum thresholds
• Impact of errors and required human review
• Fallback procedure for outage or quality deterioration
• Owner of the continue, revise, or stop decision after 90 days

“Automate quotations with AI” is too broad. A testable statement would be: “Extract product family, quantity, requested delivery date, and unresolved conditions from submitted specifications, then prepare a question-list draft for a sales employee to review. Pricing and customer communication remain out of scope.” Inputs, outputs, errors, and responsibilities can now be tested.

Before asking a development partner for a proposal, see our guide to outsourcing AI development in Thailand. Writing the requirement as a business scenario, data boundary, evaluation set, and operating responsibility makes competing proposals more comparable than requesting “a chatbot.”

Build, buy, or combine—and define the vendor boundary

An AI solution can be a configured SaaS product, an application assembled from APIs and existing systems, or a custom application and model workflow. The choice is not based only on whether an in-house engineer is available. Consider business differentiation, confidentiality, integration, frequency of change, accountability, and exit options.

For many SMEs, a standard capability plus a small integration may be practical. However, choosing by implementation fee alone omits usage charges, data preparation, permissions, evaluation, and support. The opposite mistake is to demand complete future flexibility through custom development before the value hypothesis has been tested.

Responsibilities that remain inside the company

A vendor can design and implement technology, support testing, configure monitoring, and train users. It cannot take over every business accountability. The company still must:

• Set the business objective and priority.
• Approve permitted and prohibited data.
• Explain correct outcomes and exceptions.
• Decide whether outputs are acceptable for the workflow.
• Approve production start, suspension, and restart.
• Review obligations to customers, employees, and contractual parties.

Create a one-page RACI naming the process owner, final approver, IT or security owner, data owner, and vendor lead. If a vendor claims “accuracy,” ask who creates the evaluation set, which versions of the model, prompt, retrieval source, and workflow were measured, and who detects deterioration after change.

The 90-day AI adoption roadmap

Ninety days should not be treated as one long development phase. Use days 0–30 to fix the problem and baseline, days 31–60 to test value and risk in a limited environment, and days 61–90 to validate operating sustainability. End each period with a continue, revise, or stop gate.

Days 0–30: fix the workflow and baseline

The first month prioritises observation before a product commitment.

1. Name the process owner and target users.
2. Record work, waiting, rework, and exception paths from start to finish.
3. Define and measure current elapsed time, throughput, errors, and corrections.
4. Collect representative samples and difficult cases for evaluation.
5. Classify data as public, internal, confidential, or restricted under company policy.
6. Define AI scope and explicit exclusions.
7. Design human review and a fallback procedure.
8. Compare feasible approaches and approve the pilot plan.

Do not rely on the average alone. Examine the median, range, and difficult-case mix. A baseline based only on a fast employee’s best day, or an AI test fed only easy examples, overstates benefit.

Days 31–60: measure benefit and danger together

Operate a prototype in an evaluation environment. Include missing inputs, contradictions, multiple languages, long documents, ambiguous requests, and inaccessible sources—not just clean examples.

• Score output quality by required element.
• Classify material errors and record their triggering conditions.
• Measure response time and usage volume.
• Log input, output, evaluation, and the versions of models and settings.
• Test that the system does not retrieve data outside the user’s permission.
• Include employee correction time in end-to-end effort.
• Exercise the fallback to the current workflow.

“Nine out of ten outputs looked good” is insufficient. Confusing a customer identity is not equivalent to correcting punctuation. Separate severity. Where a critical error has zero tolerance, design both detection and suspension rather than assuming a high average score makes it disappear.

Days 61–90: test a limited live operation

Limit the users and transaction volume while retaining required human review.

• Record training time and support questions by user group.
• Hold daily or weekly quality reviews appropriate to volume.
• Exercise the reporting path for error, data incident, outage, and abnormal cost.
• Version prompts, retrieval sources, workflow rules, and integrations.
• Measure actual subscription, usage, and internal operating effort.
• Compare time, quality, and waiting against the same baseline scope.
• Prepare evidence for the continue, redesign, or stop decision.

The next step after day 90 does not have to be company-wide deployment. Stabilise the selected workflow and confirm that the owner and monitoring capacity remain sustainable. If value exists but review effort is too high, narrowing automation can be a better decision than increasing autonomy.

Write the RFP and acceptance criteria as evidence, not a demo request

Replace adjectives such as “highly accurate,” “secure,” “easy,” and “integrates with our systems” with requirements that both parties can test. Give candidate vendors the same evaluation data and scenarios so that demonstrations based on different success cases are not compared as if they were equivalent.

How to define an acceptance test

A requirement such as “at least 90% summary accuracy” is not comparable until the measurement method is defined. Specify the unit of assessment, the person or procedure establishing expected results, whether partial credit exists, and whether critical errors override the overall score.

For enquiry classification, test more than category match. Include failure to identify urgent cases, extraction of customer and product, routing to the correct queue, source evidence, and a hold state when confidence is insufficient. For internal search, test not only whether an answer can be produced, but whether an unauthorised document is excluded, the source and update date are visible, and the system declines to guess when evidence is absent.

An acceptance plan should cover:

1. Target population and sample selection
2. Expected result or adjudication procedure
3. Quality metrics and error severity
4. Measurement points for response time and availability
5. Permission, leakage, and malicious-input tests
6. Audit trail and reproducibility
7. Fallback for outage, limit, or vendor unavailability
8. Approvers for pass, conditional pass, and fail

For the data boundary around confidential prompts and outputs, see our generative AI data-leak prevention guide. Product configuration must be combined with policy, classification, permissions, logs, training, and incident handling.

Right-size AI governance without leaving accountability blank

The NIST AI Risk Management Framework is voluntary and supports risk management across the design, development, use, and evaluation of AI systems. Its Generative AI Profile offers technology-specific risks and suggested actions. AI RMF 1.0 is under revision in 2026, so it should be used as a living risk-management reference, not misrepresented as a fixed certification requirement.

ETDA’s stated direction for 2026 also emphasises making AI governance usable through training and practical tools. That announcement should not be interpreted as proof that a new binding AI law has been enacted. Legal, contractual, privacy, employment, and sector requirements should be checked for the particular country and use case.

For an SME, minimum governance does not require a large committee. It does require seven accountable elements:

• Process owner: value, quality, and operation
• Final approver: production start, suspension, and restart
• Data classes: permitted, conditional, and prohibited inputs
• Human review: which outputs are checked and by whom
• Change control: versions of prompts, models, sources, and integrations
• Incident path: data exposure, misdelivery, material error, and abnormal cost
• Periodic review: continued value, quality, risk, and cost

Names and treatment must align with company policy. The practical objective is a short rule that users can apply and a named contact when they are unsure. A long policy does not work if employees cannot distinguish a consumer account from an enterprise-managed service.

Illustrative budget, TCO, and ROI worksheet—not a market benchmark

The following is a fully hypothetical planning example. Every amount, workload, volume, and benefit assumption is fictional. It is not a market rate, a TOMAS TECH quotation, a customer result, or a promised ROI. Replace it with measured company data and supplier quotations. THB is used only to demonstrate the calculation.

Assume a document-review workflow handles 1,000 cases per month. The current process takes 12 minutes per case; AI processing plus human review is assumed to take 8 minutes. The illustrative labour value is 350 THB per hour and there are 20 working days per month. The hypothetical system meets the acceptance criteria, and human review prevents critical errors from being released.

Under those assumptions, the simple payback is about 29.6 months: 180,000 ÷ approximately 6,083. This is not an investment conclusion. Lower volume, longer review, changing API prices, exchange rates, or extended training will alter the result. Faster customer response, avoided opportunity loss, or reduced rework may create additional benefit if the company can measure them consistently. Do not monetise vague benefits merely to make the case positive.

Include the full operating lifecycle in TCO

• Discovery, requirements, data preparation, and evaluation-set creation
• Subscription, API, cloud, storage, and connectivity
• Identity, permissions, audit logs, and security assessment
• Integration and regression testing after system changes
• User and administrator training and support
• Quality monitoring and management of prompts and retrieval sources
• Incident handling, fallback, and vendor replacement
• Data export, migration, and deletion verification at contract end

A useful ROI worksheet includes downside, base, and upside cases for volume, time saved, and recurring cost. A scale decision should test whether value survives under the same scope and measurement method after human review and operating cost are included.

Common failure patterns and recovery gates

1. Starting with a company-wide AI platform

If users and workflows are undefined, a broad licence may increase activity without producing measurable business outcomes. Recover by selecting one workflow and creating the baseline and evaluation set. Extend shared infrastructure after that workflow proves its needs for identity, logs, and data boundaries.

2. Buying from an easy demonstration

A demo confirms possibility, not production quality. Return to representative anonymised data, long and missing inputs, contradictions, multiple languages, and exceptions. If material errors cannot be caught, limit the system to drafting or reduce the scope.

3. Treating accuracy as the vendor’s responsibility alone

The company owns the business meaning of correct outcomes and exceptions. The process owner should own the evaluation criteria; the vendor supports technical improvement and testing. If employees disagree about the correct answer, align the process rule before tuning the AI.

4. Leaving human review as an unmeasured “temporary” step

Human review is a valid control, but it becomes a hidden bottleneck if no one measures who reviews how many cases and for how long. Include review effort in TCO. Simplify it gradually only for outputs with demonstrated, bounded risk.

5. Failing to evaluate production changes

Models, prompts, retrieval documents, APIs, and business rules change. Run a fixed regression set before and after changes. Retain the ability to revert when critical errors increase.

6. Omitting spending limits and exit design

Usage-based fees change as adoption grows. Put monthly limits, warnings, volume tiers, data export, and integration alternatives into the RFP. Stopping is not necessarily failure; it is the correct gate when the value hypothesis does not survive evidence.

Evidence checklist for scale, revision, or stop

At the end of the pilot, answer with evidence:

1. Did time, quality, or waiting improve against the same baseline scope?
2. Are critical errors within the defined limit, and can they be detected and stopped?
3. Is human review sustainable for the responsible team?
4. Were prohibited data, access, retention, and logs controlled?
5. Did the team return to the fallback during an outage or quality event?
6. Is TCO—including initial, recurring, usage, and internal work—within approval?
7. Can operation be transferred without dependence on one employee or vendor?
8. Can users and administrators explain both value and workload?
9. Can the next workflow provide its own data, evaluation, and accountable owner?
10. Can data and integration be closed safely if the company stops?

Passing quality with an unacceptable TCO is a stop or redesign. Saving time while failing to control a material error is not a scale decision. Even a smaller-than-expected benefit can reveal necessary data cleanup or process standardisation; that evidence should inform the next hypothesis rather than justify uncontrolled expansion.

FAQ: AI adoption for small and midsize businesses

Where should an SME start with generative AI?

Start with one daily or weekly workflow whose current time can be measured and whose output can be reviewed by a qualified employee. Policy search, record summarisation, or enquiry classification may be candidates, but assess them against your own data and risk. Define scope, exclusions, baseline, acceptance, and owner before comparing products.

Must an AI adoption roadmap last exactly 90 days?

No. Ninety days is a practical decision structure, not a law. Monthly or seasonal processes may need a longer observation period. The essential discipline is to separate problem definition, limited evaluation, and limited live use, with an evidence gate after each phase.

How much does generative AI adoption cost?

There is no single price. It depends on users, transactions, data, integration, security, evaluation, and support. Estimate TCO including data preparation, internal work, monitoring, training, changes, and exit—not only licences and development. The table in this guide is hypothetical and is not market pricing.

Can an SME run a PoC with a free generative AI service?

It may be possible for an early interaction test using public information. Before entering company data, review contractual entity, service terms, training use, retention, access, and logs. Security and administration capabilities may differ between consumer and enterprise-managed services.

What accuracy percentage is sufficient for adoption?

A single percentage is not enough. Decide by error type, impact, detectability, review, and volume. Separate a missing critical fact or misdelivery from a wording correction, and define acceptance for each business scenario.

Does a small company need AI governance?

Yes, but it does not need a large-enterprise committee. Name the process owner and approver; classify data; define human review, change records, incident reporting, and periodic review. Do not expand use while accountability remains empty.

Is build or outsource better for an SME?

Standard work may suit a configured service; differentiated work with sustained engineering capability may justify building; proprietary data and approvals often favour a combination. In every approach, business purpose, data approval, acceptance, and production start or stop remain company responsibilities.

Summary: design the day-90 decision before buying AI

AI adoption for SMEs is an operating change, not a tool purchase. Select one workflow through strategy, people, data, infrastructure, and governance readiness, then compare value, feasibility, and risk. Use days 0–30 for the baseline, 31–60 for limited evidence, and 61–90 for limited live operation. Scale only when quality, time, security, traceability, fallback, and TCO survive human review. Narrowing or stopping when the evidence fails is disciplined adoption, not defeat.

TOMAS TECH can help structure candidate workflows, data boundaries, evaluation sets, RFPs, 90-day pilots, and integration with existing systems. Even if you are still deciding which workflow should come first, you can contact us for a practical discussion.

Sources

• OECD — AI adoption by small and medium-sized enterprises
• World Bank — Thailand Digital Data Infrastructure Roadmap
• depa Thailand — AI Transformation field follow-up
• ETDA AIGC — AI Readiness Assessment
• ETDA — AI 2026: Driving Trust AI Governance
• NIST — AI Risk Management Framework
• World Bank — Thailand’s Digital Future Key to Boosting Growth

*This guide is based on public information checked on 30 August 2026 and provides general implementation guidance. Confirm current legal, contractual, privacy, employment, sector, and security requirements for the relevant jurisdiction and use case with qualified advisers.*