Malaysia AI market, policy & data
AI Procurement in Malaysia: A Tender Spec Framework That Avoids Black-Box Lock-In
· By AIHQ Team
Why the AI tender document decides more than the vendor does
An HR director at a Malaysian GLC sits on an evaluation panel for an AI capability programme. The specification she is handed names one platform, bundles training into a licence count, and scores vendors on "innovation" without saying how it will be measured. Two years later the organisation owns a tool it cannot audit, a training log nobody reports on, and no contractual way to move to a cheaper model.
The tender document, not the vendor pitch, is where that outcome gets fixed. For HR and L&D leaders — who increasingly co-own AI procurement because training, adoption and governance sit in their remit — the practical question is which clauses to write before the market responds.
Head-to-head: tool-anchored spec vs capability spec
The comparison below is the core of this framework. The left column is what most inherited templates look like. The right column is what you want to publish.
| Criterion | Tool-anchored spec (high lock-in risk) | Capability spec (low lock-in risk) |
|---|---|---|
| Scope statement | Names a product, tier or seat count | Names the workflow, role group and outcome |
| Model reference | Specifies one model or provider | Model- and tool-agnostic; behaviour described, not brand |
| Data residency | Silent, or "vendor standard practice" | Explicit hosting location, retention period, deletion rights |
| Evaluation criteria | Weighted on features and demo quality | Weighted on capability transfer, acceptance tests, governance |
| Proof of concept | Treated as the contract itself | Time-boxed milestone with pass/fail gates before scaling |
| Pricing structure | Per-seat, all-in, opaque | Separated: capability building, implementation, licence, support |
| Exit and portability | Not addressed | Data export, prompt/prompt-library ownership, wind-down period |
| Training outcomes | Attendance counted | Role-based competency checks with named owners and dates |
Who should pick what
Pick a capability spec if you are an agency, GLC or enterprise buying anything that touches employee workflows, internal documents or confidential data, and if you expect the organisation to still be using AI in three years with a different vendor set.
A lighter, tool-specific spec is defensible if you are buying a narrow, replaceable utility — a short pilot with one department, a fixed 8-week engagement, or a commodity seat for a defined team — where switching cost is genuinely low. Even then, keep the data-residency and exit clauses in.
The seven clauses that trap buyers
1. The scope clause written as a product name
"Provision of ChatGPT Enterprise training for 200 staff" reads clean but pre-selects the answer. Rewrite it around the work: summarisation of policy documents, drafting support for HR communications, quality-checked reporting. Add a line stating that equivalent tools may be proposed and will be evaluated on behaviour. This is also where you connect training to real roles rather than generic exposure, as covered in AIHQ enterprise AI training.
2. The model-agnostic clause that is not actually agnostic
A spec that says "vendor must describe their LLM" is not model-agnostic; it invites a brand name and a lock. Instead require: a description of the model class and limitations, the ability to swap models without re-procurement, and a written statement of what happens to prompts, uploaded files and fine-tuned assets if the provider changes. Malaysia's local model discussions matter here — see Malaysia GPT local AI models.
3. The silent data-residency clause
Say where data is processed and stored, the retention period, deletion rights on exit, and whether staff data or candidate data (common in HR use cases) can be excluded entirely. Require a named accountable role for data handling. Do not accept "we comply with PDPA" as a clause — ask for the control, not the slogan.
4. The unevaluated evaluation criteria
Publish the weighting in the tender itself. A workable split for a capability-plus-training programme: 30% demonstrated capability transfer, 25% workflow fit and use-case realism, 20% governance and data protection, 15% price, 10% local support and references. Score against written rubrics, not demo impressions. The ChatGPT Malaysia partner comparison is useful context on what local support actually changes.
5. The PoC with no gates
Write milestones with dates, owners and pass/fail criteria. A realistic sequence for a mid-sized rollout:
- Weeks 1–2 — HR/L&D defines role groups and baseline metrics; procurement confirms contract schedule.
- Weeks 3–6 — Vendor runs two role-based workshops; L&D observes and scores application on real tasks.
- Week 7 — Gate review: at least 60% of participants complete a role-specific task unaided. Owner: HR.
- Weeks 8–12 — Department pilot with governance rules live; IT and risk confirm data handling.
- Week 13 — Go/no-go on scale-up, with pricing for the next phase already on the table.
6. The bundled pricing clause
Ask for capability building, implementation, licence and support priced separately. Bundled per-seat pricing hides the fact that you may not need the licence tier you are being sold, and it makes exit expensive because nobody knows what the training alone cost.
7. The missing exit clause
Require: full export of organisational data in a usable format, ownership of any prompt libraries, SOP content or knowledge base built during the engagement, a 90-day wind-down, and a transition-support obligation. If the vendor builds a custom AI chatbot or internal copilot on your content, the content and its structure must remain yours.
Where HR and L&D should hold the pen
Three sections of any AI tender belong to the people function, because they are capability questions disguised as procurement questions.
The capability baseline. Specify who will be trained, in which roles, at what level, and what a competent output looks like. Attendance is not a metric; a role-based assessment is.
The adoption and measurement clause. State how usage will be reviewed — quarterly, with named owners — and what counts as progress. Training outcomes vary by role, adoption and measurement approach, so the spec should define the review rhythm rather than promise a number.
The governance clause. Require that responsible-use rules, escalation paths and human review requirements are documented and communicated before go-live, not after. A responsible AI training component is a reasonable line item.
Funding is the fourth consideration. AIHQ is a registered HRD Corp training provider, and programmes can be structured to be HRDC claimable, subject to client eligibility, grant approval and HRD Corp submission requirements. Write claimability into the tender as a structured deliverable requirement rather than an assumption, and confirm current government AI procurement guidelines obligations with your own procurement and legal teams before publication.
What a strong tender pack contains
Before you publish, check that the pack includes: a workflow-and-role scope statement; a model-agnostic clause with a change-of-provider position; data residency, retention and deletion terms; a published scoring rubric with weights; a PoC schedule with gates, dates and owners; separated pricing; and an exit clause covering data, IP and transition. Seven documents, roughly two weeks of drafting, and it changes the shape of every bid you receive.
FAQ
Can we still name a preferred platform? You can state a reference platform for comparison, but the evaluation rubric must allow equivalents. Naming a platform as mandatory is what converts a tender into a formality.
How detailed should the data residency clause be? Enough that a bidder cannot answer with a policy link. Name the storage location, retention period, deletion mechanism and the accountable role.
What if the vendor refuses the exit clause? Treat it as a scored weakness rather than an automatic disqualification, but weight it heavily for anything involving employee or citizen data.
How long should an AI PoC run? Eight to twelve weeks for a role-based pilot. Longer PoCs tend to mean the scope was never defined.
Does a capability spec slow procurement down? It often speeds it up, because bidders price against a defined scope instead of guessing.
FAQ
Can we still name a preferred AI platform in a Malaysian tender?
You can cite a reference platform for comparison, but the evaluation rubric should allow equivalents. Making one platform mandatory is what turns a tender into a formality and recreates lock-in.
How detailed should the data residency clause be?
Detailed enough that a bidder cannot answer with a policy link. Specify storage location, retention period, deletion mechanism and the accountable internal role.
What if a vendor refuses the exit and portability clause?
Record it as a scored weakness rather than an automatic disqualification, but weight it heavily wherever employee, candidate or citizen data is involved.
How long should an AI proof of concept run?
Eight to twelve weeks for a role-based pilot, with a gate review around week seven and a scaled pricing schedule already tabled before the go/no-go decision.
Does a capability-based spec slow procurement down?
Usually the opposite. Bidders price against a defined scope instead of guessing, which reduces clarification rounds and post-award variation claims.