Part IV — Enterprise AI Architecture

The AI Landscape — An Architect's Map

The AI landscape in 2025 presents enterprise architects with a challenge that has no precedent in recent technology history: a capability surface that is expanding faster than any organization can track, marketed with claims that frequently outpace what is actually deliverable, and built on architectural assumptions that differ fundamentally from the systems architects have spent careers designing. This chapter provides the map that architects need before making commitments.

What You Will Learn

• The AI capability categories that matter for enterprise architecture
• How different AI capability types relate to each other architecturally
• The build vs. buy vs. API decision framework for AI components
• The architectural leverage points where design decisions have the most impact

33.1 The AI Capability Categories

Enterprise architects should organize AI capabilities into five categories:

Foundation models. Large-scale neural networks trained on vast corpora that serve as the base for downstream tasks. GPT-4, Claude, Gemini, LLaMA are foundation models. They are characterized by broad capability (they can be prompted to perform many different tasks), emergent behavior (capabilities not explicitly trained), and high inference cost relative to specialized models. Foundation models are the "general contractors" of the AI world — capable of many things, not optimized for any specific thing.

Specialized models. Models fine-tuned or trained from scratch for specific tasks — a sentiment classifier, a named entity recognizer, a fraud scoring model, a document layout parser. Specialized models are faster, cheaper, and more accurate than foundation models for their specific task, but they require training data, labeling investment, and retraining as task requirements evolve.

Embedding models. Models that convert content (text, images, code) into numerical vectors suitable for semantic similarity comparison. Embedding models are the infrastructure of RAG systems, semantic search, and clustering applications. They are significantly cheaper than generative models and are available from both commercial providers and open-source.

Multi-modal models. Models that process or generate multiple content types — text, images, audio, video, code. Multi-modal capabilities are increasingly relevant as enterprise data is not exclusively text, and as AI features need to interact with documents, diagrams, audio recordings, and video content.

Agentic frameworks. Software architectures that combine multiple AI capabilities with tool use, memory systems, and orchestration to produce autonomous systems that complete multi-step tasks. Agentic frameworks are not a model type — they are an architectural pattern built on top of foundation or specialized models.

33.2 Architectural Relationships Between AI Capabilities

The AI capability categories are not independent — they compose. Understanding how they compose is what distinguishes an architect's view from a practitioner's view.

Foundation → specialized: Fine-tuning a foundation model on domain-specific data produces a specialized model that retains broad language understanding while developing task-specific precision. This is cheaper than training a specialized model from scratch and more accurate than prompting the foundation model alone.

Embedding model → RAG → foundation model: Embedding models enable retrieval of relevant documents; RAG passes those documents to a foundation model as context; the foundation model generates a grounded response. This pipeline is the most common enterprise AI architecture pattern.

Specialized + foundation + agentic framework: Agentic systems typically orchestrate a foundation model (for reasoning and planning) with specialized models (for specific high-volume tasks like extraction or classification), connected by an agentic framework that manages tool use, memory, and multi-step execution.

Architects who understand these compositional relationships can evaluate vendor offerings critically: what AI capabilities is the vendor actually providing, which are they combining, and where are they adding differentiation versus where are they reselling commodity capabilities?

33.3 Build vs. Buy vs. API

The build vs. buy decision for AI components has three options rather than two:

API (use a hosted model). Access AI capabilities via API from a commercial provider — OpenAI, Anthropic, Google, Azure AI. No infrastructure, no training, immediate access to frontier capabilities. Trade-offs: data leaves your environment (privacy and compliance implications), costs scale with usage, model behavior is not under your control, and the provider can change or deprecate the capability.

Buy (procure a packaged AI solution). Purchase a vendor-packaged AI product — a contract analysis tool, a customer service AI, a document processing platform. Faster time-to-value than building, purpose-built for the use case, but limited customizability and vendor lock-in. Appropriate when the use case is standard and the vendor's solution covers 80%+ of requirements without significant customization.

Build (train or fine-tune your own model). Invest in training or fine-tuning a model on your organization's data. Maximum customizability, data stays in your environment, no per-inference API cost at scale, but requires ML engineering capability, infrastructure investment, and ongoing maintenance. Appropriate when competitive differentiation requires proprietary AI capability, when data privacy requirements prohibit external API use, or when inference volume is high enough that API costs exceed self-hosting costs.

For most enterprise use cases, the answer is API for initial validation and exploratory features, buy for standard use cases where vendor solutions are mature, and build for strategic capabilities where differentiation matters.

33.4 Architectural Leverage Points

The architectural decisions with the most impact on AI system quality and maintainability:

Data pipeline architecture. How data flows from source systems to AI systems determines quality, freshness, and cost more than any model selection decision. Architects who invest in clean, well-governed data pipelines have an AI advantage that persists across model generations.

Abstraction layer for model access. Applications that call AI APIs directly become tightly coupled to specific model providers. An abstraction layer — a service that applications call, which routes to the appropriate model — enables model substitution, A/B testing, and cost optimization without application changes.

Evaluation infrastructure. The evaluation pipeline — how model outputs are measured against quality criteria — determines how quickly teams can detect and respond to quality changes. Evaluation infrastructure is operational infrastructure, not just development tooling.

Context management. How context is assembled, compressed, and provided to AI models determines both quality (are the right inputs in context?) and cost (how many tokens are consumed per inference?). Context management architecture is the most underinvested component in enterprise AI systems.

Audit and lineage. Enterprise AI systems must produce outputs that can be audited — what inputs produced what outputs, through what chain of reasoning. Building audit and lineage into the architecture from the start is dramatically cheaper than retrofitting it.

These leverage points apply regardless of which specific AI capabilities are deployed. Architects who design for them build systems that remain maintainable as the AI landscape evolves.