De dependiente de API a dueño de modelo: un plan de migración de 90 días

Has leído sobre los riesgos de dependencia de proveedores. Has hecho la checklist de independencia. Sabes que la matemática de costos favorece a los modelos propios. Ahora necesitas un plan.

Este playbook cubre los primeros 90 días de migración de dependiente de API a propietario de modelo. Está diseñado para equipos sin experiencia en ML, asumiendo que tienes acceso a tus logs de API y datos de dominio. El objetivo no es eliminar todo uso de API — es ser dueño de tus capacidades de IA más críticas y construir una base para independencia continua.

Antes de empezar: la mentalidad de migración

Dos principios marcan la diferencia entre una migración fluida y una dolorosa:

Ejecución paralela, no cambio en frío. No estás arrancando tu integración API y reemplazándola con un modelo ajustado el día uno. Estás ejecutando ambos lado a lado, comparando calidad y enrutando tráfico gradualmente. La API se mantiene activa hasta que el modelo ajustado se demuestre.

Empieza estrecho, expande sistemáticamente. No intentes migrar todo a la vez. Elige una tarea. Hazla bien. Construye confianza y conocimiento institucional. Luego repite.

Fase 1: Auditoría (Días 1-14)

Semana 1: Inventario de tus puntos de contacto con IA

Mapea cada lugar donde tu aplicación o flujo de trabajo llama a una API de IA. Para cada punto de contacto, documenta:

La mayoría de los equipos descubren que tienen 3-8 tareas de IA distintas en producción. Algunos tienen más.

Semana 2: Puntuación y priorización

Puntúa cada tarea en tres dimensiones:

Aptitud para fine-tuning (1-5):

• Formato consistente de entrada/salida → mayor puntuación
• Gran volumen → mayor puntuación
• Datos de entrenamiento disponibles → mayor puntuación
• Vocabulario o conocimiento específico del dominio → mayor puntuación
• Salida subjetiva o creativa → menor puntuación

Impacto de negocio (1-5):

• Alto costo mensual → mayor puntuación
• Orientado al cliente → mayor puntuación
• Sensible a SLA → mayor puntuación
• Generador de ingresos → mayor puntuación

Complejidad de migración (1-5, menor es mejor):

• Clasificación/extracción simple → baja complejidad
• Razonamiento multi-paso → complejidad media
• Generación abierta → mayor complejidad
• Multi-modal (texto + imágenes) → mayor complejidad

Prioridad = Aptitud x Impacto / Complejidad

Tu tarea con mayor puntuación es tu objetivo piloto de migración. En la mayoría de los negocios, es una de estas:

• Clasificación/enrutamiento de tickets de soporte al cliente
• Generación de contenido en un formato específico
• Extracción de datos de documentos estructurados
• Generación de respuestas de FAQ/base de conocimiento
• Calificación o puntuación de leads

Fase 2: Piloto (Días 15-45)

Semana 3: Prepara tu dataset de entrenamiento

Tus logs de API son tus datos de entrenamiento. Extrae pares de entrada/salida de tu sistema de producción.

Tamaño mínimo de dataset: 500 ejemplos de alta calidad. Esto es suficiente para una tarea bien definida con formato consistente.

Recomendado: 1,000-2,000 ejemplos. Le da al modelo más casos límite de los que aprender.

Calidad sobre cantidad. 500 ejemplos cuidadosamente revisados superan a 5,000 ruidosos. Invierte tiempo en calidad de datos, no solo en volumen.

Pasos de preparación del dataset:

1. Exporta datos crudos. Extrae pares de entrada/salida de tus logs de API, CRM o base de datos. Formatea como JSONL con la estructura de mensajes de chat que tu herramienta de entrenamiento espera.

2. Filtra por calidad. Elimina ejemplos donde la salida de la API fue incorrecta, mal formateada o requirió corrección manual. Quieres solo ejemplos de la tarea hecha correctamente.

3. Deduplica. Ejemplos casi idénticos agregan ruido. Elimina duplicados y casi-duplicados.

4. Balancea categorías. Si estás entrenando un clasificador, asegura representación razonable en todas las categorías. Un desequilibrio extremo (90% categoría A, 2% categoría B) causa que el modelo tenga bajo rendimiento en categorías minoritarias.

5. Divide los datos. Reserva 10-15% como conjunto de prueba que no se usará en el entrenamiento. Este es tu benchmark de evaluación.

Semana 4-5: Ajusta el modelo

Selecciona tu modelo base. Para la mayoría de las tareas de negocio:

• 7B parámetros — Inferencia rápida, corre en hardware de consumo, bueno para clasificación y extracción
• 14B parámetros — Mejor para tareas de generación, requiere más cómputo pero aún práctico
• Llama 3, Qwen 2.5 o Mistral — Todos de calidad de producción, todos comercialmente permisivos

Elige tu enfoque de entrenamiento:

• LoRA/QLoRA — El enfoque estándar. Entrena adaptadores ligeros (50-200MB) sobre los pesos base congelados. Eficiente en memoria, rápido de entrenar, y el adaptador es portable.
• Fine-tuning completo — Modifica todos los pesos. Mejor para tareas complejas pero requiere más cómputo. Generalmente innecesario para tareas de negocio bien definidas.

Configuración de entrenamiento (punto de partida):

• Learning rate: 2e-4
• Batch size: 4-8
• Épocas: 2-3
• LoRA rank: 32

Usando Ertas: Sube tu dataset JSONL, selecciona tu modelo base y comienza el entrenamiento. La plataforma maneja el aprovisionamiento de GPU, gestión de hiperparámetros y seguimiento de progreso. La configuración toma unos 2 minutos. El tiempo de entrenamiento depende del tamaño del dataset y modelo — típicamente 15-60 minutos para un fine-tune con LoRA.

Ejecuta 2-3 experimentos. Prueba diferentes modelos base, rangos de LoRA o duraciones de entrenamiento. La comparación lado a lado entre experimentos te ayuda a encontrar la mejor configuración.

Semana 6: Evalúa

Ejecuta tu conjunto de prueba reservado tanto a través del modelo API como de tu modelo ajustado. Compara:

Métricas cuantitativas:

• Precisión (para tareas de clasificación/extracción)
• Cumplimiento de formato (¿la salida coincide con tu estructura esperada?)
• Consistencia (¿misma respuesta para entradas equivalentes?)
• Latencia (tiempo de respuesta por solicitud)

Umbral de calidad: Para tareas específicas de dominio con buenos datos de entrenamiento, espera:

• 90-95% de precisión en clasificación y extracción
• Dentro del 5-10% del modelo API en calidad de generación
• Cumplimiento de formato superior al 98%

Si el modelo ajustado se queda corto:

• Agrega más ejemplos de entrenamiento en las áreas donde tiene bajo rendimiento
• Verifica problemas de calidad de datos (ejemplos mal etiquetados, formatos inconsistentes)
• Prueba un modelo base más grande (7B → 14B)
• Aumenta el rango de LoRA para más capacidad

La mayoría de las brechas de calidad se arreglan con mejores datos, no modelos más grandes.

Fase 3: Validación (Días 46-60)

Semana 7-8: Despliegue en sombra

Despliega tu modelo ajustado junto a la API. Enruta todo el tráfico de producción a través de ambos modelos, pero solo sirve la respuesta del modelo API a los usuarios.

Compara salidas en tiempo real:

• Registra ambas respuestas para cada solicitud
• Marca desacuerdos para revisión humana
• Rastrea métricas de calidad sobre tráfico de producción real (no solo rendimiento del conjunto de prueba)
• Monitorea casos límite que no aparecieron en tus datos de entrenamiento

El despliegue en sombra captura problemas que la evaluación estática no detecta:

• Cambios en distribución de entrada (patrones de tráfico real difieren de datos de entrenamiento)
• Casos límite raros (entradas que tu conjunto de prueba no cubrió)
• Variaciones de formato (los usuarios no siempre escriben como tus ejemplos de entrenamiento)

Semana 8-9: Prueba A/B

Una vez que el despliegue en sombra confirma paridad de calidad, ejecuta una prueba A/B real:

• Enruta 10-20% del tráfico de producción al modelo ajustado
• Sirve la respuesta del modelo ajustado a esos usuarios
• Compara métricas de negocio: satisfacción del usuario, tasa de completación de tareas, tasa de errores
• Expande a 50% si las métricas se mantienen
• Monitorea por al menos una semana completa en cada porcentaje de tráfico

Criterios de decisión para proceder:

• Calidad dentro del 5% del modelo API en tus métricas clave
• Sin aumento en quejas de usuarios o reportes de errores
• Cumplimiento de formato superior al 95%
• Latencia dentro del rango aceptable para tu aplicación

Comienza tu migración de 90 días. Ertas maneja las partes más difíciles — preparación de dataset, entrenamiento, evaluación, exportación GGUF — todo en una interfaz visual. Pre-suscríbete a precio early-bird →

Fase 4: Expansión (Días 61-90)

Semana 9-10: Migración a producción para la tarea piloto

Con la prueba A/B validada, enruta el 100% del tráfico de tu tarea piloto al modelo ajustado.

Checklist de migración:

• Exporta modelo a formato GGUF
• Despliega en tu infraestructura de inferencia de producción (Ollama, vLLM o llama.cpp)
• Configura monitoreo y alertas para métricas de calidad
• Mantén fallback a API (mantén la integración API activa pero inactiva — puedes volver a enrutar si es necesario)
• Actualiza tu documentación y runbooks

Mide el impacto:

• Reducción de costo mensual (disminución de factura API)
• Mejora de latencia (la inferencia local es típicamente más rápida)
• Mejora de confiabilidad (sin dependencia de uptime de API externa)
• Métricas de calidad (deberían mantener los niveles validados durante la prueba A/B)

Semana 11-12: Comienza la siguiente migración

Aplica el mismo proceso a tu segunda tarea de mayor prioridad. Esto va más rápido porque has construido el conocimiento institucional:

• Tu pipeline de datos está establecido
• Tu framework de evaluación existe
• Tu infraestructura de despliegue está corriendo
• Tu equipo entiende el flujo de trabajo de fine-tuning

Tiempo típico para migraciones subsecuentes: 3-4 semanas (versus 6 semanas para la primera).

Semana 12: Establece cadencia continua

Configura los sistemas que mantienen tus modelos ajustados actualizados:

Programa de reentrenamiento. A medida que tu negocio evoluciona, tus modelos necesitan actualizaciones. El reentrenamiento mensual o trimestral con datos frescos mantiene el rendimiento alto. Usa tus logs de producción como nuevos datos de entrenamiento — las propias salidas del modelo (validadas por humanos) alimentan el entrenamiento futuro.

Monitoreo de calidad. Rastrea métricas de precisión de forma continua. Configura alertas para degradación de calidad. Si la precisión cae por debajo de tu umbral, activa un ciclo de reentrenamiento.

Gestión de versiones. Mantén versiones anteriores del modelo disponibles para rollback. Rastrea qué versión del modelo está desplegada en cada ambiente.

Errores comunes (y cómo evitarlos)

Error 1: Intentar migrar todo a la vez

El error: Pasar semanas construyendo un plan de migración elaborado para las 8 tareas de IA, luego intentar ejecutar en paralelo.

La solución: Envía una migración primero. Aprende de ella. Aplica esos aprendizajes a la siguiente. Lo secuencial supera lo paralelo cuando estás construyendo nueva capacidad organizacional.

Error 2: Calidad insuficiente de datos de entrenamiento

El error: Volcar 10,000 logs de API crudos en un dataset de entrenamiento sin revisión. Los logs incluyen salidas incorrectas, formatos inconsistentes y casos límite que el modelo API manejó pobremente.

La solución: Invierte más tiempo en curación de datos y menos en volumen de datos. Revisa ejemplos. Elimina los malos. Asegura consistencia de formato. Un dataset curado de 800 ejemplos supera a un dataset sin revisar de 5,000.

Error 3: Saltarse el despliegue en sombra

El error: Pasar directo de evaluación en conjunto de prueba a despliegue en producción. El conjunto de prueba no captura la distribución completa de entradas del mundo real.

La solución: Siempre despliega en sombra. Siempre haz pruebas A/B. Las 2-3 semanas extra de validación previenen incidentes de producción que toman más de 2-3 semanas en recuperarse.

Error 4: Optimizar para la métrica incorrecta

El error: Perseguir 99% de precisión cuando tu modelo API solo logra 85%. El modelo ajustado logra 92% — mejor que la API — pero el equipo sigue iterando porque no es "perfecto."

La solución: Tu benchmark es el modelo API actual, no la perfección teórica. Si el modelo ajustado iguala o supera a la API en tus métricas, esa es una migración exitosa.

Error 5: Olvidar el fallback

El error: Eliminar la integración API después de migrar al modelo ajustado. Tres meses después, necesitas reentrenar el modelo y no tienes fallback durante la ventana de entrenamiento.

La solución: Mantén la integración API inactiva. No estás pagando por ella si no la estás llamando. Pero tenerla disponible para emergencias — incluso brevemente — vale el costo mínimo de mantenimiento.

El atajo de Ertas

El playbook anterior funciona con cualquier cadena de herramientas de fine-tuning. Pero gran parte del trabajo manual — aprovisionamiento de GPU, configuración de entrenamiento, formateo de dataset, exportación GGUF — puede comprimirse con la plataforma correcta.

Con Ertas, las Fases 2-3 se comprimen significativamente:

• Subida de dataset reemplaza la preparación manual de JSONL (o usa el editor visual)
• Entrenamiento con un clic reemplaza la configuración de GPU, archivos de configuración y scripts de monitoreo
• Evaluación incorporada reemplaza pipelines de evaluación personalizados
• Comparación lado a lado entre experimentos reemplaza el rastreo manual
• Exportación GGUF reemplaza cadenas de herramientas de cuantización

Una migración que toma 6 semanas con herramientas manuales puede comprimirse a 2-3 semanas con una plataforma integrada. Las partes más difíciles — aquellas donde los equipos se atascan — son exactamente las partes que la plataforma maneja.

Después de 90 días

Al final de este playbook, deberías tener:

• 1-2 tareas de producción corriendo en modelos ajustados que te pertenecen
• Ahorros de costos comprobados documentados y cuantificados
• Un framework de evaluación listo para futuras migraciones
• Infraestructura de despliegue corriendo y monitoreada
• Una lista priorizada de las siguientes tareas a migrar
• Conocimiento institucional del flujo de trabajo de fine-tuning

Ya no eres completamente dependiente de API. Eres dueño de capacidades de IA críticas. Tus costos son más predecibles. Tu producto es más resiliente.

Y la próxima vez que un proveedor de IA envíe un aviso de depreciación o un cambio de precios, tendrás opciones — no solo obligaciones.

---

Comienza tu migración. Ertas maneja todo el pipeline — de dataset a GGUF — en una interfaz visual, sin código requerido. Pre-suscríbete a precio early-bird. Ver planes →