E026 AI for IT Automation and Security carries the banner number ITCL 2201 and is worth 3 competency units. It covers how artificial intelligence techniques strengthen security practice, automate repetitive technical work, optimize how a network runs, and improve both the detection of threats and the response to them. E026 and ITCL 2201 name one requirement. The course is applied rather than theoretical: the question is never whether AI is impressive, it is which technique fits a particular operational problem and what it costs to be wrong.
Detection is a statistics problem before it is an AI problem
The idea that unlocks this course is that automated detection produces four outcomes, not two. A true positive is a real threat caught. A false positive is a normal event flagged. A true negative is normal traffic correctly ignored. A false negative is a real threat missed. Every technique in the syllabus trades these against one another, and every design decision you will be asked to justify is a decision about which error you would rather make.
That framing explains why security operations teams distrust noisy tools. In an environment generating enormous volumes of routine events, a detection rate that sounds excellent can still bury an analyst in alerts, and alert fatigue is itself a security failure. A submission that recommends an AI driven detection approach without discussing false positive volume has skipped the part practitioners care about most.
Automation raises a different question: what should be automatic. Enrichment, correlation, ticket creation and evidence gathering are low risk to automate because a mistake wastes time. Isolating a host, disabling an account or blocking traffic are high risk because a mistake causes an outage. Mature designs automate the first category fully and put the second behind a human decision, and saying so in your work demonstrates operational judgment.
Optimization and anomaly detection share a technique and differ in purpose. Learning what normal looks like on a network can tell you that something is broken or that something is hostile, and the same baseline serves both. Being explicit about which question a model is answering keeps the analysis from sliding between the two.
The adversarial side belongs in any serious treatment. Attackers use the same techniques, models can be misled by crafted input, and a detection system is itself an asset that can be attacked. WGU records this work as Competent or Not Competent, without letter grades or an ordinary grade point average, and the 3 competency units sit within a six month term charged at one flat rate.
Turning scored aspects into an implementation proposal
If your version of E026 uses a performance assessment, the aspects your evaluator scores are the outline of the proposal. WGU requires a score of 2 in every aspect for a task to pass and scores each aspect independently, so a sophisticated technique discussion will not carry an unanswered aspect about risk or human oversight.
Budget the words before you draft. Consider a rubric of five scored aspects with a target near 2,000 words. Reserve 150 words to describe the operational problem and the environment, and 130 for the close, which leaves 1,720. Two aspects demand technical justification, usually the choice of technique and the design of the detection or automation itself, and they take 440 words each for 880, because each needs the requirement, the technique, the data it needs and the failure mode. The three remaining aspects, typically covering benefits, risks or limitations, and human oversight, take 280 each for 840. Together they come to 1,720 exactly.
In every technical paragraph, follow the same order: the task being automated or detected, the data available to do it, the technique applied, the error it will make, and what happens when it makes that error. That last item is the one students omit, and it is the one that turns a description into an analysis.
Reserve budget for the human in the loop. Aspects about oversight, escalation and accountability are common in this subject and cheap to answer well, and they are usually the thinnest section in a returned draft.
Shape for an AI in operations proposal
E026 deliverables usually propose applying a technique to a described operational or security problem. These proportions carry that proposal.
| Section | What belongs there | Share |
|---|---|---|
| Operational problem | The task or threat today, how it is handled now, and what that costs in time or risk. | 12 percent |
| Data available | What signals exist, their volume and quality, and what is missing. | 13 percent |
| Technique and fit | The approach chosen, what it needs to work, and the alternative you rejected. | 20 percent |
| Design and workflow | Where it sits, what it produces, and what happens to the output next. | 18 percent |
| Error profile | The mistakes it will make, their cost, and how the design absorbs them. | 15 percent |
| Oversight and accountability | What stays under human decision, who reviews it, and how the system is audited. | 14 percent |
| Close | What would make you turn it off, and what you would measure first. | 8 percent |
Sourcing claims about a fast moving field
This subject attracts marketing, and marketing is the worst available evidence. Anchor technical claims about how a technique behaves in method literature or a technical reference rather than in a product page. Anchor operational claims about how security teams work in industry reports and practitioner research from recognized bodies. Anchor claims about a specific tool in that tool's documentation, dated.
Be exact about what a technique is. Terms in this field are used loosely in the press and precisely in the literature, and an evaluator with a technical background will notice a submission that treats every automated system as the same thing. Name the family of technique you mean and stay consistent with the name.
Avoid performance figures you cannot source. A claimed detection rate without a dataset, a baseline and a citation says nothing, because the same technique performs very differently on different data. Where you want to make a quantitative point, describe the tradeoff rather than inventing a number: raising sensitivity catches more real threats and produces more false alarms, and the analyst hours consumed by those alarms are the real constraint.
Include the ethical and privacy dimension where it applies. Monitoring systems watch people, models trained on operational data inherit whatever bias that data carries, and automated action taken against a user account has consequences for that user. Cite framework or policy sources for those claims in the style your task specifies, and cite at the point of the claim.
What earns Competent, and what comes back
Competent work treats the technique as a means. It states the operational problem in concrete terms, shows that the data needed actually exists, chooses an approach with a reason and a rejected alternative, and is candid about the errors the system will make and who absorbs them. It also draws a clear line between what runs automatically and what a person decides.
Returns cluster in five places. The proposal describes a technology and never states the problem it solves here. The data section assumes signals that the described environment does not collect. Error rates are ignored, so the design has no failure behavior. Automation is proposed for actions whose failure would cause an outage, with no safeguard. Or oversight is answered with a sentence saying that humans will review the output, without saying which humans, reviewing what, and how often.
A fast check before you submit: for every automated action in your design, write down what happens if it fires on a normal event. If the answer is unacceptable, that action needs a human gate, and saying so is a stronger answer than pretending the model will not be wrong.
WGU attaches no grade penalty to a revised and resubmitted performance assessment, so submit when every aspect carries a genuine answer. Objective assessments at WGU are proctored, and our boundary is absolute: preparation only, with concept drills, terminology work, scenario practice and a candid read of your preassessment. Sitting an assessment is outside what we do, we are uninvolved while one runs, and we neither ask for nor hold portal credentials.
Proposal reads like a product brochure?
Send the E026 rubric and your scenario. We rebuild it problem first, with the data it needs, the errors it will make and the human gate where it belongs.
Six mistakes that cost time in E026
- Leading with the technology. Name the operational problem and its current cost first, or the proposal has nothing to justify it.
- Assuming data that is not collected. A technique needs signals. Check the described environment actually produces them.
- Ignoring false positives. Alert volume is the constraint real teams live with. A design that ignores it will not survive contact.
- Automating disruptive actions blindly. Enrichment can be automatic; isolating a host usually needs a human gate. Say which is which.
- Unsourced performance numbers. Accuracy claims without a dataset and a citation are decorative. Describe the tradeoff instead.
- Oversight as a slogan. Name who reviews what, how often, and what record proves the review happened.
Three questions students ask about E026
Do I need to write code or train a model for this course?
How much math background does this assume?
Is E026 the same course as ITCL 2201?
Where E026 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.