These questions aren't hypothetical. They're the ones your legal team raised last week, the ones flagged by your procurement lead, and the ones your CISO keeps mentioning when AI tools are proposed. The NIST Cyber AI Profile Workshop highlighted these concerns, showing how practitioners are trying to integrate AI adoption with existing risk frameworks.
Here's what surfaced most often, and what you can do about it.
Q1: Do we need a separate AI risk framework, or can we integrate it into our current system?
You don't need a separate framework. Integrate AI risk into your existing enterprise risk management structure.
The consensus is clear: AI risk is organizational risk. Treating it separately creates gaps and confusion. Your current risk register, governance committees, and reporting lines should include AI considerations just like they did with cloud or mobile risks.
Start with the NIST Cybersecurity Framework (CSF) 2.0 functions you already use (Identify, Protect, Detect, Respond, Recover) and add AI-specific subcategories. For example, under Identify, include asset management for AI models and datasets. Under Protect, add controls for model versioning and data tracking.
The NIST AI Risk Management Framework isn't a replacement. It's a companion that defines AI-specific risks like data poisoning. Map these risks to your existing CSF implementation for integration without redundancy.
Q2: Who should own AI risk management? Our AI team lacks cybersecurity expertise, and our security team lacks AI knowledge.
This is a multidisciplinary collaboration gap. AI involves legal (bias and liability), technical (model architecture), procurement (third-party dependencies), and governance (risk appetite) considerations.
You need a cross-functional working group, not a single owner. Include representatives from:
- Information security (threat modeling and incident response)
- Data governance (data lineage and privacy controls)
- Legal (regulatory obligations and contractual risk)
- Engineering or AI development (model behavior and performance)
- Procurement (vendor due diligence on AI components)
Run this group like a SOC 2 readiness team. Assign a program lead, but distribute control ownership across functions. Your security team shouldn't evaluate model drift alone; your AI team shouldn't write incident response playbooks by themselves.
Participants highlighted the need for education to bridge knowledge gaps. Schedule joint training sessions where AI engineers explain model behavior to security staff, and security staff walk AI teams through threat scenarios like adversarial inputs.
Q3: How do we manage AI as both a defense tool and an attack vector?
AI's dual-use nature requires planning for both scenarios. You're deploying AI to improve anomaly detection, but adversaries use AI to scale phishing campaigns or poison your training data.
For defensive AI use:
- Establish benchmarks before deployment. If your AI-driven SIEM generates 40% false positives, it's creating alert fatigue.
- Implement human-in-the-loop processes for high-stakes decisions. Your AI can recommend; a human should authorize.
- Document model behavior and decision logic. When asked how your AI reached a conclusion, "the model decided" isn't enough.
For offensive AI threats:
- Update threat models to include AI-enabled attack techniques. MITRE ATLAS provides a taxonomy for adversarial machine learning tactics.
- Apply Zero Trust Architecture principles to AI components. Validate and monitor model outputs.
- Build incident response runbooks that distinguish between traditional breaches and AI-specific attacks like model poisoning.
Q4: What about third-party AI models and open-source components?
Supply chain security for AI is complex. You're inheriting risks from training data, model architectures, and third-party APIs.
Require an AI Software Bill of Materials (AI SBOM) from vendors. This should document:
- Training data sources and any biases
- Model architecture and open-source libraries used
- Update frequency and communication of model changes
- Dependencies on external APIs or data feeds
For internally built models using open-source components, maintain your own AI SBOM. Track libraries, monitor for vulnerabilities, and evaluate model updates before deployment.
Ask vendors about model versioning and rollback procedures. If a model update introduces unexpected behavior, you need the ability to revert to the last known-good version.
Participants highlighted concerns about model changes over time. Monitor for model drift and set thresholds that trigger human review.
Q5: How transparent do we need to be about Automated Individual Decision-Making and Profiling?
Transparency is about trust and auditability. When your AI system denies access or flags a transaction, you need to explain why to regulators, auditors, and affected parties.
Document three layers:
- Data provenance: Where did the training data come from? What preprocessing was applied?
- Model behavior: What features does the model weigh most heavily? What's the expected error rate?
- Decision-making process: How does model output translate to action? Who reviews outputs? What override mechanisms exist?
This documentation supports internal governance and external compliance. If you're subject to the General Data Protection Regulation, you'll need to explain automated decision-making to data subjects.
Transparency also means being honest about limitations. If your AI can't explain its reasoning in certain scenarios, document that gap and implement compensating controls like requiring human review.
Q6: What controls differ for AI versus traditional systems?
Some controls extend from existing cybersecurity practices; others need AI-specific adaptations.
Traditional controls that apply:
- Network segmentation for AI infrastructure
- Role-Based Access Control for model repositories
- Encryption for data in transit and at rest
- Vulnerability scanning for underlying systems
AI-specific controls emphasized:
- Cryptographic signing for models to ensure integrity
- Securing feedback loops to prevent error amplification
- Adaptive identity management for non-human identities
- Incident response procedures that distinguish attacks on AI models from traditional infrastructure attacks
You'll also need governance controls around model lifecycle management: who approves deployments, how often models are retrained, and how you manage models across environments.
Where to Go From Here
NIST is running virtual working sessions focused on securing AI components, conducting AI-enabled cyber defense, and thwarting AI-enabled attacks. These sessions will inform the preliminary draft of the Cyber AI Profile.
Join NIST's Community of Interest at [email protected] to participate in discussions and access the workshop summary when it's published.
In the meantime, start with your existing risk register. Add a column for AI-specific considerations and review your current controls with your cross-functional team. You'll identify gaps faster by testing your framework against real AI use cases than by waiting for perfect guidance.
