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.
- 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.
- 021 week
Tier and scope
Tier by potential harm with the business, so effort concentrates where a failure actually hurts someone.
- 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.
- 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.
| Deliverable | What it contains | When |
|---|---|---|
| Discovered AI inventory | Built 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 tiering | Each 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 1 | Full assessment of the highest-tier systems covering data, model, deployment context, oversight and failure modes. | Week 4-6 |
| DPIAs where required | Data 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 register | Origin, licensing, training-data position, change notification and support commitments for every third-party model in scope. | Week 6 |
| Prioritised remediation backlog | Findings 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?
When is a DPIA required for an AI system?
How do you assess a third-party model you cannot inspect?
How often should AI risk assessments be repeated?
Start
Three ways in, depending on how close the deadline is.
- Book it
Book a discovery call
Thirty minutes, no deck. We work out whether there is a real engagement here, and say so if there is not.
- Go
Check the EU AI Act applies
Six questions, a dated list of the obligations that reach you, and a calendar file so the deadlines land somewhere you will see them again.
- Go
Request a roadmap
You know the obligation and the deadline. We scope the sprints, the deliverables and the dates.
Or just email a human: hello@cloudgap.ai
We reply within24 hours