How Should Parallel Running Be Managed Before an AI Bordereaux Workflow Goes Live?
A parallel run should be a time-bound comparison with a defined baseline, representative bordereaux, one authorised system of record and pre-agreed exit criteria. Teams should investigate material differences rather than merely count matches, monitor the operational effort created by review, and extend or stop the run when the evidence does not support cutover.
Key takeaways
- Define the baseline and system of record before starting.
- Include routine, difficult and peak-period submissions.
- Investigate material differences and their causes.
- Use explicit exit, extension and stop criteria.
A pilot can show that an AI-assisted workflow is capable of processing bordereaux. It does not necessarily show how that workflow behaves across live reporting cycles, operational peaks and difficult submissions.
Parallel running compares the proposed workflow with the current process before cutover. It can expose hidden differences in data, decisions and workload.
The exercise needs a defined end. Without scope, authority and exit criteria, it can become an expensive dual process that produces two competing answers.
Parallel running answers an operational question
Functional testing asks whether the workflow performs specified tasks. A parallel run asks whether it can operate within the real service, including submission variation, deadlines, hand-offs, exceptions and downstream dependencies.
The comparison should test more than output agreement. It should examine processing time, review effort, exception quality, reconciliations and the ability to recover from failure. A workflow that produces accurate results but doubles specialist review may not yet support the intended operating model.
Parallel running is not proof that the current process is always correct. Differences can reveal an error in the new workflow, an inconsistency in existing handling or an ambiguous business rule that neither process resolves reliably.
A bounded comparison protects daily processing
Define the scope, start conditions, duration logic and accountable owner. Select bordereaux that represent normal volume, known difficult formats, relevant coverholders and seasonal or reporting peaks. Duration should be based on sufficient coverage, not a universal number of weeks.
Choose the baseline and one authorised system of record. During a pre-production comparison, the current approved process will often remain authoritative, but the decision must be explicit. Prevent both outputs from being loaded downstream or sent separately to stakeholders.
Create a discrepancy log that records the source, affected field or record, materiality, cause, resolution and owner. Decide which differences require immediate review and which can be sampled. Resource this work without weakening daily processing.
AI output should be compared in context
Compare results at meaningful levels. Field-level agreement can show mapping or extraction differences, while control totals reveal financial effects. Review confidence, exception routing and the reasons analysts override suggestions.
Include cases the workflow should decline to process. Correctly escalating an unfamiliar layout can be safer than returning a plausible but unsupported transformation. Test failures in reference data, integrations and review hand-offs as well as normal AI output.
AI can help group discrepancies and identify patterns, but analysts should confirm root causes. A recurring difference may require a rule change, better source guidance, more representative training examples or a change to the current process.
Exit criteria prevent an indefinite dual process
Agree cutover, extension and stop criteria before results are known. Criteria may cover material accuracy, reconciliation, exception quality, review capacity, stability across sources and recovery testing.
An extension should answer a defined evidence gap. Repeating the same routine cases does not resolve uncertainty about a missing class of bordereaux. A stop decision is appropriate where material risk, workload or unresolved dependencies exceed agreed tolerance.
Retain the comparison evidence and approvals. At cutover, confirm the production version, support arrangements, monitoring and recovery path. Parallel running reduces uncertainty; it does not remove the need for post-live oversight.
Example
A hypothetical managing agent runs an AI-assisted premium bordereaux workflow alongside its analyst-led process over two reporting cycles.
The sample includes routine submissions, a new layout and a high-volume period. The existing process remains the authorised record. Differences are logged by field, materiality and cause, while the team also measures review effort and exception ageing.
Several discrepancies reveal inconsistent historic treatment rather than AI error. Owners clarify the rules and rerun affected cases. Cutover proceeds only after the predefined quality, workload and recovery criteria are met.
FAQs
-
How long should a parallel run last?
Long enough to cover representative normal, difficult and peak conditions. A fixed duration is less useful than evidence that all material submission types and process dependencies have been exercised.
-
Which result is authoritative during parallel running?
One system of record should be agreed before the run begins. This prevents two outputs from reaching downstream users and makes correction and approval responsibilities clear.
-
Does every difference mean the AI is wrong?
No. Differences may reveal an AI error, an existing-process inconsistency or an ambiguous rule. Investigate material differences and record the confirmed cause rather than assuming either process is right.
Talk us through your DA process
Book a conversation to explore where AI could help improve delegated authority data flow, validation and operational control.
