Apple baja la complejidad, no la fricción: qué cambia de verdad para las apps reguladas en la UE fuera del App Store

Apple ha movido ficha donde más le dolía: el bolsillo de los desarrolladores y la paciencia de Bruselas. Desde el 1 de octubre de 2026, cobrará una comisión del 5% por transacciones digitales en apps distribuidas fuera del App Store en la Unión Europea, dentro de un nuevo esquema con el que intenta cerrar su pulso con la Comisión bajo la Digital Markets Act. Sobre el papel, parece una simplificación. En la práctica, para cualquier app regulada —fintech, insurtech, salud digital, identidad, firma electrónica o servicios con IA— el cambio abre otra discusión menos vistosa y bastante más incómoda: cuando Apple deja de ser el cuello de botella comercial, también deja de absorber parte de la fricción operativa, contractual y de control.

Ese es el detalle que suele perderse entre porcentajes y comunicados. Menos dependencia del App Store no significa menos riesgo. Significa riesgo repartido entre más actores: marketplaces alternativos, procesadores de pago, proveedores antifraude, SDKs de analítica, herramientas de KYC, motores de IA y equipos legales que hasta ayer vivían razonablemente cómodos con un único canal de distribución. La competencia entra. Con ella, entra también una matriz de responsabilidades mucho más fea.

Tesis editorial

La UE ha conseguido que Apple afloje un poco el control económico del ecosistema iOS. Bien. Pero conviene no confundir apertura de mercado con madurez de control. Para las apps reguladas, este giro no abarata el cumplimiento: lo redistribuye. Y a veces lo encarece.

Si tu empresa desarrolla o distribuye una app financiera, de pagos, identidad o salud en iOS, el problema no es solo si Apple cobra un 5%, un 20% o si Epic llama “junk fees” a todo lo que se mueve. El problema serio es otro: quién responde cuando el recorrido de datos personales, logs de seguridad, credenciales, eventos de fraude y evidencias de consentimiento deja de pasar por un carril relativamente uniforme y empieza a cruzar varios operadores. Ahí es donde el debate deja de ser antitrust y se convierte en compliance de verdad.

La ironía regulatoria es bastante elegante. Durante años, el jardín vallado de Apple fue criticado por anticompetitivo. Con razón. Pero ese mismo jardín, por restrictivo que fuera, daba una arquitectura de distribución más predecible. La apertura exigida por la DMA no elimina el deber de control; lo complica. Y la Comisión haría mal en celebrar la simplificación tarifaria como si el trabajo estuviera hecho. El trabajo, para regulados y supervisores, empieza ahora.

Qué ha cambiado exactamente y por qué importa más de lo que parece

Reuters informó el 18 de agosto de 2026 de que Apple aplicará un 5% de “Core Technology Commission” a las transacciones digitales realizadas en apps distribuidas fuera del App Store en la UE. Al mismo tiempo, mantiene para apps dentro del App Store que usan pagos alternativos una comisión del 20%, reducible al 10% en el programa para pequeñas empresas. Apple elimina además dos piezas del esquema anterior: la initial acquisition fee y la store services fee. La fecha de efecto es el 1 de octubre de 2026. La Comisión Europea ha dicho que acoge favorablemente los cambios y vigilará su implementación.

Hasta aquí, la crónica. Lo interesante viene después. Apple no está solo retocando precios: está homogeneizando un modelo de términos para la UE que se parece más al que usa en otros mercados abiertos parcialmente, como Japón y Brasil. Eso tiene dos consecuencias prácticas.

La primera: el incentivo económico para ir fuera del App Store mejora para determinados casos de uso, sobre todo cuando el margen unitario es estrecho o cuando el desarrollador quiere controlar la relación comercial directa con el cliente. Esto importa en suscripciones, servicios financieros embedded, seguros on-demand, telemedicina y software B2B con módulos premium.

La segunda, bastante menos simpática: si aumentan los canales alternativos, aumentan las combinaciones posibles de tratamiento de datos, autenticación, atención al cliente, resolución de incidencias, reversos, chargebacks, fraude y notificación regulatoria. Lo que antes podía resolverse con un número limitado de contratos y flujos ahora exige cartografía fina. Si no la tienes, no estás “innovando”; estás improvisando con exposición legal.

El punto ciego: Apple sale un poco del centro y los terceros entran de lleno

Las organizaciones reguladas llevan años aprendiendo una lección a golpes, especialmente desde DORA: el riesgo crítico rara vez está donde el organigrama cree que está. Está en terceros, cuartos y quintos. Y abrir iOS en la UE multiplica precisamente eso: la capa de terceros.

Piensa en una app de inversión distribuida por un marketplace alternativo en iOS. El flujo puede incluir, como mínimo, al operador del marketplace, al procesador de pagos, a un proveedor de prevención de fraude, a un motor de biometría o liveness para onboarding, a un SDK de analítica móvil, a un proveedor cloud, a un servicio de mensajería push, a una herramienta de observabilidad y quizá a un modelo de IA para asistencia al cliente o scoring antifraude. Si además el servicio incorpora firma electrónica avanzada o identidad digital, aparecen prestadores de confianza o proveedores KYC adicionales. Cada uno añade una superficie contractual y técnica. Cada uno puede tocar datos personales, telemetría, credenciales o señales de riesgo. Cada uno puede fallar.

DORA no aplica a Apple por ser Apple, sino a las entidades financieras cubiertas y a su gestión de riesgo sobre terceros TIC. Ahí manda el capítulo V y, de forma muy concreta, el art. 28, que obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC como parte integral del marco de gestión del riesgo. Si la apertura del ecosistema iOS te lleva a incorporar un marketplace alternativo o a depender de nuevos proveedores para pagos y distribución, eso no es un detalle comercial. Es una entrada en el perímetro de third-party risk que debe inventariarse, evaluarse, documentarse y, cuando proceda, someterse a cláusulas contractuales reforzadas.

La pregunta útil no es “¿podemos distribuir fuera del App Store?”. La pregunta útil es “¿hemos rehecho el mapa de dependencias, datos y evidencias para soportarlo sin romper DORA, GDPR y el resto?”. Son dos conversaciones muy distintas. La primera la suele ganar negocio. La segunda decide si dormirás tranquilo cuando llegue auditoría o incidente.

GDPR: el reparto de responsabilidades se vuelve bastante menos cómodo

En protección de datos, la apertura del ecosistema iOS no crea obligaciones nuevas en abstracto. Lo que cambia es el reparto de hechos que activan obligaciones ya existentes. Y ahí está la trampa.

Si una app se distribuye a través de un marketplace alternativo o desde la web, el desarrollador gana margen comercial, pero también asume más control efectivo sobre el journey del usuario: adquisición, consentimiento, onboarding, soporte, pagos, devoluciones, comunicaciones y, a veces, actualizaciones. Cuanto más controlas, más difícil es esconderse detrás de la ficción de que otro actor llevaba la parte delicada.

El GDPR exige, en su art. 5.2, responsabilidad proactiva. En el art. 24, medidas apropiadas del responsable. En el art. 25, protección de datos desde el diseño y por defecto. En el art. 28, garantías contractuales del encargado. Y si hay corresponsabilidad real, el art. 26 pide repartir de forma transparente las respectivas obligaciones. Este último punto va a dar guerra: muchos acuerdos de ecosistema intentan resolver la complejidad con redacciones ambiguas. Mala idea. Si dos actores determinan conjuntamente fines y medios de una parte del tratamiento, el regulador no se impresionará por una cláusula creativa escrita a las 23:40 por legal de producto.

La reapertura de la distribución también puede alterar el análisis de bases jurídicas y transparencia. Si el desarrollador captura más datos de adquisición o comportamiento fuera del entorno estándar del App Store, deberá revisar sus notices, CMPs si aplica, minimización, retención y uso secundario de datos. El hecho de que técnicamente puedas medir más no vuelve automáticamente lícito medir más. Parece obvio, pero 2026 sigue siendo un año excelente para descubrir que mucha telemetría móvil se recogía “porque sí”.

Otro frente muy concreto es la gestión de brechas. El art. 33 GDPR mantiene la obligación de notificar a la autoridad competente en un máximo de 72 horas desde que el responsable tenga constancia de una violación de seguridad de los datos personales, salvo que sea improbable que entrañe riesgo para los derechos y libertades de las personas físicas. Si el incidente ocurre en un actor nuevo del chain —marketplace alternativo, proveedor de pago, componente de autenticación— el reloj no se detiene porque el contrato no estuviera claro. Si tu equipo tarda 36 horas en averiguar quién custodiaba qué logs, ya vas tarde.

Esto obliga a dos cosas muy poco glamourosas y muy necesarias: matrix de notificación entre terceros y ejercicios de mesa que contemplen incidentes fuera del canal App Store. Si no los has probado, tu cumplimiento es teórico. Y el cumplimiento teórico sirve hasta el primer incidente, luego decora expedientes sancionadores.

DMA, sí; pero la historia real para regulados se escribe entre contratos, SDKs y evidencias

La base política del cambio es la Digital Markets Act, que fuerza a los gatekeepers a no bloquear la contestabilidad del mercado. Perfecto. El problema es que la DMA no sustituye las demás capas regulatorias. Las superpone.

En otras palabras: que Apple tenga que abrir más el ecosistema no exime al desarrollador de probar seguridad, legalidad del tratamiento, resiliencia operativa o gobernanza de terceros. De hecho, puede endurecer la prueba. Antes bastaba con conocer muy bien un canal dominante. Ahora toca conocer varios y demostrar coherencia entre ellos.

En una entidad financiera sujeta a DORA, el inventario de activos y dependencias debe reflejar dónde se distribuye la app, cómo se actualiza, qué servicios críticos soportan autenticación, pagos, comunicación con clientes y prevención de fraude. Si el marketplace alternativo o la web app se convierten en vía principal o material para determinados clientes, ese canal pasa a ser una dependencia relevante para el servicio. El art. 11 de DORA exige un marco sólido y completo de gestión del riesgo TIC; el art. 15 obliga a detección de actividades anómalas; el art. 17 a respuesta y recuperación. Ninguna de esas obligaciones pregunta con ternura si el incidente ocurrió dentro del App Store oficial o en una ruta alternativa más barata.

También hay un ángulo de outsourcing y concentración. Muchas empresas, al salir del carril Apple, tenderán a concentrar funciones en nuevos intermediarios “all-in-one”: distribución, pagos, antifraude, analítica y CRM. Comercialmente suena eficiente. Regulatoriamente, puede ser una invitación a recrear otro gatekeeper, esta vez sin el escrutinio histórico de Apple y quizá con controles más inmaduros. Cambiar una dependencia hiperconocida por otra menos auditada no es diversificación; es maquillaje.

NIS2: si el canal alternativo falla, la autoridad querrá saberlo antes de que acabes el PowerPoint

NIS2 aprieta donde antes había demasiada poesía. El art. 21 exige medidas técnicas, operativas y organizativas apropiadas para gestionar riesgos de seguridad de redes y sistemas de información. No es una lista aspiracional: incluye gestión de incidentes, continuidad, seguridad de la cadena de suministro, desarrollo seguro, políticas para evaluar la eficacia de medidas de gestión de riesgos y prácticas básicas de ciberhigiene.

La cadena de suministro, precisamente, es el terreno donde la apertura de iOS cambia el mapa. Un operador esencial o importante que distribuya servicios a través de nuevos canales móviles debe revisar si esos canales entran en su scope de seguridad, monitorización y reporte. Si una dependencia alternativa compromete disponibilidad, integridad o confidencialidad de un servicio crítico, no valdrá alegar que el problema vino “del marketplace”. NIS2 no premia las excusas delegadas.

Los plazos de reporte de NIS2 tampoco están diseñados para organizaciones que necesiten varios días para decidir quién era el dueño del problema. El art. 23 establece una alerta temprana sin demora indebida y, en todo caso, en 24 horas desde que se tenga conocimiento de un incidente significativo; una notificación de incidente en 72 horas; y un informe final en el plazo de un mes. Si el nuevo modelo de distribución introduce más actores y más puntos de fallo, la capacidad de correlacionar señales y escalar rápido se vuelve decisiva.

Aquí se juntan DORA y NIS2 de forma incómoda pero útil. DORA pide gobernanza y testing; NIS2 exige medidas y reporte en sectores cubiertos; ambos castigan la opacidad operacional. Y ambos se llevan mal con arquitecturas improvisadas alrededor de un cambio comercial que se ha vendido internamente como “solo una comisión nueva”. No, no es solo eso.

AI Act y fraude: la apertura de canales puede disparar la dependencia de modelos poco gobernados

La noticia no va de IA, pero el mercado sí. En 2026, casi cualquier app regulada que revise su funnel móvil está tocando algún componente de IA: scoring antifraude, personalización, soporte conversacional, detección de anomalías, clasificación documental en onboarding o verificación de identidad asistida por machine learning. La apertura de iOS y la mayor libertad en distribución y pagos pueden acelerar esa adopción porque el desarrollador controla más del recorrido comercial y quiere optimizar conversión, prevención de abandono y monetización. El riesgo es obvio: se sube la exposición a modelos sin la gobernanza adecuada.

El AI Act entra aquí por dos puertas. La primera es la clasificación de determinados sistemas de IA utilizados en servicios financieros o para evaluación de riesgos vinculados a personas físicas. La segunda, los deberes sobre transparencia, calidad de datos, supervisión humana, gestión del riesgo, registro y monitoreo post-market para sistemas de alto riesgo, según el régimen aplicable. No todo motor antifraude será automáticamente “alto riesgo”, pero muchos casos de uso en banca, seguros e identidad merecen análisis serio, no optimismo automático del proveedor.

¿Qué controles recomendaría a una entidad financiera o aseguradora que aproveche los nuevos canales de iOS y meta más IA en onboarding o fraude? Cuatro muy concretos.

Primero, inventario de modelos y decisiones asistidas por IA dentro del recorrido móvil, con mapeo de qué datos entran, qué proveedor participa y qué output afecta a clientes o empleados.

Segundo, validación ex ante de sesgo, precisión, drift y explicabilidad operativa en procesos sensibles, especialmente si el modelo puede bloquear altas, pagos o autenticación reforzada.

Tercero, override humano real para casos de excepción y reclamaciones. “Human in the loop” no es dejar un correo compartido y rezar.

Cuarto, logging preservable y usable para auditoría e incidentes. Si el modelo participa en una decisión relevante y luego ocurre fraude o discriminación alegada, necesitarás evidencia, no folklore técnico.

La combinación peligrosa es bastante conocida: nuevo canal + presión de conversión + proveedor con marketing exuberante + gobernanza lenta. Sale cara. A veces en pérdidas por fraude; a veces en reclamaciones; a veces en ambos frentes a la vez.

eIDAS 2.0, identidad y confianza: más distribución no equivale a más confianza

Para servicios de identidad digital, firma electrónica, onboarding remoto o credenciales verificables, el cambio en iOS toca una fibra sensible: la experiencia de confianza. eIDAS 2.0 está empujando el ecosistema europeo hacia carteras de identidad digital y servicios de confianza más interoperables. Eso no significa que cualquier nuevo canal de distribución de apps herede automáticamente la confianza que el usuario atribuye a una tienda oficial muy reconocible.

Una app legítima distribuida por un marketplace alternativo puede encontrar más fricción en adopción precisamente porque el usuario tiene menos referencias. Esa fricción comercial tiende a compensarse con más mensajería, más telemetría, más pasos de verificación o más dependencias de terceros. Y ahí reaparecen GDPR y seguridad.

Si el servicio usa certificados, sellos, firma avanzada o cualificada, onboarding de identidad o credenciales verificables, conviene revisar si la cadena de distribución compromete de algún modo la percepción de integridad del software o la robustez del proceso de enrolment. No es solo reputación. Si el canal alternativo genera más confusión del usuario, pueden aumentar phishing, clonación de interfaces y suplantación de soporte. En servicios de confianza, esa externalidad no es menor. Es el negocio.

Impacto regulatorio cruzado

Este caso parece un asunto de competencia, pero para apps reguladas se comporta como una pieza de dominó que toca varias normas a la vez.

DMA: fuerza la apertura del ecosistema y reduce barreras comerciales. Ese es el detonante.

GDPR: obliga a reescribir el mapa de responsables, encargados, corresponsables, bases jurídicas, minimización, transparencia y respuesta a brechas. Los artículos que más van a sufrir en la práctica son 5.2, 24, 25, 26, 28 y 33.

DORA: convierte cualquier nuevo intermediario TIC en un problema de gobernanza, inventario, evaluación y cláusulas contractuales, con foco en terceros críticos y capacidad de respuesta operativa. Aquí importan especialmente los arts. 11, 15, 17 y 28.

NIS2: mete presión sobre medidas de seguridad, cadena de suministro y tiempos de reporte si el servicio cae dentro de su ámbito. Los arts. 21 y 23 son la referencia más inmediata.

AI Act: no nace de esta controversia, pero entra en escena cuando las empresas aprovechan la apertura para rediseñar funnels, antifraude, soporte y onboarding con modelos de IA. El riesgo está menos en el titular y más en la implementación atropellada.

NIST CSF 2.0: aunque no sea ley europea, sigue siendo un marco útil para ordenar la respuesta. Govern, Identify, Protect, Detect, Respond y Recover encajan bastante bien con este escenario multicanal. Si una empresa no sabe usar un marco voluntario para aterrizar obligaciones duras, luego no debería sorprenderle que la documentación regulatoria parezca escrita en jeroglíficos.

Hay además una tensión política de fondo. La UE quiere más competencia digital sin rebajar seguridad ni derechos fundamentales. Perfecto como principio. Pero ese equilibrio requiere supervisión coordinada entre competencia, protección de datos, ciberseguridad sectorial y, cuando proceda, supervisión financiera. Si cada autoridad mira solo su trozo, los incentivos del mercado producirán exactamente lo de siempre: innovación en acquisition, deuda en control.

Qué deberían hacer ahora las apps financieras, de pagos, seguros y salud digital

Lo primero es aceptar una realidad algo poco épica: este cambio exige trabajo de arquitectura de control, no solo negociación comercial. Si una entidad está valorando salir parcialmente del App Store o habilitar pagos alternativos dentro de iOS, debería arrancar con un assessment interfuncional en el que estén producto, seguridad, privacidad, legal, procurement, fraude y continuidad. Si falta alguno, aparecerá más tarde en formato incidente.

La secuencia operativa sensata sería esta. Uno: redibujar el flujo end-to-end del cliente por canal, identificando dónde se capturan datos, dónde se autentica, dónde se paga, dónde se atienden reclamaciones y qué terceros participan. Dos: clasificar qué funciones soportan un servicio importante o crítico, especialmente bajo DORA si aplica. Tres: recalificar roles GDPR por cada tratamiento relevante y revisar si hay corresponsabilidad real en alguna fase. Cuatro: renegociar contratos con obligaciones concretas sobre seguridad, subencargados, tiempos de notificación, acceso a logs, derecho de auditoría y cooperación regulatoria. Cinco: ejecutar pruebas de incidente y continuidad que partan de fallos en el canal alternativo, no del caso cómodo dentro del App Store.

Hay detalles muy específicos que muchos equipos pasarán por alto si van deprisa. Por ejemplo, si el canal alternativo implica más uso de web-to-app journeys o deep links, conviene revisar protección frente a manipulación de enlaces, secuestro de sesión, overlays maliciosos y spoofing de identidad visual. Si se introducen nuevos SDKs para medición o pagos, toca SBOM interno o, al menos, inventario disciplinado de componentes y revisión de permisos. Si se externaliza más soporte o antifraude, el acceso a datos y registros debe alinearse con necesidad real y retención mínima.

Otro punto: las apps reguladas no deberían tratar el nuevo 5% como una invitación automática a reconfigurar precios o funnels sin evaluar riesgo de conducta comercial. En servicios financieros y de salud, la forma de presentar descuentos, suscripciones, renovaciones, cancelaciones o información contractual sigue sometida a normativa sectorial y de consumo. Abrir el canal no abre una barra libre de dark patterns. La Comisión, los reguladores de consumo y las autoridades de protección de datos no suelen aplaudir la creatividad cuando huele a manipulación.

La Comisión no debería conformarse con “vigilar la implementación”

La reacción de la Comisión Europea, según Reuters, ha sido dar la bienvenida a los cambios y anunciar seguimiento. Bien, pero es una formulación peligrosamente genérica. Si Bruselas quiere que la DMA produzca competencia real sin deterioro en seguridad y gobernanza, necesita algo más granular que vigilancia de escaparate.

Hay al menos cuatro preguntas que el seguimiento regulatorio debería abordar este año y en 2027.

Una: si el nuevo 5% corrige de verdad las barreras de salida o solo las reempaqueta. Aquí la disputa con Epic no es anecdótica; es un termómetro. Puede que Epic dramatice, como acostumbra, pero la crítica obliga a examinar si el coste total y las condiciones técnicas siguen desincentivando el uso de canales alternativos.

Dos: si la apertura altera materialmente el perfil de incidentes, fraude o disputas de consumo. Si cambia, el debate ya no es solo de competencia.

Tres: si los desarrolladores pequeños quedan más expuestos a acuerdos opacos con intermediarios alternativos que sustituyen un gatekeeper por otro menos visible.

Cuatro: si el ecosistema regulado —finanzas, salud, identidad— está recibiendo orientación suficiente sobre intersección entre competencia, privacidad y resiliencia. La respuesta honesta hoy es que no demasiado.

La UE tiene una costumbre regulatoria entrañable: legislar por piezas maestras y luego obligar al mercado a coserlas con hilo fino. A veces sale bien. A veces produce una manta preciosa con agujeros en las esquinas. Este caso va camino de eso si no hay coordinación práctica entre autoridades.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, EDEs, EMI, neobancos, gestoras y fintechs operando en España, el asunto es europeo y muy concreto. Primero, porque el cambio aplica en la UE y puede afectar a la distribución de apps a clientes españoles desde el 1 de octubre de 2026. Segundo, porque España llega a esta fase con supervisores y órganos de control especialmente sensibles a outsourcing, resiliencia y tratamiento de datos.

Una entidad española sujeta a DORA no puede evaluar la salida parcial del App Store como una mera optimización de costes de adquisición. Si la app soporta pagos, acceso a cuentas, inversión, seguros o autenticación de cliente, el canal móvil participa en un servicio que puede resultar importante o crítico. Eso arrastra exigencias de gobernanza, pruebas, documentación y terceros. El Banco de España, la CNMV y la DGSFP miran cada vez menos la etiqueta comercial y cada vez más la dependencia operacional real.

También importa el ángulo PSD2/servicios de pago, aunque no sea el centro de la noticia. Si el nuevo recorrido de pagos o autenticación introduce fricciones o excepciones distintas, habrá que revisar coherencia con autenticación reforzada del cliente, gestión del fraude y trazabilidad. No por Apple, sino por el propio diseño del servicio. Y si la entidad usa IA para scoring antifraude o atención al cliente en el canal móvil, haría bien en tratar 2026 como el año de consolidar gobernanza antes de escalar, no después.

En sanidad digital y seguros de salud el riesgo es paralelo. Más control del funnel puede tentar a capturar señales conductuales o biométricas adicionales. Con datos de salud o inferencias sensibles, esa tentación debería pasar por comités, DPIA cuando corresponda y una revisión muy fría de necesidad y proporcionalidad. Lo contrario acaba mal y además deja rastro documental.

El error que más probablemente veremos en los próximos meses

No será un gran ciberataque cinematográfico. Será algo bastante más cotidiano: empresas que abran un canal alternativo sin haber redefinido su modelo de responsabilidad documental y técnica. Luego llegará una incidencia menor —un error de cobro, una caída de onboarding, una disputa de consentimiento, un falso positivo antifraude, una fuga de telemetría, un retraso en parcheado de un SDK— y descubrirán que nadie sabía con precisión qué tercero hacía qué, qué logs existían, quién notificaba a quién y bajo qué plazo.

Ese tipo de fallo no suele salir en portada. Pero es el que desgasta de verdad: investigaciones internas largas, discusiones entre legal y seguridad, auditorías tensas, reclamaciones de clientes y reguladores preguntando por evidencias que no existen o están repartidas en seis proveedores. El coste reputacional no llega por el drama del porcentaje. Llega por la torpeza operacional posterior.

Si Apple quería resolver “disagreements” con la Comisión, probablemente ha avanzado. Si los desarrolladores querían más claridad económica, también. Si las empresas reguladas creen que eso simplifica su vida de cumplimiento, se están contando un cuento bastante caro.

La pregunta final no es cuánto cobra Apple, sino cuánto control conservas tú

La discusión pública seguirá girando sobre si el 5% es razonable, si el 20% dentro del App Store sigue siendo excesivo y si Epic tiene razón cuando acusa a Apple de vaciar la DMA de contenido. Todo eso importa. Pero para quien opera servicios regulados, la pregunta útil es más prosaica y más seria: al abrir el canal, ¿conservas visibilidad, capacidad de respuesta, evidencia auditable y control real sobre terceros?

Si la respuesta es sí, la nueva fase de iOS en Europa puede ser una oportunidad legítima: mejor economía unitaria, relación directa con el cliente, más flexibilidad comercial y quizá menos dependencia de un único gatekeeper.

Si la respuesta es no, el ahorro aparente se convertirá en deuda regulatoria. Y esa deuda siempre vence en el peor momento posible: cuando hay incidente, cuando hay inspección o cuando la dirección pregunta por qué algo que parecía una mejora de margen ha terminado en un problema de consejo de administración.

Apple ha simplificado una factura. No ha simplificado el riesgo. Para las apps reguladas, de hecho, lo ha vuelto más visible. Casi se agradece.