Project status updates often hide risks inside ordinary sentences. “Vendor review is taking longer than expected” might be a warning, an active issue, or simply context. ChatGPT can help collect these signals and turn them into a consistent working table. It should not decide the severity, promise a response, or assign an owner without evidence.
OpenAI’s ChatGPT documentation describes using attached files to summarize, compare, and extract information. The UK government’s Orange Book describes risk management as a structured process that includes identification, assessment, treatment, monitoring, and reporting. The workflow below is our recommendation, not a built-in risk-management feature: extract possible risks from approved updates, preserve the source, then let the project team validate every row.
Define the register before you upload anything
Start with the project’s existing risk method. If your organization already defines likelihood, impact, escalation levels, or required fields, use those definitions. Do not invent a second scoring system just because a prompt can generate one.
A useful register usually needs enough structure to support a decision without becoming a dumping ground. Consider these fields:
- Risk ID: a stable identifier that does not change when wording changes.
- Risk statement: cause, uncertain event, and potential effect.
- Source: the update, date, section, or quotation that triggered the row.
- Likelihood and impact: values from your approved scale, confirmed by a reviewer.
- Response: the planned treatment or control.
- Owner: the accountable role or person, confirmed by the team.
- Trigger and review date: what should prompt action and when the row is reviewed.
The Orange Book is principles-based rather than a universal template. Treat the fields above as a recommendation, then adapt them to your organization’s process.
Choose a narrow, traceable source set
Use a bounded set of status reports, meeting notes, decision logs, or delivery updates. Label every item before analysis, such as S-001 for the weekly status report and S-002 for the vendor update. Include the document date and reporting period.
Remove information that the analysis does not need, and follow your organization’s privacy, confidentiality, retention, and access rules. Confirm that the files are allowed in the ChatGPT workspace you are using. If one report refers to an attachment you do not have, record the gap instead of asking the model to reconstruct it.
You are preparing a source inventory for a project risk review.
For each supplied status update, list:
- source ID and date
- reporting period
- projects, workstreams, or milestones mentioned
- explicit blockers, dependencies, delays, assumptions, and unresolved decisions
- exact supporting sentence or section reference
Do not create risk ratings, owners, deadlines, causes, or mitigations. Mark missing context as [SOURCE GAP].Separate risks, issues, decisions, and routine work
A risk is uncertain. An issue has already happened. A decision is a choice that needs to be made. Routine work is neither unless uncertainty could affect an objective. Mixing these categories creates a register that is hard to use.
Ask ChatGPT to classify each signal, but make the categories provisional. A sentence such as “testing may slip if the environment is unavailable Friday” contains a potential risk. “The environment was unavailable Friday” is an issue. The project lead should confirm the classification.
Classify each extracted signal as:
1. candidate risk
2. current issue
3. pending decision
4. dependency
5. routine status
6. unclear
For every classification, cite the source ID and supporting text. Explain the minimum reason for the label. Do not infer facts that are not present. Keep unclear items in a review queue.Write risk statements without inventing causes
A risk statement is more useful when it links a documented cause to an uncertain event and a possible effect. The source may not contain all three parts. When it does not, leave a visible gap for the team.
Consider this fictional status update, S-003: “Security review has not started because the architecture diagram is incomplete.” The incomplete diagram and unstarted review are current issues. A future milestone delay is only a possibility, and no affected milestone is named. Route the existing issue to the issue log. Keep any related future risk incomplete until the team supplies the missing event and objective.
Draft one candidate risk statement for each item classified as a candidate risk.
Use this structure:
Because [documented cause], [uncertain event] may occur, which could affect [documented objective, milestone, cost, quality, or scope].
Cite the source ID after each clause. If a clause is not supported, write [TEAM INPUT NEEDED] instead of completing it. Do not add likelihood, impact, owner, response, or deadline.Deduplicate carefully and preserve differences
Weekly updates often repeat the same concern. Group candidate risks by cause, event, and effect, not by similar wording alone. Two vendor delays may require different owners, contracts, or responses. One risk may also appear in several sources, which strengthens traceability but does not prove severity.
Compare the candidate risks and propose duplicate groups.
For each group, show:
- every candidate risk ID
- shared cause, uncertain event, and effect
- important differences in scope, timing, owner, dependency, or response
- recommendation: merge, keep separate, or needs review
Do not merge rows when any difference could change ownership, treatment, escalation, or reporting.Score and assign only with human confirmation
The project team should apply the approved likelihood and impact scale. The Orange Book stresses clear roles, informed decision-making, and useful reporting. A government Gate Review guide also identifies likelihood, mitigation, residual risk, and a RAID log as evidence of risk management. These sources support disciplined review, not automatic scoring by a model.
If you use ChatGPT during the review, give it the exact scoring definitions and ask it to identify which evidence is missing. Do not accept a score simply because the explanation sounds plausible.
Using only the approved scoring definitions below, prepare a review worksheet for each candidate risk.
Include:
- evidence that could support each likelihood level
- evidence that could support each impact level
- missing facts needed for a decision
- proposed owner role only when the source explicitly names responsibility
- questions for the project team
Do not select the final score or assign an owner. Leave those fields [HUMAN DECISION].Test the register against the source set
Run two checks. First, trace every register row back to at least one source. Second, trace every extracted blocker, dependency, delay, assumption, and unresolved decision forward to either a risk row or another named log. This catches unsupported entries and dropped signals.
Then review for stale wording, duplicate ownership, vague responses, missing triggers, and dates that came from inference rather than evidence. High-impact risks deserve extra scrutiny even when they appear only once.
- Every row has a stable ID and source reference.
- Issues and decisions were routed to the correct log.
- Cause, event, and effect are supported or visibly incomplete.
- Duplicate groups preserve material differences.
- Likelihood, impact, and ownership were confirmed by people.
- Responses have accountable owners and review triggers.
- The source-to-register and register-to-source checks both pass.
ChatGPT can accelerate extraction, normalization, and comparison. The project team remains responsible for risk acceptance, prioritization, ownership, and escalation.
Want more practical AI workflows with built-in checks? Join ZippByte Weekly for concise prompts and verification habits you can adapt to your own work.