Asignar una política a un dispositivo es solo la mitad del trabajo. La otra mitad es saber si el dispositivo ha hecho realmente lo que le pediste y, si no lo ha hecho, por qué. A eso responden las comprobaciones de conformidad.
Funcionan como una lista de incidencias abiertas. Cada entrada es un problema, titulada con lo que falla y desplegable para ver el detalle que hay detrás.
Las comprobaciones solo aparecen cuando hay algo que reportar. Un dispositivo con la lista vacía es un dispositivo sin nada pendiente: no hay entradas en verde confirmando que cada punto se supera. Aquí el silencio es la buena noticia.
Dónde consultarlas
Abre un dispositivo desde el listado y ve a la sección Overview, donde encontrarás los Compliance checks.
El escudo que aparece junto al campo de la política en el listado de dispositivos es el resumen de esa misma información, así que puedes triar el parque sin abrir los dispositivos uno a uno:
| Escudo | Qué significa |
|---|---|
| 🟢 Verde | El dispositivo es conforme. Nada que hacer. |
| ⚪ Gris | Hay al menos una comprobación abierta, y no es un problema de seguridad. |
| 🔴 Rojo | La postura de seguridad es En riesgo o Potencialmente comprometido. |
La diferencia entre gris y rojo merece interiorizarse. El gris es operativo: algo no ha llegado todavía, o un ajuste no está soportado. El rojo es un problema de confianza: el propio sistema operativo puede haber sido modificado. Piden respuestas completamente distintas.
Qué reporta cada plataforma
Las comprobaciones de conformidad son una vista común, pero cada dispositivo reporta solo lo que expone su propio sistema operativo. Que un bloque no aparezca no significa que falten datos: esa plataforma no tiene ese concepto.
| Comprobación | Apple | Android | AOSP |
|---|---|---|---|
| Versión de la política sin enviar | — | ✅ actual + deseada | ✅ actual |
| Perfil de configuración pendiente | ✅ | — | — |
| Apps pendientes | ✅ | — | — |
| Libros pendientes | ✅ | — | — |
| Fallos a nivel de ajuste | — | ✅ | ✅ |
| Postura de seguridad | — | ✅ | — |
Dos consecuencias que conviene tener claras antes de prometer nada a un cliente:
En Apple no obtienes fallos a nivel de ajuste. Ves lo que sigue pendiente, no un motivo por ajuste. Si una restricción no está surtiendo efecto en un iPhone, esta vista no te dirá por qué.
En AOSP no hay postura de seguridad, porque depende de la Play Integrity API. Se explica en Postura de seguridad del dispositivo.
Comprobaciones en Apple
Perfil de la política
El perfil de la política no está actualizado significa que el dispositivo no ha aplicado la versión actual del perfil de la política. Cuando lo que corresponde es retirarlo, la comprobación dice El perfil de la política debe ser desinstalado.
Apps
Cada app genera una comprobación, y el título te dice en cuál de las tres situaciones estás:
| Título | Qué significa |
|---|---|
| App no instalada | El dispositivo aún no tiene la app. |
| App no actualizada | La app está instalada, pero en una versión anterior a la desplegada. |
| La app debe desinstalarse | La app está en el dispositivo y no debería. |
Cada una muestra el Bundle ID, etiquetado con su origen — Applivery para las apps subidas a la plataforma, VPP para las licenciadas a través de Apple Business —, además de la versión esperada y, cuando la app ya está, la versión instalada. Comparar esas dos es lo que distingue una instalación fallida de una desactualizada.
Libros
Los libros funcionan igual: Libro no instalado o El libro debe ser desinstalado, mostrando el nombre del recurso si el libro se subió como asset, o el nombre de la App Store si se distribuye desde la tienda.
Comprobaciones en Android y AOSP
Versión de la política
La versión de la política aún no se ha enviado al dispositivo significa que el dispositivo sigue funcionando con una versión anterior a la asignada.
En Android la comprobación muestra la política actual y la política deseada, cada una con su versión, así que la diferencia se ve de un vistazo. En AOSP solo se muestra la actual.
Normalmente se resuelve solo en la siguiente sincronización. Si persiste, el dispositivo está desconectado o no puede aplicar alguno de los ajustes — en cuyo caso verás además una comprobación a nivel de ajuste indicando cuál.
Fallos a nivel de ajuste
Este es el bloque que responde a "qué ajuste ha fallado y por qué". Cada comprobación está titulada con el motivo y se despliega con el detalle:
| Campo | Qué te dice |
|---|---|
| Paquete | La app a la que afecta el problema, cuando afecta a alguna. |
| Campo | El ajuste exacto, o la ruta precisa del campo dentro de él en los ajustes con campos anidados. |
| Motivo | Una explicación más concreta cuando existe: un fallo de instalación de app, o un motivo específico de contraseña o de Wi-Fi. Se muestra en naranja. |
| Valor actual | Lo que el dispositivo tiene realmente, cuando el ajuste no se ha podido aplicar. |
| WiFi GUID | La configuración de red concreta afectada, en los problemas de Wi-Fi. |
Esa combinación es la que hace útil el bloque en soporte: no obtienes "el dispositivo no es conforme", sino el campo, el motivo y lo que el dispositivo tiene en su lugar.
Dos de ellos merecen una nota:
Los problemas de contraseña añaden el ámbito entre paréntesis: si el requisito aplica a todo el dispositivo o solo al perfil de trabajo. En dispositivos donde ambos van por separado, esa es la diferencia entre que el usuario cambie la contraseña correcta o la equivocada.
Los fallos de instalación de apps son donde el campo Motivo se gana su sitio. Distingue una instalación aún en curso de una app que no está aprobada, que se ha quedado sin licencias, que no está disponible en el país del usuario o que no es compatible con el dispositivo — y cada una se resuelve de forma completamente distinta.
Postura de seguridad
En Android, un dispositivo cuya postura esté en riesgo aparece como una comprobación en rojo, titulada En riesgo o Potencialmente comprometido, con el riesgo detectado y el consejo de Google para mitigarlo. Es la comprobación que hay detrás del escudo rojo y la única que no trata sobre tu configuración. Consulta Postura de seguridad del dispositivo.
Las comprobaciones informan, no aplican
Nada de esta vista bloquea un dispositivo ni lo borra por sí solo. Actuar sobre lo que encuentres es una decisión aparte:
Comandos remotos desde el panel, para una respuesta puntual sobre un dispositivo concreto.
Policy Enforcement Rules en Android, para bloquear y después borrar automáticamente pasados unos días. Reaccionan justo a los fallos a nivel de ajuste de más arriba, y no tienen equivalente en Apple.
Reglas de automatización, para aplicar automáticamente una política distinta a una audiencia de dispositivos.