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.
Six tasks and where the line falls
The line is easier to see across several tasks at once than in the abstract. What moves as you read down the table is how much of the answer lives in material you can hand 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 rather than the thinking | That every figure, date and commitment in the draft is true, and that the tone suits the audience receiving it |
| Summarising status | Yes, where you hold the source and can see 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 you could supply | 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 it earns its place today
Drafting documentation. A status report, a change request, a risk register entry, a closure summary. Given your 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 rather than in the thinking.
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 you, so you 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 your 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
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 the text you can supply.
The second is accountability, which is discussed 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 rather than an overhead on it.
You remain accountable for a decision the model informed
A decision taken with the help of a model is your decision, in exactly the way a decision helped by a spreadsheet is. What that requires in practice is concrete. You can explain the reasoning independently of the tool. You 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 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 you paste
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 you submit 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 you put into it, so the approval question is asked once for the tool rather than each time for the text. Which tools are sanctioned, for what categories of material, is a governance decision rather than a personal one, 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
A model that learns from your 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 learnt from six years ago.