Disponibilidad de WebNN, backends y privacidad

WebNN es una API web para expresar cálculos de aprendizaje automático como grafos ejecutables por el navegador. Puede permitir inferencia local sin depender por completo de un servicio remoto. Su disponibilidad depende de cada implementación; por ello, la aplicación necesita una alternativa y no debe interpretar la presencia de la API como una promesa de velocidad o hardware.

Qué representa WebNN

La aplicación describe operaciones y flujo de datos, y solicita al navegador construir, compilar y ejecutar un grafo. La API pretende que el agente de usuario asigne el trabajo a los recursos disponibles, manteniendo el modelo del grafo independiente de la interfaz de un fabricante concreto (modelo de programación del W3C).

WebNN no es renderizado gráfico. Para cómputo y renderizado gráfico, consulta WebGPU y privacidad del navegador. La disponibilidad de una API no implica la de la otra.

Describe la tarea, no el nombre de la API: una función fotográfica puede necesitar un grafo de imágenes, una transcripción uno de audio y una función documental uno de texto. Cada tarea puede usar un modelo, forma de entrada, interpretación de salida y alternativa distintos.

Mantén esas decisiones separadas para no presentar una capacidad general cuando solo se ha probado una función. Así también puedes explicar qué función no está disponible y mantener utilizables las partes no relacionadas de la página. Un grafo válido puede no servir para una entrada concreta, como una imagen con disposición de color inesperada o un documento con texto no compatible. Valida también el recorrido de entrada y explica qué parte requiere atención para que el usuario pueda actuar sin conocer el modelo de ejecución del navegador.

Disponibilidad y opciones de ejecución

El soporte depende de la madurez de la implementación, el canal de publicación, el sistema operativo, el hardware y la configuración. Un navegador puede exponer solo parte de la funcionalidad o no exponerla. La especificación permite consultar el soporte de operadores concretos con opSupportLimits() y no expone el dispositivo seleccionado (consulta de soporte, consideraciones de privacidad); por eso, la presencia de la API no demuestra qué backend ejecuta el grafo.

Estas decisiones pueden cambiar entre versiones: un navegador puede añadir una operación, retirar una ruta experimental o cambiar la planificación del grafo; una actualización del sistema puede cambiar los recursos disponibles, y una instalación administrada puede restringir funciones por política. Son detalles de implementación que afectan a compatibilidad y rendimiento, no un contrato estable para identificar una máquina.

Cuando un resultado importe, registra la versión del navegador, la familia del sistema operativo, la versión de la aplicación, la revisión del modelo y el requisito del grafo. Esto permite decidir si cambiar la aplicación, mantener una alternativa o aplazar una función, pero no justifica conclusiones sobre el dispositivo físico de una persona.

El mismo grafo puede aceptarse en una versión y rechazarse en otra por una operación aún no disponible o por depender de un comportamiento fuera de la política de soporte. Regístralo como resultado de compatibilidad, no como dato sobre una persona o máquina.

Preguntas de privacidad

La inferencia local puede reducir la necesidad de enviar algunos datos a un servicio, pero no vuelve privada a una aplicación por sí sola. La aplicación sigue controlando qué almacena, transmite y registra. Una página también puede saber si existe una capacidad. Usa ese dato para seleccionar funciones, no como identidad ni como afirmación sobre el hardware. El cálculo local no demuestra cómo se comunica el resto de la aplicación; como revisión del flujo de datos, comprueba si se suben por separado datos de origen, resultados o telemetría (consideraciones de privacidad del W3C). La declaración de privacidad del W3C describe el procesamiento de entradas por WebNN; una subida independiente de datos por la aplicación es otro flujo de datos.

Limita las comprobaciones a una necesidad visible para el usuario, solicita solo lo necesario y revisa la telemetría antes de registrar resultados. La privacidad depende del flujo completo, no solo del lugar del cálculo: un grafo local puede mantener la entrada en el dispositivo, pero la aplicación aún podría guardar una imagen original, almacenar en caché el modelo, exportar el resultado o enviar un informe de error. Una alternativa remota puede requerir una carga, una cuenta y otras reglas de retención; explica esa opción antes de mover los datos. Para soporte, prefiere un estado breve, función disponible, alternativa elegida o tarea incompleta, en vez del objeto completo de capacidades. Las entradas pueden contener rostros, voces o documentos personales y necesitan reglas separadas de acceso y eliminación. La decisión de ejecución del navegador no responde a esas cuestiones del producto.

Pruebas de compatibilidad

Prueba el grafo requerido y el resultado esperado en cada familia de navegadores admitida. Incluye una ruta para los navegadores sin WebNN y comprueba que cambiar a ella no pierda datos ni deje una tarea a medias. Evalúa los resultados funcionales por separado de las expectativas de rendimiento. Mantén un registro compacto de versión del navegador, sistema operativo, resultado de la función y resultado de la alternativa; no decidas a partir de una sola estación, no conviertas el tiempo transcurrido en un umbral de lanzamiento ni lo uses como etiqueta del dispositivo. Usa fixtures representativos y no sensibles para entradas normales e inválidas, datos de modelo ausentes, operaciones no disponibles, cancelación y resultados que la interfaz no puede presentar. Evalúa por separado el significado de la salida, la estabilidad de memoria, la interacción, la accesibilidad y la posibilidad de que el usuario corrija el resultado. Mantén las comprobaciones específicas por función cuando los modelos admitan grafos distintos, en vez de crear un estado global de «listo». Registra la tarea, clase de entrada, finalización y alternativa visible sin conservar una descripción permanente del navegador.

Gestión de cambios de versión

Cuando cambie el soporte, repite las pruebas del grafo y confirma que la alternativa siga disponible. Un cambio de backend merece revisión si afecta resultados o recursos de los que depende la aplicación, pero una consulta pública de capacidades no permite asumir cuál es ese backend.

La revisión de versiones del navegador ayuda a comparar versiones. La madurez y superficie de WebNN pueden evolucionar aparte del soporte WebGPU.

Para cada candidato de versión, prueba la compilación admitida y la revisión del modelo con los mismos fixtures, incluida la actualización del modelo almacenado en caché. Distingue una interfaz no disponible, una salida inaceptable y una ejecución incompleta: pueden requerir una ruta alternativa, cambiar el modelo o la compilación, o cancelar de forma recuperable. Registra resultados para la tarea sin guardar objetos detallados de capacidades ni inferir hardware.

Cubre cada familia y rango de sistemas operativos admitidos; fija la revisión de la aplicación, modelo y fixtures para atribuir cambios. Una función opcional no debe desactivar el resto de la página. Documenta tarea, resultado y rango probado, sin prometer velocidad o resultados idénticos.

Cuando investigues cambios, varía una sola entrada de versión cada vez cuando sea posible. Compara primero una actualización solo del navegador con el mismo modelo y preprocesamiento; después prueba solo el modelo con una compilación conocida. Así puedes separar aceptación del grafo, conversión de entrada, comportamiento del modelo y selección de alternativa.

Para imágenes prueba disposición de color, orientación, alfa y redimensionamiento, incluyendo transparencia y escalado. Para audio varía frecuencia de muestreo y canales e incluye silencio, recorte, voz con ruido y clips cortos y largos; comprueba que remuestreo y conversión de canales sigan el preprocesamiento declarado. Para texto prueba entrada vacía y larga, puntuación inusual, varias escrituras y un idioma distinto al seleccionado.

Separa fallos de validación, preprocesamiento, creación y ejecución del grafo, posprocesamiento y presentación. Valora la utilidad semántica, no solo que el grafo corra; compara aceptación funcional aparte de latencia y memoria. Repite una entrada para detectar estado accidental de otra tarea y usa otra fixture para verificar que cambiar modelo o idioma cambie la ruta. Explica los problemas con acciones que el usuario pueda tomar, como elegir otro archivo o idioma; no atribuyas al navegador una entrada fuera del rango del modelo.

Para cada modelo, documenta junto a sus fixtures las formas y rangos de entrada y salida, normalización y correspondencia de etiquetas. Incluye valores justo dentro y fuera de los límites y muestra un error específico de entrada antes de ejecutar el grafo. Compara las salidas con criterios de aceptación propios de la tarea, sin exigir valores internos idénticos entre implementaciones. El manifiesto debe identificar revisiones del modelo y preprocesamiento, clase de entrada, resultado esperado y si alguien debe revisar o corregirlo.

En clasificación, comprueba el mapeo de etiquetas y trata una puntuación como orientativa salvo que el modelo defina su significado. En transcripción, comprueba habla omitida e idioma; en resúmenes, contrasta las afirmaciones clave con la fuente. Define criterios de aceptación para cada tipo de resultado.

La entrega del modelo necesita reglas de ciclo de vida. Conserva activa una revisión conocida y funcional mientras se descarga la nueva; comprueba el recurso nuevo con una tarea básica antes de seleccionarlo y recupera limpiamente una descarga interrumpida. Etiqueta los recursos almacenados con revisiones del modelo y preprocesamiento y una nota de compatibilidad; distingue los recursos completos de los parciales y evita reutilizar una versión de idioma o preprocesamiento antigua. Si se pierde la conexión o falta almacenamiento, elimina solo el recurso temporal incompleto, conserva el modelo funcional y deja que el usuario elija reintentar o descargar más tarde. Si el espacio es limitado, explica qué recurso se eliminaría y ofrece un modelo menor o una ruta de servicio; no borres el único modelo local útil antes de que su reemplazo supere la prueba. Registra las restricciones de licencia. Una actualización puede cambiar etiquetas, interpretación de confianza, idiomas o textos accesibles aunque el grafo no cambie; explícalo y permite seguir con la versión anterior cuando la política y el espacio lo permitan.

Prueba la alternativa como un recorrido completo con la tarea y fixture que expusieron el fallo. Una ruta sin inferencia puede permitir editar una transcripción, buscar texto normalmente o filtrar sin clasificación; un modelo menor debe declarar sus límites de entrada o calidad; una ruta de servicio puede requerir cuenta y carga.

Conserva la entrada original hasta que el usuario acepte el resultado, ofrece cancelar y deja un estado recuperable si se pierde la red, se deniega un permiso, se llena el almacenamiento o se abandona la página. Aclara si una solicitud incompleta se canceló, se puede reanudar o dejó un resultado parcial; no lo muestres como completo. Antes de cualquier carga, identifica el servicio y su retención y pide confirmación explícita. En un reintento, muestra si el procesamiento sigue siendo local o cruza ese límite. El usuario debe poder volver atrás sin perder la fuente ni conceder un permiso ajeno a la tarea; nunca cambies silenciosamente de procesamiento local a carga porque el grafo no esté disponible.

Incluye accesibilidad en el mismo registro de versión. Una etiqueta prevista debe poder leerse con lector de pantalla; un indicador que solo usa color necesita otra señal; y el usuario debe poder corregir o ignorar un resultado orientativo. Anuncia el progreso con claridad, mantén la comprensión al ampliar la página o mover el foco al botón de cancelar y prueba solo con teclado desde la selección de entrada hasta la corrección o cancelación. Comprueba que el foco no se pierda al cambiar de modelo o alternativa. En funciones de voz o imagen, explica si el resultado es una sugerencia, una transcripción o una exportación final. Mantén una ruta manual si el resultado es incierto o el usuario no puede conceder el permiso solicitado.

Para operaciones y soporte, conserva solo la versión del navegador, familia del sistema operativo, revisiones de la aplicación y modelo, requisito del grafo, clase de entrada, etapa fallida y resultado esperado frente al visible que hagan falta para reproducir el problema. Prefiere un código de resultado y un fixture sintético a imágenes, grabaciones, documentos u objetos de grafo completos. Registra si el usuario eligió procesamiento local o un servicio y elimina fixtures y diagnósticos temporales al cerrar el caso. Define un plazo de retención e informa qué campos se recogen cuando la persona decide reportar un problema. Si el medio original es imprescindible, solicítalo mediante el consentimiento y controles de eliminación separados del proceso de soporte. Compara tareas completadas, alternativas, cancelaciones e incompletas sin crear un perfil permanente del navegador; mantén utilizables las funciones no relacionadas y explica qué tarea se vio afectada.

Revisa privacidad cuando cambien el flujo de datos o el comportamiento del modelo. La inferencia local indica dónde corre el grafo, no si la aplicación almacena o transmite entradas, resultados o telemetría. Revisa esas rutas aparte: una imagen seleccionada puede almacenarse localmente, un resultado exportarse y un informe diagnóstico enviarse aunque el grafo permanezca en el dispositivo. No combines objetos de capacidades detallados con identificadores de cuenta cuando baste un resultado agregado. Separa los datos necesarios para operar la función de los de soporte: la inferencia puede requerir una entrada efímera; la telemetría quizá solo necesite saber si la función terminó, usó una alternativa o se canceló. Los diagnósticos deben ser elegidos por el usuario, limitados a reproducir la tarea, con propósito y retención declarados, y una ruta de borrado para registros, modelos almacenados y resultados temporales. Para reproducir, relaciona versiones de navegador, aplicación y modelo con preprocesamiento, posprocesamiento, invalidación de caché, entrada y exportación cuando dependan entre sí; revisa cada capa por separado si solo cambia una. Evalúa función, memoria, interacción y explicaciones accesibles como aspectos distintos. Explica si un resultado es orientativo y cómo corregirlo; no retires una alternativa hasta repetir la misma tarea en todo el rango admitido. Una instalación administrada puede aplicar políticas distintas a un navegador personal: documenta las configuraciones admitidas y conserva una ruta utilizable cuando el administrador desactive un grafo opcional.

Mapa de afirmaciones y fuentes

• El modelo de programación y el límite entre construir y ejecutar el grafo están definidos en el modelo de programación del W3C.
• La disponibilidad por operador se consulta con opSupportLimits(); no revela el backend ni el hardware.
• El límite cualificado de privacidad sobre capacidades y procesamiento de entradas está en las consideraciones de privacidad del W3C; las cargas, el almacenamiento y la telemetría de la aplicación son flujos de datos separados.
• La especificación WebNN es la referencia para validación, ejecución y compatibilidad; las pruebas descritas son criterios de aceptación de la aplicación, no garantías normativas del navegador.

Fuentes públicas

• Especificación WebNN del W3C
• API WebNN, grupo comunitario Web Machine Learning del W3C