In the second week of June 2026 the conversation about software supply-chain security took a sharp turn. Two enterprise breaches disclosed in five days had the same root cause: an unsanctioned AI agent connected to a production data store, deployed by a single team, invisible to the security function. In both cases the SBOM was clean. The vulnerability was not a library — it was a model and an agent the SBOM did not even know existed.
Industry analysts and a fast-moving cluster of vendors responded with the same answer: enterprises need an **AI-BOM**. Where a Software Bill of Materials inventories the libraries and dependencies in a codebase, an AI Bill of Materials inventories the AI components in an organisation — the models, the datasets they were trained or fine-tuned on, the agents and tools they expose, and the prompts and policies that govern their behaviour. By the end of 2026 most large enterprises will be running AI-BOM tooling. By the end of 2027 the EU AI Act second wave will make a documented AI inventory mandatory for any system classified as high-risk.
SMBs are tempted to file this in the "we'll get to it next year" bucket. That is exactly the mistake the breached enterprises made. Shadow AI inside a 60-person company is, in our incident-response experience, denser than inside a 6,000-person company. There are fewer governance layers, fewer audit tools and a higher per-employee experimentation rate. The exposure per dollar of revenue is higher, not lower.
This guide is the playbook we use at [Call IT Dev](https://callitdev.com) when an SMB asks us for a first AI-BOM. It defines what an AI-BOM actually contains, why shadow AI is the real driver of urgency, the practical first-inventory exercise you can run this month, and the threshold at which it makes sense to bring in external AppSec.
Strip the marketing and an AI-BOM has five mandatory sections.
**1. Models.** Every model in use, whether self-hosted, hosted by a vendor, or accessed via API. For each model: name, version, provider, deployment mode (SaaS, dedicated instance, on-prem), the inference endpoint, the data residency of that endpoint, and the terms of service governing input and output rights.
**2. Datasets.** Every dataset used to train, fine-tune or evaluate a model in scope, AND every dataset routinely sent as runtime context (RAG corpora, embedding stores, agent memory). For each dataset: source, license, sensitivity classification (public, internal, confidential, regulated), and the retention policy.
**3. Agents and tools.** Every autonomous or semi-autonomous agent in production, with its goal definition, its tool list (what it can call), its escalation policy, and the human owner accountable for its behaviour. This is the section most enterprises do not have.
**4. Prompts and policies.** The system prompts, tool descriptions and policy documents that shape agent behaviour. Treated as source code — versioned, reviewed, signed. Without this section the AI-BOM is a snapshot with no auditability over time.
**5. Interconnections.** A graph view: which agents call which tools, which tools touch which datasets, which models back which agents. This is the section that makes the AI-BOM useful for incident response. When the next breach hits, the question "what does this compromised agent have access to?" becomes answerable in minutes instead of weeks.
A well-built AI-BOM lives next to the SBOM in the same software supply-chain platform, is regenerated on every release, and is queryable by both engineering and security functions.
Most SMBs assume their AI exposure equals the AI features they consciously bought. In our incident-response engagements, the AI surface area is between 4x and 11x the size leadership thinks it is. The delta is shadow AI — AI tools used by employees, contractors or even product teams without security review.
Three shadow-AI patterns dominate in 2026.
**Pattern 1 — Personal-tier coding assistants on production codebases.** A contractor connects a free or personal-tier coding assistant to your repo. Your code is sent to a public endpoint, may be retained, may be used in training depending on the tool's ToS. The contractor sees a productivity uplift; you see nothing until a snippet of your auth code appears in a public model output six months later.
**Pattern 2 — Personal browser agents on the company tenant.** An employee installs a browser-based agent that reads their Gmail, calendar and Slack to "automate" workflows. The agent now has scoped access to confidential conversations and customer data, governed by the personal account, not the enterprise tenant. SSO and DLP do not see it.
**Pattern 3 — Product teams shipping LLM features on personal API keys.** A product engineer wires GPT-X into a customer-facing feature using a personal API key during prototyping. The prototype goes to production. The API key is not in the secrets vault, the prompts are not in git, and the inference endpoint is in a region your DPO would not approve. The first time legal hears about it is the customer complaint.
In every one of these patterns, the SBOM is clean. The AI-BOM, if it existed, would surface the gap on the first scan.
We run a six-day exercise to ship a first AI-BOM for a company under 250 employees. It is hands-on, deliberately low-tech, and produces a usable inventory and a remediation backlog.
**Day 1 — Charter and scope.** Two-hour kickoff with security lead, engineering lead, legal and the executive sponsor. Agree the scope (typically: all production systems plus all employee productivity tools), the inventory template (the five sections above), and the disclosure protocol for findings.
**Day 2 — Engineering survey.** A 12-question form sent to every engineer asking which AI tools they use, against which codebases, with which accounts, and at which inference endpoint. Phrased as a no-blame audit. Response rate runs 70–85% if leadership signals psychological safety; below that, the answers are useless.
**Day 3 — Network and identity telemetry.** Pull 30 days of DNS, proxy and SSO logs. Filter on known AI-tool domains (we maintain a list of 240+). Cross-reference with employee identities. The list of AI tools in use will not match the engineering survey — the delta is shadow AI.
**Day 4 — Product surface review.** Walk through every production service with the team lead. For each, document: does it call an LLM? An agent? A vector store? On which key, against which endpoint, with what input data? This is where the personal-API-key prototypes surface.
**Day 5 — Draft AI-BOM and risk triage.** Consolidate findings into the five-section AI-BOM. Tag each entry with sensitivity (data type touched) and likelihood (frequency, contractor or employee, sanctioned or shadow). Sort. Identify the top 5 immediate-action items — typically: a shadow tool to be killed, a personal API key to be rotated, a prompt repository to be created, a data-egress policy to be enforced.
**Day 6 — Executive readout and remediation backlog.** One-hour readout to the executive sponsor, with the AI-BOM, the top-5 actions, the 30-60-90 day remediation backlog, and the ownership map. Hand the inventory to engineering and security as a living document with a quarterly refresh cadence.
The exercise costs roughly 80 internal hours and 20–40 hours of external help if you bring in an AppSec specialist. It is the highest-ROI security work an SMB can do in 2026.
The AI-BOM is not a replacement for any existing control — it is a missing layer that makes the other controls work as intended.
Treated as a missing layer rather than a new product category, the AI-BOM clarifies the work the rest of the stack should already have been doing.
For an SMB the right threshold to engage external AppSec for the AI-BOM work is one of three triggers.
**Trigger 1 — You have shipped an LLM feature to customers.** Once you have a production LLM endpoint behind a customer experience, the threat surface includes prompt injection, output exfiltration, jailbreak risk and supply-chain poisoning. These need specialist review that most generalist security functions cannot deliver.
**Trigger 2 — You hold regulated data.** Healthcare PHI, financial data, EU personal data under GDPR. The regulatory framework for AI handling of regulated data is moving fast and the cost of misclassification is asymmetric.
**Trigger 3 — A contractor or third party uses AI on your codebase or data.** Your control over their tool stack ends at the contract. An AppSec function that audits the contractor's AI usage on your behalf closes the gap.
Below those triggers, the first AI-BOM exercise can be run with internal hands and a published playbook. Above them, external specialists pay for themselves in the first quarter.
We run the inventory exercise, the AI-BOM tooling and the ongoing audit cadence as part of our [cybersecurity service](https://callitdev.com/en/services/software-development/cybersecurity). When the AI-BOM surfaces a need for AI engineering — restructuring agents, hardening prompts, replacing a shadow tool with a sanctioned one — that work flows into our [AI automation engineering team](https://callitdev.com/en/services/software-development/ai-automation). And when shadow AI is being introduced through a stressed helpdesk function — employees using consumer tools to handle tickets faster — we replace the pressure with a properly staffed [helpdesk and IT support service](https://callitdev.com/en/services/bpo/helpdesk-it-support) that removes the incentive to reach for the shadow tool.
If you are responsible for security or engineering in an SMB and you have not yet built an AI-BOM, do these three things this quarter.
**One — Run a one-week shadow-AI discovery.** Engineering survey, DNS log review, product surface walkthrough. The output is not the AI-BOM yet; it is the realisation that your AI surface is bigger than you thought. That realisation is the budget unlock.
**Two — Stand up the inventory template.** The five sections — models, datasets, agents, prompts, interconnections — owned by named engineering and security leads, refreshed quarterly. Even a half-complete inventory is dramatically better than none.
**Three — Pick the top three remediation items and ship them in 30 days.** Typically: kill one shadow tool, rotate one personal API key, version one prompt repository. If the remediation surfaces a need to rebuild an agent or harden a customer-facing LLM feature, our [software development team](https://callitdev.com/en/services/software-development) ships it under the same DevSecOps gates described above. The point is to demonstrate that the inventory drives action, not that it sits as a compliance artifact.
We are happy to be one of the partners you talk to. WhatsApp us at [+212 537 373 777](https://wa.me/212537373777) or [book a free 15-minute scoping call](https://callitdev.com/en/contact) and we will share our AI-BOM template, the shadow-AI discovery checklist and an honest read on whether you need outside help yet.
**Is an AI-BOM legally required today?** Not yet in most jurisdictions. The EU AI Act second wave makes it mandatory for high-risk systems from 2027. Enterprise procurement is already requiring it from suppliers in 2026. Building one this year puts you ahead of both clocks.
**How is an AI-BOM different from a model card?** A model card describes one model. An AI-BOM inventories every model, dataset, agent and prompt in your environment, plus the connections between them. The model card is an input to the AI-BOM, not a substitute.
**Who should own the AI-BOM internally?** Joint ownership: engineering owns accuracy, security owns risk triage, legal owns licence and regulatory mapping. A single owner fails; the inventory either drifts from reality (security-only) or misses the risk lens (engineering-only).
**What tools do you recommend?** For an SMB first inventory, a spreadsheet or Notion table is sufficient. At 50+ entries you outgrow it. Several SBOM platforms now ship AI-BOM modules; we recommend evaluating two and committing once your AI surface justifies the seat cost.
**How often should we refresh the AI-BOM?** Quarterly at minimum, with a lightweight monthly delta review. Major changes — new model in production, new agent shipped, new contractor onboarded — trigger an out-of-cycle update.
Not yet in most jurisdictions. The EU AI Act second wave makes it mandatory for high-risk systems from 2027. Enterprise procurement is already requiring it from suppliers in 2026. Building one this year puts you ahead of both clocks.
A model card describes one model. An AI-BOM inventories every model, dataset, agent and prompt in your environment plus the connections between them. The model card is an input to the AI-BOM, not a substitute.
Joint ownership: engineering owns accuracy, security owns risk triage, legal owns licence and regulatory mapping. A single owner fails — the inventory either drifts from reality (security-only) or misses the risk lens (engineering-only).
For an SMB first inventory, a spreadsheet or Notion table is sufficient. Past 50+ entries you outgrow it. Several SBOM platforms now ship AI-BOM modules; evaluate two and commit once your AI surface justifies the seat cost.
Quarterly at minimum, with a lightweight monthly delta review. Major changes — new model in production, new agent shipped, new contractor onboarded — trigger an out-of-cycle update.
CALL IT DEV — Software, AI and dedicated tech teams — Casablanca | Madrid | Dubai — contact@callitdev.com — +212-537-373777