Your security team just deployed an AI-powered threat detection tool. Your legal department is experimenting with a contract analysis assistant. Your customer service team wants to use a chatbot trained on support tickets. Each of these decisions creates new privacy and security obligations that your existing control frameworks probably don't address.
NIST is launching a dedicated program for the cybersecurity and privacy of AI, and it's building resources to help you adapt frameworks like the Cybersecurity Framework and Privacy Framework to these scenarios. The questions below come from conversations with GRC teams trying to figure out what changes when AI enters the picture.
Do I need to update my data asset inventory when teams start using AI?
Yes, and you need to think about data differently.
When business units incorporate AI into their solutions, you're creating new dependencies on data across the organization. A marketing team's customer sentiment analysis tool might pull from the same data lake that finance uses for fraud detection. Your existing data processing register probably categorizes data by system or department, but AI models create cross-functional data flows that don't respect those boundaries.
Start by identifying which AI implementations process special categories of data. Then map the data lineage: where does the training data come from, how is it transformed, and what outputs does the model generate? This isn't just about compliance documentation. AI's analytic power across disparate datasets creates re-identification risks that wouldn't exist if those datasets remained siloed.
NIST's new program is developing guidance on securing AI systems and minimizing data leakage, which refers to the risk that model training could inadvertently expose sensitive information in the model's outputs. If your customer service chatbot was trained on support tickets containing account details, it might reveal patterns or specifics it shouldn't.
How do I classify AI-generated outputs in my data protection controls?
Treat them as derived data that inherits the sensitivity of the training inputs, then add a layer for inference risk.
If you train a model on employee performance reviews, the model's predictions about future performance are derived from special categories of data and should be protected accordingly. But there's an additional risk: the model might infer protected characteristics that weren't in the training data. AI's predictive capabilities could reveal insights about people that go beyond what you explicitly collected.
Your data classification scheme needs a category for AI-generated insights. Document what training data fed each model, what the model outputs, and who has access to those outputs. This becomes critical for responding to data subject requests. If someone asks what personal data you hold about them, you need to account for both the source data and any AI-generated predictions or profiles.
Should I be worried about AI-enabled phishing in our security awareness program?
Yes, and your annual training deck won't cut it anymore.
NIST specifically calls out AI voice generators as an example of AI-enabled threats that might require organizations to update their anti-phishing training. Adversaries can now create convincing audio of your CEO requesting an urgent wire transfer or a vendor asking to update payment details. Your finance team's rule of "verify requests over $10,000 with a phone call" becomes useless when the phone call itself is synthetic.
Update your security awareness program to address:
- Voice and video deepfakes
- AI-generated spear-phishing that references real projects and relationships
- Chatbots impersonating help desk staff to harvest credentials
More importantly, update your verification procedures. Multi-channel verification needs to involve channels the attacker can't control. If someone calls requesting a payment change, don't call back the number they provided. Use a known good number from your vendor risk profile.
How do I evaluate false positive rates when our SOC wants AI threat hunting tools?
Establish a baseline with your current detection rates, then measure how AI changes both true positives and false positives over a defined period.
NIST notes that using AI for threat hunting could increase detection rates but might also increase false positives. If your current SIEM generates 50 alerts per day with a 20% true positive rate, and the AI tool generates 200 alerts per day with a 15% true positive rate, you've gone from 10 real threats detected to 30, but you've also gone from 40 false positives to 170.
The question isn't whether the AI is "accurate." It's whether your team can investigate 170 false positives without missing the 30 real threats, and whether that's a better use of their time than investigating 40 false positives while catching only 10 threats.
This is where explainability matters. NIST emphasizes that solutions need to be explainable and interpretable so cybersecurity practitioners can understand why the AI flagged something. If your analysts can't understand the AI's reasoning, they can't improve the model or build institutional knowledge about emerging attack patterns.
Do I need new cybersecurity skills on my team to manage AI systems?
You need a combination of traditional security skills applied to new attack surfaces and some new competencies.
NIST recently introduced Security of AI as a competency area in the NICE Workforce Framework for Cybersecurity. This recognizes that securing AI systems requires understanding both how to protect the AI infrastructure (securing the model training environment, protecting model parameters, ensuring integrity of training data) and how to defend against AI-specific attacks like adversarial inputs designed to fool the model.
Your security team doesn't need to become data scientists, but they do need to understand:
- How to inventory AI systems and their dependencies
- What adversarial machine learning attacks look like (NIST published a taxonomy in NIST AI 100-2)
- How to evaluate whether an AI vendor's security claims are credible
- How to assess privacy risks from model training and inference
Consider whether your current vulnerability management process accounts for AI-specific vulnerabilities. Model poisoning, where an attacker corrupts training data to influence model behavior, doesn't look like a traditional CVE.
Where should I start with NIST's new resources?
NIST is developing a community profile to adapt the Cybersecurity Framework for AI use cases, starting with three focus areas: securing AI systems and minimizing data leakage, defending against AI-enabled attacks, and using AI to improve cyber defense and privacy protections.
The program builds on existing publications you can use now:
- NIST SP 218A covers secure software development practices for generative AI
- NIST AI 100-2 provides a taxonomy of adversarial machine learning attacks
- Draft NIST SP 800-226 offers guidelines for evaluating differential privacy guarantees
Start by mapping which of the three risk sources applies to your current AI implementations. If you're using a vendor's AI-powered security tool, you're primarily concerned with the third category. If you're building internal AI applications, the first category is your priority. Most organizations will need to address all three eventually.
Where to get more specific guidance
NIST's new program website (check nist.gov for updates) will host the community profile as it develops. The AI RMF provides the broader risk management context, while the Cybersecurity Framework community profile will give you specific control objectives.
For now, review your data processing register and identify which AI systems process special categories of data. Update your vendor risk profile template to include questions about AI model security and data retention in training datasets. Add AI-enabled attack scenarios to your next tabletop exercise.
The frameworks are catching up to the technology. Your job is making sure your controls don't fall behind while they do.
