A medida que se aceleraba la adopción empresarial de la inteligencia artificial, McKinsey veía una necesidad creciente de ayudar a sus clientes a ir más allá de los principios de IA responsable y de los documentos de política.

Las organizaciones necesitaban una forma práctica de gobernar la IA a lo largo de todo el ciclo de vida, desde la aprobación inicial del caso de uso y la selección del modelo hasta el desarrollo, el despliegue, el monitoreo y el eventual retiro.

McKinsey enfrentaba, por tanto, una decisión estratégica de producto: ¿cómo sería la plataforma ideal de gobernanza de IA para empresas, y debía McKinsey construir esa capacidad internamente o asociarse con un proveedor tecnológico establecido?

La pregunta era más compleja que comparar funcionalidades de producto. El mercado de gobernanza de IA aún estaba emergiendo. Las plataformas líderes usaban un lenguaje similar (IA responsable, gobernanza de modelos, cumplimiento regulatorio y gestión de riesgos), pero diferían significativamente en su profundidad técnica, sus modelos operativos, sus capacidades de integración y su capacidad para sostener la gobernanza a escala empresarial.

Antes de evaluar posibles socios, McKinsey necesitaba establecer qué debía habilitar realmente una plataforma eficaz de gobernanza de IA; cómo la usarían los ejecutivos, los dueños de negocio, los equipos de riesgo, las áreas legales, los tecnólogos y los auditores; qué capacidades eran esenciales para la adopción empresarial; qué elementos podían crear una diferenciación significativa; qué podía McKinsey construir y mantener razonablemente de forma interna; dónde podían obtenerse del mercado tecnología especializada, inteligencia regulatoria o capacidades de pruebas técnicas; y cómo una plataforma podía complementar las capacidades de asesoría y transformación de McKinsey sin convertirse en un producto de software desconectado.

El momento aumentaba la urgencia. El Instituto Nacional de Estándares y Tecnología de Estados Unidos había publicado su AI Risk Management Framework en enero de 2023, dando a las organizaciones una estructura para gestionar el riesgo de la IA. En diciembre de 2023, ISO/IEC 42001 se convirtió en el primer estándar internacional de sistemas de gestión de IA. Las empresas necesitaban cada vez más traducir esos marcos en procesos operativos, controles técnicos y evidencia auditable.

Saad comenzó por abordar la pregunta desde la perspectiva de las personas que, en última instancia, serían responsables de gobernar la IA dentro de una organización compleja.

Su experiencia iba más allá de asesorar sobre políticas de IA. Había dirigido personalmente las funciones de tecnología empresarial, ciberseguridad, privacidad, cumplimiento y gestión de riesgos como Head of Corporate Technology en Zillow, CTO de la Ciudad de Seattle y CIO de la Ciudad de Ottawa. En Amazon, también había ayudado a grandes organizaciones globales a identificar y poner en operación oportunidades de IA a escala.

Esto le permitió evaluar la categoría de plataformas a través de tres lentes complementarios: el lente ejecutivo, centrado en la visibilidad, el aseguramiento y la información para la toma de decisiones que requerirían los consejos y los ejecutivos; el lente de gobernanza, centrado en cómo los equipos legales, de riesgo, privacidad, seguridad y cumplimiento establecerían y harían cumplir los requisitos; y el lente de entrega, centrado en cómo los científicos de datos, desarrolladores, equipos de producto y dueños de negocio podrían satisfacer los requisitos de gobernanza sin impedir la experimentación y la innovación.

Saad aportó además experiencia en construcción de producto, adquirida al desarrollar el AI Governance Sandbox. Ese trabajo trataba la gobernanza no como un conjunto estático de políticas, sino como un sistema en funcionamiento que abarca alineación regulatoria, aplicación de políticas, documentación de gobernanza, evaluación técnica, pruebas de riesgo e integración empresarial. La amplitud actual del AI Governance Sandbox (que incluye validación contra más de 20 marcos, políticas como código, generación de artefactos de gobernanza, pruebas de robustez, evaluación de modelos fundacionales, detección de sesgos, despliegue privado e integración de sistemas) ilustra la perspectiva multidimensional de producto que Saad aportó al proyecto.

Antes de revisar posibles socios, Saad ayudó a McKinsey a definir un blueprint de la mejor plataforma empresarial de gobernanza de IA posible. El blueprint consideró las capacidades requeridas a lo largo del ciclo de vida de la IA: inventario y titularidad de la IA; clasificación de riesgos; flujos de trabajo de gobernanza; alineación con políticas y regulación; implementación de controles; evaluación técnica; gobernanza de IA de terceros; supervisión humana; evidencia y auditabilidad; monitoreo del ciclo de vida; reportes ejecutivos; integración empresarial; y flexibilidad de despliegue.

El blueprint resultante fue intencionalmente más amplio que una lista de verificación de cumplimiento regulatorio. Describía cómo una plataforma de gobernanza debía ayudar a una organización a tomar mejores decisiones, permitiendo al mismo tiempo que la adopción responsable de la IA avanzara con rapidez.

Con el estado objetivo establecido, Saad evaluó múltiples plataformas líderes de gobernanza de IA contra un marco común, definido desde la perspectiva del operador. Los proveedores no fueron evaluados únicamente por la solidez de sus demostraciones de producto ni por el número de regulaciones citadas en sus materiales de marketing. La evaluación consideró la amplitud y madurez de las capacidades, la usabilidad para distintos interesados, el soporte a todo el ciclo de vida de la IA, la cobertura regulatoria y de políticas, las capacidades de riesgo técnico y de pruebas, la integración con la arquitectura empresarial y los flujos de entrega, el soporte tanto al aprendizaje automático tradicional como a la IA generativa, la configurabilidad, la seguridad, la privacidad, las consideraciones de despliegue, la escalabilidad, la auditabilidad y la idoneidad para una alianza estratégica más amplia.

Usar el mismo blueprint para cada proveedor permitió a McKinsey distinguir entre similitudes superficiales de funcionalidad y diferencias significativas de capacidad operativa. También evitó que el proceso se convirtiera en una evaluación dirigida por los proveedores, en la que la definición del problema cambiara según el producto que se estuviera demostrando.

Saad ayudó después a enmarcar la decisión estratégica central. El análisis no se redujo a una comparación binaria entre construir todo internamente y comprar un producto externo terminado. Consideró un espectro de modelos posibles: construir una plataforma propietaria; combinar capacidades desarrolladas internamente con tecnología especializada de terceros; asociarse con un proveedor establecido de gobernanza de IA; configurar una plataforma externa alrededor de la propiedad intelectual, las metodologías y los flujos de trabajo con clientes de McKinsey; y usar distintos proveedores para distintos elementos del ciclo de vida de la gobernanza.

Para cada camino, Saad ayudó a aclarar las implicaciones en tiempo de salida al mercado, inversión en producto, capacidades técnicas, mantenimiento regulatorio, requisitos de integración, diferenciación, control sobre la propiedad intelectual, titularidad continua del producto, capacidad de atender clientes globales, dependencia de un proveedor externo y escalabilidad a largo plazo.

La decisión se convirtió en: ¿qué capacidades debía poseer McKinsey porque crean diferenciación estratégica, y qué capacidades podían acelerarse o fortalecerse mediante un socio especializado?

Saad tradujo el trabajo en tres entregables principales: un blueprint de plataforma que define las capacidades, los flujos de trabajo, los usuarios y los requisitos empresariales asociados a una plataforma eficaz de gobernanza de IA; una evaluación escrita que compara las principales plataformas del mercado y sus fortalezas relativas, brechas e idoneidad como posibles socios estratégicos; y una presentación ejecutiva que explica el panorama del mercado, los requisitos del operador, los intercambios entre construir y asociarse y las opciones estratégicas disponibles para McKinsey.

Los entregables se diseñaron para dar a los ejecutivos una base clara para la discusión, en lugar de presentar la evaluación tecnológica como una recomendación predeterminada. El rol de Saad no era tomar la decisión final de construir o asociarse en nombre de McKinsey. Su rol era mejorar la calidad de esa decisión definiendo el resultado deseado, fundamentando la evaluación en experiencia operativa real y haciendo visibles los intercambios.

El proyecto dio a McKinsey una base, informada por la experiencia de un operador, para abordar una categoría tecnológica emergente y estratégicamente importante.

Entregó una definición compartida de lo que debe lograr una plataforma empresarial de gobernanza de IA; un blueprint de plataforma que conecta los principios de gobernanza con flujos de trabajo prácticos y capacidades técnicas; un marco común para evaluar a los proveedores líderes; una evaluación escrita de las fortalezas relativas y las brechas de los posibles socios; una clasificación estructurada de las soluciones relevantes del mercado; mayor claridad sobre los intercambios entre el desarrollo interno y la alianza externa; una distinción más clara entre las capacidades que McKinsey podría querer poseer y las que podría obtener de un proveedor especializado; un paquete de decisión a nivel ejecutivo que tradujo un panorama tecnológico complejo en opciones estratégicas; y una base más sólida para determinar cómo la tecnología podía complementar las capacidades de asesoría en gobernanza de IA de McKinsey.

El valor del encargo no estuvo ligado a una sola funcionalidad de software ni a la selección de un proveedor. Ayudó a McKinsey a evitar comenzar con un producto, una alianza o un programa de construcción interna antes de establecer lo que los clientes y los operadores empresariales realmente requerirían.

Esa distinción fue importante porque la gobernanza de IA se estaba convirtiendo rápidamente en una capacidad operativa, y no en un ejercicio ocasional de cumplimiento. La propia investigación de McKinsey encontró más tarde que las organizaciones que obtenían mayor valor de la IA generativa tenían más probabilidades de incorporar revisiones de riesgo desde etapas tempranas del desarrollo e involucrar a las funciones legales y de gobernanza en el ciclo de vida de la IA.

Durante un taller de liderazgo en Madrid, Expedia identificó la mejora del Net Promoter Score como una prioridad de negocio importante.

La discusión hizo aflorar una paradoja central. Los datos internos del taller indicaban que más del 80% de los viajeros tenía una buena experiencia y, sin embargo, Expedia tenía relativamente poca presencia en la vida de esos clientes satisfechos una vez completadas sus reservas. Las interacciones más significativas de la empresa después de la reserva solían concentrarse en momentos negativos, como cuando un vuelo se interrumpía, una reserva cambiaba o un viajero necesitaba asistencia.

Saad replanteó el asunto como algo más que un problema de servicio al cliente o de NPS. Era un problema de modelo de relación.

La oportunidad consistía en llevar a Expedia más allá de una relación principalmente transaccional, en la que el cliente reserva y se va, y crear una razón para que el viajero permaneciera conectado con Expedia durante todo el viaje. Eso significaba ser útil durante la inspiración, la planeación, la preparación, el viaje mismo y los momentos inesperados, en lugar de esperar a que el cliente regresara con un problema.

La investigación posterior de Expedia sobre los viajeros reforzó la escala de esta oportunidad. En promedio, los viajeros consultaban 141 páginas de contenido de viajes y dedicaban 303 minutos a interactuar con contenido de viajes durante los 45 días previos a la reserva. Aproximadamente el 80% visitaba una agencia de viajes en línea en algún punto de ese recorrido. Fuente: Expedia Group Path to Purchase Research.

Saad facilitó la discusión del liderazgo en torno a una nueva pregunta estratégica: ¿cómo podía Expedia convertirse en un compañero valioso a lo largo de todo el recorrido del viajero, y no solo en el lugar donde se reservaba el viaje o donde se resolvían los problemas?

A partir de esta pregunta, Saad originó la propuesta Expedia Travel Companion: una experiencia habilitada por IA, diseñada para mantenerse continuamente útil, entender el contexto del viajero y acompañar tanto los momentos positivos como los difíciles.

El concepto era deliberadamente más amplio que un chatbot convencional de servicio al cliente. Su propósito era ayudar a reposicionar a Expedia como un participante permanente y confiable en la experiencia de viaje.

Saad tradujo el concepto en un PRFAQ, usando el mecanismo Working Backwards de Amazon para definir la experiencia futura del cliente antes de pasar a la implementación detallada. La narrativa articulaba la necesidad no cubierta del viajero y la promesa al cliente, la experiencia que Expedia podía crear a lo largo del ciclo de vida del viaje, cómo la IA podía hacer la relación más contextual, proactiva y personalizada, por qué la propuesta importaba para el NPS, la lealtad y el compromiso sostenido del cliente, y las preguntas que Expedia tendría que resolver antes de implementar.

El PRFAQ fue revisado y respaldado por el liderazgo de Expedia, lo que estableció la alineación en torno a la propuesta y creó un mandato para desarrollarla más a fondo.

Saad desarrolló después una narrativa de seis páginas al estilo de Amazon, que llevó la propuesta de una idea ejecutiva hacia una estrategia de producto lista para la decisión. El documento de seis páginas reunió el problema del cliente, la lógica estratégica, las experiencias prioritarias, la propuesta de valor y las consideraciones necesarias para pasar del concepto a la implementación. Creó una narrativa compartida que los líderes de producto, tecnología y negocio podían usar para evaluar la oportunidad y tomar decisiones.

Trabajando con un equipo multifuncional, Saad ayudó a desarrollar un prototipo que demostraba cómo el Travel Companion podía operar a lo largo del recorrido del viajero. El prototipo permitió al liderazgo ver cómo Expedia podía apoyar proactivamente a un viajero en lugar de esperar una búsqueda, una transacción o una solicitud de servicio. También desplazó la conversación del potencial abstracto de la IA hacia una experiencia de cliente tangible que podía probarse, cuestionarse y desarrollarse.

El proyecto transformó una preocupación general sobre el NPS en una dirección de producto concreta habilitada por IA.

Produjo un nuevo planteamiento estratégico del reto de relación con el cliente de Expedia, un PRFAQ respaldado por el liderazgo que definía la experiencia futura, una narrativa de seis páginas que conectaba el valor para el cliente con la estrategia de negocio, un prototipo que ilustraba cómo podía funcionar la propuesta a lo largo del viaje, y la alineación ejecutiva en torno a llevar a Expedia de una plataforma orientada a la transacción hacia una relación de viaje continua.

El concepto de Travel Companion fue posteriormente desarrollado por Expedia y presentado públicamente como Romie el 14 de mayo de 2024.

Expedia describió a Romie como un asistente de IA que abarca la planeación, la búsqueda, la reserva y la asistencia durante el viaje. Sus capacidades anunciadas públicamente incluían participar en conversaciones de viajes en grupo, convertir esas conversaciones en búsquedas personalizadas, construir itinerarios, monitorear interrupciones, proponer alternativas y actualizar la información del viaje en tiempo real.

El producto alfa encarnaba el principio central de la propuesta original de Travel Companion: Expedia podía seguir siendo valiosa a lo largo de toda la experiencia, no solo cuando el cliente hacía una reserva o cuando algo salía mal. Fuente: anuncio de Romie de Expedia Group.

Expedia Group se había convertido en uno de los negocios de tecnología de viajes más grandes del mundo mediante la expansión internacional y la adquisición de múltiples marcas de viajes. Ese crecimiento creó una oportunidad significativa, pero también una complejidad tecnológica considerable. Cada negocio adquirido traía sus propias plataformas, arquitectura, recursos de nube, prácticas operativas y estándares de gobernanza. AWS ha descrito públicamente el entorno de nube de Expedia como uno que abarca más de 21 marcas adquiridas, mientras que el anterior Chief Technology Officer de Expedia describió pilas tecnológicas derivadas de adquisiciones que podían frenar la innovación y afectar la experiencia de viajeros y socios. Al mismo tiempo, Expedia necesitaba optimizar un patrimonio tecnológico que representaba aproximadamente US$600 millones de gasto, mantener el desempeño de aplicaciones e infraestructura conforme crecían los volúmenes de transacciones, escalar los servicios tecnológicos de forma consistente hacia los mercados internacionales, integrar a las empresas recién adquiridas sin perpetuar plataformas fragmentadas, fortalecer la disciplina de seguridad y arquitectura, y dar a los ejecutivos mejor visibilidad sobre el costo, el desempeño, el riesgo y la responsabilidad de la tecnología. El asunto era, por tanto, mayor que reducir la factura de la nube. Expedia necesitaba una capacidad empresarial repetible para gestionar la tecnología a escala, una que pudiera introducir estándares comunes y disciplina financiera sin frenar a los equipos de ingeniería ni limitar la innovación.

Saad posicionó el Cloud Centre of Excellence como algo más que una función centralizada de gobernanza o de control de costos. El caso de negocio conectó el modelo operativo propuesto con cuatro prioridades estratégicas: optimización de costos, desempeño, escalabilidad internacional e integración de adquisiciones. Este planteamiento ayudó a desplazar la discusión de una reducción de costos puntual hacia la creación de una capacidad de escalamiento empresarial de largo plazo. Saad desarrolló el caso de negocio del Cloud Centre of Excellence, reuniendo la lógica financiera, operativa y estratégica. El caso abordó la escala del gasto tecnológico, el costo de las prácticas fragmentadas, el valor de los estándares comunes de arquitectura, gobernanza y seguridad, la necesidad de una titularidad y unos derechos de decisión más claros, los beneficios de estandarizar la integración de adquisiciones, las capacidades organizacionales requeridas para sostener el modelo, y las inversiones por fases y el patrocinio necesarios para avanzar. Después presentó y socializó el caso con los ejecutivos correspondientes de Expedia, traduciendo la propuesta técnica en resultados de negocio como crecimiento rentable, expansión internacional más rápida, mejor desempeño, integración de adquisiciones más predecible, menor riesgo y mayor transparencia sobre la inversión en tecnología. Saad diseñó un modelo integral que cubría gobernanza y derechos de decisión, FinOps y gestión de costos, estándares de arquitectura, gestión del desempeño, soporte a migraciones, seguridad y riesgo, integración de adquisiciones, capacitación y adopción, tableros ejecutivos y KPIs. Tras asegurar el apoyo ejecutivo, convirtió el caso de negocio en un plan de implementación y supervisó la ejecución, ayudando a mantener la alineación y asegurando que el Centre of Excellence permaneciera conectado con los objetivos de crecimiento, financieros y tecnológicos de Expedia.

El proyecto llevó a Expedia de una necesidad estratégica de mayor disciplina en la nube a un modelo operativo empresarial ejecutable. Estableció un Cloud Centre of Excellence integral que abarca gobernanza, finanzas, arquitectura, desempeño, seguridad y adopción; un marco común para gestionar aproximadamente US$600 millones en gasto tecnológico; mayor visibilidad ejecutiva sobre el costo, el desempeño y el riesgo de la tecnología; una base repetible para integrar empresas adquiridas y entornos tecnológicos; estándares compartidos capaces de sostener la expansión internacional sin recrear capacidades tecnológicas mercado por mercado; un mecanismo para equilibrar la consistencia empresarial con la velocidad y la autonomía que requieren los equipos de producto e ingeniería; y una hoja de ruta de implementación que llevó la iniciativa más allá de la estrategia y hacia la ejecución. AWS describe de forma independiente el recorrido más amplio de Expedia en la nube como la creación de consistencia entre los recursos de nube, la estandarización de la gobernanza en más de 21 marcas, la simplificación de las pilas tecnológicas, el establecimiento de un Cloud Centre of Excellence y la creación de servicios compartidos para desarrolladores en todo el grupo. Un ejemplo público de esos principios operativos a escala es la plataforma compartida de bases de datos de Expedia, Cerebro, que pasó de dar soporte a tres cuentas de AWS a más de 400, redujo el aprovisionamiento de bases de datos de días a minutos y permitió a Expedia aplicar prácticas comunes de seguridad, costo y gobernanza manteniendo un equipo de soporte reducido. Estos resultados reportados públicamente demuestran el tipo de reutilización, estandarización y apalancamiento operativo que el Centre of Excellence fue diseñado para institucionalizar.

As enterprise adoption of artificial intelligence accelerated, McKinsey was seeing a growing need to help clients move beyond responsible-AI principles and policy documents.

Organizations needed a practical way to govern AI across the full lifecycle, from initial use-case approval and model selection through development, deployment, monitoring and eventual retirement.

McKinsey therefore faced a strategic product decision: what would the ideal enterprise AI governance platform look like, and should McKinsey build that capability internally or partner with an established technology provider?

The question was more complex than comparing product features. The AI governance market was still emerging. Leading platforms used similar language - responsible AI, model governance, regulatory compliance and risk management - but differed significantly in their technical depth, operating models, integration capabilities and ability to support governance at enterprise scale.

Before assessing potential partners, McKinsey needed to establish what an effective AI governance platform should actually enable; how executives, business owners, risk teams, legal functions, technologists and auditors would use it; which capabilities were essential for enterprise adoption; which elements could create meaningful differentiation; what McKinsey could reasonably build and maintain internally; where specialist technology, regulatory intelligence or technical testing capabilities could be sourced from the market; and how a platform could complement McKinsey's advisory and transformation capabilities without becoming a disconnected software product.

The timing increased the urgency. The US National Institute of Standards and Technology had released its AI Risk Management Framework in January 2023, providing organizations with a structure for managing AI risk. In December 2023, ISO/IEC 42001 became the first international AI management-system standard. Enterprises increasingly needed to translate such frameworks into operating processes, technical controls and auditable evidence.

Saad began by approaching the question from the perspective of the people who would ultimately be accountable for governing AI inside a complex organization.

His experience extended beyond advising on AI policy. He had personally led enterprise technology, cybersecurity, privacy, compliance and risk-management functions as Head of Corporate Technology at Zillow, CTO of the City of Seattle and CIO of the City of Ottawa. At Amazon, he had also helped major global organizations identify and operationalize AI opportunities at scale.

This allowed him to evaluate the platform category through three complementary lenses: the executive lens, focused on the visibility, assurance and decision-making information boards and executives would require; the governance lens, focused on how legal, risk, privacy, security and compliance teams would establish and enforce requirements; and the delivery lens, focused on how data scientists, developers, product teams and business owners could satisfy governance requirements without preventing experimentation and innovation.

Saad also brought product-building experience from developing the AI Governance Sandbox. That work treated governance not as a static set of policies, but as a working system spanning regulatory alignment, policy enforcement, governance documentation, technical evaluation, risk testing and enterprise integration. The current breadth of the AI Governance Sandbox - including validation against more than 20 frameworks, policy-as-code, governance-artifact generation, robustness testing, foundation-model evaluation, bias detection, private deployment and systems integration - illustrates the multidimensional product perspective Saad brought to the engagement.

Before reviewing potential partners, Saad helped McKinsey define a blueprint for the best possible enterprise AI governance platform. The blueprint considered the capabilities required across the AI lifecycle: AI inventory and ownership; risk classification; governance workflows; policy and regulatory alignment; control implementation; technical evaluation; third-party AI governance; human oversight; evidence and auditability; lifecycle monitoring; executive reporting; enterprise integration; and deployment flexibility.

The resulting blueprint was intentionally broader than a regulatory-compliance checklist. It described how a governance platform should help an organization make better decisions while allowing responsible AI adoption to proceed at speed.

With the target state established, Saad assessed multiple leading AI governance platforms against a common operator-led framework. Providers were not evaluated solely on the strength of product demonstrations or the number of regulations referenced in their marketing materials. The assessment considered breadth and maturity of capabilities, usability for different stakeholders, support for the full AI lifecycle, regulatory and policy coverage, technical risk and testing capabilities, integration with enterprise architecture and delivery workflows, support for traditional machine learning and generative AI, configurability, security, privacy, deployment considerations, scalability, auditability and suitability for a broader strategic partnership.

Using the same blueprint for each provider allowed McKinsey to distinguish between superficial feature similarity and meaningful differences in operating capability. It also prevented the process from becoming a vendor-led evaluation in which the definition of the problem changed depending on which product was being demonstrated.

Saad then helped frame the central strategic decision. The analysis was not reduced to a binary comparison between building everything internally and purchasing a finished external product. It considered a spectrum of potential models: building a proprietary platform; combining internally developed capabilities with specialist third-party technology; partnering with an established AI governance provider; configuring an external platform around McKinsey's intellectual property, methodologies and client workflows; and using different providers for different elements of the governance lifecycle.

For each path, Saad helped clarify the implications for time to market, product investment, technical capabilities, regulatory maintenance, integration requirements, differentiation, control over intellectual property, ongoing product ownership, ability to support global clients, dependence on a third-party provider and long-term scalability.

The decision became: which capabilities should McKinsey own because they create strategic differentiation, and which capabilities could be accelerated or strengthened through a specialist partner?

Saad translated the work into three principal deliverables: a platform blueprint defining the capabilities, workflows, users and enterprise requirements associated with an effective AI governance platform; a written assessment comparing leading market platforms and their relative strengths, gaps and suitability as potential strategic partners; and an executive presentation explaining the market landscape, operator requirements, build-versus-partner trade-offs and strategic choices available to McKinsey.

The deliverables were designed to give executives a clear basis for discussion rather than present the technology assessment as a predetermined recommendation. Saad's role was not to make the final build-versus-partner decision on McKinsey's behalf. His role was to improve the quality of that decision by defining the desired outcome, grounding the assessment in real operating experience and making the trade-offs visible.

The engagement gave McKinsey an operator-informed foundation for approaching an emerging and strategically important technology category.

It delivered a shared definition of what an enterprise AI governance platform should accomplish; a platform blueprint connecting governance principles to practical workflows and technical capabilities; a common framework for evaluating leading providers; a written assessment of the relative strengths and gaps of potential partners; a structured ranking of relevant market solutions; greater clarity on the trade-offs between internal development and external partnership; a clearer distinction between the capabilities McKinsey might want to own and those it could obtain from a specialist provider; an executive-level decision package that translated a complex technology landscape into strategic choices; and a stronger basis for determining how technology could complement McKinsey's AI governance advisory capabilities.

The value of the assignment was not tied to a single software feature or vendor selection. It helped McKinsey avoid beginning with a product, partnership or internal build program before establishing what clients and enterprise operators would actually require.

That distinction was important because AI governance was rapidly becoming an operating capability rather than an occasional compliance exercise. McKinsey's own research later found that organizations experiencing the greatest value from generative AI were more likely to embed risk reviews early in development and involve legal and governance functions in the AI lifecycle.

During a leadership workshop in Madrid, Expedia identified improvement in Net Promoter Score as an important business priority.

The discussion surfaced a central paradox. Internal workshop data indicated that more than 80% of travelers had a good experience, yet Expedia had relatively little presence in the lives of those satisfied customers once their reservations were complete. The company's most meaningful post-booking interactions were often concentrated around negative moments, such as when a flight was disrupted, a reservation changed or a traveler needed assistance.

Saad reframed the issue as more than a customer-service or NPS problem. It was an engagement-model problem.

The opportunity was to move Expedia beyond a primarily transactional relationship, where the customer books and leaves, and create a reason for the traveler to remain connected with Expedia throughout the journey. That meant being useful during inspiration, planning, preparation, the trip itself and unexpected moments, rather than waiting for the customer to return with a problem.

Expedia's subsequent traveler research reinforced the scale of this opportunity. On average, travelers viewed 141 pages of travel content and spent 303 minutes engaging with travel content during the 45 days before booking. Approximately 80% visited an online travel agency at some point in that journey. Source: Expedia Group Path to Purchase Research.

Saad facilitated the leadership discussion around a new strategic question: How could Expedia become a valuable companion throughout the traveler's journey, not simply the place where the journey was booked or where problems were resolved?

From this question, Saad originated the Expedia Travel Companion proposition: an AI-enabled experience designed to remain continuously useful, understand the traveler's context and support positive as well as difficult moments.

The concept was deliberately broader than a conventional customer-service chatbot. Its purpose was to help reposition Expedia as a persistent and trusted participant in the travel experience.

Saad translated the concept into a PRFAQ, using Amazon's Working Backwards mechanism to define the future customer experience before moving into detailed implementation. The narrative articulated the unmet traveler need and customer promise, the experience Expedia could create across the travel lifecycle, how AI could make the relationship more contextual, proactive and personalized, why the proposition mattered for NPS, loyalty and sustained customer engagement, and the questions Expedia would need to resolve before implementation.

The PRFAQ was reviewed and endorsed by Expedia leadership, establishing alignment around the proposition and creating a mandate to develop it further.

Saad then developed an Amazon-style six-page narrative that moved the proposition from an executive idea toward a decision-ready product strategy. The six-pager brought together the customer problem, strategic rationale, priority experiences, value proposition and considerations required to move from concept to implementation. It created a shared narrative that product, technology and business leaders could use to evaluate the opportunity and make decisions.

Working with a cross-functional team, Saad helped develop a prototype demonstrating how the Travel Companion could operate across the traveler journey. The prototype allowed leadership to see how Expedia could proactively support a traveler rather than waiting for a search, transaction or service request. It also shifted the conversation from the abstract potential of AI to a tangible customer experience that could be tested, challenged and developed.

The engagement transformed a broad NPS concern into a concrete AI-enabled product direction.

It produced a new strategic framing of Expedia's customer-engagement challenge, a leadership-endorsed PRFAQ defining the future experience, a six-page narrative connecting customer value with business strategy, a prototype illustrating how the proposition could work across the journey, and executive alignment around moving Expedia from a transaction-oriented platform toward a continuous travel relationship.

The Travel Companion concept was subsequently taken forward by Expedia and publicly introduced as Romie on May 14, 2024.

Expedia described Romie as an AI assistant spanning planning, shopping, booking and in-trip assistance. Its publicly announced capabilities included participating in group travel conversations, converting those conversations into personalized searches, building itineraries, monitoring disruptions, proposing alternatives and updating trip information in real time.

The alpha product embodied the central principle behind the original Travel Companion proposition: Expedia could remain valuable throughout the experience, not only when the customer made a reservation or when something went wrong. Source: Expedia Group's Romie Announcement.

Expedia Group had grown into one of the world's largest travel-technology businesses through international expansion and the acquisition of multiple travel brands. That growth created significant opportunity, but also considerable technology complexity. Each acquired business brought its own platforms, architecture, cloud resources, operating practices and governance standards. AWS has publicly described Expedia's cloud environment as spanning more than 21 acquired brands, while Expedia's former Chief Technology Officer described acquisition-driven technology stacks that could stifle innovation and affect the experience of travelers and partners. At the same time, Expedia needed to optimize a technology estate representing approximately $600 million in spend, maintain application and infrastructure performance as transaction volumes grew, scale technology services consistently into international markets, integrate newly acquired companies without perpetuating fragmented platforms, strengthen security and architecture discipline, and give executives better visibility into technology cost, performance, risk and accountability. The issue was therefore larger than reducing the cloud bill. Expedia needed a repeatable enterprise capability for managing technology at scale, one that could introduce common standards and financial discipline without slowing engineering teams or limiting innovation.

Saad positioned the Cloud Centre of Excellence as more than a centralized governance or cost-control function. The business case connected the proposed operating model to four strategic priorities: cost optimization, performance, international scalability and acquisition integration. This framing helped move the discussion away from one-time cost reduction and toward the creation of a long-term enterprise scaling capability. Saad developed the business case for the Cloud Centre of Excellence, bringing together the financial, operational and strategic rationale. The case addressed the scale of technology spend, the cost of fragmented practices, the value of common architecture, governance and security standards, the need for clearer ownership and decision rights, the benefits of standardizing acquisition integration, the organizational capabilities required to sustain the model, and the phased investments and sponsorship needed to proceed. He then presented and socialized the case with the appropriate Expedia executives, translating the technical proposition into business outcomes such as profitable growth, faster international expansion, better performance, more predictable acquisition integration, reduced risk and greater transparency over technology investment. Saad designed a comprehensive model covering governance and decision rights, FinOps and cost management, architecture standards, performance management, migration support, security and risk, acquisition integration, training and adoption, executive dashboards and KPIs. After securing executive support, he converted the business case into an implementation plan and oversaw execution, helping maintain alignment and ensuring the Centre of Excellence remained connected to Expedia's growth, financial and technology objectives.

The engagement moved Expedia from a strategic need for greater cloud discipline to an executable enterprise operating model. It established a comprehensive Cloud Centre of Excellence spanning governance, finance, architecture, performance, security and adoption; a common framework for managing approximately $600 million in technology spend; greater executive visibility into technology cost, performance and risk; a repeatable foundation for integrating acquired companies and technology environments; shared standards that could support international expansion without recreating technology capabilities market by market; a mechanism for balancing enterprise consistency with the speed and autonomy required by product and engineering teams; and an implementation roadmap that moved the initiative beyond strategy and into execution. AWS independently describes Expedia's broader cloud journey as creating consistency across cloud resources, standardizing governance across more than 21 brands, simplifying technology stacks, establishing a Cloud Centre of Excellence and creating shared developer services across the group. One public example of those operating principles at scale is Expedia's shared database platform, Cerebro, which expanded from supporting three AWS accounts to more than 400, reduced database provisioning from days to minutes, and allowed Expedia to apply common security, cost and governance practices while maintaining a lean support team. These publicly reported results demonstrate the type of reuse, standardization and operating leverage the Centre of Excellence was designed to institutionalize.

À medida que a adoção corporativa da inteligência artificial se acelerava, a McKinsey via uma necessidade crescente de ajudar os clientes a ir além dos princípios de IA responsável e dos documentos de política.

As organizações precisavam de uma forma prática de governar a IA ao longo de todo o ciclo de vida, desde a aprovação inicial do caso de uso e a seleção do modelo até o desenvolvimento, a implantação, o monitoramento e a eventual desativação.

A McKinsey enfrentava, portanto, uma decisão estratégica de produto: como seria a plataforma ideal de governança de IA para empresas, e a McKinsey deveria construir essa capacidade internamente ou fazer parceria com um fornecedor de tecnologia estabelecido?

A questão era mais complexa do que comparar funcionalidades de produto. O mercado de governança de IA ainda estava emergindo. As plataformas líderes usavam uma linguagem semelhante (IA responsável, governança de modelos, conformidade regulatória e gestão de riscos), mas diferiam significativamente em profundidade técnica, modelos operacionais, capacidades de integração e capacidade de sustentar a governança em escala corporativa.

Antes de avaliar possíveis parceiros, a McKinsey precisava estabelecer o que uma plataforma eficaz de governança de IA deveria realmente viabilizar; como executivos, donos de negócio, equipes de risco, áreas jurídicas, tecnólogos e auditores a usariam; quais capacidades eram essenciais para a adoção corporativa; quais elementos poderiam criar diferenciação significativa; o que a McKinsey poderia razoavelmente construir e manter internamente; onde tecnologia especializada, inteligência regulatória ou capacidades de testes técnicos poderiam ser obtidas no mercado; e como uma plataforma poderia complementar as capacidades de consultoria e transformação da McKinsey sem se tornar um produto de software desconectado.

O momento aumentava a urgência. O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos havia publicado seu AI Risk Management Framework em janeiro de 2023, dando às organizações uma estrutura para gerenciar o risco de IA. Em dezembro de 2023, a ISO/IEC 42001 tornou-se o primeiro padrão internacional de sistemas de gestão de IA. As empresas precisavam cada vez mais traduzir esses frameworks em processos operacionais, controles técnicos e evidências auditáveis.

Saad começou abordando a questão a partir da perspectiva das pessoas que, em última instância, seriam responsáveis por governar a IA dentro de uma organização complexa.

Sua experiência ia além de assessorar sobre políticas de IA. Ele havia liderado pessoalmente as funções de tecnologia corporativa, cibersegurança, privacidade, conformidade e gestão de riscos como Head of Corporate Technology na Zillow, CTO da Cidade de Seattle e CIO da Cidade de Ottawa. Na Amazon, também havia ajudado grandes organizações globais a identificar e operacionalizar oportunidades de IA em escala.

Isso lhe permitiu avaliar a categoria de plataformas por meio de três lentes complementares: a lente executiva, focada na visibilidade, na garantia e nas informações para tomada de decisão que conselhos e executivos exigiriam; a lente de governança, focada em como as equipes jurídica, de risco, privacidade, segurança e conformidade estabeleceriam e fariam cumprir os requisitos; e a lente de entrega, focada em como cientistas de dados, desenvolvedores, equipes de produto e donos de negócio poderiam atender aos requisitos de governança sem impedir a experimentação e a inovação.

Saad trouxe também experiência em construção de produto, adquirida no desenvolvimento do AI Governance Sandbox. Esse trabalho tratava a governança não como um conjunto estático de políticas, mas como um sistema em funcionamento que abrange alinhamento regulatório, aplicação de políticas, documentação de governança, avaliação técnica, testes de risco e integração corporativa. A amplitude atual do AI Governance Sandbox (incluindo validação contra mais de 20 frameworks, políticas como código, geração de artefatos de governança, testes de robustez, avaliação de modelos de fundação, detecção de vieses, implantação privada e integração de sistemas) ilustra a perspectiva multidimensional de produto que Saad trouxe ao projeto.

Antes de analisar possíveis parceiros, Saad ajudou a McKinsey a definir um blueprint da melhor plataforma corporativa de governança de IA possível. O blueprint considerou as capacidades necessárias ao longo do ciclo de vida da IA: inventário e propriedade da IA; classificação de riscos; fluxos de trabalho de governança; alinhamento com políticas e regulação; implementação de controles; avaliação técnica; governança de IA de terceiros; supervisão humana; evidências e auditabilidade; monitoramento do ciclo de vida; relatórios executivos; integração corporativa; e flexibilidade de implantação.

O blueprint resultante foi intencionalmente mais amplo do que uma lista de verificação de conformidade regulatória. Ele descrevia como uma plataforma de governança deveria ajudar uma organização a tomar melhores decisões, permitindo ao mesmo tempo que a adoção responsável da IA avançasse com rapidez.

Com o estado-alvo estabelecido, Saad avaliou várias plataformas líderes de governança de IA contra um framework comum, definido a partir da perspectiva do operador. Os fornecedores não foram avaliados apenas pela força de suas demonstrações de produto ou pelo número de regulações citadas em seus materiais de marketing. A avaliação considerou a amplitude e a maturidade das capacidades, a usabilidade para diferentes partes interessadas, o suporte a todo o ciclo de vida da IA, a cobertura regulatória e de políticas, as capacidades de risco técnico e de testes, a integração com a arquitetura corporativa e os fluxos de entrega, o suporte tanto ao aprendizado de máquina tradicional quanto à IA generativa, a configurabilidade, a segurança, a privacidade, as considerações de implantação, a escalabilidade, a auditabilidade e a adequação a uma parceria estratégica mais ampla.

Usar o mesmo blueprint para cada fornecedor permitiu à McKinsey distinguir entre semelhanças superficiais de funcionalidades e diferenças significativas de capacidade operacional. Também impediu que o processo se tornasse uma avaliação conduzida pelos fornecedores, na qual a definição do problema mudasse conforme o produto que estivesse sendo demonstrado.

Saad ajudou então a enquadrar a decisão estratégica central. A análise não foi reduzida a uma comparação binária entre construir tudo internamente e comprar um produto externo pronto. Ela considerou um espectro de modelos possíveis: construir uma plataforma proprietária; combinar capacidades desenvolvidas internamente com tecnologia especializada de terceiros; fazer parceria com um fornecedor estabelecido de governança de IA; configurar uma plataforma externa em torno da propriedade intelectual, das metodologias e dos fluxos de trabalho com clientes da McKinsey; e usar diferentes fornecedores para diferentes elementos do ciclo de vida da governança.

Para cada caminho, Saad ajudou a esclarecer as implicações em tempo de chegada ao mercado, investimento em produto, capacidades técnicas, manutenção regulatória, requisitos de integração, diferenciação, controle sobre a propriedade intelectual, propriedade contínua do produto, capacidade de atender clientes globais, dependência de um fornecedor terceiro e escalabilidade de longo prazo.

A decisão passou a ser: quais capacidades a McKinsey deveria possuir porque criam diferenciação estratégica, e quais capacidades poderiam ser aceleradas ou fortalecidas por meio de um parceiro especializado?

Saad traduziu o trabalho em três entregáveis principais: um blueprint de plataforma definindo as capacidades, os fluxos de trabalho, os usuários e os requisitos corporativos associados a uma plataforma eficaz de governança de IA; uma avaliação escrita comparando as principais plataformas do mercado e seus pontos fortes relativos, lacunas e adequação como possíveis parceiros estratégicos; e uma apresentação executiva explicando o panorama do mercado, os requisitos do operador, os trade-offs entre construir e fazer parceria e as escolhas estratégicas disponíveis para a McKinsey.

Os entregáveis foram concebidos para dar aos executivos uma base clara para a discussão, em vez de apresentar a avaliação tecnológica como uma recomendação predeterminada. O papel de Saad não era tomar a decisão final de construir ou fazer parceria em nome da McKinsey. Seu papel era melhorar a qualidade dessa decisão, definindo o resultado desejado, fundamentando a avaliação em experiência operacional real e tornando visíveis os trade-offs.

O projeto deu à McKinsey uma base, informada pela experiência de um operador, para abordar uma categoria tecnológica emergente e estrategicamente importante.

Ele entregou uma definição compartilhada do que uma plataforma corporativa de governança de IA deve realizar; um blueprint de plataforma conectando princípios de governança a fluxos de trabalho práticos e capacidades técnicas; um framework comum para avaliar os fornecedores líderes; uma avaliação escrita dos pontos fortes relativos e das lacunas dos possíveis parceiros; uma classificação estruturada das soluções relevantes do mercado; maior clareza sobre os trade-offs entre desenvolvimento interno e parceria externa; uma distinção mais clara entre as capacidades que a McKinsey poderia querer possuir e aquelas que poderia obter de um fornecedor especializado; um pacote de decisão de nível executivo que traduziu um panorama tecnológico complexo em escolhas estratégicas; e uma base mais sólida para determinar como a tecnologia poderia complementar as capacidades de consultoria em governança de IA da McKinsey.

O valor do trabalho não estava vinculado a uma única funcionalidade de software ou à seleção de um fornecedor. Ele ajudou a McKinsey a evitar começar por um produto, uma parceria ou um programa de construção interna antes de estabelecer o que os clientes e os operadores corporativos realmente exigiriam.

Essa distinção foi importante porque a governança de IA estava rapidamente se tornando uma capacidade operacional, e não um exercício ocasional de conformidade. A própria pesquisa da McKinsey constatou mais tarde que as organizações que obtinham maior valor da IA generativa tinham mais probabilidade de incorporar revisões de risco no início do desenvolvimento e de envolver as funções jurídica e de governança no ciclo de vida da IA.

Durante um workshop de liderança em Madri, a Expedia identificou a melhoria do Net Promoter Score como uma prioridade de negócio importante.

A discussão revelou um paradoxo central. Os dados internos do workshop indicavam que mais de 80% dos viajantes tinham uma boa experiência e, no entanto, a Expedia tinha relativamente pouca presença na vida desses clientes satisfeitos depois que suas reservas eram concluídas. As interações mais significativas da empresa após a reserva costumavam se concentrar em momentos negativos, como quando um voo era interrompido, uma reserva mudava ou um viajante precisava de assistência.

Saad reformulou a questão como algo mais do que um problema de atendimento ao cliente ou de NPS. Era um problema de modelo de relacionamento.

A oportunidade era levar a Expedia para além de uma relação essencialmente transacional, em que o cliente reserva e vai embora, e criar uma razão para que o viajante permanecesse conectado à Expedia ao longo de toda a viagem. Isso significava ser útil durante a inspiração, o planejamento, a preparação, a viagem em si e os momentos inesperados, em vez de esperar que o cliente voltasse com um problema.

A pesquisa posterior da Expedia sobre viajantes reforçou a escala dessa oportunidade. Em média, os viajantes consultavam 141 páginas de conteúdo de viagem e dedicavam 303 minutos a interagir com conteúdo de viagem durante os 45 dias anteriores à reserva. Aproximadamente 80% visitavam uma agência de viagens on-line em algum ponto dessa jornada. Fonte: Expedia Group Path to Purchase Research.

Saad facilitou a discussão da liderança em torno de uma nova pergunta estratégica: como a Expedia poderia se tornar um companheiro valioso ao longo de toda a jornada do viajante, e não apenas o lugar onde a viagem era reservada ou onde os problemas eram resolvidos?

A partir dessa pergunta, Saad originou a proposta Expedia Travel Companion: uma experiência habilitada por IA, concebida para se manter continuamente útil, entender o contexto do viajante e apoiar tanto os momentos positivos quanto os difíceis.

O conceito era deliberadamente mais amplo do que um chatbot convencional de atendimento ao cliente. Seu propósito era ajudar a reposicionar a Expedia como um participante permanente e confiável na experiência de viagem.

Saad traduziu o conceito em um PRFAQ, usando o mecanismo Working Backwards da Amazon para definir a experiência futura do cliente antes de passar à implementação detalhada. A narrativa articulava a necessidade não atendida do viajante e a promessa ao cliente, a experiência que a Expedia poderia criar ao longo do ciclo de vida da viagem, como a IA poderia tornar o relacionamento mais contextual, proativo e personalizado, por que a proposta importava para o NPS, a fidelidade e o engajamento sustentado do cliente, e as questões que a Expedia precisaria resolver antes da implementação.

O PRFAQ foi revisado e endossado pela liderança da Expedia, estabelecendo alinhamento em torno da proposta e criando um mandato para desenvolvê-la ainda mais.

Saad desenvolveu então uma narrativa de seis páginas no estilo da Amazon, que levou a proposta de uma ideia executiva a uma estratégia de produto pronta para decisão. O documento de seis páginas reuniu o problema do cliente, a lógica estratégica, as experiências prioritárias, a proposta de valor e as considerações necessárias para passar do conceito à implementação. Criou uma narrativa compartilhada que os líderes de produto, tecnologia e negócio podiam usar para avaliar a oportunidade e tomar decisões.

Trabalhando com uma equipe multifuncional, Saad ajudou a desenvolver um protótipo que demonstrava como o Travel Companion poderia operar ao longo da jornada do viajante. O protótipo permitiu à liderança ver como a Expedia poderia apoiar proativamente um viajante em vez de esperar por uma busca, uma transação ou uma solicitação de serviço. Também deslocou a conversa do potencial abstrato da IA para uma experiência de cliente tangível que podia ser testada, questionada e desenvolvida.

O projeto transformou uma preocupação genérica com o NPS em uma direção de produto concreta habilitada por IA.

Ele produziu um novo enquadramento estratégico do desafio de engajamento de clientes da Expedia, um PRFAQ endossado pela liderança definindo a experiência futura, uma narrativa de seis páginas conectando o valor para o cliente à estratégia de negócio, um protótipo ilustrando como a proposta poderia funcionar ao longo da jornada, e o alinhamento executivo em torno de levar a Expedia de uma plataforma orientada à transação para um relacionamento de viagem contínuo.

O conceito de Travel Companion foi posteriormente desenvolvido pela Expedia e apresentado publicamente como Romie em 14 de maio de 2024.

A Expedia descreveu o Romie como um assistente de IA que abrange planejamento, busca, reserva e assistência durante a viagem. Suas capacidades anunciadas publicamente incluíam participar de conversas de viagens em grupo, converter essas conversas em buscas personalizadas, montar itinerários, monitorar interrupções, propor alternativas e atualizar as informações da viagem em tempo real.

O produto alfa incorporava o princípio central da proposta original do Travel Companion: a Expedia poderia continuar sendo valiosa ao longo de toda a experiência, e não apenas quando o cliente fazia uma reserva ou quando algo dava errado. Fonte: anúncio do Romie pelo Expedia Group.

O Expedia Group havia se tornado um dos maiores negócios de tecnologia de viagens do mundo por meio da expansão internacional e da aquisição de várias marcas de viagens. Esse crescimento criou uma oportunidade significativa, mas também uma complexidade tecnológica considerável. Cada negócio adquirido trazia suas próprias plataformas, arquitetura, recursos de nuvem, práticas operacionais e padrões de governança. A AWS descreveu publicamente o ambiente de nuvem da Expedia como abrangendo mais de 21 marcas adquiridas, enquanto o ex-Chief Technology Officer da Expedia descreveu pilhas tecnológicas oriundas de aquisições que podiam sufocar a inovação e afetar a experiência de viajantes e parceiros. Ao mesmo tempo, a Expedia precisava otimizar um patrimônio tecnológico que representava aproximadamente US$600 milhões em gastos, manter o desempenho de aplicações e infraestrutura à medida que os volumes de transações cresciam, escalar os serviços de tecnologia de forma consistente para os mercados internacionais, integrar as empresas recém-adquiridas sem perpetuar plataformas fragmentadas, fortalecer a disciplina de segurança e arquitetura, e dar aos executivos melhor visibilidade sobre custo, desempenho, risco e responsabilidade da tecnologia. A questão era, portanto, maior do que reduzir a conta da nuvem. A Expedia precisava de uma capacidade corporativa repetível para gerenciar a tecnologia em escala, uma que pudesse introduzir padrões comuns e disciplina financeira sem desacelerar as equipes de engenharia nem limitar a inovação.

Saad posicionou o Cloud Centre of Excellence como algo mais do que uma função centralizada de governança ou de controle de custos. O business case conectou o modelo operacional proposto a quatro prioridades estratégicas: otimização de custos, desempenho, escalabilidade internacional e integração de aquisições. Esse enquadramento ajudou a deslocar a discussão de uma redução de custos pontual para a criação de uma capacidade de escalonamento corporativo de longo prazo. Saad desenvolveu o business case do Cloud Centre of Excellence, reunindo a lógica financeira, operacional e estratégica. O caso abordou a escala dos gastos com tecnologia, o custo das práticas fragmentadas, o valor de padrões comuns de arquitetura, governança e segurança, a necessidade de propriedade e direitos de decisão mais claros, os benefícios de padronizar a integração de aquisições, as capacidades organizacionais necessárias para sustentar o modelo, e os investimentos em fases e o patrocínio necessários para avançar. Em seguida, apresentou e socializou o caso com os executivos pertinentes da Expedia, traduzindo a proposta técnica em resultados de negócio como crescimento rentável, expansão internacional mais rápida, melhor desempenho, integração de aquisições mais previsível, menor risco e maior transparência sobre o investimento em tecnologia. Saad desenhou um modelo abrangente cobrindo governança e direitos de decisão, FinOps e gestão de custos, padrões de arquitetura, gestão de desempenho, suporte a migrações, segurança e risco, integração de aquisições, capacitação e adoção, painéis executivos e KPIs. Depois de assegurar o apoio executivo, converteu o business case em um plano de implementação e supervisionou a execução, ajudando a manter o alinhamento e garantindo que o Centre of Excellence permanecesse conectado aos objetivos de crescimento, financeiros e tecnológicos da Expedia.

O projeto levou a Expedia de uma necessidade estratégica de maior disciplina na nuvem a um modelo operacional corporativo executável. Ele estabeleceu um Cloud Centre of Excellence abrangente, cobrindo governança, finanças, arquitetura, desempenho, segurança e adoção; um framework comum para gerenciar aproximadamente US$600 milhões em gastos com tecnologia; maior visibilidade executiva sobre custo, desempenho e risco da tecnologia; uma base repetível para integrar empresas adquiridas e ambientes tecnológicos; padrões compartilhados capazes de sustentar a expansão internacional sem recriar capacidades tecnológicas mercado a mercado; um mecanismo para equilibrar a consistência corporativa com a velocidade e a autonomia exigidas pelas equipes de produto e engenharia; e um roadmap de implementação que levou a iniciativa para além da estratégia, rumo à execução. A AWS descreve de forma independente a jornada mais ampla da Expedia na nuvem como a criação de consistência entre os recursos de nuvem, a padronização da governança em mais de 21 marcas, a simplificação das pilhas tecnológicas, o estabelecimento de um Cloud Centre of Excellence e a criação de serviços compartilhados para desenvolvedores em todo o grupo. Um exemplo público desses princípios operacionais em escala é a plataforma compartilhada de bancos de dados da Expedia, Cerebro, que passou de dar suporte a três contas AWS para mais de 400, reduziu o provisionamento de bancos de dados de dias para minutos e permitiu à Expedia aplicar práticas comuns de segurança, custo e governança mantendo uma equipe de suporte enxuta. Esses resultados divulgados publicamente demonstram o tipo de reutilização, padronização e alavancagem operacional que o Centre of Excellence foi concebido para institucionalizar.