Using AI at Work

What AI tools are good for in IT

Used well, an AI assistant takes the blank-page and the look-it-up work out of many IT tasks. Typical good uses:

• Drafting: a reply to a user, a change description, a first version of a knowledge article, a status update during an outage.
• Summarizing: a long ticket history for the next shift, a vendor's release notes, a meeting transcript.
• Explaining: an unfamiliar error message, a command's options, a concept you have to pick up quickly.
• Writing scripts and queries: a PowerShell one-off, a regular expression, a SQL query, a Python script to parse a log.
• Reviewing: asking for a second look at your own script or text, to catch what you missed.

What these have in common: you can judge the result. You can read a draft reply and see whether it is right; you can test a script. The risk rises sharply when you cannot check the answer, for example a fact you do not know, a setting you cannot verify, or code you do not understand. Why models are strong and weak where they are is explained in limits and myths; how to ask well is in working with LLMs.

What never to paste

Whatever you type or upload into an AI tool leaves your hands. It goes to the provider's servers, may be stored in logs and chat histories, may be read by the provider's staff for abuse monitoring, and depending on the product and the contract, may be used to train future models. Consumer versions and business versions of the same tool often have different terms. So:

• Credentials and secrets: passwords, API keys, tokens, private keys, connection strings. A secret that has been pasted anywhere outside its secrets store must be treated as leaked and rotated, just like one committed to Git.
• Personal data: names, email addresses, phone numbers, account numbers or anything else about customers and colleagues, unless the tool is approved for that data. Sharing it with an unapproved tool can be a data breach under the GDPR or the UK GDPR.
• Internal configurations: firewall rules, network diagrams, server names and addresses, especially when they contain secrets or reveal weaknesses.
• Confidential business information: contracts, unreleased plans, security findings, source code that is not allowed to leave the company.

Your organization's data classification decides which data may go into which tool. An approved business tool may be allowed to see internal data that a free public chatbot may never see.

When you do need help with a log or configuration, strip it first. The script below replaces the most obvious sensitive values in a log excerpt with placeholders. The order of the rules matters: credentials inside a URL are removed before the email rule could misread them.

import re

log = """\
08:12:03 login failed for j.devries@example.com from 192.0.2.44
08:12:09 db_url=postgres://billing:Winter2026!@198.51.100.15:5432/invoices
08:12:10 api_key = 4f9c2e7a1b8d4e6f
08:13:45 VPN tunnel to 203.0.113.9 down, retrying"""

RULES = [
    ("credentials in URL", r"://[^:/\s]+:[^@\s]+@", "://[USER]:[PASSWORD]@"),
    ("secret value", r"(?i)\b(password|passwd|secret|token|api_key)\s*=\s*\S+", r"\1 = [REDACTED]"),
    ("email address", r"[\w.+-]+@[\w-]+(\.[\w-]+)+", "[EMAIL]"),
    ("IPv4 address", r"\b\d{1,3}(\.\d{1,3}){3}\b", "[IP]"),
]

found = {}
for name, pattern, replacement in RULES:
    log, count = re.subn(pattern, replacement, log)
    found[name] = count

print(log)
print()
for name, count in found.items():
    print(f"{name:<20} {count}")

08:12:03 login failed for [EMAIL] from [IP]
08:12:09 db_url=postgres://[USER]:[PASSWORD]@[IP]:5432/invoices
08:12:10 api_key = [REDACTED]
08:13:45 VPN tunnel to [IP] down, retrying

credentials in URL   1
secret value         1
email address        1
IPv4 address         3

Checking the output

How much checking an answer needs depends on what happens if it is wrong. A rephrased email needs a read-through; a firewall change needs a review and a test. Habits that work:

• Verify facts against a source. Version numbers, command options, product limits, legal deadlines: look them up in the official documentation. If the assistant gives a source, open it; invented references look real.
• Test code in a safe place. Run generated scripts in a test environment or on a copy, never first on production. Read every command that deletes, overwrites or changes permissions. Make sure you understand what the code does before you run it.
• Watch for invented details. A package name that does not exist, a configuration flag that sounds right, an API endpoint the vendor never had. Attackers register package names that AI tools tend to invent, so check dependencies before installing them; see package hallucination.
• Check what was left out. A summary can be accurate and still miss the one line that mattered.
• Use your normal process. AI-written changes go through the same review, testing and change approval as any other change.

You remain accountable

Human accountability is the principle that a named person or role stays responsible for the outcome of work done with AI, and can explain and answer for it. The AI tool cannot be: it has no responsibility, no job and no signature. If an AI-drafted reply promises a customer something wrong, the person who sent it, and the organization behind them, own the consequences.

In practice this means: do not send, merge, deploy or decide anything you could not explain yourself. When you hand on AI-assisted work, you vouch for it as if you had written it. This is the individual side of AI governance and of the human oversight described in responsible AI.

Shadow AI and acceptable use policies

Shadow AI is the use of AI tools, accounts or features at work without the organization's approval or knowledge: a personal chatbot account for summarizing customer emails, a browser extension that reads every page, an AI feature switched on in a SaaS product nobody reviewed. It is a form of shadow IT, and it usually starts with good intentions: people want to work faster and the official route is slow or does not exist.

The risks are concrete: confidential data leaving the company under terms nobody checked, no logging when something goes wrong, output nobody knows was AI-generated, and possibly obligations under privacy and AI laws that nobody is meeting: the GDPR and the EU AI Act, the UK GDPR, or US state privacy and AI laws. Banning AI outright tends to push it further underground. What works better is to offer approved tools, make the rules clear, and make it easy to ask for a new tool.

An acceptable use policy for AI is the organization's written set of rules for how staff may use AI tools: which tools are approved, which data may be used with them, how output must be checked and disclosed, and who to ask. It follows the same structure as other topic policies in the policy hierarchy. An excerpt from a fictional energy company's policy:

3. Approved tools
   3.1 Use only AI tools on the approved list on the intranet. The list
       states, per tool, the highest data classification allowed.
   3.2 Do not use personal accounts of AI tools for work.
   3.3 Request a new tool through the service portal. IT Security and
       the data protection officer review requests within ten working days.

4. Data
   4.1 Never enter passwords, keys, tokens or other secrets in any AI tool.
       If this happens, report it to the service desk and rotate the secret.
   4.2 Personal data of customers or employees only in tools approved for
       "Confidential" data, and only when the task requires it.

5. Output
   5.1 AI output is a draft. The person who uses it is responsible for
       checking it and for the result.
   5.2 Scripts and configuration changes follow the normal review, test
       and change process.
   5.3 Tell the recipient when a customer-facing text or a decision was
       substantially produced by AI, as described in our disclosure
       guidelines.

7. Not allowed
   7.1 Using AI to make decisions about individual customers or employees
       without human review.
   7.2 Uploading third-party documents whose license forbids it.

AI literacy and disclosure

Being AI literate means knowing roughly how the tools work, where they fail, what you may share with them and how to check what they give back: most of this topic, in short. Disclosure means telling people when AI played a substantial part in something they receive. How much of either the law requires depends on where you work.

Most disclosure, though, is about trust. Colleagues reviewing your code should know which parts were generated, because they will review it differently; a customer who gets a reply drafted by AI and checked by a person may be told so according to your organization's policy. The aim is not a disclaimer on every email but honesty where it would change how people read or rely on the work.

A checklist before using AI on a task

1. Is the tool approved for this kind of work and this data classification?
2. Have I removed secrets, personal data and anything confidential that the task does not need?
3. Can I check the result? If not, can someone else, or should I do this differently?
4. What happens if it is wrong? The higher the impact, the more verification and review.
5. Have I verified the facts, tested the code in a safe place, and read what will actually be sent or run?
6. Could I explain and defend the result without mentioning the AI?
7. Does anyone need to know AI was involved, under our policy or because it changes how they will rely on it?

AI certifications

An AI certification is a credential awarded after passing a proctored exam that tests AI knowledge against published objectives, such as Microsoft's or AWS's AI fundamentals exams. It is different from a certificate of completion, which you earn by finishing a course or learning path, usually without an independent exam. Both have value; they say different things. The overview below is as of October 2026; exam codes, formats and prices change, so check the official page before you book.

For someone starting in IT, AI-901 or AIF-C01 is the natural first step: choose by the cloud your organization uses. AI-901 is more hands-on and expects you to write a little Python; AIF-C01 tests understanding rather than building. Security people may look at SecAI+ next.

How this topic maps to them

Pages in this topic carry the tags AI-901 and AWS AI Practitioner where their content is in those exams' objectives, with exam-tip callouts on the tagged pages. The foundations (what AI is, how machines learn, classic machine learning, transformers, working with LLMs, retrieval, agents, vision and speech, infrastructure and responsible AI) are relevant to both. Data, evaluation, neural networks, deep learning, AI security and regulation are tagged for AWS AI Practitioner only, whose objectives cover them more explicitly. This page, limits and myths and AI in IT operations are untagged: they are about working with AI rather than about an exam. No page here replaces the official skills outline and the vendors' own hands-on labs.