Social Rocket
La IA de pesos abiertos resulta cada vez más interesante para los equipos de marketing, porque los modelos no tienen por qué ejecutarse necesariamente a través de ChatGPT, Claude o Gemini. Quien opera los pesos del modelo por sí mismo puede ejecutar tareas recurrentes en su propia infraestructura, controlar mejor los flujos de datos y reducir costes con grandes volúmenes.
Una guía práctica reciente de Social Media Examiner presenta este enfoque como alternativa a las suscripciones de IA y los costes de API, que no dejan de subir. La idea básica tiene sentido, pero con una advertencia importante: pesos abiertos no significa automáticamente gratuito, privado ni mejor. Lo decisivo son la carga de trabajo, el hardware, el alojamiento y la capacidad técnica propia para operarlo.
Qué significa realmente «pesos abiertos»
En un modelo de pesos abiertos, los pesos entrenados del modelo están disponibles. Así, el modelo puede ejecutarse en hardware propio, en una nube privada o con un proveedor de alojamiento especializado.
OpenAI ofrece, por ejemplo, gpt-oss-20b y gpt-oss-120b bajo una licencia Apache-2.0. Según OpenAI, los modelos no están disponibles a través de la API regular de OpenAI, sino pensados para infraestructura controlada por uno mismo o para proveedores externos de alojamiento. El modelo más pequeño está diseñado para entornos con unos 16 GB de memoria; la variante grande se optimizó para poder ejecutarse en una única GPU de 80 GB.
Es importante distinguir los conceptos: pesos abiertos no es automáticamente lo mismo que código abierto completo. Los pesos pueden estar abiertos mientras que los datos de entrenamiento, el código de entrenamiento o partes de la infraestructura de herramientas no se publican.
Para los equipos de marketing, al final importa menos la etiqueta que la pregunta: ¿puede el modelo ejecutar el proceso deseado de forma fiable, rentable y con la protección de datos necesaria?
Dónde los modelos locales empiezan a tener sentido en marketing
La mayor palanca surge en tareas frecuentes y claramente delimitadas. Un modelo de frontera de precio elevado no es necesario para cada paso de procesamiento.
Ejemplos típicos son:
- agrupar grandes cantidades de feedback de clientes o comentarios en redes sociales,
- crear resúmenes e informes recurrentes,
- clasificar o etiquetar textos existentes,
- buscar en bases de conocimiento internas,
- extraer datos estructurados de documentos,
- generar primeras variantes de titulares, metadatos o textos para redes sociales,
- o dejar que los agentes ejecuten pasos parciales sencillos y bien definidos.
Un posible flujo de trabajo híbrido sería, por tanto: un modelo comercial más potente desarrolla la estrategia, los criterios de revisión o un plan complejo. El procesamiento masivo posterior lo asume un modelo de pesos abiertos más económico.
Ya vemos un principio similar con agentes de IA en la compra de medios: en cuanto los agentes ejecutan muchas acciones individuales, la elección del modelo y el control de costes se convierten en parte del propio flujo de trabajo.
Local no significa automáticamente gratuito
Los pesos de un modelo pueden estar disponibles de forma gratuita. Operarlo, no.
Siguen existiendo costes por hardware, electricidad, almacenamiento, tiempo de GPU, alojamiento y mantenimiento. A ello se suma el tiempo de trabajo para actualizaciones, monitorización y corrección de errores.
Por eso un modelo local no es automáticamente más barato que una suscripción de 20 o 30 euros. Para un único responsable de marketing que escribe textos unas cuantas veces al día, un servicio en la nube ya listo suele ser más rentable.
La situación cambia con volúmenes elevados. Si un equipo ejecuta a diario decenas de miles de clasificaciones, resúmenes o extracciones, los modelos locales o los proveedores económicos de inferencia de pesos abiertos pueden resultar rentables. Entonces los costes son más previsibles y dependen menos directamente de cada token de un modelo de frontera.
Los altos ahorros potenciales mencionados en el artículo de Social Media Examiner son experiencias prácticas de usuarios concretos, así que no deben entenderse como una previsión de costes general.
La privacidad es un argumento más fuerte que el precio en sí
Para muchas empresas, lo más interesante no es el precio por token, sino el control sobre dónde se procesan los datos.
OpenAI explica expresamente que, en el caso de los modelos gpt-oss alojados por uno mismo, OpenAI no recibe los datos procesados mientras no se compartan deliberadamente con OpenAI o se procesen a través de un socio de alojamiento gestionado. Un modelo operado íntegramente en local puede, por tanto, mantener los datos sensibles dentro de la propia infraestructura.
Esto es relevante, por ejemplo, para análisis internos de clientes, campañas no publicadas, datos de ventas o bases de conocimiento propietarias.
Aun así, rige lo siguiente: local no significa automáticamente conforme al RGPD. Los controles de acceso, el registro de actividad, los conceptos de eliminación, las bases jurídicas y el tratamiento de datos personales siguen siendo responsabilidad de la empresa. Quien use un proveedor externo de inferencia en lugar de hardware propio también debe revisar de nuevo el tratamiento de datos de ese proveedor.
El mismo principio básico se aplica a las interfaces de IA propias: en nuestra guía sobre ChatGPT, MCP, OAuth y servidores propios explicamos por qué el verdadero límite de seguridad debería estar en el backend y no en el modelo de lenguaje.
Los modelos pequeños pueden bastar para tareas bien definidas
El error de razonamiento más habitual al elegir IA suele ser escoger para cada tarea el modelo más potente disponible.
Para estrategia compleja, investigación difícil o decisiones muy ambiguas, un modelo de frontera puede tener sentido. Para clasificación, extracción o transformaciones estandarizadas, en cambio, esa diferencia de rendimiento suele importar menos.
OpenAI posiciona gpt-oss-20b precisamente para este tipo de entornos con menos recursos. Al mismo tiempo, los modelos de pesos abiertos pueden integrarse en automatizaciones existentes mediante frameworks como Ollama, llama.cpp o vLLM.
Así surge para las empresas una capa adicional de optimización: ¿no solo qué prompt, sino qué modelo recibe qué paso del flujo de trabajo?
Esta pregunta gana importancia cuando la IA pasa de ser un asistente ocasional a un sistema de producción permanente. Nuestro estudio actual sobre el uso de la IA en marketing ya muestra la brecha entre el uso generalizado y una rentabilidad medida con rigor.
Cuándo no suele compensar la IA de pesos abiertos
Para muchos equipos pequeños, un modelo en la nube sigue siendo la opción más práctica. La infraestructura propia no compensa especialmente cuando:
- el volumen de uso es bajo o muy variable,
- siempre se necesita la máxima calidad de modelo,
- nadie puede encargarse de la infraestructura y las actualizaciones,
- o el flujo de trabajo consiste sobre todo en conversaciones creativas puntuales.
Incluso una solución local aparentemente gratuita puede resultar cara si los empleados deben resolver problemas técnicos con regularidad o si los modelos están mal dimensionados.
Por eso, la IA de pesos abiertos es menos un sustituto de ChatGPT o Claude que una capa más dentro del stack de IA.
Un punto de partida sensato: medir primero la carga de trabajo
Antes de que una empresa compre hardware, debería saber qué tareas consumen realmente dinero y tokens.
Una prueba pragmática tiene este aspecto:
- elegir un proceso recurrente y fácil de medir,
- documentar la calidad y los costes del modelo en la nube actual,
- probar el mismo proceso con un modelo de pesos abiertos adecuado,
- comparar la tasa de errores, la velocidad y los costes operativos,
- solo después decidir entre autoalojamiento o migración permanente.
Así, la IA de pesos abiertos deja de ser una decisión ideológica entre «nube» y «local» y se convierte en una cuestión normal de fabricar o comprar.
Para los equipos de marketing, esa es probablemente la tendencia relevante a largo plazo: modelos potentes en la nube para tareas difíciles, modelos más pequeños o autoalojados para el procesamiento repetible y una capa de orquestación que decida qué modelo asume cada trabajo.