Using AI at work: what to do, and what never to do

Claude, ChatGPT, Gemini and Grok are the same kind of tool wearing different badges. They differ in price, in which one is wired into the software you already own, and in the details of what they will and will not do. They do not differ in the part that matters: each one predicts text that is likely to follow your text, and each one is exactly as fluent when it is wrong as when it is right.

Understand that one sentence and the rest of this article is common sense. Miss it and you will eventually paste something you should not have, or run something you did not read.

Know which account you are in

Before anything else. The free app you signed into with a personal address, the paid personal plan and the account your employer provides are three different products with three different sets of terms about retention, human review and whether what you type may be used to improve a future model.

Those terms change, and they differ per vendor, so the useful habit is not memorising them. It is knowing which account you are in, and checking that product’s current terms once rather than assuming.

If your employer provides one, use it. Not out of obedience — because it is the one covered by an agreement that says what happens to your data, and it is the one that stops existing when you leave.

Never paste these. Ever.

This is the short list, and it is short so there is no excuse for not knowing it.

• Credentials of any kind. Passwords, API keys, tokens, connection strings, private keys, certificates, recovery codes. “I only wanted it to check the syntax” is how most of them get pasted, and a key in a chat log is a key you must now rotate.
• Customer or employee personal data. Names with anything attached: addresses, health details, salaries, case notes, the contents of a ticket that identifies someone.
• Anything under a contract that names where it may be processed. If a customer agreement or a data processing agreement limits where their data may go, an AI vendor is somewhere it has not been agreed to go.
• Whole config files and logs, unread. They are full of internal hostnames, IP ranges, usernames, licence keys and paths that name your organisation. Redact first — the same habit this site asks for before posting in the forum.
• Anything you would not put in an email to a stranger. That is the honest test, and it is easier to apply under pressure than a policy document.

If something did get pasted: treat it as disclosed. Rotate the credential, tell whoever owns the data, and delete the conversation — in that order. Deleting first feels better and fixes nothing.

How to ask so the answer is worth having

Most bad answers are bad questions. These tools cannot see your environment, your constraints or what you have already ruled out, and they will not ask unless you invite them to.

Give it the four things

• The goal. Not the step you think you need — the outcome you are after. “Users cannot print after the October update” beats “how do I clear a print spooler”.
• The context. Versions, platform, scale, what is already in place. “Windows Server 2022, about 400 users, printers published from a print server” changes the answer completely.
• What you have tried. Otherwise the first three suggestions will be the three things you did yesterday.
• The constraints. No reboot until Saturday. No third-party tools. Must work in PowerShell 5.1. These are the difference between a usable answer and a nice idea.

Then work with it, not at it

• Ask for the reasoning, not just the result. “Explain why that switch is needed” turns an answer into something you keep.
• Push back when it is wrong. Saying “that flag does not exist in this version” usually gets a correction. It is a draft, not a verdict.
• Ask what it would break. “What are the risks of running this on a domain controller” is the single most useful follow-up question there is.
• Ask for the alternative. “Is there a way that does not need a reboot?” often finds one.

Always check the answer

These tools state things that are not true with complete composure. Not occasionally — routinely, and most often in exactly the places you are least able to catch it: a plausible switch that does not exist, a cmdlet from a different version, a registry path that is almost right, a citation to a document that was never written.

What you were given	How to check it before you trust it
A command or script	Read every line. Look up any flag you do not recognise in the official documentation. Run it somewhere that does not matter first.
A configuration change	Find it in the vendor’s own documentation. If it does not exist there, it probably does not exist.
A fact, a figure or a date	Verify it at the source. Treat anything it did not link to as unverified.
A quotation or a reference	Open it. Fabricated citations look exactly like real ones.
Code for something that matters	Review it as you would a colleague’s pull request, because that is what it is.

The rule that covers all of it: if you could not defend the change in an incident review, you are not ready to make it. “The AI suggested it” has never once been a satisfactory answer to “why did this happen”.

Using it for scripts and commands

This is where our trade gets the most out of these tools and takes the most risk, so it earns its own rules.

• Never paste a command straight into a production shell. Not from an AI, not from a forum, not from this site. Read it first.
• Be specific about the destructive ones. Anything with Remove-, Delete, -Force, -Recurse, DROP or rm gets read twice and tested somewhere disposable.
• Ask for a dry run. “Give me a version that reports what it would change without changing anything” is a request these tools handle well, and it is how you find out it was going to touch the wrong OU.
• Ask what happens when it fails halfway. Scripts that are fine on the happy path are how a partial change becomes an outage.
• Keep the backup habit. A tested backup, before the change, exactly as you would for any other change.

# Ask for this shape when the script changes anything that matters:
#   - a -WhatIf or dry-run mode that is the default
#   - it stops on the first error rather than carrying on
#   - it says what it is about to do, and to how many objects
#   - it writes a log you can read afterwards

Be careful what you connect it to

These assistants increasingly offer to read your mail, your files or your browser, and to act rather than only advise. That is genuinely useful and it is a different level of trust, because an assistant that can only write is limited by what you do with the text. One that can act is limited by what it is allowed to reach.

• Grant the narrowest access that does the job, and grant it for a reason you could explain.
• Remember that anything it reads can contain instructions aimed at it — a web page or an email can be written to influence an assistant that reads it. Its output is a draft shaped by content you did not control.
• Keep a person in the loop for anything that sends, pays, deletes or grants. Reviewing before it goes is not a lack of trust; it is the same rule as change control.

What it is genuinely good at

It would be a poor article that only listed dangers. Used well, and checked, these tools are very good at:

• Explaining an error message or a block of unfamiliar code in plain language.
• A first draft of a script, a policy, an email or documentation, which you then make correct.
• Turning something into something else: a log into a table, notes into a runbook, a rough idea into a clear paragraph.
• Rubber-ducking a problem at two in the morning when there is nobody to ask.
• Teaching you something, if you ask why rather than only what.

That last one is the whole game. Every answer is a chance to be better at your job tomorrow, or a chance to be one step more dependent. The difference is entirely in whether you asked it to explain itself. We have written about that in more detail.

Notes

• The vendors differ less than the marketing suggests. Every point above applies to all four, and to whichever assistant is built into the software you already pay for.
• Model knowledge has an edge. Each one was trained up to some point and may not know about anything after it. For anything version-specific or recent, check the vendor’s documentation rather than the assistant.
• It will agree with you too readily. If you tell it it is wrong when it was right, it will often fold. Confidence in either direction is not evidence.
• Running the tools rather than using them? The security side — consented connectors, data boundaries and what to tell your users — is in the advisory.