AI-ENG-AH — Build, Buy, Open Source & Vendor Strategy - Doctrinal Knowledge Base for Strategic Dependency Architecture

Conceptual Glossary of AI Sourcing Architecture

To establish a mathematically precise and legally rigorous foundation for enterprise technology acquisition, the vocabulary of artificial intelligence sourcing must be strictly standardized:

• AI Sourcing Architecture: The technical and procurement discipline of designing, deploying, and continuously auditing the mix of proprietary interfaces, self-hosted models, open-weight artifacts, and native code layers that comprise an enterprise execution plane. It establishes how an organization balances operational agility against systemic dependency risk.
• Build: The direct engineering and deployment of proprietary software components, custom orchestration layers, fine-tuned model adapters, or specialized base-model architectures on managed or owned infrastructure.
• Buy: The commercial acquisition of fully integrated, vendor-hosted applications where the software vendor defines the user interface, workflow engine, orchestration logic, and underlying model endpoints.
• Managed API: A consumption-based cloud endpoint hosted by a model provider that delivers inference outputs via standard HTTPS requests, charging fees based on token or request volume while withholding access to model weights and parameters.
• Vendor Application: A finished software-as-a-service (SaaS) product that wraps model capabilities within a specific business workflow, assuming operational control over retrieval pipelines, model routing, and output formatting.
• Open Source Software (OSS): Code distributed under licenses approved by the Open Source Initiative (OSI) that grant the unrestricted rights to use, study, modify, and share the software system.1
• Open Weight Model: An artificial intelligence model whose learned parameters and weights are made available for download, but whose commercial distribution, training modifications, and usage scale are governed by custom, non-OSI-compliant community agreements.3
• Source-Available Model: A machine learning model whose code and parameter architectures are visible for audit and study, but whose licensing explicitly restricts commercial application, redistribution, or competitive derivative creation.3
• Self-Hosting: The operation of open-weight or proprietary models on infrastructure directly leased, owned, or logically isolated by the deploying organization, including virtual private clouds (VPCs) and private hardware clusters.
• Local Deployment: The execution of models on physical, non-cloud edge hardware, local workstations, or closed on-premises data centers, operating entirely decoupled from external network dependencies.
• Hybrid Architecture: An engineering pattern that partitions execution across both proprietary managed endpoints and self-hosted models, controlled by an internally owned gateway layer to balance cost, latency, and compliance constraints.5
• Control Plane: The central architectural layer that governs routing, identity and access management, policy enforcement, semantic caching, rate limiting, and audit logging across all underlying model executions.5
• Execution Plane: The runtime infrastructure where raw inference calculations are executed, whether hosted on a vendor’s public cloud API, a private GPU cluster, or a localized edge device.8
• Data Rights: The contractual terms governing who owns, can access, and can use inputs (prompts), outputs (completions), vector embeddings, telemetry logs, and user feedback generated during model operations.9
• Lock-In: The structural, mathematical, and financial coupling of an application to a specific model provider’s API, prompt formatting, embedding coordinate geometry, or commercial terms.11
• Exit Plan: A pre-vetted, contractually supported, and technically validated decommissioning protocol that details how an organization can transition a workload away from a vendor without service interruption, data loss, or degradation of system behavior.10
• Real Total Cost of Ownership (TCO): The comprehensive, fully loaded financial calculation of all capital and operational expenditures associated with an AI system throughout its lifecycle, extending far beyond raw infrastructure or subscription pricing.14

AI Sourcing Strategy Doctrine

The core tenet of modern enterprise system design is that sourcing decisions must not be driven by model leaderboard rankings, developer advocacy, or temporary demonstration quality. Sourcing strategy is a discipline of strategic dependency design. The primary objective is to optimize for capability, control, cost, compliance, security, portability, and long-term lifecycle viability. The modern enterprise must operate under a foundational mandate: own the control plane; vary the execution plane.5

                  ┌──────────────────────────────────────────────┐  
                  │          ENTERPRISE CONTROL PLANE            │  
                  │  (SSO/RBAC, CEL Routing, Semantic Cache,     │  
                  │   Audit Logging, Policy Gates, Evals)        │  
                  └──────────────────────┬───────────────────────┘  
                                         │  
                 ┌───────────────────────┼───────────────────────┐  
                 ▼                       ▼                       ▼  
     ┌───────────────────────┐ ┌───────────────────┐ ┌───────────────────────┐  
     │    PROPRIETARY API    │ │  PRIVATE CLOUD    │ │     LOCAL / ON-PREM   │  
     │   (Managed Frontier)  │ │ (Open/Self-Host)  │ │   (Sensitive/Edge)    │  
     └───────────────────────┘ └───────────────────┘ └───────────────────────┘  
     └───────────────────────────────────┬───────────────────────────────────┘  
                                         ▼  
                             ┌───────────────────────┐  
                             │    EXECUTION PLANE    │  
                             └───────────────────────┘

An organization cedes strategic viability when it allows its core business logic, proprietary data representations, and user feedback systems to become trapped inside vendor-owned wrappers. The strategic value of artificial intelligence does not reside in the commodity intelligence rented from frontier foundation model providers; it resides in the proprietary data corpus, the domain-specific evaluation metrics, the workflow integration, and the accumulated user interaction loops.
Consequently, enterprise architects must construct an internal control plane that abstracts away provider-specific dependencies.12 By intercepting all traffic through an internally managed gateway, the enterprise can dynamically direct workloads to the cheapest, fastest, or most compliant execution environment without altering application code.12
Workloads must be ruthlessly classified. Generic reasoning tasks can be rented from managed APIs, provided robust data boundaries and zero-data-retention terms are contractually guaranteed.9 Conversely, core product differentiators, regulated data pipelines, and high-frequency automated workflows must utilize self-hosted open-weight models, private clouds, or hybrid routing to preserve operational autonomy, ensure cost predictability at scale, and eliminate the existential risk of vendor deprecation.16
This approach inherits critical constraints from surrounding engineering disciplines:

• Product-Fit Alignment: Sourcing choices must directly map to real, validated user workflows and acceptable latency bounds, rejecting complex multi-billion parameter configurations if an optimized small local model satisfies the use case.6
• Adoption Compatibility: Vendor selections must integrate cleanly with corporate training infrastructures, ensuring model behaviors are explainable, supportable, and aligned with real feedback loops.9
• Environmental Sustainability: Sourcing decisions must calculate hardware utilization, power consumption, and carbon impact, balancing local GPU operations against the efficiency gains of centralized cloud architectures.16
• Supply Chain Resilience: Downloaded models, libraries, and containers must undergo rigorous Software Bill of Materials (SBOM) audits to verify provenance, validate cryptographic trust, and eliminate unpatched vulnerability vectors.24

Build, Buy, Open, and Hybrid Decision Matrix

AI sourcing strategy is not a binary build-versus-buy question. Enterprises must choose among finished vendor applications, managed APIs, hosted open models, self-hosted models, open-source stack assembly, in-house build, and hybrid control-plane architectures. The right answer depends on workflow differentiation, data sensitivity, latency, cost profile, internal engineering capacity, compliance exposure, portability needs, and exit risk.

Decision Rule

The preferred architecture is the lowest-complexity sourcing posture that satisfies:

workflow fit
+ data rights
+ risk tier
+ cost-to-serve
+ operational readiness
+ portability
+ strategic differentiation

Do not self-host to look sophisticated. Do not buy a vendor app that captures the core workflow. Do not use managed APIs without an exit route. The goal is controlled optionality, not ideological purity.

AI Stack Ownership Map

An AI system is a layered dependency graph. Each layer should be classified by the degree of strategic control required. Not every layer must be literally owned, but every critical layer must be controlled through architecture, contract, abstraction, export rights, or operational policy.

AI STACK CONTROL MAP

[ User Interface / Workflow Surface ]
        |
[ Prompts / Context / Product Logic ]
        |
[ Evals / Rubrics / Quality Gates ]
        |
[ Internal Gateway / Routing / Policy Plane ]
        |
[ Retrieval Corpus / Embeddings / Indexes ]
        |
[ Tool and Action Execution Layer ]
        |
[ Telemetry / Feedback / Audit Evidence ]
        |
[ Model Providers / Weights / Serving Runtime ]
        |
[ Compute Infrastructure / Hosting Region ]

Control States

Layer Ownership and Control Requirements

The durable rule is: own what differentiates you, control what can harm you, abstract what changes quickly, and rent what is commodity.

Open Source, Open Weight, and License Model

A downloadable model is not automatically open source. AI sourcing must distinguish open-source software, open-source AI systems, permissive open-weight models, restricted open-weight models, research-only models, source-available systems, and hosted proprietary APIs.

The term “open source” should be used carefully. Under the Open Source AI Definition, an Open Source AI system must provide freedoms to use, study, modify, and share, and must make available the preferred forms needed to modify the system, including sufficient data information, code, and parameters.

MODEL / AI ASSET LICENSING FLOW

[ AI Asset ]
      |
      v
[ Does it grant rights to use, study, modify, and share? ]
      |
      +-- no --> [ Proprietary / Source-Available / Restricted ]
      |
      v
[ Are required modification artifacts available? ]
  data information | code | parameters
      |
      +-- no --> [ Open Weights or Source-Available, not full Open Source AI ]
      |
      v
[ Are usage, field, scale, or competition restrictions absent? ]
      |
      +-- no --> [ Restricted Open Weights / Custom License ]
      |
      v
[ Open Source AI Candidate ]

License and Asset Taxonomy

Required License Review Questions

Procurement Rule

Do not ask, “Is the model open?” Ask:

What exact artifact is available?
Under what exact license?
For what exact use?
At what scale?
With what derivative rights?
With what output rights?
With what provenance?
With what exit path?

The answer should be recorded in the AI inventory before production use.

Managed API Evaluation Model

Managed APIs provide rapid access to high-capability models without operating the underlying infrastructure. They are often the correct sourcing choice for frontier reasoning, variable demand, multimodal workloads, and fast experimentation. They also introduce dependency, drift, data, availability, cost, and portability risks.

Managed API Risk and Control Matrix

Gateway Abstraction Imperative

Application code should call an internal AI gateway rather than directly hardcoding provider SDKs and endpoints.

[ Application ]
      |
      v
[ Enterprise AI Gateway ]
  identity | quota | policy | routing | logging | cache | eval hooks
      |
      +--> Provider A
      +--> Provider B
      +--> Hosted open model
      +--> Self-hosted model
      +--> Degraded deterministic route

Gateway Responsibilities

Managed APIs are rented capability. The enterprise control plane is what prevents rented capability from becoming strategic captivity.

Vendor Application Evaluation Model

Buying a finished AI vendor application can be the right decision when the workflow is commodity, the vendor product fits the user surface, internal engineering capacity is limited, and speed-to-market matters. The risk is that the vendor may capture the workflow, user feedback, data flows, evaluation surface, and operational dependency.

VENDOR APPLICATION DEPENDENCY CHAIN

[ Enterprise Buyer ]
        |
        v
[ Vendor Application / SaaS UI ]
        |
        +--> model provider
        +--> cloud host
        +--> analytics provider
        +--> support tooling
        +--> subprocessors
        +--> data stores

Vendor Application Evaluation Matrix

Wrapper Risk

A vendor application may be a thin workflow layer over a foundation model API. This is not automatically bad, but the buyer must understand what value the vendor actually provides.

Federal Procurement Planning Note

Some federal procurement environments may impose special AI disclosure, data-handling, domestic-sourcing, or use-rights requirements. Proposed GSA AI terms in 2026 illustrate the direction of travel: disclosure of AI systems used in contract performance, downstream provider visibility, data segregation, and special government-use rights may become relevant for contractors.

Treat these requirements as jurisdiction- and contract-specific. Do not generalize draft federal procurement terms into universal enterprise doctrine. For government-related work, legal and contracts teams must verify the current clause status before procurement approval.

Vendor Application Decision Rule

Buy the application when:

workflow is commodity
+ vendor fit is strong
+ data rights are clear
+ exit is tolerable
+ integration burden is lower than building
+ the vendor’s roadmap risk is acceptable

Do not buy when the vendor would own the enterprise’s strategic workflow, feedback loop, evaluation surface, or customer relationship.

Open Model and Self-Hosting Strategy

Self-hosting open-weight or proprietary models can improve data control, cost predictability, latency, and sovereign deployment posture. It also transfers operational responsibility to the enterprise. The organization becomes responsible for serving reliability, GPU capacity, memory pressure, patching, model upgrades, telemetry, security, evaluation, and incident response.

Self-Hosting Decision Drivers

VRAM and Memory Planning

VRAM is often the binding constraint in self-hosted inference. A simple parameter-memory heuristic is useful for early planning, but production sizing must include KV cache, batch size, context length, precision, runtime overhead, parallelism, and fragmentation.

Approximate model memory:
  model_weight_memory
+ KV_cache_memory
+ runtime_overhead
+ batch_overhead
+ safety_margin
<= available_accelerator_memory

Parameter Memory Heuristic

KV Cache Scaling

The KV cache scales with:

context length
× batch size
× number of layers
× hidden dimensions / attention heads
× cache precision

Longer context windows and larger batches can exhaust VRAM even when model weights fit. Increasing context is not free. It can reduce throughput, increase memory pressure, and force smaller batch sizes. For many enterprise workflows, better retrieval, chunking, reranking, and context compression are more efficient than simply expanding the active context window.

Common Self-Hosting Failure Modes

Self-hosting is a control strategy, not a virtue signal. It should be chosen when the organization can operate the system better than it can rent it.

Local Deployment Readiness Model

Local, on-premises, private-cloud, or edge deployment requires more than purchasing GPUs. The organization must be ready to operate hardware, serving runtimes, security controls, telemetry, model lifecycle, incident response, and user support.

Readiness Tiers

Readiness Assessment

Consumer GPU and Commodity Hardware Note

Consumer or prosumer GPUs can be useful for prototyping, labs, edge cases, and cost-sensitive internal workflows. They may also introduce warranty, availability, driver, cooling, power, memory, and support limitations. Use them deliberately, not because the spreadsheet looked heroic before anyone added operations.

Hybrid Architecture Pattern Library

Hybrid AI architectures combine owned control surfaces with multiple execution environments. Their purpose is not complexity for its own sake. A hybrid pattern is justified when it improves cost, privacy, reliability, latency, compliance, or capability while preserving a coherent control plane.

Hybrid Architecture Rule

Hybrid systems need a single owned policy, telemetry, evaluation, and routing story. Without that, “hybrid” means vendor sprawl wearing a fake mustache.

Vendor Selection Scorecard

AI vendors should be evaluated by risk tier, not by a single universal score threshold. A low-risk internal productivity tool, a customer-facing support agent, and a regulated decision-support workflow do not require identical evidence. They do require a consistent review structure.

Scoring Dimensions

Risk-Tier Evidence Requirements

Fatal Flaws

A scorecard should support judgment, not replace it. Procurement decisions should record risk tier, accepted residual risks, required mitigations, and the named owner of the vendor relationship.

Data Rights and Training-Use Checklist

AI contracts must define rights and restrictions for prompts, completions, uploaded files, embeddings, vector indexes, telemetry, user corrections, fine-tunes, adapters, logs, and derived artifacts. Marketing assurances are not enough. The controlling terms must appear in the contract, DPA, order form, enterprise settings, or incorporated policy.

Contract Review Checklist

Consumer and Shadow-AI Caution

Consumer AI tools often have different data-use, retention, training, and admin-control terms than enterprise products. Current provider policies may allow users to opt out of training or choose data-use settings, but those defaults change and vary by product tier. Enterprises should not rely on consumer settings for corporate data protection.

Data Rights Rule

No production AI system should launch until the organization can answer:

What data enters?
Where does it go?
Who can see it?
How long is it retained?
Can it train a model?
Who owns derived artifacts?
Can we export it?
Can we delete it?
Can we prove the answers?

AI Security Review Checklist

AI security review must cover software supply chain, model artifacts, provider infrastructure, tenant isolation, prompt/tool boundaries, data egress, secrets, and incident response. Traditional SaaS security review is necessary but not sufficient.

AI security review should be performed before procurement approval, before production launch, and after material model, provider, tool, or data-flow changes.

Integration Cost Model

The purchase price of an AI dependency is only one part of integration cost. Real integration cost includes identity, permissions, data preparation, retrieval, evals, telemetry, support, governance, fallback, migration, and user enablement.

Avoid universal engineering-hour estimates. Instead, estimate each cost center from system complexity, number of integrations, data volume, risk tier, and required assurance level.

Integration Cost Centers

Reindexing and Embedding Migration Cost

Changing embedding models often requires rebuilding the vector index. The cost depends on:

number of source documents
× chunks per document
× embedding model cost or infrastructure cost
× dimensions and storage footprint
× metadata reconstruction
× validation and retrieval eval effort
× downtime or blue-green migration requirements

The safe planning assumption is that embedding migration is a project, not a config flip.

Integration Cost Estimate Template

Integration cost is where “cheap API” fantasies go to be politely mugged by reality.

Lock-In Taxonomy

Lock-in is not a singular commercial concern; it is a multi-dimensional technical dependency. Enterprise architects must identify, track, and mitigate eleven distinct dimensions of lock-in.

                  ┌──────────────────────────────────────────────┐  
                  │              LOCK-IN CATEGORY                │  
                  └──────────────────────┬───────────────────────┘  
                                         │  
        ┌───────────────┬────────────────┼───────────────┬───────────────┐  
        ▼               ▼                ▼               ▼               ▼  
  ┌───────────┐   ┌───────────┐    ┌───────────┐   ┌───────────┐   ┌───────────┐  
  │   MODEL   │   │    API    │    │  PROMPT   │   │ EMBEDDING │   │   DATA    │  
  └───────────┘   └───────────┘    └───────────┘   └───────────┘   └───────────┘  
        ▼               ▼                ▼               ▼               ▼  
  ┌───────────┐   ┌───────────┐    ┌───────────┐   ┌───────────┐   ┌───────────┐  
  │ WORKFLOW  │   │   EVAL    │    │ AGENT/TOOL│   │COMMERCIAL │   │COMPLIANCE │  
  └───────────┘   └───────────┘    └───────────┘   └───────────┘   └───────────┘  
                                         ▼  
                                   ┌───────────┐  
                                   │ ADOPTION  │  
                                   └───────────┘

1. Model Lock-In: Product functionality depends on the unique edge-case behaviors, formatting styles, or reasoning quirks of a specific provider’s model.12
2. API Lock-In: Application code directly imports vendor-specific SDKs and endpoints, requiring a codebase refactor to swap providers.12
3. Prompt Lock-In: System prompts are highly optimized and tuned to one model architecture, producing degraded or incorrect outputs when sent to other models.12
4. Embedding Lock-In (Representation Lock-In): Stored vector indexes are tied to the specific mathematical coordinate system and dimensionality of a single embedding model.11 Upgrading or changing the model renders the entire index obsolete overnight.11
5. Data Lock-In: Interaction history, training data, and user correction logs are stored in a vendor’s proprietary cloud and cannot be easily exported.9
6. Workflow Lock-In: Internal business processes are redesigned around a vendor’s custom SaaS user interface, making system migration difficult.10
7. Eval Lock-In: Performance monitoring and evaluation metrics are managed exclusively inside a vendor’s proprietary dashboard, preventing independent verification.21
8. Agent & Tool Lock-In: The orchestration platform is tied to a vendor’s proprietary tool-calling schema, blocking migration to open-source agent runtimes.23
9. Commercial Lock-In: High usage-based discounts or multi-year commitments hide future pricing increases and limit bargaining leverage.10
10. Compliance Lock-In: Audit records, safety proofs, and regulatory reports reside inside a vendor’s system, leaving the organization vulnerable during external compliance audits.27
11. Adoption Lock-In: Staff are trained exclusively on a vendor-specific interface, requiring retraining during system migrations.22

AI Vendor Exit Plan Template

Every production AI dependency must have an exit plan before launch. Exit planning is not pessimism. It is dependency hygiene. Vendors change prices, models, policies, regions, roadmaps, ownership, and terms. Systems that cannot leave cannot negotiate.

Exit Plan Summary

Exit Phases

Exit Drill Requirements

Exit plans should define thresholds by workload. A support chatbot and a regulated transaction system do not need the same RTO, but both need to know how they leave.

Real Total Cost of Ownership (TCO) Model

AI sourcing decisions must be evaluated using real total cost of ownership, not subscription price or token price alone.

Real TCO =
  C_vendor
+ C_infra
+ C_integration
+ C_governance
+ C_ops
+ C_support
+ C_eval
+ C_security
+ C_risk
+ C_lifecycle
+ C_exit

TCO Worksheet

Sensitivity Variables

TCO Comparison Template

TCO should be recalculated at renewal, major model migration, workload growth, incident, regulatory change, and hardware refresh.

Procurement Reality Model

AI procurement is a multi-disciplinary operating process. Legal, security, engineering, governance, finance, product, operations, and the business owner must review different parts of the dependency. The goal is not to slow every request equally. The goal is to route each request through the review depth appropriate to its risk.

AI PROCUREMENT FLOW

[ Intake Request ]
  use case | data classes | users | vendor | model route | risk hypothesis
        |
        v
[ Triage ]
  low | medium | high | regulated / prohibited
        |
        +--> [ Fast Track Review ]
        |
        +--> [ Standard Review ]
        |
        +--> [ Enhanced Review ]
        |
        +--> [ Block / Legal Escalation ]
        |
        v
[ Parallel Review ]
  legal/DPA
  security
  engineering/integration
  governance/compliance
  finance/TCO
  product/workflow fit
  adoption/support
        |
        v
[ Decision ]
  approve
  approve with controls
  sandbox only
  revise and resubmit
  reject
        |
        v
[ Inventory + Monitoring + Renewal Review ]

Risk-Tier Review Matrix

Review Workstreams

Mandatory Procurement Artifacts

Procurement should end with an owned inventory record, not an email saying “approved.” The inventory record is what enables renewal review, incident response, audit, and exit.

Cross-Canon Handoff Map

AI-ENG-AH defines sourcing architecture and strategic dependency design. It determines when to build, buy, self-host, use open-weight models, consume managed APIs, assemble open-source stacks, or route across hybrid execution planes. It connects product strategy, governance, runtime architecture, security, sustainability, telemetry, evaluation, procurement, and exit planning.

Core Handoff Rule

Sourcing is architecture. A vendor contract, model license, API endpoint, embedding model, gateway, support term, or export clause can determine whether an AI system is portable, governable, profitable, safe, and durable.

The enterprise should not merely ask:

Which model is best?

It should ask:

Which dependencies are we creating?
Who controls them?
How do we verify them?
How do we operate them?
How do we leave?

Works cited

1. Open Source AI, accessed June 15, 2026, https://opensource.org/ai
2. The Open Source AI Definition – 1.0 – Open Source Initiative, accessed June 15, 2026, https://opensource.org/ai/open-source-ai-definition
3. The Future of Open Source in the AI Era - Blog - One Horizon, accessed June 15, 2026, https://onehorizon.ai/blog/the-future-of-open-source-in-the-ai-era
4. Meta Llama 3 and the 700M MAU Limit: Who This License Does Not …, accessed June 15, 2026, https://wcr.legal/llama-3-license-700m-mau-limit/

5. AI Gateway Architecture: A Guide for Technical Teams

   MLflow, accessed June 15, 2026, https://mlflow.org/articles/ai-gateway-architecture-a-guide-for-technical-teams/

6. Hybrid AI routing

   Services - SLM-Works, accessed June 15, 2026, https://slm-works.ai/services/hybrid-routing

7. LLM Gateway: Architecture, Routing & Governance Guide

   Axiom Studio, accessed June 15, 2026, https://axiomstudio.ai/learn/what-is-an-llm-gateway

8. Deployment - Truefoundry, accessed June 15, 2026, https://www.truefoundry.com/deployment
9. Enterprise AI Procurement & Contract Negotiation: The Complete Guide (2026), accessed June 15, 2026, https://thenegotiationexperts.com/blog/ai-complete-guide
10. AI Vendor Agreements & Enterprise AI Transactions Explained - Altawil Law Group, accessed June 15, 2026, https://thepathtojustice.com/ai-vendor-agreements-enterprise-ai-transactions/

11. Vendor Lock-In in the Embedding Layer: A Migration Story

    by Vassiliki Dalakiari

    ITNEXT, accessed June 15, 2026, https://itnext.io/vendor-lock-in-in-the-embedding-layer-a-migration-story-183ea58e3668

12. What Is an LLM Gateway and How Does It Work? - Truefoundry, accessed June 15, 2026, https://www.truefoundry.com/blog/llm-gateway

13. Vector Migration Explained: 7 Reasons Moving Vector Data Is Harder Than It Looks

    by Syed

    Medium, accessed June 15, 2026, https://medium.com/@syed_33931/vector-migration-explained-7-reasons-moving-vector-data-is-harder-than-it-looks-1edd66f6c439

14. LLM Hosting Cost 2026: Self-Host vs API Pricing Guide - AI Superior, accessed June 15, 2026, https://aisuperior.com/llm-hosting-cost/
15. Self-Hosting LLMs: Hidden Costs You’re Missing - Azumo, accessed June 15, 2026, https://azumo.com/artificial-intelligence/ai-insights/self-hosting-llms-cost
16. Self-Hosted LLM Guide: Costs, Architecture & Breakeven Point …, accessed June 15, 2026, https://alpacked.io/blog/self-hosted-llm-guide/
17. The LLM layer you’re probably missing (LLM gateway pattern explained) - Redgate, accessed June 15, 2026, https://www.red-gate.com/simple-talk/ai/the-llm-layer-youre-probably-missing-llm-gateway-pattern-explained/
18. Top 5 Enterprise AI Gateways for Multi-Model Routing in 2026 - Maxim AI, accessed June 15, 2026, https://www.getmaxim.ai/articles/top-5-enterprise-ai-gateways-for-multi-model-routing-in-2026/
19. DPA for AI vendors: what to actually check before you sign …, accessed June 15, 2026, https://companyscope.io/topics/dpa-for-ai-vendors
20. Vector Database Pricing Models: The Hidden Cost, accessed June 15, 2026, https://www.actian.com/blog/databases/the-hidden-cost-of-vector-database-pricing-models/
21. LLM Gateway Architecture: 2026 Engineering Reference - Digital Applied, accessed June 15, 2026, https://www.digitalapplied.com/blog/llm-gateway-architecture-2026-engineering-reference
22. Preparing for EU AI Act Compliance with ISO 42001 - A-LIGN, accessed June 15, 2026, https://www.a-lign.com/articles/preparing-for-eu-ai-act-compliance
23. The Full Picture of 2026 Enterprise AI Architecture: A New World of Autonomous Infrastructure Opened by Hybrid LLMs, AI Gateways, and AgentOS - note, accessed June 15, 2026, https://note.com/betaitohuman/n/n1c9b6d466f6b?hl=en
24. SOFTWARE BILL OF MATERIAL FOR AI - BSI, accessed June 15, 2026, https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/KI/SBOM-for-AI_minimum-elements.pdf?__blob=publicationFile&v=4
25. What Is an AI-BOM (AI Bill of Materials)? & How to Build It - Palo Alto …, accessed June 15, 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-an-ai-bom
26. What Is an LLM Gateway? The Missing Layer Between Your App and AI Models, accessed June 15, 2026, https://openrouter.ai/blog/insights/llm-gateway/
27. ISO 42001 Documentation: What’s Required for Compliance? - Hicomply, accessed June 15, 2026, https://www.hicomply.com/en-us/hub/documentation-requirements

28. ISO 42001 Checklist (2026): 38 Controls for AI Management

    Knowlee, accessed June 15, 2026, https://www.knowlee.ai/blog/iso-42001-checklist-ai-management

29. What Is Gemma 4’s Apache 2.0 License? Why It Matters More Than the Model Itself, accessed June 15, 2026, https://www.mindstudio.ai/blog/gemma-4-apache-2-license-commercial-use
30. Vector Database: Everything You Need to Know - WEKA, accessed June 15, 2026, https://www.weka.io/learn/guide/ai-ml/vector-database/
31. The State of “Open” Source AI – Gabriel Toscano - Sites@Duke Express, accessed June 15, 2026, https://sites.duke.edu/gabrieltoscano/2026/02/05/the-state-of-open-source-ai/
32. FinOps for AI: Tools & Services Considerations, accessed June 15, 2026, https://www.finops.org/wg/finops-for-ai-tools-services-considerations/
33. What Is the Gemma 4 Apache 2.0 License? Why It Changes …, accessed June 15, 2026, https://www.mindstudio.ai/blog/what-is-gemma-4-apache-2-license-commercial-ai-deployment
34. GSA AI Procurement Rules Would Introduce New Disclosure and Use-Rights Requirements for Federal Contractors - Gibson Dunn, accessed June 15, 2026, https://www.gibsondunn.com/gsa-ai-procurement-rules-would-introduce-new-disclosure-and-use-rights-requirements-for-federal-contractors/
35. “Additional Commercial Terms” must be removed from LICENSE to make Llama 3 open source #156 - GitHub, accessed June 15, 2026, https://github.com/meta-llama/llama3/issues/156
36. meta-llama/Llama-3.3-70B-Instruct - Hugging Face, accessed June 15, 2026, https://huggingface.co/meta-llama/Llama-3.3-70B-Instruct
37. Significant Risks in Using AI Models Governed by the Llama License - Open Source Guy, accessed June 15, 2026, https://shujisado.org/2025/01/27/significant-risks-in-using-ai-models-governed-by-the-llama-license/
38. Eight essential clauses for AI contracts: A guide for vendors and customers in Northern Ireland - A&L Goodbody, accessed June 15, 2026, https://www.algoodbody.com/insights-publications/eight-essential-clauses-for-ai-contracts-a-guide-for-vendors-and-customers-in-northern-ireland
39. Vector Database Challenges: What Breaks in Production - Redis, accessed June 15, 2026, https://redis.io/blog/common-challenges-working-with-vector-databases/

Attribution

Part of Stunspot’s Guide to AI Systems — The AI Engineering Systems Canon.

Created by Sam “stunspot” Walker / Collaborative Dynamics.

Repository: https://github.com/Stunspot/stunspots-guide-to-ai-systems
Stunspot: https://stunspot.com
Collaborative Dynamics: https://www.collaborative-dynamics.com
Discord: https://discord.gg/stunspot

Licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Commercial use, resale, paid redistribution, inclusion in commercial training products, or incorporation into paid knowledge-base products requires prior written permission.

← Back to Canon Map