Novedad en beta, aún no disponible
Trust Insights se anunció en la WWDC 2026 y llegará con iOS 27, iPadOS 27 y Mac Catalyst 27. Hoy estamos en la 26, así que todavía no puedes lanzarlo a producción. Esta entrada es un resumen conceptual de la sesión y la documentación preliminar: los nombres de la API y los detalles pueden cambiar antes del lanzamiento. Trátala como una guía y no como un tutorial listo para copiar y pegar.
La autenticación resuelve una pregunta: ¿quién eres? Pero hay un tipo de ataque que la deja completamente inútil, porque la persona que actúa es la legítima, con su cara, su huella y su contraseña. La persona está siendo guiada en tiempo real por un estafador. Trust Insights es el nuevo framework de Apple (iOS 27) que intenta responder a otra pregunta: ¿estás actuando libremente?
En esta entrada lo vemos de forma resumida: qué problema ataca, cómo se integra a nivel de app (todo es cliente, con una API de Swift), qué significan sus señales y cómo diseñar una respuesta que proteja a la persona, sin romper la experiencia de usuario y protegiendo su privacidad.
1. El problema: engaño, no hackeo
Las estafas en línea o "Social scams" (p.e. en redes sociales o apps de mensajería) tienen como objetivo atacar (o engañar) la psicología humana y no la posible vulnerabilidad técnica en, por ejemplo, una página web o app.
Cuando esto ocurre, la víctima realiza acciones legítimas y autenticadas, pero bajo presión, miedo o engaño. Tu app no puede distinguir esa intención genuina de la coaccionada.
Falso soporte técnico
Alertas falsas que empujan a dar acceso remoto y ceder el control del dispositivo.
Suplantación de autoridad
Hacerse pasar por el banco, alguna administración pública o la policía para obtener datos sensibles.
Falsa emergencia familiar
Peticiones urgentes de dinero que explotan el vínculo emocional, cada vez más con deepfakes generados por IA.
El hilo común es el coaching en tiempo real: el atacante guía a la víctima por teléfono o chat mientras ella ejecuta los pasos. La autenticación multifactor y la biometría no ayudan aquí, porque quien actúa es el usuario real. Hace falta una señal de otro tipo.
2. Qué es Trust Insights
Es un framework que aporta contexto conductual: en lugar de confirmar la identidad, estima si la acción parece libre o dirigida. Combina infraestructura de dispositivo y de nube, pero la integración es enteramente en el lado del cliente, con una API de Swift. No montas nada de servidor para empezar a usarlo.
Lo que sí analiza
- Patrones de interacción y de tiempo
- Contexto de la operación
- Datos básicos de sensores
Lo que nunca toca
- Contenido de Fotos, Mensajes o Mail
- Nada de eso sale del dispositivo
- Ni se comparte con Apple ni con terceros
Los datos de origen del dispositivo se procesan localmente y se descartan justo después de evaluar. Del dispositivo solo sale un único valor de salida, que Apple puede complementar con señales de la Apple Account y comprobaciones de velocidad para dar contexto adicional.
3. Cómo se integra (todo a nivel de app)
El flujo tiene cuatro piezas conceptuales. Todo ocurre en el cliente con la API de Swift.
import TrustInsights.schema es obligatorio; el modelVersion es opcional (indicar versión actual y previa ayuda a validar y gobernar modelos).
InsightContext define el operationCategory y las evaluaciones, y con él creas el InsightEvaluator. Antes de seguir, comprueba la autorización del usuario.requestEvaluation. Devuelve un resultado por cada evaluación pedida.Esquema conceptual (según la sesión, sujeto a cambios)
import TrustInsights
// 1. Comprobar que el usuario tiene Trust Insights habilitado para tu app
guard evaluator.isAuthorized else {
// Avisar al usuario o continuar con tu lógica de riesgo habitual
return
}
// 2. Pedir la evaluación (requiere conexión; puede tardar un par de segundos)
let result = try await evaluator.requestEvaluation()
// 3. Interpretar la señal y decidir la respuesta
switch result.coachingRisk {
case .unknown: ... // sin evidencia NO significa bajo riesgo
case .medium: ... // añadir fricción o verificación
case .high: ... // informar del riesgo antes de continuar
}Dónde colocar la llamada importa
La evaluación tarda un par de segundos y necesita conexión a Internet. Piensa bien en qué punto del flujo la haces: aprovecha animaciones o pantallas intermedias que ya tengas para que la espera no se note.
Las cinco categorías de operación
El operationCategory le dice al sistema qué tipo de acción está realizando el usuario, y determina qué lógica de modelo se aplica.
| Categoría | Para qué |
|---|---|
.payment | Cualquier intercambio de activos, contenido o dinero, incluidas las compras dentro de un juego. |
.account | Actualizar datos de la cuenta o información de seguridad. |
.resourceUse | Peticiones a infraestructura costosa o limitada, por ejemplo inferencia de IA (cuando un modelo de IA aplica sus conocimientos para analizar datos nuevos y generar una respuesta, ya sea de predicción o decisión). |
.communication | Enviar mensajes, remitir formularios o firmar documentos. |
.other | Otra alternativa (fallback) para operaciones que no encajen en ninguna de las anteriores. Si acabas aquí, puedes dar feedback a Apple sobre el encaje de tu categoría. |
4. Interpretar la respuesta
En este caso tendríamos que gestionar o interpretar unos de los tres resultados posibles para la solicitud de información IsLikelyBeingCoachedInsight ("¿es probable que le estén guiando?"). Tras estos tres valores hay un modelo de ML sofisticado, pero para tu lógica se resume en tres niveles.
unknown
El sistema no tiene indicios de riesgo. No lo interpretes como riesgo bajo.
medium
Indicios de coaching. Valora introducir fricción, verificación extra o ajustar tu puntuación de riesgo.
high
Riesgo alto. Se debe informar a la persona del riesgo detectado antes de que continúe.
La regla de oro
Nunca trates unknown ni un valor ausente como "riesgo bajo". Y maneja por separado los errores de evaluación y los de insight: significan cosas distintas. Bloquear una operación basándote solo en un trust insight tampoco se recomienda; es una señal más dentro de tu lógica de riesgo, no el juez único.
5. Cerrar el bucle: feedback
La integración no termina al leer el resultado. Hay dos tipos de feedback, y el primero es obligatorio.
Feedback en tiempo real: reportConsumption (obligatorio)
Por cada evaluación debes llamar a reportConsumption sobre el resultado para contar cómo respondió tu app. Si lo omites, tu app puede sufrir limitaciones de uso (rate-limit). Hay seis valores:
.usedReducedFriction: el insight ayudó a hacer la operación más fácil..usedUnchangedFriction: se evaluó pero no cambió la experiencia..usedIncreasedFriction: llevó a comprobaciones o fricción extra..notUsedNotNeeded: el usuario canceló; no hizo falta decidir..notUsedError: un fallo técnico impidió usarlo (por ejemplo, el resultado llegó tarde)..usedEvaluationOnly: se usó solo para evaluación interna o para comparar los procesos, productos, servicios o estrategias de tu empresa con otras organizaciones (benchmarking), sin afectar a la experiencia del usuario.
Feedback offline: etiquetas de fraude (opcional)
Cuando una operación evaluada resulta ser fraude confirmado, esa etiqueta ayuda a mejorar el modelo. Pueden llegar días, semanas o meses después. Aquí es donde entra la única parte de servidor: se envían por Apple Business Register con una API server-to-server. No es obligatorio para beneficiarte de Trust Insights, pero fortalece el ecosistema.
En la línea de este blog, nos quedamos en el lado del dispositivo. Solo un apunte de privacidad para esa vía de servidor: no incluyas PII ni información de más, y aplica técnicas que eviten el fingerprinting sobre cualquier valor que quede.
6. Privacidad por diseño
La minimización de datos es el centro del framework: procesa solo lo necesario, descarta las entradas de inmediato y mantiene en el dispositivo todo lo que deriva de él. Y el usuario manda.
Control del usuario
- Se puede desactivar en Ajustes.
- Al desactivarlo puede aplicarse un periodo de espera (cooldown period), precisamente para proteger a quien haya sido instruido para desactivarlo.
Comprueba la autorización
Consulta el estado de autorización para saber si el usuario tiene Trust Insights habilitado para tu app. Si no lo está, quizá quieras avisarle.
Un matiz para el desarrollador de la app cuando le resulta de aplicación el RGPD
Aunque el framework es de Apple, quien lo integra suele ser el responsable del tratamiento de los datos personales, y por tanto el obligado a cumplir con el RGPD. Que Trust Insights procese solo lo necesario, descarte las entradas de inmediato y deje salir un único valor encaja con el principio de minimización de datos (art. 5.1.c) y con la protección de datos desde el diseño y por defecto (art. 25). Adoptar una API pensada así es una de esas "medidas técnicas apropiadas" que el art. 25 espera de ti, y refuerza tu responsabilidad proactiva (art. 5.2). Ahora bien, no te exime del resto: seguirás necesitando una base de licitud, informar con transparencia y limitar la finalidad del tratamiento. Lo desarrollo en Privacidad desde el diseño en iOS.
7. Cuándo llamarlo y buenas prácticas
Elegir cuándo pedir un insight es tan importante como el cómo. Reserva la llamada para los momentos donde más aporta.
Transacciones financieras importantes
Pagos entre particulares, transferencias de importe alto.
Acciones irreversibles
Borrado de cuenta, exportación de datos personales.
Concesión de permisos
Acceso remoto, autorización de un dispositivo nuevo.
Compartir datos sensibles
Credenciales, documentos personales.
- Intégralo en tu lógica de riesgo existente. Nunca debe ser el único factor de una decisión.
- Muestrea versiones de modelo a lo largo del tiempo para entender cómo afectarían los modelos nuevos a tu lógica antes de actuar sobre ellos.
- Maneja los errores a todos los niveles: los de evaluación y los de insight tienen significado distinto.
- Diseña la intervención con criterio. El ejemplo de Apple: ante un
mediumen una transferencia grande a alguien que dice ser el médico de un familiar, la app muestra una advertencia y añade un retardo. También podrías revisar en servidor, añadir un paso de revisión manual o ajustar el riesgo sin interrumpir. Depende de tu app, tus usuarios y tu producto.
8. Conclusión
Trust Insights aporta algo que ninguna contraseña ni biometría da: contexto de si la persona actúa libremente. Llega en iOS 27, es cliente de principio a fin y está pensado con la privacidad por delante (datos que no salen del dispositivo, un solo valor de salida, control total del usuario). Cuando esté disponible, la idea es sencilla de resumir: pídelo en los momentos que importan, trátalo como una señal más y nunca unknown como riesgo bajo, y cierra el bucle con reportConsumption. Mientras tanto, es buen momento para ir pensando dónde encajaría en tu app y dar feedback a Apple por Feedback Assistant.
Bibliografía y fuentes consultadas
- Apple. Meet Trust Insights (sesión de la WWDC 2026).
- Apple Developer. Trust Insights (documentación del framework).
- Apple Developer. App Attest (framework complementario para verificar que las peticiones vienen de instancias legítimas de tu app).