When An AI Wrote My Client’s Forensic Directive

My client sent me a formal forensic directive. It demanded five devices, a network audit and a court-admissible report. A chatbot had written it in about nine seconds.

Hello, I am Nitin.

Part way through a device forensics engagement, my client sent me a document titled like a military order. Capital letters. The word DIRECTIVE in the title. Numbered mandatory requirements. Language about evidentiary standards and chain of custody.

It read like it had come from a law enforcement agency.

It had come from a chatbot.

She had described her situation to a general-purpose AI assistant, asked it what a proper forensic investigation should involve, and it had produced a confident, authoritative, comprehensive document. She then forwarded that document to me as the specification for the work I was doing.

This is going to happen to every professional reading this, in every field, and I do not think most of us have worked out how to handle it yet. So here is how I handled it, including the part I got wrong.

What the directive asked for

The engagement I had been contracted for was a single handset.

The directive required forensic examination of five mobile devices, a full examination of a host computer, an audit of the network switching and segmentation, analysis of firewall logging, and a final report prepared to a standard suitable for submission to law enforcement and admissible in court.

Every individual item in that list is a real thing that a real investigator does. That is what makes it dangerous. It is not nonsense. It is a competent description of a much larger engagement, produced instantly, for free, by a system that had no idea what had been contracted, what it would cost, or whether any of it was possible.

Why the machine wrote it that way

This is the part worth understanding, because it generalises far beyond my case.

My client described her situation to the assistant in her own words, and her words carried her certainty. She was being hacked, across multiple devices, persistently. She was not asking whether that was true. She was asking what a thorough investigation into it would look like.

So the model answered the question it was asked. It did not audit the premise. It produced the most comprehensive version of the thing requested, because comprehensive reads as helpful.

And here is the sharp edge. A human expert hearing that same description would have interrupted. Before designing an investigation, a competent investigator asks what makes you believe this, what have you already ruled out, what would change your mind. That interruption is most of the professional value. The model skipped it, not out of malice, but because it was optimising for a complete answer to a stated request rather than the right answer to an underlying situation.

The output then came back to me carrying an authority it had not earned. Formatted like an official document. Confident in tone. Free of hedging. And because it was written in the register of a legal instrument, it felt non-negotiable.

The three problems with acting on it

The first was scope. This was several times the contracted engagement. Not an adjustment, a different project, at a different price, over a different timeline.

The second was feasibility. Parts of it required physical custody of hardware I did not have and could not get. You cannot forensically image a device that is in another country. A directive can demand it. Physics declines.

The third was the standard. "Court-admissible" is not a quality level you apply by trying harder. It is a chain-of-custody discipline that begins before the first byte is collected: documented seizure, verified imaging with hashes recorded at capture, tamper-evident storage, an unbroken custody log, examination of copies only. Evidence already collected in a normal engagement cannot be retroactively upgraded to that standard. If it matters legally, the process has to be designed that way from the first minute, and that usually means an examiner who will appear in court to defend it.

That last point is the one that cannot be negotiated, and it is the one the directive was most confident about.

What I did, and what I got wrong

What I got wrong first was reacting to the document instead of to the person.

My instinct was to argue with the directive point by point, which is a trap, because it treats the chatbot as the counterparty. It is not. The counterparty is a frightened, exhausted client who found something that finally sounded like it was taking her seriously.

What actually worked was addressing what the document meant rather than what it said. She did not want a VLAN audit. She wanted somebody to believe her and to be thorough. The directive was the closest thing she had found to being believed.

So the response had three parts.

I acknowledged that the document described real investigative work and that wanting thoroughness was completely reasonable.

Then I separated it into three explicit buckets, in writing: what was already in scope and underway, what was genuinely valuable but was additional work requiring its own agreement, and what was not achievable by me at all with the reasons stated plainly. That third bucket is the one people avoid and it is the one that builds trust, because a professional who says "I cannot do that, here is who can" is instantly more credible than one who says yes to everything.

And I asked her a question the assistant had never asked: what would actually resolve this for you? Not what should be investigated. What would let you stop.

That question changed the engagement more than any forensic artefact did.

How to handle this when it happens to you

It will happen. Clients are going to arrive with AI-generated specifications, treatment plans, legal arguments and architectural designs, formatted with total confidence.

Do not dismiss it, because dismissal insults the client and they will simply take the document to someone who will accept it uncritically. Do not accept it either, because you will be delivering to a specification nobody with domain judgement ever reviewed.

Do the thing the model did not do. Audit the premise. Ask what the document assumes, whether those assumptions hold, and what it would take to know. That single act is now one of the clearest ways to demonstrate you are worth hiring.

Conclusion — steal this checklist

• Treat an AI-generated specification as a client request, not a professional instruction. It carries no authority regardless of formatting.
• Respond to the person, not the document. Arguing point by point with a chatbot's output misses what the client actually needs.
• Sort every requirement into in scope, additional work, or not possible, in writing. Ambiguity is where engagements go to die.
• Say what you cannot do and why. Naming limits builds more trust than agreeing to everything.
• Understand that court-admissible is a process, not an effort level. It requires chain of custody from the first moment and cannot be applied retrospectively.
• Audit the premise, always. The model answered the question as asked. Your value is asking whether it was the right question.
• Ask the client what outcome would let them stop. It reframes the engagement around resolution instead of endless collection.
• If you use an assistant to scope professional work, feed it your uncertainty, not just your conclusion. A premise you do not question will be reflected straight back at you.