Lesson 5: Scripting and AI Operations Practical

Automation changes the cost of a mistake.

Typing the wrong command on one computer can damage one computer.

Running the wrong script against forty computers can damage forty computers before you have time to finish saying, "Wait..."

AI changes the speed of another part of the work. It can summarize notes, explain an error, draft documentation, or suggest a script.

It can also invent details, misunderstand the environment, expose sensitive information, or produce code that is confidently wrong.

The useful skill is not:

Use automation and AI.

It is:

Control the operational risk before high-leverage tools multiply it.

Recognize the common script types

At A+ depth, recognize these file types and typical contexts:

The extension tells you something about the expected runtime.

It does not tell you the script is safe.

A file called fix-printer.ps1 can still delete the wrong directory if the code says so.

Names are labels. Read the behavior.

Operational data boundary

Support evidence has a boundary before it reaches an AI tool

Use approved tools only after removing data the service does not need.

1. 01
   Raw support record

   May contain names, credentials, private addresses, customer data, or confidential logs.

2. 02
   Minimize

   Keep only evidence required for the bounded support question.

3. 03
   Sanitize

   Remove secrets and identifying or restricted content before transfer.

4. 04
   Approved tool

   Use the authorized system with a human reviewing claims and actions.

5. 05
   Verified output

   Treat generated suggestions as hypotheses until local evidence proves them.

Scripts are operational tools

Common technician uses can include:

• restarting approved machines or services;
• remapping network drives;
• gathering inventory;
• collecting diagnostic output;
• installing approved applications;
• initiating backups;
• performing update tasks;
• repeating standardized configuration steps.

The value is consistency and scale.

That is also the risk.

Source comes before execution

Before running a script, establish:

Where did it come from?
Who authored or approved it?
Has it changed since approval?
What interpreter/runtime executes it?
What privilege does it require?
Which assets are in scope?
What files/settings/services can it change?
Can it restart systems?
Can it contact external services?
What is the rollback path?
How will success be verified?

Do not run an unknown script on a managed endpoint to discover what it does.

That is not analysis. That is execution.

Read-only inspection is different from execution

A technician can inspect:

• comments;
• commands;
• paths;
• loops;
• environment assumptions;
• network destinations;
• deletion or overwrite behavior;
• restart behavior;
• logging.

You do not need to be a software engineer to notice:

remove everything under this path
restart every target
upload logs to this external URL

Those are operationally important behaviors.

Scope control prevents a small task becoming a fleet-wide incident

Suppose a PowerShell script accepts a list of computer names.

The intended target is:

LAB-TEST-01

The actual target variable contains:

LAB-*

That small difference changes scope from one test system to an entire lab.

A safe operational process can use:

• pilot devices;
• explicit target lists;
• dry-run or preview modes where supported;
• approval;
• staged rollout;
• stop conditions.

Automation should make the intended scope clearer, not hide it.

Privilege increases impact

A script that runs as a normal user can still cause problems.

A script running with administrator or root authority can change much more.

Ask whether the task truly requires elevation.

If an inventory script only reads system information, permanent administrator rights may be unnecessary.

Least privilege applies to automation too.

Scripts can create resource problems without being malicious

A poorly designed script can:

• consume CPU;
• exhaust memory;
• fill a disk with logs;
• saturate a network;
• repeatedly restart a service;
• create too many processes;
• launch against the wrong devices.

"The script is ours" does not mean "the script cannot hurt us."

Operational errors do not need malicious intent.

Automation needs rollback and verification

Suppose a deployment script updates an application.

A complete plan includes:

known-good old version
backup of required data/config
pilot result
approved installer/script
rollout scope
stop condition
rollback command/procedure
user-function verification
final documentation

The script returning exit code 0 is useful.

It does not prove the application opens the required project correctly.

Return to the business requirement.

AI is also a source that requires verification

An AI assistant can be useful for:

• summarizing ticket notes;
• reorganizing documentation;
• explaining an error message;
• generating a first draft of a knowledge article;
• comparing supplied configuration states;
• suggesting troubleshooting questions;
• drafting or explaining a script.

AI output is not automatically evidence.

Hallucination means plausible can still be false

AI systems can produce information that sounds confident and coherent but is factually wrong or invented.

Example:

"This PowerShell parameter guarantees the application will never restart a user session."

That sentence sounds specific.

It still needs verification against the actual command, script, application, and documentation.

Confidence is not evidence. You have heard that before for a reason.

Bias affects recommendations and interpretation

AI output can reflect patterns and assumptions in its training data, prompt, or available context.

That matters when AI is used to summarize incidents, evaluate users, rank options, or recommend policy.

A useful technician asks:

• What information did the model receive?
• What perspective may be missing?
• Is the output making an unsupported assumption about the user or system?

Accuracy can become stale

Software versions, commands, policies, vendors, and support lifecycles change.

An AI answer can be internally reasonable and outdated.

Verify time-sensitive technical claims against current authoritative documentation.

Public versus private AI changes the data boundary

Before placing information into an AI service, ask:

Is this service approved?
Is the information public, internal, confidential, or regulated?
Does it contain usernames, customer data, student data, logs, or incident details?
Where may the data be stored or processed?
Does policy permit this use?
Can I remove sensitive details and still solve the problem?

Never paste real passwords, API keys, MFA codes, private student/customer records, regulated data, or confidential incident material into an unapproved AI system.

The model does not need your secrets to explain a generic error.

Source quality still matters when AI summarizes it

If the source is wrong, a beautiful AI summary can be beautifully wrong.

Ask what the answer is based on:

• current vendor documentation;
• a ticket record;
• supplied logs;
• forum speculation;
• an unknown source.

AI can improve presentation without improving the underlying evidence.

AI policy includes appropriate use and plagiarism boundaries

Organizations and schools may define:

• when AI assistance is allowed;
• what data may be entered;
• whether disclosure or attribution is required;
• what counts as original work;
• which tools are approved;
• what human verification is required.

"The AI wrote it" does not transfer responsibility away from the person who submits or deploys it.

The technician still owns the decision.

Practical: the 40-workstation update

A fictional computer lab has forty workstations.

Request:

Deploy an approved application update before tomorrow morning.

Available materials:

• signed vendor installer;
• vendor example PowerShell deployment script;
• AI-generated modified script that claims to add logging and automatic restart;
• current application version for rollback;
• approved maintenance window.

You will not execute either script in this activity.

The job is to evaluate the operational plan.

Stage 1: define the change

Record:

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

If the scope field says only:

lab computers

it is not specific enough.

Name the intended population.

Stage 2: compare the script sources

For each script, document:

source
file type
integrity / trust evidence
required privilege
intended actions
target-selection behavior
restart behavior
file / registry / service changes
network destinations
logging behavior
unknowns
approve / reject / escalate and why

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

Comments are not execution.

Stage 3: challenge the AI claim

AI output:

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

Problems with that statement include:

• safety cannot be guaranteed from prose;
• environment-specific dependencies are unknown;
• restart behavior needs code and test verification;
• the target scope must be checked;
• authorization and maintenance-window rules still apply;
• AI can hallucinate or omit dangerous behavior;
• the generated script has a different provenance from the vendor script.

A strong reviewer does not ask whether the sentence sounds professional.

They ask what evidence would make it true.

Stage 4: define rollback

A useful rollback may require:

• previous approved installer/version;
• backed-up application configuration;
• protected user data;
• uninstall/reinstall procedure;
• pilot evidence;
• stop condition for broad deployment.

Write the stop condition explicitly.

Example:

Stop rollout if the pilot cannot open and export the standard test project after update.

That is better than:

Stop if something goes wrong.

Stage 5: protect the AI data boundary

Ticket data contains fictional information only.

For a real environment, identify what would need to be removed or withheld before using an approved AI service:

• credentials;
• private user information;
• proprietary code;
• sensitive logs;
• security incident details;
• regulated data.

If redacting those details still lets the AI help with a generic error, use the smaller dataset.

Data minimization works here too.

Stage 6: communicate the change

Write a stakeholder update that explains:

• what will change;
• when;
• expected interruption;
• what users need to do;
• what rollback exists;
• when success will be confirmed.

Do not bury the important impact under script terminology.

The users care whether the application will be available in the morning.

Stage 7: define verification

Verification should include:

deployment status
application version
required service launches
standard test workflow succeeds
user data/config present
no unexpected restart state
sample or full target coverage verified
rollback no longer needed or remains available
final ticket/change record updated

A green automation dashboard is one piece of evidence.

The real application function is another.

Operational defense

Present the plan in this order:

1. request and scope;
2. authority and change process;
3. backup and rollback;
4. script source and risk review;
5. pilot/staging plan;
6. AI accuracy/privacy/policy decision;
7. communication;
8. verification;
9. documentation and follow-up.

What Week 16 should leave you with

Professional IT work is a controlled system:

ticket + asset
      ↓
authority + policy
      ↓
risk + safety + privacy
      ↓
backup + rollback
      ↓
human or automated action
      ↓
verification
      ↓
communication + documentation

The best technician is not the person who changes systems 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.

Next week the objective labels disappear again. The incidents can come from anywhere in the course.