La memoria de Google Private AI Compute desafía el modelo de privacidad sin estado de la nube
Google ha añadido memoria persistente del lado del servidor a Private AI Compute, superando el diseño sin estado que antes definía la IA en la nube centrada en la privacidad. El sistema busca recordar el contexto entre dispositivos mientras mantiene las claves de descifrado en hardware controlado por el usuario.
Se trata de un cambio significativo para la memoria de Google Private AI Compute. Hasta ahora, Google y Apple consideraban el olvido una protección de privacidad fundamental. Cada solicitud a la nube entraba en un entorno aislado, recibía una respuesta y salía sin contexto personal persistente.
Google sostiene ahora que un asistente no puede ofrecer una experiencia realmente continua si su entorno en la nube olvida todo tras cada solicitud. Su respuesta propuesta es una bóveda de memoria cifrada que permanece en la nube, pero que no puede abrirse sin claves derivadas del dispositivo.
La arquitectura crea una tensión directa entre continuidad y minimización de datos. Recordar más puede hacer que un asistente resulte más útil, pero también crea un objetivo duradero que los sistemas sin estado fueron diseñados para evitar.
Google dota de memoria a Private AI Compute
Google está convirtiendo un servicio de inferencia privada en una capa persistente de computación personal.
Google DeepMind dio a conocer la arquitectura el 23 de septiembre de 2026. Su actualización técnica describe una capa de memoria que conservará el contexto personal entre sesiones y dispositivos.
Private AI Compute amplió originalmente el trabajo exigente de IA más allá de un teléfono. Un dispositivo podía enviar una solicitud cifrada a la infraestructura protegida de Google cuando un modelo local no disponía de suficiente capacidad de cálculo.
Ese entorno en la nube procesaba la solicitud dentro de sistemas aislados por hardware. Después devolvía el resultado sin conservar el contexto personal de la sesión.
Google denomina sin estado a este diseño anterior. En términos prácticos, el servicio podía ayudar con una solicitud, pero no podía continuar de forma segura la misma experiencia más adelante.
La nueva capa de memoria cambia esa limitación. El contexto personal puede permanecer en una base de datos por usuario después de que termine una solicitud de inferencia. Google afirma que la información almacenada permanece cifrada y que las claves necesarias para desbloquearla siguen estando en los dispositivos del usuario.
Cuando un modelo autorizado necesita ese contexto, el dispositivo establece una conexión autenticada y cifrada de extremo a extremo con un entorno aislado en la nube. Ese enclave seguro descifra temporalmente la información necesaria en memoria protegida.
Un enclave seguro es un área reforzada por hardware que aísla el código y los datos del servidor en general. Ni siquiera el software de infraestructura con privilegios debería poder inspeccionar libremente la memoria activa del enclave.
Tras gestionar una solicitud, el sistema puede actualizar el contexto conservado. Luego vuelve a cifrar ese contexto antes de devolverlo al almacenamiento.
Esta estructura permite experiencias que resultaban difíciles bajo un modelo sin estado. Una conversación iniciada en un teléfono podría continuar en un portátil sin reconstruir manualmente su contexto.
Google también ofrece un ejemplo relacionado con gafas inteligentes. Una persona podría consultar instrucciones mediante las gafas y recuperar después el contexto relevante desde otro dispositivo.
La empresa no ha anunciado en la divulgación una fecha de lanzamiento general para consumidores. Describe la arquitectura como una capacidad que permitirá futuras experiencias de memoria persistente.
Esta distinción importa. Google ha revelado el modelo de seguridad, pero los lectores aún no cuentan con una lista completa de productos ni con controles estándar para inspeccionar las memorias almacenadas.
El anuncio aun así representa un cambio estratégico. Google ya no trata la inferencia privada en la nube y la personalización persistente como problemas separados.
Su anterior plataforma Private AI Compute se centraba en ejecutar cargas de trabajo Gemini más grandes sin aplicar patrones convencionales de acceso a la nube a solicitudes sensibles. La memoria persistente amplía la responsabilidad del sistema más allá del momento de la inferencia.
Ahora el servicio debe proteger la información durante la transmisión, el procesamiento activo, el almacenamiento a largo plazo, la recuperación posterior y la eliminación. Cada etapa añadida crea otro punto donde los errores de diseño podrían afectar a la privacidad.
Esa responsabilidad ampliada es la verdadera noticia. Google propone que la IA en la nube puede recordar a una persona con el tiempo sin otorgar a su operador acceso ordinario a esa memoria.
Por qué la IA en la nube sin estado ha llegado a su límite
La característica de privacidad que hizo más fácil confiar en la IA confidencial en la nube también la hizo menos capaz como asistente personal.
El procesamiento sin estado minimiza la cantidad de información personal que queda en un servidor. También limita la continuidad, porque el modelo inicia cada sesión protegida sin un registro duradero de interacciones anteriores.
Los desarrolladores pueden sortear ese problema guardando preferencias seleccionadas en otro lugar. Un asistente podría conservar el idioma preferido de un usuario, sus restricciones alimentarias o sus destinos habituales.
Sin embargo, una lista de hechos aislados no reproduce una conversación en evolución. No puede representar por completo el trabajo pendiente, las prioridades cambiantes ni las relaciones entre actividades realizadas en distintos dispositivos.
Los usuarios se enfrentan entonces a una elección repetitiva. Pueden explicar de nuevo el mismo contexto, permitir que una cuenta convencional en la nube lo almacene o aceptar un asistente menos personalizado.
La memoria de Google Private AI Compute pretende eliminar esa elección. Separa el almacenamiento cifrado persistente de las claves necesarias para que la información sea legible.
Esta separación importa porque los modelos avanzados de IA siguen requiriendo recursos considerables del servidor. Los teléfonos y portátiles pueden ejecutar modelos locales cada vez más capaces, pero no pueden realizar eficientemente todas las tareas de escala frontera.
La infraestructura en la nube ofrece modelos más grandes, aceleradores especializados y más memoria disponible. También traslada información sensible a un entorno controlado por otra organización.
La computación confidencial busca reducir esa brecha de confianza. Protege los datos mientras se utilizan, no solo mientras están almacenados o viajan por una red.
El cifrado convencional cubre los datos en reposo y en tránsito. Sin embargo, un servidor ordinario aún debe descifrar esa información en algún punto antes de que un modelo pueda procesarla.
Un entorno de ejecución confiable, o TEE, restringe esa etapa expuesta. El código autorizado opera sobre información legible dentro de un límite aislado, mientras que el host circundante no puede inspeccionarla directamente.
Google Cloud describe la computación confidencial como una forma de proteger cargas de trabajo sensibles durante el procesamiento. Sus aplicaciones incluyen analítica, aprendizaje automático y colaboración con conjuntos de datos protegidos.
Este enfoque no elimina todas las suposiciones de confianza. Cambia qué componentes deben ser confiables y proporciona a los dispositivos evidencia técnica sobre el entorno que recibe sus datos.
La memoria persistente incrementa la importancia de esas garantías. Una sola solicitud de inferencia expone una porción limitada de contexto durante un período limitado.
Una memoria de IA duradera puede acumular conversaciones, preferencias, documentos, ubicaciones y patrones de comportamiento. Su valor para el asistente también la vuelve valiosa para los atacantes.
Los trabajadores del conocimiento reconocerán el atractivo. Un asistente personal se vuelve más útil cuando puede conectar reuniones, archivos, decisiones y tareas pendientes a lo largo del tiempo.
El mismo principio respalda una base de conocimiento personal. Una recuperación útil depende de contexto persistente, una propiedad clara y controles que impidan el acceso de personas no relacionadas.
Google intenta aplicar esos principios a escala de nube. Debe preservar la continuidad sin convertir al proveedor en custodio de historiales personales legibles.
Esa presión se extiende más allá de Google. Todos los principales proveedores de asistentes quieren un contexto más duradero porque la continuidad mejora la finalización de tareas y reduce la necesidad de repetir indicaciones.
La pregunta difícil ya no es si los asistentes deberían recordar. Es si los usuarios pueden obtener memoria útil sin aceptar la visibilidad convencional del lado del servidor.
Cómo funciona la memoria de Google Private AI Compute
El diseño sitúa los recuerdos cifrados en la infraestructura de Google, mientras mantiene la autoridad práctica para desbloquearlos vinculada a los dispositivos personales.
Google describe el almacén de memoria como una bóveda digital segura. Cada usuario recibe almacenamiento aislado protegido con cifrado asociado a los dispositivos de ese usuario.
La arquitectura utiliza una clave de cifrado de datos, comúnmente llamada DEK, para cifrar la memoria almacenada. Una segunda clave protege esa DEK para que la base de datos no contenga un secreto de desbloqueo directamente utilizable.
El diagrama de Google identifica esta segunda capa como una disposición de clave de cifrado de claves. El dispositivo participa en la derivación o protección del material de clave necesario para desenvolver los datos almacenados.
Este diseño significa que robar la base de datos cifrada no debería bastar para revelar su contenido. Un atacante también necesitaría acceso a la ruta de claves autorizada y a un entorno de procesamiento aprobado.
Cuando el asistente necesita contexto, el cliente primero verifica el entorno remoto. Este proceso se denomina atestación remota.
La atestación remota permite que un dispositivo compruebe las afirmaciones sobre el hardware y el software en ejecución del servidor antes de divulgar información sensible. Un informe válido debería mostrar que el código aprobado opera dentro del enclave esperado.
El dispositivo crea entonces un canal cifrado hacia ese entorno. La memoria se descifra únicamente dentro de memoria aislada después de que el sistema supere las comprobaciones requeridas.
El modelo puede utilizar el contexto para responder a una solicitud. También puede producir nueva información que el servicio de memoria almacena para una interacción posterior.
Google afirma que ni los administradores ni los servicios ordinarios en la nube pueden inspeccionar esa información. También sostiene que la arquitectura vuelve los datos inaccesibles incluso para Google.
Esa afirmación depende de más que el cifrado. El dispositivo debe verificar correctamente el servidor, el enclave debe hacer cumplir el aislamiento y el software debe evitar filtrar datos a través de sus resultados.
La gestión de claves también se vuelve central. Un sistema privado puede seguir fallando si la recuperación de la cuenta, el reemplazo de dispositivos, la sincronización o la revocación introducen discretamente una ruta de acceso alternativa.
Google no ha detallado por completo esos escenarios del ciclo de vida del usuario en su anuncio público. Influirán en el grado en que el sistema implementado cumpla su promesa arquitectónica.
Por ejemplo, perder todos los dispositivos de confianza plantea una decisión difícil. Las claves fuertes vinculadas únicamente al dispositivo podrían hacer que la memoria sea irrecuperable de forma permanente.
Un mecanismo conveniente de recuperación controlado por el proveedor reduciría ese riesgo. También podría crear otra vía mediante la cual alguien distinto del usuario obtenga acceso.
Añadir un teléfono nuevo plantea una cuestión relacionada. El sistema debe transferir autoridad a ese dispositivo sin revelar claves a un intermediario ni aceptar un registro no autorizado.
La eliminación también debe abarcar más que retirar una entrada de memoria visible. Los usuarios necesitan confiar en que las claves retiradas, réplicas, copias de seguridad, cachés y contexto derivado no puedan restaurar posteriormente información supuestamente eliminada.
Estos son requisitos operativos normales, no pruebas de que el diseño de Google sea defectuoso. Muestran por qué la memoria privada de IA implica más que colocar una base de datos detrás de un enclave.
La propia ruta de inferencia contiene varios componentes. Una evaluación independiente anterior describió conexiones de clientes cifradas, servicios frontend, sistemas de orquestación, módulos de seguridad de IA e infraestructura TPU reforzada.
Esos componentes se autentican entre sí y usan atestación para establecer rutas de comunicación aprobadas. Cada servicio adicional debe mantenerse dentro del límite de privacidad previsto.
Google también planea publicar un registro resistente a manipulaciones del software de servidor. Un cliente puede comparar la medición de software atestada del servidor con un registro público antes de enviar datos personales.
Este mecanismo aborda un riesgo sutil de la nube. Un proveedor podría publicar código seguro para su revisión, pero operar software distinto en producción.
Un registro de transparencia de solo anexado dificulta una sustitución no detectada. Los investigadores pueden inspeccionar las compilaciones enumeradas, mientras que los dispositivos rechazan entornos que no coinciden con las mediciones autorizadas.
El mecanismo no demuestra que todas las compilaciones autorizadas estén libres de vulnerabilidades. Aporta pruebas de que el software inspeccionado corresponde a aquello en lo que los dispositivos tienen permitido confiar.
Esta distinción es importante. La transparencia hace posible el escrutinio, pero este sigue requiriendo artefactos accesibles, investigadores capacitados y tiempo.
La promesa de privacidad sigue teniendo un límite de hardware
Google puede reducir el poder de los administradores de la nube, pero no puede eliminar toda dependencia del hardware y software diseñados por Google.
Google encargó a NCC Group la evaluación de partes seleccionadas de Private AI Compute a partir de la primavera de 2025. Diez consultores dedicaron, según se informa, 100 días-persona a revisiones de arquitectura y componentes.
La revisión independiente examinó la biblioteca criptográfica Oak Session, la atestación remota, el relé de ocultación de IP, el registro de transparencia y código de servidor seleccionado. Ese trabajo aporta más sustancia que una afirmación de producto sin auditoría.
Sin embargo, su alcance importa. Una revisión de componentes seleccionados no certifica todas las futuras funciones de memoria, implementaciones de cliente, revisiones de hardware o procedimientos operativos.
La evaluación también identifica un límite fundamental. Actualmente, la inferencia práctica de IA opera sobre datos legibles dentro de algún sistema de computación físico.
Por tanto, la información cifrada se convierte en texto plano dentro del procesador protegido durante el cálculo. El hardware y el código aprobado pueden acceder a ella porque deben realizar el trabajo solicitado.
El informe de NCC señala que los diseñadores de hardware conservan la capacidad teórica de crear una vía de exfiltración en sus chips. Private AI Compute depende, en última instancia, de que la plataforma TPU reforzada de Google se comporte como se describe.
Esta limitación se aplica ampliamente a la computación confidencial. Los enclaves reducen la exposición a hipervisores, administradores y software de host comprometido, pero no hacen que la computación física esté libre de confianza.
Los ataques de canal lateral plantean otra preocupación. Estos ataques infieren información protegida a partir de comportamientos observables, como la temporización, el acceso a memoria, la contención de recursos o el uso de energía.
Las plataformas confidenciales añaden mitigaciones continuamente, pero nuevas vulnerabilidades de hardware pueden alterar supuestos de seguridad previos. Por ello, el argumento de privacidad de un sistema debe evolucionar con el panorama de amenazas.
El software dentro del enclave también puede cometer errores. Un modelo o servicio de apoyo podría revelar detalles sensibles en una salida, incluso si el almacenamiento subyacente sigue protegido criptográficamente.
La inyección de prompts presenta un desafío relacionado. El contenido malicioso puede manipular a un asistente para recuperar o revelar información que el usuario no pretendía compartir en ese contexto.
El enclave no puede decidir automáticamente si una solicitud representa la intención real del usuario. Ejecuta software autorizado conforme a las políticas implementadas por los desarrolladores.
El contexto persistente eleva las consecuencias porque puede haber más información disponible durante una interacción comprometida. Los controles de acceso deben limitar qué memorias puede recuperar cada función.
El sistema también necesita protecciones frente a inferencias a partir de metadatos. El tamaño del almacenamiento, la frecuencia de acceso, la temporización del dispositivo y los patrones de red pueden revelar información sin exponer el contenido exacto de la memoria.
La arquitectura anterior de Google incluye un relé de ocultación de IP diseñado para separar la identidad del usuario de las solicitudes. El sistema persistente debe conservar protecciones similares en las lecturas y actualizaciones de memoria.
Los investigadores han propuesto enfoques más abiertos para la IA confidencial. El artículo OpenPCC de 2026 sostiene que los primeros sistemas de Google y Apple dependen en gran medida de infraestructura propietaria.
Sus autores crearon un prototipo de código abierto con entornos de ejecución confiables disponibles comercialmente. Su crítica pone de relieve una cuestión clave de verificación para Google.
Los investigadores externos necesitan suficiente código, mediciones y herramientas para probar las afirmaciones significativas sobre privacidad. Un registro público por sí solo no crea reproducibilidad completa.
Google afirma que está publicando detalles actualizados de arquitectura, pruebas de seguridad, protocolos de verificación y resultados de auditorías. La profundidad de esa divulgación determinará hasta qué punto los investigadores pueden evaluar de forma independiente la capa de memoria.
Por ello, los usuarios deberían interpretar «inaccesible incluso para Google» como un objetivo de seguridad respaldado por controles en capas. No es una afirmación que no requiera confianza en Google.
La arquitectura reduce el número de personas y sistemas capaces de ver el contexto personal. También dificulta técnicamente más el acceso no autorizado y facilita su detección.
Es un estándar más sólido que una base de datos en la nube convencional protegida principalmente por políticas y controles de acceso administrativos. Aun así, no equivale a mantener toda la información en hardware desconectado.
El modelo sin estado de Apple es ahora el principal contrapunto
Google apuesta a que la persistencia privada puede superar al olvido estricto sin debilitar el límite efectivo de privacidad del usuario.
Private Cloud Compute de Apple ofrece la comparación más clara. Apple diseñó PCC en torno al procesamiento sin estado, el acceso administrativo limitado, la imposibilidad de dirigir solicitudes a nodos concretos y la transparencia verificable del software.
Su arquitectura de seguridad indica que los datos del usuario no deberían permanecer tras completarse una solicitud. Las claves de cifrado para el volumen de datos de un nodo cambian al reiniciarse y no se conservan.
Apple también elimina las herramientas de depuración interactiva y los registros de propósito general de los nodos PCC. Su modelo público considera la imposibilidad de conservar datos de usuario como una propiedad exigible.
Google compartía gran parte de esa filosofía sin estado cuando lanzó Private AI Compute. La memoria persistente en el servidor crea ahora una división visible entre ambos enfoques.
El modelo de Apple minimiza el estado duradero en la nube. El nuevo diseño de Google acepta un estado cifrado duradero porque considera esencial la continuidad entre dispositivos para la IA personal.
Ninguna postura resuelve todos los problemas. El procesamiento sin estado protege frente a la acumulación a largo plazo, pero limita la capacidad de un asistente para retomar el trabajo de forma natural.
La memoria cifrada persistente permite una personalización más rica. Crea un ciclo de vida más amplio que abarca creación, recuperación, modificación, transferencia, retención y eliminación.
La comparación no se limita a Google frente a Apple. Representa dos definiciones de lo que la IA privada en la nube debería garantizar.
Una definición sostiene que la computación privada debe olvidar después de cada tarea. La otra sostiene que debe recordar, pero solo mediante claves y software autorizados por el dispositivo del usuario.
Apple también ha ampliado PCC a la infraestructura de Google Cloud para cargas de trabajo exigentes. Afirma que los dispositivos Apple siguen confiando únicamente en software aprobado criptográficamente por Apple.
Esta asociación muestra que la propiedad del hardware y el control de la privacidad no siempre pertenecen a la misma organización. La atestación de software puede permitir que una empresa imponga requisitos sobre la infraestructura de otra.
Sin embargo, Apple sigue describiendo PCC como un sistema sin estado. Por tanto, la capa persistente de Google va más allá de la propiedad que Apple presenta como una salvaguarda central.
La diferencia se hará tangible a través del comportamiento del producto. Un asistente sin estado necesita contexto del dispositivo o de un almacén independiente controlado por el usuario cada vez que entra en la nube.
El enfoque de Google permite que el entorno de nube protegido recupere directamente el contexto previo tras la autorización del dispositivo. Esto puede reducir la latencia, las transferencias repetidas y las brechas entre productos.
También podría aumentar la dependencia del formato de memoria de Google y de su sistema de inscripción de dispositivos. A los usuarios podría resultarles difícil inspeccionar o transferir un historial optimizado para un asistente interno.
La portabilidad no se aborda en el anuncio. Tampoco los formatos estándar de exportación, los valores predeterminados de retención ni la posibilidad de ejecutar servicios de memoria compatibles en otro lugar.
Estas cuestiones afectan tanto a la competencia como a la privacidad. Una memoria útil se convierte en un activo personalizado que mejora con el tiempo.
Si ese activo permanece vinculado a un solo asistente, cambiar de servicio implica perder el contexto acumulado o exponerlo durante la migración. El cifrado no evita por sí solo el bloqueo de proveedores.
Google puede reforzar su posición proporcionando a los usuarios controles claros de inspección, exportación, corrección y eliminación. También puede documentar cómo se mueve la memoria cuando las personas cambian de dispositivo o de cuenta.
Apple, por su parte, enfrenta presión para demostrar que su diseño sin estado puede ofrecer una continuidad comparable. Podría depender más del almacenamiento cifrado en el dispositivo y sincronizar solo el contexto mínimo necesario para cada solicitud.
Otros proveedores de asistentes se enfrentan a la misma decisión. Pueden mantener la memoria en bases de datos de cuentas convencionales, adoptar infraestructura confidencial o dejar el contexto a largo plazo en dispositivos controlados por el usuario.
El diseño de Google hace que el almacenamiento ordinario en el servidor parezca menos defendible para asistentes altamente personales. Una vez que existen controles más sólidos, los usuarios conscientes de la privacidad pueden preguntarse por qué los competidores no los utilizan.
Qué deberían observar los usuarios y los investigadores a continuación
La arquitectura se ganará la confianza mediante controles desplegados y escrutinio externo, no solo con su diagrama.
La primera señal es el lanzamiento del producto. Google debe identificar qué experiencias de Gemini usan memoria persistente de Private AI Compute y cuáles siguen utilizando otros sistemas de almacenamiento.
Un indicador visible debería informar a los usuarios cuando una solicitud entra en el entorno protegido. Google ya proporciona información de red de Private AI Compute en dispositivos Pixel compatibles.
La memoria persistente necesita controles igual de claros. Los usuarios deberían poder ver qué se retuvo, por qué se recuperó y qué dispositivo autorizó la operación.
Esa interfaz revelará si la privacidad de la memoria de IA de Google resulta comprensible fuera de un documento de seguridad. Las memorias ocultas o excesivamente amplias debilitarían el valor práctico de la arquitectura.
La segunda señal es la verificación independiente. Los investigadores necesitan registros de software utilizables, herramientas de inspección, pruebas de atestación y documentación para los nuevos componentes de memoria.
El registro de transparencia de Google debería cubrir todos los servicios críticos para la seguridad que puedan recuperar o actualizar contexto persistente. Una cobertura parcial podría dejar código importante fuera del escrutinio público.
Las evaluaciones futuras deberían probar la ruta de memoria desplegada, y no solo la infraestructura anterior sin estado. Deberían examinar la gestión de claves, la inscripción de dispositivos, la eliminación, la recuperación y la resistencia a entradas maliciosas.
La investigación pública sobre vulnerabilidades importará más que el número de documentos publicados. Hallazgos creíbles, correcciones y plazos de divulgación mostrarán cómo se comporta la plataforma bajo presión.
La tercera señal es la respuesta competitiva. El compromiso de Apple con el procesamiento sin estado sirve ahora como una alternativa clara frente a la que puede juzgarse el diseño de Google.
Si Google ofrece una continuidad útil entre dispositivos sin fallos materiales de privacidad, el modelo estrictamente sin estado podría empezar a parecer innecesariamente limitante. Los competidores enfrentarían presión para añadir persistencia protegida.
Si la recuperación, la eliminación o la verificación resultan opacas, la arquitectura de Google basada en olvidar por defecto gana respaldo. El mismo resultado favorecería a los asistentes que conservan los recuerdos localmente.
Los compradores empresariales también deberían vigilar si Google adapta el sistema para los datos organizativos. Las claves de dispositivos personales no se trasladan fácilmente a la rotación de empleados, la retención legal o los espacios de trabajo compartidos.
Una empresa puede necesitar que los administradores recuperen registros o retiren accesos. Esos requisitos pueden entrar en conflicto con la promesa de que ni siquiera el proveedor puede descifrar el contexto almacenado.
Los desarrolladores deberían examinar el eventual modelo de acceso. Una capa de memoria privada necesita permisos estrictamente delimitados para que una aplicación no pueda recuperar contexto creado para una finalidad no relacionada.
Los usuarios no deberían asumir que todas las funciones de IA de Google reciben automáticamente estas protecciones. Private AI Compute es una arquitectura específica, no una etiqueta universal para todo el procesamiento en la nube.
La documentación del producto debe indicar cuándo se activa el sistema y qué sucede cuando no está disponible. El comportamiento de respaldo puede debilitar la privacidad si las solicitudes pasan silenciosamente a un servicio menos protegido.
La memoria de Google Private AI Compute aborda una debilidad real de los asistentes privados en la nube. Los sistemas sin estado protegen a los usuarios al olvidar, pero tienen dificultades para respaldar el trabajo continuo entre dispositivos.
La alternativa de Google es técnicamente ambiciosa y conceptualmente sencilla. Almacenar el contexto de forma remota, conservar las claves con el usuario y descifrar únicamente dentro de software verificado.
La parte difícil comienza cuando ese diseño sale del diagrama. La recuperación de cuentas, la migración de dispositivos, los límites de acceso, la transparencia, la eliminación y los defectos de software determinarán su nivel real de privacidad.
Para los usuarios, la acción inmediata es sencilla. Comprueben si las futuras funciones de memoria de Gemini identifican Private AI Compute, muestran el contexto conservado y ofrecen controles de eliminación directos.
Para los investigadores, la prueba es más exigente. ¿Pueden expertos independientes verificar el software de producción, reproducir la cadena de confianza y detectar debilidades significativas antes que los atacantes?
Google ha propuesto que los asistentes en la nube ya no tienen que elegir entre memoria y privacidad. Las próximas versiones deberán demostrar si la memoria segura del lado del servidor puede cumplir esa promesa con el tiempo.
