Most risk registers get written after the fire.

Most risk registers get written after the fire.

Budget blow, a broken pipeline, a model that starts making things up. By then you are writing a diary. AI projects have extra ways to fail that a generic matrix misses: hallucinations, bad training data, token bills, a vendor that vanishes, a privacy leak. Those are live, not theoretical.

The same tools you are using on the work can look at your own history and flag the patterns that usually come before a miss. That is not a crystal ball. It is a score you can argue with.

Use the misses, not just the wins

One InnovateAI participant built a scoring model from two years of business-development outcomes. First pass was too kind. The file only had the wins. He added companies that had large layoffs as the other pile. The contrast made the score useful.

Do that for projects. Feed a model the last two years, including the ones that slipped, blew budget, or died. Ask what starting conditions showed up before the bad ones. Team size, data quality, vendor age, integration mess, whether anyone owned governance.

Four things worth watching

How often the model claims something it cannot show. Sensitive data in prompts: names, health, trade secrets. Token spend against a daily cap. Vendor health: funding, adoption, whether the API stays up. A language model plus a spreadsheet can turn that into a 1-to-10 score. You do not need a data-science bench.

A score of eight means this looks like things that failed. It does not mean it will. A person still decides: shrink the scope, add review, or pause. Start with one file and one score. Better than waiting for the fire.