La IA en el dispositivo ejecuta un modelo compacto de lenguaje o visión directamente en el teléfono o portátil en lugar de en un servidor en la nube. Apple Intelligence y Gemini Nano de Google son los ejemplos más conocidos. Pasar una función de piloto a producción significa confirmar la compatibilidad del dispositivo, diseñar una alternativa en la nube, probar la calidad en hardware real, documentar el comportamiento de privacidad y medir la adopción por separado para cada plataforma.
Apple Intelligence es el sistema de funciones generativas de Apple en iOS, iPadOS y macOS, con un modelo más pequeño en el dispositivo y Private Cloud Compute para solicitudes más pesadas. Apple ha abierto el acceso a su modelo base en el dispositivo para desarrolladores a través de un marco de trabajo, en el momento de escribir este artículo. Gemini Nano es el modelo Gemini más pequeño de Google, disponible en dispositivos Android seleccionados a través del servicio del sistema AICore de Android y, de forma experimental, dentro de Chrome a través de API de IA integradas. Ambos conllevan el mismo compromiso: privacidad y velocidad a cambio de un modelo más pequeño y una cobertura de dispositivos desigual.
¿Por qué debería importarle a un equipo de marketing o producto?
Los modelos en el dispositivo permiten que una aplicación resuma, reescriba, clasifique o extraiga texto sin enviar datos del usuario a un servidor. Eso es importante para las aplicaciones que manejan mensajes, notas de salud o datos financieros, y para los mercados donde los usuarios y los reguladores son sensibles a las transferencias de datos.
También hay un aspecto de costes. La inferencia en el dispositivo del usuario no aparece en su factura de la nube. Para una función utilizada millones de veces al día, como las respuestas inteligentes o la limpieza de texto, eso puede cambiar la economía, aunque el esfuerzo de ingeniería sea mayor.
¿Qué dispositivos lo admiten realmente?
Esta es la primera puerta en la lista de verificación. Apple Intelligence requiere hardware reciente y configuraciones específicas de idioma y región; Gemini Nano se limita a dispositivos cuyos fabricantes incluyen soporte para AICore. Ambas listas cambian con cada lanzamiento, así que consulte la documentación oficial en lugar de una entrada de blog.
Obtenga sus propias analíticas antes de comprometerse. Si solo una fracción de sus usuarios activos posee dispositivos compatibles, la función se convierte en una mejora, no en una función principal, y el plan debería decirlo.
Lista de verificación del piloto
- Anote la tarea única que realizará el modelo, como resumir tickets de soporte o etiquetar fotos.
- Confirme la proporción de sus usuarios activos en dispositivos compatibles, por plataforma y país.
- Pruebe el modelo en el dispositivo con 50 a 100 ejemplos reales y compárelo con un modelo en la nube en el mismo conjunto.
- Mida la latencia y el impacto en la batería en el dispositivo compatible más antiguo, no solo en el más nuevo.
- Decida qué sucede en los dispositivos no compatibles: ocultar la función, llamar a un modelo en la nube u ofrecer una versión más simple sin IA.
- Revise la redacción de la política de privacidad con el departamento legal antes de que cualquier usuario vea la función.
¿Qué cambia entre el piloto y la producción?
Un piloto demuestra que el modelo puede hacer la tarea. La producción demuestra que puede hacerlo para miles de personas en hardware mixto, con actualizaciones de modelo que usted no controla.
Tanto Apple como Google actualizan sus modelos en el dispositivo a través de actualizaciones del sistema operativo o del servicio del sistema. Sus prompts y el análisis de salida pueden comportarse de manera diferente después de una actualización. Trate esto como cualquier dependencia de terceros: mantenga un conjunto de pruebas de regresión y ejecútelo cuando una nueva versión del SO llegue a la versión beta.
Lista de verificación de producción
- Marque la ruta de IA con un indicador de función para que pueda desactivarse de forma remota.
- Registre señales de resultado anónimas, como aceptado, editado o descartado, sin registrar el contenido del usuario.
- Establezca límites para la longitud y el formato de salida, y maneje respuestas vacías o mal formadas.
- Documente la ruta de respaldo y su coste si utiliza un modelo en la nube.
- Añada la función al control de calidad de lanzamiento en al menos un dispositivo compatible y uno no compatible por plataforma.
- Prepare respuestas de soporte para “¿por qué no veo esta función?”
¿Cómo mide si funcionó?
Mida la adopción y la calidad por plataforma, porque los modelos difieren. Las métricas útiles son la proporción de usuarios elegibles que prueban la función, la tasa de aceptación de la salida de IA, la tasa de edición después de la aceptación y el tiempo de finalización de la tarea en comparación con la ruta sin IA.
Tenga cuidado con las promesas de privacidad en la medición. Si su marketing dice que los datos nunca salen del dispositivo, sus analíticas no pueden recopilar el texto en silencio. Rastree el comportamiento, no el contenido.
¿Cuáles son los límites principales de los modelos en el dispositivo?
Los modelos pequeños saben menos y razonan menos que sus hermanos en la nube. Son buenos en tareas limitadas con la información necesaria en el prompt, como reescribir un párrafo o extraer una fecha de un correo electrónico. Son malos en preguntas abiertas que requieren un amplio conocimiento del mundo.
Las ventanas de contexto también son más cortas, por lo que es posible que los documentos largos deban dividirse. Y como no puede ajustar el modelo del sistema como lo haría con un modelo en la nube, las mejoras de calidad provienen de mejores prompts y una mejor preparación de la entrada, no del entrenamiento. Planifique las funciones en torno a estos límites en lugar de esperar que la próxima versión del SO los elimine.
¿Qué casos de uso se adaptan mejor a los modelos en el dispositivo?
Las tareas de texto limitadas son el comienzo más seguro: resumir un solo mensaje, sugerir una respuesta corta, reescribir una nota en un tono más amable o extraer una dirección o fecha. Las tareas de imagen, como etiquetar fotos o eliminar un fondo, también se adaptan al procesamiento local.
Las tareas que necesitan información fresca, documentos largos o un razonamiento cuidadoso pertenecen a un modelo de servidor. Una división clara, local para tareas privadas rápidas y en la nube para las pesadas, es más fácil de explicar a los usuarios y a los equipos legales que una función que cambia de forma impredecible.
Cómo aplica Alien Road la IA en el dispositivo
Nuestro papel en un compromiso típico se sitúa entre el producto y el marketing. El descubrimiento comienza con las analíticas del cliente para dimensionar la audiencia de dispositivos compatibles, luego un breve taller sobre qué tarea brinda a los usuarios un beneficio visible.
Ayudamos a configurar el conjunto de pruebas y la comparación con un modelo en la nube, definimos las métricas de adopción y creamos un panel que divide los resultados por plataforma y clase de dispositivo. En el lado del marketing, escribimos el texto dentro de la aplicación y la tienda para que las declaraciones de privacidad coincidan exactamente con lo que hace la función, y reportamos la adopción mensualmente para que el cliente pueda decidir si expandirla, mantenerla o retirarla.
Por dónde empezar esta semana
Exporte los usuarios activos del último mes por modelo de dispositivo y versión de SO. Compárelo con las listas de soporte oficiales actuales para Apple Intelligence y Gemini Nano. Esa única tabla le dice si la IA en el dispositivo es una función principal o una mejora silenciosa para su producto.
Si la proporción es significativa, elija una tarea de texto, recopile 50 ejemplos reales y ejecútelos a través del modelo en el dispositivo en un teléfono de prueba. Anote dónde falla. Esa lista es su plan piloto.
Seguir leyendo: Optimización con IA · Optimización con IA