Roles y permisos del espacio de trabajo: cinco peldaños de acceso

Un espacio de trabajo empieza siendo una persona y un saldo, y los permisos no son ningún problema. Luego se suma un editor freelance para una campaña, un servicio de backend necesita una clave y alguien de finanzas quiere ver cuánto cuesta todo esto. En ese momento, «todos son administradores» deja de ser un atajo y se convierte en un riesgo, porque en eroq cada miembro gasta del mismo saldo de créditos compartido.

Por eso los roles son, primero, una escalera y, después, una cuadrícula de casillas. Cinco peldaños, quince capacidades con nombre propio, una regla sobre quién puede actuar sobre quién y, cuando un peldaño no encaja exactamente con alguien, un interruptor por persona para cada capacidad. Aquí tienes el modelo completo, y el comportamiento que sorprende a todo el mundo la primera vez: qué le pasa a una clave de API cuando degradas a la persona que la creó.

Los cinco peldaños

Cada peldaño tiene todas las capacidades del peldaño de abajo, más las suyas. Ese es todo el modelo mental; lo demás son detalles.

Propietario. Todo, incluidas las dos capacidades que nadie más tiene: transferir el espacio de trabajo a otra persona y eliminarlo por completo. El propietario es la cuenta que creó el espacio de trabajo.

Administrador. Lleva la casa. Personas, facturación, configuración del espacio de trabajo, claves de API, webhooks, generación, publicación, biblioteca y uso. Todo salvo transferir y eliminar.

Desarrollador. Construye sobre la API. Crea y revoca claves de API, gestiona endpoints de webhook, genera a pleno ritmo, publica, consulta la biblioteca y el registro de uso. Sin facturación, sin invitaciones, sin configuración. Es el peldaño para el ingeniero que integra la API y que nunca debería poder cambiar el plan.

Creador. Trabaja en el estudio. Genera, publica en el escaparate de la comunidad, consulta la biblioteca y el uso. Sin claves, sin webhooks, sin configuración, sin facturación. Por defecto, un Creador recibe además la mitad de la cuota por minuto del límite de solicitudes del espacio de trabajo: suficiente para trabajar todo el día en la herramienta de video, pero no tanto como para dejar sin recursos a un pipeline de producción que corre en el mismo plan.

Lector. Consulta la biblioteca de creaciones y el registro de uso. No puede gastar ni un crédito. Es el peldaño para un cliente, una parte interesada o la persona que solo necesita comprobar qué se hizo y cuánto costó.

Las capacidades tienen nombre propio, no se sobreentienden: generar, publicar, ver la biblioteca, ver el uso, los cuatro permisos de almacenamiento (explorar, subir, eliminar, configuración), claves de API, webhooks, configuración del espacio de trabajo, gestionar personas, facturación y planes, transferir la propiedad y eliminar el espacio de trabajo. La matriz de la pestaña Miembros en /dashboard/workspace se genera a partir de los mismos datos que aplica el servidor, así que lo que ves ahí es lo que de verdad ocurre en cada solicitud.

Cuando un peldaño no encaja: marca un permiso

Una escalera es el punto de partida correcto y la respuesta final equivocada. El editor que debería publicar pero nunca gastar un crédito, el contratista que necesita claves de API durante un mes pero jamás debe ver la facturación, la persona de finanzas que solo debería recargar el saldo y nada más: ninguno de ellos es un peldaño.

Por eso cada capacidad es también una casilla. Abre el acceso de un miembro en la pestaña Miembros y el rol será el punto de partida: cada casilla viene rellenada a partir de él, y tú marcas o desmarcas cualquiera por encima. Un Lector con Generar marcado puede gastar créditos; un Desarrollador con Claves de API desmarcado no puede crear ninguna. La lista de miembros muestra una pequeña etiqueta personalizado junto a cualquiera cuyo acceso difiera de su rol, y al pasar el cursor por encima ves exactamente qué se añadió o se quitó.

Tres reglas evitan que esto se convierta en un caos:

1. Solo puedes conceder lo que tienes. Un Desarrollador puede marcar Webhooks para un Creador porque los Desarrolladores tienen webhooks; no puede marcar Facturación y planes para nadie, porque él mismo no la tiene. Desmarcar siempre está permitido sobre cualquiera que esté por debajo de ti.
2. Las casillas nunca cambian el rango. Un Creador con Gestionar personas marcado puede invitar y editar a personas por debajo de Creador, y solo por debajo de Creador. La escalera sigue decidiendo quién está por encima de quién.
3. Transferir y eliminar no tienen casilla. Son del propietario, y punto.

También puedes hacer todo esto antes de que llegue la persona. El formulario de invitación tiene la misma cuadrícula plegada bajo el selector de rol: invita a alguien como Lector con Generar marcado y eso es exactamente lo que tendrá desde su primer inicio de sesión, sin ningún intervalo en el que un recién llegado tenga más o menos de lo que pretendías.

Un cambio de rol conserva las casillas que siguen teniendo sentido: asciende a Creador a un Lector personalizado y la marca de Generar, que ahora ya va incluida en el rol, simplemente desaparece; la marca de Facturación que tenía se queda. Y una clave de API sigue las mismas reglas que todo lo demás: marca o desmarca una casilla y la clave lo aplica en menos de treinta segundos, exactamente igual que con un cambio de rol.

Por qué el propietario no es un rol que puedas asignar

El propietario no se guarda en la fila de la membresía. Es una propiedad del propio espacio de trabajo (la cuenta que lo creó) y se eleva al peldaño superior cuando se lee el espacio de trabajo.

Parece un detalle de implementación. Tiene tres consecuencias con las que puedes contar:

1. Siempre hay exactamente un propietario. No «normalmente uno». El esquema no puede representar dos.
2. No puedes crear uno por accidente. Un administrador que reparte roles nunca ve Propietario en el selector, porque no es un rol asignable.
3. Transferir el espacio de trabajo es un acto deliberado, distinto de ascender a alguien. Entregar la cuenta de una empresa no es el mismo gesto que darle a un colega acceso a la facturación, y el modelo se niega a mezclarlos.

La versión práctica: si vas a configurar un espacio de trabajo para una empresa, créalo desde una cuenta que controle la empresa, no desde un inicio de sesión personal que querrás borrar dentro de dieciocho meses.

Solo puedes gestionar a personas con un rango inferior al tuyo

La segunda regla: solo puedes actuar sobre un miembro si tu rango es estrictamente superior al suyo, y nunca puedes conceder un rol igual o superior al tuyo.

Léelo dos veces, porque las dos mitades importan:

• Dos administradores nunca pueden degradarse, quitarse ni bloquearse entre sí. Los rangos iguales no se tocan. Si un administrador tiene que irse, se encarga el propietario.
• Un Desarrollador no puede ascenderse a Administrador, ni ascender a nadie a Administrador, porque Administrador no está por debajo de Desarrollador.
• El selector de rol del formulario de invitación solo muestra los peldaños que puedes repartir. Un administrador ve Administrador, Desarrollador, Creador y Lector. Un desarrollador no ve nada con lo que invitar, porque las invitaciones son una capacidad de gestión de personas.

Con un nivel plano de administradores, un espacio de trabajo acaba secuestrado por quien haga clic más rápido durante un desacuerdo. Una escalera lo vuelve imposible, no solo improbable.

Una clave de API hereda el rol de su titular

Esta es la parte que conviene interiorizar. Una clave no es una identidad aparte con sus propios permisos. Lleva el rango del miembro que la tiene, evaluado en cada llamada.

Degrada a un Desarrollador a Lector y sus claves dejan de generar, de inmediato, sin que tengas que tocar las claves:

curl -X POST https://eroq.ai/v1/videos/generations \
  -H "Authorization: Bearer $EROQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "eroq-motion-one",
    "prompt": "A courier crosses a wet avenue under a broken streetlight, headlights smearing behind her. Tracking shot, 35mm film, neon noir palette, tense tempo.",
    "seconds": 5,
    "aspect": "9:16"
  }'

{
  "error": {
    "message": "This workspace role cannot spend credits. Ask an admin for Creator access or above.",
    "type": "permission_error",
    "code": "role_forbidden"
  }
}

Fíjate en lo que no ocurrió: no se cobró nada y la clave sigue pudiendo leer. Las claves de un miembro degradado pueden seguir listando creaciones y leyendo el uso, porque esas son capacidades de Lector. Solo dejan de funcionar las capacidades que quitaste.

Cuando alguien deja el equipo, este es todo el procedimiento. Un único cambio de rol elimina la generación en todas las claves que esa persona haya creado, sin auditar qué claves existen ni qué servicio las está usando. Cambia primero el rol y revoca las claves cuando te venga bien. Los cambios de rol se aplican a las solicitudes nuevas en cuestión de segundos.

Además, la comprobación vive en un solo lugar del servidor, el momento en que los créditos están a punto de moverse, así que un endpoint de generación nuevo no puede olvidarla.

Dos controles por encima del rol

Los roles deciden qué. Dos controles por miembro deciden cuánto, y un administrador ajusta ambos en la pestaña Miembros:

Una parte de los límites de solicitudes por minuto, en porcentaje. La parte propia del rol es el techo (Creador empieza en la mitad) y un ajuste por miembro solo puede reducirla aún más, nunca ampliarla por encima de lo que permite el rol.

Un tope mensual de créditos. Un límite estricto a lo que ese miembro puede gastar del saldo compartido en un mes natural, que se reinicia el día 1. Los reembolsos se descuentan, así que un render que falló y se reembolsó solo no se come en silencio la asignación de nadie. Al llegar al tope se devuelve un rechazo claro que indica la cifra, no un misterioso error de facturación.

Ninguno de los dos controles es obligatorio: déjalos vacíos y el miembro simplemente obtiene lo que concede su rol. Dimensionarlos es un tema aparte, y el razonamiento detrás de los créditos planos está en precios por créditos para APIs de IA.

Una asignación por defecto sensata

• Servicio de backend o integración → Desarrollador, con una clave por pipeline.
• Editor freelance o contratista → Creador, con un tope mensual ajustado al encargo.
• Productor o responsable de cuenta que aprueba el gasto → Administrador.
• Cliente, parte interesada, auditor → Lector.
• La cuenta que es la titular legal del trabajo → Propietario, y nadie más.

Una restricción más que conviene tener en cuenta antes de invitar a nadie: cuántos puestos incluye tu plan. Los espacios de trabajo gratuitos tienen uno, cada plan individual tiene exactamente dos y los equipos de verdad viven en los planes para empresas. La tabla de puestos está en /pricing y se explica de nuevo en /faq.

Preguntas frecuentes

¿Pueden dos administradores quitarse entre sí en eroq?

No. Un miembro solo puede actuar sobre alguien con un rango estrictamente inferior, así que los rangos iguales son intocables entre sí. Quitar o degradar a un administrador es tarea del propietario.

¿Qué pasa con las claves de API cuando degrado a un compañero?

Siguen funcionando para lo que el nuevo rol todavía permite y dejan de hacer el resto. Tras una degradación a Lector, las claves pueden seguir leyendo la biblioteca y el uso, mientras que cualquier llamada de generación responde 403 role_forbidden sin cobrar ni un crédito.

¿Propietario es un rol que puedo darle a otra persona?

No como rol. El propietario es la cuenta que creó el espacio de trabajo, así que nunca aparece en el selector de rol: cederlo es una transferencia del propio espacio de trabajo, una acción aparte y exclusiva del propietario.

Configura la escalera antes de que se una la segunda persona: abre la pestaña Miembros en /dashboard/workspace.