Scalexa Consulting / practical guide

AI Platform Risk Audits: A UK Founder’s Pre-Deployment Guide

An AI platform risk audit is an evidence-led review of the AI system and the platform around it before deployment. It is not a model score, a generic governance checklist, or legal sign-off. For a UK founder or CTO, the useful question is whether the intended use case, data, suppliers, controls, human decisions and operating arrangements are understood well enough to make a responsible launch decision.

Set the boundary around the AI system and use case

Start with the use case, not the model name. Describe who will use the system, what decision or task it supports, what happens when it is wrong, and which users or customers could be affected. Then map the complete chain: model and provider, prompts and retrieval, application interfaces, data stores, human review, production and non-production environments, and the teams that operate them.

Record the platform boundary and the exclusions. A hosted model, an internal tool, an AI-assisted customer journey and a fully automated decision have different risk questions. Before deployment, the team should be able to say what must be true, what evidence supports it, and who has authority to delay the launch when the evidence is not sufficient.

Define before inspecting

The intended users, use case, affected journey, business consequence and unacceptable outcomes.
The model, provider, data flows, interfaces, environments, support path and human decision points.
The production boundary, explicit exclusions, assumptions and evidence owners.
The conditions that must be met before deployment and the person who can make that decision.

Check data, privacy and information governance

Trace every important input and output. Establish where data came from, whether its use is expected, what is retained, who can access it, and whether it is sent to a model or supplier. Keep training, evaluation, retrieval and live inference data distinct in the record where they have different purposes or controls. Sensitive data needs an explicit handling decision rather than an assumption that a provider or library has made the question disappear.

For a UK deployment, ask the appropriate privacy and legal owners how applicable data protection duties, a DPIA and required records should be handled. Capture the decision and its evidence, including retention, deletion, access and data-subject considerations where relevant. This is a technical decision aid, not legal advice, and an audit cannot certify compliance.

Evidence to trace

Data provenance, purpose, quality, minimisation, retention, deletion and access decisions.
A clear separation of training, evaluation, retrieval and live inference data where applicable.
Sensitive-data handling, supplier terms, transfer considerations and the owners of privacy evidence.
The applicable privacy assessment, records and review decisions, with legal questions routed to the right adviser.

Review security and third-party exposure

Follow identity and access through the AI path: production, prompts, retrieved context, model credentials, logs, evaluation sets, deployment systems and support tools. Review secrets, tenant isolation, input and output handling, prompt-injection and other abuse cases, and the evidence that an incident can be detected and contained. Ask what a compromised account, malicious input or unsafe provider response would expose.

Treat model and hosting suppliers as part of the platform boundary. Record the provider, service version, locations and material dependencies that matter to the use case, then set an owner for changes in terms, models, dependencies and hosting. The question is not whether a supplier removes risk; it is whether the business knows the exposure, its fallback and its route to escalation.

Security questions to answer

Which identities and services can access prompts, context, outputs, data, secrets and deployment paths?
How are input, output, logging, isolation, abuse cases and incident routes tested and reviewed?
Which model, hosting, dependency and service changes need review before they reach production?
What happens when a provider is unavailable, compromised, materially changes or returns an unsafe result?

Evaluate model and product behaviour

Test the behaviour users will experience, not only the model in isolation. Use representative cases, important edge cases, known failure modes and realistic context. Set quality and accuracy thresholds for the use case, test unsafe or misleading outputs, and investigate possible bias or uneven performance across affected groups. A benchmark result is useful only when it connects to the product decision the system supports.

Keep model evaluation distinct from whole-platform readiness. A model can perform well on a test set while the surrounding retrieval, permissions, prompt construction, user interface, fallback or monitoring remains unsafe. Pin the model and evaluation version, record limitations, and define how drift, provider changes and production feedback will trigger a review.

Separate model evidence from platform evidence

Representative test sets, edge cases, expected outputs, quality thresholds and known limitations.
Tests for unsafe, misleading, biased, adversarial and out-of-scope inputs relevant to the use case.
Versioned evaluation evidence covering the model, prompts, retrieval context and product flow.
Monitoring and review triggers for drift, model or provider changes, user feedback and incidents.

Test human oversight and operating ownership

Name the people who can approve release, review outputs, handle exceptions and pause or override the system. Make the hand-off visible in the product and the operating process: a human reviewer cannot provide meaningful oversight if they cannot see the relevant context, understand the limits or act before harm compounds.

Define what happens when a user disputes an output, a customer asks for an explanation, an operator sees a pattern or an incident affects people. Record escalation, communication and training responsibilities. Accountability should be practical and owned by named roles, with a route to change the system when the evidence shows that the current arrangement is not working.

Make oversight real

A named release approver, output reviewer, incident owner and person authorised to pause or override.
Clear exception, appeal, escalation and communication paths for affected users or customers.
Enough context, training and tooling for reviewers to make and record a meaningful decision.
A post-launch review date and a way to change ownership when the use case or risk changes.

Check reliability and deployment controls

AI features add operational boundaries that a demo can hide. Set expectations for latency, cost, throughput and capacity, then observe them in the journey that matters. Check what the product does when a provider is slow or unavailable, a quota is reached, a dependency changes or an output cannot be trusted. A safe fallback may be a simpler path, a human hand-off or a deliberate pause.

Review deployment controls: version pinning, approvals, environment separation, rollback or forward-fix, backup and recovery where relevant, and post-launch monitoring. The team should be able to connect a change to its evidence and reverse or contain it when the result is not as expected.

Test the operating path

Observable latency, cost, capacity, availability and quality boundaries for the intended journey.
Fallbacks for provider failure, unsafe outputs, quota limits, dependency changes and human hand-off.
Version pinning, release approvals, environment separation and a tested rollback or pause path.
Relevant backup, recovery, incident and post-launch review evidence with named owners.

Turn findings into a launch decision

Bring the evidence together in a register that a founder, CTO and delivery team can use. Each finding should name the affected journey, evidence, consequence, severity or impact, owner, remediation option, review date and residual risk. Distinguish an observed issue from an assumption or missing evidence so that “we do not know” remains visible rather than becoming an accidental approval.

The outcome can be go, fix, investigate or pause. A launch decision is responsible when it states why, what must happen next, who owns it and when it will be revisited. The audit should make the next decision clearer, not imply that every uncertainty can be removed before a system is used.

Pre-deployment checklist

The use case, platform boundary, data flows, suppliers, exclusions and evidence owners are recorded.
Data, privacy, security, model behaviour, oversight and operating controls have an accountable owner.
Known limitations, fallback behaviour, monitoring, versioning, rollback and incident routes are tested or explicitly open.
Every material finding has an affected journey, impact, owner, option, review date and residual-risk decision.
The launch outcome is explicit: go, fix, investigate or pause, with a named decision-maker.