IA local: cuándo conviene no mandar el dato a la nube
Correr el modelo en tu máquina resuelve una sola cosa, y la resuelve del todo. Cuando vale la pena, qué sigue costando cuando la licencia es gratis, y la regla de decisión en una tabla.
«Correr el modelo en local» suena a decisión de infraestructura y en realidad es una decisión sobre datos. La pregunta no es qué máquina tenés: es si la información con la que estás trabajando debería salir de tu empresa o no.
Lo hacemos para parte de nuestro trabajo interno y lo documentamos públicamente — cómo montar el modelo y cómo usarlo como subagente están escritos paso a paso. Este artículo es lo que viene antes de esas guías: cuándo vale la pena.
Que resuelve, y que no
Resuelve exactamente una cosa, y la resuelve del todo:
- El dato no se mueve. No hay tercero, no hay transferencia internacional que informar, no hay términos de servicio que revisar cada vez que cambian, no hay una copia en un sistema que no controlás.
Y no resuelve ninguna de estas, aunque se le atribuyan seguido:
- No hace que la salida sea correcta. Un modelo local se equivoca igual, y a veces más. La revisión humana sigue siendo obligatoria en lo que importa.
- No te da una base de licitud. Tratar datos personales sigue necesitando un fundamento, corra donde corra el modelo.
- No te exime de contarlo. Si procesás datos de tus clientes con IA, eso va en tu política de privacidad aunque el servidor esté debajo de tu escritorio.
Cuando el dato no deberia salir
En la mayoría de las tareas la respuesta correcta no es «local»: es mandar menos. Si podés quitar las identidades y el modelo sigue resolviendo, el problema desapareció y no hiciste nada raro.
El caso de correr local aparece cuando eso no alcanza. Típicamente:
- La tarea es leer el registro completo. Revisar contratos, analizar historiales, procesar documentación con datos de personas. Reducir el dato es reducir la tarea.
- El volumen convierte lo excepcional en sistemático. Mandar un documento una vez es una decisión; mandarlos todos, todos los días, es una arquitectura.
- El cliente lo puso por contrato. Pasa cada vez más en salud, legal y finanzas: el dato no sale de la infraestructura, y punto.
- Es material tuyo que no querés entregar. Código propietario, estrategia, números sin publicar. Acá no hay obligación legal de por medio, solo criterio.
El costo real no es la licencia
Los modelos abiertos no se pagan, y eso hace que el cálculo parezca obvio. No lo es: el costo se mudó de lugar.
- Memoria. Es la restricción que manda. Un modelo tiene que entrar entero en memoria para correr con soltura, y eso —más que la velocidad del procesador— define qué podés usar.
- Tiempo. Genera más lento que un servicio comercial. En una tanda que corre de fondo da igual; en algo que alguien está esperando, no.
- Mantenimiento. Actualizaciones, configuración, cosas que se rompen. Sin alguien que lo sostenga, el modelo local se convierte en una herramienta que nadie usa.
- Techo de capacidad. En el razonamiento más difícil un modelo local rinde por debajo del mejor comercial del momento. Negarlo lleva a decepciones evitables.
La conclusión útil no es «no conviene», es no conviene para todo. Y como el cómputo propio no se factura por uso, hay una asimetría a favor: probar con un modelo más capaz antes de asumir que ninguno puede solo cuesta tiempo.
Que tareas rinden bien en local
El patrón que vemos: rinde donde la tarea está acotada y el criterio es mecánico.
- Transformar texto de un formato a otro.
- Resumir documentos largos siguiendo una estructura fija.
- Clasificar y etiquetar en categorías que vos definiste.
- Extraer campos de documentos con forma conocida.
- Borradores largos que después alguien edita.
Y rinde mal donde hay que llevar la cuenta de muchas cosas a la vez, o donde una equivocación sutil pasa desapercibida. Las cifras agregadas son el ejemplo canónico: un modelo puede razonar bien sobre un conjunto de datos y equivocarse al sumarlo. Los agregados se calculan con código, no con lenguaje — y eso vale para cualquier modelo, local o no.
Una regla que se aplica en diez segundos
| Si el dato es... | Y la tarea es... | Entonces |
|---|---|---|
| Publico o anonimo | Cualquiera | Modelo comercial, sin vueltas |
| Identificable pero reducible | Acotada | Comercial, mandando solo lo necesario |
| Identificable y necesario entero | Acotada y repetitiva | Local |
| Identificable y necesario entero | De razonamiento dificil | Contrato que lo respalde, o partir la tarea |
La fila que más se salta es la segunda, y es la que resuelve la mayoría de los casos: el dato es identificable, pero la tarea no necesita las identidades. Ahí no hace falta montar nada.
Preguntas frecuentes
- Necesito una maquina especial? Necesitas memoria suficiente para sostener el modelo, que es la restriccion real, mas que la velocidad del procesador. Un portatil actual con RAM generosa corre un modelo mediano; los muy grandes piden hardware dedicado. Verificar si entra es el primer paso, no una consecuencia.
- Un modelo local es tan bueno como uno comercial? En el razonamiento mas dificil, en general no. En trabajo acotado y mecanico suele alcanzar de sobra, y ahi esta la mayor parte del volumen. El error es tratarlos como intercambiables: son herramientas distintas.
- Esto elimina la necesidad de una politica de privacidad? No. Correr el modelo en local elimina la transferencia a un tercero. No elimina la base de licitud, ni la limitacion de finalidad, ni la obligacion de contarle a la gente que haces con sus datos.
- Se puede combinar con un modelo comercial? Suele ser la respuesta correcta. El trabajo sensible o de mucho volumen corre local; el razonamiento dificil va al mejor modelo disponible con el dato ya reducido a lo que necesita.