Across Ardent’s work with mature data environments, we have seen assumptions that were manageable at a smaller scale become more exposed as an organisations process or business automation journey expands. Before increasing the role of AI, our starting point is to establish why a workflow produces a particular outcome, what data it relies on and how changes in that data affect the result.

We call thisdata proofing: tracing one automated outcome through the data that supports it, testing the conditions that could make it unreliable, defining when the process should stop and proving how an incorrect action would be recovered. It provides practical evidence for deciding how far automation can safely act before AI increases its speed, reach or role in the process.

At its simplest, a data proof should answer five questions:

1. What action are we allowing the process to take?

2. Which data and assumptions justify that action?

3. What happens when that information is incomplete, late or wrong?

4. When should the process stop or return to a person?

5. Can an incorrect outcome be identified, reversed and recovered?

Together, those answers show whether to expand automation, limit AI to recommendations or retain human review.

Scale exposes the data assumptions your pilot never tested

In Ardent’s experience when an automation is first tested, it often uses a limited set of data, familiar scenarios and people who already understand the process. As it expands, different users, less predictable records, delayed updates and combinations the original workflow never encountered begin to appear.

History shows how quickly automated execution can magnify a control gap. In 2012, a software deployment problem at Knight Capital(a US electronic trading firm)generated more than four million unintended trade executions in 45 minutes and ultimately cost the firm more than $460 million, according to the US Securities and Exchange Commission.

The Knight Capital incident was not an AI failure, which is precisely why it matters: automation already allows a missed signal to travel faster than people can respond, and AI can introduce more routes through the same process. In ordinary operations, the same pattern might turn a late customer status into the wrong communication, a duplicate transaction into an unnecessary investigation or outdated stock data into an unsuitable order.

In client environments, we have seen automations behave well in testing and then produce occasional wrong outputs when live volumes introduce a record type, customer segment or exception the pilot never encountered. The important question is therefore not simply whether an automation completed successfully, but whether the organisation can explain and defend the action it produced.

Ardent’s starting point: prove one business action, not the whole estate

When Ardent begins this work with a client team, we start with one business action rather than the entire data estate. That might be something automation already does, or AI is expected to influence, such as prioritising a service case, releasing an order or contacting a customer.

The next step is to agree what a correct outcome looks like and what harm an incorrect one could cause. In Ardent engagements, this works best when process owners join those managing the data and technology. A data engineer can confirm that a field arrived and passed validation, while the process owner can explain whether it still means what the automation assumes.

That conversation often exposes decisions outside the technical design: an apparently eligible customer with an open dispute elsewhere, stock held in the wrong location or a service case covered by an agreed pause in another system.

These conditions are routinely resolved through experience or manual checking. Making them visible turns informal judgement into evidence the automation can use, or recognise as a reason to pause. It also creates a clear boundary for the proof: one action, the information supporting it and the consequence of getting it wrong.

Trace why each automated outcome was safe to act on

A useful trace should show which systems supplied the information, when the data was last updated, which definitions or transformations were applied and whether missing values were inferred or a person overrode the result. It should also reveal whether another system records the same fact differently.

Thetraceis most useful when it connectstheaction to therule, threshold or model thatauthorisedit,alongside the condition of the dataat that moment. Lineage showswhere a value travelled; this showswhy it was considered safe to use.

In ourexperience, bringing the technical and operational views together helps the client team see where automation relies on confirmed data and where it depends on an assumption. The technical path may be documented while the reason behind a business rule sits with an analyst or operations team, so tracing one outcome gives both perspectives a common reference.

Turn real exceptions into the test for AI readiness

For each failure case, the response should be agreed before the workflow is given greater authority. The process might continue if missing information does not affect the decision, narrow the action it can take, hold the case for review or stop entirely. The aim is for uncertainty to trigger a defined response rather than an improvised one.

Past incidents, near misses and routine manual corrections often produce better tests than an imagined catalogue of failures because they show where people already apply judgement. Process owners can describe both the warning signs and the practical consequence, including recurring cases such as a manual override that expires quietly and allows an outdated decision to stand.

Those failure cases also need a baseline against which their effect can be judged. Without understanding the process AI is intended to improve, a successful demonstration can easily be mistaken for operational progress. Useful measures might include manual corrections, slow exceptions, reversed actions, duplicate checks and mistakes with meaningful customer, financial or operational consequences.

A workflow is not controlled until the wrong action can be recovered

Stopping is only part of the control. Teams also need to know what happens when an incorrect action has already travelled further through the process: whether it can be reversed, which downstream systems require correction and how affected users will be informed.

In one recovery test, Ardent found that a reversal updated the customer-facing system immediately but took considerably longer to reach billing and fulfilment. The workflow appeared corrected while downstream processes were still acting on the earlier decision.

Testing the recovery route before scaling can expose unclear ownership, missing evidence and corrections that reach one system but not another. If recovery still depends on one person knowing where to look, the process is not yet ready for greater automation.

A completerecovery testshould confirm thatthe affected actioncan be identified,further propagationcontainedandevery dependent systemreturnedtothe correct state within an agreed time.

Use the data proof to decide how much authority AI should have

The result does not have to be a simple yes or no. Low-impact, well-evidenced cases may support full automation; incomplete context may require human approval; and slow recovery or material consequences may rule out automated action.

Ardent works alongsideorganisationsto trace decisions through their data, test the conditions that could undermine them and build proportionate stop and recovery paths. Beginning with one critical workflow creates a practical route to scaling AI with evidence and control.

Evidence and further reading

• US Securities and Exchange Commission, SEC Charges Knight Capital With Violations of Market Access Rule (2013).

• National Institute of Standards and Technology, AI Risk Management Framework Core.

• Ardent, Intelligent ETL: From Data Preparation to Decision Intelligence (2026).

• Ardent, Making Your Existing Data Pipelines AI-Ready (2026).

• Ardent, Migrating to Agentic AI; A Practical Roadmap for Data Teams Already Running ETL Pipelines (2026).