Hay una objeción que aparece en casi todos los diagnósticos que hago, y no es «no sé usar IA».
Es esta: «eso no lo puedo subir».
El expediente de un cliente. Los estados financieros que sustentan un crédito. La base con los datos de las personas a las que le facturas. Gente que sabe exactamente qué proceso quiere quitarse de encima, y que no lo intenta porque el dato que ese proceso necesita no puede salir de su computadora.
Esta semana esa objeción tiene una respuesta distinta.
Qué pasó
Meta liberó Muse Glimmer: un modelo de 30 mil millones de parámetros, con pesos abiertos bajo licencia Apache 2.0, pensado para correr localmente. Los pesos vienen comprimidos a unos 4 bits, lo que deja el modelo por debajo de 20 GB — cabe en una sola tarjeta de 24 GB o en un equipo con memoria unificada tipo Mac.
Y no es solo un modelo que contesta. Está hecho para trabajar como agente: planear varios pasos, llamar herramientas, leer capturas y documentos, y corregirse cuando algo falla.
Por qué esto importa más de lo que parece
Lo interesante no es el tamaño. Es de qué lado de tu red vive el dato.
Cuando usas una herramienta en la nube, tu proceso tiene un requisito que casi nadie escribe: el dato tiene que poder salir. Ese requisito es el que mata la mitad de los proyectos que veo, y se descubre tarde: después de diseñar el flujo, cuando alguien de sistemas dice que no.
Un modelo que corre en tu máquina elimina ese requisito. El expediente no se va a ningún lado. No hay política que negociar porque no hay transferencia que autorizar.
Eso convierte procesos que estaban descartados en procesos que se pueden intentar.
Y ahora la parte que no te van a contar
Que corra en tu laptop no lo hace ni gratis ni sencillo.
Es más débil que los modelos grandes, y Meta lo dice. Muse Glimmer está destilado de un modelo mayor y no pretende igualarlo. Para redactar y clasificar rinde bien; para razonamiento largo y delicado, rinde menos. Si tu proceso es «analiza estos estados financieros y dime si el crédito se sostiene», esto no es el juguete que resuelve eso.
El equipo cuesta. 24 GB de VRAM no es la laptop que te dieron en la oficina. Es una inversión real, y si tu caso no aguanta ese número, la respuesta sigue siendo no.
«Local» no es lo mismo que «permitido». Que el dato no salga de la máquina reduce el riesgo, no lo apaga. Si trabajas con información regulada, instalar un modelo en tu equipo del trabajo sigue siendo algo que tu área de sistemas tiene que saber. La pregunta cambia de «¿puedo subir esto?» a «¿puedo instalar esto?», y esa segunda también tiene dueño.
Cómo lo aterrizo en un proyecto
Si esto te sonó a tu caso, el orden es:
Primero, mide el proceso como está. Minutos por vez, veces por semana, cuántas veces tienes que rehacerlo. Si montas un modelo local sin ese número, en un mes vas a tener una sensación en lugar de un resultado — que es el mismo error de siempre, ahora con hardware más caro.
Segundo, pregunta antes de comprar. «¿Puedo instalar una herramienta que procesa esta información sin enviarla a internet?» Esa frase, a la persona que decide. La respuesta cambia el proyecto entero, y cuesta un correo.
Tercero, empieza por lo revisable. Aunque el modelo viva en tu máquina, la primera tarea que le des tiene que ser una donde tú veas la salida antes de que la vea alguien más. Local no significa desatendido.
Cuarto, compara contra tu número. Dos semanas operando, y la misma medición del primer paso. Si no bajó, el problema no era dónde vivía el dato.
Lo que de verdad cambió
Hasta esta semana, «no puedo subir esa información» cerraba la conversación.
Ahora la abre en otro punto: si el dato no puede salir, ¿cuánto te cuesta hoy ese proceso, y qué tendría que pasar para poder intentarlo en tu propia máquina?
Esa segunda pregunta se puede contestar. La primera no.