The inventory assumption

The NIST AI RMF, the EU AI Act, CIRCIA, and the CISA/Five Eyes agentic AI guidance all share one foundational assumption: that the operator maintains a complete, accurate inventory of AI systems as their starting condition. The MAP function cannot map what the operator has not catalogued. The conformity assessment cannot assess systems the operator does not know it is deploying. The accountability opacity risk cannot be addressed for agents the operator cannot see.

Issues Paper No. 1 asked three sovereignty questions. Issues Paper No. 2 asked three governance readiness questions. Issues Paper No. 3 asked three compliance architecture questions. All nine questions assume the operator can point to a specific AI system and answer. Shadow AI means there are AI systems on the network - influencing operational decisions, processing regulated data, generating compliance exposure - that the operator cannot point to because it does not know they are there.

This is not a peripheral risk. It is a foundational failure that undermines every governance and compliance structure built on top of it.

The scale of the problem

IBM's 2025 Cost of a Data Breach Report found that shadow AI was a factor in one in five breaches studied, adding USD 670,000 to average breach costs. Ninety-seven per cent of organisations experiencing AI-related breaches lacked proper AI access controls. Netskope's Cloud and Threat Report 2026 found that organisations now record an average of 223 GenAI-linked data policy violations per month, with top-quartile organisations recording 2,100 per month.

IDC's 2025 survey reported that 56 per cent of employees use unauthorised AI tools at work, while only 23 per cent use AI tools their organisation provides and governs. Netskope found that 72 per cent of enterprise generative AI usage occurred through personal accounts, outside organisational visibility and control.

Shadow AI in critical infrastructure

In telecom, the exposure is structurally worse. Telecom engineers routinely handle surveillance-grade data: call detail records, location telemetry, CPNI-protected billing information, and live network topology.

The field engineer

A site engineer on a rooftop takes photos of equipment panels and uploads them to a public LLM. Forty seconds, three answers, problem diagnosed. But those photos carry equipment serial numbers, IP addresses, VLAN configurations, rack layouts revealing physical network topology, firmware versions mapping to known vulnerability databases, and EXIF metadata with GPS coordinates of the cell site.

The NOC engineer

A NOC engineer managing a complex alarm storm at 2am opens a personal account on a commercial LLM and pastes alarm logs. The enterprise-approved tool sits behind an SSO portal that does not integrate with NOC terminals, configured so conservatively it refuses to process network topology data. CDR fragments, cell tower identifiers, and subscriber identifiers survive the engineer's hasty redaction.

Ungoverned decision influence

Data leakage is the obvious risk. The deeper risk is ungoverned decision influence. When an engineer uses an unvetted model to interpret an alarm pattern or reconfigure equipment, the AI has influenced an operational decision on critical infrastructure - completely outside every governance framework the operator has built. No audit trail. No accountability chain. No conformity assessment.

The decision influence spectrum

Decision influence operates on a spectrum from general information retrieval to autonomous execution:

Level
Description
Governance requirement
Information retrieval
General technical queries with no operator-specific data
Minimal - standard usage logging
Interpretation assistance
Model helps interpret operational data; engineer applies independent judgment
Moderate - data classification, approved tool requirement
Recommendation
Model provides specific operational recommendations
High - decision logging, human verification
Configuration generation
Model generates executable configurations, scripts, or commands
Critical - mandatory review, testing, approval chain
Autonomous execution
Agent executes actions without per-action human approval
Maximum - full conformity assessment, continuous monitoring

Shadow agentic AI

Beyond conversational generative AI, shadow agentic AI introduces qualitatively different risks. Agentic systems make decisions without per-action human intervention. Multi-agent systems create coordination opacity - when multiple agents interact, no single agent has visibility over the emergent behaviour of the system. And agentic systems exhibit goal drift: an agent optimising for network uptime may take actions that conflict with data minimisation or regulatory compliance.

The regulatory exposure

Shadow AI creates simultaneous exposure across multiple mandatory regimes:

  • CPNI (Section 222) - FCC penalties of up to $251,322 per violation per day. In 2024, the FCC fined AT&T, Verizon, Sprint, and T-Mobile a combined approximately $196 million for CPNI violations related to geolocation data.
  • EU AI Act - Shadow AI renders the entire compliance architecture inoperative for systems most likely processing the most sensitive data under the least controlled conditions.
  • CIRCIA - If an AI system the operator did not know existed contributes to a reportable incident, the 72-hour clock starts running without the system inventory, decision log, or model metadata a compliant report requires.
  • Five Eyes agentic AI guidance - Shadow AI is accountability opacity by definition. The guidance requires cryptographically anchored agent identities and continuous monitoring - impossible for systems the operator cannot see.

Why prohibition fails

The instinctive corporate response is prohibition. The evidence indicates it does not work. Sixty-nine per cent of organisations already suspect or have evidence that employees are using prohibited public generative AI tools. Prohibition creates a compliance illusion: leadership believes the policy is being followed because they have stopped seeing the activity. They have stopped seeing it because it has moved to personal devices, personal accounts, and browser-based tools that bypass enterprise monitoring.

Shadow AI is not primarily a policy problem. It is a product problem. If the sanctioned tool is better than the shadow tool, the shadow tool dies. If it is not, no policy will save you. But even in well-provisioned environments, shadow AI persists for behavioural reasons: habit formation, switching costs, and the perceived frontier capability of the latest consumer model.

The Governed AI System Registry

This paper proposes a Governed AI System Registry - an operational mechanism that gives operators complete visibility over every AI system, tool, model, and agent operating on or interacting with their network infrastructure. It is analogous to the Configuration Management Database every telecom operator maintains for network hardware.

The registry operates across four layers:

Enterprise Layer - The Sanctioned AI Catalogue

A complete catalogue of every AI system the operator has deliberately deployed. Each entry is a living record with mandatory metadata: system identifier, model provenance, deployment context, data inputs, access permissions, decision influence level, autonomy classification, obligation mapping, human oversight status, and conformity status. Updated within 24 hours of any material change.

Vendor Layer - AI Ingredient Labels

Tracks every AI component embedded in third-party software through AI Ingredient Labels: model identifiers, training data provenance, AI supply chain composition, data processed, decisions influenced, inference location, and opt-out capability. Vendors certify annually, notify within 72 hours of material changes, and participate in the emerging AI-SBOM standard.

Operational Layer - Frictionless Governed Tools

Pre-approved AI tools that are faster, more capable, and lower friction than shadow alternatives. A tiered inference architecture resolves the tension between speed and data protection: Tier 1 (cloud) for public/internal data, Tier 2 (sovereign/on-prem) for network data, and Tier 3 (isolated on-prem with pre-inference anonymisation) for subscriber and CPNI data.

Discovery Layer - Continuous Shadow AI Discovery

Continuously monitors for unsanctioned AI usage through endpoint agents, API gateway monitoring, DLP telemetry, DNS/traffic analysis, and CASB integration. Every detection is treated as a product failure signal, not a disciplinary trigger. A six-step response protocol routes from detection through risk assessment and gap analysis to tool provisioning.

Governed AI System Registry architecture diagram showing four layers: Enterprise Layer (declared systems), Vendor Layer (AI ingredient labels), Operational Layer (frictionless governed tools), and Discovery Layer (continuous shadow AI discovery), feeding into governance outputs and compliance evidence.
Figure 1 — The Governed AI System Registry: four-layer architecture for continuous operational AI inventory and telecom AI governance.

Workforce trust and safe harbour

The Discovery Layer's monitoring infrastructure is functionally indistinguishable from surveillance infrastructure. If engineers perceive it as surveillance, they will conceal shadow AI usage rather than report it. The paper proposes explicit safe harbour provisions: engineers who voluntarily disclose shadow AI usage receive documented protection from disciplinary action. Even engineers whose usage is detected automatically receive non-punitive treatment by default. Only genuinely malicious use - intentional data exfiltration or deliberate circumvention - is routed to security operations, with clear threshold criteria, governance separation, and transparency reporting.

Implementation

The registry is implemented through four overlapping workstreams: Discovery (weeks 1-12), Classification (weeks 4-16), Operational Provisioning (weeks 8-36), and Continuous Monitoring (week 6 onward). Initial operating capability is achievable in 3-4 months. A minimum viable registry - simplified Enterprise Layer, DNS-based detection, and one approved tool addressing the highest-volume shadow use case - can be established within 60 days.

Three AI Inventory Questions

Building on the diagnostics from Paper No. 1, Paper No. 2, and Paper No. 3:

  1. Can you produce a complete AI inventory - including systems you did not deploy? - A question of visibility. The inventory must include sanctioned deployments, vendor-embedded AI, staff personal accounts, open-source models, and third-party tools. Can you articulate the calibrated confidence level of your inventory?
  2. Can you classify the regulatory obligations each system triggers and the level of decision influence it exerts? - A question of classification. An inventory without regulatory classification is a list, not a governance instrument. Can you quantify your Detection Layer's coverage gaps?
  3. When an invisible system causes an incident, can you reconstruct what happened? - A question of forensic readiness. An operator with a Governed AI System Registry has the detection data and AI artifact provenance records needed. An operator without one is reconstructing from interviews under time pressure about a tool nobody was supposed to be using.

The twelve-question diagnostic

The four ITS Issues Papers together form a twelve-question diagnostic covering the full scope of operational control over AI in telecom critical infrastructure:

The twelve-question diagnostic framework across four papers: Paper 1 Sovereignty (Q1-Q3), Paper 2 Governance (Q4-Q6), Paper 3 Compliance (Q7-Q9), Paper 4 Inventory (Q10-Q12).
Figure 2 — The twelve-question diagnostic framework across four ITS Issues Papers.
Paper 1: Sovereignty
Paper 2: Governance
Paper 3: Compliance
Paper 4: Inventory
Q1 / Q4 / Q7 / Q10
What data built this model?
Can you produce a complete decision trail?
Can you enumerate every mandatory obligation?
Can you produce a complete AI inventory - including systems you did not deploy?
Q2 / Q5 / Q8 / Q11
Where is inference running?
Does your architecture prevent unauthorised authority escalation?
Can you trace governance to the specific evidence each obligation requires?
Can you classify the obligations and decision influence level of each system?
Q3 / Q6 / Q9 / Q12
What did the model do in the last 60 seconds?
Can you explain a specific decision to a regulator?
Who owns the gaps - and what is the remediation timeline?
When an invisible system causes an incident, can you reconstruct what happened?

An operator that can answer all twelve has operational sovereignty over its AI systems. The inventory questions are listed last because they were identified last. But operationally, they come first. You cannot govern what you cannot see.

Policy recommendations

  • For NIST: The Critical Infrastructure Profile should explicitly require a continuously updated AI system inventory as a precondition for MAP function implementation. The AI RMF should incorporate decision influence level classification. NIST should develop AI Ingredient Label guidance for critical infrastructure vendors.
  • For telecom operators: Conduct an immediate baseline shadow AI assessment within 30 days. Deploy a minimum viable registry within 60 days. Engage with GSMA and TM Forum to propose the AI Ingredient Label as an industry-standard contractual clause.
  • For regulators: CIRCIA should explicitly address incidents where the contributing AI system was unknown. The EU AI Act's deployer obligations should include a positive duty to discover AI systems in use. The FCC should extend CPNI protection requirements to explicitly address AI systems processing CPNI data.
Download full paper Discuss this research

Citation: Institute for Technology Stewardship (2026). The Ghost in the Network: Shadow AI and the Inventory Crisis in Telecom Operations. Issues Paper No. 4, July 2026.
© 2026 Institute for Technology Stewardship. Licensed under CC BY-NC 4.0.