What boards must require before accepting AI/ADM systems: a pragmatic acceptance pack and testable gates for programmes that process personal data

Why boards are being asked to decide without delivery evidence

Regulation and policy have moved quickly: SI 2026/425 makes the Information Commissioner responsible for a statutory AI/ADM code, the Data (Use and Access) Act 2025 changes data sharing rules, and the NCSC has explicit machine‑learning and CAF v4.0 expectations for operational resilience. Senior leaders are now asked to approve transitions where legal, safety and resilience obligations are interwoven with technical performance. Yet programmes routinely present compliance statements, vendor attestations and redacted slides — not the reproducible, testable ledger a board can rely on. The result is approval on hope, not tested evidence.

How people, process, data, systems, suppliers and controls interact in an AI acceptance decision

An AI acceptance decision sits at the intersection of multiple domains. People operate the model in process; the model consumes data and produces decisions that must integrate with casework, records and human review; suppliers supply models, training pipelines and hosting; controls (DPIA, monitoring, incident response) are required by law and contract; governance must trace requirements to evidence. Failure in any domain creates delivery and regulatory risk — for example, a model that performs well in vendor demos but was trained on unrepresentative data will fail in production, creating safety incidents, regulatory breaches and operational disruption.

Senior leaders should therefore require an acceptance pack that links requirements, traceable tests, supplier evidence and operational controls to the actual decision they are being asked to make: ‘Do we accept this system into live use for the specified business function under these constraints and liabilities?’

The acceptance lifecycle: the gates that matter

Turn the decision into three executable gates (programme language that boards understand):

1) Pre‑acceptance gate (readiness to be assessed by the board): Artefacts required include: a delivery‑grade DPIA endorsed by the DPO; a model card and training/validation dataset provenance; a requirements traceability matrix mapping each legal, safety and operational requirement to tests; integration and end‑to‑end test reports; and a supplier evidence pack (contract clauses, portability/reversibility proofs, escrow arrangements). The board should see reproducible test outputs, not only summary metrics.

2) Pre‑go‑live gate (acceptance to operate in a limited live scope): Beyond the pre‑acceptance artefacts require: a live‑data shadow trial with monitored outcomes; real user and service owner acceptance evidence; security and adversarial robustness test reports; monitoring and drift detection configured against agreed KPIs; and confirmed incident response and rollback procedures with supplier sign‑offs.

3) Acceptance to transition to BAU (full operational acceptance): This requires a period of stabilisation with defined acceptance criteria met (statistical stability, no high‑severity incidents, supplier SLA performance, evidence of staff competence). Contractual handover artefacts — runbooks, runchains for reversibility, update/change protocols and maintenance commitments — must be complete.

Concrete artefacts the board should require in the acceptance pack

Make the acceptance pack a ledger of reproducible artefacts. At minimum demand the following, organised and referenced in a single indexed pack:

• Statutory and governance: DPIA signed by the DPO and evidence of any ICO consultations, plus the programme’s legal risk register mapped to model output types. • Requirements traceability matrix (RTM): every board requirement (safety, fairness, explainability, latency, throughput, reversibility) mapped to a test and an owner. • Model deliverables: model card, architecture diagram, training/validation/test datasets with provenance metadata, random seed and environment for reproducibility, and a frozen evaluation snapshot. • Reproducibility test: an independent technical exercise that reproduces model outputs from the supplied artefacts on a sealed test environment. • Security and robustness: NCSC‑aligned ML threat model, adversarial/poisoning test reports, penetration test, and third‑party vulnerability disclosure arrangements. • Performance and integration: end‑to‑end integration tests, load/performance tests, and a shadow‑trial report showing business outcomes against control cohorts. • Monitoring and controls: clear drift‑detection thresholds, alerting rules, escalation ladders, and the operations runbook. • Supplier assurances: signed contractual clauses for model portability, reversibility tests (proved with dry‑run reversibility artefacts), data handling and retention, escrow arrangements, breach notification times, and retraining obligations. • Acceptance criteria and conditional decisions: a short, explicit list the board can read in 10 minutes that states the pass/fail criteria and conditional approvals (for example: 'approved for 3‑site shadow trial only; not approved for national roll‑out until reversibility test passed').

Practical tests and failure modes leaders must understand

Demand tests that reify the RTM. Examples: (a) Reproducibility: the programme must recreate model outputs from the supplied code and frozen datasets in a controlled environment. Failure mode: vendor cannot reproduce claims or omits preprocessing code. (b) Re‑training and portability: the buyer or independent party must be able to retrain or convert the model using specified artefacts. Failure mode: missing provenance or licence prevents retraining. (c) Shadow trial with business outcome comparison: run live inputs through the model but route decisions to human teams for a defined period. Failure mode: drift or unacceptable false positives identified only in live data. (d) Adversarial/robustness testing: simulate poisoning and input manipulation. Failure mode: model fragile to simple perturbations. (e) Incident‑response dry run: simulate a model failure and exercise rollback to ensure reversibility works operationally. Failure mode: contractual reversibility exists but is operationally untested.

Each test must be mapped to a clear acceptance criterion in the pack: what metric(s) must be achieved, who signs the evidence, and what conditional mitigations apply if the test is marginal.

How to sequence board approvals and conditional sign‑offs

Boards must stop signing open‑ended approvals. Use conditional approvals: explicit, time‑boxed and evidence‑linked. For example: 'Approve limited use in a shadow trial for N sites, conditional on (1) independent reproducibility test pass, (2) supplier reversibility dry run passed, and (3) operational monitoring configured and staffed.' Only when those conditions are met should the board approve wider transition. If a condition fails, the board should have pre‑agreed options: fund remediation, limit scope, or require a roll‑back.

This sequencing aligns accountability: the programme commits to delivering artefacts and tests; suppliers commit to contractually backed reversibility and support; operational teams confirm staffing, and the board retains a small set of executable decisions instead of vague checklists.

Commercial and contractual levers that matter to acceptance

Technical evidence needs commercial teeth. Contract clauses should require demonstrable portability, reversibility and third‑party audit rights. Insist on: escrow of model artefacts, field‑tested reversibility acceptance tests tied to payments or milestone releases, clear breach notification windows aligned with the organisation’s incident response, and obligations to support re‑training or export of data. These clauses convert technical tests into enforceable remedies if the supplier cannot or will not deliver operationally.

Handover and transition into BAU: what good looks like

Handover is not a one‑line note. It is an evidence‑led set of confirmations: operational runbooks validated, monitoring alert fatigue measured and adjusted, staff trained and assessed, supplier support handover confirmed, and a post‑go‑live review date with a predefined remediation budget if drift or defects are detected. Boards should require a formal ‘stabilisation acceptance’ before full release of holdback funds and contract closure.

Antares recommended actions

These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.

1. Require a single indexed acceptance pack that maps every board requirement to a tested artefact and named owner; refuse to accept narrative summaries alone.
2. Make acceptance conditional: approve limited live trials only after independent reproducibility, supplier reversibility dry‑run and adversarial robustness tests pass. Escalate any single high‑severity failure to stop further rollout.
3. Contractually bind suppliers to model portability, reversibility tests, escrow of artefacts and rapid breach/rollback obligations; link milestone payments to demonstrable reversal and recovery tests.
4. Mandate a stabilisation acceptance gate before contract closure: predefined KPIs, no unresolved high‑severity incidents, monitoring operational and staffed, and a post‑go‑live remediation budget.
5. Require the board pack to include an RTM, DPIA signed by the DPO, model card and dataset provenance, adversarial/security tests aligned to NCSC ML principles, and a clear escalation ladder for drift or harm.