Skip to content

AI Security

AI risk assessment

What this is

AI risk assessment identifies the artificial intelligence systems in use across an organisation, including undeclared shadow AI, and evaluates each against the harm it could cause. It covers system inventory, criticality tiering, model and data provenance, and the impact assessments required under ISO 42001, the EU AI Act and UK data protection law.

The problem

Every AI inventory built from a survey is wrong, and the gap is where the risk lives.

Ask team leads to list the AI their teams use and you get a list. It will contain the obvious things - the copilot, the model behind the product feature, the vendor tool with AI in its name. It will not contain the consumer chatbot somebody has been pasting customer emails into, the vendor feature that quietly became AI at the last release, or the model a departed contractor stood up and nobody decommissioned.

The systems missing from the survey are disproportionately the risky ones, because the reason they are missing is that nobody thought of them as AI systems requiring governance. That is precisely the population where data is leaving without a contract, where a decision affecting a person is being made without oversight, and where no impact assessment exists.

Then the assessment itself needs proportion. Applying the same rigour to a model that reorders search results and a model that screens candidates wastes effort on one and under-protects the other. Tiering by potential harm is what makes the programme finishable.

Who this is for

  • Organisations that need an AI inventory they can defend rather than one assembled from a survey.
  • Teams facing an ISO 42001 audit, where an incomplete scope is the most common Stage 2 failure.
  • Companies deploying AI in decisions affecting individuals, where a DPIA is mandatory before processing begins.
  • Firms consuming third-party models who cannot currently answer provenance or licensing questions.
  • Anyone who has been asked by a customer which AI systems process their data.

Delivery

How the engagement actually runs

Sprints inside your engineering cycle, with findings arriving continuously rather than a report arriving at the end. Durations are elapsed time for a typical scope, and get re-scoped against your estate before anything is committed.

  1. 011-2 weeks

    Discovery sweep

    Four parallel routes to find AI in use. Expect the inventory to be materially larger than the survey suggested; that difference is the point of the exercise.

  2. 021 week

    Tier and scope

    Tier by potential harm with the business, so effort concentrates where a failure actually hurts someone.

  3. 032-4 weeks

    Assess tier 1

    Full assessment of the high-tier systems, including DPIAs where the processing requires one. Findings delivered as they land.

  4. 041 week

    Hand over the method

    Your teams take over the assessment for new systems, using a methodology sized to your release process rather than ours.

Deliverables

What you actually receive

Artefacts your team owns and can maintain after the engagement, not a report that ages the moment it lands.

Deliverables for AI risk assessment, with what each one contains and when it lands
DeliverableWhat it containsWhen
Discovered AI inventoryBuilt from SSO logs, expense data, network signal and structured interviews - four routes, because no single one is sufficient. Includes shadow AI and vendor AI features.Week 2
Criticality tieringEach system tiered by potential harm: who is affected, how reversible the outcome is, and whether a human is genuinely in the loop.Week 3
Risk assessments, tier 1Full assessment of the highest-tier systems covering data, model, deployment context, oversight and failure modes.Week 4-6
DPIAs where requiredData protection impact assessments for processing likely to result in high risk, which covers most AI touching personal data. Written to be defensible to the ICO.Week 5-7
Model and supplier provenance registerOrigin, licensing, training-data position, change notification and support commitments for every third-party model in scope.Week 6
Prioritised remediation backlogFindings as a working backlog with owners and dates, in your tooling, rather than a risk report with a heat map.Week 7

Frameworks this touches

FAQ

Questions people actually ask

What is shadow AI?

Shadow AI is artificial intelligence in use inside an organisation without governance, approval or often awareness. It includes staff using consumer AI tools on company data, AI features enabled inside SaaS products the organisation already pays for, models deployed by individual teams outside any review, and systems left running after the person who built them moved on. It is consistently a larger population than the declared inventory.

When is a DPIA required for an AI system?

A data protection impact assessment is mandatory under UK GDPR where processing is likely to result in a high risk to individuals. The ICO's criteria include innovative technology, large-scale profiling, automated decision-making with legal or similarly significant effects, and systematic monitoring - and most AI touching personal data hits at least one. The DPIA must be completed before processing begins, which is the requirement most often missed.

How do you assess a third-party model you cannot inspect?

By assessing what you can establish and documenting what you cannot. That means the provider's published documentation and model cards, contractual commitments on data use and change notification, evaluation of the model's actual behaviour on your inputs including adversarial ones, and the controls you place around it - input filtering, output review, human oversight. Where provenance cannot be established, that is itself a finding to record and decide on, not a gap to leave silent.

How often should AI risk assessments be repeated?

Assessment should be triggered by change rather than by calendar. A new system, a material change in how an existing system is used, a model version update, a change in the data it processes, or a change in the provider's terms should each trigger reassessment. A periodic review of the whole inventory annually catches drift, but calendar-only review means a system that changed in February is assessed in November.