Before the Model: A Twelve-Point Operations Debt Review for UK AI Programmes

Most AI pilots do not fail because the model is weak. They fail because the operational estate beneath the model cannot answer basic questions about provenance, ownership, exception handling and evidence. For UK operations, data and finance leaders, that is an uncomfortable but useful starting point. A pilot that looks modest on a vendor proposal can become a lengthy remediation programme once ERP extracts, CRM records, spreadsheet workarounds and SaaS integrations are drawn into scope.

Digital operations debt is the accumulated cost of those compromises: the manual reconciliation, undocumented interfaces, duplicated master records and personal workarounds that keep a process running. It is rarely visible in a business case, yet it determines whether an AI pilot can move from demonstration to controlled production. The twelve questions below are designed as a pre-budget audit. They are not a substitute for legal or assurance advice, but they give leadership teams a common basis for challenge.

Begin with the decision, not the model

1. Which operational decision will the pilot change, and who is accountable for that decision today? If the answer is a committee, a shared inbox or a spreadsheet owner, the pilot is not ready. AI needs a decision owner who can define acceptable error, escalation and sign-off.

Trace the data path through the estate

2. Can you trace every field used by the pilot from source system to model input, including manual spreadsheet steps? For most UK mid-market organisations, the honest answer includes at least one workbook that is critical but unowned. A data lineage diagram that omits these steps is a fiction.

3. Which spreadsheet or end-user computing steps are load-bearing, and who maintains them? Finance and operations teams often rely on spreadsheets for allocations, pricing, stock adjustments or commission. If a pilot depends on one, it needs version control, access control and a named custodian before go-live.

4. Which SaaS tools exchange data with core systems, and under what integration contract? CRM, procurement, HR and warehouse tools often sit outside formal integration ownership. Record the direction of flow, frequency, schema, error handling and contractual responsibility for each connection.

Test exception handling before accuracy claims

5. How are exceptions handled now, and will the pilot preserve that handling? Models are usually evaluated on normal cases. Operations run on exceptions. If the current process relies on experienced staff overriding rules, the pilot must either capture that judgement or route the case to a human with the same authority.

6. What happens when the model is uncertain or unavailable? A pilot without a fallback is a single point of failure. Define thresholds for abstention, manual review and service continuity.

7. Are service levels and escalation paths defined for the pilot? AI introduces new failure modes: stale inputs, drifting data, API outages and unexplained outputs. Operations need an escalation route that does not depend on the data science team being on call.

Settle ownership and master data

8. Who owns each master data domain, and is that ownership recognised outside the pilot team? Customer, supplier, product, employee and location data need accountable owners. A pilot team cannot become the de facto master data authority by default.

9. Which duplicate customer, supplier or product records will the pilot treat as truth? Deduplication is not a technical tidy-up. It changes reporting, credit decisions, stock allocation and customer service. The rule for survivorship should be documented and approved before the pilot uses the data.

Check governance, privacy and auditability

10. Have you completed a data protection impact assessment where UK GDPR requires one, and does it cover the pilot's data flows? AI pilots often introduce new processing, new data sources or new inference. The assessment should address purpose limitation, minimisation, retention and any automated decision-making.

11. Can the organisation meet ICO expectations on lawful basis, subject rights and records of processing for pilot data? The Information Commissioner's Office expects accountability to be demonstrable, not assumed. If pilot data is copied into a separate environment, the record of processing and retention schedule must follow it.

12. Can you reproduce and explain a pilot decision to an auditor, regulator or customer months later? In regulated processes, auditability is part of the control environment. That means logging inputs, model version, rules applied, human overrides and the final decision in a way that survives staff turnover.

Using the audit as a budget gate

A single red flag need not stop a pilot, but it should change the scope. If questions 2, 3, 4, 8 or 9 cannot be answered with evidence, the programme is probably funding data remediation under an AI label. That is not necessarily wrong, but it should be budgeted and governed as such.

Finance leaders should ask for the remediation cost separately from the pilot cost. Operations leaders should ask who will own the process after the pilot. Data leaders should ask whether the pilot creates reusable controls or another one-off extraction. The most useful outcome of this audit is not a pass or fail mark. It is a clearer view of what must be fixed before an AI pilot can be trusted in production.