Señala las brechas antes del contrato

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

Al terminar esta lección podrás nombrar las brechas de capacidades de cada ruta de despliegue y presentarlas al cliente sin perder la venta.

Por qué el momento determina el resultado

Toda brecha se descubre. Lo único que importa es quién la descubre y cuándo

En la lección 3.1 recomendaste una ruta. La misma CLI funciona en todas, pero la superficie que la rodea cambia, y esas diferencias aparecen durante la activación si no las anticipas.

En una activación de 30 días el patrón es predecible:

• Semana uno: un campeón pregunta dónde quedó una función
• Semana dos: el CoE pregunta por qué el dashboard de métricas está vacío
• Día 30: el informe de brechas más grandes contiene elementos que el cliente conoce desde la firma del contrato, o elementos que escucha por primera vez con tu nombre asociado

flowchart LR
    S1["Semana 1: un campeón pregunta dónde quedó una función"] --> S2["Semana 2: el CoE pregunta por qué el dashboard de métricas está vacío"] --> D30["Día 30: informe de brechas más grandes"]

Un memo de brechas de una página, entregado junto con la recomendación de ruta antes de la firma, es el seguro más barato de este curso. Es la misma disciplina que señalar las exclusiones de alcance en un SOW: nadie disputa una línea que aceptó.

Regla de trabajo: una brecha señalada al momento del contrato es consultoría. La misma brecha descubierta en la semana tres es un defecto con tu nombre.

Seis brechas que deben estar en tu memo

Estas son las diferencias entre las rutas de nube y Enterprise directo que los clientes realmente encuentran. Compáralas con la ruta que recomendaste en la lección 3.1.

1. WebSearch no está disponible

Bedrock · Capacidad

La herramienta WebSearch integrada no funciona en Bedrock. Los equipos que dependen de consultas de documentación en vivo necesitan una alternativa MCP aprobada, definida durante el pre-kickoff y no improvisada en la semana dos.

2. Claude en la web no viene incluido

Todas las rutas de nube · Superficie de producto

Solo Teams y Enterprise directo incluyen la superficie web. En Bedrock, Vertex o Foundry, los stakeholders de negocio no tienen una superficie de chat, a menos que el cliente compre una por separado. Esto aparece la primera vez que un ejecutivo pide una demo.

3. La retención cero de datos (ZDR) no aplica

Todas las rutas de nube · Cumplimiento

La retención cero de datos es una capacidad exclusiva de Enterprise directo. En las rutas de nube, la retención sigue las políticas del proveedor que el cliente ya gobierna. El encuadre preciso, como practicaste en la lección 3.1, es: control distinto, no control ausente.

4. Las versiones del modelo son responsabilidad del cliente

Todas las rutas de nube · Operaciones

Los alias como sonnet se resuelven a valores predeterminados que pueden quedar atrás de las nuevas versiones, o apuntar a modelos que la cuenta todavía no tiene habilitados. Las tareas en segundo plano también usan por defecto el modelo principal, en lugar de un modelo más económico de la clase Haiku. Fija las versiones en la configuración compartida antes del despliegue.

5. La telemetría viene desactivada por defecto

Todas las rutas de nube · Medición

Las métricas de Anthropic, el reporte de errores y el envío de /feedback vienen desactivados por defecto en las rutas de terceros; en su lugar, el feedback escribe un paquete local. Las métricas de adopción que revisa el CoE cada semana necesitan OTel o un gateway, tema que cubre la lección 3.4.

6. Vertex tiene su propia letra pequeña

Vertex · Plazos y valores por defecto

• Prevé de 24 a 48 horas para la aprobación de acceso en Model Garden.
• Habilita la búsqueda de herramientas MCP (MCP tool search) de forma explícita: viene desactivada por defecto, así que si no se configura, los catálogos grandes de herramientas se cargan completos desde el inicio.
• Verifica el caché de prompts por región: la disponibilidad varía tanto en Vertex como en Bedrock. Si los conteos de caché están en cero, revisa la región.

Un memo de brechas es una página, no un registro de riesgos

Estructura cada línea de la misma forma:

• Nombra la brecha: qué capacidad está ausente o reducida en esta ruta.
• Ubica el momento: en qué semana, con qué persona, en qué reunión el cliente la habría encontrado.
• Presenta primero la mitigación: el plan que ya está en marcha, dicho antes que la limitación.

“WebSearch no está disponible en Bedrock; el equipo de documentación de tu plataforma lo encontraría en la semana uno; definiremos una alternativa MCP aprobada durante el pre-kickoff.”

Esa frase se lee como preparación. Una tabla de comparación de funciones sin contexto se lee como una razón para frenar el trato. Presenta primero la mitigación, y el memo se convierte en evidencia de que ya lo has hecho antes.

Comprueba tu comprensión

Escenario: Northgate Logistics firmó Bedrock, y llegan las brechas

Escribiste el memo de brechas al momento del contrato. Ahora la activación está en marcha y las brechas aparecen una a una. Tres decisiones, seis 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 3 · Semana del contrato

El CTO lee tu memo de brechas y frunce el ceño: “Si le muestro esta lista a Seguridad, van a frenar todo el trato. ¿Podemos recortarla?”

• A. Mantener cada línea y replantear cada una como mitigación. Cada brecha se mantiene, emparejada con el momento en que aparecería y con el plan que ya está en marcha. Ofrece recorrer el memo con Seguridad tú mismo.
• B. Recortarla a las dos brechas que más le importarían a Seguridad. Mantén ZDR y telemetría, y elimina los elementos de superficie de producto. El CTO conoce mejor a su equipo de seguridad.
• C. Pasar el memo al deck del kickoff. Sácalo por completo de la conversación del contrato y preséntalo en el kickoff, una vez que el trato esté asegurado.

Ver respuesta

• Mejor opción (+2) · A. Mantener cada línea y replantear cada una como mitigación. El memo queda intacto y Seguridad escucha cada brecha con un plan adjunto. Dentro de seis meses, nadie en Northgate podrá decir que no se les avisó, y el CTO aprende que no negocias la transparencia.
• Incorrecta (+0) · B. Recortarla a las dos brechas que más le importarían a Seguridad. Las líneas recortadas son exactamente las que aparecen en la semana uno: un campeón preguntando dónde quedó WebSearch, un ejecutivo pidiendo la demo web. Cada una se convierte en una sorpresa con tu nombre en un memo que no la mencionaba.
• Parcial (+1) · C. Pasar el memo al deck del kickoff. Las brechas se señalan antes de que alguien las encuentre, pero después de la firma. Si Seguridad habría cambiado la decisión de ruta por ZDR o telemetría, les quitaste esa opción.

Decisión 2 de 3 · Semana dos

Un campeón publica en el canal de activación: “WebSearch simplemente no funciona para nadie. ¿Está rota nuestra instalación?” Veinte desarrolladores están mirando el hilo.

• A. Abrir un ticket de soporte y publicar que está en investigación. Trátalo como un posible defecto hasta confirmarlo. Mejor prevenir que equivocarse frente a veinte personas.
• B. Responder con la línea del memo y la alternativa planeada. WebSearch no está disponible en Bedrock, se señaló en el contrato y la alternativa MCP aprobada está en el catálogo. Enlaza ambos.
• C. Sugerir a los desarrolladores usar claude.ai en el navegador para sus búsquedas. Desbloqueo rápido: las cuentas personales de Claude pueden buscar en la web mientras resuelves una respuesta a largo plazo.

Ver respuesta

• Parcial (+1) · A. Abrir un ticket de soporte y publicar que está en investigación. Honesto pero lento, y da la impresión de que no conoces tu propio despliegue. El ticket vuelve con “funciona según lo diseñado” en dos días, que son dos días de veinte desarrolladores creyendo que la instalación está rota.
• Mejor opción (+2) · B. Responder con la línea del memo y la alternativa planeada. Veinte desarrolladores ven tu respuesta en una sola publicación: brecha conocida, señalada en el contrato, alternativa en el catálogo. El hilo se cierra, y el memo se pagó solo, en público.
• Incorrecta (+0) · C. Sugerir a los desarrolladores usar claude.ai en el navegador para sus búsquedas. Acabas de aconsejar a los desarrolladores del cliente que enruten su trabajo por cuentas personales no gestionadas, fuera del perímetro de seguridad que firmó el CISO. Si alguien captura eso, termina en la agenda del comité directivo.

Decisión 3 de 3 · Revisión de métricas del CoE

El líder del CoE abre la revisión semanal: “¿Dónde están nuestros datos de uso? El plan dice que rastreamos DAU y costo por desarrollador, y no veo nada.”

• A. Explicar el valor predeterminado y proponer la solución. La telemetría hacia Anthropic está desactivada por defecto en Bedrock. Los datos viven en el stack propio del cliente: OTel para los eventos de uso, Cost Explorer para el gasto, o centralizados mediante el gateway que diseñarás en la próxima lección.
• B. Decir que el dashboard de Anthropic debería tenerlo. La consola tiene vistas de uso; prométele encontrar el enlace correcto después de la reunión.
• C. Hacer una encuesta a los desarrolladores para cubrir esta semana. El uso autorreportado y las horas ahorradas mantienen viva la revisión mientras la cuestión de la instrumentación se resuelve más adelante.

Ver respuesta

• Mejor opción (+2) · A. Explicar el valor predeterminado y proponer la solución. Nombraste el valor predeterminado, dónde viven realmente los datos y la decisión que necesita tomar el CoE. El flujo de trabajo de métricas queda desbloqueado, y dejaste preparada la conversación sobre el gateway para la próxima sesión.
• Incorrecta (+0) · B. Decir que el dashboard de Anthropic debería tenerlo. Las vistas de uso de la consola pertenecen a la ruta de Enterprise directo. El cliente está en Bedrock; no existe un dashboard de Anthropic con sus datos. El líder del CoE lo descubre después de la reunión, por boca de otra persona.
• Parcial (+1) · C. Hacer una encuesta a los desarrolladores para cubrir esta semana. La encuesta mantiene viva la reunión, y las horas autorreportadas forman parte del scorecard del Día 30. Pero tapa la brecha de instrumentación, que sigue sin resolverse la semana siguiente.

Ver cierre del escenario

• 6 puntos · Listo para entregar. Memo intacto, brechas respondidas desde el expediente, métricas desbloqueadas. Así se ve la gestión de brechas de paridad cuando funciona: el cliente nunca vive una sorpresa, solo confirmaciones de cosas que ya le habías dicho.
• 3–5 puntos · Sólido, pero con exposición. El proyecto sobrevive, pero al menos una brecha llegó al cliente antes que tu explicación. Revisa la consecuencia de cada punto perdido; cada una corresponde a una línea que tu memo debía incluir.
• 0–2 puntos · Vuelve al memo. Las brechas llegaron a los campeones, a Seguridad o al CoE antes que tú, y la confianza ahora se está reparando en lugar de acumularse. Vuelve a la sección «Seis brechas que deben estar en tu memo» y repite el escenario. En un engagement real, así es como un partner pasa a ser descrito como alguien que aprende a nuestra costa.

Ideas clave

• Toda brecha se descubre; lo que cambia es cuándo y quién la encuentra. Señalada en el contrato es consultoría; descubierta en la semana tres es un defecto con tu nombre.
• Cada ruta tiene brechas. El memo de brechas las convierte en líneas de contrato con mitigaciones ya incluidas.
• Las seis brechas del memo incluyen WebSearch en Bedrock, Claude en la web, ZDR, la gestión de versiones del modelo, la telemetría desactivada y la letra pequeña de Vertex.
• El memo es una página: nombra la brecha, ubica el momento en que aparecería y presenta la mitigación antes que la limitación.

Siguiente: Configuración de proxy corporativo