The Pentagon's 180-day deadline to remove Anthropic technology exposes a fundamental gap: most organizations cannot precisely answer, "where do we use AI?" Only 31% of organizations report being fully equipped to secure agentic AI systems, leaving the majority unprepared for such directives.
You need an inventory system that functions effectively before the next ban occurs. This template provides a structured approach to mapping AI components across your environment, whether you're responding to a compliance mandate or establishing proactive governance.
Purpose of the Template
This AI Component Inventory Template helps you identify, classify, and track AI dependencies across your systems. Unlike traditional software bill of materials (SBOM) approaches, this template addresses the specific challenges of AI components:
- Embedded AI services that may be invisible in standard dependency scans
- Third-party integrations where AI capabilities are features, not products
- Shadow AI deployed by development teams without central approval
- Transitive dependencies where your vendors use AI without disclosure
Use this template when:
- You receive a directive to remove or audit a specific AI vendor
- You're implementing AI governance policies
- You need to respond to "do we use X?" questions from leadership or regulators
- You're assessing supply chain risk for contracts or compliance frameworks
Prerequisites
Before you start:
Access requirements:
- API gateway logs or network traffic data (minimum 30 days)
- Cloud provider billing and service usage reports
- Source code repository access
- Vendor contract database or procurement records
Team involvement: You need representatives from:
- Application development teams
- Infrastructure/cloud operations
- Procurement or vendor management
- InfoSec/GRC
Time commitment:
- Initial inventory: 40-60 hours across the team
- Weekly maintenance: 2-4 hours
Tools you'll need:
- Spreadsheet software or asset management system
- Code search capability (grep, GitHub search, or similar)
- Network traffic analysis tools (if available)
The Template
Copy this structure into your asset management system or spreadsheet:
AI COMPONENT INVENTORY
Component Identification:
- Component Name: [Specific AI service or model name]
- Provider/Vendor: [Company name]
- Component Type: [API Service | Embedded Model | SaaS Feature | Open Source]
- Discovery Method: [How you found it: code scan, billing, vendor disclosure, etc.]
- Discovery Date: [YYYY-MM-DD]
Integration Details:
- System/Application: [Where it's used]
- Business Owner: [Team or individual]
- Technical Owner: [Engineer or team responsible]
- Integration Method: [Direct API | SDK | Third-party wrapper | Embedded in vendor product]
- API Endpoints: [Specific URLs or service names]
- Authentication Method: [API key | OAuth | Service account]
Usage Classification:
- Criticality: [Critical | High | Medium | Low]
- Data Sensitivity: [What data types flow through this component]
- User-Facing: [Yes | No]
- Automated Decision-Making: [Yes | No | Partial]
- Production Status: [Production | Staging | Development | Deprecated]
Risk Assessment:
- Contractual Terms: [Direct contract | Subprocessor | Unknown]
- Data Residency: [Known location | Unknown | Multi-region]
- Compliance Scope: [Which frameworks apply: PCI DSS, SOC 2, HIPAA, etc.]
- Removal Complexity: [Easy | Moderate | Difficult | Critical dependency]
- Removal Impact: [Description of what breaks if removed]
- Alternative Available: [Yes/No and name if yes]
Governance:
- Approval Status: [Approved | Shadow IT | Legacy]
- Review Date: [Last assessment]
- Next Review: [Scheduled date]
- Monitoring: [How you track usage/changes]
- Incident Response Contact: [Who to notify if this component fails or is banned]
Example entry:
Component Identification:
- Component Name: Claude 2.1 API
- Provider/Vendor: Anthropic
- Component Type: API Service
- Discovery Method: Code scan + AWS billing analysis
- Discovery Date: 2025-01-15
Integration Details:
- System/Application: Customer support ticket analysis system
- Business Owner: Customer Success VP
- Technical Owner: Support Engineering team
- Integration Method: Direct API via AWS Bedrock
- API Endpoints: bedrock-runtime.us-east-1.amazonaws.com (Claude model)
- Authentication Method: AWS IAM role
Usage Classification:
- Criticality: High
- Data Sensitivity: Customer support tickets (PII, product usage data)
- User-Facing: No (internal tool)
- Automated Decision-Making: Partial (suggests responses, human reviews)
- Production Status: Production
Risk Assessment:
- Contractual Terms: Subprocessor (through AWS)
- Data Residency: US East (Virginia)
- Compliance Scope: [SOC 2](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) Type II, GDPR (customer data processing)
- Removal Complexity: Moderate
- Removal Impact: Support team loses ticket categorization and response suggestions; manual workload increases 30%
- Alternative Available: Yes - OpenAI GPT-4 or internal fine-tuned model
Governance:
- Approval Status: Approved (Q3 2024 architecture review)
- Review Date: 2024-12-10
- Next Review: 2025-06-10
- Monitoring: AWS CloudWatch metrics + weekly cost review
- Incident Response Contact: [email protected]
Customizing the Template
For your organization size:
If you're under 500 employees, combine the Business Owner and Technical Owner fields into a single "Owner" field. You likely don't need the separation.
If you're over 2,000 employees, add a "Business Unit" or "Division" field to enable filtering by organizational structure.
For your compliance requirements:
Add framework-specific fields based on your obligations. For PCI DSS v4.0.1 scope, add a "Cardholder Data Exposure" field. For HIPAA, add "PHI Processing" classification. For government contractors, add "ITAR/EAR Classification" and "FedRAMP Authorization Status."
For your technical environment:
If you use infrastructure-as-code, add a "IaC Repository" field linking to Terraform/CloudFormation definitions.
If you have a service mesh, add "Service Mesh Endpoint" to track traffic routing.
If you use feature flags, add "Feature Flag Status" to track whether AI features can be disabled without code changes.
For different AI component types:
For open-source models you host: Add "Model Version," "Training Data Provenance," and "Hosting Infrastructure" fields.
For AI embedded in SaaS products: Add "Vendor AI Disclosure Level" (Full | Partial | None) and "Opt-out Available" (Yes | No).
For custom-trained models: Add "Training Data Sources," "Model Registry Location," and "Retraining Schedule."
Validation Steps
Week 1: Discovery validation
Run these checks to confirm your inventory is complete:
Billing validation: Cross-reference your inventory against cloud provider bills. Search for AI/ML service line items. Any charges without corresponding inventory entries indicate gaps.
Code scan validation: Search your repositories for common AI service patterns:
openai.oranthropic.in Python@anthropic-ai/oropenaiin JavaScript package.jsonaws-sdkcalls tobedrock-runtimeorsagemaker-runtime- API keys or endpoints in environment variables
Network traffic validation: If you have the capability, analyze egress traffic for AI service domains. Common patterns:
*.anthropic.comapi.openai.com*.cohere.aibedrock-runtime.*.amazonaws.com
Week 2: Classification validation
Criticality verification: For each component marked "Critical," document the specific failure scenario. If you can't articulate what breaks and when, downgrade it.
Data flow mapping: For components processing sensitive data, trace the data path. Verify that your "Data Sensitivity" classification matches what actually flows through the component. Check logs, not documentation.
Removal complexity testing: For 2-3 low-criticality components, perform a test removal in a non-production environment. Your estimates should match reality within 50%. If they don't, recalibrate your assessments.
Ongoing: Maintenance validation
Monthly reconciliation: Compare your inventory to the previous month. You should see changes. If nothing changed for 60+ days, your discovery methods aren't working.
Quarterly deep scan: Re-run your code and billing scans. New components appear through normal development. Expect 10-15% inventory growth per quarter in active development environments.
Vendor disclosure verification: When vendors update terms or publish AI usage disclosures, cross-check against your inventory. Add newly disclosed components immediately.
Red flags that indicate inventory gaps:
- Zero "Shadow IT" or "Unknown" approval statuses (every organization has some)
- All components marked "Easy" removal complexity
- No components discovered through billing analysis
- Identical "Next Review" dates for all entries
When leadership asks "do we use Anthropic?" or when the next AI vendor ban drops, you'll have an answer in minutes, not months. The 180-day clock starts when the directive arrives, not when you start building your inventory.
