Artificial intelligence creates more than one cybersecurity problem for business leaders. Employees may use AI to draft content or analyze information; security teams may use it to sort alerts; and attackers can use it to scale impersonation or manipulate familiar workflows. Treating AI as a single tool category hides three separate leadership decisions.
The National Institute of Standards and Technology's Cybersecurity Framework Profile for Artificial Intelligence, often called the Cyber AI Profile, offers a useful way to separate them. NIST's IR 8596 is currently labeled an initial preliminary draft. Its three focus areas are securing AI system components, conducting AI-enabled cyber defense, and thwarting AI-enabled cyber attacks. The point for business leaders is not to adopt a new checklist blindly. It is to see that protecting AI, using AI for defense, and preparing for AI-shaped threats require connected but distinct controls.
One technology, three different questions
AI discussions often collapse risk, opportunity, and security into one conversation. That makes it easy to approve a tool because it seems useful, or reject a useful capability because its risks feel vague. Separate the decisions so each can be evaluated on its own merits:
- How do we secure AI? Identify the models, applications, data, identities, and integrations involved, then limit access and define acceptable use.
- Where can AI improve defense? Choose a bounded security workflow where assistance could reduce repetitive work, and decide what evidence and human review are required.
- How will we respond to AI-enabled threats? Strengthen identity, verification, reporting, and response processes that remain effective when messages, voices, or documents are easier to imitate.
These questions can share tools and owners, but they do not have the same success measure. A secure AI service can still be a poor choice for a particular workflow. An AI-assisted alert queue can still miss a threat. A well-designed fraud process can reduce exposure even if employees never use a generative AI product.
NIST's draft is a planning lens, not a final standard or regulatory requirement. Verify its status before treating it as mandatory. Its value is the reminder to examine both securing AI and adapting cybersecurity practices to it.
Secure the AI systems the business actually uses
Start with discovery, not procurement paperwork. Ask teams what AI features are embedded in software they already use, which standalone services they have adopted, and whether any tools can connect to company files, mailboxes, code, customer records, or administrative systems. An inventory should name the business purpose, owner, provider, data types, integrations, and approval status. Include vendor features that may be enabled by default, not just products employees identify as AI.
Map what information can enter each system and what the service can do with it. Review retention and training terms, deletion options, and the provider's incident-notification process. A public chatbot, a company-controlled assistant, and an agent that can update records have different risk profiles. Do not assume a paid plan fits every data type or workflow.
Identity and permissions deserve special attention when AI tools use connectors or agents. Give each integration only the access required for its assigned task. Separate ordinary user access from administrative privileges, require strong authentication, and record which identity an automated action uses. For systems that can send messages, change data, approve requests, or execute transactions, define limits before activation and require a person to authorize consequential actions.
Make the rules usable. Tell employees which tools are approved, what data is restricted, how to request a new use case, and where to report a mistake or unexpected output. Provide a safe path for experimentation so staff do not have to choose between an unclear policy and unreviewed workarounds.
Use AI in defense without outsourcing judgment
Security teams face large volumes of alerts, logs, and routine documentation. AI may help summarize an incident timeline, group similar notifications, explain a configuration finding, or draft a first version of a report. Start with a task that is narrow, repeatable, and easy for an experienced person to check. Define what information the tool can see and what it is not allowed to decide.
Evaluate assistance against a known sample before relying on it. Measure whether the output is accurate enough for the intended purpose, how often it misses important details, whether reviewers can trace claims back to evidence, and how much time the workflow actually saves. Keep the original logs or records available; a generated summary is not a substitute for underlying evidence. Monitor for changed behavior when a vendor updates the model or its connected data.
Keep human authority explicit. A tool that recommends a response is different from one that disables an account, blocks traffic, or sends a customer notice. For actions that affect access, operations, or evidence, use approval gates and a documented rollback path. Restrict automation to the lowest-risk actions that can be safely reversed, and record who approved both the workflow and any exception.
These safeguards let teams learn where AI helps without turning untested output into an unreviewed security decision.
Prepare processes for AI-shaped attacks
AI does not make every message or call fraudulent, and familiar attack patterns still matter. It can, however, lower the effort required to produce convincing, personalized content or imitate a trusted voice. Leaders should avoid relying on an employee's ability to spot awkward grammar or an unfamiliar tone as the only defense. Strengthen the process that verifies a request, especially when it changes money, access, payroll, or sensitive information.
For payment or account changes, confirm through a known phone number or trusted channel already on file, not a number or link supplied in the new request. Use separate approval for high-impact transactions. For sensitive data requests, verify the person's identity and business need. Make it easy to report a suspicious message or voice interaction, and ensure reports reach someone who can investigate and warn others.
Protect the identities that attackers may target first. Apply multifactor authentication, prioritize phishing-resistant methods for privileged access where feasible, review who can reset accounts, and remove access promptly when roles change. Test incident plans for scenarios involving a convincing executive impersonation, a compromised mailbox, or fraudulent instructions that arrive through a normal business channel.
Technology controls need to match how decisions are made. If a procedure permits one person to request, approve, and release a sensitive transaction, a more convincing impersonation can exploit that design. Add independent verification at the points where the business impact is highest, and rehearse the escalation path so staff know what to do under time pressure.
Put the three lenses into the leadership cadence
Leaders do not need a large committee to begin. Assign an accountable owner for AI policy, a technical owner for security controls, and a business owner for each use case. Clarify who can approve access, accept residual risk, pause a workflow, and notify leadership when something goes wrong. These responsibilities may sit with a small number of people, but they should not be implicit.
For each use case, record its purpose, data, connected services, permissions, expected benefit, test results, human review, incident path, and next review date. Then decide what to tackle first based on exposure and business impact rather than novelty. A low-risk drafting assistant with no sensitive data may be a reasonable early experiment. A system that can read customer records or take actions across several tools deserves stronger review and tighter boundaries.
Review the inventory when a vendor changes its features, a team connects new data, an agent gains new permissions, or a workflow begins affecting customers or money. Track a few measures that support decisions: whether uses have named owners, whether access matches approved purposes, whether high-impact actions are reviewed, and whether tests find issues before production. Avoid vanity counts of prompts or tools; measure whether the control works and whether the business outcome is real.
AI adoption does not require choosing between speed and security. It requires separating the decisions, assigning owners, and testing each one against real work. Secure the systems the organization uses, apply AI to bounded defensive tasks where it demonstrably helps, and improve the processes that protect people from impersonation and manipulation. That is a practical agenda whether AI adoption is just beginning or already spread across the business.
