Gestión de asientos y consola de administración

Módulo 7 · Administración y medición · Lección 1 de 6

Al terminar esta lección podrás asignar asientos, configurar SSO, establecer límites de gasto y completar todas las comprobaciones previas de administración antes de que el primer desarrollador abra una terminal.

La postura de administración empieza antes de la presentación de kickoff.

Por qué es trabajo previo al kickoff

La consola de administración es infraestructura. Trátala como tal.

En una activación de 30 días, el trabajo previo al kickoff va desde el día -14 hasta el día 0. En esa ventana se configura el SSO, se asignan los asientos y se establecen los límites de gasto. Lo que no se hace en esas dos semanas aparece el día 1 en forma de escalaciones.

El patrón de fallo habitual no es una funcionalidad que falta, sino la persona equivocada en el rol equivocado. Un contacto de TI al que se le asignó el rol Admin por defecto no puede configurar el SSO ni aprovisionar asientos, por muy capaz que sea técnicamente. Un desarrollador con un asiento Standard en un plan legacy no puede autenticarse en Claude Code. Una organización recién aprovisionada con un límite de gasto de $0 rechazará todas las llamadas a la API. Son problemas de roles y de configuración, no de despliegue. Se resuelven en cinco minutos si se detectan durante el descubrimiento; si se detectan en el kickoff, generan escalaciones de medio día.

• Confirma los roles antes de entregar cualquier tarea de configuración a TI: Admin no puede hacer lo que sugiere su nombre
• Revisa los tipos de asiento antes de que los desarrolladores instalen: los asientos Standard bloquean por completo la autenticación en Claude Code
• Establece los límites de gasto antes de que alguien haga una llamada a la API: el valor por defecto en los planes basados en uso es $0

Regla de trabajo

Las asignaciones de roles y la configuración de asientos del cliente son la ruta crítica. Conócelas antes del kickoff, no durante él.

Tipos de asiento

El modelo de facturación determina quién recibe Claude Code y quién no.

Claude Enterprise funciona con dos modelos de facturación. El modelo en el que esté el cliente determina qué tipos de asiento existen, quién puede asignarlos y a qué accede realmente cada desarrollador. Cada fila de la tabla describe qué puede hacer un desarrollador con ese tipo de asiento.

Modelo de facturación	Estado	Tipo de asiento	Etiqueta	Qué obtienen los desarrolladores
Por asiento (seat-based)	Legacy	Standard	Sin Claude Code	Solo chat en Claude.ai. Los desarrolladores con asiento Standard no pueden autenticarse en Claude Code en absoluto. Si un desarrollador de un plan legacy tiene errores de autenticación y no logra averiguar por qué, revisa primero el tipo de asiento.
Por asiento (seat-based)	Legacy	Premium	Claude Code incluido	Incluye acceso a Claude Code. Solo el Primary Owner puede comprar y asignar asientos Premium. Los planes legacy pasan a facturación basada en uso en la próxima renovación del contrato. Anota el calendario en el descubrimiento si el cliente está en este modelo.
Por uso (usage-based)	Transicional	Chat / Chat + Code	En retirada	Los asientos solo de chat no incluyen Claude Code. Los asientos Chat + Code sí lo incluyen. No están disponibles después de la próxima renovación para las organizaciones que hoy están en este modelo. Anota la transición en el descubrimiento.
Por uso (usage-based)	Actual	Claude Enterprise	Todo incluido	Un solo tipo de asiento que cubre Claude.ai, Claude Code y Cowork. El uso se factura a tarifas de API sobre la tarifa por asiento. El límite de gasto por defecto a nivel de organización es $0. Configúralo antes de asignar asientos o todas las llamadas a la API fallarán.

Jerarquía de roles

El rol Admin no significa lo que sugiere su nombre.

Claude Enterprise tiene cuatro roles. La mayor parte de lo que necesitas configurar antes del kickoff requiere Owner o superior. El Primary Owner controla las acciones más críticas, y cada organización tiene exactamente uno.

flowchart TD
    PO["Primary Owner (uno por organización)"] --> OW["Owner"]
    OW --> AD["Admin"]
    AD --> US["User"]

Primary Owner

Uno por organización. Tiene el nivel de autoridad más alto en Claude Enterprise. Normalmente es el CTO, el director de TI o una cuenta de servicio dedicada.

Puede hacer:

• Aprovisionar y comprar asientos
• Solicitar exportaciones de datos
• Transferir la propiedad a otro usuario
• Todo lo que puede hacer un Owner

Suele ser la persona más difícil de agendar. Confírmala y bloquea su calendario antes de la semana previa al kickoff. Sin ella, el aprovisionamiento de asientos no puede avanzar.

Owner

Tu contraparte principal de TI en la mayoría de los engagements. Es el rol que gestiona la mayor parte de la configuración técnica de la organización.

Puede hacer:

• Configurar SSO y SCIM
• Acceder a los registros de auditoría
• Gestionar la configuración de retención de datos
• Ver analíticas de uso
• Invitar o eliminar Admins y Owners

Si el contacto de TI solo puede tener un rol, debe ser Owner, no Admin. Los Owner pueden configurar SSO; los Admin no.

Admin

Un rol de acceso limitado. El nombre sugiere más control del que realmente ofrece.

Puede hacer:

• Invitar y eliminar miembros
• Ver analíticas de uso (solo Enterprise, no Team)

No puede hacer:

• Configurar SSO ni SCIM
• Aprovisionar ni comprar asientos
• Acceder a los registros de auditoría

El hueco más habitual antes del kickoff. Las organizaciones cliente suelen asignar Admin por defecto a los contactos de logística de TI. Detéctalo en el descubrimiento, no la mañana del kickoff.

User

El rol que tiene cada desarrollador y usuario final una vez aprovisionado. No tiene capacidades administrativas.

Puede hacer:

• Crear y gestionar chats
• Usar proyectos
• Acceder a Claude Code (con el tipo de asiento adecuado)

En este nivel de rol no se ven ni se accede a los ajustes de administración. Los desarrolladores reciben este rol por defecto al añadirlos a la organización.

Lista de verificación previa al kickoff

Cuatro pasos, en este orden, antes de que cualquier desarrollador inicie sesión.

Estos son los ajustes que generan escalaciones si faltan el día 1. El equipo de TI ejecuta la mayor parte; tu trabajo es confirmar que las personas correctas tienen los roles correctos y saben qué se espera antes de que empiece la semana del kickoff.

flowchart LR
    S1["1. Configurar identidad (Owner o Primary Owner)"] --> S2["2. Asignar asientos y límites de gasto (Primary Owner para asientos)"]
    S2 --> S3["3. Desplegar managed-settings.json (antes de instalar)"]
    S3 --> S4["4. Verificar autenticación de desarrolladores"]

1. Configurar la identidad (requiere Owner o Primary Owner)

Configura SAML 2.0 u OIDC para SSO y pruébalo con un grupo piloto pequeño antes del despliegue amplio. Activa la captura de dominio para enrutar automáticamente a todos los usuarios del dominio de la organización. En organizaciones con más de 20 desarrolladores, configura SCIM para aprovisionar automáticamente desde el IdP y desaprovisionar al dar de baja. JIT es más sencillo, pero ofrece menos control sobre el acceso.

2. Asignar asientos y establecer límites de gasto (se requiere Primary Owner para los asientos)

Ve a Settings > Organization > Members y asigna el tipo de asiento adecuado. En planes basados en uso, establece el límite de gasto a nivel de organización antes de que cualquier desarrollador intente una llamada a la API. El valor por defecto es $0 y rechazará todo el uso hasta que se cambie. Establece límites por usuario si necesitas un control más preciso.

3. Desplegar managed-settings.json (despliégalo antes de que los desarrolladores instalen)

El archivo de ajustes a nivel de organización está por encima de los ajustes de usuario y de proyecto, y ningún desarrollador individual puede sobrescribirlo. Úsalo para bloquear permisos, imponer el método de autenticación, fijar la versión mínima y configurar las listas de permitidos de MCP. Despliégalo antes de que los desarrolladores instalen Claude Code. No puede aplicarse retroactivamente a sesiones que ya están en curso.

4. Verificar la autenticación del desarrollador

Los desarrolladores ejecutan claude en la terminal, seleccionan “Claude account with subscription” y se autentican mediante el SSO de Enterprise. Ejecuta /status dentro de Claude Code para confirmar que el asiento y el proveedor de autenticación están correctamente vinculados. Si un desarrollador se autenticó antes con una cuenta personal, debe ejecutar primero /logout.

Comprueba tu comprensión

Escenario · Pre-kickoff bajo presión

Un nuevo despliegue de Claude Enterprise. El kickoff es en 14 días. Tu contacto de TI, Priya, acaba de recibir un rol en la consola de administración. Cuatro decisiones, ocho puntos. Eres responsable del flujo de configuración de administración: elige una opción en cada decisión y compara tu criterio con la explicación. Cada opción vale 2 puntos (mejor), 1 (parcial) o 0 (incorrecta). Las elecciones son definitivas y tienen consecuencias.

Decisión 1 de 4 · Primera llamada con TI

Tienes 30 minutos con Priya. Acaba de recibir un rol en la organización de Claude Enterprise y necesitas la organización lista en 14 días. ¿Qué confirmas primero?

• A. Su rol en la consola de administración
• B. El número de desarrolladores que necesitan acceso
• C. Qué IDE usan los desarrolladores

Ver respuesta

Mejor opción: A (2 puntos). Parcial: B (1 punto). Incorrecta: C (0 puntos).

A. Su rol en la consola de administración (mejor, 2 puntos). Cuáles de los cuatro roles tiene y qué puede hacer realmente ese rol.

Retroalimentación: El rol es la pregunta que condiciona todo. Un contacto de TI que no puede aprovisionar asientos ni configurar SSO bloquea la fase previa al kickoff, sin importar cuántos desarrolladores estén esperando. Confírmalo antes de construir el plan alrededor de cualquiera.

B. El número de desarrolladores que necesitan acceso (parcial, 1 punto). Cuántos desarrolladores necesitan asientos de Claude Code en la primera oleada, y en qué plazo.

Retroalimentación: El número de asientos importa, pero depende de la pregunta sobre el rol. Si Priya no puede aprovisionar asientos, el número es irrelevante hasta que alguien que sí pueda esté en la sala. Confirma primero el rol.

C. Qué IDE usan los desarrolladores (incorrecta, 0 puntos). Configuración del editor para preparar las guías de instalación y configuración adecuadas antes del kickoff.

Retroalimentación: La configuración del IDE es trabajo de configuración. Pertenece a la semana 1, no a la fase previa al kickoff. La pregunta que condiciona todo es si las personas adecuadas tienen los roles adecuados en la consola de administración.

Decisión 2 de 4 · La revelación del rol

Priya envía una captura de pantalla. Su rol aparece como Admin. Necesitas que configure el SSO y aprovisione 30 asientos adicionales de Claude Code antes del kickoff. ¿Qué haces?

• A. Guíala por el SSO y escala los asientos al Primary Owner
• B. Ambas tareas están bloqueadas. Eleva su rol ahora.
• C. Está bien. Admin tiene acceso completo en Enterprise.

Ver respuesta

Mejor opción: B (2 puntos). Parcial: A (1 punto). Incorrecta: C (0 puntos).

A. Guíala por el SSO y escala los asientos al Primary Owner (parcial, 1 punto). Admin puede encargarse de la configuración del SSO; el aprovisionamiento de asientos solo tiene que ir a quien tenga el rol Primary Owner.

Retroalimentación: Identificaste correctamente que los asientos requieren al Primary Owner. Pero Admin no puede configurar SSO en ningún plan; eso también requiere Owner o Primary Owner. Ambas tareas están bloqueadas, no solo una. El rol necesita elevarse antes de que empiece cualquiera de las dos.

B. Ambas tareas están bloqueadas. Eleva su rol ahora. (mejor, 2 puntos). Ni el SSO ni el aprovisionamiento de asientos están disponibles para Admin. Señala el hueco y resuelve el rol antes de que avance cualquier otra cosa.

Retroalimentación: Correcto. Admin puede invitar miembros y ver analíticas en Enterprise, pero el SSO, los registros de auditoría y los controles de retención de datos requieren Owner o Primary Owner. El aprovisionamiento de asientos es exclusivo del Primary Owner. Ambas tareas están bloqueadas. Eleva el rol antes de que avance cualquier otra cosa. Catorce días no dejan margen para idas y vueltas.

C. Está bien. Admin tiene acceso completo en Enterprise. (incorrecta, 0 puntos). Los permisos de Admin en Enterprise son más amplios que en Team, así que Priya debería poder encargarse de ambas tareas.

Retroalimentación: Admin en Enterprise puede invitar miembros y ver analíticas, pero el SSO, el aprovisionamiento de asientos y los registros de auditoría requieren Owner o Primary Owner. Un rol llamado Admin no es lo mismo que el acceso de administrador a los ajustes que importan.

Decisión 3 de 4 · Fallo del primer día

El rol de Priya se eleva a Owner. Ella aprovisiona 30 asientos de Claude Enterprise. La mañana del kickoff, el líder de desarrollo te escribe: nadie puede usar Claude Code. Cada llamada a la API falla de inmediato. ¿Qué compruebas primero?

• A. La configuración del SSO: es posible que los desarrolladores no se estén autenticando correctamente
• B. El límite de gasto a nivel de organización: en los planes basados en uso por defecto es $0
• C. Si los desarrolladores tienen instalada la versión correcta de Claude Code

Ver respuesta

Mejor opción: B (2 puntos). Parcial: A (1 punto). Incorrecta: C (0 puntos).

A. La configuración del SSO: es posible que los desarrolladores no se estén autenticando correctamente (parcial, 1 punto). Si el SSO no está completamente configurado, los desarrolladores no podrán autenticarse y recibirán errores de autenticación en cada llamada.

Retroalimentación: El SSO merece comprobarse, pero si Priya lo configuró al elevarla a Owner, los desarrolladores deberían poder autenticarse. Cuando todos los usuarios fallan a la vez, el problema está a nivel de organización. El límite de gasto de $0 es el culpable más probable; compruébalo antes de asumir un problema de autenticación.

B. El límite de gasto a nivel de organización: en los planes basados en uso por defecto es $0 (mejor, 2 puntos). Un límite de gasto de $0 bloquea cada llamada a la API de todos los usuarios a la vez, independientemente de la asignación de asientos o de la autenticación.

Retroalimentación: Correcto. El límite de gasto por defecto a nivel de organización en los planes Claude Enterprise basados en uso es $0. Ninguna llamada a la API tiene éxito hasta que se establece un límite. Es la causa más habitual de un fallo el mismo día en un despliegue nuevo. Establece primero el límite de la organización y después los límites por usuario si necesitas un control más fino.

C. Si los desarrolladores tienen instalada la versión correcta de Claude Code (incorrecta, 0 puntos). Una versión desactualizada podría causar problemas de compatibilidad que parecen fallos de la API en todo el equipo.

Retroalimentación: Las diferencias de versión no causan fallos inmediatos de la API a todos los desarrolladores a la vez. Cuando todos los usuarios fallan simultáneamente, el problema está a nivel de organización. Revisa los límites de gasto y la configuración de autenticación antes de tocar las máquinas de los desarrolladores.

Decisión 4 de 4 · El equipo de seguridad detecta un problema con MCP

Con los límites de gasto configurados, los desarrolladores pueden trabajar. Pero el equipo de seguridad detecta que algunos desarrolladores han conectado servidores MCP no autorizados. Quieren bloquearlo antes de ampliar el piloto. ¿Cuál es la solución correcta?

• A. Añadir la lista aprobada de MCP a la guía de onboarding de desarrolladores
• B. Configurar listas de permitidos de MCP en managed-settings.json
• C. Que Priya revise y apruebe las solicitudes de MCP caso por caso

Ver respuesta

Mejor opción: B (2 puntos). Parcial: C (1 punto). Incorrecta: A (0 puntos).

A. Añadir la lista aprobada de MCP a la guía de onboarding de desarrolladores (incorrecta, 0 puntos). Documenta la política para que los desarrolladores sepan qué servidores MCP están aprobados y cuáles están fuera de límites.

Retroalimentación: Una política en la guía de onboarding no se impone. Sin un control técnico, los desarrolladores pueden conectarse a cualquier servidor MCP. La guía explica la política; managed-settings.json la impone.

B. Configurar listas de permitidos de MCP en managed-settings.json (mejor, 2 puntos). Establece los servidores MCP permitidos en el archivo de políticas a nivel de organización antes de que se amplíe el piloto. Los desarrolladores no pueden sobrescribirlo.

Retroalimentación: managed-settings.json es la capa de imposición correcta. Está por encima de los ajustes de usuario y de proyecto, y los desarrolladores individuales no pueden sobrescribirla. Configura las listas de permitidos de MCP en la política de la organización antes de que se amplíe el piloto. Retirar un acceso que los desarrolladores ya tienen es más difícil que establecer los límites desde el principio.

C. Que Priya revise y apruebe las solicitudes de MCP caso por caso (parcial, 1 punto). Configura un proceso en el que los desarrolladores envían solicitudes y Priya las aprueba antes de que se conecte cualquier nuevo servidor MCP.

Retroalimentación: La intuición es correcta: hace falta un proceso de revisión. Pero la aprobación manual no escala más allá de un piloto pequeño y no tiene mecanismo de imposición. Sin un control técnico en managed-settings.json, cualquier desarrollador puede conectarse a cualquier servidor MCP, al margen del proceso de aprobación.

Ver debrief y texto de cierre

La fuente asigna un texto de cierre según la puntuación final, sobre un máximo de 8 puntos.

Listo para entregar (7 u 8 puntos). Confirmaste el rol antes de construir el plan, detectaste el alcance completo del hueco de Admin, diagnosticaste correctamente la trampa del límite de gasto y usaste la capa de imposición adecuada para MCP. Así es un flujo de trabajo limpio de administración previa al kickoff.

Sólido, con exposición (4 a 6 puntos). La configuración avanzó, pero al menos una decisión dejó un hueco abierto. Los límites del rol y el valor por defecto del límite de gasto son las dos causas más comunes de escalaciones el día 1 en despliegues nuevos. Conviene revisar los temas en los que se perdieron puntos.

Conviene volver a repasarlo (0 a 3 puntos). Algunas decisiones que generarán problemas en el campo. Revisa la jerarquía de roles en el tema 3 y la lista de verificación previa al kickoff en el tema 4, y luego repite el escenario. Los huecos de este tipo aparecen como puntos del comité de seguimiento en la semana 2.

Ideas clave

Los roles ya están asignados. Ahora vamos a instrumentar la organización.

• Cada tipo de asiento determina si un desarrollador puede acceder a Claude Code, y el modelo de facturación determina qué tipos de asiento existen.
• El SSO, la asignación de asientos y los límites de gasto dependen de los roles Owner o Primary Owner, y deben estar listos antes de que se autentique el primer desarrollador.
• Los roles incorrectos y los límites de gasto en cero son las dos causas más frecuentes de fallos el día 1; ambas se detectan antes del kickoff.
• managed-settings.json se despliega antes de instalar Claude Code, porque no se aplica retroactivamente a las sesiones que ya están en curso.

La organización ya está configurada. La lección 2 muestra cómo extraer los datos de adopción y uso necesarios para construir y defender un scorecard del día 30.

Siguiente: Analytics API para uso y adopción