En los últimos dieciocho meses, la pregunta más frecuente de los clientes enterprise ha cambiado de signo. Ya no es «¿podemos usar la IA generativa?», sino una versión mucho más específica: «¿podemos procesar estos documentos sin que salgan de nuestro perímetro?».
Es una pregunta legítima y hoy tiene una respuesta técnicamente sólida para una parte significativa de los casos de uso. La han hecho posible tres factores a la vez: modelos compactos por fin útiles, un tooling que ha madurado hasta el punto de poder gestionarlo un equipo de TI ordinario, y una presión normativa creciente (GDPR, AI Act, NIS2, requisitos sectoriales en sanidad y finanzas) que convierte la frontera del dato en un tema de gobernanza, no de preferencia técnica. Este artículo intenta distinguir la señal del ruido.
Destilación y cuantización, sin mitología
La accesibilidad de los modelos locales se apoya en dos técnicas distintas, a menudo confundidas. La destilación entrena a un modelo «estudiante» compacto para reproducir el comportamiento de un modelo «maestro» mucho más grande: no es una compresión sin pérdidas, es una transferencia selectiva de competencia. El resultado se comporta mucho mejor de lo que su tamaño sugeriría — pero sigue siendo un modelo de entre 3.000 y 8.000 millones de parámetros. La cuantización, en cambio, reduce la precisión numérica de los pesos, típicamente de 16 a 4–5 bit (formatos como GGUF): la ocupación de memoria baja unas cuatro veces, con una pérdida marginal en la mayoría de las tareas aplicativas.
El punto que rara vez se dice es que la degradación no es uniforme. Las tareas acotadas y verificables — extracción de entidades, clasificación, resumen extractivo, normalización de datos — aguantan muy bien; el razonamiento largo de varios pasos y el análisis sobre contextos muy amplios se degradan de forma neta. La consecuencia de diseño es simple: se diseña para la tarea, no para el benchmark. Un modelo de 7B que resuelve bien tres casos de uso definidos vale más que un generalista que resuelve veinte de forma mediocre.
El stack mínimo, y lo que casi siempre falta
El runtime. Ollama se ha impuesto como estándar de hecho para la ejecución local: gestiona descargas, versiones y exposición de los modelos vía API, con una experiencia que recuerda a Docker: excelente para el usuario individual y para los pilotos; para escenarios de servidor multiusuario conviene evaluar desde el primer momento runtimes orientados al throughput como vLLM, porque en producción el cuello de botella no es la memoria, sino las solicitudes concurrentes.
El contexto. Un modelo local, por sí solo, no conoce la empresa: hace falta una capa de retrieval que indexe documentos, wikis y tickets y pase al modelo los fragmentos pertinentes. Implementaciones ligeras como LightRAG hacen esta capa accesible sin infraestructura pesada. Y vale la pena ser explícitos: en gran parte de los proyectos documentales la calidad depende más del retrieval que del modelo — hemos escrito sobre ello en detalle, y es la misma lección que nos ha enseñado nuestra plataforma, construida precisamente sobre estos componentes: Ollama, vLLM, LightRAG.
La adaptación. Herramientas como Unsloth han hecho practicable el fine-tuning con técnicas LoRA/QLoRA en hardware modesto. El consejo operativo, sin embargo, es considerarlo la tercera opción, no la primera: primero el prompt, luego el retrieval, y solo si ambos fallan de forma medible se introduce un artefacto que hay que versionar y volver a poner a prueba con cada cambio de modelo base.
Lo que falta en los tutoriales. Entre un proof of concept y un sistema corporativo hay una capa que no aparece en las guías: identidad y permisos (el índice debe respetar los permisos del usuario), logging, evaluación continua de la calidad, proceso de actualización de los modelos. Aquí es donde se concentra la mayor parte del coste real.
Tres escenarios en los que lo local funciona de verdad
1 · Pre-triaje documental sobre datos reservados. Contratos, expedientes de RR. HH., documentación clínica, expedientes de seguros. El modelo no decide: extrae, clasifica, señala cláusulas anómalas y prepara el trabajo para un revisor humano. El valor está en el tiempo de lectura ahorrado; el riesgo es contenido porque el output siempre se verifica.
2 · Búsqueda semántica sobre el patrimonio interno. Actas, documentación técnica, histórico de tickets: recuperación en lenguaje natural sobre archivos que ya nadie logra navegar por carpetas. También aquí el grueso lo hace el retrieval; el modelo sintetiza.
3 · Asistencia al desarrollo en entornos aislados. Defensa, infraestructuras críticas, entornos certificados: el código propietario no sale del repositorio y a menudo la red hacia el exterior simplemente no existe. Aquí lo local no es una optimización — es la única opción.
Se añade un cuarto escenario en crecimiento: la operativa en el edge — obras, plantas, sitios remotos — donde la conectividad es intermitente y la fiabilidad cuenta más que la calidad marginal de la respuesta.
Dónde no conviene lo local
La honestidad en este punto distingue una evaluación técnica de una campaña de marketing. El razonamiento extenso — análisis comparativos complejos, síntesis sobre decenas de documentos heterogéneos, texto de calidad editorial — sigue siendo territorio de los modelos frontier, y la brecha no se cierra con la cuantización. Las cargas multiusuario no dimensionadas: un modelo que responde en dos segundos en el portátil puede tardar veinte con diez solicitudes concurrentes; se dimensiona sobre el throughput, no sobre la memoria. Y el coste total oculto: un modelo local sin actualizar es deuda técnica — hacen falta reevaluaciones periódicas, tests de regresión y alguien que se ocupe de ello. Por debajo de cierto umbral de volumen, la API sigue siendo con diferencia más económica que la gestión interna.
Dimensionar el hardware: reglas prácticas
- Regla empírica: para un modelo cuantizado a 4 bit, los GB de memoria necesarios son aproximadamente los miles de millones de parámetros × 0,6 — más el espacio para la ventana de contexto.
- Apple Silicon: la memoria unificada ayuda — con 16 GB se gestionan modelos 7–8B, con 32–64 GB se sube a 14–32B.
- GPU dedicada: 8–12 GB de VRAM cubren bien la franja 7–8B a velocidad interactiva.
- Solo CPU: adecuada para los procesamientos batch nocturnos, mucho menos para la interacción síncrona.
- Servidor compartido: una GPU de 24–48 GB sirve a una decena de usuarios concurrentes con modelos 7–8B. Por encima de las veinte personas es casi siempre más eficiente — también en la gestión — que la instalación en cada endpoint.
Tres preguntas para decidir (y la arquitectura que resulta)
Tres preguntas, en este orden: ¿puede el dato salir del perímetro? (pregunta organizativa antes que técnica); ¿la tarea es acotada y verificable? (si no se sabe decir qué es una respuesta correcta, ninguna infraestructura salvará el proyecto); ¿el volumen justifica la infraestructura? (por debajo de ciertos umbrales la API es la elección racional).
En la mayoría de los casos la respuesta no es binaria, y la arquitectura más sensata es híbrida: una capa de enrutamiento que dirige las solicitudes sobre datos reservados hacia el modelo local — en el perímetro dedicado — y todo lo demás hacia el cloud, con políticas explícitas y trazables. La soberanía sobre el dato se convierte en una propiedad del sistema, no en una renuncia funcional.
Un itinerario de adopción en 90 días
Semanas 1–3 · Perímetro. Clasificación de los datos y selección de dos casos de uso reales, cada uno con un referente de negocio. Semanas 4–8 · Prueba sobre el terreno. Prototipo funcional y, sobre todo, un set de evaluación: 30–50 casos reales con la respuesta esperada — la inversión más subestimada, la que distingue una medida de éxito de una impresión. Semanas 9–12 · Piloto. Despliegue a 10–20 usuarios, métricas, decisión documentada: ampliar, corregir o parar.
En síntesis
La IA local no sustituye al cloud y no es una respuesta universal. Resuelve de forma elegante una clase de problemas bien definida: el dato no puede moverse, la tarea está acotada, la verificabilidad cuenta más que la brillantez. Para esa clase — que en las organizaciones reguladas es todo menos marginal — la tecnología está madura, corre en hardware que a menudo ya está en la empresa y se evalúa en un trimestre con una inversión contenida. El resto, como siempre, es una cuestión de arquitectura: si quieres plantearla con un mínimo de seriedad, hablemos.
