Siete caminos hacia Claude Code, una opción adecuada para tu cliente

Módulo 1 · Fundamentos del producto · Lección 3 de 3

Al terminar esta lección podrás asociar los compromisos cloud, los requisitos de gobernanza y las necesidades de funcionalidades de un cliente con la opción de despliegue adecuada, y explicar por qué no recomiendas las demás.

Las siete rutas son: Claude.ai Teams, Claude.ai Enterprise, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Azure AI Foundry, Anthropic API y Anthropic Console.

Tres categorías: funcionalidad completa, nativa de la nube o solo API. La categoría que encaje determina todo lo demás.

Categoría	Qué incluye	Elige cuando
Gestionada por Claude (Teams + Enterprise)	Funcionalidad completa, incluye Claude en web y móvil, facturación centralizada y sin configuración de infraestructura. Ideal para la mayoría de las activaciones lideradas por GSI.	El cliente quiere el camino más rápido al valor y no tiene un requisito estricto de pasar por su propia nube. Es tu recomendación por defecto, salvo que algo la descarte.
Nativa de la nube (Bedrock, Vertex, Foundry)	Enruta a través del proveedor cloud existente del cliente. Integración con IAM, controles regionales de datos y facturación a través de la nube. No tiene superficie web de Claude.ai.	El cliente tiene compromisos cloud existentes o reglas de residencia de datos que obligan a procesar en una región que controla. Señala la brecha de gobernanza frente a Enterprise.
API / Console	Desarrolladores individuales, autenticación con clave de API y pago por uso. Sin controles empresariales. No es la ruta adecuada para un despliegue gestionado.	Un único desarrollador o un prototipo necesita acceso rápido. Para un despliegue gobernado de 200 puestos es la categoría equivocada; mencionarla solo sirve para descartarla.

Marco de decisión: el orden de la llamada de descubrimiento. Postura cloud, gobernanza y alcance.

El selector refleja la decisión real: primero la postura cloud, después la gobernanza y por último la superficie de funcionalidades. Las tres preguntas y sus resultados están en la sección de comprensión al final de la lección.

flowchart TD
  P1{"1. ¿El procesamiento debe quedarse en una región cloud que el cliente controla?"}
  P1 -- "Sí: AWS" --> BED["Amazon Bedrock (nativa de la nube)"]
  P1 -- "Sí: GCP" --> VRT["Google Cloud Vertex AI (nativa de la nube)"]
  P1 -- "Sí: Azure" --> FND["Microsoft Azure AI Foundry (nativa de la nube)"]
  P1 -- "Sin requisito estricto" --> P3{"2. ¿Alcance del despliegue?"}
  P3 -- "Un solo desarrollador o prototipo" --> API["API / Console (acceso rápido)"]
  P3 -- "Un equipo o toda la organización" --> P2{"3. ¿Seguridad pide SSO, audit logs, managed settings o Compliance API?"}
  P2 -- "Sí" --> ENT["Claude Enterprise (gestionada por Claude)"]
  P2 -- "No" --> TMS["Teams (la ruta más rápida al valor)"]

Es una guía, no un contrato. Los despliegues reales consideran la ruta de compra, las licencias existentes y la aprobación de seguridad junto con estas tres preguntas.

Empresa frente a Teams: Enterprise no es más puestos. Es el nivel de controles.

	Teams	Enterprise
Para qué	Para empezar.	Para despliegues gobernados.
Características	Facturación por uso más una tarifa de suscripción por puesto. Verifica las tarifas vigentes en anthropic.com/pricing. Gestión de equipos, herramientas de administración y SSO básico.	SSO con captura de dominio, aprovisionamiento SCIM, RBAC, Compliance API y políticas de configuración gestionadas (managed policy settings).
Cuándo recomendarlo	Un nivel de inicio, no es el adecuado para la mayoría de los despliegues empresariales.	Si el equipo de seguridad del cliente pregunta por audit logs o managed settings, este es el nivel.

En la mayoría de las activaciones lideradas por GSI, recomienda Enterprise. Si un cliente pregunta por SSO, managed settings o audit logs, Teams no cumple el requisito.

Ruta nativa de la nube: úsala cuando el cliente tiene compromisos existentes o requisitos de residencia de datos.

Bedrock para clientes con AWS como prioridad, Vertex para GCP y Foundry para Azure. La contrapartida: facturación a través de su nube, integración con IAM y controles regionales de datos, pero sin superficie web de Claude.ai, sin managed settings y sin Compliance API.

Un LLM Gateway (una capa de middleware que enruta las llamadas al modelo a través de los controles de red corporativos, añadiendo registro, filtrado y aplicación de políticas antes de que las solicitudes lleguen al proveedor del modelo) puede situarse entre Claude Code y cualquier proveedor cloud para añadir autenticación centralizada, seguimiento de uso y limitación de tasa.

Para recordar: el enrutamiento nativo de la nube satisface un compromiso existente, no un requisito de seguridad. La brecha de gobernanza frente a Enterprise es real y conviene señalarla al cliente.

Tipos de puesto: el acceso a Claude Code por uso requiere el tipo de puesto adecuado. Señálalo pronto en la contratación.

Tipo de puesto	Qué incluye	Atención
Standard (solo chat)	Sin acceso a Claude Code. Es el valor por defecto más común. Confirma que no es lo que el cliente está comprando antes del kickoff.	Un cliente que asume que “tenemos Claude” significa que los desarrolladores pueden ejecutar Claude Code está en un error. Un puesto Standard no lo incluye; es la discrepancia más común.
Chat + Code	Incluye Claude Code. Es el nivel mínimo para acceder a Claude Code. Confirma que está en el alcance de la contratación antes de empezar el proyecto.	La brecha entre lo que se mostró en la demo y lo que se compró. Si el piloto usó Code, el contrato debe incluir este nivel o uno superior.
Claude Enterprise	Nivel empresarial completo. Incluye Claude Code, todos los controles empresariales y acceso a Compliance API. Es el puesto adecuado para despliegues gobernados.	Si el equipo de seguridad pregunta por audit logs o managed settings, ese requisito apunta a este nivel y no a los inferiores.

Alerta de contratación. Confirma el tipo de puesto antes del kickoff. Las discrepancias de tipo de puesto son una causa habitual de retrasos en la activación. Añádelo a tu lista de verificación previa al kickoff.

Atención: la contratación cerrada con el nivel equivocado semanas antes del kickoff. Detectarlo pronto es mucho más barato que una modificación del contrato a mitad del proyecto.

Estos nombres de puesto reflejan el modelo de precios por uso. Los clientes con planes de puestos heredados usan los tipos Standard y Premium. Confirma en qué modelo está el cliente antes de la contratación, porque afecta tanto a los nombres como a lo que incluye cada puesto.

Práctica: pruébalo

Ya cubriste qué es Claude Code, cómo asociar cargas de trabajo al nivel de modelo adecuado y qué ruta de despliegue encaja con cada perfil de cliente. Una buena forma de ponerlo en práctica: toma tres escenarios de cliente con distintas posturas cloud, requisitos de automatización y tamaños de equipo, e intenta asociar cada uno con una ruta de despliegue y un modelo. Si puedes explicar el factor decisivo de cada uno en una frase, estás listo para tomar esa decisión en la sala.

Comprueba tu comprensión

Escenario: selección de plataforma para una firma de servicios financieros.

Tu cliente es una firma de servicios financieros. Está muy invertido en AWS, su política de seguridad exige que todo el procesamiento de datos se mantenga dentro de regiones de AWS aprobadas, y su equipo de TI gestiona los equipos de los desarrolladores con Intune. Quiere un despliegue de Claude Code para 200 desarrolladores.

Elige una opción:

• A. Claude para Enterprise directamente: conjunto de funcionalidades más completo, SSO, Compliance API. Es la recomendación estándar de GSI.
• B. Amazon Bedrock con LLM Gateway: cumple los requisitos nativos de AWS y de procesamiento regional de datos.
• C. Google Vertex AI: integración empresarial sólida y opciones de datos regionales.
• D. Anthropic Console: configuración sencilla, autenticación con clave de API y sin necesidad de infraestructura.

Ver respuesta

Respuesta: B, según las explicaciones de la lección.

Por qué no Enterprise (opción A): Claude.ai Enterprise es un producto SaaS. La infraestructura de Anthropic determina dónde ocurre el procesamiento, y el cliente no controla qué región gestiona sus datos. Los clientes que necesitan límites regionales explícitos de datos (GDPR, nube soberana, contratos de residencia de datos) requieren un despliegue en un proveedor cloud (Bedrock, Vertex o Azure), donde ellos eligen y controlan la región. Esta es la razón más habitual por la que los clientes empresariales eligen despliegues en proveedores cloud en lugar de un SaaS gestionado.

Por qué Bedrock (opción B): Bedrock cumple el requisito de procesamiento regional de datos y enruta a través de la infraestructura y la facturación AWS existentes del cliente. Añade un LLM Gateway para autenticación centralizada y seguimiento de uso. Sé explícito sobre la contrapartida: pierden la superficie web de Claude.ai y las funciones de administración de Enterprise. Evalúa con el equipo de seguridad del cliente si esa brecha debe abordarse por separado. Claude for Enterprise es el valor por defecto correcto cuando el enrutamiento nativo de la nube no es un requisito.

Sobre Intune: Intune es relevante para cómo se distribuye Claude Code a los endpoints de los desarrolladores, no para la decisión de arquitectura de despliegue. Esa decisión la determinan los requisitos de residencia de datos, los compromisos cloud existentes y la ruta de contratación.

Simulación: selector de despliegue. Responde las tres preguntas como lo harías en una llamada de descubrimiento y mira en qué camino termina.

1. ¿El cliente exige que el procesamiento se mantenga dentro de una región cloud que controla (residencia, soberanía, compromiso existente)? Opciones: Sí, AWS · Sí, GCP · Sí, Azure · Sin requisito estricto.
2. ¿El equipo de seguridad pide SSO, audit logs, managed settings o Compliance API? Opciones: Sí, la gobernanza importa · No, mantenerlo ligero.
3. ¿Cuál es el alcance del despliegue? Opciones: Un equipo o toda la organización · Un solo desarrollador o prototipo.

Ver respuesta

Resultado según tus respuestas, tal como aparece en la lección:

• Cualquier respuesta de residencia (AWS, GCP o Azure): un requisito de residencia o de compromiso existente obliga a procesar en una región que controla el cliente, así que enruta a través de su nube. Añade un LLM Gateway para autenticación centralizada y seguimiento de uso. Señala la contrapartida: sin superficie web de Claude.ai, sin managed settings y sin Compliance API.
• Sin requisito de nube, a escala de equipo u organización, con gobernanza (Sí, la gobernanza importa): Claude Enterprise. No hay requisito de enrutamiento por nube, pero el equipo de seguridad necesita SSO, audit logs, managed settings o Compliance API. Ese es el nivel de controles. Es la recomendación por defecto para la mayoría de las activaciones gobernadas de GSI.
• Sin requisito de nube, un solo desarrollador o prototipo: Anthropic API / Console. En el selector, el alcance individual lleva a esta ruta sin importar la respuesta de gobernanza. un único desarrollador o prototipo, sin necesidad de gobernanza ni de residencia, no justifica un despliegue gestionado. La autenticación con clave de API y el pago por uso es la ruta más ligera. Revisa esta decisión si crece hasta convertirse en un equipo.
• Sin requisito de nube ni de gobernanza, a escala de organización: Teams. No hay requisito de residencia ni exigencias estrictas de gobernanza. Teams es la ruta más rápida al valor. Pasa a Enterprise en cuanto aparezcan en la conversación SSO, audit logs o managed settings.

Ideas clave

Al terminar esta lección puedes asociar los compromisos cloud, los requisitos de gobernanza y las funcionalidades de un cliente con la opción de despliegue adecuada, y explicar por qué descartas las demás.

• Las siete rutas se agrupan en tres categorías: gestionada por Claude (Teams y Enterprise), nativa de la nube (Bedrock, Vertex, Foundry) y API / Console.
• Para un despliegue gobernado de equipo u organización, Enterprise es la recomendación por defecto; Teams es un nivel de inicio.
• Enrutar por la nube del cliente responde a compromisos existentes o a residencia de datos, no a un requisito de seguridad, y conlleva brechas de gobernanza que hay que señalar.
• Verifica el tipo de puesto en la contratación: un puesto Standard no incluye Claude Code.
• Las tres preguntas del selector (postura cloud, gobernanza y alcance) determinan la ruta: la nube decide primero, el alcance separa API/Console de un despliegue gestionado y la gobernanza elige entre Enterprise y Teams.

Siguiente: Instalación de la CLI y prerrequisitos