Risk changes continuously. Our understanding should too.

Adapted and expanded from my September 9 LinkedIn post.

I’ve been having a lot of conversations with people working across GRC, cyber risk, AI, and product. I like those conversations because they make me explain an idea out loud. Something that makes sense in my head still has to survive someone else’s questions.

On a recent call, we covered FAIR, third-party risk management, AI, and telemetry. I kept returning to the same observation: risk changes continuously. Much of the way we manage it still depends on a picture taken at a particular moment.

We assess a service, collect evidence, record a conclusion, and return to it later. In between, the service can change. Its controls can change. A vendor can gain access to more data. The business can become more dependent on something that used to be optional.

The assessment may have been reasonable when we completed it. The question is whether our understanding has kept up.

What changed since we last looked?

Consider a hypothetical supplier that initially supports an internal reporting process. A review finds limited access, a small amount of non-sensitive data, and a workable manual alternative.

Six months later, the business uses the same supplier to coordinate customer deliveries. Its integration has broader permissions. The team has stopped maintaining the manual process.

The supplier’s name has not changed. It may still hold the same certifications. But our dependency on it has changed substantially.

An updated permission record would tell us something useful. So would a revised service inventory, a new integration configuration, or a business owner explaining that the workaround is gone. Together, those observations could support a different account of what might go wrong.

That is the connection I want to make easier to maintain.

The pipeline has to carry meaning

A pipeline can collect records successfully without answering a useful risk question. Getting the data into one place is only the beginning.

First, preserve what the source actually reported: its identity, timestamp, and original record. Then check the structure and map fields into a consistent form. If two sources describe the same account differently, the pipeline needs an explicit way to resolve that relationship—or to record that it could not.

Next, connect the observations to business context. Which service does this account reach? What is that service expected to achieve? Which supplier, owner, or dependency is involved?

Only then do we have the ingredients for a candidate scenario. We can describe an observed condition, a plausible event, and a consequence for the objective we are trying to protect.

In the supplier example, broader access and an increased operational dependency might justify investigating whether a supplier compromise could interrupt delivery coordination or expose customer information. That is a question supported by specific evidence. It still needs review.

Where I want AI to help

I’m interested in using an LLM to examine bounded evidence, connect relevant observations, and propose scenarios that a practitioner can challenge.

The model should be able to show which records support its statement. It should distinguish an observation from an assumption. When evidence is missing or contradictory, that uncertainty should remain visible in the output.

For example, a record showing an active account does not establish that the account can still access the service. A claim about that access needs additional evidence. If the model cannot establish the relationship, a useful outcome may be a targeted question rather than a confident sentence.

The engineering work includes the rules around the model: what it can inspect, which tools it can call, how citations are checked, and what happens when its proposal fails those checks. Those controls make the reasoning inspectable. They do not make every proposed scenario true.

What continuous should mean

For this direction to be useful in a company, later evidence has to affect earlier conclusions.

A new record might strengthen a scenario. A corrected service mapping might change its business consequence. Evidence of an effective restriction might weaken it. A missing source might mean we have lost visibility rather than reduced risk.

Simply running the same prompt on a schedule would leave important work unfinished. We also need to know whether we are seeing the same scenario again, what changed, and why a reviewer’s earlier decision still holds—or needs another look.

That is a direction for development, with questions we need to test. It should not be confused with an already proven system for discovering every unknown risk in an organization.

Where Lab 01 starts

Lab 01 gives practitioners a repeatable way to inspect the first part of this process. It uses vendor-shaped mock records, business context, and a bounded agent workflow to produce cited candidate risk statements for human review.

The mock data makes the exercise accessible without requiring a company’s systems. It also limits what the exercise proves. A successful lab run demonstrates behavior on those examples; live collection, operational reliability, and discovery performance require further testing.

The lab focuses on identification. Evaluating likelihood and consequences, choosing a response, validating the change, and communicating the decision belong to the wider lifecycle I want to explore.

I want our understanding of risk to develop as the organization changes. The practical starting point is to make the evidence, context, questions, and revisions visible enough that someone can inspect them—and build on the work.