Google abre Android y su buscador a rivales de IA por orden de Bruselas: más competencia, más datos y una pregunta incómoda sobre privacidad

Bruselas ya no está insinuando nada: está dictando cómo debe abrirse Google a sus rivales de IA y de búsqueda. La Comisión Europea confirmó el 16 de julio de 2026 que Alphabet tendrá que permitir acceso a 11 funcionalidades de Android para asistentes de terceros y compartir datos que usa para optimizar su buscador con OpenAI y otros competidores con capacidades de búsqueda, con anonimización y bajo ciertos filtros de ciberseguridad y protección de datos. El calendario importa. Las medidas sobre datos se aplicarán desde enero de 2027. Los cambios en Android llegarán a partir de julio de 2027, con la siguiente iteración del sistema.

La noticia parece antitrust puro. No lo es. Para cualquier entidad regulada que use Android Enterprise, distribuya apps, dependa de Google Search para descubrimiento comercial o esté experimentando con asistentes de IA en canales de atención, esto toca tres capas a la vez: competencia, privacidad y seguridad operacional. Y ahí es donde la historia deja de ser una pelea entre Bruselas y Silicon Valley para convertirse en un problema muy terrenal para bancos, aseguradoras, fintechs y cualquier organización que no quiera descubrir demasiado tarde que la “apertura” también abre superficies de riesgo.

Google ha respondido con el argumento esperado: que la decisión “socava barreras vitales de privacidad y seguridad para millones de europeos”. Hay una parte de teatro en esa frase; las big tech invocan al usuario cuando el regulador les toca el modelo de negocio. Pero sería un error despacharlo como simple victimismo corporativo. La apertura forzada de interfaces, datos y flujos de activación de asistentes sí plantea tensiones reales entre interoperabilidad y control. Lo interesante no es si Google protesta. Lo interesante es si la Comisión ha calibrado bien dónde termina la competencia y dónde empieza el riesgo sistémico.

Tesis editorial

Mi tesis es sencilla: la Comisión acierta al forzar competencia en el acceso a Android y a ciertos datos de búsqueda, pero está empujando a Europa a una fase regulatoria más incómoda de la que parece. El DMA nació para recortar poder de gatekeepers. Ahora entra en territorio más delicado: obligar a compartir capacidades que son al mismo tiempo vectores de innovación, activos de datos y perímetros de seguridad. Si no se gobierna con precisión quirúrgica, la promesa de más competencia en IA puede terminar dejando a las empresas reguladas con un regalo envenenado: más proveedores, más integración, más riesgo contractual y más fricción entre DMA, GDPR, NIS2, DORA y AI Act.

La paradoja es casi elegante. Europa quiere menos dependencia de un solo gatekeeper, pero para conseguirlo obliga a abrir piezas de infraestructura digital que, precisamente por estar tan integradas, habían sido más fáciles de controlar bajo un único propietario. Competencia, sí. Simplificación, ni de lejos.

Lo que ha decidido la Comisión y por qué esto va mucho más allá del antitrust

Los hechos concretos son estos. Seis meses después de iniciar procedimientos de especificación para ayudar a Google a cumplir el Digital Markets Act, la Comisión detalló el 16 de julio de 2026 dos bloques de medidas. Primero, Google deberá abrir 11 funcionalidades de Android a rivales de IA para que puedan acceder a capacidades clave y competir con Gemini. Reuters cita un ejemplo muy claro: un usuario podrá activar un asistente rival por voz, de forma equivalente al “hey Google”, para buscar información o reservar un taxi. Segundo, Google deberá compartir con OpenAI y otros chatbots con funciones de búsqueda los datos que usa para optimizar su propio motor, sujetos a anonimización. Esa segunda pata se aplicará desde enero de 2027 y llevará aparejada una fórmula para calcular el precio de los datos compartidos.

Ese detalle del precio no es menor. Cuando Bruselas obliga a compartir, no está expropiando sin más; está construyendo un mercado regulado de acceso. Y un mercado regulado de acceso requiere criterios de elegibilidad, controles de seguridad, reglas de uso, trazabilidad y mecanismos de resolución de disputas. En otras palabras: compliance industrializado. La Comisión añadió que Google podrá evaluar primero si los rivales plantean riesgos de ciberseguridad y protección de datos antes de abrirles el acceso. Tampoco es trivial. Es un reconocimiento de que la interoperabilidad sin due diligence sería un disparate.

Aquí aparece el núcleo del asunto. El DMA no sustituye al GDPR ni neutraliza obligaciones de seguridad. Si un gatekeeper abre interfaces o comparte datasets anonimizados, siguen vivas preguntas clásicas: qué base jurídica sostiene ciertos tratamientos posteriores, cómo se verifica la anonimización efectiva, qué ocurre si un tercero reidentifica patrones, quién responde por un abuso de APIs o por una activación maliciosa de asistentes a través de voz, y cómo se articula la responsabilidad cuando el daño emerge de una cadena de varios actores.

Quien crea que esto se resuelve con una cláusula de contrato no ha pisado una auditoría seria en su vida.

El DMA entra en su fase difícil: de prohibir autopreferencia a rediseñar arquitectura

Durante sus primeros compases, el Digital Markets Act fue leído sobre todo como una norma de conducta para gatekeepers: no favorezcas injustamente tus servicios, no cierres el acceso, no uses datos de negocio ajeno para competir deslealmente. Todo eso sigue ahí. Pero las decisiones de especificación muestran una evolución. Ya no se trata solo de decirle a la plataforma lo que no puede hacer; se trata de concretar cómo debe rediseñar partes de su arquitectura de acceso.

Ese salto importa porque cambia el tipo de riesgo. La autopreferencia se combate con monitorización y enforcement. La apertura técnica se combate, además, con diseño seguro. Si el acceso de un asistente rival a funciones profundas de Android está mal segmentado, el problema ya no es solo una disputa de competencia. Puede ser un incidente de seguridad del dispositivo, abuso de permisos, exfiltración de datos o degradación de controles de autenticación por voz.

Y no, el hecho de que la Comisión diga que habrá “sólidas salvaguardas” no cierra la discusión. Las salvaguardas regulatorias no son un producto. Son un mandato que luego hay que traducir en ingeniería, contratos, monitorización y pruebas. Ahí se ganan o se pierden los litigios de los próximos dos años.

La propia secuencia temporal lo sugiere. La Comisión abrió procedimientos de especificación en enero de 2026, según el cómputo de “seis meses” citado por Reuters, y ahora fija un horizonte escalonado: enero de 2027 para compartir datos de búsqueda y julio de 2027 para la apertura en Android. No es un capricho burocrático. Es la admisión implícita de que esto requiere rediseño técnico, evaluación de riesgo y probablemente negociación muy áspera sobre criterios de acceso.

Privacidad: el verbo peligroso aquí es “anonimizar”

La Comisión dice que Google compartirá datos para optimizar búsqueda “sujetos a anonimización”. Bien. La pregunta seria es otra: anonimización de qué tipo y frente a qué riesgo residual. Bajo GDPR, datos verdaderamente anonimizados quedan fuera del reglamento porque dejan de referirse a una persona identificada o identificable. Pero anonimizar logs de búsqueda o señales de interacción no es lo mismo que borrar nombres de una hoja Excel. Si el dataset conserva granularidad temporal, patrones de localización, consultas raras o combinaciones de señales suficientemente singulares, el riesgo de reidentificación puede no ser teórico.

El estándar jurídico relevante aquí no es una intuición amable sino el listón europeo sobre identificabilidad y medios razonablemente utilizables. El GDPR, en su artículo 4, define datos personales; y la lógica de sus considerandos sobre anonimización y seudonimización deja claro que la irreversibilidad práctica importa. Traducido al lenguaje menos elegante del mundo real: si el receptor del dato, combinado con otros activos informacionales, puede acercarse a una persona, no basta con decir “anonimizado” y seguir adelante tan tranquilos.

Además, el dato de búsqueda tiene un vicio antiguo: revela intención. Y la intención, cruzada con contexto, es extraordinariamente sensible. Consultas relacionadas con salud, finanzas, geolocalización o vulnerabilidad económica pueden inferir categorías delicadas incluso si la identidad directa ha sido retirada. No siempre habrá tratamiento de categorías especiales en sentido estricto del GDPR, pero el riesgo material para derechos y libertades sí puede ser alto.

Esto afecta de lleno a las empresas reguladas que quieran consumir esos flujos de datos o construir servicios sobre ellos. Si tu banco, aseguradora o plataforma comparadora usa un modelo de IA de terceros entrenado o afinado con datasets procedentes de este nuevo régimen de acceso, tendrás que preguntar bastante más que “¿el proveedor cumple el GDPR?”. Las preguntas incómodas son otras:

• ¿Qué técnica de anonimización se ha usado y cómo se ha probado contra ataques de singling out, linkability e inference?
• ¿Existen restricciones contractuales de propósito y prohibiciones explícitas de reidentificación?
• ¿Qué derechos de auditoría o de suministro de evidencias tendrá el cliente regulado?
• ¿Cómo se gestiona la segregación entre datos de entrenamiento, ajuste, evaluación y telemetría operativa?
• ¿Se ha hecho una evaluación de impacto relativa a protección de datos cuando el caso de uso pueda implicar alto riesgo, conforme al GDPR art. 35?

Si estas preguntas no están en la due diligence, la conversación sobre “IA responsable” es puro atrezo.

Seguridad: abrir once funciones de Android no es solo un tema de UX

El segundo bloque de medidas merece más atención de la que está recibiendo. Once funciones de Android se abrirán para que asistentes rivales compitan con Gemini. Reuters no detalla en la pieza cuáles son esas once funciones, y precisamente por eso conviene no inventar la lista. Pero el ejemplo facilitado por la Comisión —invocar un asistente rival por voz para buscar información o reservar un taxi— basta para entender la sensibilidad del cambio. Hablamos de accesos vinculados a activación por voz, interacción con apps, contexto del dispositivo y posiblemente orquestación de tareas.

En seguridad móvil, el peligro rara vez está en una función aislada. Está en la combinación de permisos, contexto y confianza del usuario. Si el usuario percibe que cualquier asistente activado por voz “funciona como Google”, tenderá a atribuirle un nivel de confianza sistémico, aunque el proveedor, el tratamiento de datos y el perfil de riesgo sean distintos. Ese desajuste entre percepción y realidad es gasolina para incidentes de seguridad y para reclamaciones de protección de datos.

La Comisión dice que solo se ofrecerán esas 11 funciones a rivales que cumplan criterios de privacidad y seguridad. Correcto. Pero para una empresa usuaria eso no elimina su propia obligación de gobernar el riesgo de terceros. Un banco que permita a sus clientes interactuar con ciertos procesos a través de un asistente en Android no puede refugiarse en “si la Comisión les dejó entrar, suponemos que está todo bien”. Ni DORA ni NIS2 funcionan así. Tu dependencia sigue siendo tuya.

En un escenario prudente, las entidades deberían revisar al menos cuatro frentes antes de habilitar o integrar asistentes rivales en journeys sensibles:

• Autenticación y autorización: qué operaciones podrán desencadenarse por voz o mediante el asistente y cuáles exigirán step-up authentication.
• Gestión de secretos y tokens: si el asistente media con apps financieras, dónde residen credenciales, cómo se rotan y qué telemetría deja el proceso.
• Prevención de abuso y fraude: comandos ambiguos, spoofing de voz, superposición de interfaces y manipulación contextual.
• Logging y forensics: capacidad real de reconstruir quién hizo qué, desde qué capa y con qué proveedor intermediario.

La ironía aquí es obvia. Europa quiere más competencia en asistentes. Perfecto. Pero cuanto más asistido sea el canal, más crítico se vuelve conservar pruebas fiables de autenticación, consentimiento y ejecución. Eso suena menos a “fricción cero” y bastante más a “bienvenidos otra vez al compliance”.

Impacto regulatorio cruzado

La decisión de la Comisión no vive sola. Choca, encaja o se superpone con otros marcos que en 2026 ya están condicionando a las organizaciones reguladas en Europa. Y aquí conviene poner orden, porque mezclarlo todo bajo la etiqueta “cumplimiento digital” solo sirve para producir diapositivas bonitas y controles mediocres.

DMA y GDPR: apertura sí, minimización también

El DMA fuerza acceso y limita conductas de cierre. El GDPR sigue exigiendo principios de minimización, limitación de finalidad, seguridad del tratamiento y responsabilidad proactiva. Que un gatekeeper deba compartir datos anonimizados no convierte automáticamente en legítimo cualquier uso posterior por parte del receptor. Si un chatbot competidor integra señales de búsqueda y luego las reutiliza para entrenar otros modelos, personalizar publicidad o inferir perfiles de riesgo, entran en juego las bases jurídicas, la transparencia y, en su caso, la evaluación de impacto del GDPR arts. 5, 6, 13, 14, 25, 32 y 35.

La tensión práctica es esta: el DMA empuja a la disponibilidad; el GDPR obliga a restringir y justificar. Cumplir ambos exige gobernanza de datos bastante más refinada que un simple “data room para competidores”.

DMA y DORA: la dependencia de terceros no desaparece, se multiplica

Para entidades financieras, DORA sigue siendo el marco más incómodo porque no se impresiona fácilmente con discursos sobre innovación. El Reglamento (UE) 2022/2554 exige gestionar el riesgo de terceros TIC de forma estructurada. El artículo 28 obliga a establecer una estrategia sobre riesgo de terceros ICT; el artículo 30 detalla elementos contractuales clave; y los artículos 15 y 17 conectan con gestión de incidentes y continuidad. Si la apertura del ecosistema Google empuja a bancos y aseguradoras a trabajar con más asistentes, más capas de intermediación y más proveedores de datos o modelos, el mapa de concentración cambia, pero la obligación de control no se relaja.

De hecho, puede empeorar. Pasar de una dependencia muy concentrada en un gatekeeper a un mosaico de dependencias con API brokers, modelos fundacionales, capas de orquestación y proveedores de observabilidad no siempre reduce el riesgo operativo. A veces solo lo fragmenta hasta volverlo más difícil de auditar.

DMA y NIS2: la interoperabilidad amplía superficie, luego amplía obligación de gobernarla

La Directiva NIS2, en su artículo 21, exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos de seguridad de redes y sistemas de información. Entre ellas figuran políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de criptografía cuando proceda. Cuando una organización integra asistentes o motores de búsqueda enriquecidos con proveedores adicionales, la superficie de cadena de suministro crece. Y con ella, las expectativas sobre due diligence, segmentación y respuesta a incidentes.

Si una entidad esencial o importante bajo NIS2 incorpora un asistente rival en sus operaciones o en su canal de cliente, el regulador no va a aceptar como defensa que “el acceso lo ordenó la Comisión”. NIS2 no exime por moda regulatoria ajena. Exige controles.

DMA y AI Act: acceso a datos no equivale a uso permitido sin más

En 2026, el AI Act ya no es una promesa lejana sino una realidad que condiciona clasificación de sistemas, gobernanza del riesgo y obligaciones de transparencia según el caso de uso. Si la apertura impuesta a Google acelera la adopción de asistentes y chatbots con capacidades de búsqueda en banca o seguros, la cuestión no es solo si el proveedor accede a Android o a datos de búsqueda, sino para qué proceso se usa ese sistema. Si entra en decisiones o recomendaciones con impacto material en acceso a servicios, precios, fraude o tratamiento de reclamaciones, el encaje regulatorio se complica. No porque el DMA lo impida, sino porque el AI Act y las reglas sectoriales castigan la alegría descontrolada.

eIDAS 2.0 y confianza transaccional: la voz sola no basta

Si el ecosistema de asistentes se expande, volverá la vieja tentación de convertir la conveniencia en prueba de identidad. Mala idea. eIDAS 2.0 empuja carteras de identidad y servicios de confianza más robustos, no una fe ciega en la biometría de voz o en señales contextuales opacas. Para operaciones con efectos jurídicos o financieros, la autenticación fuerte y la evidencia verificable seguirán siendo la moneda de verdad. El asistente puede iniciar; no necesariamente debe autorizar.

Lo que cambia para banca, seguros y fintech en Europa

Las entidades financieras europeas llevan años atrapadas entre dos presiones. Por un lado, clientes que esperan experiencias conversacionales y flujos móviles sin fricción. Por otro, reguladores que, con razón, no aceptan que la palabra “innovación” sustituya a los controles. La decisión contra Google acelera esa tensión porque abarata, al menos en teoría, la entrada de nuevos asistentes y capas de búsqueda enriquecida en el canal móvil.

¿Dónde impacta primero? En cuatro áreas muy concretas.

1. Atención al cliente y autoservicio conversacional

Si Android permite activar asistentes rivales con acceso más profundo, veremos más intentos de llevar el soporte de primer nivel fuera de la app bancaria y más cerca del sistema operativo. Esto mejora descubrimiento y conveniencia, sí. Pero desplaza también preguntas de responsabilidad: quién registra la interacción, dónde queda el consentimiento, cómo se corrige una instrucción mal entendida, y qué proveedor asume obligaciones si un cliente interpreta que habló “con el banco” cuando en realidad habló con un intermediario.

2. Búsqueda financiera y comparadores

El acceso a datos de búsqueda anonimizados puede potenciar motores y chatbots rivales capaces de competir mejor con Google Search y Gemini. Eso puede alterar la captación de clientes para comparadores, brokers, insurtech y distribuidores de productos financieros. Más competencia en búsqueda suele significar más presión sobre SEO, adquisición y monetización. Pero también más dependencia de señales de terceros y más opacidad sobre cómo un asistente prioriza fuentes, resúmenes y recomendaciones.

Para compliance comercial y de conducta, el riesgo es evidente: si un chatbot con funciones de búsqueda resume mal una póliza, una TAE o una exclusión crítica, el perjuicio reputacional y jurídico puede aterrizar sobre la entidad aunque el error naciera aguas arriba.

3. Fraude y suplantación asistida

Cuantos más asistentes con acceso a funciones del dispositivo, más oportunidades para ingeniería social de nueva generación. Un actor malicioso no necesita comprometer el core bancario si puede manipular al usuario en el borde: inducir activaciones, redirigir acciones, capturar contexto o explotar confianza en interfaces conversacionales. La seguridad móvil ya estaba lidiando con overlays, abuso de accesibilidad y malware bancario. Añadir competencia en asistentes sin rediseñar los controles de canal sería una imprudencia notable.

4. Riesgo de proveedores y concentración oculta

El argumento político del DMA es reducir el poder del gatekeeper. Bien. El problema operativo es que muchas entidades pueden terminar migrando de una concentración visible a una concentración menos obvia: el mismo puñado de proveedores de modelos, capas de retrieval, servicios de voz, herramientas de observabilidad y conectores. Menos Google no equivale automáticamente a más resiliencia. A veces solo cambia el logotipo de la dependencia.

Qué deberían hacer ahora los equipos de compliance, legal, CISO y procurement

No hace falta esperar a enero de 2027 para empezar. Las organizaciones que toquen Android, búsqueda o asistentes de IA deberían entrar ya en modo de preparación selectiva. No de pánico. De trabajo fino.

Primero, conviene mapear dónde existe dependencia funcional de Google que pueda verse alterada por la apertura regulatoria: autenticación contextual, asistentes en móvil, journeys de cliente basados en búsqueda, captación orgánica y APIs de ecosistema. No es un inventario teórico. Es un mapa de puntos donde la entrada de rivales puede generar nuevas oportunidades comerciales o nuevos riesgos de control.

Segundo, hay que revisar los estándares internos de onboarding de proveedores de IA y de servicios conversacionales. Si el formulario de due diligence todavía distingue solo entre “SaaS” y “proveedor crítico”, está obsoleto. Debe captar al menos origen y linaje de datos, uso de subprocesadores, jurisdicciones de tratamiento, mecanismos de explicabilidad operativa, retención de prompts y logs, controles de seguridad de modelo, y capacidad de demostrar segregación entre clientes.

Tercero, legal y privacidad deberían preparar posiciones claras sobre datos anonimizados de terceros. La pregunta no es solo si el dataset llega anonimizado. La pregunta es qué usos se permitirán dentro de la entidad y bajo qué limitaciones. Entrenar modelos propios, afinar búsquedas internas, personalizar journeys o enriquecer scoring son finalidades distintas y no se deben mezclar alegremente.

Cuarto, el CISO tiene que imponer dos disciplinas que suelen perderse en la fiebre por la IA: arquitectura de confianza mínima y trazabilidad de extremo a extremo. Si un asistente externo puede iniciar acciones o mediar consultas que afectan a clientes, no debería tener más privilegios de los indispensables. Y cada paso debe dejar rastro útil para investigación y auditoría. No un log decorativo. Rastro útil.

Quinto, procurement y risk deben asumir que el “derecho de acceso” del DMA no equivale a “madurez de proveedor”. Que una empresa obtenga acceso regulado a funciones de Android o a datos de búsqueda no la convierte en apta para procesos críticos en finanzas o seguros. Eso exige evaluación propia, cláusulas contractuales exigentes y criterios de salida viables.

La objeción obvia: sin abrir, nunca habrá competencia real en IA

Es una objeción seria, y tiene bastante razón. Si Google conserva a la vez el sistema operativo, el asistente, el buscador y las señales de optimización que alimentan su ventaja, competir desde fuera se vuelve casi folclórico. La Comisión no está equivocada al ver que la batalla de la IA no se juega solo en modelos fundacionales; se juega también en acceso a interfaces, distribución, contexto y datos de uso. Abrir Android y parte del circuito de datos de búsqueda es, desde esa perspectiva, una corrección estructural a una ventaja de ecosistema que el mercado no iba a neutralizar por sí solo.

También es cierto que Google tiene incentivos evidentes para exagerar el riesgo de privacidad cuando lo que realmente se ve amenazado es su posición competitiva. No sería la primera vez que una plataforma usa la seguridad como muralla estratégica. El historial del sector invita al escepticismo.

Pero reconocer eso no obliga a tragarse sin masticar el discurso contrario: que toda apertura bienintencionada produce automáticamente mercados más sanos. No. Produce mercados más disputados. Y un mercado más disputado puede ser mejor para precios, innovación y elección, mientras empeora simultáneamente la gobernanza técnica y contractual de quienes consumen esos servicios.

Ese es el punto incómodo que muchas lecturas celebratorias están obviando.

El detalle que no conviene perder: la Comisión deja a Google hacer cribado de riesgos

Hay un elemento particularmente interesante en la decisión: Google podrá evaluar primero si un rival plantea riesgos de ciberseguridad o protección de datos antes de abrir el acceso. Este matiz puede parecer menor, pero jurídicamente y operativamente será una mina de disputas.

¿Por qué? Porque convierte a Google en una especie de portero regulado. Tiene la obligación de abrir, sí, pero conserva capacidad de objetar sobre la base de seguridad y privacidad. Eso generará tres preguntas prácticas. Primera: qué criterios concretos podrá aplicar y con qué grado de transparencia. Segunda: cómo evitar que esos criterios se utilicen para retrasar o dificultar la entrada de rivales incómodos. Tercera: qué estándar probatorio pedirá la Comisión cuando un tercero impugne una negativa.

Para las empresas usuarias hay una derivada útil. Si Google exige a rivales umbrales concretos de seguridad o privacidad para darles acceso, esos umbrales acabarán funcionando como referencia de mercado, aunque no sustituyan a marcos formales como DORA o NIS2. Vale la pena seguir de cerca esos requisitos cuando se publiquen o se conozcan por litigios, porque pueden anticipar el listón mínimo de facto en el ecosistema móvil y conversacional europeo.

Qué mirar de aquí a enero y julio de 2027

El calendario ya está bastante claro. Enero de 2027 marca la entrada en aplicación de la medida sobre intercambio de datos de búsqueda con anonimización y precio regulado. Julio de 2027 apunta al despliegue de cambios en Android con la siguiente versión del sistema. Entre medias, lo razonable es esperar negociación técnica intensa, posibles impugnaciones, presión de lobbies y mucho trabajo de detalle en criterios de elegibilidad y seguridad.

Yo vigilaría seis cosas muy concretas.

• La definición operativa de “anonimización” aplicada a datos de búsqueda y el grado de granularidad del dataset compartido.
• La fórmula de pricing y si incentiva competencia real o acceso nominal pero económicamente estéril.
• Los criterios de seguridad y privacidad que Google podrá usar para filtrar a rivales.
• La lista efectiva de las 11 funcionalidades de Android y el nivel de privilegio asociado a cada una.
• Las primeras integraciones comerciales de asistentes rivales en móvil y si se limitan a casos inocuos o entran pronto en flujos transaccionales.
• La reacción de autoridades de protección de datos y, eventualmente, de supervisores sectoriales cuando esos servicios se desplieguen en finanzas, salud o seguros.

Si esas piezas salen desalineadas, 2027 puede regalarnos una secuencia regulatoria bastante europea en el peor sentido del término: competencia en una sala, privacidad en otra, seguridad en una tercera y las empresas intentando no tropezar al pasar de una puerta a la siguiente.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, EDE, ESI y fintech con operación en España, la señal es clara: la decisión de la Comisión no cambia el núcleo de sus obligaciones, pero sí altera el perímetro tecnológico que tendrán que gobernar. Y eso en 2026 ya no se puede tratar como un asunto accesorio de innovación.

Primero, las entidades sujetas a DORA deben revisar si sus políticas de terceros TIC y sus registros de dependencia capturan adecuadamente proveedores de IA conversacional, capas de búsqueda enriquecida y componentes embebidos en ecosistemas móviles. Muchas no lo hacen todavía con el detalle suficiente. Segundo, cualquier despliegue de asistentes sobre Android para clientes minoristas debería reevaluarse a la luz de fraude, autenticación y evidencia. Tercero, las áreas de marketing y distribución tendrán que entender que la competencia en búsqueda asistida puede modificar sustancialmente cómo se presentan, resumen y recomiendan productos financieros. Eso tiene implicaciones de conducta, documentación precontractual y gestión de reclamaciones.

Y hay una cuarta derivada que en España no conviene subestimar: el peso de la externalización tecnológica en banca y seguros ya era alto. Si la respuesta a la apertura de Google consiste en sumar proveedores sin redibujar el modelo de control, las entidades pueden encontrarse con más complejidad justo cuando los supervisores esperan lo contrario: trazabilidad, resiliencia y capacidad de demostrar gobierno efectivo.

Dicho sin rodeos: si tu organización ve esta noticia y solo piensa “por fin más competencia frente a Google”, se está perdiendo la mitad peligrosa de la película.

La conclusión incómoda

La Comisión Europea ha hecho algo relevante de verdad, no otro gesto performativo para titular de verano. Obligar a Google a abrir funciones de Android y compartir ciertos datos de búsqueda redibuja la competición en IA en Europa. Puede beneficiar a usuarios y crear espacio para rivales serios. También puede reducir parte del cerrojo de ecosistema que ha protegido a Gemini y a Google Search. Hasta ahí, bien.

Pero la apertura no es un bien absoluto. Es una operación regulatoria de alta precisión sobre una infraestructura que mezcla datos, seguridad, interfaces y dependencia empresarial. Si sale bien, Europa habrá demostrado que se puede atacar el poder de plataforma sin dinamitar la protección del usuario. Si sale mal, veremos exactamente lo contrario: más elección aparente, más complejidad real y una cadena de responsabilidad tan fragmentada que, cuando llegue el primer incidente serio, todos señalarán al de al lado.

Las empresas reguladas no deberían esperar a ver quién gana la batalla política. Tienen que prepararse para una realidad bastante más prosaica: más proveedores tocarán capas antes controladas por uno solo. Eso exige mejores contratos, mejor arquitectura y mucha menos fe en los eslóganes de “IA segura” que reparten tanto las plataformas incumbentes como sus flamantes competidores.

La competencia, como la criptografía y las copias de seguridad, es estupenda. Siempre que alguien haya pensado antes en el modelo de amenaza.