3 Things AI: The “Test the Decision, Not the Demo” Edition

1. Put a price on the risk before choosing a tool

A manager has three AI proposals on the table: meeting summaries, invoice matching and customer refunds. All three can produce an impressive demo. They should not receive the same review, because a missed action item is different from a duplicate payment or an incorrect refund.

The UK Department for Science, Innovation and Technology published an AI Risk Management Toolkit on September 8. It organizes the work around identifying risks, setting risk appetite, estimating likelihood and impact, choosing treatments and keeping a central risk log. The useful development is not another list of AI dangers. It is a workbook-shaped way to connect a risk to a decision.

The benefit is proportionate effort. A low-impact drafting aid can move quickly, while a tool that changes money, access or customer records gets deeper testing and a named approver. The tradeoff is that scoring can create false precision. Calling a risk “three out of five” does not make the evidence underneath it strong.

For one proposed use, write down the harm that would make you pause, the person affected, the existing fallback and the maximum loss or delay you can accept. Then name one measure you can observe during a two-week test. That is enough for a first risk entry; a giant register is not.

The toolkit is UK government guidance, not a Canadian legal test or proof that a particular score is correct. It is most useful as a prompt for disciplined judgment, with qualified advice where the consequence demands it.

2. Treat energy as an input, not a footnote

A facilities lead is asked to support an AI project that promises lower energy bills. At the same time, the project needs new computing capacity. If the team measures only the model’s recommendation and not the electricity used to produce it, the business case can quietly argue with itself.

The UK Department for Energy Security and Net Zero opened a call for evidence on an AI-enabled clean energy system on September 8. It is asking industry, researchers, system operators and regulators for evidence about opportunities, risks, barriers and longer-term effects. The signal for a smaller business is simple: “AI for energy” contains two questions—what the system may optimize and what the system itself consumes.

The benefit is a more honest comparison. A scheduling model might shift flexible work away from an expensive peak period or help a building operator spot waste sooner. The tradeoff is measurement overhead and uncertain attribution. Weather, production volume, tariffs and equipment changes can move the same bill, so a before-and-after chart may credit the AI for work done by the season.

Choose one energy-related decision, such as when to run a non-urgent batch. Record the current rule, kilowatt-hours, demand charge where relevant, output volume and operator overrides for four weeks. Test a recommendation without automating the switch, then compare like-for-like periods.

The consultation describes an emerging policy view, not a proven return for any product or Canadian facility. Local rates, grid conditions, equipment and data quality can change both the opportunity and the result.

3. Map one real change before mapping everything

A developer is asked to change a customer-status rule in an old application. The code edit is easy. The awkward part is discovering that the same status drives an invoice, a service email and a spreadsheet used every Friday by operations.

Intellect Design Arena announced MSOCK on September 8, describing a connected representation of business rules, processes, applications, APIs and code. The company says the system is intended to show dependencies and the likely effects of a proposed software change before code is modified. That launch is a useful reminder even if you never buy the product: faster code generation increases the value of knowing what the code touches.

The benefit is a smaller surprise radius. A team can review affected people, systems and controls before an AI coding tool proposes a change. The tradeoff is freshness. A beautiful map becomes misleading when integrations, manual workarounds or owners change without the map changing too.

Pick one change completed in the last month. Trace it from the business reason to the rule, data, application, downstream handoff and person who confirms success. Mark every place where the answer came from memory instead of a maintained record. That one trace will tell you whether a broader mapping effort would solve a real problem.

This is a vendor announcement, not independent evidence that the product can find every dependency or shorten a transformation. Its claims should be tested against a change whose downstream effects your team already knows.

The bigger pattern

The practical unit of AI adoption is not the demonstration; it is the decision around it. Risk appetite says what cannot be casually lost. Energy measurement reveals whether an efficiency claim is complete. Dependency tracing shows what a quick change could disturb. None removes judgment, but each gives a small team a concrete place to test it.

Which AI decision in your business would improve most if you measured one hidden input before approving it?