Más allá del hype habitual, hay tres direcciones concretas que están cambiando cómo se construyen productos con IA: modelos que corren en el propio dispositivo en vez de depender siempre de una llamada a la nube, modelos que entienden texto, imagen y vídeo a la vez, y sistemas capaces de encadenar acciones de forma autónoma en vez de responder a una sola instrucción. Esto es lo que significa cada una para quien está construyendo software hoy.

Edge AI: privacidad y coste, no solo velocidad

El patrón habitual hasta hace poco era enviar cada petición a una API en la nube (OpenAI, Anthropic, la que sea): hay latencia de ida y vuelta por la red, un coste por token que escala con el volumen, y los datos salen de tu sistema hacia el proveedor.

La alternativa que gana terreno es correr un modelo más pequeño directamente en el dispositivo —un portátil, un teléfono de gama alta, una tablet. Modelos como LLaMA en sus versiones más compactas o Mistral 7B ya son viables en hardware de consumo reciente. Las ventajas son claras: los datos nunca salen del dispositivo (relevante para cualquier cosa sujeta a RGPD, historiales médicos o datos financieros), no hay coste marginal por petición una vez descargado el modelo, y funciona sin conexión.

La barrera principal sigue siendo el tamaño: un modelo de varios GB no cabe cómodamente en cualquier dispositivo, y el hardware de gama baja simplemente no tiene memoria suficiente para ejecutarlo con fluidez. A medida que el almacenamiento y la memoria de los dispositivos de consumo siguen creciendo, esta barrera se va reduciendo.

Modelos multimodales: texto, imagen y vídeo en la misma consulta

Durante un tiempo, cada modalidad vivía en su propio modelo: uno para texto, otro para generar imágenes, otro para transcribir audio. Los modelos multimodales actuales pueden recibir una imagen (o un vídeo) directamente como parte de la consulta y razonar sobre ella junto con el texto.

Un caso de uso muy concreto para quien programa: en vez de describir un bug por escrito y esperar que el modelo lo adivine, puedes enviar directamente una captura de pantalla del error y dejar que el modelo vea exactamente qué está pasando. Esto reduce bastante las idas y vueltas típicas de describir un problema visual con palabras.

Workflows agénticos: de responder a actuar

El patrón clásico es de un solo turno: pides algo, el modelo responde, tú ejecutas los siguientes pasos a mano. Un workflow agéntico invierte esto: le das una tarea con un objetivo final, y el propio sistema decide qué herramientas usar en qué orden —leer archivos, hacer llamadas HTTP, ejecutar código, hacer un commit— hasta completarla, incluyendo corregirse a sí mismo si un paso intermedio falla.

Un ejemplo típico: pedirle a un agente que revise un repositorio, corrija errores de tipado, ejecute los tests, y si pasan, haga commit; si no pasan, que lea el error y lo intente de nuevo. La ventaja frente a una sola llamada de inferencia es precisamente ese bucle de corrección de errores integrado en el propio proceso, en vez de depender de que el humano detecte el fallo y vuelva a pedir ayuda.

Mixture of Experts: eficiencia sin sacrificar calidad

Un modelo "denso" tradicional activa todos sus parámetros en cada petición, lo cual es costoso computacionalmente. La arquitectura Mixture of Experts (MoE) activa solo un subconjunto de parámetros relevantes para cada consulta concreta, mantiendo una calidad comparable o mejor con bastante menos coste de cómputo por petición. Es una de las razones por las que modelos con muchos más parámetros "sobre el papel" pueden ser más rápidos en la práctica que modelos denses más pequeños.

Qué hacer con esto, en términos prácticos

Si construyes una app móvil: vale la pena evaluar una opción de procesamiento local (vía llama.cpp u Ollama) con fallback a la nube cuando el dispositivo no dé para ejecutar el modelo. Ganas privacidad y capacidad offline sin renunciar a la opción cloud cuando haga falta.

Si construyes una app web: ofrecer procesamiento local en el navegador (WebGPU) es cada vez más viable para tareas ligeras, reservando la nube para lo que exige más potencia.

Si construyes un sistema con agentes: empieza con tareas acotadas y verificables (refactors pequeños, análisis de datos con salida estructurada) antes de dar autonomía sobre acciones irreversibles.

Si te preocupa el coste: para volúmenes altos de tareas simples y repetitivas, un modelo local puede salir mucho más barato que pagar por token en la nube; para tareas que exigen el razonamiento más avanzado disponible, la nube sigue siendo la opción con mejor relación calidad-esfuerzo.

El cambio de mentalidad

La pregunta ya no debería ser "¿uso la API de tal proveedor?", sino "¿esto necesita correr en local o en la nube?". Local para lo privacidad-crítico, lo simple y lo que necesita funcionar offline; nube para razonamiento complejo, los modelos más recientes, y cuando la latencia de red no es el cuello de botella. Y en cuanto a interacción: en vez de describir todo por texto, vale la pena aprovechar que los modelos actuales pueden ver imágenes directamente, y en vez de una sola pregunta-respuesta, dejar que un agente itere sobre una tarea completa cuando el caso lo permite.

Fuentes:

• Anthropic — Research
• Google DeepMind