Transformación hacia IA agéntica: la estrategia de Google en 4 fases
El domingo pasado por la mañana tuve una pequeña discusión conmigo mismo. Acababa de terminar de diseñar el séptimo "agente de IA" que había construido este trimestre: una pequeña herramienta impulsada por Claude que rastrea los precios de la competencia, los coloca en una hoja de cálculo y me envía una notificación por Slack. Funciona. Me ahorra quizá cuarenta minutos a la semana. Y, al mirar el diagrama, me di cuenta de algo incómodo.
Había construido siete agentes. Había construido cero flujos de trabajo.
Esa distinción parece una cuestión semántica hasta que te detienes a pensar en ella. Entonces deja de parecer una nimiedad y empieza a sonar como la razón principal por la que la mayoría de los proyectos piloto de IA empresarial mueren silenciosamente en su segundo año. Y ese es exactamente el problema que el nuevo Marco de Transformación Agentica de la IA de Google —el que Clara explica en el curso de Estrategia Agentica en Google Skills— está diseñado para resolver.
Pasé la mayor parte de tres días trabajando con el marco, comparándolo con mis propios proyectos y poniendo a prueba si realmente se sostiene fuera de una demo pulida para retail. Parte de él ha cambiado la forma en que estoy estructurando mi próximo proyecto con un cliente. Otra parte, sinceramente, me parece innecesariamente complicada para quienes construyen en solitario. Y una de sus etapas —la de ingeniería de valor— es justo lo que ojalá alguien me hubiera dado hace dieciocho meses.
Déjame mostrarte a qué me refiero.
La diferencia entre un agente y un flujo de trabajo agentico
Aquí está la frase que me cambió por completo la perspectiva: un agente de IA realiza una tarea. Un sistema de IA agentico ejecuta un proceso.
Cuando construí ese scraper de precios de la competencia, construí un agente. Hace una sola cosa, en un solo paso, y luego se detiene. Un humano todavía tiene que revisar los datos, decidir si necesitamos ajustar nuestros precios, redactar la solicitud de cambio, obtener la aprobación y publicarla en vivo. El agente es una herramienta. El flujo de trabajo sigue siendo completamente humano.
Un sistema agentico es lo que ocurre cuando dejas de encajar la IA en tareas individuales y empiezas a entregarle todo el proceso. Extrae los precios de la competencia. Evalúa si la diferencia es relevante. Verifica nuestra política de márgenes. Redacta un cambio de precios. Lo somete a quien deba aprobarlo. Publica la actualización en el catálogo de productos. Monitorea la conversión durante las siguientes 72 horas y, según los resultados, mantiene el cambio o lo revierte.
Eso no es un agente más grande. Es una categoría de sistema completamente diferente.
La perspectiva de Google —y creo que es acertada— es que estamos en el mismo tipo de punto de inflexión con la IA agentica que vivimos con la computación en la nube alrededor de 2010 o con el móvil en 2008. No es solo una “nueva herramienta útil”. Es una reorganización de cómo se realiza el trabajo. Las empresas que entendieron pronto la arquitectura nativa en la nube se adelantaron a las que trataron AWS como “servidores alquilados”. Ahora está comenzando la misma división entre IA agentica y la IA a nivel de tareas.
Y en ningún lugar esa diferencia es más visible que en el sector retail.
Comercio agentivo y la silenciosa muerte del clic
Aquí hay una cifra que debería captar la atención de todo fundador de e-commerce. eMarketer proyecta que el comercio electrónico impulsado por plataformas de IA alcanzará aproximadamente los $20.9 mil millones en 2026, lo que representa un aumento de casi 4 veces respecto a 2025. McKinsey pronostica que el comercio agentivo generará $1 billón en ingresos minoristas en EE. UU. para 2030. Morgan Stanley estima que para entonces casi la mitad de los compradores en línea utilizarán agentes de compras con IA, representando cerca de una cuarta parte de su gasto.
Traducción: un porcentaje significativo de tus futuros clientes nunca verá tu landing page. Le dirán a un agente lo que necesitan. El agente lo comprará.
Esto es lo que la gente quiere decir con “comercio sin clics”, y ya está apareciendo en los datos de tráfico: el tráfico de motores de búsqueda hacia destinos de marca específicos ha caído aproximadamente un 25% de cara a 2026, con una migración clara hacia canales de GenAI como ChatGPT, Perplexity y Gemini, que están asumiendo tanto la capa de descubrimiento como, cada vez más, la de transacción. Alrededor del 70% de los consumidores afirma sentirse al menos algo cómodo dejando que un agente de IA realice compras en su nombre. El 45% ya utiliza asistentes de IA para obtener ideas de productos. El 13% ha completado efectivamente una compra a través de uno — y esa cifra es la señal de alerta, no el techo.
Volveré sobre lo que esto significa para la forma en que construyes tus páginas de producto — hay una implicación específica y poco agradable para el SEO que creo que la mayoría de los equipos aún no ha considerado. Pero primero, el framework en sí, porque el framework es lo que te dice si estás construyendo algo que sobrevivirá a este cambio o algo que morirá con él.
El Marco de Cuatro Etapas de Google, Probado en Proyectos Reales
El marco consta de cuatro etapas: Descubrir, Diseñar, Construir, Escalar. Suena sospechosamente parecido a cualquier otra presentación de consultoría que haya visto. No lo es. El valor real está en el contenido de cada etapa, y el orden importa más de lo que la gente suele reconocer. Te guiaré por cada etapa tal como Clara la estructura en el curso, y luego te contaré dónde creo que se flexiona en la práctica.
Etapa 1: Descubrir — El Cambio de Mentalidad del “¿Y si...?”
La etapa de Descubrir es principalmente cognitiva. La tesis es que la mayoría de las empresas abordan la IA pensando en el “tal como está” — es decir, observan su proceso actual y preguntan: “¿Dónde podemos insertar IA para hacer esto más rápido?” Esa pregunta tiene un techo, y es bajo. Terminas con una versión más rápida del mismo proceso. Una tarea de cuarenta minutos se convierte en una de doce. Bien. Pero no es transformador.
La mentalidad del “¿y si...?” plantea una pregunta diferente. Dice: si tuviéramos un sistema incansable, razonablemente inteligente, capaz de observar, decidir y actuar a lo largo de todo este proceso de extremo a extremo, ¿cómo sería el proceso? Dejas de optimizar los pasos y empiezas a cuestionar si esos pasos siquiera deberían existir.
Probé este ejercicio con un flujo de onboarding de clientes que estaba “IA-izando” para un pequeño SaaS. Pensar en “tal como está” me llevó a construir un agente que redacta correos de bienvenida. Pensar en “¿y si...?” me llevó a preguntar: ¿por qué existe siquiera un correo de bienvenida? La razón era guiar manualmente a un nuevo usuario en la configuración. Si un agente puede detectar una nueva cuenta, observar la primera sesión del usuario y ofrecer ayuda proactivamente dentro del producto cuando encuentra fricción, entonces no hay correo de bienvenida. No hay guía de configuración. No hay ticket en el centro de ayuda sobre “cómo empiezo”. Toda la estructura del onboarding cambia.
Esa es la brecha entre el “tal como está” y el “¿y si...?”. Y la incomodidad de esa brecha es el verdadero entregable de la primera etapa. Se supone que debes salir de ella un poco desorientado. Si sales con una lista ordenada de “lugares donde poner IA”, lo hiciste mal.
Etapa 2: Diseñar — Ingeniería de Valor y Recorridos Críticos de Usuario
Esta es la etapa que, en mi opinión, es la verdadera joya del marco, y la que más se subestima en el discurso sobre IA agentica. La etapa dos hace dos cosas: te obliga a cuantificar el valor de negocio de cada posible proyecto agentico antes de construir, y te hace mapear los Recorridos Críticos de Usuario — los CUJ — que el sistema agentico debe navegar.
La ingeniería de valor, en términos sencillos, es la disciplina de negarse a construir la próxima cosa de IA hasta que puedas responder tres preguntas: ¿qué cambia específicamente para el negocio en dólares u horas?, ¿quién es la persona responsable de ese resultado hoy?, y ¿qué pasa con el trabajo de esa persona cuando el agente lo hace bien? Si no puedes responder las tres con detalles concretos, el proyecto vuelve a la cola. No se prioriza solo porque alguien en el retiro de liderazgo dijo la palabra “IA” con convicción.
Quiero ser honesto: esta es la etapa en la que personalmente he sido el peor infractor. Me encanta construir. Racionalizo el valor después. El marco asume correctamente que la mayoría haremos eso, y por eso incorpora la disciplina antes de escribir una sola línea de código.
La parte de los Recorridos Críticos de Usuario es el complemento operativo. Un CUJ no es una lista de funcionalidades. Es el camino específico que recorre una persona real (o un agente en nombre de una persona) para lograr algo importante. Mapeas el recorrido, marcas cada punto de decisión, cada dependencia de datos, cada lugar donde el proceso actual se rompe o se transfiere a otro sistema. Luego preguntas cuáles de esos pasos puede asumir un agente de principio a fin y cuáles aún requieren intervención humana.
Esto importa porque la mayoría de los proyectos “agenticos” fallan no porque el modelo sea deficiente, sino porque nadie mapeó el recorrido. El agente se atasca en el paso 4 porque los datos del paso 3 están en un sistema al que el agente no puede acceder. O el paso 6 requiere una aprobación que nadie documentó. O la transferencia entre el agente y la persona ocurre por un canal de Slack que solo monitorea un gerente específico y nadie más. El mapeo CUJ revela todo eso antes de construir, lo que es aproximadamente 200 veces más barato que descubrirlo después.
Etapa 3: Construir — Prototipado Sin Código con las Herramientas Adecuadas
La etapa tres es donde empieza la diversión, y donde Google está haciendo una apuesta bastante agresiva. La postura del marco es que el prototipo debe ser construido por el equipo multifuncional que mapeó el CUJ — no entregado a un equipo de ingeniería para que lo interprete. El objetivo de usar herramientas sin código como Google AI Studio y Gemini Enterprise en esta etapa es mantener a las personas más cercanas al proceso en el asiento del conductor mientras el sistema toma forma.
Esta parte del curso está dirigida directamente a los product managers de IA — el enfoque explícito es que un PM debería poder construir un prototipo agentico funcional sin levantar un solo ticket de ingeniería. Tengo sentimientos encontrados al respecto. Por un lado, he visto demasiadas iniciativas de IA empresarial morir en la brecha entre la especificación de un PM y la interpretación de esa especificación por parte de un ingeniero. Permitir que el PM construya el prototipo directamente cierra esa brecha, y la aceleración es real.
Por otro lado, los prototipos sin código tienden a convertirse en sistemas de producción por accidente. Lo que se construyó en tres días “para probar el concepto” se muestra a la dirección, la dirección lo adora, y de repente está en producción con toda la rigurosidad arquitectónica de un hackathon de sábado por la tarde. He visto esto con flujos de trabajo en Zapier, apps en Bubble, automatizaciones en Notion. No hay razón para que los prototipos de IA agentica sean la excepción.
La disciplina del marco en la etapa tres es lo que lo salva. Los prototipos están explícitamente definidos como desechables — prueba de concepto, no producción. El objetivo de la etapa es validar que el CUJ se sostiene cuando un agente lo ejecuta realmente, que los números de la ingeniería de valor eran correctos, y que los traspasos humanos funcionan. Una vez validado eso, pasas a la etapa cuatro, donde el sistema de producción real se construye con la arquitectura, seguridad y observabilidad que exige la producción.
Etapa 4: Escalar — La Etapa de la que Nadie Quiere Hablar
El curso es honesto en algo: la etapa cuatro — escalar y operacionalizar sistemas agenticos en toda la empresa — es la que tiene el playbook menos maduro. Todos siguen averiguando cómo hacerlo. Las empresas que lo han logrado (y no son tantas aún) lo tratan como un programa de varios trimestres que involucra equipos de plataforma, marcos de gobernanza, observabilidad de agentes y una política clara sobre cuándo la autoridad de decisión de un agente debe escalarse a una persona.
Los dos personajes que Clara utiliza para concretar esto son Beth, la directora de Estrategia de una cadena minorista ficticia llamada Symbol Mart, y Tomo, el líder técnico. El trabajo de Beth es mantener la transformación agentica alineada con el valor de negocio y asegurarse de que los proyectos priorizados realmente muevan los indicadores que debían mover. El trabajo de Tomo es garantizar que los sistemas que se construyen sean seguros, pragmáticos y lo suficientemente escalables para sobrevivir la transición de prototipo a despliegue empresarial.
La dupla importa. La razón por la que la mayoría de las iniciativas de IA agentica fracasan en la etapa cuatro es porque están en manos exclusivamente de una de esas dos personas. El liderazgo solo de Beth produce presentaciones y prototipos hermosos que nunca escalan. El liderazgo solo de Tomo produce sistemas robustos que automatizan cosas que nadie necesitaba automatizar. La afirmación operativa central del marco es que la tasa de éxito en la etapa cuatro es función de cuán estrechamente están acoplados esos dos roles a lo largo de toda la transformación.
Ese es el marco. Ahora déjame contarte dónde creo que se flexiona.
Qué Funciona Realmente y Qué Creo Que Está Sobreingenierizado
Quiero ser cuidadoso aquí, porque es fácil leer un marco de Google y tanto rendirse ante él como descartarlo. Ambas reacciones son perezosas. Esto es lo que realmente pienso después de analizarlo.
El cambio de mentalidad en la etapa de Descubrimiento es la pieza más importante, y la más fácil de pasar por alto. Casi nadie lo hace correctamente. Casi todos abordan la IA agentica llevando el modelo de proceso actual y encajando agentes en los pasos existentes. El costo de saltarse el ejercicio de “qué pasaría si” es que pasas un año construyendo agentes que solo hacen un proceso condenado un poco más rápido.
La disciplina de ingeniería de valor en la etapa de Diseño es la parte que voy a adoptar por completo y aplicar en mi propio trabajo, incluyendo proyectos que no tienen nada que ver con IA agentica. El principio se generaliza: cuantifica el valor antes de construir, nombra a la persona cuyo trabajo cambia y rechaza aprobar el proyecto hasta que puedas hacer ambas cosas. Probablemente escriba una publicación aparte solo sobre esto, porque lo merece.
El mapeo de CUJ es correcto en espíritu y algo pesado en la práctica para cualquier cosa por debajo de la escala empresarial. Si eres una startup de cinco personas o un creador en solitario, no necesitas un documento formal de CUJ. Necesitas recorrer el flujo de trabajo en una pizarra y marcar los traspasos. La formalidad del marco escala con el tamaño de la organización. Usa el principio, ajusta el artefacto a la escala.
El énfasis en no-code en la etapa de Construcción es adecuado para prototipos y peligroso para producción. Trátalo en consecuencia. El prototipo se construye rápido en Google AI Studio, Gemini Enterprise o la pila que uses. El sistema de producción se construye con un proceso de ingeniería real. No dejes que la demo se convierta en el despliegue.
La etapa de Escalado es donde el marco es honesto sobre sus propios límites, y eso lo respeto. Nadie tiene aún una hoja de ruta para una transformación agentica a nivel empresarial. Lo que el marco te da es la forma organizacional correcta: el emparejamiento de Beth y Tomo, la alineación de valor, el pragmatismo técnico. Los detalles tendrás que resolverlos haciendo.
Lo que el marco no dice explícitamente, y probablemente debería: una cantidad significativa de estas transformaciones va a fracasar. No porque el marco sea incorrecto, sino porque el cambio organizacional necesario para aplicarlo es realmente difícil. Permitir que un agente se adueñe de un proceso de extremo a extremo significa que el trabajo de alguien cambia. A veces ese cambio es enriquecedor: pasan de hacer el trabajo a supervisar el sistema. A veces es eliminación. El marco es un documento estratégico, no un documento de gestión del cambio. Vas a necesitar ambos.
Qué Significa Esto Si Estás Construyendo Ahora Mismo
Si eres desarrollador, el cambio más útil es dejar de preguntarte “¿qué tarea puedo automatizar con un agente?” y empezar a preguntarte “¿qué proceso puedo delegar a un sistema autónomo?”. Es una pregunta diferente, con una arquitectura diferente y un techo de valor completamente distinto. Los agentes que construyes bajo la segunda pregunta valen aproximadamente 10 veces más que los que construyes bajo la primera, según mi experiencia.
Si eres product manager o fundador, la disciplina de ingeniería de valor es la práctica de mayor apalancamiento que puedes adoptar este trimestre. Antes de aprobar la próxima funcionalidad de IA, escribe en un párrafo: qué cambia específicamente para el negocio cuando esto funciona, quién es la persona responsable de ese resultado hoy y qué sucede con su trabajo cuando el agente lo hace bien. Si no puedes escribir ese párrafo, la funcionalidad no está lista para ser construida.
Si diriges un negocio de comercio electrónico, el cambio hacia el comercio agentico no es un problema para 2030. Es un problema para 2026. El hecho de que el 70% de los consumidores se sientan cómodos con compras impulsadas por agentes significa que el agente de compra que vive dentro de ChatGPT o Gemini decidirá si tu producto siquiera aparece en el conjunto de consideración, mucho antes de que el cliente escriba el nombre de tu marca. Eso tiene implicaciones para la estructura de datos de producto, la accesibilidad vía API y la forma en que describes tus productos de manera legible para máquinas. Si estás construyendo la página de producto de hoy para el comprador humano del mañana, en realidad estás construyendo para un comprador que está siendo reemplazado silenciosamente.
Si eres líder empresarial, la dupla Beth-y-Tomo es la parte que debes interiorizar. Encuentra a tu Beth. Encuentra a tu Tomo. Haz que ambos sean copropietarios de la transformación. Si falta uno de los dos o queda relegado, el programa producirá algo —presentaciones o sistemas— pero no producirá transformación.
Una nota sobre la promesa del no-code
Hay un aspecto del enfoque del curso sobre el que quiero matizar con cautela. La promesa de que los PM de IA pueden construir sistemas agentivos de calidad de producción sin ingenieros es, en mi honesta opinión, parcialmente cierta y peligrosamente seductora.
La parte parcialmente cierta: los PM pueden, sin duda, crear prototipos que demuestren el CUJ, validen el valor y muestren el flujo de trabajo. Eso es real y representa un avance significativo. La parte peligrosamente seductora: la distancia entre un prototipo funcional y un sistema en producción que gestione seguridad, escalabilidad, recuperación de errores, observabilidad, cumplimiento y los casos límite que aparecen en la hora 73 de operación continua es enorme. Ahí es donde reside la ingeniería. El no-code no cierra esa brecha. Hace que el prototipo sea más rápido, lo cual es excelente. Trátalo como tal.
La forma correcta de interpretar el énfasis de Google en el no-code no es “ya no se necesitan ingenieros para la IA agentiva”. Es “la fase de prototipado ya no tiene que esperar a la disponibilidad de ingeniería, lo que significa que se pueden validar más ideas más rápido, lo que implica que la capacidad de ingeniería se dedica a los prototipos que demostraron su valor”. Esa es una afirmación mucho más modesta, y es la que realmente considero válida.
Lo que estoy haciendo diferente esta semana
Volviendo a la discusión del domingo por la mañana con la que empecé —esa en la que me di cuenta de que había construido siete agentes y cero flujos de trabajo—, ayer pasé el día rediseñando uno de ellos.
El scraper de precios de la competencia se está convirtiendo en un sistema de precios de la competencia. Sigue extrayendo los datos. Pero ahora razona sobre si la diferencia de precios importa según nuestro margen mínimo, redacta una propuesta de ajuste de precios, me envía una solicitud de aprobación en una línea con el razonamiento adjunto y, tras la aprobación, ejecuta el cambio y monitoriza la conversión durante 72 horas antes de mantener o revertir la acción. El trabajo que antes hacía yo —analizar los datos, decidir, ejecutar, monitorizar— ahora está estructurado por el sistema. Mi tarea es aprobar o rechazar la propuesta. Eso es un proceso, no una tarea.
Me llevó unas cuatro horas rediseñarlo. Estimo que me ahorrará cuatro horas al mes para siempre. La versión como agente me ahorraba cuarenta minutos a la semana. La versión como flujo de trabajo me ahorra medio día. Mismo modelo, mismos datos, mismas herramientas: la diferencia está en la pregunta que se plantea en la etapa de diseño.
Para eso sirve realmente el framework. No para hacer mejores presentaciones sobre estrategia de IA. Sino para que te plantees una pregunta diferente en el momento en que se decide toda la arquitectura de lo que vas a construir.
Elige esta semana una cosa que ya hayas "IA-izado" como tarea. Hazte la pregunta hipotética sobre ella. Pregúntate si un sistema agentivo podría hacerse cargo de todo el proceso en vez de solo una parte. Si la respuesta es sí, rediseñalo. Si la respuesta es no, pregúntate por qué —porque ese "no" suele señalar la verdadera limitación, y la verdadera limitación suele ser una transferencia manual que nadie se ha molestado en mapear.
Eso, más que cualquier framework, es el verdadero avance.
Preguntas Frecuentes
¿Cuál es la diferencia entre un agente de IA y un sistema de IA agéntica?
Un agente de IA realiza una sola tarea; un sistema de IA agéntica ejecuta un proceso completo de forma autónoma a través de múltiples pasos, decisiones y transferencias. El agente es una herramienta dentro de un flujo de trabajo aún gestionado por humanos. El sistema agéntico reemplaza el flujo de trabajo en sí. Para una distinción más profunda con ejemplos, consulta la sección anterior sobre agentes versus flujos de trabajo.
¿Cuáles son las cuatro etapas del Marco de Transformación de IA Agéntica de Google?
Las cuatro etapas son Descubrir (cambio de mentalidad de “as-is” a “what-if”), Diseñar (ingeniería de valor más mapeo del Recorrido Crítico del Usuario), Construir (prototipado sin código con herramientas como Google AI Studio y Gemini Enterprise) y Escalar (operacionalizar sistemas agénticos en toda la empresa). El orden importa: saltarse la etapa de Descubrir es la causa de fallo más común.
¿Qué es el comercio agéntico y por qué será relevante en 2026?
El comercio agéntico es el comercio electrónico realizado por agentes de IA que actúan en nombre de los compradores humanos: una experiencia de compra “cero clics” donde el agente descubre, evalúa y compra sin que el usuario visite un sitio web. eMarketer proyecta $20.9 mil millones en comercio electrónico impulsado por plataformas de IA en 2026, aproximadamente un aumento de 4 veces respecto a 2025, y McKinsey prevé $1 billón para 2030.
¿Qué es un Recorrido Crítico del Usuario (CUJ) en el diseño de IA agéntica?
Un Recorrido Crítico del Usuario mapea el camino específico de extremo a extremo que sigue un usuario (o un agente actuando en su nombre) para lograr un resultado significativo, marcando cada decisión, dependencia de datos y transferencia. El mapeo de CUJ revela las brechas operativas que pueden arruinar proyectos agénticos —acceso a datos faltante, aprobaciones no documentadas, transferencias rotas— antes de que se escriba una sola línea de código.
¿Pueden los product managers de IA construir sistemas agénticos sin ingenieros usando herramientas no-code?
Parcialmente. Los PM pueden construir prototipos validados utilizando herramientas como Google AI Studio y Gemini Enterprise, lo que representa una aceleración significativa. Pero pasar de un prototipo funcional a un sistema en producción que gestione seguridad, escalabilidad, recuperación de errores y observabilidad aún requiere ingeniería. El enfoque correcto es prototipado más rápido, no reemplazo de la ingeniería.
Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (desarrollos e integraciones a medida): fiverr.com/s/EgxYmWD
- Portafolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño & branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
