Practice 01 · AI governance
At the moment an AI output influences a customer, a regulated workflow or a material decision:
Is this use authorised now, and can you evidence the decision?
Most institutions cannot answer that question for the systems they already run. The policy is signed, the inventory is current, the model passed its tests, and the live use has still moved outside the conditions the institution approved. We build the operating layer that closes that gap.
Why approved AI drifts out of control
Governance effort tends to attach to the model, while risk attaches to the use. The same model can be low-impact in one deployment and material in another, because risk moves with purpose, audience, data, autonomy and consequence. Approval decays for the same reason. An assessment made at a point in time does not survive a model substitution, a new data source, a wider user group or a change in decision context.
Monitoring is often represented as control, but a log produced after external effect is evidence of what happened, not a control over whether it should happen. And human oversight is frequently stated rather than engineered: a reviewer without timely evidence, capacity, authority and a defined safe state does not constitute an effective control, whatever the policy says.
The control point · enforceable before external effect
The minimum operating model
Every governance engagement installs the same four elements around each consequential AI use.
A bounded 90-day implementation path
Days 0–30Define
Select one consequential use. Name business, risk and technical owners. Define authorised and prohibited purposes, scope, risk limits and the pre-release or pre-execution control point. The phase produces an approved authorised-use baseline, mapped decision rights, an initial control set and success criteria.
Days 31–60Instrument
Bind events to the use case and baseline version. Configure identity, data, model and purpose checks. Calibrate outcomes, human review and safe-state behaviour. The phase produces resolved test events, a working reviewer workflow, failure-mode results and the initial evidence chain.
Days 61–90Operate
Run live or near-live activity. Assess exception volume, contextual drift, control performance and risk translation. Decide whether to scale, remediate or suspend. The phase produces an evidence pack, a risk-appetite view, accountable exception decisions and a scale recommendation.
What the engagement covers
The work runs from board mandate and policy architecture through risk and impact assessment, model testing and evaluation, guardrail design, and oversight of systems in production. It spans custom-built models, hyperscaler platforms and foundation-model providers, and the controls that hold each to its authorised purpose. Where you need it, we lead the governance function on an interim basis while your own capability matures.
Engagements are benchmarked to ISO/IEC 42001, the NIST AI Risk Management Framework, Bank Negara Malaysia’s RMiT, national AI guidance under the NAIO, and the Personal Data Protection Act 2010 as amended. The sector context is not theoretical: the 2026 AICB–Ecosystm benchmark, AI in Practice, reports that 44 per cent of Malaysian banks and DFIs remain at a developing stage of AI readiness, only 33 per cent have structured AI governance and model risk management in place, and 27 per cent apply formal AI risk tiering. The gap between adoption and operational control is where this practice works.
Programmes and briefings
The practice runs closed executive briefings for boards, risk committees and control owners, and practitioner programmes for the teams that govern AI day to day, covering risk and impact assessment, evaluation, guardrail design and production oversight. Programmes are delivered in-house or online and are assessed on whether participants can do the work afterwards. Request the executive briefing or ask for the current programme outline.