How AI Assesses Risk for Change Requests – Cutting CAB Preparation Time by 70%

In most enterprise organizations in Vietnam - especially in the BFSI sector - Change Management processes have already been standardized for years. There is a dedicated Change Management function. The Change Advisory Board (CAB) meets on a fixed weekly schedule. Change request forms are complete. Multi-level approval workflows are in place.

Before each CAB meeting, the Change Management team has already prepared documents, collected impact assessments, and looked up similar changes from the past. The CAB meeting runs on information that has been prepared in advance.

However, one major problem still exists: the process of preparing information before CAB consumes a lot of time, and the quality of that information depends heavily on data being scattered across many different tools.

This article analyzes that real-world problem and explains how AI can address it -- helping the Change Management team prepare information faster, more completely, and more accurately.

The Real Problem: CAB Preparation Is an Invisible Burden

In a typical BFSI organization with 30-50 change requests per week, the Change Management team must perform the following tasks for each request, before it goes to CAB:

Total preparation time for 1 change request: 70-110 minutes.

With 30-50 change requests per week, the Change Management team spends 35-90 hours per week just preparing information for CAB. This is time that does not create new value - it is simply collecting and combining data that already exists somewhere in the organization.

And this is only the part that can be measured. There is another problem that quietly causes even bigger consequences: information quality.

The Quality Problem: When Data Is Scattered Across Many Tools

This is the key point that many organizations do not see immediately.

A typical enterprise has:

• ITSM platform A containing change requests and incidents

• CMDB platform B containing assets and dependencies

• Monitoring tool C containing real-time service health

• Excel / SharePoint containing the change calendar

• Confluence / Wiki containing runbooks, post-incident reviews, knowledge base

• DevOps tool D containing deployment history and code changes

When the Change Management team prepares information for a single change request, they must open 5-6 different tools, copy-paste data, and manually combine everything. During this process:

• Data is inconsistent between tools: The CMDB says service X has 5 dependencies, but the monitoring tool says it has 7. Which one is correct?

• Data is missing: The change calendar in Excel does not include changes from the DevOps team (they use their own tool). Collisions are missed.

• Data is outdated: The runbook in Confluence was last updated 8 months ago and does not match the current architecture.

• Context is lost while compiling: The person preparing the documents chooses information based on personal judgment - what seems important is included, what seems "not relevant" is left out.

The result: CAB receives documents that look complete in form, but may be inaccurate in content. Approve / reject decisions made from those documents therefore carry risk.

This is not the fault of the Change Management team. This is a systemic tool silo problem - when data is scattered, there is no way to combine it quickly and accurately by manual effort.

ITIL v5 and the New Approach: AI-Native + Single Platform

ITIL v5, released in February 2026, introduced an important change for Change Management: it no longer uses the term Change Control, but Change Enablement.

ITIL v5 also identifies Rapidly increasing complexity as one of the 5 key drivers for change. As systems grow more complex, dependencies multiply, and change frequency increases, manual preparation of information can no longer keep up.

AI solves this problem in two directions:

Direction 1: Speed up and expand data sources

AI automatically retrieves and combines information from all relevant data sources: CMDB, change history, incident history, monitoring, knowledge base, deployment logs. Preparation time drops from 70-110 minutes to just a few minutes. At the same time, AI can search sources that humans rarely have time to open: old runbooks, post-incident reviews from two years ago, deployment logs from other teams.

Direction 2: Eliminate tool silos with a connected platform

This is critical. AI only produces accurate results when data is not inconsistent, missing, or outdated. This requires the ITSM platform to connect all relevant data sources on a single platform, or integrate tightly with other tools.

When change requests, assets, incidents, deployments, and monitoring all live on the same connected platform (such as Atlassian: Jira Service Management + Jira Software + Compass + Bitbucket + Confluence), AI can cross-reference in real time, without complex ETL. The results AI provides are much more accurate compared to when data is fragmented.

Practical Implementation: 3 Change Request Groups, 3 Different Approaches

Classifying change requests into Standard / Normal / Emergency is a basic concept that most organizations already use. The section below does not re-explain the concepts, but shares how to implement each group in practice when bringing AI and a connected platform into the process.

Group 1: Standard Change - Auto-approve Based on Pre-approved Playbooks

Characteristics:

Standard Changes are changes that are pre-approved in principle, have a standard playbook, and have known and accepted risks. Examples: scheduled service restart, scheduled SSL certificate update, adding a user to an AD group, scaling up/down within defined limits.

Implementation:

Criteria to pre-approve a change type as Standard:

• Performed at least 20 times in the last 6 months

• Success rate > 98%

• Clear playbook with rollback procedure

• Does not affect Tier 1 services (or if it does, has automatic rollback)

Real-world results:

When implemented correctly, 40-50% of change requests fall into the Standard group and are fully auto-approved - no CAB, no manual preparation by the Change Management team. This is the biggest load reduction for both CAB and the Change Management team.

Important note:

Standard Change does not mean no control. AI still logs all changes, still runs post-implementation checks, and still reports regularly to CAB to review whether the Standard list is still appropriate. Every 2-3 months, the Change Management team should review: are there Standard types that should be removed (because the system has changed)? Are there new change types that now qualify to become Standard?

Group 2: Normal Change - AI Risk Assessment + AI Risk Brief for CAB

Characteristics:

Normal Changes form the largest group that requires CAB review. These are changes with risk that must be assessed, not urgent, and with time for preparation. Examples: updating middleware configuration, deploying new features, changing firewall rules, migrating databases.

Implementation:

Step 1: AI automatically collects and cross-references data

When a change request is submitted, AI immediately (within 30-60 seconds) retrieves and combines:

The key point: when these data sources live on the same connected platform, AI can cross-reference quickly and accurately. When data is fragmented, AI can only combine what it can access, and accuracy drops.

Step 2: AI Risk Scoring Framework

AI assesses risk based on 5 factors:

Risk Score = (Service Criticality × 0.3) + (Dependency Impact × 0.25)
                + (Historical Failure × 0.2) + (Change Collision × 0.15)
                + (Current Health × 0.1)

→ 1–3: LOW RISK
→ 4–6: MEDIUM RISK
→ 7–10: HIGH RISK

Step 3: AI Risk Brief automatically sent to CAB

Instead of the Change Management team spending 70-110 minutes per change manually preparing documents, AI generates a complete Risk Brief automatically. The Change Management team only needs to review it and add business context (if needed) before sending it to CAB.

AI Risk Brief Template:

═══════════════════════════════════════════════════
CHANGE REQUEST: CHG-2026-0847
═══════════════════════════════════════════════════

OVERVIEW
• Description: Update connection pool configuration
    on Payment Gateway Middleware
• Created by: Infrastructure Team
• Scheduled time: 28/05/2026, 22:00 – 23:00
• Rollback plan: Restore config from backup (ETA: 15 min)

───────────────────────────────────────────────────
AI RISK ASSESSMENT (auto-generated in 45 seconds)
───────────────────────────────────────────────────

RISK SCORE: 7.2 / 10 - HIGH RISK

1. Service Criticality: 9/10
    → Payment Gateway is a Tier 1 service

2. Dependency Impact: 8/10
    → 7 downstream services: Mobile Banking,
        Internet Banking, POS, QR Pay, Bill Payment,
        Auto Transfer, Reconciliation

3. Historical Failure Rate: 6/10
    → 4 similar changes in the last 6 months
    → 1/4 caused an incident (CHG-2025-1203 → INC-2025-3847,
        2h downtime)
    → Failure rate: 25%

4. Change Collision: 5/10
    → CHG-2026-0851 (Database maintenance)
        scheduled same day 28/05, 21:00–22:00
    → Same Payment Gateway service chain

5. Current Service Health: 4/10
    → No open incidents
    → Error rate stable over the last 7 days

───────────────────────────────────────────────────
RELATED DOCUMENTS (auto-found by AI)
───────────────────────────────────────────────────
• Runbook: Connection Pool Tuning Guide (v2.3, 03/2026)
• Post-Incident Review: INC-2025-3847
• Architecture Diagram: Payment Gateway v4.1
• Last Successful Change: CHG-2026-0612 (15/03/2026)

───────────────────────────────────────────────────
AI RECOMMENDATION: DEFER
───────────────────────────────────────────────────

• Collision with CHG-2026-0851 → reschedule
• 25% failure rate on Tier 1 → review rollback plan
• 7 downstream services → notify relevant teams
═══════════════════════════════════════════════════

Step 4: Automatic routing by Risk Level

LOW (1–3)    → Change Manager approves directly
                (no CAB needed)

MEDIUM (4–6) → Tech Lead review + Change Manager approve
                (no CAB, or quick CAB review)

HIGH (7–10)  → Goes to CAB with full AI Risk Brief

Real-world results for Normal Change:

Group 3: Emergency Change -- AI Supports Fast Decisions and Post-implementation Review

Characteristics:

Emergency Changes must be deployed immediately to fix a production issue. There is no time to prepare documents or hold a CAB meeting. Examples: hotfix for a payment gateway outage, patch for an exploited security vulnerability, emergency rollback.

This is the highest-risk group but often receives the least structured attention - because the pressure to deploy fast usually overrides risk control.

Implementation:

Phase 1: Pre-deployment - AI supports decision-making in minutes

When an Emergency Change is created (usually by someone handling an incident), AI must instantly provide:

AI does not make the decision instead of humans in Emergency cases. The final decision still belongs to the Emergency Change Authority (often the CIO/CTO or a delegated manager). But AI helps that person decide within minutes instead of asking many people and opening many tools.

Phase 2: During deployment - AI monitors in real time

While the Emergency Change is being deployed, AI:

• Monitors service health in real time

• Immediately alerts if anomalies are detected (rising error rate, increased latency, dropping throughput)

• Automatically triggers rollback if dangerous thresholds are exceeded (if configured)

• Logs the entire timeline for post-implementation review

Phase 3: Post-implementation - CAB retrospective review

This is the most important step but is often skipped: Emergency Changes must be reviewed by CAB after deployment, not to "approve backwards", but to learn and improve.

AI helps the Change Management team auto-prepare the Retrospective Review report:

═══════════════════════════════════════════════════
EMERGENCY CHANGE RETROSPECTIVE: ECHG-2026-0125
═══════════════════════════════════════════════════

TRIGGER
• Incident: INC-2026-4521 (Payment Gateway timeout)
• Detected: 25/05/2026, 14:23
• Emergency Change initiated: 14:31

DEPLOYMENT TIMELINE (AI auto-log)
• 14:31 — Emergency Change created
• 14:33 — Approved by On-call Manager (Tran Van B)
• 14:38 — Fix deployed to Production
• 14:42 — Service health recovered (verified by monitoring)
• 14:45 — Incident closed
• Total downtime: 22 minutes

ROOT CAUSE (AI suggested, human verified)
• Connection pool exhaustion due to traffic spike
• Related to deployment CHG-2026-0820 (24/05) —
    config change reduced pool size

LESSONS LEARNED
• Pool size needs proactive monitoring (new alert suggested)
• CHG-2026-0820 should have had load testing before deploy
• Runbook needs update for this scenario

CAB ACTION ITEMS
□ Update standard Pool Size config baseline
□ Add load testing requirement to checklist
    for Middleware changes
□ Schedule post-mortem session with the Application team
═══════════════════════════════════════════════════

Real-world results for Emergency Change:

Measuring Overall Effectiveness

After implementing AI Risk Assessment for all 3 Change groups, the measurement dashboard should track 6 key metrics:

Feedback loop to keep improving AI:

After each change is deployed, it is mandatory to record the Post-Implementation Result (Success / Failed / Partial). AI uses this data to learn:

• AI predicted LOW but actual result is Fail → increase risk score for similar patterns

• AI predicted HIGH but actual result is OK → decrease risk score for similar patterns

After 3-6 months of accumulating data, AI accuracy increases significantly because it has more real-world context from the organization.

Implementation Checklist by Phase

Phase 1: Audit current state (Week 1-2)

• Measure the average time the Change Management team spends per change request

• List all tools that hold change-related data (CMDB, ITSM, monitoring, change calendar, KB)

• Identify data fragmentation points: where data is inconsistent, missing, or outdated

• Export 6 months of change history: classify as Standard / Normal / Emergency

• Measure baseline for the 6 key metrics

Phase 2: Foundation for Standard Change (Week 3-4)

• Identify change types that qualify as Standard (>20 occurrences, >98% success)

• Write a playbook for each Standard Change type

• Configure auto-approve on the ITSM platform

• Set up automatic post-implementation checks

• Define a regular review cycle for the Standard list (every 3 months)

Phase 3: AI Risk Assessment for Normal Change (Week 5-7)

• Verify CMDB data quality (at least service tier + dependencies for Tier 1)

• Connect the ITSM platform with related data sources (CMDB, monitoring, KB, deployment)

• Configure the Risk Scoring Framework (5 factors, weights)

• Create the AI Risk Brief template

• Configure automatic routing by Risk Level

• Pilot with 1--2 teams before rolling out across the organization

Phase 4: Emergency Change workflow (Week 8-9)

• Define Emergency Change Authority and on-call rotation

• Set up AI quick-assist for pre-deployment (Quick Risk Score, Service Impact Map)

• Configure real-time monitoring + auto-rollback rules

• Create the Retrospective Review template

• Make Retrospective Review mandatory for all Emergency Changes

Phase 5: Measure and optimize (Week 10+)

• Build a dashboard for the 6 key metrics

• Set up the feedback loop: Post-Implementation Result is mandatory

• Review AI accuracy monthly and adjust weights if needed

• After 3 months: assess moving from rule-based → ML model

Conclusion

The Change Management challenge in enterprise organizations is not "missing process" or "CAB not preparing information before meetings". The real challenge is:

• The Change Management team is spending too much time preparing documents manually - time that does not create new value.

• Data is scattered across many tools - causing inconsistencies, gaps, and loss of context.

• As a result, the quality of risk assessment depends heavily on how accurately data is combined.

AI addresses this challenge in two parallel directions:

1. Automatically collecting and combining data from all relevant sources -- helping reduce preparation time by 70-80%.

2. Eliminating silos with a connected platform - when data lives in one place, AI can cross-reference accurately, and risk assessment results become much more reliable.

ITIL v5 calls this Change Enablement. The goal is not to block more changes, but to maximize the number of successful changes using data-driven decisions.

Organizations that start connecting their data and accumulating AI learning earlier will achieve Change Management that is faster, safer, and more reliable.

See more BiPlus blog articles here.