Portable AI Architectures | Design Guide

Models, APIs, and hosting requirements can change. A portable design separates dependencies so that a provider change has a defined scope. Adapters, evaluations, data migration, and rollout may still be necessary. This is the design companion to AI vendor lock-in.

The Layers of Portability

Review portability in four layers: model integration, data, infrastructure, and workflow.

Model portability. Aim to isolate changes to the large language model or smaller task model behind a tested interface. Business logic names a capability. extract, answer with citations, classify. never a vendor model string.

Data portability. Documents, labels, chunks, and embedding inputs live in formats you can leave with. The vector database is rebuildable. Eval sets are files, not screenshots of a fine-tune job.

Infrastructure portability. Identify which parts can move to another runtime and which need replacement. A container can package application dependencies; a Cloudflare Worker can depend on platform-specific APIs and bindings. Neither proves that all infrastructure is portable.

Workflow portability. Document retrieval, tool calls, CRM writes, and human review as an explicit process. Check whether workflow automation definitions can be exported and reproduced elsewhere. A webhook alone does not make the orchestrator or its dependencies portable.

For typical retrieval-augmented generation, model and data dominate. Infrastructure bites when retrieval, files, and queues all live in one cloud’s AI suite. Workflow bites when the “AI” is a pile of vendor automations with no diagram.

Client / internal tool
 |
 v
Application: task rules, permissions, orchestration
 |
 +-- Retrieval interface --> Vector store
 | (rebuilt from retained sources)
 +-- Model adapter -------> Selected model provider
 |
 +-- Action interface ----> CRM / ticket API

This diagram shows dependency boundaries, not execution order. For a retrieval answer, the application retrieves authorised context before requesting the answer. Replace an adapter or store client and validate the resulting behaviour before switching production.

Model Abstraction Patterns

These three patterns can help isolate business logic from provider-specific integration:

Adapter. One module: complete(request) → normalised result. Inside: retries, timeouts, token accounting, vendor errors. Outside: no SDK types. A second provider is a second adapter with the same result type. Ordinary API integration hygiene, applied to models.

Interface segregation. Do not expose a 40-field completion object to the whole codebase. Extraction wants fields. Answering wants text plus citations. Classification wants a label. Separate ports so a cheaper model can serve classification without dragging frontier options into that path.

Response normalisation. Vendors disagree on roles, tool-call shape, usage, and refusals. Translate once. Downstream code should never branch on one vendor’s content_filter and another’s stop_reason.

Keep prompt files next to the adapter, versioned, with the last model they passed. LangChain or LlamaIndex can sit inside the adapter. They should not become your type system. If the framework leaks vendor objects into the domain, you bought a second lock-in.

Fine-tuning requires a separate portability assessment. A proprietary hosted model may not expose weights for export; an open-weight model may be movable under its licence. Retain authorised training data and evaluation records so alternatives can be tested.

Data Portability

Document where source data lives and how it can be exported and rebuilt.

Source of truth is files, not the index. Markdown, PDF text, HTML, and JSON live in storage you control. Chunking is a data pipeline you can re-run. The vector index is derived. If a vendor retrieval product holds the only copy of your chunks, you have a hostage, not a knowledge base.

Record the embedding contract. Store model/version, dimensions, distance metric, and preprocessing beside the index. Some databases reject mismatched dimensions; others support multiple named vectors. Keep query and document representations compatible. The pgvector documentation provides concrete examples of vector types, indexing, and filtering.

Exportable eval data. Store authorised examples and expected outcomes in a portable format such as JSONL. Cover important classes and failure modes. A fixed number of examples cannot prove that a system will never make a mistake.

Stores you can leave. Check for a documented export and test a rebuild from retained source data. A proprietary query language alone does not establish whether the data can be exported. How to structure the content: building a knowledge base that powers AI systems.

Infrastructure Patterns

Choose deployment redundancy and portability from recovery requirements, traffic, and operational capacity. Company size alone does not determine whether multiple regions are necessary.

Keep runtime dependencies visible. Document provider-specific libraries, bindings, queues, and storage. HTTP-based model calls may be portable while the surrounding runtime needs an adapter or replacement. A Worker is not interchangeable with an arbitrary container deployment.

Cloud-agnostic where it is cheap. Object storage with a standard API, a Postgres you could host elsewhere, a queue you understand. You do not need three clouds. You need a known replacement for each piece.

Infrastructure as code. Define deployable resources and configuration in version control, while storing secret values in an appropriate secret store. Infrastructure code can improve repeatability without making provider-specific resources portable.

Location and recovery. Verify where execution, storage, backups, logs, and model processing occur. Multiple regions can improve resilience or latency, but may conflict with a strict residency requirement. Having EU users alone does not establish a requirement to run in several EU regions.

A custom app is not always required; see when a business needs a custom app. If you are building, compare the extra implementation cost of portability with the dependencies and recovery requirements you expect to manage.

The Portability Tax

Abstraction is not free.

You will write more glue. You will miss some vendor-only features on day one. You will spend time on evals a single-vendor prototype skipped. Debugging is sometimes slower because the failure is in your adapter.

Invest more when a provider failure, inaccessible source data, or lengthy migration would breach the system’s recovery requirements. Test the proposed mitigation against that requirement.

Invest less when the work is a disposable experiment or an existing product meets the requirement at acceptable risk. Record the point at which a prototype would need a production review.

For a staff Q&A system, compare approaches by the work they require rather than assigning unverified migration times:

Approach	Model change	Store change	Trade-off
Provider suite	Depends on supported models and exposed interfaces	Export and feature mapping may be needed	Less initial integration, more provider dependency
Adapter and owned source data	Adapt and evaluate the replacement	Migrate or rebuild and validate retrieval	Additional integration code to maintain
Tested secondary deployment	Use the rehearsed cutover procedure	Switch only if replication and recovery tests pass	Extra operating and validation costs

The middle approach is a useful candidate when source ownership and a model adapter address the likely changes. Choose the amount of redundancy from measured recovery needs and cost rather than a universal rule.

Where Fernside Fits

We can design AI systems with task interfaces, model adapters, exportable source data, and documented rebuild procedures. Advisory helps decide which portability work is justified for the system.

Want a system that survives a provider change? Book a discovery call and we will sketch the layers against the workflow you actually need to keep running.