A Control Framework for AI-Generated Project Forecasts

A programme forecast says there is a 73.4% chance of achieving a milestone. The number looks authoritative: a dashboard supplies a probability, a predicted completion date, and a short explanation. But the steering group cannot answer basic questions. Which projects trained the model? Are they comparable? How often did its “80% confidence” range contain the actual result? What changed in the programme since the data was collected? Who is allowed to disagree—and where will that disagreement be recorded?

The problem is not that the forecast is AI-generated. The problem is that it is being treated as truth rather than as a decision input: evidence that may inform a human decision but is subject to defined limits, challenge, and monitoring.

This distinction is becoming more urgent. In a 2026 Association for Project Management survey of 1,000 UK project professionals, 27% said AI was fully embedded in their workflow and 25% said it supported predicting outcomes and improving forecasting accuracy. That is evidence of reported use, not independent evidence that any model is accurate. APM, 2026 The right response is not to ban AI forecasting or to accept it on faith. It is to control it in proportion to the decision it may influence.

Start with the decision and the cost of being wrong

Before asking whether a model is sophisticated, identify the decision it supports. Is it helping a workstream leader decide where to investigate? Is it shaping a sponsor’s decision to release contingency? Is it triggering a contractual notice, a resource move, or a public commitment?

Those uses do not deserve the same controls. A low-consequence signal that tells a controls analyst where to look can begin as an advisory prompt. A forecast that changes funding, scope, safety, or a material external commitment needs stronger data evidence, review, documentation, and escalation.

Record four facts first:

1. Decision: what a person or authority may decide differently because of the forecast.
2. Consequence of error: the plausible cost of a false alarm and of a missed deterioration.
3. Reversibility: whether the decision can be readily undone after new evidence arrives.
4. Use status: whether the forecast may inform, advise, limit a choice, or initiate an action.

The Government Accountability Office groups accountable AI practices around governance, data, performance, and monitoring. GAO, AI Accountability Framework This is a useful control lens for project delivery: the model is not a reporting add-on if its output can change a real decision.

Do not call every AI output a forecast

“AI forecasting” covers materially different capabilities. Treating them as interchangeable creates false assurance.

Decision input	What it does	What it cannot establish on its own
Statistical baseline	Applies an explicit historical rule or reference class to estimate a likely outcome	Whether current conditions still resemble the history
Predictive or machine-learning model	Learns a relationship between defined inputs and a labelled outcome	Whether the relationship generalises to this programme or remains stable
Generative interpretation	Summarises status, extracts signals, explains patterns, or proposes scenarios from supplied material	A statistically validated probability, causal explanation, or reliable future date
Tool recommendation or agent	Combines one or more inputs into a suggested action, prioritisation, or alert	That the recommendation is authorised, complete, or suited to the decision context

This is a Strategica classification, not a technical taxonomy. Its practical value is simple: ask what evidence belongs to the actual method. A generative assistant that explains a risk register may help a reviewer notice a contradiction. It is not thereby a predictive model. Conversely, a machine-learning forecast may provide a probability but still need a human to interpret data gaps, changed conditions, and decision consequences.

Establish data readiness before you evaluate the output

Forecast errors are often blamed on the model when the deeper failure is the data definition. A schedule variance prediction is only meaningful if the organisation can state what “schedule variance” means, when it is measured, which project population it represents, and how missing or changed records are handled.

Ask these data-readiness questions:

Control question	Why it matters
What is the target?	“Late”, “over budget”, or “at risk” can have several definitions; a model needs one observable outcome.
What is the provenance?	Name the systems, owners, rights, extracts, transformations, and exclusions.
Is history comparable?	A completed construction project, software product, regulatory programme, and emergency response may share labels but not operating conditions.
What is missing or biased?	Missing actuals, optimistic status updates, inconsistent baselines, and unrecorded changes can distort learning.
Did the regime change?	New suppliers, policy, technology, funding rules, or delivery methods can make old patterns a poor guide.
Is there leakage?	Information unavailable at the forecast date must not quietly enter training or evaluation.

Project forecasting research makes the case for this discipline even without AI. Research on activity uncertainty stresses the use of completed empirical data, recognises human bias and heterogeneity, and places project-manager knowledge before statistical analysis when clustering comparable activities. Vanhoucke et al., 2020 A separate 2024 empirical study of 100 projects found that project characteristics could help indicate expected duration-forecast accuracy. Andrade and Vanhoucke, 2024 Neither study validates an AI tool. They reinforce the point that historical project data is not automatically a homogeneous, decision-ready training set.

Demand uncertainty that can be checked

A point forecast has a role, but a precise number can hide the uncertainty that matters to a sponsor. Ask for a range, the meaning of that range, and evidence that it is calibrated.

If a model labels a range “80%,” then, in relevant validation conditions, actual outcomes should fall inside comparable 80% ranges roughly eight times out of ten. That property is called calibration. It is different from a model being generally accurate, and it is not guaranteed by displaying a confidence score. Technical research shows that nominal uncertainty estimates can be miscalibrated because of model misspecification and approximation; calibration methods seek to align stated coverage with observed outcomes. Kuleshov, Fenner, and Ermon, 2018

For a project-controls audience, the operational question is not “does the model use advanced uncertainty quantification?” It is:

• Which completed or held-out forecasts were tested?
• Over what period and in which project types?
• What was the observed error and range coverage?
• Where did coverage fail—at early stages, in large projects, after a policy change, or in a particular delivery model?
• What happens when the current programme sits outside that validated context?

NIST’s AI Risk Management Framework similarly treats suitability, validation, documentation, human-AI roles, monitoring, and lifecycle governance as connected controls. NIST, AI RMF Core It is voluntary guidance, not a project-forecasting accuracy certificate. But it is a strong reason not to accept a confidence label without the evidence behind it.

Use a six-part AI forecast control record

Before an AI output affects a material project decision, create an AI forecast control record. This Strategica framework translates the decision, data, and model evidence into a traceable control.

Component	Minimum record
Purpose	Decision, consequence of error, reversibility, owner, delegated authority, and permitted use status
Data	Sources, rights, time window, target definition, transformations, missingness, comparability, exclusions, bias, and regime-change concerns
Uncertainty	Forecast version and method; point/range; validation period; error and coverage evidence; assumptions and known limits
Review	Named project-controls reviewer; challenge questions; evidence checked; acceptance, rejection, or escalation threshold
Override	Decision-maker, reason, alternative considered, date, and whether the override changes this decision or triggers a model/data review
Monitoring	Actual outcome, error, range coverage, drift signal, override pattern, incident, and recalibration or retirement trigger

The record makes an important distinction between review and override. A review tests whether the forecast is fit to influence this decision. An override records a decision not to follow it, or to follow a different interpretation, after considering the evidence. Both are legitimate. Hidden overrides make it impossible to learn whether the model, the data, the human judgement, or the decision context needs to change.

Work through one disclosed scenario

Consider a hypothetical programme that wants an AI model to estimate the chance that a critical integration milestone will slip by more than four weeks in the next quarter. Its sponsor may release a small mitigation budget if the risk crosses a defined threshold. This is a consequential but reversible decision, so the model begins in advisory mode.

The control record states that the target is “actual milestone completion more than 28 calendar days after the approved forecast at the start of the quarter.” Its data sources are an integrated schedule, dependency register, defect trend, decision log, and delivery capacity record. The controls team excludes projects whose baselines were never approved and flags a recent supplier change as a possible regime change.

The model returns a 58% probability with a 35%–78% range. The reviewer does not ask only whether the number exceeds a threshold. They ask whether the current programme resembles the validated data; whether a critical dependency has been recorded consistently; whether the range was calibrated on similar work; and whether the generative explanation has introduced any claims not present in the source records.

The reviewer accepts the output as one input, alongside an independent schedule review. The sponsor funds an integration rehearsal but does not rebaseline the programme. The decision log records the forecast version, range, evidence reviewed, decision, and reason. At quarter end, the team records the actual outcome and whether it fell within the stated range. If the programme had moved to a new platform during the period, the team also tests whether that change invalidated the comparison with historical cases.

This example is hypothetical. It does not show that a 58% forecast is useful or that a mitigation budget should be released at any particular threshold. It shows the evidence and learning trail that should exist before leaders treat a probability as decision-relevant.

Watch for five predictable failures

Automation bias occurs when a polished output receives more weight than incomplete operational knowledge. Counter it with explicit challenge rights and an independent evidence source.

False precision occurs when a date or probability hides untested assumptions. Counter it with ranges, validation evidence, and a clear use status.

Stale-model risk occurs when the data-generating conditions change. Counter it with drift and regime-change triggers, not a fixed annual review alone.

Hidden overrides occur when experienced leaders silently disregard the tool. Counter them with a short override log; this is learning data, not an attempt to force compliance.

Feedback contamination occurs when model outputs alter the records later used to evaluate or retrain the model. Counter it by retaining forecast versions, decision dates, data snapshots, and the distinction between observed outcomes and AI-influenced actions.

Pilot conservatively; scale on evidence

Start with a limited, advisory use case. Do not let the forecast independently trigger a material funding, contractual, safety, employment, or public commitment decision. Set a pilot period, a baseline or comparator, a review cadence, and a stop condition.

Scale only when the organisation can demonstrate that the forecast is useful in the defined context, its ranges and errors are understood, reviewers can challenge it, overrides are traceable, and monitoring has not exposed a condition that invalidates it. Pause or retire the system when data rights are unclear, comparability fails, error or coverage becomes unacceptable, human review becomes performative, or a material incident reveals an unowned risk.

The test is not whether AI can produce a forecast. It is whether the organisation can explain, challenge, and learn from the forecast before it changes a consequential decision.

Sources and editorial limits

• Association for Project Management, AI becomes increasingly embedded in project delivery, 2026 and Digital transformation and the AI imperative in public and private sector projects — current project-profession survey/research summaries; they do not validate forecast accuracy.
• NIST, AI RMF Core and GAO, AI Accountability Framework — transferable governance guidance, not project-controls standards or legal advice.
• Kuleshov, Fenner, and Ermon, Accurate Uncertainties for Deep Learning Using Calibrated Regression — technical uncertainty research, not project forecasting evidence.
• Vanhoucke et al., 2020 and Andrade and Vanhoucke, 2024 — non-AI project-forecasting research applied here for data, bias, and expected-accuracy principles.

No named tool was tested and the integration-milestone scenario is hypothetical. The control record needs project-controls and data/model-risk review, plus privacy, security, contractual, regulatory, and sector-specific validation before operational use.