A disappointing AI implementation does not prove that AI has no useful role in the firm. It also does not oblige the firm to try again.

The responsible response is to preserve evidence, contain harm, allocate responsibility and decide afresh whether the underlying problem justifies another intervention.

Stabilise the current service

Before a strategic reset, establish what is running and who is affected.

  • Pause unsafe or unapproved uses where necessary.
  • Preserve logs, evaluation results, contracts, versions and decisions.
  • Confirm where client, personal or confidential data was processed.
  • Review incorrect outputs and downstream decisions.
  • Revoke unnecessary supplier and user access.
  • Maintain a supported fallback for essential work.
  • Complete incident, legal, regulatory or client communication processes where required.

Do not delete evidence in an effort to move on. Equally, do not keep a risky system live merely to gather more results.

Name an accountable incident or recovery lead. If the implementation has not caused harm, the same discipline still helps the firm avoid drifting into an unsupported pilot.

Compare promise, contract and observed performance

Create a claim register from sales material, demonstrations, proposals, statements of work and contracts. For every material claim, record:

  • exact wording and source
  • task and conditions implied
  • contractual treatment
  • client assumptions and dependencies
  • observed result and evaluation method
  • known exclusions or version changes
  • commercial and operational consequence

This separates overpromise from misunderstanding, weak scoping and later change.

A demonstration against curated data may have been accurate for that data. The failure is material when its limits were concealed, the buyer reasonably inferred broader capability or acceptance criteria did not protect the intended use.

Use legal and procurement advice for contractual interpretation. Editorial labels such as “vendor failure” are not substitutes for evidence.

Diagnose both delivery systems

Examine four areas.

Use-case feasibility

Could the product available at contract date perform the intended task under realistic conditions? Was the problem suitable for AI, and was a simpler intervention considered?

Data and integration

Were source quality, rights, permissions, formats, volumes and interfaces assessed? Did the vendor state prerequisites? Did the client validate them?

Evaluation and expectations

Were baseline, representative examples, quality measures, review effort and serious failure thresholds agreed before implementation? Did leadership distinguish a generated first draft from an approved outcome?

Governance and operation

Who owned the use case? Were problems visible early? Could anyone pause the work? Were security, privacy, professional and supplier risks reviewed? Did the firm fund adoption, support and continuing evaluation?

Allocate causes and contributing conditions specifically. “Both sides made mistakes” is too vague to change another attempt.

Decide whether the original problem remains worth solving

Return to the workflow and outcome. Measure present effort, error, delay or capacity. Speak to the people doing and receiving the work.

The failed implementation may have exposed that the problem was smaller, more variable or less valuable than the business case claimed. It may also have revealed a data or process foundation worth fixing without AI.

Compare options:

  • stop and restore the previous service
  • improve the workflow without AI
  • narrow the existing product's use
  • require the supplier to remediate under the agreement
  • choose another product or delivery approach
  • build internal capability
  • wait for technology or foundations to mature

Past spend should not determine the choice. Future value, cost, risk and obligations should.

Repair internal confidence through specificity

Leaders who sponsored the work should state what happened, including the firm's contribution. Avoid a broad apology followed by another optimistic plan.

A credible account sounds like:

The supplier's classification claim was based on document types that excluded two important formats in our archive. We did not validate that sample before contracting, and our gate reporting did not expose the performance gap early. We have suspended that workflow, preserved the evidence and changed the evaluation and stop controls. We will return with options after revalidating the business need.

Colleagues need to know how their data, work and feedback were used. Acknowledge time wasted and resolve any uncertainty about monitoring or role impact.

Confidence returns through kept controls and accurate reporting, not renewed excitement.

Make any second attempt structurally different

If evidence supports another use, begin with the problem and a bounded decision. Define:

  • users, task and exclusions
  • baseline and intended outcome
  • representative evaluation set
  • business, quality and risk measures
  • human review and total effort
  • data flow and supplier processing
  • incident and stop conditions
  • operating owner and budget
  • scale gate and genuine stop option

Select a duration that captures normal variation. Do not default to 90 days or a fixed accuracy threshold without evidence.

Use an independent technical or domain reviewer where the firm lacks capability to challenge claims. Build internal literacy among owners and users, while recognising that training cannot compensate for an unsuitable product.

Evaluate a replacement vendor against failure

Give candidates the claim register and representative difficult cases. Ask them to explain what their product cannot do, how it behaves when uncertain and which client conditions are essential.

Run a buyer-controlled proof. Retain raw results, version information and calculation. Translate material promises into acceptance and contract terms.

Ask references about implementation effort, changes after launch, support and failures. A vendor's account of a difficult engagement can reveal learning, but it is not a pass-or-fail personality test.

Review subcontractors, model providers, roadmap dependencies, data terms, change rights and exit. The product may rely on components the immediate vendor does not control.

Rebuild strategy above the vendor layer

An AI strategy should not be a list of product commitments. It should define where the firm will consider AI, how use cases are chosen, which data and decisions are out of bounds, how evidence and governance work, and which capabilities the firm needs.

Maintain a use-case portfolio with owners, status, cost, performance, incidents and retirement. Review supplier concentration and shared dependencies. A failed vendor can then affect one bounded use, rather than the entire strategy.

The AI Readiness Assessment offered with this article can help profile a specific use case across workflow, data, systems, governance and people. Treat the result as a starting hypothesis and verify material gaps before another vendor conversation.

One bad implementation should neither end AI consideration nor become a reason to spend again. The reset succeeds when the firm can explain exactly what failed, protect those affected and make the next decision without needing the technology to redeem the previous one.