Disenar Sistemas de IA sin Vendor Lock-In: Que Abstraer (y Que No)

La Trampa del Lock-In

Todo proyecto de IA comienza con un solo proveedor. OpenAI, Anthropic, o un modelo local. El SDK entra en el codigo. Las funcionalidades especificas del proveedor (formato de llamadas a funciones, modo JSON, comportamiento del prompt de sistema) se integran en la logica de negocio. Seis meses despues, quieres cambiar de proveedor (costo, rendimiento, cumplimiento normativo) y descubres que la migracion requiere reescribir la mitad de la aplicacion.

Hemos construido sistemas de IA que usan multiples proveedores simultaneamente y hemos cambiado de proveedor en medio de un proyecto sin tocar la logica de negocio. Este articulo cubre la arquitectura que hace eso posible y los compromisos reales que implica.

Para patrones mas amplios de arquitectura IA, consulta nuestra guia de sistemas IA y nuestra guia de orquestacion IA.

Que Crea el Lock-In

La Capa de Abstraccion Que Funciona

Una buena capa de abstraccion tiene tres componentes: una interfaz unificada para las llamadas al modelo, una capa de gestion de prompts, y un framework de evaluacion.

// Interfaz LLM unificada
interface LlmProvider {
    generate(request: LlmRequest): Promise<LlmResponse>;
    stream(request: LlmRequest): AsyncIterable<LlmChunk>;
    embed(texts: string[]): Promise<number[][]>;
}

interface LlmRequest {
    model: string;
    messages: Message[];
    temperature?: number;
    maxTokens?: number;
    responseFormat?: 'text' | 'json';
    tools?: ToolDefinition[];
}

interface LlmResponse {
    text: string;
    usage: { promptTokens: number; completionTokens: number };
    finishReason: string;
    model: string;
    provider: string;
    latencyMs: number;
}

Cada proveedor implementa esta interfaz:

class OpenAiProvider implements LlmProvider {
    async generate(request: LlmRequest): Promise<LlmResponse> {
        const response = await this.client.chat.completions.create({
            model: request.model,
            messages: this.convertMessages(request.messages),
            temperature: request.temperature,
            max_tokens: request.maxTokens,
            response_format: request.responseFormat === 'json'
                ? { type: 'json_object' } : undefined,
        });
        return this.convertResponse(response);
    }
}

class AnthropicProvider implements LlmProvider {
    async generate(request: LlmRequest): Promise<LlmResponse> {
        const response = await this.client.messages.create({
            model: request.model,
            system: this.extractSystemMessage(request.messages),
            messages: this.convertMessages(request.messages),
            temperature: request.temperature,
            max_tokens: request.maxTokens ?? 4096,
        });
        return this.convertResponse(response);
    }
}

La logica de negocio usa la interfaz, nunca el SDK del proveedor directamente:

// Logica de negocio: agnostica del proveedor
async function generateCustomerResponse(ctx: Context, ticket: string): Promise<string> {
    const provider = ctx.getLlmProvider(); // resuelto desde la config
    const response = await provider.generate({
        model: ctx.getModelForUseCase('customer-support'),
        messages: [
            { role: 'system', content: SUPPORT_SYSTEM_PROMPT },
            { role: 'user', content: ticket },
        ],
        temperature: 0.3,
    });
    return response.text;
}

Cambiar de OpenAI a Anthropic: modifica la config. Cero cambios de codigo en la logica de negocio.

El Problema de la Portabilidad de Prompts

Los prompts no son portables entre modelos. Un prompt optimizado para GPT-4 puede producir peores resultados en Claude, y viceversa. Los modelos interpretan las instrucciones de forma diferente, manejan los casos limite de forma diferente, y tienen fortalezas distintas.

La solucion: variantes de prompt por familia de modelo.

const SUPPORT_PROMPTS: Record<string, string> = {
    'openai': `You are a customer support assistant. Be concise and helpful.
When you don't know the answer, say so clearly.
Always reference the customer's order number.`,

    'anthropic': `You are a customer support assistant.
<instructions>
- Be concise and helpful
- When you don't know the answer, say so clearly
- Always reference the customer's order number
</instructions>`,

    'local': `### System
You are a customer support assistant.
### Rules
1. Be concise and helpful
2. When you don't know the answer, say so clearly
3. Always reference the customer's order number`,
};

function getPrompt(useCase: string, provider: string): string {
    return PROMPTS[useCase][provider] || PROMPTS[useCase]['default'];
}

Esto agrega costo de mantenimiento (multiples versiones de prompts), pero es la realidad. Un solo prompt para todos los modelos significa aceptar calidad degradada en al menos uno.

Enrutamiento Multi-Modelo

Cada tarea tiene requisitos diferentes. La clasificacion necesita velocidad. La generacion necesita calidad. El embedding necesita consistencia. Dirige cada tarea al modelo correcto.

const MODEL_ROUTING: Record<string, ModelConfig> = {
    'classification': {
        primary: { provider: 'openai', model: 'gpt-4o-mini' },
        fallback: { provider: 'anthropic', model: 'claude-haiku-4-5-20251001' },
        reason: 'Fast, cheap, good enough for classification',
    },
    'generation': {
        primary: { provider: 'anthropic', model: 'claude-sonnet-4-20250514' },
        fallback: { provider: 'openai', model: 'gpt-4o' },
        reason: 'Best quality for long-form generation',
    },
    'embedding': {
        primary: { provider: 'openai', model: 'text-embedding-3-small' },
        fallback: null, // No se puede cambiar de modelo de embedding sin re-indexar
        reason: 'Consistency: all embeddings must use the same model',
    },
    'summarization': {
        primary: { provider: 'anthropic', model: 'claude-haiku-4-5-20251001' },
        fallback: { provider: 'openai', model: 'gpt-4o-mini' },
        reason: 'Fast and cheap for summaries',
    },
};

La config de enrutamiento esta separada de la logica de negocio. Cambiar que modelo maneja los resumenes es un cambio de config, no un cambio de codigo.

Lock-In de Embeddings: El Mas Dificil de Romper

Los embeddings son la forma mas fuerte de lock-in. Una vez que indexas 100K documentos con text-embedding-3-small, cambiar a un modelo de embedding diferente requiere re-indexar todo. Los vectores son incompatibles entre modelos (dimensiones diferentes, espacios semanticos diferentes).

Mitigaciones:

• Almacena los documentos fuente junto a los embeddings (para poder re-indexar)
• Registra que modelo de embedding se uso por documento
• Presupuesta el re-embedding al planificar un cambio de proveedor
• Considera modelos de embedding open-source (sentence-transformers) para portabilidad

Para profundizar en patrones de busqueda vectorial y gestion de embeddings, consulta nuestra guia de arquitectura de busqueda vectorial y nuestra guia de sistemas RAG empresariales.

Desarrollo Basado en Evaluacion

La clave para cambiar de proveedor de forma segura: evalua contra tareas, no contra modelos. Si tu suite de evaluacion prueba "la respuesta aborda correctamente el problema del cliente?" en vez de "la salida coincide con el formato de GPT-4?", puedes cambiar de modelo con confianza.

interface EvalCase {
    input: string;
    expectedBehavior: string;  // Lo que la salida deberia HACER, no lo que deberia DECIR
    criteria: EvalCriterion[];
}

interface EvalCriterion {
    name: string;
    check: (output: string, context: EvalCase) => boolean | number;
}

const SUPPORT_EVALS: EvalCase[] = [
    {
        input: "I haven't received my order #12345",
        expectedBehavior: "Acknowledge the issue, reference order number, offer next steps",
        criteria: [
            { name: 'references_order', check: (out) => out.includes('12345') },
            { name: 'acknowledges_issue', check: (out) => /sorry|apologize|understand/i.test(out) },
            { name: 'offers_action', check: (out) => /check|investigate|track|follow up/i.test(out) },
            { name: 'reasonable_length', check: (out) => out.length > 50 && out.length < 500 },
        ],
    },
];

// Ejecutar evals contra cualquier modelo
async function runEvalSuite(provider: LlmProvider, model: string): Promise<EvalResults> {
    const results = [];
    for (const evalCase of SUPPORT_EVALS) {
        const output = await provider.generate({
            model,
            messages: [
                { role: 'system', content: SUPPORT_SYSTEM_PROMPT },
                { role: 'user', content: evalCase.input },
            ],
        });
        const scores = evalCase.criteria.map(c => ({
            name: c.name,
            passed: c.check(output.text, evalCase),
        }));
        results.push({ input: evalCase.input, scores });
    }
    return summarize(results);
}

Ejecuta la suite de evaluacion antes de cambiar de modelo. Si el nuevo modelo pasa con puntuaciones aceptables, la migracion es segura. Si no, sabes exactamente que comportamientos se degradaron.

Nuestra guia de observabilidad IA cubre las metricas a monitorear en produccion para este tipo de transiciones. Tambien puedes explorar nuestro enfoque de diseno de workflows IA para estructurar tus pipelines de forma modular.

Que NO Abstraer

No todo debe abstraerse. La sobre-abstraccion agrega complejidad sin beneficio.

La abstraccion deberia cubrir: seleccion de modelo, enrutamiento de prompts, parsing de respuestas, seguimiento de costos, y logica de fallback. NO deberia intentar hacer que todos los proveedores se comporten de forma identica. No lo hacen, y pretender que si crea bugs.

Este patron forma parte de un enfoque mas amplio de arquitectura de sistemas y ingenieria de software robusta. Si trabajas con sistemas multi-agente, nuestra guia de arquitectura multi-agente cubre estrategias de enrutamiento a un nivel superior.

Cuando el Lock-In Es la Decision Correcta

A veces, quedarse atado a un proveedor es la decision de negocio correcta:

• El fine-tuning requiere compromiso con un solo proveedor. El modelo entrenado no es portable.
• Los descuentos por volumen de un solo proveedor pueden reducir costos de forma significativa.
• El cumplimiento normativo puede exigir un proveedor especifico (residencia de datos, certificaciones).
• La velocidad de salida al mercado implica usar funcionalidades especificas del proveedor sin la carga de la abstraccion.

Lo esencial: toma la decision de lock-in de forma consciente, no accidental. Si decides usar la Assistants API de OpenAI porque te ahorra 3 meses de desarrollo, es un compromiso valido. Si la usas porque no pensaste en la abstraccion, eso es deuda tecnica.

Para saber mas sobre cumplimiento normativo y las implicaciones del RGPD en tus elecciones de proveedor IA, consulta nuestra guia de conformidad RGPD para IA y nuestra pagina de RGPD.

Errores Comunes

1. SDK del proveedor en la logica de negocio. openai.chat.completions.create() esparcido en 50 archivos hace la migracion imposible. Usa una capa de abstraccion.

2. Un solo prompt para todos los modelos. Los prompts son especificos del modelo. Mantiene variantes por familia de modelo. Acepta el costo de mantenimiento.

3. Abstraer todo. La sobre-abstraccion agrega complejidad. Abstrae la interfaz, no los mecanismos internos.

4. Sin suite de evaluacion. Sin evals automatizadas, no puedes saber si un cambio de modelo degrada la calidad hasta que los usuarios se quejan.

5. Ignorar el lock-in de embeddings. Cambiar de modelo de embedding requiere re-indexar cada documento. Planifica este costo.

6. Lock-in accidental. El peor tipo. Usar funcionalidades especificas del proveedor sin darte cuenta de que estas creando una dependencia.

Nuestra guia de modos de fallo de IA cubre otras trampas comunes en sistemas IA en produccion, y la guia de gobernanza IA te ayuda a estructurar las decisiones en torno a la eleccion de proveedor.

Puntos Clave

• Abstrae la interfaz, no la implementacion. Una interfaz LlmProvider unificada con adaptadores especificos por proveedor. La logica de negocio llama a la interfaz.

• Los prompts no son portables. Manten variantes de prompt por familia de modelo. Un solo prompt para todos los modelos significa calidad degradada en algun lado.

• Dirige cada tarea al modelo correcto. Clasificacion a un modelo rapido, generacion a un modelo preciso, embeddings a un modelo consistente. Dirigido por config, no por codigo.

• Evalua contra tareas, no contra modelos. Si tu suite de evaluacion prueba comportamiento ("referencia el numero de pedido?") en vez de formato, puedes cambiar de modelo con confianza.

• Los embeddings son el lock-in mas dificil de romper. Almacena los documentos fuente. Registra que modelo se uso. Presupuesta el re-embedding.

• A veces el lock-in es la decision correcta. Fine-tuning, descuentos por volumen y cumplimiento normativo pueden justificarlo. Que sea una decision consciente.

Disenamos arquitecturas de IA agnosticas del proveedor como parte de nuestros servicios de IA y nuestra practica de consultoria. Explora nuestras soluciones para ver como aplicamos estos patrones, o revisa nuestros casos de uso concretos. Si necesitas ayuda con tu arquitectura IA, habla con nuestro equipo o solicita un presupuesto.