Durante años, correr modelos de IA dentro de la red propia fue algo que solo tenía sentido para empresas grandes con equipos de infraestructura dedicados. Eso cambió. Los modelos de código abierto alcanzaron niveles de calidad que hace poco solo tenían los modelos comerciales, y el hardware necesario para correrlos se volvió más accesible. Hoy una empresa mediana puede evaluar seriamente si determinado caso de uso debería correr en la nube o en sus propios servidores, y esa decisión merece más criterio que entusiasmo.
El error más frecuente es plantear la pregunta al revés: primero elegir la arquitectura y luego buscarle un uso. "Queremos una solución de IA local" sin tener claro para qué proceso, con qué datos y con qué equipo operándola es una forma segura de terminar con hardware costoso y subutilizado. La pregunta correcta no es nube o local. Es qué problema se está intentando resolver y qué exige ese problema.
Hay cuatro preguntas que ayudan a ordenar la decisión.
¿Qué tan sensibles son los datos? Si el caso de uso involucra contratos, fichas de pacientes, documentos legales, información de planta o datos financieros que no pueden salir de la organización por regulación o política interna, una solución local elimina el riesgo de exposición. Si los datos son operacionales pero no críticos, la nube tiene controles suficientes para la mayoría de los casos.
¿El volumen es estable y predecible? La nube cobra por uso. Algunos casos tienen un volumen alto y constante donde el costo acumulado puede justificar tener el modelo corriendo de forma propia. El caso más claro es el procesamiento de video o imágenes a escala: analizar grabaciones de cámaras de seguridad, revisar material de producción o procesar documentos visuales en volumen puede ser prohibitivamente caro vía API. Para ese tipo de flujos, el costo por llamada se acumula rápido y la solución local pasa a ser económicamente razonable.
¿Necesita baja latencia o funcionar sin conexión? Hay contextos donde depender de internet es un problema operacional real: planta de producción con conectividad limitada, operaciones en terreno, sistemas que no toleran la latencia de una llamada externa. En esos casos una solución local no es una preferencia, es un requisito.
¿El equipo tiene capacidad de operar esto? Este filtro se omite con frecuencia. Correr un modelo localmente implica actualizaciones, monitoreo, gestión de recursos y soporte cuando algo falla. No es una carga enorme, pero tampoco es invisible. Si no hay nadie que pueda hacerse cargo de esa operación, la solución local se convierte en un problema de mantenimiento antes que en un caso de uso funcionando.
En cuanto a qué modelos usar para una solución local, el ecosistema creció bastante. Llama de Meta y Mistral son los más conocidos y tienen versiones para distintos tamaños de hardware. NVIDIA tiene su propia familia de modelos, los Nemotron, optimizados para correr en sus GPUs con buen rendimiento en tareas empresariales. Para casos más especializados, como procesamiento de documentos o análisis de imágenes, hay modelos ajustados para esas tareas específicas. La elección depende del caso de uso, no de una preferencia por uno u otro.
Dicho esto, hay una categoría de casos donde una solución local directamente no tiene sentido: todo lo que tiene que ver con productividad general y ofimática. Si el objetivo es que los equipos redacten mejor, resuman reuniones, generen borradores o trabajen con documentos del día a día, herramientas como Microsoft 365 Copilot, Google Workspace o los planes empresariales de ChatGPT y Claude están diseñadas exactamente para eso, con la integración ya resuelta. Nadie debería construir infraestructura propia para reemplazar ese tipo de funcionalidad. Además, los modelos de frontera avanzan a una velocidad que una solución local no puede seguir: lo que hoy es el mejor modelo disponible para correr en hardware propio en unos meses queda por detrás de lo que ofrecen los proveedores en la nube. Para casos de uso que dependen de la capacidad general del modelo, esa brecha importa.
La solución local tiene sentido cuando hay un proceso específico, datos que no pueden salir de la organización, un volumen que justifica la inversión o una restricción operacional concreta. Fuera de eso, la nube sigue siendo más simple, más actualizada y más fácil de mantener. La decisión correcta no es ideológica, es la que sirve mejor al caso de uso que se está resolviendo.
