This is Part 2 of a four-part series on implementing practical AI governance using the NIST AI Risk Management Framework. In Part 1, we established governance structures that enable rather than block innovation. Now we tackle visibility: the hidden AI proliferating across your technology stack without oversight. The MAP function helps organizations discover, categorize, and assess AI applications before they become compliance nightmares or security risks.
The real AI governance crisis isn't the models you've formally approved, rather the ones you don't know exist. The staff member with ChatGPT access and the ability to paste in data or install a browser extension, or the vendor deploying AI-driven functionality in a product to which you already subscribe… and vetted before you did.
I've watched teams discover they're running 3-5x more AI applications than they realized, a number that's EASILY dwarfed (especially) in smaller companies. Recent IBM research confirms this visibility crisis, showing that organizations consistently underestimate their AI footprint by significant margins when conducting systematic inventories.[1] Marketing automation with sentiment analysis, customer service platforms with chatbots, financial planning tools with predictive analytics, HR systems with resume screening, and procurement software with spend analytics. Likely none went through formal AI governance review because they weren't purchased as "AI solutions."
Consider these examples:
Manufacturing company discovered their ERP system was using AI for demand forecasting when a vendor update changed prediction accuracy
Healthcare organization found their scheduling software included AI-powered patient flow optimization that was processing PHI without documentation
Financial services firm learned their expense management platform had been using AI/ML for fraud detection, creating regulatory or reporting gaps they hadn't anticipated
This visibility gap creates immediate problems: compliance exposure when auditors ask about AI usage, security risks from unknown data processing, and budget bleeding from redundant capabilities across departments.
Why Traditional Asset Management Fails
Traditional IT asset management catastrophically fails for AI because vendors don't clearly disclose AI features. What gets sold as "enhanced analytics," "intelligent automation," or "smart insights" often includes machine learning models processing your data in ways that weren't part of the original contract review.
Shadow AI adoption compounds the problem, now more than ever. Teams solve immediate problems with AI tools without waiting for formal approval processes. Marketing subscribes to AI writing platforms, sales deploys conversation intelligence software, finance adopts AI-powered forecasting tools, and ops teams use applications that likely touch customer data. Each solves genuine business problems, but there’s a high likelihood that nobody tracks cumulative risk exposure.
The challenge isn't just technical discovery, either, as it's one of organizational awareness. It’s often a complete surprise when vendors release and/or enable AI features by default in routine software updates. I know of one organization that discovered their document management system had quietly added AI-powered content classification that was automatically tagging sensitive files without user awareness.
This reflects what Berkeley CLTC research shows about the gap between AI principles and practice: organizations struggle with translational challenges between what they want to achieve and how to implement systematic governance processes.[3]
NIST MAP Function: From Discovery to Strategic Visibility
The NIST AI RMF Playbook provides specific guidance for comprehensive AI system inventory through its MAP function. Unlike ad hoc discovery efforts, NIST's approach creates systematic visibility into AI context, characteristics, and impacts across the organization.
The MAP function addresses three critical areas identified in the Playbook:
documenting AI system context (business purpose, stakeholders, and ops environment),
cataloging AI system characteristics (technical specifications, data requirements, and performance parameters), and
assessing AI system impacts (intended benefits, potential harms, and affected stakeholders).
This isn't just technology inventory anymore, it’s verging on a full-on business impact assessment which should also be pretty familiar to risk management pros. The Playbook emphasizes understanding how AI systems affect business processes, customer interactions, and organizational decision-making. Without this context, you're managing technology rather than governing business risk.
Key MAP activities include AI system identification across all organizational functions, stakeholder mapping for each AI application, data flow documentation for AI processing activities, and impact assessment for business and operational effects. The framework specifically calls for ongoing monitoring rather than one-time discovery because AI capabilities change frequently through vendor updates and feature additions.
Systematic AI Discovery
Following NIST guidance, begin with an organizational scope definition before diving into technical discovery, reminiscent of other top-down governance I’ve written about here. The Playbook recommends identifying all business functions, departments, and processes that might use AI to prevent discovery gaps where teams assume other departments are handling AI inventory.
Phase 1: Organizational AI Context Mapping
Survey all departments about their current technology usage, focusing on tools that provide recommendations, predictions, automation, or classification. Don't ask specifically about "AI" because teams often don't recognize AI features in business applications.
The Playbook recommends specific questions: What tools does your department use for decision support? Which applications provide automated recommendations? What software helps predict outcomes or classify information? Which platforms analyze patterns in your data?
Phase 2: AI System Characteristics Documentation
For each identified AI application, document technical characteristics following NIST categories. This includes AI system type (machine learning, rule-based, hybrid), data sources and types, model transparency/explainability, integration points with other systems, and vendor responsibility for maintenance and updates. You may want to go deeper on this, but hold on that until your inventory is complete.
Instead, focus on characteristics that affect business risk rather than technical details vendors can't provide: where data gets processed, how decisions get made, what happens when the AI produces incorrect results, and who can modify AI behavior.
I just recently attended a webinar for a GPT-like feature that integrates into online classrooms (a sort of “AI coach” trained on the material), which failed to answer any of these questions. I don’t think that one would get past the first sales call.
Phase 3: Impact Assessment and Risk Classification
Apply NIST's impact assessment framework to categorize AI systems by their effects on individuals, organizations, and society. It's not as onerous as it sounds. This classification approach shares similarities with the EU AI Act's risk-based categorization, though NIST focuses on impact assessment while EU regulations emphasize prohibited practices and compliance requirements.
High-Impact AI: Systems affecting customer outcomes, financial decisions, regulatory compliance, or employee treatment. These applications parallel EU "high-risk" categories and require comprehensive governance oversight.
Medium-Impact AI: Internal productivity tools and operational efficiency applications that don't directly affect external stakeholders but could impact business operations or employee workflows.
Low-Impact AI: Basic analytics and reporting features with minimal potential for individual or organizational harm, similar to EU "limited risk" or "minimal risk" classifications.
But here’s an important reality check that changes your approach ever-so-slightly: most enterprise AI applications don't fit neatly into single categories. A customer service chatbot might be low-impact for routine FAQ responses but high-impact when it escalates sensitive customer complaints or processes payment information. The same HR screening tool could be medium-impact for initial resume filtering but high-impact when it influences final hiring decisions. And let’s not talk about uses inside of Salesforce, Hubspot, Atlassian… that can get pretty tangled in a hurry.
The key is documenting these contextual variations during your inventory. Note when the same AI system operates at different impact levels depending on use case, data sensitivity, or decision authority. This nuanced documentation becomes critical when establishing governance oversight and measurement frameworks.
Don't get trapped trying to assign perfect classifications, either. Focus on identifying the highest potential impact level for each system and govern accordingly. You can always adjust classifications as you gain operational experience, but you can't recover from governance gaps that let high-impact AI operate without appropriate oversight. When in doubt, I separate the inventory items by department or line of business so I can circle back. MIT Sloan's research on AI risk assessment frameworks demonstrates that organizations using systematic classification approaches like this achieve better governance outcomes than those attempting perfect categorization.[4]
The Playbook specifically warns against underestimating AI impacts. Systems that seem low-risk in isolation often create cumulative effects when combined with other AI applications or organizational processes. This consideration becomes increasingly important as global AI regulations mature. (See my note about EU AI Act above!)
Addressing Feature Creep
One challenge the Berkeley CLTC research highlights is how organizations struggle with vendor transparency and disclosure norms. Most vendors now embed AI capabilities without clear documentation, creating what researchers call "AI decision points" where organizations must navigate unprecedented choices about technology governance.
Effective AI mapping requires vendor management integration, not parallel discovery processes. Adapt existing vendor assessment frameworks to include AI-specific questions rather than creating separate AI vendor processes.
Essential vendor questions include:
What AI capabilities does your platform provide today?
What AI features are planned for future releases?
Where is AI processing performed (cloud regions, data centers, third-party services)?
How do you disclose AI feature additions to customers?
What control do we have over AI feature activation?
Contractual requirements should mandate AI feature disclosure and change notification, full stop. Many vendors enable AI features in standard updates without explicit customer consent, but your contracts should require advance notification of AI capability additions and opt-in rather than opt-out policies for AI features that process sensitive data.
Learning from Governance Implementation Examples
The Berkeley CLTC study examines how organizations like Microsoft have approached similar challenges through their AETHER Committee structure. Their experience demonstrates that successful AI governance requires both systematic discovery and ongoing monitoring processes that scale with organizational AI adoption.
Microsoft's approach of organizing governance around specific working groups (Sensitive Uses, Bias and Fairness, Reliability and Safety) provides a model for categorizing discovered AI applications. Their experience shows that overclassification creates administrative burden, while underclassification misses critical risks. Research from Frontiers in Computer Science on corporate AI governance best practices confirms that structured working group approaches significantly improve governance effectiveness across industries.[5]
Similarly, OpenAI's staged release approach illustrates how orgs can balance openness with risk management, though that balance is becoming a bit questionable now. Their original model cards and documentation schemes provided templates for the kind of systematic documentation NIST recommends for AI system characteristics.
Building Sustainable Visibility
One-time discovery exercises fail because AI deployment accelerates after initial governance implementation. This is not a surprise to governance folks, and it only makes sense given all of the above. Sustainable AI visibility, though, requires ongoing monitoring processes that scale with organizational AI adoption.
Automated discovery helps but doesn't solve everything, just like every GRC solution ever. Cloud security tools can identify new AI workloads, API monitoring can track AI service usage, and data flow analysis can detect AI processing activities. However, business context still (at this juncture) requires human assessment.
Regular review cycles maintain visibility as AI capabilities evolve. Quarterly vendor reviews should include AI feature updates, department surveys should track new AI tool adoption, and procurement processes should automatically flag AI-related purchases or subscriptions. I know… this one can be hard, but if you have a finance team willing/able to work with you on at least some policies around subscription purchasess that’s a huge advantage.
As with all things, the goal isn't perfect visibility. No such thing. It's actionable visibility that enables informed governance decisions. Focus discovery efforts on AI applications that create business risk rather than achieving comprehensive technical documentation that will be outdated before you can press Save.
Strategic Portfolio Management
Effective AI mapping enables strategic decision-making about technology investments and risk management. When teams understand existing AI capabilities and risks, they make better decisions about new AI initiatives and avoid redundant technology investment.
Visibility also improves vendor negotiations, and orgs with comprehensive AI inventories can consolidate similar capabilities, negotiate better terms for AI features, and make informed decisions about vendor dependencies. If you haven't done this exercise, I guarantee you have at least a few competing tools with near-identical functionality in your org.
Where most orgs hit a wall is at the point they complete their AI inventory and then... what? The inventory wasn’t the point of this. Having a comprehensive list of AI applications doesn't automatically translate to business value. There are teams spending months cataloging every AI feature only to struggle with basic questions like "Is our fraud detection AI actually reducing losses?" or “What measurable ROI are we getting from that marketing automation platform?"
This is where AI mapping transitions from discovery to performance management. The inventory you take becomes the foundation for meaningful measurement, but only if you've documented the right characteristics, and the business impact data you capture during mapping directly determines what you can measure later.
I.e., if you document that your customer service chatbot "handles routine inquiries," you can't measure customer satisfaction impact. But if you document "resolves 60% of P1 support tickets with average resolution time of 3 minutes," you've created measurable baselines for performance tracking.
In other words, the most critical bridge between mapping and measurement is establishing exactly that kind of clear performance expectations for each AI application before you close out your inventory process. What business problem is this AI supposed to solve? What would success look like? What would failure look like? These questions transform your AI inventory from a compliance exercise into a strategic management tool.
Perhaps most importantly, AI mapping reveals measurement gaps that most organizations don't realize they have. You can't measure what you don't know exists, and you can't improve what you don't measure effectively. That’s something that the profileration of AI hasn’t really changed. (Yet.)
Connect with me to discuss your organization's AI discovery challenges and mapping strategies.
This series continues next week with Part 3: Measuring.
Read the NIST AI RMF Implementation Series:
Part 1: Governing
Part 2: Mapping
Part 3: Measuring
Part 4: Managing
References
[1] IBM Institute for Business Value. "CEO Study 2025: AI Leadership." IBM Newsroom, May 6, 2025. https://newsroom.ibm.com/2025-05-06-ibm-study-ceos-double-down-on-ai-while-navigating-enterprise-hurdles
[2] National Institute of Standards and Technology. "AI Risk Management Framework (AI RMF 1.0)" and "AI RMF Playbook." NIST, January 2023, updated July 2024. https://www.nist.gov/itl/ai-risk-management-framework
[3] Jessica Cussins Newman. "Decision Points in AI Governance: Three Case Studies Explore Efforts to Operationalize AI Principles." UC Berkeley Center for Long-Term Cybersecurity, 2024. https://cltc.berkeley.edu/ai-decision-points/
[4] MIT Sloan Management Review. "A Framework for Assessing AI Risk." Massachusetts Institute of Technology, 2024. https://mitsloan.mit.edu/ideas-made-to-matter/a-framework-assessing-ai-risk
[5] Frontiers in Computer Science. "Challenges and best practices in corporate AI governance: Lessons from the biopharmaceutical industry." 2024. https://www.frontiersin.org/journals/computer-science/articles/10.3389/fcomp.2022.1068361/full
CREDITS: base cover image from airc.nist.gov; Anthropic Claude Sonnet 4 for editorial review