AI in project management means the use of a language model, or a tool built on one, in the ordinary work of running a project. The 2026 examination content outline made the subject testable for the first time, and it sits in the Business Environment domain. A language model is a fast, confident and occasionally wrong writer with no stake in the outcome. That description is enough to work out most of what it should and should not be doing on a project, and it is more useful than either the enthusiasm or the dismissal currently on offer.
The sections below take six common tasks and show where the line falls, describe where a model helps and where the help runs out, and then cover the three questions that come with putting project material into one, which are accountability, confidentiality and the habits hidden in historical data.
Six tasks and where the line falls
The line is easier to see across several tasks at once than in the abstract. What moves down the table is how much of the answer lives in material that can be handed over, and how much lives in judgement about people, money and consequence.
| Task | Does a model help today | What the project manager stays accountable for |
|---|---|---|
| Drafting documentation | Substantially. The saving is the blank page, and the thinking stays with the writer | That every figure, date and commitment in the draft is true, and that the tone suits the audience receiving it |
| Summarising status | Yes, where the source is held and it is clear what was dropped | Deciding what the summary means, and escalating the item the summary flattened into a clause |
| Pattern finding in historical estimates | Yes, and this is one of its stronger uses | Judging which patterns still apply, given what has changed in the organisation since the record was made |
| First pass risk identification | Yes, as a prompt for the people who know this project | Which of the candidate risks are real here, what the responses are, and who owns each one |
| Stakeholder judgement | Barely. What decides it is absent from any text that could be supplied | The whole of it, including the history between two directors that appears in no document |
| A contract award decision | Use it to structure the comparison, and never to make the call | The award itself, the audit trail behind it, and the defence of it to a losing bidder or a regulator |
Two readings come out of that table. The top four are places where a draft gets checked against material where being wrong is detectable, which is the condition that makes the help safe. The bottom two are decisions where the accountability column is the whole row.
Where a model helps today
The top four rows deserve a closer look.
Drafting documentation. A status report, a change request, a risk register entry, a closure summary. Given the project manager's notes and the house format, a model produces a first draft in a fraction of the time, and the saving is entirely in the blank page.
Summarising status. Turning a long thread, a set of team updates or an hour of meeting notes into something readable. This works because the source material is in front of the reader, who can tell when the summary has dropped the one sentence that mattered.
Finding patterns in historical estimates and schedule data. Which categories of work were consistently underestimated, which dependency turns up on every project of this type, where the same phase slips. The model is describing patterns in the organisation's own records, which is a task it is genuinely suited to and one nobody has time to do by hand.
First pass risk identification. A generated list of risks for a project of this shape is broader than a workshop held at four in the afternoon with tired people. Its value is as a prompt for those who know the project. Most of the list gets discarded, and the two entries nobody had thought of pay for the exercise.
The common thread is that each produces a draft that a competent person then checks against material where being wrong is detectable.
Where the help runs out
The bottom two rows are where that condition fails. Judgement under ambiguity is the first exclusion. Deciding whether to escalate now or wait a week depends on political knowledge, on how a particular director reacts to surprises and on what else is happening that month. None of that is in any text that could be supplied.
The second is accountability, which has a section of its own below because it is the one people get wrong most often. The third is relationships. Trust with a sponsor is built by turning up with bad news early, a supplier negotiation is won by knowing what the other side needs, and a difficult conversation with a team member is the job itself.
Accountability for a decision the model informed
A decision taken with the help of a model is the decision of the person who took it, in exactly the way a decision helped by a spreadsheet is. What that requires in practice is concrete. The project manager can explain the reasoning independently of the tool. They have checked any figure or fact the output asserts, because fluent text is evidence of nothing but fluency. The record shows what was decided and on what basis, and the fact that something was drafted by a model leaves the name on it unchanged.
The failure worth naming is the quiet one, where a plausible output is accepted because checking it would take longer than writing it. That is the general problem of over reliance and automation bias, treated properly elsewhere on this site, and project work is unusually exposed to it because so much of the output looks exactly like a document somebody would have written anyway.
Confidentiality is decided before anything is pasted
The second question comes before the output exists. Project material is rarely neutral. A risk register names people, a commercial schedule carries supplier pricing and a programme plan may set out a restructuring that has not been announced. A design document can describe exactly how a control works. Depending on the tool and the contract behind it, what is submitted may be retained, reviewed by staff or used to improve a model.
The rule that holds is that the tool inherits the classification of whatever is put into it, so the approval question is asked once for the tool and never each time for the text. Which tools are sanctioned, for what categories of material, is a governance decision, and the site's material on AI governance and compliance covers how that decision is made and recorded.
Historical project data carries the organisation's habits
The third question concerns the pattern finding that the model is best at. A model that learns from a project archive learns what the organisation did, which is a different record from what worked. If integration work has always been underestimated, that is the pattern available to be reproduced. If certain suppliers were scored by a small group with a preference, the preference is in the data and will come back wearing the authority of a number.
None of this makes the analysis useless. It makes it a description of the past that needs a person to say which parts still apply, which is the same qualification any experienced project manager would attach to a lesson learned from six years ago.