Scenario 4. Integrate AI in case management
This section examines how agencies can integrate AI capabilities into an existing operational system and workflow. A common example is case management, where agencies assess how AI, such as ML, can prioritise, triage or support decisions in a domain that is often compliance-sensitive, data-intensive and consequential for individuals and entities.
Key challenges
Case management presents an integration-led architectural challenge. Agencies are assessing how AI capabilities can be introduced into existing workflows without weakening accountability, legal defensibility, traceability or meaningful human control. Machine learning (ML) can improve the speed and consistency of identifying higher-risk cases, but it must be integrated without weakening existing accountability, auditability or legal defensibility.
The central architectural challenge is determining whether ML can improve prioritisation, or determining which cases are prioritised for review or action. Because this decision can have significant consequences, agencies must be able to explain, reconstruct and, where necessary, contest the basis for selection. Agencies need clear audit trails, proportionate human oversight and safeguards against bias or historical skew in selection outcomes.
Agencies may share broad architectural patterns for case management, but case selection logic, data and treatment pathways are often domain-specific, sensitive and difficult to standardise. These factors make reuse possible at the pattern level but not as a single shared solution.
How AIRA supports this scenario
AIRA helps by turning this into a structured integration-and-operating model rather than a narrow model-selection exercise. It articulates the scenario across layers and domains so that agencies can distinguish the additional components needed beyond their existing case management systems; identify hidden dependencies such as data preparation, explainability, assurance evidence and workflow redesign; and decide where rules, models and human review need to work together.
In summary, AIRA supports this scenario as follows:
- Map existing operational workflow to AIRA: Use the functional stack to map the current case management system as a baseline. This helps agencies distinguish existing capabilities from new capabilities that need to be introduced and exposes dependencies that may not be obvious before integration.
- Map new capabilities across the functional stack: Use AIRA to identify new components required beyond the existing system, such as risk models, explainability views, feedback loops or machine-learning operations. Decisions in one layer may require supporting capabilities in others, such as data preparation to support model training, or observability infrastructure to support monitoring.
- Assess whether integration strengthens or destabilises the existing workflow: Use AIRA to assess whether AI integration may improve case prioritisation or if it could destabilise existing controls, decision quality or operational outcomes. Consider whether the integration may weaken accountability, auditability, legal defensibility or the consistency of case selection over time
- Assess whether the workflow itself could change: Consider whether AI enables steps to be collapsed, combined or re-sequenced across organisational or system boundaries
- Map how AI outputs move through the workflow: Risk scores or recommendations can influence case selection, escalation or investigation. Make sure the architecture clearly frames how outputs move through the workflow, where human judgement remains, and how control boundaries are enforced and monitored in operation. Human oversight should be proportionate to consequence without reintroducing the manual bottleneck the capability is meant to relieve.
- Engineer trustworthiness and assurance across the workflow, not just the model: Use AIRA T&A domains across the full functional stack to identify where assurance controls are needed. This can include data lineage, audit trails, fairness and bias testing, explainability, privacy and security controls. Monitor for drift or disparity, and the ability to reconstruct why a case was flagged. This may include retaining system operational data to support results.
- Determine the human agency, oversight and control: Use AIRA to define where outputs remain advisory, where they shape prioritisation, and where additional reviews for higher-consequence cases are needed. This depends on how clearly the architecture defines review points, escalation pathways, role clarity and responsibility across case officers, supervisors, technical teams and accountable officials.
- Map detection and monitoring mechanisms against AIRA: Case selection behaviour may change over time. Use AIRA to identify where monitoring, feedback loops and controlled improvement mechanisms are needed across the functional stack. The architecture should also support the ability to constrain, pause or roll back case selection behaviour when degradation or disparity is detected.
- Introduce the simplest AI-enabled capability: A practical architectural objective is to introduce the simplest AI-enabled capability that strengthens case management without weakening existing governance. Mature it over time as evidence, controls and operational capability improve.
Figure 4: Mapping of architecture impacts when introducing ML capability
Illustrates an example mapping of existing, enhanced and new capabilities when integrating ML for the first time into an existing case management solution. It helps agencies identify which capabilities require little to no change, which may require uplift, and which may need to be introduced.
Legend:
- (E) existing with no to minimal change
- (U) candidate for uplift or enhancement
- (N) new
Detailed scenario analysis
Functional stack
Table 10 illustrates the typical architecture capabilities and components of a case management solution. Where an agency already has an operational case management solution and is considering ML for the first time, the functional stack articulation helps distinguish existing capabilities from new capabilities that need to be introduced across the stack.
| AIRA Layers | Indicative capabilities and components |
|---|---|
| Experience |
|
| Application and orchestration |
|
| Intelligence and analytics |
|
| Data and metadata |
|
| Platform and infrastructure |
|
Communication
The communication stack for case management includes interoperability and ecosystem integration, cross-agency data sharing, event-driven workflows and the feedback loops that connect model outputs, human decisions and system improvement over time.
Indicative communication capabilities include:
- integration with case management, data and operational systems
- interoperability across agency and external data sources
- event-driven workflows for case lifecycle management
- data and decision exchange across trust boundaries
- feedback loops between model outputs, human decisions and system updates.
Trustworthiness and assurance
Table 11 summarises key T&A drivers in AI-enabled case management and how architectural design can help address them. These drivers reflect the core question in this scenario: whether case selection decisions can be assessed and governed in practice. They include concerns such as fairness across cohorts, sufficiency of explanation for review and legal defensibility, protection of sensitive information, visibility of system behaviour and the ability to reconstruct and justify decisions over time. The table does not prescribe controls but highlights how architectural choices can support agencies in examining and managing these concerns across the full system lifecycle.
| AIRA Group | Key drivers | How architecture can help |
|---|---|---|
| Observability | Case management spans multiple stages of ingestion, analysis and decision-making, often involving opaque model behaviour. | Architecture can enable visibility into data flows, model behaviour and decision outcomes across the case lifecycle, supporting monitoring and investigation of system behaviour. |
| Traceability | Case selection decisions may be reviewed, challenged or audited at a later point in time, requiring reconstruction of how outcomes were produced. | Architecture can support end to end lineage of data, model inputs, decision logic and actions taken, enabling reconstruction of how and why cases were flagged or prioritised. |
| Explainability and interpretability | Case officers, supervisors and external reviewers need to understand why cases were selected or prioritised. | Architecture can support explainable outputs and supporting views that enable case officers and reviewers to understand, interrogate and justify case selection decisions in operational, audit and legal contexts. |
| Validity and reliability | Case prioritisation influences operational decisions and allocation of investigative resources and must remain consistent over time. | Architecture can support validation of risk scores and decision outcomes, including testing approaches, monitoring for drift and maintaining consistent behaviour across operating conditions. |
| Safety | Case selection may lead to investigative or enforcement actions with real world consequences for individuals and entities. | Architecture can support safe operation through clearly defined operating bounds, fallback pathways and escalation mechanisms where system outputs are uncertain or unreliable. |
| Fairness | Case selection may disproportionately affect certain groups, particularly where data or model behaviour introduces bias. | Architecture can support fairness assessment through cohort-level monitoring, representative data handling and mechanisms to test and review whether mitigation approaches are proportionate to the operational and legal context. |
| Sustainability | Models, data and operational processes evolve over time, and unmanaged change can degrade performance or governance. | Architecture can support controlled updates to models and data and enable systems to adapt over time without weakening governance or operational control. |
| Security and resilience | Case management systems handle sensitive and high value data and depend on multiple interconnected systems. | Architecture can support controlled integration points, secure handling of interactions and resilience to system failures to ensure continuity of operations and protection of case data. |
| Privacy | Case management often involves processing personal or sensitive information across multiple systems and workflows. | Architecture can support data minimisation, purpose limitation and controlled access to personal information throughout the case lifecycle. |
Human agency, oversight and control
In this scenario, HAOC is enabled through architectural capabilities that define decision boundaries, enable monitoring and intervention and preserve accountability over time. Table 12 distinguishes controls that are established at design time from those exercised during system operation. The run-time controls then inform the skills and training required to operate the system.
| Indicative capability | Design-time controls | Run-time controls |
|---|---|---|
| Decision scope and control boundaries | Definition of where automation applies, including decision scope, thresholds and limits on model-driven case selection. | System operates within defined decision boundaries, with visibility of when decisions are automated, assisted or require human review. |
| Human review and intervention points | Design of review checkpoints for higher consequence or uncertain cases, including override and approval pathways. | Case officers and supervisors can review, intervene, override or escalate decisions where required. |
| Supervisory monitoring and oversight | Definition of monitoring requirements, including what system behaviour and case-selection patterns must be observable. | Supervisory functions can monitor case selection behaviour, detect drift or anomalies and trigger investigation or intervention. |
| Accountability and decision attribution | Definition of attribution requirements linking model outputs, system decisions and human actions. | System behaviour and decisions can be traced to specific inputs, model states and human actions to support accountability and review. |
| Feedback and system improvement | Design of structured feedback mechanisms linking case outcomes and human judgement to model updates and workflow refinement. | Feedback from case officers and operational outcomes informs controlled updates to models and processes over time. |
| High consequence case handling | Identification of case types requiring additional control (for example regulatory, legal, or high-impact cases) and design of differentiated workflows. | Such cases are subject to additional review, escalation or constraints on automation in operation. |
| Operational control and safe stop mechanisms | Definition of conditions for pausing, constraining or rolling back system behaviour (for example, drift thresholds or anomaly triggers). | System can be constrained, paused or adjusted in response to emerging risks, degraded performance or governance concerns. |
Across these views, AIRA points towards introducing the simplest AI-enabled capability that strengthens case management without weakening the accountability, auditability and legal defensibility the existing process already depends on. This means integrating where the case selection decision remains explainable and contestable, where the audit trail is sufficient to reconstruct and defend each prioritisation, and where human oversight is proportionate to consequence without reintroducing the manual bottleneck, the capability is meant to relieve. Capability can then mature over time as evidence, controls and operational experience improve. Where these conditions cannot be met, the response is to narrow the scope of automation, keep outputs advisory, or defer integration, rather than accept weakened governance for efficiency gains.