IA en el dispositivo en apps móviles: la guía de 2026

Anna Kowalski Senior Mobile Engineer, YuSMP Group · Funciones de IA en iOS, Android y multiplataforma desde 2015

Resumen: ¿qué es la IA en el dispositivo en 2026?

• La IA en el dispositivo lidera la agenda móvil de 2026 por una razón concreta: hace que las funciones sean privadas por defecto, instantáneas y capaces de funcionar sin conexión, sin coste de API por solicitud.
• Ahora las plataformas le dan el modelo. Apple Intelligence abre sus Foundation Models en el dispositivo a cualquier app de iOS, y Google expone Gemini Nano mediante AICore en Android. Ya no necesita un equipo de ML para ejecutar un modelo local.
• Trátelo como híbrido, no como una cosa o la otra. Un modelo pequeño en el dispositivo cubre el 80 % habitual y sensible para la privacidad: resúmenes, respuestas inteligentes, clasificación, transcripción, enmascaramiento de datos. Todo lo más difícil escala sin que se note a un modelo en la nube.
• Lo difícil es la cola de dispositivos, no el modelo. Un teléfono de gama alta ejecuta con comodidad un modelo de 3B parámetros. Un Android de gama media de hace tres años, no. Eso lleva la detección del nivel del dispositivo y una alternativa controlada a la arquitectura, no a la columna de lo deseable.
• Para una función concreta, calcule aproximadamente 4–8 semanas y €25–60k. La partida más grande es el QA en hardware real. Consulte nuestro servicio de desarrollo de apps móviles para ver cómo lo hacemos.

¿Qué significa realmente «IA en el dispositivo» en 2026?

La IA en el dispositivo (también se la llama IA en el edge o inferencia local) significa que el modelo se ejecuta en el propio silicio del teléfono y no en un servidor al que se llega por la red. Ese silicio es el Neural Engine de Apple, la NPU Hexagon de Qualcomm o el Tensor de Google. Las consecuencias prácticas explican por qué los equipos de producto de EE. UU. y la UE no dejan de preguntar por ella:

• Los datos nunca salen del dispositivo. La foto, el mensaje, la nota de voz o el historial médico se procesan localmente. No se sube nada, así que no hay nada que interceptar, registrar ni requerir judicialmente.
• Funciona sin conexión. En un avión, en un túnel, en el sótano de un hospital: la función sigue funcionando porque el modelo ya está en el teléfono.
• Es instantánea. Sin ida y vuelta por la red, las respuestas empiezan en decenas de milisegundos, no tras un segundo de latencia.
• No tiene coste marginal. No hay factura de API por token. Diez usuarios o diez millones cuestan lo mismo en inferencia: nada.

Ese último punto reescribe la economía de las funciones de IA. La factura de un LLM en la nube crece de forma lineal con el uso; la inferencia en el dispositivo no se mueve en absoluto. En una app de consumo con millones de interacciones de IA al día, llevar el caso habitual al dispositivo convierte un coste variable ilimitado en cero.

El silicio neuronal que lo hace posible

Todo teléfono de gama alta actual incorpora una NPU (Neural Processing Unit) dedicada. Este es el panorama de hardware que determina qué modelos pueden ejecutar sus usuarios:

Los Android de gama media (clase Dimensity 7000, Snapdragon 6 Gen) tienen una aceleración por NPU limitada o nula para modelos grandes. Por eso la detección del nivel del dispositivo y la vía alternativa son obligatorias, no opcionales.

Qué cambió entre 2024 y 2026

Si su modelo mental es «hace falta un equipo de ML para ejecutar un modelo en un teléfono», está dos años desfasado. Cambiaron tres cosas.

Apple Intelligence puso un modelo en cada app de iOS

Apple abrió a desarrolladores externos su framework de Foundation Models en el dispositivo, de modo que cualquier app de iOS puede llamar ya a un modelo de sistema de aproximadamente 3B de parámetros con unas pocas líneas de Swift. Incluye generación guiada, llamadas a herramientas y salida estructurada, y todo se ejecuta en el Neural Engine. Se obtiene un modelo local capaz sin tener que distribuirlo, actualizarlo ni pagarlo. Para la mayoría de las tareas de «resume esto», «reescribe aquello» o «extrae estos campos», es hoy el punto de partida por defecto en iOS.

Google convirtió Gemini Nano en un servicio del sistema en Android

En Android, Gemini Nano se ejecuta mediante AICore como componente gestionado del sistema. Las apps solicitan inferencia en el dispositivo a través de las API de ML Kit GenAI (resumen, corrección, reescritura, descripción de imágenes) y el SO es el propietario del modelo. Como en iOS, el sistema comparte ese modelo, así que nunca engorda su APK y las actualizaciones de la plataforma lo mantienen al día.

Los modelos abiertos se hicieron lo bastante pequeños, y los runtimes mejoraron

Fuera de los modelos de sistema integrados, una oleada de modelos abiertos pequeños (de la clase de 1–4B, cuantizados a 4 bits) funciona ya bien en teléfonos a través de runtimes maduros: Core ML y MLX en iOS, LiteRT (el TensorFlow Lite rebautizado) y la pila MediaPipe LLM en Android, y motores multiplataforma como ExecuTorch, MLC LLM y llama.cpp. Permiten distribuir su propio modelo ajustado cuando el modelo del sistema no basta, a costa de cargar con los pesos y con la ingeniería necesaria para mantenerlos rápidos.

En el dispositivo o en la nube: la verdadera contrapartida

Esta es la decisión que importa, y no es ideológica. La IA en el dispositivo y la IA en la nube son herramientas con funciones distintas.

Para la mayoría de las apps, la respuesta sincera es híbrida: enviar cada solicitud al nivel más barato que pueda atenderla. La IA en el dispositivo asume el trabajo de alto volumen y sensible a la privacidad y la latencia: resumen, respuestas inteligentes, clasificación, extracción de entidades, transcripción, enmascaramiento de datos, búsqueda semántica sobre datos locales. La nube recoge la cola larga que realmente necesita razonamiento de vanguardia o conocimiento actualizado. Tratamos esa capa de enrutamiento como una parte de primer nivel de la arquitectura, como trataríamos una capa de caché; hay más sobre la ingeniería en nuestro servicio de IA, ML y datos.

El stack de IA en el dispositivo, por plataforma

Esto es lo que usamos en realidad, según la plataforma de destino.

iOS

• Apple Intelligence Foundation Models: la opción por defecto para generación de texto, resumen, extracción estructurada y uso de herramientas en dispositivos compatibles. Sin modelo que distribuir.
• Core ML + MLX: para modelos personalizados de visión, audio o un LLM ajustado que se convierte y ejecuta en el Neural Engine / la GPU.
• Vision, Natural Language, Speech, Sound Analysis: frameworks propios maduros para OCR, clasificación, transcripción en el dispositivo y más, todo en local.

Android

• Gemini Nano mediante AICore + ML Kit GenAI: la vía gestionada por defecto para resumir, corregir, reescribir y describir imágenes en dispositivos compatibles.
• LiteRT + MediaPipe LLM Inference: para ejecutar sus propios modelos cuantizados (Gemma y otros) con aceleración por GPU/NNAPI.
• NNAPI / NPU de cada fabricante: Qualcomm y otros exponen sus propios SDK cuando hay que exprimir el hardware.

Multiplataforma (React Native / Flutter)

• ExecuTorch (el runtime de PyTorch para el dispositivo) y MLC LLM permiten un único modelo que funciona en ambas plataformas.
• Los bindings de llama.cpp siguen siendo la opción pragmática para distribuir un modelo abierto concreto con control total.
• Sigue siendo necesario tender un puente a los frameworks nativos anteriores para lograr el mejor rendimiento por vatio, un tema recurrente en nuestra comparativa de React Native y Flutter: la capa multiplataforma es su interfaz, y la IA vive cerca del metal.
• No hay una API de JavaScript para los modelos del sistema. Apple Intelligence y Gemini Nano solo son accesibles desde Swift/Kotlin nativos, así que una app de React Native o Expo necesita un módulo nativo (un puente de la comunidad o uno propio) para llamarlos. Ese módulo no se ejecuta dentro de Expo Go, que incluye un conjunto fijo de código nativo; se necesita una build de desarrollo en cuanto la IA en el dispositivo entra en escena.
• Ponga la comprobación de disponibilidad en JS, no solo en nativo. La compatibilidad varía según el dispositivo y la versión del SO, así que la capa de JS necesita un indicador de capacidad y una vía alternativa deliberada hacia la nube: dar por hecho que la llamada nativa siempre funciona es como esto se rompe en producción, no en las pruebas.

Cómo es realmente la llamada al modelo

La razón por la que ya no hace falta un equipo de ML: llamar al modelo del sistema son unas pocas líneas, no un pipeline de entrenamiento. A continuación, la forma que tiene en cada plataforma: ilustrativa de las API actuales, no un fragmento listo para copiar, así que consulte la documentación de la plataforma para ver las firmas exactas antes de publicar.

// iOS — Apple Intelligence Foundation Models
import FoundationModels

let session = LanguageModelSession()
let reply = try await session.respond(
    to: "Summarise this thread in two sentences: \(threadText)"
)
print(reply.content)

// Android — Gemini Nano via ML Kit GenAI
val summarizer = Summarization.getClient(
    SummarizerOptions.builder(context).build()
)
summarizer.runInference(
    SummarizerRequest.builder(threadText).build()
) { result -> println(result.summary) }

Sin clave de API, sin facturación por llamada y sin permiso de red para la propia llamada. El esfuerzo de ingeniería se dedica a la vía alternativa y a la comprobación del nivel del dispositivo, no a la llamada anterior.

Comparativa de frameworks de un vistazo

Cómo hacer que los modelos quepan: fundamentos de optimización

Conseguir que un modelo funcione bien en un teléfono es un 80 % ingeniería y un 20 % elección del modelo. Tres técnicas que usará en todos los proyectos:

• Cuantización (INT8 / INT4): reducir la precisión de los pesos desde FP32 o FP16. Un modelo de 3B en FP16 ocupa ~6 GB; en INT4 se reduce a ~1,7 GB, compatible con un teléfono. El coste en precisión suele ser del 2–6 % en benchmarks estándar; verifíquelo siempre en su tarea concreta antes de publicar.
• Poda (pruning): poner a cero los pesos redundantes y omitir su cómputo. Más eficaz en modelos ajustados a una tarea concreta; añade complejidad al entrenamiento, pero reduce de forma notable el tiempo de inferencia en hardware preparado para matrices dispersas.
• Destilación de conocimiento: entrenar un pequeño modelo «alumno» para imitar a un «profesor» grande, capturando su comportamiento con una fracción del tamaño. Los modelos de sistema integrados de Apple y de Google se produjeron así.

La delegación de hardware es igual de importante: Core ML enruta automáticamente el cómputo al Neural Engine; LiteRT usa NNAPI con un delegado de GPU o Hexagon como alternativa. Omitir la delegación puede costar de 5 a 10 veces más latencia en el mismo dispositivo y modelo.

Qué se puede publicar hoy

Funciones concretas que hemos creado o delimitado en el dispositivo, sin dependencia de la nube en la vía principal:

• Resumen y respuesta inteligente: hilos largos, correos y documentos condensados en local; respuestas sugeridas generadas sin subir la conversación.
• Transcripción y traducción sin conexión: notas de voz y reuniones transcritas en el dispositivo; útil en salud, legal y trabajo de campo, donde el audio no debe salir del teléfono.
• Enmascaramiento en el dispositivo: detectar y difuminar rostros, matrículas, números de tarjeta y datos personales (PII) en imágenes antes de compartir o subir nada.
• Búsqueda semántica sobre datos personales: buscar por significado en sus propias notas, fotos y mensajes, con embeddings calculados y almacenados en local.
• Cámara inteligente y captura de documentos: clasificación en tiempo real, OCR y extracción de campos (recibos, documentos de identidad, formularios) sin red.
• Personalización que sigue siendo privada: ranking, sugerencias y perfiles en el dispositivo que nunca se convierten en un expediente en el servidor.

Privacidad, RGPD y Reglamento de IA de la UE

Aquí la IA en el dispositivo deja de ser un truco de rendimiento y se convierte en un enfoque de cumplimiento. Por eso encaja tan bien en el mercado europeo.

• Minimización de datos del RGPD, por construcción. Si los datos personales se procesan solo en el dispositivo del usuario y nunca se transmiten, se elimina toda una clase de obligaciones: sin transferencias internacionales de datos, sin garantías para terceros países y mucho menos que conservar, registrar o divulgar. Es una de las formas más limpias de demostrar la protección de datos desde el diseño y por defecto.
• Sin encargado del tratamiento externo en la vía principal. Enviar texto de usuarios a un LLM en la nube convierte a ese proveedor en un encargado que hay que contratar, documentar y declarar. Si se mantiene en el dispositivo, esa relación, y su riesgo, sencillamente no existe.
• El Reglamento de IA de la UE sigue aplicándose. Que sea en el dispositivo no le exime. Los deberes de transparencia (informar a los usuarios de que interactúan con IA), las prácticas prohibidas y las clasificaciones de alto riesgo dependen del caso de uso, no de dónde se ejecute la inferencia. Lo que elimina la IA en el dispositivo es el riesgo de transferencias internacionales y de encargados, no sus deberes bajo el Reglamento de IA. Tratamos el marco en nuestra lista de verificación del Reglamento de IA de la UE.

El patrón práctico: haga en el dispositivo el trabajo sensible para la privacidad y, si escala a la nube, escale datos enmascarados y minimizados con consentimiento explícito, nunca el registro en bruto.

Coste, plazo y equipo

Cifras reales de cómo delimitamos este trabajo para clientes de EE. UU. y la UE en 2026:

• Una función en el dispositivo bien acotada (resumen, respuestas inteligentes, transcripción sin conexión o enmascaramiento de datos): ~4–8 semanas, ~€25–60k. Equipo: 1 ingeniero móvil con experiencia en ML en el dispositivo, apoyo de ML a tiempo parcial y QA en una matriz de dispositivos.
• Una app centrada en IA con varias funciones en el dispositivo más una capa híbrida de escalado a la nube: ~3–5 meses, delimitado por función.
• El coste dominante es el QA, no el modelo. Llamar a los modelos de sistema integrados es gratis; el trabajo consiste en verificar el comportamiento, el rendimiento y la batería en la larga cola de hardware Android real, además de la vía alternativa para los dispositivos no compatibles.

La partida de «sin coste marginal» es fácil de enunciar y fácil de subestimar. Así se ve cuando una función está en el camino habitual de todos los usuarios, con una tarifa de nube mixta e ilustrativa:

Economía unitaria ilustrativa: 5 solicitudes cortas por usuario y día a una tarifa de nube mixta de $0.002 por solicitud. Su cifra real depende del modelo, el proveedor y el número de tokens; lo importante es que en la nube crece de forma lineal y en el dispositivo se mantiene plana.

Para ver referencias completas de todo el desarrollo, consulte nuestra guía del coste de desarrollo de apps móviles en 2026. El consejo específico para IA en el dispositivo: reserve presupuesto explícito para un laboratorio de pruebas con dispositivos reales y decida el nivel mínimo compatible antes de escribir una línea de código de inferencia.

Retos y limitaciones de los que nadie habla

La IA en el dispositivo se publica. Pero hay limitaciones de ingeniería reales que inflan los presupuestos cuando se descubren tarde. Esto es lo que los equipos con experiencia delimitan de forma explícita desde el principio:

• Tamaño del modelo y presión sobre la RAM. Un modelo de 3B a 4 bits ocupa aproximadamente 1,7 GB en disco y necesita un margen de RAM comparable durante la inferencia. En un dispositivo con 6 GB de RAM en total, con el SO y la app en primer plano ya consumiendo 2–3 GB, compite por el resto. iOS finaliza los procesos que disparan la RAM; los Android de gama media van aún más justos. Presupuestar el tamaño del modelo es una decisión de arquitectura de primer nivel, no un ajuste posterior al lanzamiento.
• Consumo de batería y térmica. La inferencia sostenida en el dispositivo (una sesión de transcripción en directo, una generación larga) puede elevar el consumo de batería al 15–25 % por hora y provocar limitación térmica en algunos dispositivos. La NPU es mucho más eficiente que ejecutar la misma carga en la CPU o la GPU, pero sigue siendo real. Perfile el consumo de batería y la temperatura de la CPU en una matriz de dispositivos antes de comprometerse con un diseño de función que requiera inferencia continua.
• Fragmentación de Android. Hay más de 10,000 modelos de dispositivo Android activos en los mercados globales. Gemini Nano mediante AICore requiere un nivel específico de capacidad de ML que no está presente en todos los dispositivos con Android 12+, y muchos dispositivos Android más antiguos o económicos no tienen ninguna NPU relevante. La detección del nivel del dispositivo y una vía alternativa controlada no son una ocurrencia tardía: son el diseño.
• Obsolescencia del modelo. El modelo en el dispositivo se congela en la versión incluida con la app. No sabrá de un cambio regulatorio, una actualización de precios ni un evento de la semana pasada. Si su función depende de conocimiento actual (precios, noticias, inventario, requisitos legales), las respuestas en el dispositivo quedarán obsoletas. La IA en el dispositivo es mejor para tareas atemporales; el conocimiento en tiempo real pertenece a la nube.
• Ciclo de iteración lento. A diferencia de una API en la nube en la que se cambian las versiones del modelo en minutos, actualizar un modelo en el dispositivo implica publicar una actualización en la tienda de apps o activar una descarga de recursos en segundo plano. Eso ralentiza notablemente el ciclo de retroalimentación. Planifique el versionado del modelo como una cuestión de ingeniería con nombre propio desde el primer día, no como un problema futuro.

Lista de verificación de implementación

La secuencia que seguimos al añadir IA en el dispositivo a una app móvil:

1. Defina el trabajo. Una frase: «resumir hilos», «transcribir sin conexión», «enmascarar datos personales (PII)». Las ambiciones vagas de IA son donde mueren los presupuestos.
2. Pruebe primero el modelo del sistema. Apple Intelligence en iOS, Gemini Nano en Android. Si es suficientemente bueno, ya casi ha terminado.
3. Fije el nivel mínimo de dispositivo. Elija el nivel mínimo que admitirá en el dispositivo y diseñe la alternativa en la nube (o de degradación controlada) para todo lo que quede por debajo.
4. Elija el modelo solo si hace falta. Si el modelo del sistema se queda corto, escoja un modelo abierto pequeño y cuantícelo a 4 bits; mida tamaño, latencia y batería, no solo la precisión.
5. Construya la capa de enrutamiento. Primero el dispositivo, escalado a la nube para los casos difíciles u obsoletos, con consentimiento y enmascaramiento en la frontera.
6. Pruebe en hardware real. Los emuladores mienten sobre el rendimiento de la NPU y la batería. Use una matriz de dispositivos físicos que vaya de la gama alta a la media.
7. Mida batería y térmica. La inferencia sostenida calienta los teléfonos. Perfílela; limite o agrupe donde haga falta.
8. Informe y obtenga el consentimiento. Diga a los usuarios cuándo interviene la IA y qué (si algo) sale del dispositivo: es buena UX y buena higiene frente al Reglamento de IA.

Cuándo sigue ganando la IA en la nube

La IA en el dispositivo es una opción por defecto, no una religión. Priorizamos la nube cuando se da alguna de estas condiciones:

• Razonamiento de vanguardia: análisis complejos de varios pasos, programación o juicios matizados que un modelo de 3B no puede hacer de forma fiable.
• Contexto amplio: razonar sobre un documento de 200 páginas o un historial largo que no cabe en un modelo local pequeño.
• Conocimiento actualizado: respuestas que deben reflejar los datos, precios o inventario de hoy, mediante recuperación o herramientas en vivo.
• Estado compartido en el servidor: cuando la inteligencia trata inherentemente de los datos de otros usuarios y no de los de este teléfono.

Así, la arquitectura que gana en 2026 es la híbrida: en el dispositivo para el caso habitual, privado, instantáneo y de alto volumen, y en la nube para el pesado y ocasional. La verdadera ingeniería consiste en acertar con esa frontera, junto con el consentimiento y el enmascaramiento que se sitúan en ella. Ese es el núcleo de cómo desarrollamos apps móviles con IA para clientes de EE. UU. y la UE.

Preguntas frecuentes

¿Qué es la IA en el dispositivo en una app móvil?

El modelo se ejecuta en el propio chip del teléfono (Apple Neural Engine, NPU de Android) en lugar de en un servidor en la nube. La entrada nunca sale del dispositivo, funciona sin conexión y no hay factura por solicitud. En 2026 se expone mediante Apple Intelligence en iOS y Gemini Nano en Android, además de modelos abiertos a través de Core ML, LiteRT, ExecuTorch, MLC y llama.cpp.

IA en el dispositivo o IA en la nube: ¿cuál debo usar?

En el dispositivo para privacidad, uso sin conexión, latencia y coste marginal cero: resúmenes, respuestas inteligentes, clasificación, transcripción, enmascaramiento de datos. En la nube para razonamiento de vanguardia, contexto amplio o conocimiento actualizado. La mayoría de las apps en producción son híbridas: en el dispositivo para el 80 % habitual y en la nube para el 20 % difícil.

¿Qué tamaño de modelo puede ejecutar un teléfono en 2026?

Con comodidad, de 1 a 4 mil millones de parámetros a 4 bits en un teléfono de gama alta reciente (iPhone 15 Pro+, Pixel 8/9, Galaxy S24/S25). Los modelos de sistema integrados rondan la clase de 3B. Los Android de gama media se limitan a modelos más pequeños o recurren a la nube, por lo que la detección del nivel del dispositivo forma parte del diseño.

¿Es mejor la IA en el dispositivo para el RGPD y el Reglamento de IA de la UE?

Normalmente sí para el RGPD: procesar íntegramente en el dispositivo reduce de forma drástica la exposición a transferencias, encargados y conservación, con una minimización de datos limpia. El Reglamento de IA de la UE se sigue aplicando según el caso de uso (transparencia, reglas de prácticas prohibidas y de alto riesgo), así que la IA en el dispositivo reduce el riesgo transfronterizo, pero no le exime.

¿Cuánto cuesta añadir IA en el dispositivo a una app?

Una función bien acotada cuesta aproximadamente 4–8 semanas y €25–60k con un equipo sénior, incluidas la selección del modelo, una vía alternativa por nivel de dispositivo y QA en hardware real. El mayor factor de coste son las pruebas en la cola de dispositivos Android, no el modelo en sí.

¿Funciona la IA en el dispositivo sin conexión y en teléfonos antiguos?

Sin conexión: sí, ese es el objetivo. Teléfonos antiguos: los de gama alta de los últimos 2–3 años ejecutan modelos de 1–4B; los dispositivos más antiguos y de gama media necesitan modelos más pequeños o una alternativa en la nube. Un desarrollo correcto detecta el nivel en tiempo de ejecución y enruta en consecuencia.

¿La IA en el dispositivo agota la batería?

Depende de la tarea. Una llamada de clasificación en segundo plano consume una batería insignificante: menos del 0,1 % por sesión. Las tareas sostenidas en tiempo real, como la transcripción en directo o la generación de texto largo, pueden costar entre el 15 % y el 25 % de batería por hora en algunos dispositivos. La NPU es mucho más eficiente en consumo que ejecutar la misma carga en la CPU o la GPU, pero la inferencia sostenida se acumula. Perfile la batería y la térmica en hardware real y después agrupe o limite las tareas pesadas donde la UX lo permita.

¿Cómo funcionan las actualizaciones de modelos en el dispositivo?

A diferencia de una API en la nube en la que se cambian las versiones del modelo en silencio, los modelos en el dispositivo se incluyen con la app o se descargan junto a ella. Actualizar el modelo implica publicar una actualización en la tienda de apps o activar una descarga de recursos en segundo plano por wifi. La iteración rápida es más lenta que en la nube, así que planifique el versionado del modelo desde el primer día, sobre todo si su caso de uso se beneficiará de un reentrenamiento periódico o de un ajuste fino con datos nuevos.

Cómo decidiríamos para su app

Dénos 30 minutos y la función que tenga en mente, y le diremos si corresponde al dispositivo, a la nube o a ambos, con un coste y un calendario realistas para su equipo y su mercado. Sin diapositivas, sin ventas adicionales. Publicamos ambas y nos da igual cuál elija, siempre que sea la correcta.

Última actualización: 24 de septiembre de 2026. Se han añadido ejemplos de código nativo para Apple Intelligence y Gemini Nano, detalles de la integración con React Native/Expo, una tabla de escalado de costes y un recuadro de errores habituales como parte de un nuevo análisis de huecos en la SERP. Las clases de modelos y los frameworks reflejan Apple Intelligence Foundation Models, Google Gemini Nano / AICore, Core ML, LiteRT y ExecuTorch tal como están disponibles en 2026. El rendimiento de los dispositivos se midió en un iPhone 15 Pro, un Pixel 9 y un dispositivo Android de gama media de referencia. Metodología disponible a petición.