What Not to Hand to AI

The line you draw in advance

The previous lessons were about where AI helps. This one is about where it does not, and the reason it needs a whole lesson is that the dangerous uses do not feel dangerous. They feel efficient. The estimate appears in seconds. The difficult email is drafted before you have finished your coffee. It is only later that you discover what it cost.

It is much easier to decide where the line is on a calm Tuesday than at six o'clock on a Thursday with a steering group in the morning. So decide now.

Estimates

We have touched on this already, but it deserves to be stated plainly. An AI tool does not know how long your work will take. It does not know your team, your systems, your approval processes, or the fact that the last three similar projects all ran over. What it produces is a number shaped like an estimate, based on how such things are generally described.

The danger is not that the number is wrong. All estimates are wrong. The danger is that it has no owner. When a team member gives you an estimate, you can ask how they got there, challenge it, and hold them to it. When a model gives you one, there is nobody to ask.

Use AI to structure the estimating conversation: list the tasks, prompt for things people forget, turn the team's numbers into a tidy table. The numbers themselves come from the people doing the work.

Bad news to stakeholders

Telling a sponsor the project will be late, or telling a client that a feature is cut, is one of the most important things a project manager does. It is also the thing people most want to avoid, which is exactly why it is tempting to let a model write it.

The problem is not the prose. A drafted message will usually be polite and clear. The problem is that bad news is a relationship moment. The person receiving it is judging whether they can still trust you, and they are reading for tone, for ownership, and for whether you saw it coming. Generated text tends to be smooth and slightly evasive, which is precisely the wrong register.

At a minimum, write the first version yourself. Then, if you like, ask for a review.

Below is a message I have written telling [my sponsor / a client] that
[the problem]. Do not rewrite it.
Tell me:

Anywhere I sound like I am avoiding responsibility.
Anywhere the actual news is buried or softened.
Whether the reader knows what happens next and what I need from them.
Keep your feedback to five bullet points.

Better still, if the news is serious, pick up the phone first and send the written version afterwards.

Anything confidential

Budgets, supplier negotiations, unannounced restructures, commercial terms, personal details of people on the project. Before any of it goes into an AI tool, you need to know what your organisation allows and which tools are approved. If you do not know, find out before you paste, not after.

The practical habit is simple: strip it out. Replace names with roles, figures with placeholders, the client with "Client A". You lose very little quality and remove most of the risk. The AI Safety and Verification course goes further into checking what AI tells you, and the AI for Managers course covers setting team-wide ground rules.

Performance issues

A team member keeps missing deadlines. It is affecting the project and you need to address it. Do not ask an AI to draft that conversation, and do not paste the details of someone's performance into a tool to get advice. It is personal data about a named person, it may end up in a formal process, and the person deserves to be dealt with by someone who knows them.

If you need to think it through, talk to your line manager or HR. Those conversations belong with people who are accountable for them.

The wrong choice

Here is the honest part. At some point you will get this wrong. You will use a generated estimate that turns out to be wildly off, or send a drafted update that softened something it should not have. It happens to careful people.

When it does, the only defensible response is to own it. "The AI suggested it" is not an explanation anyone will accept, and the attempt makes things worse, because it tells people you were not really in charge of your own project. Say what went wrong, what you are doing about it, and what you will do differently. That is exactly what you would expect from a team member, and it is what your stakeholders expect from you.

There is a quieter version of the same mistake. A model presents two options and recommends one, confidently and with good reasons. You follow it. It was the wrong call. The recommendation was never a decision; it was a paragraph. The decision was yours the moment you acted on it.