El equipo de ingeniería de Meta publicó un informe arquitectónico sobre Private Processing, el sistema de computación confidencial que está extendiendo de WhatsApp y la app Meta AI a las AI Glasses, describiendo cómo la compañía pretende ejecutar cargas de trabajo de IA con estado y personalizadas —transcripción en streaming, búsqueda contextual, memoria de largo plazo— en la nube sin que la propia Meta pueda leer los datos subyacentes. La publicación, atribuida a Pritam Shah y Oskar Linde en el blog de ingeniería de Meta, plantea el problema con claridad: las gafas no pueden alojar modelos lo suficientemente grandes para estas funciones de forma local, por lo que el cómputo debe trasladarse a la nube, y la nube debe rediseñarse para que no pueda ver lo que está procesando.

El mecanismo se apoya en entornos de ejecución confiables, o TEEs, hardware presente en ciertas CPUs y GPUs que cifra la memoria de una máquina virtual confidencial (CVM) bajo una clave que retiene un silicio dedicado, nunca liberada al sistema operativo anfitrión, al hipervisor ni al operador de la infraestructura. La publicación de Meta cita las tres garantías del Confidential Computing Consortium para este modelo: confidencialidad de datos (nadie fuera de la CVM puede leer la memoria en uso), integridad de datos (nadie externo puede alterarla) e integridad del código (nadie puede modificar el código en ejecución). Antes de que un dispositivo de gafas envíe cualquier contexto personal, realiza una atestación remota mediante TLS —exigiendo un certificado firmado por hardware desde el TEE del servidor, y luego verificando los hashes binarios del TEE contra lo que Meta denomina un registro de transparencia público e independiente. Si falla la verificación del certificado del proveedor o el hash no coincide con el registro, indica la publicación, el protocolo de enlace falla y el dispositivo no se conecta.

La capa de enrutamiento está diseñada para impedir que la propia infraestructura de Meta vincule una solicitud con una identidad. Según la publicación, los dispositivos utilizan credenciales anónimas —tokens firmados a ciegas (blind-signed) obtenidos en horarios aleatorios— de modo que el servicio de autenticación no puede asociar una solicitud con una cuenta, y luego se conectan a través de un relay OHTTP de terceros (la publicación menciona a Fastly o Cloudflare) para seleccionar un nodo TEE mediante heurísticas que no identifican al usuario. Esta es la propiedad de "no focalización" ("non-targetability") que Meta enumera como uno de los cinco requisitos de ingeniería del sistema, junto con el aislamiento de hardware, las garantías de fallo cerrado (fail-closed), la verificabilidad pública y el almacenamiento cifrado.

La memoria persistente —la función que permite a un asistente recordar algo de una sesión anterior— se resuelve colocando el motor de almacenamiento dentro del propio TEE, en lugar de en una base de datos externa cifrada. La publicación de Meta argumenta que esta decisión de diseño está forzada por dos modos de falla que identifica en el enfoque convencional: la fuga por patrones de acceso, donde incluso las bases de datos fuertemente cifradas siguen revelando cuándo y con qué frecuencia un usuario las consulta, permitiendo mapear el comportamiento diario solo a través de metadatos; y el colapso de escalabilidad, donde la búsqueda vectorial semántica o las combinaciones entre múltiples sesiones sobre almacenamiento cifrado requieren extraer el texto cifrado a través de la red y descifrarlo en cada consulta, provocando "picos de latencia" a medida que crece el contexto. Colocar juntos la ejecución y el estado dentro de la memoria cifrada por el procesador, señala la publicación, significa que las lecturas nunca cruzan un límite de red externo.

El costo operativo de este diseño se manifiesta en la observabilidad, y la publicación lo reconoce abiertamente. Los diagnósticos de ingeniería estándar no funcionan dentro de un TEE: no se puede conectar un depurador, no hay volcados de memoria ante un fallo, no es posible inspeccionar el payload que provocó un error. Meta afirma que construyó su monitoreo únicamente en torno a señales agregadas de salud —utilización de CPU, asignación de memoria, latencia de red y tasas de falla de hardware— lo que significa que los ingenieros resuelven problemas en un sistema de producción para consultas de AI Glasses sin ver jamás una solicitud que falla.

La publicación no menciona cifras de benchmarks, ni datos de latencia, ni costos ni recuentos de parámetros de los modelos que se ejecutan dentro de estas CVMs —una omisión notable para un texto que plantea afirmaciones sobre escala. Lo que sí ofrece es un compromiso de validación por terceros: Meta afirma que colabora con firmas de seguridad independientes, incluida NCC Group, para auditar la lógica de atestación y el modelo de aislamiento, y que está ampliando su programa de Bug Bounty para cubrir explícitamente Private Processing en AI Glasses, proporcionando a investigadores externos los binarios de la CVM y documentación para poner a prueba la cadena de atestación. La publicación también señala dónde el diseño sigue siendo aspiracional y no está aún implementado: describe que Private Processing, hasta ahora, maneja "tareas discretas, como resumir un mensaje", mientras plantea el uso multisesión y agéntico —un agente que retiene estado sensible a través de contextos del mundo real— como una extensión futura que requiere atestación entre CVMs que aquí no está completamente especificada.

Para los equipos que construyen inferencia dividida entre dispositivo y nube para wearables, la lección operativa tiene menos que ver con los primitivos criptográficos y más con el costo de depuración: si el límite de confianza excluye a los propios ingenieros de inspeccionar payloads en vivo, la respuesta a incidentes debe rediseñarse en torno a telemetría agregada antes de lanzar, no después del primer fallo en producción.