IA en el dispositivo (on-device): qué cambia para privacidad, latencia y UX

La IA en el dispositivo corre el modelo en el teléfono o la computadora: gana privacidad y uso sin conexión, pierde capacidad. El patrón común es híbrido.

info Definición Rápida
La IA en el dispositivo (on-device AI) es ejecutar un modelo de IA directamente en el teléfono, la computadora o un equipo local, sin enviar cada petición a un servidor. Cambia tres cosas para el diseño: la respuesta ya no depende de la red, los datos pueden quedarse en el equipo y la capacidad queda limitada por el hardware, la memoria y la batería.

¿Qué gana y qué pierde?

La documentación de Android resume el balance: ejecutar los prompts de forma local elimina las llamadas a un servidor, mantiene los datos sensibles en el dispositivo, permite el uso sin conexión y reduce el costo de inferencia. Pero la velocidad depende del hardware del equipo, y Gemini Nano tiene límites de tokens y de capacidad del modelo. Apple, por su parte, describe su modelo local como un modelo de 3.000 millones de parámetros, a escala de dispositivo, que no está diseñado para conocimiento general del mundo ni para razonamiento avanzado.

DimensiónEn el dispositivoEn la nube
LatenciaSin viaje por la red, pero depende del chipDepende de la conexión
PrivacidadLos datos pueden quedarse en el equipoLos datos salen del equipo
CapacidadModelos pequeñosModelos grandes
Costo por usoHardware y bateríaPago por petición
ConocimientoLimitado al modelo instaladoActualizable

¿Qué opciones existen en noviembre de 2026?

  • Apple. El framework Foundation Models, presentado en 2025, da a las apps acceso al modelo local de Apple Intelligence. Apple lo describe como inferencia sin costo, disponible sin conexión y que protege la privacidad. Hay que comprobar en tiempo de ejecución si el modelo está disponible, porque solo corre en equipos con Apple Intelligence activado y en regiones soportadas. En junio de 2026 Apple presentó una tercera generación de sus modelos (AFM 3), todavía en periodo beta.
  • Android. Gemini Nano corre en AICore, un servicio del sistema que gestiona la distribución y las actualizaciones del modelo. Las APIs GenAI de ML Kit ofrecen tareas listas como resumen, corrección, reescritura, descripción de imágenes y reconocimiento de voz.
  • Chrome. Según la documentación de Chrome, la Prompt API es estable en la web desde Chrome 148 y usa Gemini Nano. Funciona solo en escritorio, necesita al menos 22 GB libres y más de 4 GB de VRAM, y descarga el modelo la primera vez. Acepta inglés, español, japonés, alemán y francés. Las APIs de traducción, detección de idioma y resumen son estables desde Chrome 138.
  • ExecuTorch. Es el runtime de PyTorch para llevar tus propios modelos a móviles, equipos embebidos y computadoras. Su versión 1.0 salió en octubre de 2025 y Meta la usa en producción en sus apps.

Una consultora de mercado coincide en el diagnóstico: en septiembre de 2026 calificaba a los asistentes, resúmenes, traducción y dictado en teléfonos y computadoras como tareas en producción, y esperaba que la mayoría de los casos de uso fueran híbridos. Revisa las versiones concretas antes de comprometerte con una: el mercado se mueve rápido. Para entender cómo se comparan los tamaños, revisa modelos pequeños vs. grandes.

¿Cómo se diseña un producto híbrido?

El dispositivo atiende lo rutinario y sensible, y la nube atiende lo difícil. Un diseño práctico:

  1. Clasifica las tareas. Cuáles son frecuentes y sensibles, y cuáles son raras y complejas.
  2. Define el umbral de escalamiento. Por ejemplo, si el modelo local tiene baja confianza o si la tarea supera cierto largo.
  3. Avisa al usuario cuándo sale algo del dispositivo. Es una decisión de privacidad, no un detalle técnico.
  4. Diseña el modo sin conexión y el caso sin modelo. No todos los equipos tienen el modelo disponible; define qué hace la app entonces.
  5. Mide por separado. Latencia y calidad en local y en nube, porque el resultado puede diferir.

Ejemplo ilustrativo

Ejemplo ilustrativo: una app de notas médicas para un consultorio quiere resumir las dictaciones del médico. Decide que el resumen corra en el dispositivo, para que el audio no salga del equipo. Cuando la dictación supera cierto largo o el modelo local tiene baja confianza, la app pide permiso antes de enviar el texto a la nube y lo muestra en pantalla. El médico sabe en todo momento qué salió del equipo. El caso es inventado para ilustrar el método.

¿Cómo elegir el tamaño del modelo local?

Empieza por el presupuesto, no por el modelo más grande que quepa. Define tres números antes de elegir: la memoria que puedes ocupar sin afectar al resto de la app, la latencia máxima aceptable para la tarea y el consumo de batería que el usuario tolera en una sesión típica. Con esos números, prueba dos o tres tamaños en dispositivos de gama baja, media y alta, porque la experiencia en un teléfono antiguo puede ser muy distinta a la de uno nuevo.

Mide la calidad de respuesta en esos mismos dispositivos. Un modelo que responde rápido pero resume mal una dictación clínica no sirve, y la calidad solo se ve con casos reales de tu producto. Documenta el tamaño elegido y el dispositivo mínimo soportado, para que el equipo no lo cambie sin medir de nuevo.

¿Cómo comunicar lo que sale del equipo?

La comunicación es parte del diseño, no un texto legal al final. Dile al usuario, con una frase que entienda, qué se procesa en el equipo y qué sale, en qué casos y con qué propósito. Un indicador visible, como un icono o una etiqueta junto a la respuesta, ayuda más que un aviso que se acepta sin leer. La opción de no enviar debe ser tan fácil como la de enviar.

Piensa también en el historial. Si la app guarda resúmenes locales, dile dónde se guardan y cómo se borran. Un usuario que entiende el flujo confía más, y esa confianza es la principal ventaja de correr el modelo en su propio dispositivo.

Errores comunes

  • Prometer privacidad total sin explicar qué sale del equipo en los casos de escalamiento.
  • Suponer que todos los equipos tienen el modelo: sin una alternativa, la función falla en los que no lo soportan.
  • Usar un modelo local grande que agota la batería.
  • Medir solo la latencia y no la calidad de la respuesta.
  • Ocultar el cambio entre local y nube.

Cuándo NO conviene correrlo en el dispositivo

Cuando la tarea necesita conocimiento reciente o razonamiento largo, cuando el dispositivo es muy antiguo o cuando el costo de mantener varios modelos supera el beneficio de privacidad. En esos casos, la nube con buenos controles de datos suele ser la opción más simple. Para pensar en los datos que entran al modelo, revisa privacidad y datos en productos con IA y costo por token.

Fuentes

Preguntas frecuentes

¿Qué es la IA en el dispositivo?
Ejecutar un modelo de IA directamente en el teléfono, la laptop o un equipo local, sin enviar cada petición a un servidor.
¿Qué ventajas tiene frente a la nube?
Los datos pueden quedarse en el equipo, no depende de la red para responder y funciona sin conexión. Su costo es una capacidad menor y la dependencia del hardware, la memoria y la batería del dispositivo.
¿Qué modelos y herramientas existen hoy?
En Apple, el framework Foundation Models da acceso al modelo local de Apple Intelligence. En Android, Gemini Nano corre en el servicio AICore y se usa con las APIs GenAI de ML Kit. En Chrome de escritorio, la Prompt API usa Gemini Nano. ExecuTorch, de PyTorch, sirve para desplegar modelos propios.
¿Cuál es el patrón más común?
Híbrido: el modelo local atiende las tareas rutinarias y sensibles, y la nube resuelve los casos difíciles. Google documenta esa combinación con Firebase AI Logic en Android.