Migración
Migrar sin migrar: qué es una API compatible con OpenAI
Cuando una pyme valora mover su IA de la nube a sus propias oficinas, la objeción que de verdad frena la decisión casi nunca es el hardware. Es esta frase: "tendré que rehacer todas mis integraciones". El chatbot interno, el clasificador de correos, los flujos de trabajo en n8n, los scripts que ya funcionan. La buena noticia es que esa fricción es, en la mayoría de los casos, imaginada. Existe un estándar de facto que hace que migrar se parezca menos a una mudanza y más a cambiar dos líneas de configuración.
El miedo: rehacerlo todo
Tras un par de años usando IA en la nube, cualquier empresa acumula piezas: un asistente interno conectado al ERP, un extractor de datos de facturas, resúmenes automáticos de reuniones, algún flujo de trabajo en n8n o Make. Cada pieza costó horas de desarrollo y de pruebas, y nadie quiere volver a abrir código que ya funciona. Ese es el motivo real por el que muchas pymes siguen pagando APIs en la nube aunque su situación haya cambiado: no es una decisión, es no haber tomado ninguna. El statu quo gana por defecto.
Pero conviene mirar qué hay escrito de verdad en ese código. En casi todos los casos: una llamada HTTP a una ruta concreta, con un JSON en un formato concreto. Nada más. Y ahí está la clave.
Qué significa compatible con OpenAI
La API de OpenAI se ha convertido en el estándar de facto del sector. Sus rutas (/v1/chat/completions, /v1/embeddings, /v1/models) y su formato de petición (una lista de mensajes con roles, parámetros como temperature o max_tokens, respuestas en streaming) son hoy la lengua común de las aplicaciones con LLM. Por eso los servidores de inferencia de código abierto más usados, como vLLM u Ollama, exponen exactamente esa misma interfaz.
La consecuencia práctica: tu código no habla "con OpenAI", habla un formato. El SDK oficial acepta un parámetro base_url. Frameworks como LangChain o LlamaIndex, y herramientas como n8n, permiten apuntar a un endpoint propio. Un servidor local que implementa ese formato es, para tus integraciones, indistinguible del original.
La migración típica: URL, clave y nombre de modelo
La migración típica toca tres cosas. Uno: la URL base, que pasa de api.openai.com al servidor de tu oficina. Dos: la clave de API, que ahora emites tú y ya no viaja fuera de tu red. Tres: el nombre del modelo, porque el alias de la API externa se convierte en el checkpoint abierto que hayas desplegado, como Qwen3.8-27B o DeepSeek V4 Flash 0731.
Ni la lógica de negocio, ni los prompts, ni la gestión de errores, ni el streaming cambian: los mismos reintentos, los mismos parsers de respuesta. Si tu integración usa el SDK o un framework estándar, el cambio real son dos variables de entorno y un nombre de modelo.
Dónde sí hay trabajo real
Ahora la parte honesta: hay casos donde sí hay trabajo, y conviene identificarlos antes de decidir.
Primero, las funciones propietarias del proveedor. Si dependes de la Assistants API, de los almacenes de ficheros gestionados, de la búsqueda web integrada o de la API de voz en tiempo real, eso no es el formato estándar, es producto del proveedor. Todo tiene equivalente con modelos abiertos (un RAG propio, herramientas propias), pero es desarrollo, no un cambio de URL.
Segundo, la dependencia de un modelo concreto. Un prompt afinado durante meses contra un modelo específico puede comportarse distinto en otro. Las llamadas a funciones y las salidas estructuradas varían en calidad según el modelo. Esto no se resuelve con fe: se resuelve con un conjunto de pruebas construido con tus casos reales y ejecutado contra el modelo candidato antes de migrar nada.
Tercero, el tamaño. Qué modelo abierto puede sustituir al que usas depende de la memoria disponible en el equipo; en la guía de qué GPU necesita tu empresa explicamos las cuentas.
Probar en paralelo antes del cambio
La ventaja de una API compatible es que permite probar sin apostar. El procedimiento sensato: mantén la nube funcionando, levanta el endpoint local y apunta a él un entorno de pruebas. Reproduce con él peticiones reales de los últimos meses, compara respuestas, mide latencia y tasa de acierto en tus casos, no en benchmarks genéricos.
Cuando un flujo de trabajo pasa las pruebas, se migra ese flujo, no todos a la vez. Y el plan de vuelta atrás es el mismo mecanismo: si algo falla, restauras la URL y la clave anteriores y estás donde estabas. La misma propiedad que hace fácil entrar hace fácil salir. Migrar deja de ser un salto al vacío y se convierte en una serie de cambios pequeños y reversibles.