Table of contents
- Classify the Use Case and Establish the Guardrails
- Use a PEST Analysis and a SWOT Analysis Before Choosing AI Use Cases
- Use the Cone of Plausibility to Avoid AI Fantasy Planning
- Threat Model the AI System Before It Becomes Business-Critical
- Define Policies, Procedures, and User Awareness
- Determine Logging, Monitoring, Alerting, and AI Observability
- Use a Gap Analysis to Identify What Must Change
- Align the Program to Existing Frameworks
- Use the SIPOC Tool to Operationalize the AI Initiative
- Identify and Manage Stakeholders With a Power/Interest Grid
- So What Should Leaders Do With This?
As TrustedSec performs more AI assessments, one of the most common themes we hear from clients is that they have been directed to adopt AI, but they don’t yet know where or how to begin. That’s not unusual. Organizations often receive a technology mandate before there’s a clearly defined business problem, ownership model, data strategy, governance structure, or operational plan.
I’ve seen this pattern before with other major technology initiatives. An organization may begin with a specific problem, such as improving collaboration or data sharing, and select a larger platform as the solution. The original problem may be addressed, but the selected solution quickly introduces broader questions around user access, licensing, support, training, data governance, collaboration features, security controls, and stakeholder expectations. What starts as a focused business problem becomes a much larger organizational change effort.
AI creates the same challenge, but with greater complexity. A request to “implement AI” may sound like a tool selection issue, but it quickly becomes a question of business process, business data of all classification levels, identity and access, security controls, user behavior, monitoring, accountability, and governance. A chatbot that summarizes public content is very different from a retrieval-augmented system connected to internal documents. A coding assistant is very different from an AI agent that can call APIs, create records, modify data, or trigger business workflows.
The first question shouldn’t be, “Which AI tool should we buy?” The first question should be, “What are we trying to accomplish, and what must be true before this capability is allowed to operate inside the business?”
When clients ask where to begin with AI, the answer is rarely just a tool recommendation. It’s an assessment of what the organization can responsibly operate, monitor, defend, and support. It’s also a plan to close the gap between where the organization is and where it needs to be before AI gets integrated. A secure AI initiative should not start with a model, but with a framework.
As I thought through a framework that could address concerns from all perspectives within an organization, I realized this was really a strategy development exercise. I covered a similar approach in a 2020 SANS blog post on building an information security program in a post-breach environment. I'll use the same concepts and tools for developing an AI strategy in this blog post.
Classify the Use Case and Establish the Guardrails
Before an organization decides where AI can help, it needs to understand what kind of AI use is actually needed. Not every AI use case introduces the same level of risk. A tool that helps an employee draft an email is very different from a system that can search internal records, recommend a decision, call an API, or modify business data.
Is AI being used to assist, retrieve, recommend, or act?
At the lowest level, AI may only assist an individual user. It may help summarize, draft, classify, or brainstorm, while the human remains fully responsible for the final product. At the next level, AI may retrieve or analyze internal information. This introduces questions about data classification, access control, source integrity, and whether the user should be allowed to see everything the AI can retrieve.
Things get riskier when AI begins influencing business decisions. If an AI system recommends how to prioritize support tickets, assess risk, generate security findings, evaluate business data, or respond to customers, the organization needs to understand who owns that recommendation and how it will be reviewed.
The highest-risk use cases are those where AI can take action. Once an AI system can create tickets, send messages, update records, query customer data, trigger workflows, or call APIs, it’s not just producing content. It’s participating in business operations.
This is where governance, risk, and compliance need to be addressed before the technical implementation moves too far. The organization should define the policies, procedures, roles, and control expectations that guide AI adoption across the business.
Common considerations include:
- An internally developed and approved AI use policy
- Data classification rules for AI tools
- Restrictions on regulated, confidential, customer, employee, and proprietary data
- Vendor and third-party AI review requirements
- Human review requirements for high-impact outputs
- Rules for AI-generated code, reports, legal language, customer communications, and security analysis
- Model, application, and prompt logging expectations
- Incident response procedures for AI-related events
- Exception handling and approval workflows
- Requirements for testing before production use
This governance layer should answer a simple question: what must be true before an AI system is allowed to touch business data, influence business decisions, or interact with users?
Without an answer, AI adoption becomes inconsistent. One department may treat AI as a productivity tool. Another may use it to summarize sensitive records. Another may connect it to internal systems. Another may build an agent that can take action through APIs. Each use case introduces different risks, but without governance they may all be treated as the same thing. They are not the same thing.
The point isn’t to label AI as safe or unsafe. The point is to understand what the system is allowed to access, what it is allowed to influence, how much authority it has, and what controls must exist before it becomes part of a business process. The guardrails should scale with the level of access, autonomy, sensitivity, and business impact.
Use a PEST Analysis and a SWOT Analysis Before Choosing AI Use Cases
Security teams are often brought in after the business has already selected a tool. By that point, the conversation can become unnecessarily adversarial. The business thinks it has already made a decision, and security is left trying to explain risks that should have been part of the decision process from the beginning.
A better approach is to evaluate the environment before choosing the use case or the tool. When I look at early AI strategy, I like to separate two questions that often get blended together: why is the organization being pushed toward AI, and is the organization actually ready to support the use cases being discussed?
The challenge is understanding how to evaluate the environment in such a way that aligns the technical and security goals to the goals of the business in a way that’s contextual and understandable to all those perspectives.
Two tools that can be used for this evaluation are PEST (Political, Economic, Social, and Technological) analysis and SWOT (Strengths, Weaknesses, Opportunities, and Threats) analysis. Both of these tools are in the form of a four-quadrant grid.
A PEST analysis is a strategic framework used to assess the external macro-environment factors that could affect an organization, initiative, or decision.
In a PEST analysis each quadrant captures relevant factors, risks, or questions, not solutions. The point is environmental scanning, not problem-solving. The reason I recommend this is that it forces structured thinking about factors outside the organization's direct control before committing to a strategy or initiative.
A PEST analysis helps answer the question: why is the organization being pushed toward AI? It looks at the external pressures shaping the AI conversation. These may include regulatory pressure, board expectations, customer requirements, competitive pressure, workforce concerns, public perception, data readiness, architecture maturity, and the ability to monitor and secure the environment.
There are several variants for PEST that include:
Name | Adds to PEST |
|---|---|
PESTLE/PESTEL | +Legal, +Environmental |
STEEPLE | +Legal, +Environmental, +Ethical |
STEPPLED | +Demographic on top of STEEPLE |
PESTLIED | +Legal, +International, |
STEEP | Drops Political, focuses on Social, Tech, Economic, Environmental, Political reordered |
Figure 1 - PEST Analysis Variants (Courtesy of Chartered Management Institute)
For the purposes of this blog, and simplicity, I'm going to use PEST. An example PEST analysis might look like this:
Once the external environment is understood, a SWOT analysis can help evaluate internal readiness. SWOT analysis is a strategic planning framework used to evaluate an organization, project, or decision by examining both internal capabilities and external conditions.
In this case, a SWOT analysis helps answer the question: is the organization actually ready to support the use cases being discussed? It looks at internal strengths and weaknesses, then compares them against external opportunities and threats. This is where the conversation becomes more contextual from an organizational perspective. The organization may have executive sponsorship, strong cloud architecture, and mature security operations. It may also have inconsistent data quality, unclear ownership, weak AI policy, immature logging, or limited user training.
The real value is in pairing the quadrants, matching strengths to opportunities (where to push) and identifying where Weaknesses meet Threats (where exposure is highest). A SWOT used only as a list misses that analytical layer.
PEST and SWOT are often used together. PEST informs the external half of SWOT, the Opportunities and Threats quadrants. Running PEST first gives you richer, more structured input before you build the SWOT.
An example SWOT analysis might look like this:
PEST and SWOT don’t secure AI by themselves. They help avoid choosing AI projects in a vacuum. They make the business context visible before technical decisions are made. The wrong AI use case can fail even when the tool works as designed. The issue is often not the model. The issue is whether the organization had the governance, data, controls, users, and operating model needed to support it.
Use the Cone of Plausibility to Avoid AI Fantasy Planning
AI creates a planning problem for organizations because the future is not yet clear. Most organizations know they are expected to adopt AI, but they may not yet know which use cases are realistic, which risks are acceptable, which controls are required, or which outcomes are actually achievable in their environment. This is where the Cone of Plausibility becomes useful.
Imagine a sideways-facing cone extending from the organization’s current state into the future. At the narrow end is where the organization is: the current business model, data maturity, technology stack, regulatory environment, security program, workforce capability, and risk tolerance.
As the cone extends forward, the range of possible AI futures expands. Some of those futures are useful. Some are unrealistic. Some are overly optimistic. Some are overly pessimistic. The purpose of the cone is not to predict one perfect future. The purpose is to help the organization reason through what futures are plausible and which ones should influence strategy.
At the top is the over-optimistic AI narrative. This is where AI saves the organization, transforms every process, eliminates inefficiency, reduces cost, improves quality, and creates competitive advantage with minimal disruption. When this kind of optimism is taken too far it becomes hype. It assumes the organization can move faster than the data, people, controls, and processes may realistically allow.
Towards the bottom is the over-pessimistic AI narrative. Here, AI introduces unacceptable risk, leaks sensitive data, creates regulatory exposure, damages customer trust, replaces human judgment, and causes business failure. When this kind of thinking gets taken too far, it becomes paralysis. It assumes the risks are so severe that the organization cannot responsibly adopt AI at all.
Between those two extremes is the plausible operating range. This is where useful AI strategy lives.
The plausible operating range includes the AI futures that could realistically occur based on the organization’s business strategy, operating model, data quality, security maturity, regulatory obligations, budget, culture, and technical capability. These are not fantasy outcomes. They are scenarios the organization can reasonably evaluate, prioritize, test, govern, and improve.
For example, it may not be plausible for an organization to immediately deploy autonomous AI agents that can take action across production systems. However, it may be plausible to implement an internal knowledge assistant using approved documentation, strong access controls, logging, and human review. Replacing an entire support process with AI isn’t realistic. However, using AI to summarize tickets, suggest responses, classify issues, or improve analyst triage is.
The Cone of Plausibility helps the organization ask better questions:
- What AI outcomes are possible but unrealistic for us right now?
- What outcomes are plausible based on our current maturity?
- What outcomes become plausible if we improve our data, controls, monitoring, and governance?
- What outcomes create enough business value to justify the risk?
- What outcomes should be avoided because they exceed our ability to govern them?
- What preferred future should we intentionally move toward?
This is where PEST and SWOT analyses provide important context. PEST helps identify the external forces shaping the organization’s AI future: political, economic, social, and technological pressures. SWOT helps identify the internal strengths, weaknesses, opportunities, and threats that determine whether an AI initiative is realistic. Together, these tools help narrow the cone.
The organization starts with a broad range of possible AI futures. Then, it uses business context, risk analysis, governance requirements, threat modeling, and stakeholder input to identify the futures that are actually plausible. From there, the organization can select a preferred strategic future: the AI-enabled operating model that creates measurable value, aligns with the business strategy, and can be responsibly governed.
The goal is not to chase the most exciting AI use case, but to identify the AI future the organization can safely and intentionally build toward.
Without this step, AI strategy is often driven by fear, hype, vendor pressure, or executive mandate. With this step, AI strategy becomes a deliberate planning exercise. The organization can acknowledge both the upside and downside of AI without being controlled by either extreme.
The Cone of Plausibility gives leaders a way to say: “Here is where we are today. Here are the futures we can imagine. Here are the futures that are realistic. Here are the risks we must manage. And here is the future we are choosing to pursue.”
Threat Model the AI System Before It Becomes Business-Critical
Once plausible use cases are selected, the organization should threat model each AI system.
- The threat model considerations include:
- The business process being augmented
- The users and administrators
- The model or AI service provider
- The data sources
- The prompts and system instructions
- The retrieval layer, if Retrieval-Augmented Generation (RAG) is used
- The vector database or embedding store
- The plugins, tools, APIs, and connected systems
- The identity and authorization model
- The trust boundaries
- The logging and monitoring points
- The failure modes
- The abuse cases
Traditional threat modeling still matters, but AI adds new patterns. Prompt injection, indirect prompt injection, sensitive information disclosure, excessive agency, insecure tool use, data poisoning, vector store manipulation, model DoS, and hallucinated or unsafe output all need to be considered.
The threat model should also ask what the AI system can influence. Can it only generate text? Can it retrieve documents? Can it call tools? Can it send messages? Can it create records? Can it modify data? Can it trigger workflows? Can it reach external systems?
The more agency the system has, the more important authorization, approval workflows, rate limits, output validation, and human-in-the-loop controls become.
Define Policies, Procedures, and User Awareness
End-users need clear guidance. They should not be expected to understand AI risk through intuition.
Users should know:
- What AI tools are approved
- What data they may and may not enter
- Whether AI output must be reviewed before use
- How to report inaccurate, unsafe, or suspicious AI behavior
- Whether AI-generated content needs disclosure
- What use cases are prohibited
- What happens when AI produces confidential, offensive, biased, or incorrect output
- How to handle AI-generated code, summaries, recommendations, or customer-facing content
Procedures for AI system owners and administrators should be defined. Things like onboarding new AI tools, approving data sources, reviewing model changes, handling vendor changes, testing new integrations, responding to incidents, and periodically reassessing risk should also be defined.
AI awareness training should be practical. Users do not need a lecture on neural networks. They need to understand the behaviors that create risk: pasting sensitive data into unapproved tools, trusting output without verification, using AI-generated code without review, connecting AI to data it should not access, and treating confident output as correct output.
Determine Logging, Monitoring, Alerting, and AI Observability
AI systems should not operate as black boxes. If an organization cannot determine what an AI system accessed, what it produced, what tools it called, what policies were enforced, and what actions were taken as a result, then the organization will struggle to validate controls, investigate incidents, or demonstrate responsible use.
AI monitoring should be treated as an extension of existing security, application, infrastructure, privacy, and compliance monitoring. Many organizations already have logging and monitoring capabilities in place, and the broader market now includes a growing number of AI-focused observability, governance, safety, and security tools. These tools vary widely in maturity and focus. Some are designed for application performance and model behavior. Some focus on prompt and response analysis. Some monitor RAG, vector stores, and data access patterns. Others focus on policy enforcement, sensitive data exposure, model risk, agent actions, or integration with existing security operations workflows.
The important point is not that an organization must immediately buy a new AI monitoring platform. The important point is that AI creates new types of events that may not be fully captured by traditional application logs or infrastructure telemetry.
Depending on the use case, AI observability may include:
- User identity and session context
- Prompt and response metadata
- Redacted prompt and response content where appropriate
- Model, provider, and version information
- Retrieval events from internal knowledge sources
- Documents or data sources referenced by the AI system
- Tool, plugin, API, or agent actions
- Authorization decisions
- Policy enforcement decisions
- Blocked or filtered requests
- Sensitive data exposure indicators
- Attempts to bypass instructions or controls
- Administrative and configuration changes
- Token usage, latency, error rates, and cost anomalies
- Human approval, rejection, or override events
These events should be routed to the appropriate operational processes. Some may belong in application monitoring, others in security monitoring. Some may require privacy, legal, compliance, or business-owner review. The organization should define which AI events are security-relevant/operationally relevant, and which require escalation.
Alerting should focus on behaviors that indicate meaningful risk, such as repeated attempts to extract sensitive data, attempts to bypass system instructions, unusual access to protected knowledge sources, unexpected tool use, excessive or abnormal model usage, unauthorized configuration changes, or AI-generated output being used in workflows that require human approval.
The goal is not to collect every AI interaction indefinitely. The goal is to create enough visibility to answer important questions:
- What did the AI system access?
- What did it produce?
- Was the user authorized?
- Were policies enforced?
- Did the system call any tools or APIs?
- Was sensitive data involved?
- Was human approval required?
- Was an alert generated?
- Can the event be investigated later?
Organizations should evaluate AI monitoring capabilities based on their use cases, risk tolerance, regulatory obligations, data sensitivity, and existing security architecture. In some environments, existing logging, monitoring, and SIEM workflows may be sufficient if they are extended to capture AI-specific events. In other environments, dedicated AI observability, model monitoring, governance, or security tooling may be appropriate.
The monitoring strategy should be selected based on the AI system’s risk profile, not market noise. A low-risk internal productivity tool may only require basic usage, access, and policy logging. A retrieval-augmented system connected to internal documents may require visibility into data access, retrieval behavior, and sensitive information exposure. An AI agent that can call tools or perform business actions may require much stronger monitoring around authorization, tool use, approvals, and exception handling.
The important point is that monitoring should be designed before AI systems become business-critical. Visibility, alerting, investigation, and response should be part of the AI implementation plan, not an afterthought added after the first incident.
Use a Gap Analysis to Identify What Must Change
Once the organization has used PEST/SWOT and the Cone of Plausibility to identify a realistic AI direction, and has started defining the governance guardrails, threat models, policies, and procedures needed to support that direction, the next step is to determine what is missing between the current state and the desired future state. This is where a Gap Analysis is useful.
A Gap Analysis compares the organization’s current state to its desired future state. In the context of an AI initiative, the current state may include the organization’s existing governance, policies, data maturity, technical architecture, security controls, monitoring capabilities, user training, vendor management process, and operational readiness.
The desired future state is the AI capability the organization wants to responsibly implement. That may be an internal knowledge assistant, AI-assisted security triage, a developer productivity tool, a customer support assistant, a business process automation capability, or a more advanced AI agent.
The Gap Analysis asks a simple but important question: what has to be created, improved, approved, documented, funded, trained, monitored, or controlled before this AI initiative can be safely implemented?
For example, the organization may discover gaps such as:
- No approved AI acceptable use policy
- No process for reviewing AI vendors
- No clear data classification rules for AI use
- No defined risk acceptance process for AI-enabled systems
- No logging or monitoring requirements for prompts, responses, retrieval events, or tool use
- No clear ownership for AI-generated outputs
- No user training for approved and prohibited AI use
- No process for testing AI systems before production use
- No incident response procedure for AI-related events
- No governance model for reviewing new AI use cases
- No technical architecture for secure AI integration
- No defined human approval requirements for high-impact decisions
The purpose of the Gap Analysis is not to stop the AI initiative. The purpose is to make the implementation realistic. It gives the organization a clear view of what must be addressed before moving forward.
This is especially important because AI initiatives often expose weaknesses that already existed in the organization. Poor data governance, unclear ownership, immature logging, inconsistent access control, weak vendor review, or limited user training may not be AI-specific problems. However, AI can amplify those problems by making data easier to access, outputs easier to trust, and actions easier to automate.
A Gap Analysis helps the organization convert AI strategy into a practical implementation roadmap. Each gap can be translated into an action item, owner, dependency, risk decision, control requirement, or project milestone.
For example:
- If the gap is missing policy, the action may be to create AI acceptable use standards.
- If the gap is unclear data access, the action may be to define approved data sources and access controls.
- If the gap is insufficient monitoring, the action may be to define AI observability and alerting requirements.
- If the gap is user readiness, the action may be to create training and communication plans.
- If the gap is unclear accountability, the action may be to assign business, technical, and control owners.
The Gap Analysis becomes the bridge between strategy and execution. After the preferred AI future has been identified, the organization needs to determine what stands between the current state and that future. A Gap Analysis provides that bridge. Once the gaps are known, a tool called SIPOC (Suppliers, Inputs, Process, Outputs, Customers) can be used to map the process, artifacts, and stakeholders required to close them. The SIPOC will be discussed later in this blog.
Align the Program to Existing Frameworks
Over the past few months, I’ve seen several posts from individuals claiming they have created an AI governance program from scratch. Organizations don’t need to reinvent the wheel—existing frameworks can and should structure that effort.
If you’re standing before executives, board members, auditors, or regulators and are asked about your AI governance program, the stronger answer is that you are leveraging an industry-standard framework. These frameworks are already widely socialized and understood by those audiences.
To understand what those audiences expect and what questions they are trained to ask, start with the National Association of Corporate Director's Handbook on Cyber-Risk Oversight. The NACD represents the board members and executives you will likely face in those conversations, and reading their guidance tells you how governance is evaluated from the top down.
From there, the right frameworks depend on the layer you are addressing.
The NIST AI RMF can help frame AI risk governance, mapping, measurement, and management. NIST’s Generative AI Profile can help organizations think through risks that are specific to GenAI. OWASP’s LLM and GenAI guidance can help application and security teams focus on common implementation risks. MITRE ATLAS can support adversarial threat modeling for AI-enabled systems. ISO/IEC 42001 can help organizations formalize an AI management system. Existing cybersecurity frameworks, such as NIST CSF, can still apply because AI systems are still software, data, identity, infrastructure, vendors, and business processes.
The key is not to pick a framework and treat it as a checklist. The key is to use the right framework at the right layer.
- Governance frameworks help define accountability.
- Threat frameworks help identify abuse cases.
- Security control frameworks help define safeguards.
- Process tools help operationalize implementation.
- Stakeholder tools help keep the initiative aligned.
These are all voluntary frameworks and none of them is prescriptive by design. A sound approach is to implement the controls that reduce the most risk first, and build from there.
Use the SIPOC Tool to Operationalize the AI Initiative
After governance, strategy, plausibility, and threat modeling are complete, the organization needs an implementation model. SIPOC is useful because it forces teams to define the process before they automate or augment it.
A SIPOC is a high-level process mapping tool used to understand how work flows from beginning to end. SIPOCs also help an organization identify important information, e.g., who provides the information, artifacts, decisions, or resources needed for a process; what those inputs are; what process steps transform those inputs; what outputs are created; and who receives or depends on those outputs.
This is especially useful for AI initiatives because it’s rarely done by one team. It may involve executive leadership, legal, compliance, privacy, risk management, security, IT, architecture, procurement, finance, data owners, business units (BUs), training teams, and end-users. A SIPOC provides a shared view of the work required to move from AI strategy to governed implementation.
A SIPOC is useful because it creates structure before the organization dives into detailed planning or technical implementation. When organizations begin AI initiatives, it is easy to jump directly to tooling, vendors, models, or use cases. SIPOCs create breathing room to ask important questions:
- What work actually needs to happen?
- What decisions need to be made?
- What artifacts need to be produced?
- Who provides the required inputs?
- Who receives the outputs?
- Who needs to be involved from a governance, risk, compliance, technical, and business perspective?
Another benefit of a SIPOC is that it exposes the full chain of responsibility. It helps identify stakeholders, dependencies, handoffs, missing inputs, unclear ownership, and process gaps early in the initiative.
For AI adoption, this is important because the output of one process often becomes the input for another. For example, the governance process may produce acceptable use rules, risk decisions, and control requirements. Those outputs then become inputs for architecture, security design, vendor selection, user training, monitoring, and operational support.
SIPOCs helps prevent AI implementation from becoming a disconnected set of activities. It shows how strategy, governance, technical design, implementation, training, and operations connect to each other.
An example SIPOC for an AI initiative might look like this:
When using a SIPOC, it’s often helpful to start with the Process column instead of the Suppliers column.
The Process column identifies the major steps required to complete the initiative. For an AI implementation, those steps may include defining the AI strategy, selecting priority use cases, establishing governance and policy guardrails, designing the technical architecture, selecting or building the AI solution, training users, and operating the capability.
Once the major processes are identified, the next step is to determine the Outputs created by each process. Outputs are the artifacts, decisions, deliverables, or results produced by the process. These may include an AI initiative charter, prioritized use cases, business case, approved policies, risk decisions, control requirements, reference architecture, logging and monitoring plan, implementation plan, user guidance, training materials, and operating procedures.
After the outputs are defined, identify the Customers who receive or depend on those outputs. In this context, customers may be internal stakeholders rather than external customers. They may include executive sponsors, steering committees, business owners, control owners, security teams, implementation teams, platform owners, managers, end-users, compliance teams, audit teams, and the SOC.
At this point, the organization has identified the downstream side of the process: what gets produced and who needs it.
Then, the team works backward to identify the Inputs required for each process. Inputs are the information, artifacts, requirements, or resources needed to perform the work. For an AI initiative, inputs may include strategic objectives, business problems to solve, budget goals, regulatory obligations, risk appetite, data classification rules, technical requirements, approved data sources, access control requirements, vendor assessments, cost models, user requirements, training materials, and change management plans.
Finally, identify the Suppliers who provide those inputs. Suppliers may include executive leadership, legal, compliance, privacy, risk management, security, IT, architecture, data owners, procurement, finance, vendors, service providers, BUs, HR, communications, training teams, and end-user representatives.
By working through the SIPOC this way, the organization identifies stakeholders from both directions. The Outputs and Customers reveal who depends on the results of the process. The Inputs and Suppliers reveal who must provide the information, approvals, requirements, and resources needed to make the process successful. This creates an end-to-end stakeholder view.
For AI initiatives, that’s one of the most important benefits of SIPOC. It helps the organization understand not only what needs to be implemented, but who needs to be involved, what each group provides, what each group receives, and where governance, risk, compliance, security, technical, and operational responsibilities intersect.
Identify and Manage Stakeholders With a Power/Interest Grid
AI initiatives affect more stakeholders than most teams expect. Legal, compliance, security, engineering, data owners, HR, privacy, procurement, business leadership, customer support, and end-users may all have legitimate concerns.
A power/interest grid helps determine how to manage those stakeholders:
High Power/High Interest: Manage closely: these are executive sponsors, system owners, legal, compliance, security leadership, and business owners for high-impact use cases.
High Power/Low Interest: Keep satisfied: these may include senior leaders or control owners who do not need daily detail but must remain confident that the initiative is aligned with business risk tolerance.
Low Power/High Interest: Keep informed: these are often end-users, analysts, support teams, developers, and operational teams directly affected by the AI system.
Low Power/Low Interest: Monitor: these stakeholders may not need frequent engagement, but their interest or influence could change as the project evolves.
An example Power/Interest Grid might look like this:
Stakeholder management matters because AI adoption often fails socially before it fails technically. Users may not trust it. Legal may be brought in too late. Security may be treated as a blocker. Business leaders may expect more capability than the system can responsibly provide. A stakeholder plan helps prevent those gaps.
So What Should Leaders Do With This?
In sum, this blog is intended to be a high-level guide for building an AI adoption strategy. It’s not meant to suggest that every organization should follow the exact same path. The right approach depends on what might realistically work inside your organization, based on your business objectives, culture, data, technical maturity, security capabilities, risk tolerance, and the stakeholders who will be affected by the change.
AI adoption should not be planned in a silo. Plans created in a silo rarely get the level of buy-in needed to survive implementation. One of the most important steps in building support is giving affected stakeholders a voice early in the process. That does not mean every suggestion has to be accepted or every concern should override the strategy. It means the organization should look for trends in the feedback, identify edge cases that may have been missed, and use the input that makes sense. By giving stakeholders a chance to participate, the organization begins the buy-in process before the implementation ever starts. People are more likely to support a change when they can see that their perspective was considered.
Your organization may or may not already have a PEST or SWOT analysis. Since those tools are often developed or influenced by business leaders, it may make sense to start there. Have the conversation with leadership, understand what already exists, and begin socializing the approach. This also demonstrates that technology and security leaders are thinking beyond tools and controls. They are considering the broader business environment, the organization’s strengths and weaknesses, external pressures, stakeholder concerns, and the practical limits of what can be implemented safely.
An initiative like this creates organizational change. Managing that change, along with the expectations that come with it, is just as important as the technical and security work. In my opinion, incremental change that accounts for affected stakeholders is usually more effective than a hurried implementation where communication, training, and stakeholder management happen after the fact. A more deliberate approach helps ensure that the right use cases are considered, the right risks are identified, and the organization understands how the change will affect people, processes, data, and operations.
AI adoption should also be evaluated frequently. The technology is changing quickly, and course corrections are easier to make when issues are identified early. Organizations should consider how an AI implementation may create dependency on specific tools, vendors, workflows, integrations, or business processes that may be difficult to unwind later. Availability, cost, licensing changes, vendor direction, regulatory expectations, and operational support can all affect the long-term viability of an AI strategy.
For those reasons, it is worth thinking through backup and tertiary plans before they are needed. If a provider becomes too expensive, if a service changes direction, or if availability becomes an issue, leaders should understand what alternatives exist. Responsible AI adoption is not just about getting the first implementation right. It is about creating an approach that can adapt as the organization learns, as the technology changes, and as the business environment evolves.
The goal is not to move as fast as possible or to avoid AI because the risks are uncomfortable. The goal is to move deliberately, with enough structure to make good decisions, enough stakeholder involvement to create buy-in, and enough flexibility to adjust when conditions change, which is inevitable.