Lesson 5: Scripting and AI Operations Practical

Core path: 42 minutes

Automation can save a technician an hour.

It can also repeat the same mistake across fifty machines in seconds.

AI can help organize or explain support information.

It can also be confidently wrong, leak sensitive information, or violate policy.

The skill is not "use automation." The skill is control the operational risk.

Recognize common script file types

At A+ depth, recognize these common script types:

This week is not about becoming a programmer. It is about recognizing what a technician may be asked to review or run and understanding the risk before execution.

Common technician automation use cases

Scripts may support tasks such as:

• basic repetitive automation;
• restarting machines or services under an approved process;
• remapping network drives;
• installing applications;
• running automated backups;
• gathering inventory or diagnostic information;
• initiating updates.

A script still needs authorization, testing, scope control, and verification.

Automation risk

Possible failure modes include:

• unintentionally introducing malware through an untrusted script/source;
• changing system settings beyond the intended scope;
• deleting or overwriting data;
• exhausting CPU, memory, storage, or network resources;
• causing application, browser, or system crashes;
• running successfully on the wrong set of devices.

Technician rule:

Read the purpose, source, scope, required privilege, expected change, rollback path, and verification plan before execution.

Do not run unknown scripts on managed or important systems just to discover what they do.

AI is another operational tool

AI may be integrated into support applications for tasks such as summarizing notes, suggesting documentation, explaining error messages, searching knowledge, or helping organize troubleshooting information.

AI output is not automatically verified evidence.

Limitations

Recognize:

• bias: output can reflect biased data or assumptions;
• hallucination: output can invent plausible but false information;
• accuracy limits: even a confident answer can be technically incorrect or outdated.

Policy

Organizations may define appropriate AI use, including plagiarism/attribution rules, allowed data, approved tools, and required human review.

Public vs private AI

Before placing information into any AI system, ask:

Is this public or private information?
Does it include customer/user data?
Is the AI service approved?
Where does the data go?
What data source is the output based on?
Can the result be verified independently?

Never paste real passwords, tokens, private student/customer records, regulated data, or confidential incident material into an unapproved AI service.

Practical: the 40-workstation update

You are the technician for a fictional computer lab with 40 workstations.

Ticket/request:

Deploy an approved application update before tomorrow morning. The vendor provides a signed installer and an example PowerShell deployment script. An AI assistant generated a modified version that claims to add logging and automatic restart.

You do not execute either script in this activity.

Stage 1: documentation and change control

Record:

requester:
assets/scope:
purpose:
change type:
maintenance window:
risk level:
approval:
backup/rollback:
test group:
verification:

Stage 2: evaluate the script path

For the vendor script and AI-modified script, document:

source:
file type:
required privilege:
intended actions:
restart behavior:
logging behavior:
unknowns:
reason to approve/reject/escalate:

Do not trust the AI version because it looks cleaner or includes comments.

Stage 3: AI review

The AI answer says:

This script is completely safe and guaranteed not to interrupt users.

Identify at least three problems with that statement.

Strong answers include:

• safety cannot be guaranteed from prose alone;
• environment-specific dependencies are unknown;
• restart/user-impact behavior must be verified;
• authorization and maintenance-window rules still apply;
• AI may hallucinate or miss an unsafe command;
• the script source and code must be reviewed/tested independently.

Stage 4: backup and rollback

State what must be recoverable if the update breaks the application.

A good rollback plan may involve:

• previous approved application package/version;
• backed-up application configuration or user data where relevant;
• documented uninstall/reinstall procedure;
• pilot/sandbox results;
• clear stop condition before wider deployment.

Stage 5: communication

Write a short user/stakeholder status update that explains:

• what will change;
• when;
• expected impact;
• what users should do;
• when success will be confirmed.

Avoid unnecessary jargon.

Stage 6: final defense

Present your operational decision in this order:

1. request and scope;
2. authorization/change process;
3. backup/rollback;
4. script-source and risk review;
5. AI limitations/privacy decision;
6. communication plan;
7. verification and documentation.

Week 16 checkpoint

Operational Procedures connects the technical course to professional practice:

ticket / asset
→ approved change
→ backup / safety / policy
→ communication / remote-support boundary
→ automation or AI tool
→ controlled implementation
→ verification
→ documentation / follow-up

The best technician is not the person who changes systems the fastest.

It is the person who can make the right change, under the right authority, with a recovery path, without exposing people or data, and with evidence that the work actually succeeded.