How to Get Started with AI Risk Assessment

Most organizations know they need to assess their AI systems. Far fewer know where to start. The topic feels big and new, so it waits. Meanwhile the models, the agents, the integrations keep shipping.

Here is the good news. You do not need a new discipline to start. AI risk assessment follows the same logic as any risk work. You find what you have. You gather data. You estimate how likely a bad event is. You estimate how much it would hurt. You calculate risk. What changes is the asset you look at and the scenarios that go wrong.

You cannot assess what you cannot see.

Below is a five-step way to begin. Each step maps to the NIST AI Risk Management Framework (AI RMF 1.0): the voluntary framework NIST published in January 2023.

Step 1: Start with an AI asset inventory

You cannot assess what you cannot see. So find what you have:

Models (LLMs, classical ML models, model APIs)
Datasets (training, fine-tuning, inference/retrieval data)
AI-powered applications and features
Third-party AI integrations and vendor APIs
Prompt libraries and system prompts
Agents and automation workflows
Infrastructure behind the AI (vector databases, GPUs, pipelines)

Structure it as an AI Bill of Materials (AI-BOM). It is the same idea as a software bill of materials (SBOM), extended to cover models, datasets, and their provenance. This is a real direction, not a buzzword:

CycloneDX supports a Machine Learning Bill of Materials (AI/ML-BOM) as of spec v1.5. It covers models, datasets, and configurations.
SPDX 3.0 added formal AI and Dataset profiles to describe ML components in a machine-readable format.
CISA and G7 partners published Software Bill of Materials for AI: Minimum Elements as baseline guidance.
The OWASP AI-BOM project is building community guidance on what an AI-BOM should contain.
For a single model, a Hugging Face model card is a ready-made source of metadata: intended use, training data, limitations. Pull it straight into your inventory.

One honest note. The tooling is still young. There is no push-button “AI-BOM generator” yet. You assemble the inventory from these standards plus your own asset data. But the standards give you a real format to aim at. That is where AI risk assessment starts.

Step 2: Gather data for risk analysis

Once you know what you have, gather the data that drives the analysis. The data also tells you which kind of assessment you can credibly run:

Quantitative: numbers-based, in frequency and dollars
Qualitative: ratings-based (high/medium/low), useful when data is thin

When usable data exists, go quantitative. It is more defensible and more useful. It hands leadership dollar ranges and probabilities instead of colored boxes. It is not automatically more precise (bad inputs still produce bad outputs), but done well it is far easier to act on and to defend. Good sources:

Threat intelligence reports
Industry incident and breach reports
Internal incident data
Red team findings
Testing and evaluation results

More grounded data, stronger estimates.

Step 3: Use simulations for likelihood estimation

This is where it gets interesting. Do not guess likelihood as a single number. Model it as a range and simulate it. You can:

Run Monte Carlo simulations over your estimated inputs
Use Python libraries such as SciPy to sample distributions
Model the frequency of attack scenarios
Estimate probability of failure

This is the logic behind FAIR (Factor Analysis of Information Risk), the open standard for quantitative cyber risk. FAIR splits risk into Loss Event Frequency and Loss Magnitude. Then it uses Monte Carlo sampling to produce a distribution of losses instead of one fragile point estimate. If your approach already looks like this, you are doing FAIR-style analysis.

I have used SciPy this way before. I ran simulations for phishing scenarios to estimate how often they occur. The same logic maps straight to AI-specific risks. Those risks are catalogued in the OWASP Top 10 for LLM Applications (2025):

Prompt injection (LLM01:2025)
Data leakage / sensitive information disclosure (LLM02:2025)
Model misuse / excessive agency (LLM06:2025)
Hallucination-driven decisions / misinformation (LLM09:2025)

This turns assumptions into numbers you can compare.

Step 4: Estimate impact

For impact, ground the numbers in real references:

Threat intelligence reports
Industry breach-cost reports
Regulatory penalty schedules
Operational downtime estimates

Then translate them into the terms leadership cares about:

Financial impact
Operational impact
Compliance impact
Reputational impact

Step 5: Calculate risk

Now you have likelihood and impact. Calculate risk, then act:

Prioritize risks (highest expected loss first)
Define mitigation strategies
Implement controls
Monitor continuously

Monitoring matters more with AI than with static software. Models drift. Prompts change. New integrations appear weekly. Your inventory and your estimates are living documents.

How this aligns with the NIST AI RMF

The approach maps onto the four core functions of the NIST AI RMF 1.0:

Govern: accountability, roles, and AI risk ownership (this runs across every other step, not just at the start)
Map: identify AI assets, data flows, and dependencies (your AI-BOM step)
Measure: assess risk quantitatively or qualitatively (your simulations and data analysis)
Manage: implement controls, mitigation, and continuous monitoring

Start small and you are already aligned with a recognized framework. That makes the work easier to explain, defend, and scale.

Where to start this week

Pick one AI system you run in production. Build a one-page AI-BOM for it. List the top four OWASP LLM scenarios that actually apply. That single page is a real AI risk assessment in miniature. Everything above is just how you deepen it.

What are You Looking For?