IT Process Automation: What AI Should Actually Touch First
IT process automation with AI works best on a handful of narrow, repetitive tasks. A worked ticket-triage example, the checks that matter, and what to leave alone.
Most "IT process automation" pitches promise to automate the department. What actually works is smaller and less exciting: a handful of narrow, repetitive steps inside a process, with a person still reading the output before it goes anywhere. That is a less impressive pitch and a much more reliable one.
The gap between buying an automation tool and actually getting time back from it is well documented — Stanford’s AI Index tracks adoption rising much faster than measured productivity gains, which is what you would expect if most deployments are automating the wrong step. This is about picking the right one.
Where AI actually fits in an IT process
Inside a typical IT process — a ticket coming in, an access request, an incident — there are usually two kinds of work mixed together: mechanical steps that follow a pattern, and judgement calls that do not. AI is genuinely useful on the first kind and a liability on the second, so the job is separating them rather than automating the process end to end.
- Ticket triage and categorisation — reading a raw description and routing it to the right queue with a priority label.
- First-response drafting — a reply that confirms receipt, asks the two or three questions that are always missing, and sets expectations.
- Log and alert summarisation — turning a screen of timestamps into "here is what changed and when" for the person on call.
- Runbook lookup — surfacing the relevant section of an existing procedure instead of someone searching a wiki mid-incident.
- Onboarding and offboarding checklists — drafting the list of accounts and access to grant or revoke from a role template, for a person to execute and confirm.
Notice what is not on that list: actually granting access, closing a ticket, or deciding an incident is resolved. Those stay a human action. The pattern is the same one that makes B2B marketing automation work — draft the email, keep a person reviewing it before it sends — applied to a help desk instead of a lead sequence.
Run the candidate through four questions first
Find the repetitive part sets out the general test, and it applies directly here: does this happen at least weekly, is the input predictable in shape, is a mistake cheap and visible, and could you explain the steps to a new hire in five minutes? Ticket triage clears all four easily. "Decide whether this outage breaches the SLA" does not — the input varies too much and a wrong call is expensive, so leave it with a person.
Task-level analysis of where these tools actually help keeps landing on the same shape: narrow, well-defined tasks inside a job, not whole roles. The International Labour Organization’s global analysis and separate job-posting data from Indeed’s Hiring Lab both point the same way: demand shifts toward people who can run and check these tools, rather than disappearing.
A worked example: ticket triage
Weak: "Sort this ticket."
Better: "Here is a raw support ticket description. Assign it one category from this list — Access, Hardware, Software, Network, Account — and one priority from Low, Medium, High, using these definitions: [paste your team’s priority definitions]. If the description is missing information needed to act on it, list the specific questions to ask back, rather than guessing. Do not close or resolve anything."
The second version gives the model a fixed set of categories, your team’s own definition of priority rather than its guess at one, and an explicit instruction not to take any action — only to classify and flag gaps. That last line matters more than it looks: it is the difference between a drafting tool and one quietly making decisions nobody reviewed. How to write a prompt that works on the first try covers the general version of specifying the job this precisely.
Where this goes wrong
A model asked to triage tickets will produce a confident category and priority even when the description genuinely does not contain enough information to support one. That is not a bug specific to this use case — large language models are well documented to produce fluent, plausible answers regardless of whether the underlying information supports them, and a wrong priority label reads exactly as confident as a right one. What AI is actually bad at covers the same failure mode in more general terms.
The fix is not asking the model to double-check its own classification — that tends to produce agreement rather than a genuine second opinion, so checking an AI answer when you are not the expert is worth reading before you rely on this for anything customer-facing. The practical version here: sample a slice of auto-triaged tickets every week and have a person re-check the category and priority against what actually happened. If the error rate on a category is high, stop automating that category rather than tuning the prompt indefinitely.
Decide in advance how you will notice it broke
The NIST AI Risk Management Framework is built around exactly this: monitoring a deployed system for the specific ways it can fail, not just checking that it works on day one. For a triage system, decide up front what you would look for if it silently started misrouting tickets — a queue that goes unusually quiet, a category whose volume jumps for no operational reason, or a spike in tickets reopened after being marked resolved. Pick a number you can check weekly, not a feeling you would eventually notice.
If the task genuinely outgrows a well-written prompt — a multi-step workflow spanning several systems, not a single classification — how to create an AI model sets out the routes beyond prompting and, more usefully, why most IT tasks should stop well before that point.
Automate the sorting and the first draft. Keep the decision that actually closes something.
What to do Monday
Pick one queue — password resets or a single ticket category is a reasonable start — and draft the classification prompt above using your team’s own category and priority definitions. Run it against a week of historical tickets you already know the right answer for, before pointing it at anything live. Note the error rate, decide what you would need to see to trust it further, and leave the actual resolution with the person who has always done it.
Coursium teaches this kind of practical, tool-specific skill directly — writing the request precisely enough that a tool’s output is actually usable, and knowing where to keep a human in the loop. Stay ahead of AI by learning the tools on your phone.