Your AI Strategy Based on the Cyber Security Threat Landscape

Procuring an AI tool is the easiest step in this process. The selected tool will not be able to decide what data your staff may put into it, who reviews the output, or who is accountable when things go wrong. So, the question is what do you need to do when AI is introduced within your technology stack and placed directly into the hands of your own staff.

For many utilities, this reality has already arrived:

• Staff have personal accounts on AI tools that are not approved.
• Meeting platforms transcribe and summarize by default using AI-enabled tools.
• Vendors have added AI features to software you already run, delivered in updates you already applied.

In several organizations, the decision to adopt AI was never actually made. Staff took matters into their own hands. The question is not whether to allow AI, but whether the use already underway is governed, and that requires a policy.

This second part of our AI Cyber Security Series focuses on what it takes to govern AI adoption from within.

The Requirement for an AI Policy

With the rapid advancement and adoption of these new technologies, organizations have not been able to completely govern acceptable usage, safe practices, or incident response with regard to artificial intelligence.

Users have begun using these tools without proper vetting or risk assessment. That practice is known as Shadow AI. IBM defines it as the following.

“the unsanctioned use of any artificial intelligence (AI) tool or application by employees or end users without the formal approval or oversight of the information technology (IT) department.”

The instinct in many IT departments is to ban it. But users have gained real productivity from these tools, taking them away can be counterproductive to organizations. Somebody who finds a tool useful will carry on using it on a personal device, and the confidential work then leaves your environment with no record of what went along with it. A policy that says yes with boundaries gives you a foundation for navigating the threat landscape.

AI-embedded systems already run inside your organization. Assistants in the office suite, meeting transcription tools, browser add-ons and code assistants in engineering environments are present in systems used daily by every type of employee. Most of them have no “disable” option.

The Cyber security and Infrastructure Security Agency (CISA) and its partners note in their December 2025 guidance that some Operational Technology (OT) devices now ship with built-in AI, in some cases needing internet connectivity to function. Whether your organization uses AI is no longer a question the IT department can answer on its own.

Without written governance, you have no boundary on what data leaves the organization, no record of where that data was used, and no answer when a regulator or a client asks whether AI touched sensitive information. Part of the threat landscape is how your own internal material becomes training material for somebody else's AI model. Anything typed into an unvetted model is out of your control from that moment, and for a utility, that material can include asset inventories, network details and more.

Policy Scope

A policy covers everyone, with no exemption for seniority, and every tool, including the AI features inside software you already own. Contractors working on your systems sit inside the scope as well.

Data Classifications

An AI policy requires a data classification scheme behind it. The moment a member of staff is about to paste something into a chat window, they need a clear rule on what is permitted and what is prohibited. This may result in unknown information disclosures within the organization.

The four tiers in the figure below work for most utilities:

What Data Classification Does Not Enforce

A classification scheme tells people and tools what matters. By itself it stops nothing, and that is where AI policies most often fail in practice. Once a member of staff selects a paragraph and copies it, there is no file and no metadata left, only text, and that text can be pasted anywhere. To combat these technical gaps, we recommend the following best practices:

• Put enforcement where the traffic passes. An endpoint agent, a managed browser or a web gateway can inspect a paste into an AI site. 
• Write detectors for what the top tiers of your classification actually look like in your organization, such as asset tags, relay settings or address ranges. 
• Log what cannot be blocked. What people are actually pasting is the input to the next revision of the tool list. 

Approved Tools

Classification applies to tools as well as to information. The policy should name which tools are allowed and what class of data each one is cleared for. Evaluate each tool in use. Questions regarding the assessment may include:

• Where is data processed and stored?
• Does the tool train on customer input?
• Does the tool support single sign-on and audit logging?
• Does the tool conflict with requirements you already work under?

Terms of service can change quickly. Since 24 April 2026, GitHub Copilot has used interaction data from the personal Free, Pro and Pro+ plans to train and improve its models unless the user opts out. The Copilot Business and Copilot Enterprise plans are not affected by that change.

Changes like this will continue to come, so set a cadence for reviewing the tool inventory.

Acceptable Use

Guidelines for what is not allowed should take a clear position on what users are already doing. It is recommended to apply the following best practices:

• No personal accounts for work.
• State the tiers from your organization’s data classification scheme that may not go into any AI tool.
• No AI output is treated as fact until a qualified member of staff has reviewed it.

Accountability

AI output is raw material. It is not finished work, and a qualified individual should review it before any of it is accepted. AI can never be held accountable. It is a tool that acts on a user’s instructions, so the user is always responsible. An IBM training manual from 1979 captured the same idea. 

A computer can never be held accountable; therefore, a computer must never make a management decision.

An individual who submits work produced with AI owns it. To enforce that accountability, user accounts should be individual rather than shared, which keeps logging and auditing accurate.

Transparency

Transparency should be encouraged in any organization that uses this technology. AI is both an exciting and a divisive talking point depending on who is asked.

Organizations and individuals who get called out for using AI are usually the ones who did not declare it. So, the use and its purpose are best disclosed in advance. Consider how AI was used, and whether to disclose it:

• If AI helped with research, structure or formatting and the author checked everything, no disclosure is needed.
• If AI drafted substantive content used in the final work, it is advised to say so.
• If AI generated analysis, summaries, or interpretations that shaped the conclusions, disclose which sections relied on AI output and describe how it was reviewed or verified.
• If AI tools processed sensitive, proprietary, or personal data during the work, disclosure should note this alongside the data-handling safeguards used.

Policy Limits

Some things an AI policy will not reach, and they need separate attention. A policy governs how your personnel use AI. It does not govern where AI sits in your network, what your vendors have embedded in your equipment, or what you do when a model strays from the intended instruction set.

Network Segregation

Language models belong in the business layers, working on data taken out of systems. Nothing should reach into the control path on its own authority.

Push data out, and do not let anything reach in. CISA recommends push-based or brokered patterns that move summaries out of the OT network without granting persistent inbound access. That keeps the OT network segregated from the network where AI tools are configured.

Remember that AI is meant to make parts of the job easier, not to do the job for you. Keep operators practised enough to run processes this way and always keep a human in the loop.

Figure 2 maps this across the plant. At the bottom are field devices, then local controllers such as programmable logic controllers (PLCs) and remote terminal units (RTUs). Above them sit the supervisory systems operators work with, including supervisory control and data acquisition (SCADA), distributed control systems (DCS) and human-machine interfaces (HMI). Language models belong at the top, in the enterprise and business systems. 

Vendor AI

What AI your vendors have embedded is a question that is usually left unanswered. Vendors are adding AI to OT products, sometimes with a connectivity requirement attached. AI capabilities in these systems include:

• Predictive maintenance
• Asset discovery
• Automated incident response

When engaging with an OT vendor for a new system, ask these questions as groundwork for understanding what AI the system carries:

• What AI is in this product?
• Where does the model run?
• Does the model train on our operational data?
• Can it work without continuous access to your cloud?
• Can we turn the feature off and keep it off?

Incident Response

Incident response plans are usually drafted once and do not go through major revision until they are executed during an incident. As seen in part 1 of our series, attackers of all skill levels are equipping themselves with this technology. Plans should cover AI related incidents including the following:

• An attack against or through an AI system can include manipulated input, poisoned data, or a model acting on instructions hidden in something it reads.
• AI system failure, where a model drifts until its outputs no longer match the plant.
• Self-inflicted data disclosure, which is sensitive material typed into the wrong tool.

CISA's guidance tells operators to update response plans for malicious activity directed at an AI system and for AI system failure. Add a section covering what the process does when an AI-assisted system is unavailable, then run it as a tabletop exercise.

Standards

The North American Electric Reliability Corporation Critical Infrastructure Protection (NERC CIP) standards already govern Bulk Electric System Cyber System Information (BCSI) handling, and AI use should not create an exemption. On the voluntary side, the National Institute of Standards and Technology (NIST) AI Risk Management Framework and its Generative AI Profile are good starting points.

Sector-specific guidance is still being written. NIST released a concept note in April 2026 for an AI RMF profile on trustworthy AI in critical infrastructure, and AI RMF 1.0 is itself under revision.

The Five Gates to Assess AI Usage

Before any action, it is worth assessing where your organization stands on AI use today. One way to do that is to run every proposed tool, and every tool already running, through five gates: do we need it, do we know what is already running, can we feed it safely, can we carry it, and can we prove it. A tool that fails a gate does not proceed until the gap behind that gate is closed. Organizations that skip this step are the ones most likely to get hurt.

From Policy to Practice

The policy is not the finish line, it's actually what lets you start. Most utilities that work through the five gates find the first gap is not technology at all, it is how people understand data and how they handle it, and both are within reach when the strategy is set up properly.

Our next part in the series works through each gate in detail and more. 

References