Una sola decisión marca todo el engagement

Módulo 3 · Arquitectura de despliegue · Lección 1 de 5

Al terminar esta lección podrás recomendar una ruta de despliegue para cualquier perfil de cliente y defenderla con argumentos de facturación, autenticación, cumplimiento y capacidades.

Por qué esta decisión es difícil de revertir

La ruta marca los rieles antes de que alguien escriba un prompt

El lugar donde corre el tráfico de Claude Code del cliente determina quién le factura, cómo se autentican los usuarios, dónde quedan los datos de uso y qué funciones existen en absoluto.

• Compras firma según la vía de facturación
• Seguridad revisa el modelo de autenticación
• Finanzas construye el chargeback sobre la superficie de seguimiento de costos

Revertir la ruta después del despliegue implica repetir los tres frentes de trabajo. Por eso, en una activación estándar de 30 días, esta recomendación se cierra en pre-kickoff, las dos semanas previas al Día 0, junto con el cuestionario de seguridad y la configuración a nivel de organización, y no en una solicitud de cambio a mitad del proyecto. Trátala como una selección de plataforma en cualquier proyecto de modernización: una puerta de un solo sentido, a menos que alguien pague para volver atrás.

Regla de trabajo: los compromisos de nube existentes del cliente y su postura de cumplimiento son los que eligen la ruta. Tu trabajo es sacarlos a la luz antes de que el cliente elija por defecto.

El mismo Claude Code, cuatro rieles distintos

La CLI es idéntica en todas las rutas. Lo que cambia es todo lo que la rodea.

Ruta	Facturación	Autenticación	Auditoría y costos	Notas clave
Claude for Enterprise (directo)	Contrato por asiento, con SSO y captura de dominio	SSO de Claude.ai	Compliance API; costos en el dashboard de uso	Valor predeterminado recomendado por Anthropic. Permisos basados en roles y políticas de configuración gestionadas. Es la única ruta que incluye Claude en la web y la única elegible para retención cero de datos (ZDR, zero data retention)
Amazon Bedrock	Pago por uso (PAYG) a través de AWS, que consume compromisos existentes de AWS	IAM o claves API de Bedrock	CloudTrail; Cost Explorer; filtrado de contenido con Bedrock Guardrails	El tráfico del modelo permanece dentro de la cuenta de AWS del cliente. El cliente administra la habilitación de modelos por cuenta y región
Google Vertex AI	Facturación a través de GCP	Credenciales de GCP y Application Default Credentials; roles de IAM	Cloud Audit Logs	El acceso a los modelos se solicita por proyecto en Model Garden, con una aprobación que puede tardar de 24 a 48 horas. Soporta endpoints globales, multirregionales y regionales
Microsoft Foundry	Facturación a través de Azure	Clave API o Microsoft Entra ID, con políticas RBAC	Azure Monitor	El cliente aprovisiona los despliegues de modelos Claude en el portal de Foundry. Las solicitudes se enrutan a infraestructura operada por Anthropic, a diferencia de Bedrock y Vertex. Eso cambia la conversación sobre residencia de datos, y la lección 3.5 explica cómo

Cuatro preguntas, en este orden

Trabaja con estas preguntas durante el discovery. Las respuestas del cliente son las que reducen las opciones.

1. ¿Dónde están los compromisos de nube? Un acuerdo de gasto comprometido que el cliente necesita consumir, como un EDP (Enterprise Discount Program) de AWS, un CUD (Committed Use Discount) de GCP o un MACC (Microsoft Azure Consumption Commitment), es el impulso más fuerte hacia la ruta de nube correspondiente. El gasto que cuenta contra el compromiso es dinero que el cliente considera ya gastado. Pregunta a Compras, no solo a TI.
2. ¿Cómo prefiere comprar Compras? ¿Una suscripción por asiento con un contrato nuevo de Anthropic, o pago por uso (PAYG) a través de un proveedor de marketplace de nube que ya tienen aprobado? Muchas empresas aprueban gasto en marketplace en días y un proveedor nuevo en meses. Esto decide los plazos tanto como la arquitectura.
3. ¿Qué exige la postura de cumplimiento? Si el cliente exige retención cero de datos (ZDR), eso es posible solo en Enterprise directo. Si exige que el tráfico permanezca dentro de su propio tenant de nube y sus regiones, apunta a Bedrock o Vertex. Pide el cuestionario de seguridad temprano; la lección 3.5 te da las respuestas que pedirá.
4. ¿Quién administra usuarios y presupuestos? Enterprise directo ofrece administración de asientos, políticas de configuración gestionadas y un dashboard de uso de serie. En las rutas de nube, el cliente construye el equivalente con IAM más herramientas de costos de nube, o añade un gateway LLM para autenticación central y presupuestos. Ese patrón de gateway es la lección 3.4.

flowchart TD
    Q1["1. ¿Dónde están los compromisos de nube?"] -->|"EDP, CUD o MACC"| R1["Ruta de nube que coincide con el compromiso"]
    Q2["2. ¿Cómo prefiere comprar Compras?"] -->|"Asientos con contrato nuevo"| E["Claude for Enterprise (directo)"]
    Q2 -->|"PAYG por marketplace de nube existente"| R1
    Q3["3. ¿Qué exige la postura de cumplimiento?"] -->|"ZDR obligatoria"| E
    Q3 -->|"Tráfico dentro de su tenant y regiones"| B["Bedrock o Vertex AI"]
    Q4["4. ¿Quién administra usuarios y presupuestos?"] -->|"Administración integrada"| E
    Q4 -->|"IAM, herramientas de costos o gateway"| R1

La compensación que hay que nombrar en voz alta

Cada recomendación de ruta es un intercambio

Decirlo de forma explícita es lo que separa una recomendación de una preferencia.

Rutas de proveedor de nube: el perímetro del cliente, las herramientas del cliente

El tráfico y la facturación viven dentro de una infraestructura que el cliente ya gobierna: IAM que ya audita, herramientas de costos que Finanzas ya usa, compromisos que Compras ya firmó. El costo: no hay Claude en la web incluido, no hay ZDR y hay un puñado de brechas de capacidades que señalarás en la lección 3.2. Dos consecuencias afectan directamente a la activación:

• Fija tú las versiones del modelo: los alias sin fijar se resuelven a valores predeterminados que pueden ir por detrás de las nuevas versiones, o romper a los usuarios cuando un modelo todavía no está habilitado en su cuenta. Fija las versiones en las políticas gestionadas antes del despliegue.
• Construye el dashboard de uso: el reporte de costos se arma desde Cost Explorer, GCP Billing o Azure Cost Management, o se centraliza mediante el patrón de gateway de la lección 3.4.

Claude for Enterprise directo: la superficie completa, gestionada por Anthropic

Una sola suscripción cubre Claude Code y Claude en la web, con SSO, administración de asientos, configuración gestionada, Compliance API y elegibilidad para ZDR. El costo: una nueva relación con un proveedor, precios por asiento en lugar de consumo de un compromiso de gasto, y tráfico del modelo hacia la plataforma de Anthropic en lugar del tenant propio del cliente.

Del compromiso al Día -14

La recomendación escribe tu checklist de pre-kickoff

En una activación de 30 días, el pre-kickoff va del Día -14 al Día 0. Cada ruta pone bloqueos distintos en esa lista, y algunos tienen plazos que no se pueden comprimir.

Enterprise directo: la identidad es el cuello de botella

• Configura SSO y captura de dominio con el equipo de identidad (IdP) del cliente
• Mapea la lista de asientos y las asignaciones de roles
• Aplica las políticas de configuración gestionadas
• Envía la solicitud de habilitación de ZDR al equipo de cuentas de Anthropic si el cliente la requiere; se confirma por organización

Amazon Bedrock: plomería de cuenta, casi el mismo día

• Envía el formulario de caso de uso por cada cuenta de AWS (el acceso es inmediato)
• Crea la política de IAM para invocar modelos y perfiles de inferencia
• Habilita los modelos Claude en las regiones objetivo
• Fija los IDs de modelo en la configuración compartida antes de que alguien instale

Google Vertex AI: presenta la solicitud de acceso el Día 1

• Habilita la API de Vertex AI en el proyecto
• Solicita acceso a Claude en Model Garden (la aprobación puede tardar 24 a 48 horas)
• Confirma la cuota en la región objetivo
• Fija los IDs de modelo en la configuración compartida

La espera de aprobación es la razón por la que esto no puede empezar la semana del kickoff.

Microsoft Foundry: aprovisiona despliegues y fija versiones

• Aprovisiona el recurso de Foundry
• Crea los despliegues de modelos Claude con versiones fijas en lugar de actualización automática
• Acuerda con el equipo de identidad los roles de Entra ID o el manejo de claves API
• Fija los nombres de despliegue en la configuración

Comprueba tu comprensión

Escenario: Meridian Capital pide una recomendación para el viernes

Un cliente de servicios financieros, con 800 desarrolladores, está activando Claude Code. Tú diriges el frente de despliegue. Cuatro decisiones, ocho puntos. Las elecciones tienen consecuencias: la mejor opción suma 2 puntos, una opción parcial suma 1 y una opción incorrecta suma 0.

Decisión 1 de 4 · Llamada de descubrimiento

Tienes 30 minutos con el líder de plataforma del cliente y un gestor de compras. ¿Qué defines primero?

• A. Número de asientos y escalonamiento del despliegue. Cuántos de los 800 desarrolladores necesitan acceso en la primera ola y en qué plazo.
• B. Compromisos de nube y vía de compra. Si existe un EDP, CUD o MACC, y si Compras prefiere gasto por marketplace o un contrato nuevo con un proveedor.
• C. Estándares de IDE y estructura del repositorio. Qué editores usan los equipos y cómo está organizado su monorepo, para tener lista la guía de configuración.

Ver respuesta

• Parcial (+1) · A. Número de asientos y escalonamiento del despliegue. Útil, pero el escalonamiento encaja en cualquier ruta. Pasas veinte minutos en las olas de despliegue y tienes que agendar una segunda llamada para preguntarle a Compras la pregunta que de verdad decide la arquitectura.
• Mejor opción (+2) · B. Compromisos de nube y vía de compra. Los compromisos y la vía de compra son las palancas que eligen la ruta. Con la pregunta del EDP respondida, cada conversación posterior tiene un ancla. Los asientos y la configuración del IDE importan, pero encajan en cualquier ruta.
• Incorrecta (+0) · C. Estándares de IDE y estructura del repositorio. Los detalles de configuración son territorio del Curso 2 y encajan en cualquier ruta. El gestor de compras revisa el teléfono; la pregunta que decide la arquitectura nunca se hace.

Decisión 2 de 4 · La recomendación

Compras confirma un EDP de AWS a tres años con compromiso no consumido significativo, y el CFO quiere que el gasto de IA cuente contra él. La revisión de seguridad sigue pendiente. ¿Qué incluyes en el borrador de tu recomendación?

• A. Bedrock, condicionado a la revisión de seguridad. El consumo del EDP, junto con IAM y CloudTrail nativos de AWS, encaja con sus prioridades declaradas. Señala que la revisión pendiente todavía podría cambiar la decisión.
• B. Enterprise directo. Los controles de administración más sólidos, acceso web incluido y elegibilidad para ZDR. Recomiéndalo como la opción premium, pese al EDP.
• C. Microsoft Foundry. Su stack de identidad es Entra ID, así que la ruta de Azure ofrece la historia de autenticación más limpia.

Ver respuesta

• Mejor opción (+2) · A. Bedrock, condicionado a la revisión de seguridad. Recomendación correcta, con la salvedad adecuada. El EDP y la intención del CFO apuntan de lleno a Bedrock, y condicionar la recomendación a la revisión de seguridad significa que la respuesta de cumplimiento pendiente no puede tomar por sorpresa a tu recomendación.
• Parcial (+1) · B. Enterprise directo. Defendible en capacidades, pero va en contra de la prioridad financiera declarada por el cliente. A menos que la revisión de seguridad saque a la luz un requisito de ZDR, recomendar en contra de consumir el EDP es una venta difícil con este CFO.
• Incorrecta (+0) · C. Microsoft Foundry. Una preferencia de identidad no pesa más que un acuerdo de gasto comprometido. Entra ID es un detalle de autenticación; el EDP es un compromiso financiero que el CFO ya asumió.

Decisión 3 de 4 · El CISO hace una objeción

En la reunión de revisión, el CISO pregunta: “¿Podemos tener retención cero de datos en Bedrock?” La sala te mira.

• A. “Sí, la ZDR aplica en todas las rutas”. Tranquiliza a la sala: la retención cero de datos de Anthropic cubre Claude Code dondequiera que se ejecute.
• B. “No. En Bedrock, la retención la rige AWS”. La ZDR de Anthropic es una capacidad de Enterprise directo. En Bedrock, la inferencia corre en la cuenta de AWS del cliente, así que la retención y el cifrado siguen las políticas de AWS que ya controlan.
• C. “Déjame llevarme la pregunta y confirmarla”. Aparca la pregunta y haz seguimiento con el equipo de cuentas de Anthropic después de la reunión.

Ver respuesta

• Incorrecta (+0) · A. “Sí, la ZDR aplica en todas las rutas”. Error, y peligroso. La ZDR es solo de Enterprise directo. Si esto llega al expediente de seguridad y alguien lo verifica, la corrección vendrá del lado del cliente y tu recomendación pierde la credibilidad de su autor.
• Mejor opción (+2) · B. “No. En Bedrock, la retención la rige AWS”. Exacto, y lo dijiste en la sala. La ZDR de Anthropic aplica a Claude for Enterprise directo. En Bedrock, la inferencia corre dentro de la cuenta de AWS del cliente, bajo políticas de retención que ya gobierna. El CISO escucha a un consultor que conoce dónde están los límites.
• Parcial (+1) · C. “Déjame llevarme la pregunta y confirmarla”. Honesto, y mejor que adivinar. Pero esta pregunta aparece en todos los cuestionarios de servicios financieros, y no tenerla lista te cuesta credibilidad en la sala que más necesitas.

Decisión 4 de 4 · La última pregunta del CIO

El CIO está listo para aprobar Bedrock, pero pregunta: “¿Qué estamos renunciando frente a ir directo?”

• A. Mantenerlo comercial. Explica la diferencia de facturación: consumo de PAYG en lugar de asientos, y un dashboard de uso que tendrán que construir con herramientas de AWS.
• B. “Funcionalmente, nada”. La CLI es el mismo binario en todas las rutas, así que la experiencia del desarrollador es idéntica. Mantén el impulso hacia la aprobación.
• C. Nombrar las brechas de paridad. Sin Claude en la web incluido, sin ZDR de Anthropic, WebSearch no disponible, y el cliente se encarga de fijar las versiones del modelo. Ofrece un memo de brechas de una página antes de la aprobación.

Ver respuesta

• Parcial (+1) · A. Mantenerlo comercial. Cierto, pero incompleto. La facturación es la brecha que el CIO ya puede ver. Las que aparecen en la semana tres (WebSearch ausente, sin acceso web incluido, fijación de modelos) son las que había que nombrar hoy.
• Incorrecta (+0) · B. “Funcionalmente, nada”. La CLI es la misma; la superficie que la rodea no lo es. “Funcionalmente, nada” se convierte en “¿por qué no nos lo dijeron?” la primera vez que un equipo encuentra una brecha. El impulso que consigues hoy se paga después con intereses.
• Mejor opción (+2) · C. Nombrar las brechas de paridad. Esto es señalar brechas de paridad cuando funciona: concreto, antes de la aprobación y por escrito. El CIO firma conociendo el intercambio. Cuando un desarrollador pregunte dónde quedó WebSearch, la respuesta ya está en el expediente.

Ver cierre del escenario

• 7–8 puntos · Listo para entregar. Anclaste la decisión en los compromisos, recomendaste con una condición, mantuviste la posición sobre ZDR y dejaste las brechas por escrito. Así se ejecuta el frente de despliegue tal como lo plantea la metodología. Lleva esta misma secuencia al artefacto.
• 4–6 puntos · Sólido, pero con exposición. La recomendación se aprobó, pero al menos una respuesta dejó exposición: una pregunta ancla omitida, una respuesta de cumplimiento blanda o una brecha sin nombrar. Vuelve a las consecuencias de los pasos en los que perdiste puntos; cada una corresponde a una lección de este curso.
• 0–3 puntos · Vuelve a hacer el discovery. La ruta se eligió por defecto y no por evidencia. Revisa los cuatro factores de decisión de la sección «Cuatro preguntas, en este orden» y vuelve a hacer el escenario. En un engagement real, esta versión de la conversación aparece en el comité directivo como una solicitud de cambio.

Artefacto del curso · Deployment Decision Doc

Este curso termina con un Deployment Decision Doc para un cliente de ejemplo: la recomendación de ruta más la postura de autenticación, red, gateway y cumplimiento que la defiende. Esta lección aporta el perfil del cliente y la recomendación de ruta.

1. Abre un documento nuevo. Define un cliente de ejemplo: industria, número de desarrolladores, nube principal y un acuerdo de gasto comprometido (EDP, CUD o MACC).
2. Responde las cuatro preguntas de decisión para ese cliente en una oración cada una: compromisos de nube, vía de compra, postura de cumplimiento y responsable de la administración.
3. Escribe la recomendación: una ruta, dos oraciones de justificación y la única condición que cambiaría tu decisión.
4. Lista los bloqueos de pre-kickoff que genera tu ruta, cada uno con un responsable y un plazo, para que el documento encaje directamente en el checklist del Día -14 de un plan de activación.

Ideas clave

• La ruta sigue a los compromisos de nube, la vía de compra y la postura de cumplimiento del cliente. Estos tres factores la eligen antes de que se escriba el primer prompt.
• Enterprise directo es la única ruta con Claude en la web y elegible para ZDR. Las rutas de proveedor de nube mantienen facturación y tráfico dentro de la infraestructura que el cliente ya gobierna, con la excepción de Foundry, que enruta a infraestructura de Anthropic.
• La decisión se cierra en pre-kickoff: revertirla después implica repetir facturación, autenticación y cumplimiento.
• Una recomendación no está completa hasta nombrar lo que el cliente cede al tomarla.

Siguiente: Brechas de paridad y flags