Inadequate pre-deployment testing

What it is

Testing before release is the last point at which a fault is cheap to fix. For AI systems it has to cover more than whether the software runs: accuracy on realistic cases, behaviour at the edges, safety of outputs, resistance to misuse, performance across groups, and how real users interact with it. The risk is that some of this is skipped, often under pressure to launch, or that the test conditions bear little relation to production.

How it happens

• A deadline is fixed before the scope of testing is known.
• A demonstration to stakeholders stands in for testing.
• Tests use clean, curated inputs unlike real ones.
• Nobody defined what result would stop the release.

Why it matters

Faults reach customers and operations, where they are costlier to correct and may already have caused harm. A release with no test evidence also leaves the organisation unable to show that it took reasonable care.

Warning signs

• No acceptance criteria were agreed before testing began.
• Test evidence is absent from the approval record.
• Known failures were waived without a recorded owner.
• Testing was done only by the build team.

Who owns it

The system owner is accountable for the decision to release. Engineering and independent testers produce the evidence. The approving authority confirms that the criteria were met.

In practice

An insurer launches an assistant to answer policy questions after a week of internal trials in which staff asked the questions they expected. Customers ask about exclusions in ways nobody tried, and the assistant confirms cover that the policy does not give. The same pattern generalises to any release where testing reflected the builders' expectations of use.