El 75% de las empresas ha lanzado iniciativas de IA generativa y solo el 25% ha conseguido resultados tangibles a escala (BCG, enero 2025). El cuello de botella habitual no está en el modelo, está en la elección de arquitectura: ingeniería de prompts, RAG, ajuste fino (fine-tuning) o un híbrido. Decidir mal compromete coste operativo, latencia, exposición regulatoria y deuda técnica. Este artículo desglosa cuándo cada estrategia es defendible en B2B y qué señales obligan a descartar el ajuste fino.
TL;DR. Tres caminos para llevar un LLM a producción B2B: prompt engineering, RAG y fine-tuning. La decisión no se basa en moda, se basa en volumen y calidad del dato propio, restricción de latencia, exposición regulatoria bajo EU AI Act y disponibilidad de equipo. RAG cubre la mayoría de casos enterprise cuando hay corpus documental cambiante. El fine-tuning justifica su sobrecoste solo con 10.000+ ejemplos limpios y patrones de razonamiento específicos del dominio. La arquitectura híbrida (RAG + fine-tuning ligero) gana tracción en producción. El error caro es saltar de prompt a fine-tuning sin pilotar RAG: reentrenamientos que no escalan y deuda técnica acumulada.
El panorama LLM en B2B: por qué B2C no escala
El ecosistema de modelos de lenguaje ha evolucionado hasta el punto en que no existe una arquitectura única que funcione para todos los casos. La estrategia óptima depende del caso de uso, la calidad de los datos disponibles y los objetivos del proyecto. Lo que funciona para una startup B2C orientada a consumidor masivo suele resultar ineficiente y costoso para una empresa B2B con requisitos de trazabilidad, gobierno y compliance.
Aplicar enfoques diseñados para B2C en contextos B2B genera dos patrones de fracaso recurrentes: sobreinversión en fine-tuning sin haber agotado RAG, y bajocoste en gobernanza que estalla en auditoría. Las decisiones de arquitectura LLM deben basarse en análisis de requisitos y riesgos reales, no en la moda del ciclo de hype.
Costes reales: fine-tuning vs RAG vs prompt engineering
La pregunta operativa de cualquier equipo de plataforma e ingeniería es cuánto cuesta cada enfoque en infraestructura, ingeniería y compliance. El fine-tuning requiere inversión significativamente superior a RAG y prompt engineering, pero el desglose preciso depende del volumen de datos, el modelo base y la arquitectura cloud.
Infraestructura
El fine-tuning demanda GPU dedicada para entrenamiento adicional, almacenamiento de checkpoints y un pipeline de evaluación reproducible. Las cargas de entrenamiento sobre modelos abiertos de 7B-13B parámetros con LoRA o QLoRA reducen el coste de GPU, pero siguen exigiendo arquitectura específica. RAG y prompt engineering tienen inversión inicial muy inferior: RAG necesita vector store y orquestación de recuperación; prompt engineering solo plataforma de servicio.
Ingeniería y MLOps
Aquí se manifiesta la complejidad real del fine-tuning. Diseñar pipelines de datos, validar modelos, gestionar drift y operar reentrenamientos periódicos exige horas significativas de ingeniería senior y un stack MLOps maduro. RAG demanda ingeniería de datos para el corpus y DevOps para la capa de recuperación. Prompt engineering es la opción menos intensiva en recursos técnicos, aunque su techo de calidad es inferior.
Cumplimiento y gobernanza
Cuando el fine-tuning toca datos sensibles, la trazabilidad del dataset y la auditoría del modelo entrenado son requisito bajo EU AI Act y RGPD. La documentación técnica, el control de versiones del dataset y los logs de inferencia añaden carga operativa que conviene presupuestar desde el día uno.
Latencia y operativa
RAG introduce latencia adicional por la recuperación: típicamente entre 200 y 500 ms por consulta en arquitecturas estándar, aunque vector stores optimizados y reranking selectivo pueden bajarla. El fine-tuning mantiene latencia de inferencia baja pero requiere ciclos de reentrenamiento para evitar obsolescencia del modelo.
Tabla comparativa: fine-tuning vs RAG vs prompt engineering
| Estrategia | Coste inicial | Coste operativo | Latencia | Adaptación al dominio | Carga regulatoria | Perfil de equipo |
|---|---|---|---|---|---|---|
| Fine-tuning | Alto | Alto | Baja | Profunda (estilo + razonamiento) | Alta (auditoría dataset) | ML Engineer senior + MLOps |
| RAG | Medio | Medio | Media-alta | Alta (hechos verificables) | Media (gobierno corpus) | Data Engineer + DevOps + ML |
| Prompt engineering | Bajo | Bajo | Baja | Limitada al contexto del prompt | Baja | Prompt Engineer + Data Lead |
Obligaciones regulatorias 2026: EU AI Act y RGPD
Si la organización opera en España o la UE, el despliegue de LLM está sujeto a un marco normativo que entra en fase de aplicación crítica en 2026. Desde el 2 de agosto de 2026, las obligaciones sobre sistemas de IA de alto riesgo del EU AI Act son plenamente aplicables. Las multas escalan según la infracción: hasta 35 M€ o el 7% de la facturación anual global por prácticas prohibidas; hasta 15 M€ o el 3% por incumplimiento de obligaciones de alto riesgo; hasta 7,5 M€ o el 1% por información incorrecta a autoridades. El RGPD sigue siendo obligatorio para cualquier dato personal en el ciclo de entrenamiento e inferencia.
Obligaciones EU AI Act relevantes para LLM
- Clasificación del sistema según nivel de riesgo (inaceptable, alto, limitado, mínimo).
- Documentación técnica del modelo, dataset de entrenamiento y proceso de evaluación.
- Transparencia sobre uso de IA frente al usuario final.
- Evaluación de impacto cuando el sistema afecte a derechos fundamentales.
- Registro en la base de datos UE para sistemas de alto riesgo.
RGPD aplicado a entrenamiento e inferencia
Más allá del AI Act, el RGPD exige trazabilidad de datos personales en el pipeline, base legal explícita para el tratamiento, principios de limitación de finalidad y minimización. El fine-tuning sobre datos personales sin anonimización defendible es una de las exposiciones más comunes en proyectos B2B mal diseñados.
La interpretación de obligaciones regulatorias debe validarse con asesoría legal específica para el sector y tipo de dato. Este artículo aporta marco general, no dictamen jurídico.
Deuda técnica antes de escalar LLM
Antes de invertir en un proyecto LLM ambicioso, conviene auditar la infraestructura existente. Muchas organizaciones descubren tarde que sus plataformas de datos heredadas no escalan a producción de IA. IBM (2024) reporta que el 41% del nuevo código comercial en IA es generado por IA, lo que incrementa la deuda técnica en un 39% si no se gestiona con revisión humana sistemática.
Diagnóstico de plataformas heredadas
Auditoría honesta de la infraestructura: qué sistemas son compatibles con arquitectura moderna de IA, dónde hay cuellos de botella en la integración de datos, qué componentes exigen reemplazo o modernización. El objetivo es evitar que el proyecto LLM herede los problemas estructurales del stack actual.
Modernización incremental
Plan de modernización realista: migración hacia arquitecturas modulares y escalables, automatización y monitorización como prioridad, retirada gradual de sistemas que actúen como obstáculos. La modernización incremental reduce riesgo operativo frente al rediseño completo.
Enfoque híbrido: cuándo combinar RAG y fine-tuning
Una tendencia consolidada en producción B2B es la combinación de enfoques. Las arquitecturas híbridas usan fine-tuning para ajustar estilo, formato y patrones de razonamiento del dominio, y RAG para fundamentar respuestas en hechos verificables y actualizables. La literatura técnica de IBM Research sobre RAG describe casos donde el híbrido supera tanto a fine-tuning puro como a RAG aislado en tareas específicas del dominio.
Ventajas y compromisos
La ventaja: mayor precisión y adaptabilidad sin pagar el coste completo del fine-tuning puro, con la flexibilidad de actualizar el corpus sin reentrenar. El compromiso: latencia operativa adicional, complejidad de integración entre orquestación de recuperación y modelo ajustado, y necesidad de coordinación entre los equipos que mantienen el corpus y los que mantienen el modelo.
Brecha de talento: ML Engineering senior en España
La adopción de LLM en B2B choca con una restricción que el presupuesto no resuelve: la oferta de ingeniería senior de ML, MLOps y AI Application Engineering en España es estructuralmente baja. Esta brecha es uno de los motores del implementation gap del 75% (BCG, enero 2025): proyectos con presupuesto y patrocinio que no encuentran capacidad de ejecución.
Estrategias de mitigación
- Upskilling del equipo actual en RAG, evaluación de modelos y prompt engineering avanzado: el horizonte de retorno es 6-12 meses.
- Capacidad de ejecución certificada en IA aplicada incorporada como blended team (talento senior + agentes IA orquestados) para el último tramo del proyecto, donde la mayoría de iniciativas se atasca.
- Capa Builder (AI Application Engineering: LLM, RAG, agentes en producto) cuando el reto es construir la aplicación IA; capa Integrator (AI Systems Engineering) cuando el reto es integrar el LLM con el stack enterprise existente y resolver el compliance.
Lista de verificación antes de comprometer fine-tuning
Antes de aprobar presupuesto de fine-tuning, el proyecto debe responder afirmativamente a estos cinco puntos:
- ¿Existen 10.000+ ejemplos de alta calidad y representativos del dominio?
- ¿Está cuantificado el retorno esperado en un horizonte de 18-24 meses?
- ¿El riesgo regulatorio es gestionable y completamente auditable (dataset + modelo + inferencia)?
- ¿La deuda técnica de la plataforma de datos está bajo control?
- ¿Hay capacidad senior interna o acceso fiable a equipos externos certificados para sostener reentrenamientos?
Glosario técnico
Fine-tuning (ajuste fino). Entrenamiento adicional de un modelo de lenguaje preentrenado sobre datos específicos del dominio para adaptar su comportamiento.
RAG (Retrieval-Augmented Generation). Arquitectura que combina recuperación de información relevante con generación de texto para producir respuestas fundamentadas en fuentes verificables.
Prompt engineering. Diseño y optimización de instrucciones y contexto para guiar el comportamiento del modelo sin modificar sus parámetros.
MLOps. Prácticas y herramientas para el despliegue, monitorización y mantenimiento de modelos de ML en producción.
Gobernanza de datos. Marco de políticas, procesos y controles que asegura calidad, seguridad y cumplimiento en el ciclo de vida del dato.
Pasos inmediatos recomendados
- Auditoría de deuda técnica y plataforma de datos. Diagnóstico del estado real de la infraestructura antes de cualquier compromiso LLM.
- Pilotaje comparado RAG vs fine-tuning. Caso de uso real, métricas definidas, baseline honesto.
- Plan de capacidad senior. Identificación de los perfiles ML/MLOps/AI Application Engineering necesarios y la combinación interno + capacidad certificada externa.
Cerrar el implementation gap en proyectos LLM
El 75% de las empresas con iniciativas de IA generativa no llega al resultado en producción (BCG, enero 2025). El factor diferencial no es elegir entre fine-tuning, RAG o prompt engineering: es disponer de capacidad de ejecución certificada para llevar la arquitectura elegida hasta producción sin acumular deuda técnica ni exposición regulatoria.
En Shakers conectamos a equipos de producto y plataforma con talento certificado en skills de IA aplicada (Builder) e integración LLM en stack enterprise (Integrator), incorporado en blended teams con agentes IA orquestados cuando el proyecto lo requiere. Capacidad técnica medible, sin sobreestructura.
Preguntas frecuentes
¿Cuándo compensa el fine-tuning frente a RAG?
Cuando hay un patrón de razonamiento o estilo específico del dominio que el prompt no consigue replicar, y el corpus de entrenamiento supera los 10.000 ejemplos limpios. Si la necesidad es respuestas fundamentadas en documentos cambiantes, RAG es la opción defensible.
¿Qué volumen y calidad de datos exige el fine-tuning?
Mínimo de 10.000 ejemplos representativos del dominio para resultados estables; con LoRA o QLoRA y modelos base abiertos, el umbral puede bajar. Datos ruidosos o sesgados degradan el modelo más que mejorarlo.
¿Cómo impacta el fine-tuning en la gobernanza de modelos?
Exige trazabilidad del dataset, versionado del modelo, logs de inferencia y documentación técnica para cumplir EU AI Act y RGPD. Sin gobierno, el modelo ajustado es una caja negra auditable a posteriori con coste alto.
¿Qué riesgos regulatorios auditar antes del fine-tuning?
Clasificación del sistema bajo EU AI Act, base legal RGPD del dataset, política de retención, evaluación de impacto sobre derechos fundamentales si aplica.
¿Qué perfiles internos son imprescindibles?
ML Engineer senior con experiencia en fine-tuning, MLOps Engineer para pipeline y monitorización, responsable de cumplimiento con experiencia en datos personales y modelos.
¿Cuál es el rango de coste de un proyecto piloto de fine-tuning?
Depende del modelo base, el volumen de datos y el stack cloud. Un piloto sobre modelo abierto con LoRA y dataset moderado puede ejecutarse con presupuesto significativamente inferior al fine-tuning completo sobre modelo propietario. Conviene cotizar contra el caso concreto.
¿Qué latencia añade RAG frente al fine-tuning?
Entre 200 y 500 ms adicionales por consulta en arquitecturas estándar. Optimizaciones como reranking selectivo, caching y vector stores de baja latencia reducen ese margen.
¿Cómo afecta la deuda técnica a la escalabilidad de LLM?
Retrasa integración, multiplica coste de reentrenamientos y compromete fiabilidad en producción. Es el factor que con mayor frecuencia convierte un piloto exitoso en un proyecto no escalable.
