AI Readiness Checklist for Malaysian SMEs: Fix the Workflow Before the Model

You want your business to “do something with AI,” but every demo looks convincing and nobody can tell you whether your own team is ready. If you own a Malaysian business with 10–100 staff, these six questions will help you decide—in about 10 minutes—whether to test one small AI use case or fix the work around it first.

You do not need a perfect database, an AI department or a long strategy document. You need one useful job, real examples, a way to judge the result and a person who will remain responsible.

AI readiness is less about buying the newest model and more about whether your business can run one controlled test.

First, choose one job—not “AI for the company”

Set a timer for 10 minutes and think about one recurring piece of work. It might be sorting customer enquiries, extracting details from supplier documents, preparing a first draft of a quotation, summarising service notes or checking whether a form is complete.

Do not assess the whole company at once. “Use AI in sales” is too broad. “Prepare a first draft reply to common product enquiries for a salesperson to review” is specific enough to discuss.

If you are not sure whether the pressure calls for another employee, better software or both, start with the earlier reader-path guide: Should You Automate Before You Hire?. That decision comes before choosing an AI tool.

Now answer the following questions with yes, partly or not yet. There is no score. One important “not yet” can matter more than five easy yeses.

1. Can you name the job and the person who owns the result?

Finish this sentence:

We want to improve [one recurring job] for [one group of staff], and [one named role] is responsible for the result.

If you cannot finish it without using phrases such as “improve efficiency” or “use AI,” the opportunity is still too vague. Spend time observing the work instead of comparing models.

The owner does not have to be a technical person. It should be someone who understands why the job matters and can decide what a useful result looks like. For a quotation-drafting test, that might be the sales manager. For extracting invoice details, it might be the finance manager.

Also ask how often the job occurs and why it is worth improving. A frequent task that delays customers or creates repeated rework is usually a better first test than a rare decision with serious consequences.

If your answer is “not yet”: name the job, the users and the business owner before speaking to vendors.

2. Can staff explain how the work happens today?

Ask one person who does the work to walk through a recent case from beginning to end. Where did it start? Which messages, documents or systems did they use? Where did they wait? What made the case unusual? What showed that the work was finished?

You are looking for a repeatable path, not a beautiful flowchart. If every employee describes a different process, adding AI may make the disagreement faster without making the outcome better.

Pay attention to workarounds. Staff may copy information from email into a spreadsheet, ask a manager in WhatsApp, or check an old document because the official instructions are incomplete. These details are part of the real job. A test designed around the ideal process will fail when it meets ordinary work.

Some steps may not need AI at all. A fixed rule, a form with required fields or a connection between two existing systems may solve the problem more reliably.

If your answer is “partly”: follow three to five real cases and agree on the normal path, common exceptions and finish point.

3. Do you have real examples—and permission to use them?

A useful test needs examples of the work you actually receive: ordinary cases, incomplete ones, unusual wording and examples where staff had to ask for help. Ten or twenty well-chosen cases can teach you more than a polished demonstration created by a vendor.

Check where the information comes from and whether it is still accurate. If a customer-answering assistant relies on product information, somebody must know which price list, policy or catalogue is current. If two documents disagree, the team needs a rule for which one wins.

Then consider what the examples contain. Customer messages, employee records, health information, bank details and contracts may require tighter handling than public product descriptions. Before putting real business data into an external service, check what the provider retains, who can access it, whether it may be used for training, how it can be deleted and what your own obligations require. Malaysia’s Personal Data Protection Department publishes the official text of the Personal Data Protection Act 2010 as a starting point; obtain advice appropriate to your situation.

If your answer is “not yet”: collect controlled examples, remove information you do not need and confirm which data may be used before testing.

4. Can a person tell a good answer from a bad one?

An impressive answer is not the same as a correct one. Choose five to ten examples and ask the business owner to write down what the result must contain, what it must not claim and which mistakes would make it unusable.

For document extraction, the check may be whether required fields match a verified record. For a quotation draft, it may include the correct items, prices, terms and missing-information warnings. For enquiry sorting, it may be whether each message reaches the correct team and urgent cases are not missed.

Avoid judging a test from two memorable examples. Use the same cases and rules when comparing approaches. Keep a few cases aside so that later changes are tested on material the setup was not built around.

If your answer is “not yet”: define a small set of test cases and clear review rules before paying for a larger pilot.

5. What happens when the answer is wrong or uncertain?

Start with the consequence, not the cleverness of the technology.

If a draft contains a weak sentence, an authorised employee can correct it before sending. If a system could promise a customer the wrong price, approve a payment, make an employment decision or change an important record, the consequence is higher and the safeguards must be stronger.

For a first test, keep the AI’s role narrow. It can prepare, suggest, sort or highlight while a person remains responsible for consequential decisions. The reviewer should be able to see the original evidence, correct the result and stop the next action. Unclear, unusual or sensitive cases should go to a named person rather than disappearing into an error message.

This does not mean every output must be checked forever. It means you reduce review only after real results show which cases are dependable and which still need judgement.

If your answer is “we have not discussed it”: write down what the system may do, what always needs approval and who handles uncertain cases.

For your IT person

Keep the first test separate from live customer or financial actions. Use approved accounts and the least access the job needs. Record the source used, tool or model version, result, reviewer correction and final outcome so changes can be compared. Treat email, documents and web content as untrusted input that cannot override business rules. Protect credentials and personal data from prompts, logs and error messages. Add clear timeouts and a visible failure queue rather than silently retrying forever. Make it possible to switch the test off, revoke access and export the review history. Test ordinary, incomplete, misleading and sensitive examples before connecting the tool to daily work.

6. Who will own the test after the demo?

Many AI experiments fade because the person who built the demonstration leaves and nobody owns the daily work. Before starting, name who will:

• answer staff questions;
• review failures and corrections;
• approve changes to instructions, models or data sources;
• watch usage and ongoing cost; and
• decide whether to continue, change direction or stop.

Choose a review date and the evidence you will use. Useful measures depend on the job: handling time, missing information, correction rate, customer response time, staff rework or cost per completed case. “People tried it” is activity, not proof that it helped.

The test should sit close enough to the real workflow that staff can judge it, but with limits that make mistakes recoverable. If employees must continue every old step and also operate the new tool, the test may create more work than it removes.

If your answer is “the vendor will handle it”: name an internal business owner as well. A supplier can support the technology, but your company still owns the result and the decision to keep using it.

What your answers mean

You do not need to turn the answers into a percentage.

• Mostly yes: you may be ready to define a small pilot around that one job. Confirm the limits, test cases, human review and decision date in writing.
• The job or workflow is unclear: map the work first. Ordinary software or a simpler process change may be the better answer.
• The examples or data rights are unclear: do not use live records yet. Build a controlled sample and settle access, privacy and source ownership.
• Nobody can judge the result: choose a more checkable first use case or define the review rules before implementation.
• The consequence is high and errors are hard to reverse: keep the tool in an assistive role, involve the right specialist, or choose a safer first test.
• Nobody owns daily operation: pause until a business owner and review date are agreed.

These are not failures. They tell you what to fix before spending more money.

The next useful decision

If the six answers are clear, write a one-page brief for one controlled test: the job, users, owner, examples, expected result, limits, review method and continue-or-stop date. That is enough to have a useful conversation with a software provider or consultant.

Do not choose a product merely because it gave the best live demo. Once you understand the work, use the next reader-path guide—Do You Need a Ready-Made Tool, Custom Software, or an AI Agent?—to compare implementation options.

The best first AI project is not the most ambitious. It is the one your team can explain, test, supervise and stop if it does not help.

Sources checked

• NIST: AI Risk Management Framework — voluntary risk-management context across AI design, development, use and evaluation.
• NIST AI RMF Playbook — suggested actions organised under Govern, Map, Measure and Manage; the Playbook states that it is not a mandatory checklist.
• NIST AI 600-1: Generative Artificial Intelligence Profile — generative-AI risk and action profile.
• OWASP: Top 10 for LLM Applications — application-security reference for technical review.
• Personal Data Protection Department: Personal Data Protection Act 2010 (Act 709) — official Malaysian reference point for personal-data obligations.
• Dreamcode: Should You Automate Before You Hire? — the preceding reader-path article for deciding whether business pressure calls for hiring, automation or both.
• Dreamcode: How to Scope the First Version of an AI or Automation Project — guidance for limiting a first release to one useful workflow.
• Dreamcode: Do You Need a Ready-Made Tool, Custom Software, or an AI Agent? — the following reader-path article for choosing an implementation approach.

Evidence checked on 12 October 2026. Provider capabilities, policies, legal requirements and official guidance can change; verify the current position and actual implementation context before acting.