AI readiness scorecard for growing Singapore companies

An AI readiness scorecard should support a decision about one workflow. Management needs to know whether to fund prerequisite work, authorize a controlled trial or permit a defined operating scope. A company-wide maturity label cannot establish whether a particular system can change a customer record reliably.

Bain Squared defines readiness here as the demonstrated ability to perform a bounded task, identify unacceptable results and recover from failure. Our assessment separates workflow definition, information quality, permissions, review capacity, economics and continuing ownership. A weakness in any one of those areas can prevent a launch even when the others appear strong.

This Squared Report sets out a firm-owned planning method informed by public technical and risk-management sources. It is not a validated predictive model, an industry benchmark, a certification or an original survey. The worked invoice-reminder example is fictional. Its purpose is to show how evidence and operating assumptions change the size of a commitment management can justify.

What should an AI readiness scorecard measure?

Assess the proposed workflow rather than the technology category. A useful unit of assessment has a trigger, defined inputs, an intended action and a completion condition. “Use AI in finance” is too broad. “Prepare an overdue-invoice reminder from approved records for a collector to review” is sufficiently specific to test.

Record the existing process and its limitations. The baseline should include the work currently required, the exceptions people handle and the consequences of an error. If management cannot describe how the task is performed today, the first investment may need to improve the process definition rather than introduce a new execution method.

Anthropic's 2024 distinction between workflows and agents provides a useful technical reference. Different patterns allocate different degrees of discretion to the model. The architecture selected should reflect the task's need for that discretion and the team's ability to evaluate the resulting behavior.

We retain six separate assessments because each can change the decision independently. Reliable data does not resolve an unclear approval policy. Clear permissions do not create reviewer capacity. An aggregate score can help organize a discussion, while the release decision must still identify and resolve each prerequisite.

Assess each prerequisite against recorded evidence

Score each area from zero to three. Zero means the relevant condition is unknown or absent. One means it is described but has not been demonstrated. Two means the team has tested it in a representative controlled setting. Three means the evidence remains current during a defined period of limited operation, with review and recovery arrangements in use. These are proposed evidence states, not external standards.

Each assessment requires a dated artifact that another reviewer can inspect. A process map establishes the intended sequence; a test result shows observed behavior; a permission configuration shows what the connection actually allows. The scorecard should distinguish these forms of evidence so a description is never mistaken for a demonstrated control.

The scorecard should show the six results separately. A total can be recorded for administrative comparison, but it must not authorize launch. An unknown permission boundary is a stop condition even if every other area is strong. The operator should be able to locate that gap without interpreting an aggregate score.

NIST's 2023 AI Risk Management Framework supplies the broader governance reference. The scorecard adapts risk-oriented thinking into a local decision record; it does not claim that its numerical labels are NIST's or that a completed worksheet demonstrates compliance.

Workflow definition and information quality

Workflow readiness asks whether the task is bounded and the completion condition can be observed. Record the trigger, permitted actions and situations that leave the normal path. Identify which decisions depend on judgment that the team has not yet expressed as an agreed policy. An unresolved business disagreement should remain visible rather than be embedded in a prompt.

Information readiness asks whether the workflow can access the right records with sufficient freshness and context. Identify the authoritative source for each required field. If a contract system and a customer relationship system disagree, specify which one governs the proposed action and who resolves the inconsistency. The model should not be expected to establish corporate policy from conflicting documents.

Test missing and outdated information deliberately. A controlled example should include an absent identifier, a duplicate record and a changed status where those conditions are relevant. The team should define whether the workflow stops, asks for clarification or uses a documented fallback. A confident completion based on guessed information should be treated as a distinct failure.

The evidence for these areas includes a process map, source register and a representative test set. At the described stage, those documents may exist without successful tests. At the tested stage, the record should show what happened when the inputs were incomplete or contradictory, including cases the workflow correctly declined to handle.

Permissions and human review

Permission readiness concerns what the system can read and change. List the tools available to the model and the rights each connection grants. A service account with broad access may be convenient for development while exceeding the approved operating scope. Assess the actual configured permissions rather than the intended limits described in a presentation.

Separate drafting, approval and execution where the consequences justify it. A person should know what they are approving, which records support the action and whether the proposed change differs from the approved policy. An approval button provides little protection if the reviewer cannot see the relevant evidence or if the action can change after approval.

Human-review readiness concerns capacity as well as authority. Record which cases reach a person, who receives them and what happens when the reviewer is unavailable. A workflow that sends every unusual case to a busy manager can create a growing queue while appearing successful on routine cases. Measure that queue and include it in the operating decision.

Anthropic's 2025 guidance on effective agent tools links tool design with evaluation. In this scorecard, useful evidence includes clear action descriptions, destination checks and a record of reviewer decisions. A person should be able to distinguish a completed action from an attempted one that may require investigation.

Economics and continuing ownership

Economic readiness requires a comparison on a consistent basis. Include model charges, software, integration support, review, correction and ongoing maintenance. Compare the same task volume and completion standard. A system that handles only the easiest cases should not be credited with replacing the full cost of the existing process.

Distinguish a capacity benefit from a cash benefit. Time released may allow employees to handle more work or improve service. It becomes a cash saving only when management changes an actual expenditure or avoids a cost it would otherwise incur. The business case should identify which outcome it assumes and who can make that operating decision.

Ownership readiness requires a process owner and a system owner with defined decision rights. Record who can change business rules, approve new permissions, update reference information and pause the workflow. A vendor may perform technical operation while the client retains authority over customer commitments and commercial policy.

NIST's 2024 Generative AI Profile is a further reference for evaluating risks around generative systems. The local scorecard should record review triggers such as a changed model, integration or use case. Previous evidence should be reconsidered when the conditions it tested no longer apply.

The invoice-reminder example separates capacity from cash

Consider a fictional service business preparing reminders for overdue invoices. The proposed system retrieves the invoice, checks recorded status, prepares a draft and places it in a collector's review queue. It cannot change the balance, alter payment details or send the message. Disputed invoices and conflicting customer records leave the normal path.

Assume, solely for this example, that the team handles 1,000 cases per month at six minutes per case. The current handling effort is 100 hours, calculated as 1,000 multiplied by six and divided by 60. At an assumed loaded labor cost of S$40 per hour, the modeled capacity cost is S$4,000 per month. These figures are hypothetical inputs, not observed results.

Suppose the supervised system reduces ordinary preparation and review to two minutes per case. That requires approximately 33.3 hours. Add eight minutes for each exception, an assumed S$300 of monthly software cost and 20 hours of monthly maintenance at the same assumed hourly cost. With a 10 percent exception rate, total effort becomes approximately 66.7 hours and modeled cost becomes approximately S$2,967.

The difference from the manual capacity cost is approximately S$1,033 per month. It is not automatically a cash saving because the employees may remain employed on the same terms. If setup costs an assumed S$6,000, dividing that setup cost by the modeled benefit gives approximately 5.8 months. That simple payback applies only if the capacity benefit is realized and the assumptions hold; it excludes financing and other costs not modeled.

Exception handling changes the economic conclusion

In this example, the exception rate is the most important operating sensitivity once volume and review time are fixed. At zero exceptions, modeled monthly cost is approximately S$2,433. At 10 percent it is approximately S$2,967, and at 20 percent approximately S$3,500. These are calculations from the stated inputs, with no change in the definition of a completed case.

At an exception rate of approximately 29.4 percent, the modeled monthly cost equals the manual capacity cost. At 40 percent, cost is approximately S$4,567. The companion worksheet exposes these assumptions so a team can replace them with its own observed values. The equality point is a feature of this example, not a general threshold for AI projects.

Other uncertainties can change the result more abruptly. If the underlying records are wrong, better preparation speed may increase the number of drafts requiring correction. If the reviewer checks less carefully because the output looks polished, the measured handling time may improve while the consequence of an error rises. Neither effect is resolved by a lower model price.

For this illustrative workflow, we recommend a controlled trial with a defined review period and spending limit. Compare completed work with the manual baseline and record review time, exceptions and incorrect proposed actions separately. Management should set stop conditions before the trial so the approval does not depend on how promising the demonstration feels at the end.

A stop condition overrides the score

Do not permit external execution when the system's authority is unclear. Do not continue an action path when the team cannot establish whether a previous attempt succeeded. Do not expand the scope while a material failure lacks an owner. These are proposed operating stops that apply independently of the numerical assessment.

Choose among prerequisite work, a supervised trial and limited operation. Prerequisite work is appropriate when a necessary data, policy or access question remains unresolved. A supervised trial is appropriate when the task is defined and the team can test behavior without granting broader authority. Limited operation requires evidence for the actual scope and a workable response when conditions change.

Record the approved task and operating mode in a short decision memorandum. Attach the evidence reviewed and state the limitations that remain. The budget, responsible owner and next review condition should be explicit. Where broader authority was considered, record the reason it was deferred so the next reviewer can identify what evidence would change that decision.

The agentic AI launch checklist provides a companion record for permissions, failures and release approval. The ownership article explains the continuing management roles. Use those records with the scorecard so that the assessment leads to an operating decision rather than an isolated workshop output.

What the scorecard cannot establish

The method cannot establish regulatory compliance, security assurance or suitability for every kind of data and decision. Sector-specific obligations and high-consequence uses require specialist assessment. A completed worksheet should identify those dependencies rather than imply that an internal score replaces them.

The evidence states do not predict a future failure rate. A controlled test samples a defined set of conditions. New customers, changed records, model updates or different workloads can expose behavior the test did not include. The operating record needs a way to detect that change and reopen the relevant assessment.

The economic example also omits factors that may dominate a real business case. These include the value of faster service, the cost of a serious error, contractual commitments and the opportunity cost of the team's attention. Add those factors where they are decision-relevant and support them with evidence instead of treating the simple calculation as a complete investment model.

The scorecard should leave management with a commitment it can explain and review. Assess one workflow, attach current evidence and identify the condition for the next release decision. Where a prerequisite is unresolved, fund the work needed to resolve it before expanding the scope. The method is useful when it narrows uncertainty around that decision; a higher score alone is insufficient.