OJK AI Governance for Banks: What It Means for Model Testing and Change Control
A practical interpretation of Indonesia’s AI-governance direction for banking teams managing AI development, testing and model or workflow changes.
QUICK ANSWER
Indonesia’s Financial Services Authority (OJK) has issued Artificial Intelligence Governance for Indonesian Banks as a minimum benchmark for responsible AI development and implementation in the banking sector. OJK explicitly frames AI as dynamic and evolving, which makes risk management, prudence and the ability to respond to change central concerns.
For model and workflow teams, the practical implication is straightforward: AI evidence should remain tied to the version, use case and operating context being assessed. When a model, feature, prompt, threshold, data source or workflow changes materially, institutions should determine whether prior evidence still applies and what additional testing is needed before further progression.
WHAT OJK HAS ACTUALLY PUBLISHED
OJK launched Artificial Intelligence Governance for Indonesian Banks on 29 April 2025. OJK describes the guidance as supporting responsible AI development and implementation and as complementing existing digital-transformation, technology, cybersecurity, digital-maturity and resilience frameworks.
OJK also states that the guidance is intended as a minimum benchmark for the banking sector and recognises that AI technology will continue to face dynamic developments and challenges.
That does not mean this article can reduce OJK’s guidance to one simple testing checklist. The useful commercial and operational lesson is narrower: change and risk need to be managed deliberately rather than treated as one-time approval events.
WHY CHANGE CONTROL IS CENTRAL TO AI GOVERNANCE
A bank can keep the same product name while materially changing the AI behaviour underneath it. Examples include:
- replacing the model version;
- adding a new feature or signal;
- changing the prompt or retrieval source;
- modifying a threshold or rule;
- moving output into a different workflow;
- changing the level of automation or customer impact;
- switching a third-party AI provider;
- expanding into a new product or customer segment.
Each of these can affect the meaning of earlier evidence.
A useful control process therefore needs to answer three questions: What changed? Which previous assumptions or tests are affected? What evidence is required before the next stage?
MODEL TESTING SHOULD FOLLOW THE USE CASE
A technically sound model can still be unsuitable for the workflow in which it will operate. A fraud score may improve ranking but create too many alerts. A new feature may be predictive but unavailable at the intended decision time. A model may perform well overall while behaving poorly in a critical subgroup.
This is why evaluation should connect model behaviour to the actual operating context.
For one proposed change, a bounded evaluation can define:
1. the current baseline;
2. the exact candidate change;
3. the historical population and evidence window;
4. timing and data-availability assumptions;
5. the primary decision metric;
6. operational and policy guardrails;
7. uncertainty and limitations;
8. the owner of the next decision.
This does not replace formal bank governance. It makes the evidence behind one change easier to review.
TESTING A MODEL IS NOT THE SAME AS APPROVING A WORKFLOW
Banks should distinguish among at least three layers.
Model evidence asks how the model performs and what its limitations are.
Workflow evidence asks how one proposed model or rule change affects the real operational process under declared constraints.
Production approval considers a broader set of security, technology, policy, monitoring, operational-support and accountability questions.
A positive result at one layer should not be represented as authority for the next.
WHEN SHOULD PRIOR EVIDENCE BE REVISITED?
Prior evidence may need to be reassessed when a change affects behaviour, data, risk or reliance materially.
Examples include a new model build, new training data, changed threshold, changed feature availability, modified prompt, new external dependency, new workflow placement or movement from analyst support toward automated customer action.
The response can be proportionate. Some changes may require targeted checks. Others may justify a broader revalidation or approval cycle according to bank policy and applicable regulation.
WHY VERSION AND PROVENANCE MATTER
A result that says only “Model X passed” is weak evidence if later reviewers cannot identify which model version, configuration, data window and test protocol were used.
Version-bound evidence helps teams determine whether a result still applies after change. It also makes disagreements easier to resolve because the decision record identifies what was actually tested.
For third-party AI, provenance may be more difficult. Banks may need notification rights, contractual controls, behavioural monitoring or compensating tests when provider-side changes are not fully visible.
WHAT THIS MEANS FOR FRAUD AND RISK WORKFLOWS
Fraud and risk teams often operate under constraints that are invisible in generic model benchmarks: limited investigation capacity, delayed outcomes, rapidly changing typologies, customer-friction limits and real-time latency.
For that reason, a useful comparison can hold operational constraints fixed. If a new fraud model is intended to improve prioritisation, compare it with the current baseline at the same declared review capacity rather than allowing the candidate to consume more review resources.
That produces evidence closer to the decision the institution actually faces.
HOW AEGI FRAMES THE PROBLEM
AEGI Shield is designed around a bounded change decision. One fraud or risk workflow remains the reference context, the existing process remains the baseline, one candidate is defined, and approved historical evidence is used to assess whether the change deserves the next controlled stage.
The output can support Continue, Refine or Stop. It does not replace OJK interpretation, the bank’s model-risk process, security review or production-change authority.
AEGI’s method should therefore be understood as a possible evidence mechanism inside institution-owned governance, not as a claim of regulatory compliance.
FREQUENTLY ASKED QUESTIONS
Does OJK require AEGI’s method?
No. OJK does not endorse AEGI. The cited guidance provides banking-sector AI-governance direction; AEGI’s Controlled Evaluation is a separate commercial approach.
Does every AI model change require full revalidation?
Not necessarily. Banks should assess materiality and apply their own policies and applicable requirements. Some changes may justify targeted testing while others require broader validation.
Can workflow changes matter even when the model is unchanged?
Yes. Thresholds, rules, workflow placement and authority levels can materially alter operational and customer impact.
Why use historical replay before production?
Where historical evidence can answer the question, replay can compare a candidate with the baseline without granting it customer-impacting authority. It is an evidence stage, not production proof.
CONCLUSION
OJK’s AI-governance direction reinforces a durable principle: AI risk management must remain responsive to changing models, systems and use contexts. For individual change decisions, that means keeping evidence bound to the candidate, workflow, data and constraints that were actually evaluated.
NEXT STEP
If a bank or financial institution is considering one fraud or risk workflow change, AEGI can first assess whether the baseline, candidate and historical evidence path are sufficiently bounded for a Controlled Evaluation.
CLAIM BOUNDARY
This article is educational and is not Indonesian legal, regulatory, compliance or model-risk advice. OJK materials should be interpreted directly by the relevant institution and advisers. References to OJK do not imply endorsement or certification of AEGI.
SOURCES
[1] OJK, Artificial Intelligence Governance for Indonesian Banks, 29 April 2025: