AI Business Case: How to Build One Malaysian Boards Approve
An AI business case is the document that turns a promising idea into a funded, governed project. It names one process, puts a financial value on fixing it, states the full cost of building and running the system, and shows how risk and compliance will be handled. For a Malaysian enterprise, it also has to show that the project can leave the pilot stage, which is where most of them stall.
This guide sets out how to write that case for a finance, manufacturing, logistics or insurance business in Malaysia. It covers the structure a board expects, how to separate hard savings from soft benefits, which costs are routinely left out, and where Malaysian regulation and funding change the numbers.
TL;DR
A strong AI business case is built around one high-volume process, not around “AI” as a theme. Start with the cost of the current process and the measurable change you expect.
Count hard financial benefits (cost per invoice, claim or document) separately from soft benefits such as employee experience. Boards fund the first and tolerate the second.
Budget for production, not just the pilot: data integration, monitoring, governance and ongoing operations are where cases fail.
In Malaysia, treat compliance as part of the case. Bank Negara Malaysia (BNM) guidance, the PDPA 2010 and the national AIGE guidelines all shape design and cost.
Check public funding early. MDEC grants and manufacturing incentives can change the payback period, but eligibility is narrow.
Table of Contents
Why most AI business cases fail before the budget meeting
The common failure is not a lack of enthusiasm. It is an ambiguous return. Everest Group notes that many enterprises stay conservative with AI spending because ROI expectations are unclear, even in a well-understood field like intelligent document processing. When the finance team cannot trace a benefit to a budget line, the proposal is deferred.
The second failure comes after approval. Malaysian commentary on scaling AI points out that many organisations run pilots but few convert them into enterprise-wide change. The usual cause is not model accuracy. It is the work of connecting messy operational data from several systems into one architecture, which a pilot can avoid and a live system cannot.
A business case that ignores either problem will be approved on optimism and then cost more than planned. One that addresses both is easier to approve and easier to defend a year later.
The market context your board will ask about
Boards want to know whether peers are moving. In banking, the evidence is strong. BNM’s discussion paper on AI in the financial sector reports that 71% of banking institutions and DFIs had implemented at least one AI application as of 2024, up from 56% a year earlier. The same paper indicates that more than 60% of institutions treat AI as a strategic priority for the next one to three years.
In manufacturing, the clearest local proof point is Agilent’s Penang smart factory. MIDA’s release on the site’s recognition as a World Economic Forum lighthouse describes a 40% productivity gain and a 48% cut in delivery lead times. Treat that as a ceiling set by a global leader with a long digital programme, not as a forecast for a first project. Your case should rest on your own baseline.
Peer adoption belongs in the opening page of the case as context. It should never be the argument. The argument is your own numbers.
Start with one process and its current cost
The most reliable AI business cases are narrow. They pick a process with high volume, repeated manual steps and a cost that finance already tracks. Everest Group’s view is that the difference between failure and success often lies in choosing a use case where automating manual tasks gives immediate, measurable relief to a high-volume process.
In the sectors we work with, the candidates are familiar:
Banking and insurance: onboarding documents, claims intake, underwriting submissions, KYC file review, contract and policy extraction.
Manufacturing: supplier invoices, quality certificates, work orders, maintenance logs and compliance paperwork.
Logistics: bills of lading, customs declarations, proof-of-delivery matching and freight invoices.
For each candidate, collect four figures before writing anything else: monthly volume, average handling time, fully loaded cost of the people involved, and the error or rework rate. A case built on these four numbers is already more credible than most. If you cannot get them, that is itself a finding: the process is not ready for automation, and the first investment is measurement.
If you need a method for ranking several candidates, our work on use-case prioritisation and value mapping sits within the strategy stage of our services. Our article on proving AI ROI in a 90-day test shows how to turn a ranked shortlist into a controlled trial.
Hard benefits, soft benefits and what to leave out
Separate benefits into three groups, and label them in the document.
Hard financial benefits
These are reductions you can find in the ledger: lower cost per invoice or claim, fewer overtime hours, reduced reliance on outsourced data entry, fewer penalties from late processing, lower rework. State the baseline, the expected change and the date you will measure it. Only these belong in the payback calculation.
Soft benefits
Faster onboarding, better employee experience and improved customer satisfaction are real. Everest Group explicitly distinguishes them from hard savings, and so should you. List them, assign an owner, and keep them out of the headline return. If the project only pays back with soft benefits included, the case is not strong enough.
Benefits to exclude
Do not count headcount reductions you do not intend to make. Do not count revenue uplift you cannot trace to a specific change in conversion or throughput. Do not count the same saving twice, once as time and once as cost. Finance reviewers look for these in the first five minutes.
The costs that decide the real payback
A pilot budget covers a model and a demo. A production budget covers much more. The AIBP analysis of Malaysian scale-up stresses that projects which do not plan for data interoperability from day one often stall after the proof of concept. Build the following lines into the cost side.
Data and platform work. Connecting source systems, cleaning data, and building the pipelines and storage the model depends on. This is frequently the largest line and the one most often underestimated.
Integration. The model has to write back into your core banking, ERP, claims or transport management system, with the right approvals and exception handling.
Deployment and monitoring. Models drift. Document formats change, suppliers change templates, customer language shifts. Someone has to monitor accuracy and retrain.
Governance and audit. Logging, explainability, access control and review workflows. In regulated sectors this is not optional overhead.
Change management. Staff need new procedures and clear rules on when to override the system. Our piece on AI change management covers what leaders must do here.
Run costs. Licences, cloud or on-premise compute, and the team that operates the system. Present these as an annual figure for at least three years, so the board sees total cost of ownership rather than a one-off project fee.
A worked example of the arithmetic
The following is an illustration with invented round numbers, not a client result or a benchmark. Suppose a Malaysian insurer processes 20,000 claim submissions a month. Each takes 25 minutes of manual data capture and checking, and the team’s loaded cost is RM40 an hour. The monthly handling cost is about RM333,000.
If automation handles 60% of submissions without human touch and cuts the remainder to 15 minutes, the monthly handling cost falls to roughly RM113,000. The hard saving is about RM220,000 a month, or RM2.6 million a year. Against that, put the build cost, integration, annual run cost, and a contingency. If the first-year total is RM2.0 million and annual run cost thereafter is RM0.8 million, payback falls inside the second year, and the net three-year benefit is clear.
Now stress the model. What if straight-through processing is 40% rather than 60%? What if volumes are 15% lower? A case that still pays back under the pessimistic assumptions is the one a board will sign. A case that only works at the optimistic end will be challenged, and rightly.
Risk, compliance and governance belong in the case
In Malaysia, governance is part of the business case, not an appendix. Three layers matter.
National guidance. MOSTI launched the National Guidelines on AI Governance and Ethics (AIGE) in September 2024. They provide a framework for safe, ethical and responsible AI, but responsibility for the outcome of a system still rests with the organisation deploying it. That means internal mechanisms for transparency and explainability must exist and be costed.
Sector regulators. For banks and insurers, BNM’s paper stresses that efficiency alone is not enough if a system lacks the audit trails and transparency sector authorities expect. It also treats regulatory sandboxes as a phase for aligning automated decision-making and profiling with the Personal Data Protection Act 2010, not only as a place to test ideas.
The legal outlook. Malaysia has no dedicated statute for algorithmic bias or profiling today. Legal commentary on AI and the law in Malaysia is a useful starting point for your counsel. Do not read the absence of a statute as permission: design for stricter rules, because adopting sector guidance early costs less than retrofitting a live system. Your legal and compliance team should review this section before it reaches the board.
A short risk register helps: model error, data leakage, vendor dependency, regulatory change and staff adoption, each with an owner and a control. It signals that the sponsor has thought about how the system fails, which is what approvers want to see.
Funding that can shorten the payback
Public support can improve the numbers, but only for companies that qualify. In July 2025, MDEC introduced two grants worth RM2.9 million in total: the Malaysia Digital Acceleration Grant for AI and the SmartMFG+ Incentive Programme. According to MDEC’s announcement, eligibility is limited to companies with Malaysia Digital or MSC Malaysia status, or a pending Malaysia Digital application.
That excludes many enterprises, and application windows have been short. Check current terms directly with MDEC before you include any grant in a financial model, and show the case both with and without funding. A project that depends on a grant you have not yet won is a weaker project.
How to structure the document
A board paper should be short enough to read before the meeting. A structure that works for most Malaysian enterprises runs in this order.
Decision requested. One sentence: the amount, the scope and the date.
Problem and baseline. The process, its volume, its cost and its error rate.
Proposed solution. What the system does, where it sits in existing systems, and where humans stay in the loop.
Benefits. Hard first, soft second, with owners and measurement dates.
Costs. Build, integrate, run, govern, three-year view.
Scenarios. Base, pessimistic and optimistic, with and without grants.
Risk and compliance. The register, plus the regulatory position.
Delivery plan. A staged path with a go or no-go gate after a time-boxed trial.
Ownership. Who is accountable for results after launch, not only during the build.
The last item matters more than it appears. Many cases name a project lead and nothing beyond go-live. Accountability that ends at delivery is how a system quietly degrades.
Our perspective: accountability is the business case
We see the same pattern across finance, manufacturing, logistics and insurance. Business cases are written by one team, the system is built by a second, and it is run by a third. Each handoff loses context, and the numbers in the case slowly stop matching the system in production.
Our view is that an AI business case is only as good as the continuity behind it. That is why we ask one senior team to own strategy, build and operation, and why we engineer for production from the first week: integration, governance, auditability and monitoring are designed in, not added after a successful demo. It also changes what we put in a case. We would rather show a modest, measured return that survives scrutiny than a large one that depends on the pilot’s conditions.
We also advise leaders to write the measurement plan before the build plan. If the board cannot see in month three whether the system is on track, the business case is a hope, not a plan.
— Thomas Samuel
Turning an approved case into a running system
Approval is the start of the hardest part. Our enterprise AI roadmap sets out how to move from pilots to governed production, and our enterprise AI strategy playbook covers the leadership decisions around it. For manufacturers, our article on Malaysian manufacturing AI pilots that scale looks at what separates a pilot that pays back from one that stalls, and our manufacturing industry page describes the systems we build for plants.
If you are preparing a case now, we can help at the stage where it is most useful: before the numbers are fixed. Our AI strategy and roadmap work tests use cases against value, and our readiness and data diligence review checks whether your data can support the process you have chosen. After approval, the same team can deliver and run the system through managed AI operations. Contact us through our services page to discuss the process you are considering.
FAQ
How long should an AI business case be?
For a board or investment committee, aim for five to eight pages with a one-page summary at the front. Put the financial model, data assessment and risk register in appendices. Reviewers decide on the summary, then test the appendices for weak assumptions.
What payback period should we expect?
It depends entirely on volume, baseline cost and integration effort, so no honest figure applies to every project. Narrow, high-volume document processes tend to pay back faster than broad transformation programmes. Build the case on your own baseline, and test it against a pessimistic scenario before presenting it.
Do we need a pilot before asking for full funding?
A time-boxed trial with agreed success measures is usually the safest route, because it replaces estimates with measured results. The trial must use real data and real systems, or its results will not carry over to production. Set the go or no-go criteria before it begins.
Does Malaysian regulation affect the business case?
Yes, mainly through cost and design. Banks and insurers should work from BNM’s guidance, and any system that handles personal data must respect the PDPA 2010. The AIGE guidelines apply as a national framework for responsible AI. Ask your compliance and legal teams to review the governance section before submission.
Who should own the business case?
The business owner of the process, not the technology team, should own it, with finance validating the numbers. Technology and compliance contribute cost and risk. Ownership should continue after launch, so someone is accountable for the benefits actually being realised.
Sources
Everest Group: Beyond Words, the True RoI of Intelligent Document Processing
AIBP: Scaling AI in Malaysia, from Pilot Projects to Strategic Transformation
Bank Negara Malaysia: Artificial Intelligence in the Financial Sector
MIDA: Agilent Puts Malaysia on the Global Map for Industry 4.0 Excellence
Malaysia.gov.my: National Guidelines on AI Governance and Ethics (AIGE)
Chloe Lim & KM Loke: Artificial Intelligence and the Law in Malaysia
MDEC: RM2.9 Million in Strategic Grants to Advance AI and Industrial Digitalisation
Recommended