How to use AI for project status reports without losing control

AI can make a project status report cheaper to assemble, but it should draft and reconcile the update rather than decide what is true. Give it dated source material, require it to expose conflicts and missing evidence, and keep a named person responsible for the final judgement and send. The useful question is not whether the prose sounds polished. It is whether every material statement can be traced to a source and approved by someone who understands the work.

This is a source-based guide, not a claim about results from a particular client. For a firsthand account of a broader personal workflow, see A PM with an agent chief-of-staff. The reporting pattern below is intended for delivery leads who already have project data spread across tickets, decisions, risks and meeting notes.

Give the draft a controlled evidence pack

Start with a reporting period and a small set of authorised inputs: the previous approved report, work items changed during the period, the current risk and decision logs, milestone dates, and approved meeting notes. Record the source timestamp and system version where it matters. Do not pour entire mailboxes, chats or raw production traces into a prompt. That increases both privacy exposure and the chance that old discussion is mistaken for a current decision.

• State the reporting period, audience and decision the report supports.
• Define which sources are authoritative for scope, dates, progress, risks and cost.
• Exclude secrets, personal data and conversational material that has no reporting purpose.
• Preserve source references so a reviewer can inspect the evidence behind each claim.

Reconcile before writing

The first AI task should be comparison, not composition. Ask it to list what changed since the last approved report, where sources disagree, which planned items have no evidence of completion, and which new risks lack an owner. A ticket marked done does not prove that a business outcome happened. A meeting note does not override the system of record unless an authorised decision changed it.

Illustrative reconciliation

Milestone: catalogue migration
Plan: complete 4 September
Work tracker: 18/20 tasks complete
Decision log: launch moved to 6 September

Draft conclusion: AMBER
Conflict to resolve: plan date is stale
Missing evidence: reconciliation of the final two tasks
Human decision needed: approve revised date and owner

The example is deliberately plain. The model has not inferred that the milestone is complete or selected a new date. It has made the disagreement visible and handed the decision back to the accountable person.

Draft the project report in six parts

Once conflicts are visible, ask AI to draft an ordinary project report. Keep each section tied to evidence and make unknowns explicit. The structure should help a reader understand what changed, what is likely to happen next and where a decision is required:

• Milestone and scope progress: what was planned, what has evidence of completion, and what moved in or out of scope.
• Schedule forecast: the current forecast, the evidence behind it, and the assumption or unresolved conflict that could change it.
• Risks and issues: impact, likelihood where known, mitigation, owner and the point at which escalation is required.
• Dependencies: what is needed from another team or supplier, who owns the handoff, and the date it becomes critical.
• Decisions needed: the exact choice, decision owner, deadline, available options and consequence of delay.
• Next actions: a short list with one named owner and due date for each action.

Monitor the AI workflow separately

Keep the drafting system's measures outside the project report unless that workflow is itself in scope. In a separate monitoring record, track evaluation results, human corrections, failures, latency, token use and cost, plus sample size and relevant model, prompt and tool versions. Anthropic's evaluation guide recommends task-specific graders, regression suites and calibrated human review. Microsoft's tracing documentation describes operational signals and notes limitations for some preview tracing paths. These measures show whether drafting is dependable; they do not show project progress.

Make approval an explicit stage

The reviewer should check each red or amber statement, every date change, claimed completion, cost comparison and external commitment. They should also inspect what the draft omitted. Approval needs a name and timestamp; silence is not approval. The AI should have no route to send the report, change a project record or conceal an unresolved conflict while the workflow is being established.

• Reject unsupported completion and savings claims.
• Replace false precision with the evidence range or mark the value unavailable.
• Confirm that every material risk and action has a named owner.
• Keep sensitive prompts and tool payloads out of the distributed report.
• Archive the approved report and the evidence references used to produce it.

Know the limits

This workflow cannot repair weak project records. It can repeat a confident but wrong status, miss work that lives outside the authorised sources, or make a stale plan sound current. The NIST Generative AI Profile frames governance, context, measurement and ongoing management as connected work. That is the right expectation here: reporting is a control loop, not a weekly writing trick.

If the team cannot identify authoritative sources, an accountable approver and a correction path, fix those first. If it can, AI can remove much of the copying and formatting while leaving the decisions where they belong. I also cover this distinction in speaking and workshops for delivery teams deciding how far to take AI-assisted work.