IA local en aplicaciones .NET MAUI: modelos en el dispositivo, privacidad y coste cero por token

Hasta hace poco, añadir IA generativa a una aplicación móvil significaba casi siempre enviar una petición a un servicio remoto, esperar la respuesta y pagar por los tokens consumidos. Microsoft Build 2026 puso otra opción en primer plano para .NET MAUI: ejecutar modelos y capacidades de IA en el propio dispositivo.

No es solamente una forma de ahorrar. Si el caso de uso encaja, la IA local permite trabajar sin conexión, reduce la exposición de datos sensibles y evita que la latencia de red forme parte de la experiencia. Pero también traslada a la aplicación responsabilidades que antes asumía el proveedor de la API: compatibilidad de hardware, descarga del modelo, memoria, batería, actualizaciones y calidad de las respuestas.

Qué anunció Microsoft y qué conviene matizar

En el resumen oficial de .NET en Microsoft Build 2026, Microsoft destacó la sesión Taking your AI to the edge with .NET MAUI: modelos locales y capacidades en el dispositivo para aplicaciones móviles y de escritorio, con impacto en privacidad, rendimiento y experiencia de usuario.

La palabra importante es edge, pero la segunda más importante es preview. El propio anuncio avisa de que muchas de las características mostradas forman parte de previews de .NET 11. Además, MAUI aporta la interfaz y el código compartido, pero no convierte mágicamente todos los modelos locales en multiplataforma. El proveedor real depende del sistema operativo y del hardware.

En Windows, el ejemplo más directo es Phi Silica, el modelo de lenguaje local expuesto mediante Windows AI APIs. Microsoft proporciona incluso un tutorial específico para .NET MAUI. En la versión documentada al preparar este artículo se requieren Windows 11 25H2, Windows App SDK 2.0 preview, un equipo compatible y un token de acceso limitado (LAF). Son requisitos de preview, no una base que debamos ocultar al lector.

Qué significa realmente ejecutar IA en el dispositivo

Una aplicación MAUI puede consumir capacidades locales de varias formas. El sistema operativo puede proporcionar un modelo ya optimizado para el hardware; la aplicación puede distribuir su propio modelo; o puede descargarlo después de la instalación. También puede apoyarse en motores de inferencia como ONNX Runtime para ejecutar modelos compatibles.

Cada enfoque cambia el reparto de responsabilidades. Si el modelo lo proporciona la plataforma, la descarga, la optimización y parte de las actualizaciones pueden quedar en manos del sistema operativo, pero la aplicación depende de dispositivos y versiones concretos. Si distribuimos nuestro propio modelo, ganamos control y portabilidad a cambio de aumentar el tamaño, las pruebas y el mantenimiento.

Por eso no existe una única “IA local para MAUI”. MAUI comparte la interfaz, la navegación y buena parte de la lógica, mientras que la capa de inferencia puede variar entre Windows, Android, iOS y macOS. El diseño debe contemplar esa diferencia desde el principio.

Una arquitectura preparada para local, nube o ambas

La interfaz de usuario no debería conocer el modelo concreto ni la tecnología que lo ejecuta. Conviene definir una capacidad —resumir, clasificar, extraer entidades o generar texto— y proporcionar una implementación adecuada para cada plataforma.

Microsoft.Extensions.AI ofrece abstracciones como IChatClient para desacoplar el consumo del proveedor. También podemos usar interfaces propias cuando la tarea sea más específica que una conversación. Esta separación permite cambiar un modelo local, recurrir a una API remota o aplicar una estrategia híbrida sin reescribir la pantalla.

La aplicación también necesita detectar capacidades en tiempo de ejecución. No basta con comprobar el sistema operativo: pueden influir la arquitectura, la memoria disponible, la NPU o GPU, la versión del sistema y si el modelo está instalado. Cuando la capacidad no exista, la experiencia debe degradarse de forma comprensible: desactivar la función, ofrecer una alternativa remota con consentimiento o explicar qué requisito falta.

El primer uso también forma parte de la experiencia

Un modelo local puede estar incluido en la instalación, pero también puede requerir una descarga inicial considerable. La aplicación debería informar del tamaño, pedir confirmación, mostrar el progreso y permitir posponerla. Asimismo, debe contemplar falta de espacio, descarga interrumpida, actualización del modelo y eliminación posterior por parte del usuario.

Esta preparación inicial no genera una factura por tokens, pero sí tiene un coste para el usuario en tiempo, almacenamiento y datos móviles. Ocultarlo detrás de un indicador de actividad indefinido sería una mala experiencia, aunque la inferencia posterior sea rápida y privada.

Privacidad: mejora real, pero no automática

Si la inferencia se ejecuta completamente en el dispositivo, el prompt y la respuesta no tienen que salir de él. Esto resulta especialmente valioso para notas personales, documentos internos, historiales, datos recogidos en campo o aplicaciones que deben funcionar sin conexión.

Sin embargo, “modelo local” no equivale por sí solo a “aplicación privada”. Hay que revisar también:

• la telemetría y los registros de la aplicación;
• las copias de seguridad del sistema operativo;
• los volcados de errores y archivos temporales;
• el historial de conversaciones guardado localmente;
• las funciones auxiliares que sí consulten servicios remotos;
• la procedencia, licencia y cadena de suministro del modelo.

La afirmación correcta no es “la IA local garantiza privacidad”, sino “la IA local permite diseñar un flujo en el que los datos no abandonen el dispositivo”. Después hay que verificar que el resto de la aplicación respeta ese diseño.

Coste cero por token no significa coste cero

Una vez instalado el modelo, generar cien o diez mil resúmenes no produce una factura por tokens. El coste marginal del proveedor desaparece y el presupuesto se vuelve más predecible. Eso puede ser decisivo en aplicaciones con mucho uso, despliegues educativos, herramientas internas o productos con un precio fijo bajo.

Siguen existiendo otros costes: más tamaño de descarga, consumo de almacenamiento, RAM, CPU/GPU/NPU, energía, pruebas sobre distintos dispositivos y mantenimiento de versiones. En algunos escenarios, distribuir y soportar el modelo puede ser más caro que consumir una API ocasionalmente.

Local frente a nube: una decisión de producto

Criterio	Modelo local	API en la nube
Conectividad	Puede funcionar sin conexión	Requiere red
Privacidad	Los datos pueden permanecer en el equipo	Los datos viajan al proveedor
Coste variable	Sin precio por token	Pago por uso o cuota
Calidad máxima	Limitada por tamaño y hardware	Acceso a modelos más grandes
Compatibilidad	Hay que detectar capacidades	Cliente relativamente ligero
Actualización	La gestiona la app o la plataforma	La gestiona el proveedor

Elegiría ejecución local para clasificación, extracción, resumen, reescritura, búsqueda semántica y asistentes acotados cuando la privacidad, el modo sin conexión o el volumen importen más que obtener la máxima calidad posible.

Elegiría la nube para razonamiento complejo, contextos muy grandes, conocimiento reciente, cargas multimodales exigentes o cuando necesite resultados homogéneos en dispositivos modestos.

Y en muchos productos elegiría ambas: una ruta local por defecto y una ruta remota, consentida y visible, para las tareas que realmente la necesitan. No es una derrota de la IA local; es una arquitectura que coloca cada trabajo donde tiene más sentido.

Qué medir antes de publicar

La comparación no debería terminar en “funciona en mi equipo”. Conviene medir, al menos, tiempo hasta el primer token, tokens por segundo, memoria máxima, consumo de batería, tamaño de descarga, temperatura, tasa de errores y calidad con un conjunto fijo de ejemplos. También hay que probar el primer uso, cuando el modelo todavía no está preparado, y la cancelación de una generación larga.

Build 2026 no convierte de golpe la IA local en una opción universal para cualquier aplicación MAUI. Sí marca un cambio importante: el modelo ya no tiene por qué ser siempre un servicio remoto. Con una capa de abstracción, detección de capacidades y expectativas realistas, podemos ganar privacidad, respuesta sin conexión y coste cero por token sin cerrar la puerta a la nube cuando haga falta.