Using AI safely on IT operations data

The risk in letting your team use AI is almost never the model. It is the paste. Someone drops a full ticket, a config file, or a chunk of a log into a chat window to save ten minutes, and in that ticket is a customer name, an internal hostname, or an IP range that should never have left your estate. The tool did nothing wrong. A person under time pressure made a disclosure decision with no framework, at the exact moment they were least equipped to make it well.

That is the whole problem, and it is solvable. You do not need to ban AI, and you do not need a forty-page policy nobody reads. You need one rule, a classification your team can apply in seconds, a sanitise habit that removes the leak before it happens, and a reporting culture that catches the mistakes without punishing the people who own up to them. This guide is the what and the why. Done well, it turns "we should be careful with AI" into something a person can actually follow while their cursor is hovering over paste.

The one rule

Nothing enters a public AI tool before it passes classification. When you are not sure, treat it as confidential and sanitise first.

That is it. Everything else is detail that makes the rule easy to keep. The reason it works is that it moves the decision to a single, memorable checkpoint rather than leaving it to judgement in the moment. A rule that lives at the point of action beats a policy that lives in a document, every time.

The classification that holds up under pressure

A traffic light is the right shape because it is fast, and speed is what determines whether people actually use it. Three levels, and the reasoning behind each matters more than the label.

Green, fine in any AI tool. Generic technical questions, public documentation, structure requests such as "draft an RFC for a firewall change", and process descriptions that name no system, site or person. The test for green is that the text would be just as true for any company in the world. A stack trace with the hostnames stripped is green. The same trace with PRINTSRV-VENLO-02 still in it is not.

Amber, only in an approved enterprise tool with a data processing agreement. Internal procedures, runbooks, aggregated metrics, ticket content with names removed, architecture described without credentials. Amber is the dangerous category, not red, because red is obvious and amber is where good people talk themselves into a paste. The information is genuinely useful to work with, and the only safe route for it is a tool your organisation has a contract with, not a personal account.

Red, never in any AI tool. Credentials, keys, certificates and secrets. Personal data. Customer-identifying data without a contractual basis. Security weaknesses in your own estate that are unpatched and exploitable. Anything under a confidentiality term or a legal hold. Red is not a judgement call. If a credential is in the text, the text does not go into an AI tool, full stop, and the presence of that credential in a ticket is itself worth flagging to whoever owns it.

The trap: the ticket that looks green and is amber

Here is the case that catches careful people. Consider this ticket:

"Warehouse scanner keeps dropping the connection during picking, started after the firmware upgrade on the 14th, about 15 of 240 devices affected across the Venlo site."

It reads like a generic technical question. It is not. The site name, the device count, the date, and the firmware detail are individually harmless and collectively identifying. Anyone who knows the sector can work out whose operation this is, and now you have handed a third party the state of a named customer's warehouse. The three numbers that felt like helpful colour, 240 devices, 15 affected, the 14th, are exactly what make it disclosing.

The fix is not to stop describing the problem well. It is to describe it without the identifiers: "about 6 percent of a device fleet dropping connections after a firmware upgrade" is green, carries the same diagnostic weight, and identifies nobody. This is the single most useful instinct to build in a team: the identifying detail is almost always separable from the technical detail, and separating them costs about thirty seconds.

The sanitise habit

Sanitising is not deletion. Done well, it keeps everything a diagnosis needs and removes everything an identity needs. Three principles make it work.

Replace consistently, not randomly. If the same server appears three times, it should become the same token all three times, because "the same host in all three log lines" is diagnostic information you want to preserve. Redacting each mention to a generic blank destroys the pattern that might be the answer.

Keep the machine-generated evidence. Timestamps, error codes, sequence, and timing deltas are the diagnosis. Strip the human-readable identifiers around them, not the codes themselves.

Sweep the places the eye skips. In a config file, the live credential is almost never in the active settings a reviewer reads; it is in a commented-out block from two years ago that nobody looks at before sharing. In a screenshot, it is the browser tab titles and the rows of data behind the dialog you meant to capture. The disclosure hides in the periphery, and the habit that matters is checking the periphery on purpose.

The approved-tool question

Most real incidents trace back to one thing: a personal account. On a personal AI account, the terms are between the individual and the provider. Your organisation has no contract, no deletion rights, and no visibility, and the disclosure is legally the individual's as much as yours. An approved enterprise tier with a data processing agreement and a no-training guarantee is a different thing entirely, and amber content can go there.

So the practical question your team needs to be able to answer is not "is this tool good", it is "which tool am I in right now, and what are its terms". If the honest answer is "I am not sure", that uncertainty is itself the signal to stop. Unknown terms plus real data is the exact shape of nearly every avoidable incident.

The uncomfortable truth underneath this: when an engineer reaches for a personal account at 17:40 on a Friday, it is usually because the approved tool is slow, unavailable, or worse than the alternative. The durable fix is rarely more willpower. It is making the compliant route the path of least resistance, so the safe choice is also the easy one.

What to do when it goes wrong

It will go wrong at some point, and the next thirty minutes decide whether it stays a contained mistake or becomes an unreported breach. The biggest risk in that window is not the disclosure itself. It is that the person who did it decides to say nothing.

So the one cultural commitment that matters more than any control: reporting is fast, and reporting is not punished. Someone who pastes the wrong thing and says so within the hour gives you a chance to request deletion, rotate anything credential-shaped, and assess the exposure while it is still small. Someone who hides it hands you a breach discovered by an auditor months later. The first honest report handled kindly buys you the next twenty, and that is worth far more than the satisfaction of making an example of anyone.

When it happens, capture the facts plainly: what was entered, into which tool, on what kind of account, containing what, and when. That record is what turns a panic into an assessment, and it is also what a data protection lead needs to decide whether any notification duty applies.

Make it a habit, not a document

The failure mode of data safety is a policy PDF that gets a read receipt and changes no behaviour. The thing that actually works is small and physical: agree the one line your team will never cross, pin the classification where people work rather than in a folder, and sanitise one real ticket together so everyone sees the leak that used to happen. A team that has done it once, on their own data, has started a habit. A team that has only read about it has not.

The goal is not to make your team afraid of AI. It is to let them use it fully on the boring, repetitive work that eats their week, with the confidence that the one decision that matters, what may enter the tool, is made the same way every time. Get that right and AI stops being a risk to manage and becomes the time saver it was supposed to be.