La publicación llegó el día antes del lanzamiento previsto

El 31 de julio la cuenta de Google AI Studio publicó una nota breve para agradecer a las aproximadamente 800.000 personas que habían reservado su aplicación móvil en iOS y Android. Esa nota no anunciaba un lanzamiento. Era una cancelación. La aplicación independiente no llegaría en absoluto.

La información publicada ese mismo día situaba el lanzamiento previsto el 1 de agosto, lo que coloca la decisión dentro de las últimas veinticuatro horas de un calendario de entrega. Las reservas estaban abiertas en Google Play y en la App Store desde la conferencia de desarrolladores I/O de este año, tiempo más que suficiente para que muchísimas personas registraran su interés y para que algunas organizaciones ya hubieran escrito esa aplicación en una planificación.

Las cifras de reservas suelen citarse como prueba de que un lanzamiento está asegurado. Esta se citó en el aviso de que el lanzamiento quedaba cancelado. Esa inversión es la parte que conviene guardar.

Google dio la razón, y no era el producto

Las cancelaciones suelen llegar envueltas en nada. Esta llegó con una explicación, y la explicación es inusualmente directa. "En lugar de pedirte que descargues otra aplicación más, hemos decidido adoptar un enfoque completamente distinto: uno en el que las aplicaciones surjan de forma natural, en el curso de tus conversaciones cotidianas con Gemini", escribió la compañía. Para lograrlo trabaja con el equipo de la aplicación Gemini, tanto en el móvil como en el escritorio.

Lea otra vez la primera parte. La objeción no apunta a la calidad de la aplicación, ni a su madurez, ni a su coste, ni a su acogida. La objeción apunta a la descarga. En la misma nota la compañía dijo que había quedado claro que a la gente le interesa crear software sobre la marcha, lo que constituye un reconocimiento explícito de que la demanda medida era real.

La secuencia, por tanto, es esta: demanda confirmada, producto terminado, lanzamiento cancelado. Nada en esa secuencia es un fracaso de producto. Es una decisión sobre dónde debe vivir una capacidad, tomada por quienes son dueños de la superficie de distribución y no de la función.

Lo que hay que vigilar es la superficie propia

La mayoría de los compradores evalúa el riesgo de la hoja de ruta de un proveedor con cifras de adopción. Si alguien lo usa, si crece, si el proveedor se comprometió en público. Los tres son instrumentos equivocados, porque aquí los tres salieron positivos y ninguno importó. Ochocientas mil inscripciones son más o menos la señal de demanda más ruidosa que un equipo de producto puede generar antes de entregar, y aun así perdió.

El instrumento que sí habría funcionado es estructural y se aplica en un minuto. Hágase dos preguntas sobre cualquier capacidad de proveedor de la que dependa. ¿Le llega a través de una superficie propia, es decir, su propia aplicación, su propia consola, su propio portal o su propia línea en la factura? ¿Y esa superficie hace un trabajo que el producto insignia del proveedor podría absorber de forma plausible? Lo que responda que sí a ambas es candidato a la consolidación, con independencia de lo bien que le esté yendo.

Esto no predice que toda función así vaya a desaparecer. Describe qué riesgo está asumiendo usted en realidad. Cuando un proveedor consolida, la capacidad suele sobrevivir y la superficie no, de modo que la interrupción para la que hay que planificar no es la pérdida de una función. Es una migración forzosa según el calendario del proveedor y no según el suyo.

Lo que sobrevivió indica dónde va en serio el proveedor

La versión web de AI Studio no se tocó. Google dijo que sigue invirtiendo en ella y la situó para quienes quieren ir de una idea a una instrucción y de ahí a un negocio. Ese encuadre es la mitad útil del anuncio, porque separa las dos superficies por intención: una es para quien construye y se quedó, la otra duplicaba un trabajo que el asistente principal ya podía hacer y desapareció.

Para un equipo que planifica, la lectura es más estrecha que "aquí no se puede confiar en Google". Es que la superficie de desarrollo llevaba el compromiso y la superficie cercana al consumidor llevaba el riesgo. Quien pensara construir un flujo de trabajo sobre la aplicación móvil habría atravesado la semana sin cambios si lo hubiera construido contra la web y las interfaces que la sostienen.

Para los equipos europeos hay un punto adicional. Que una capacidad se mude a una aplicación de asistente general no es un traslado neutro, porque las condiciones, los controles administrativos y el tratamiento de datos de un asistente de consumo no son automáticamente los de un producto para desarrolladores. Cuando un proveedor anuncia un movimiento así, pida esa comparación por escrito antes de planificar alrededor del nuevo hogar, no después.

Ponga la superficie en el contrato, no en la diapositiva

El cambio práctico es pequeño. Cuando una capacidad de proveedor aparece en un plan, nombre la superficie de entrega en el documento que obliga y no solamente la capacidad. "Creación de aplicaciones disponible en la aplicación móvil del proveedor" y "creación de aplicaciones disponible" son compromisos distintos, y solo uno de los dos sobrevive a una consolidación. Si el proveedor se niega a nombrar la superficie, esa negativa también es información, y ahora sale más barata.

El coste de no hacerlo no es dramático, y por eso se omite. Un equipo que hubiera destinado 20.000 euros de tiempo interno a una construcción móvil este trimestre no ha perdido la capacidad ni ha perdido el dinero. Ha perdido el calendario, y se entera con un día de margen por una publicación en una red social en lugar de con un preaviso contractual. Es una pérdida pequeña, evitable y perfectamente repetible.

Leer a continuación: Bruselas acaba de poner precio a los datos de búsqueda de Google  |  Los chips cayeron un 20%. Su factura de cómputo no