Roles y acceso¶

Esta página explica cómo decide OS lo que alguien puede hacer en una organización: roles, grupos, atributos, el documento de reglas de la organización, cómo llega un socio a las organizaciones que tiene debajo, y por qué nadie puede dar más de lo que tiene. No contiene pasos; las páginas de tareas de Administrar muestran cómo configurarlo.

Una regla decide¶

Todo lo que alguien puede hacer en OS proviene de reglas. Una regla dice, sobre un tipo de cosa (un grupo, un miembro, un agente, una conversación), si lo permite (permit) o lo deniega (forbid), para qué acciones y bajo qué condiciones.

Hay cuatro acciones:

Tres convenciones deciden cada caso:

• Nada se puede hacer sin una regla que lo permita. El orden de las reglas no importa.
• Una regla que deniega prevalece. Si encaja un forbid, OS deniega, diga lo que diga un permit.
• Ninguna acción incluye otra. Quien puede modificar pero no ver, no encuentra la cosa. Lo que no puedes ver no existe para ti: OS responde como si no estuviera.

Una regla puede poner condiciones a la cosa (el nombre, o una etiqueta que lleva) y a la persona (un atributo que tiene). Una regla solo vale si se cumplen todas sus condiciones; quien quiera permitir dos valores escribe dos reglas. Cómo es exactamente una regla está en Tipos y acciones.

Roles¶

Un rol es un conjunto de reglas con nombre. Quien tiene un rol queda sujeto a sus reglas. Un miembro recibe un rol directamente, o mediante un grupo al que pertenece.

Todas las organizaciones tienen los mismos roles integrados. Son iguales en todas partes y no se modifican.

Además, un administrador crea roles propios para su organización: por ejemplo un rol «Jefe de equipo» que puede administrar a los miembros de su propio departamento. Una organización tiene como máximo 100, cada uno con como máximo 200 reglas. Consulta Administrar roles.

Lo que permiten los roles integrados en las funciones de IA¶

Los roles integrados también contienen reglas sobre las funciones de IA: modelos, agentes, conocimiento, archivos y conversaciones.

Todos los roles integrados pueden usar todos los modelos, herramientas, agentes, prompts, skills, planificaciones, workflows, conocimiento y archivos de la organización. Lo que el servicio de la organización no contiene, tampoco puede un rol integrado. De las conversaciones, la memoria, los archivos guardados y las filas del datastore, un miembro accede a las suyas y a las compartidas, que no son de nadie en particular.

Un administrador nunca ve las conversaciones, la memoria ni los archivos de un compañero. Tampoco org-admin accede de esas filas más que a las suyas y a las compartidas. Quien quiera otra cosa escribe para ello una regla propia, y solo puede hacerlo si él mismo tiene ese acceso (más abajo).

Ajustes para toda la organización¶

Algunas cosas valen para todos en la organización a la vez y no dependen de la persona. Por eso no están en un rol sino en el documento de reglas:

• si las funciones de IA pueden escribir memoria: por defecto, nadie;
• si los archivos y páginas guardados pueden compartirse mediante un enlace: por defecto, nadie;
• si se pueden descargar los archivos que creó una herramienta: por defecto, todo miembro;
• qué enrutadores de modelos se pueden usar: por defecto, todos, para todo miembro;
• a qué direcciones externas pueden llegar las funciones de IA. Sin una regla al respecto son las direcciones que tu operador permite para la organización; una regla puede restringirlo.

Escribir memoria y compartir mediante un enlace se activan en cuanto el documento de reglas los permite, y entonces para todos, nunca para una sola persona. Solo quien los tiene, org-admin u operator, puede escribir una regla así (cómo). Un rol propio no puede decir nada sobre estas cosas.

Grupos¶

Un grupo reúne miembros, por ejemplo un equipo o un departamento. Un grupo puede tener roles y valores de atributos, y todo miembro del grupo los tiene también. Quien sale del grupo, o cuyo grupo desaparece, pierde lo que daba el grupo. Consulta Administrar grupos.

Atributos¶

Un atributo es un dato sobre un miembro que las reglas pueden leer, como department (departamento) u office (oficina). El administrador decide qué atributos conoce la organización y si los valores son libres o salen de una lista fija. Un miembro tiene los valores que recibió él mismo más los de sus grupos. Consulta Administrar atributos.

Tres atributos los lee OS siempre por sí mismo y no puedes crearlos:

• role: cada rol que tiene el miembro, directamente o mediante un grupo;
• group: cada grupo al que pertenece el miembro;
• subject: quién es el miembro, para que una regla pueda decir «esto es mío».

OS vuelve a determinar estos datos en cada solicitud a partir de lo que ha registrado la organización. Un miembro no puede indicar por sí mismo sus propios atributos.

El documento de reglas¶

Además de roles, cada organización tiene un documento de reglas: reglas que valen para todo miembro activo. En él pones lo que vale para todos, como «nadie usa el modelo caro» o «los becarios no usan agentes del departamento de finanzas». Aquí están también los ajustes para toda la organización. Consulta El documento de reglas.

Para un miembro valen, pues, en conjunto: las reglas de sus roles, el documento de reglas y member.

Socios y las organizaciones que están debajo¶

Un rol se da con un alcance:

• organisation (por defecto): el rol vale en la organización que lo dio.
• descendants: el rol vale en esa organización y en todas las que están debajo.

Así trabajan las personas de un socio en las organizaciones de sus clientes, sin ser miembros de ellas. Un empleado de soporte que tiene org-admin con alcance descendants en el socio administra también a los clientes que están bajo el socio. Del socio solo cuenta en una organización cliente lo que se dio con alcance descendants; el documento de reglas del socio y sus roles con alcance organisation no llegan hacia abajo.

Una organización no puede quitar la administración que una organización superior da con alcance descendants: sobre la administración no existen reglas que deniegan. Sobre las funciones de IA sí: un forbid en el documento de reglas de una organización vale allí también para las personas de un socio. El registro de auditoría de la organización indica en cada cambio desde qué organización actuó la persona.

El primer administrador de una organización nueva recibe org-admin con alcance descendants, para que también administre los departamentos que cree más tarde bajo su organización.

Nadie da más de lo que tiene¶

Todo cambio que permita a alguien hacer más es una concesión: dar un rol, poner a un miembro en un grupo, dar a un grupo un rol o un valor, dar un valor de atributo, escribir las reglas de un rol propio o el documento de reglas, e invitar con alguno de estos. OS solo permite una concesión si tú mismo puedes hacer el cambio y tienes lo que das:

• un rol lo tienes si lo tienes tú (con al menos el mismo alcance), o si tienes todas sus reglas;
• un valor de atributo lo tienes si lo tienes tú, o si puedes conceder ese atributo (org-admin puede hacerlo para cualquier atributo);
• un grupo lo tienes si tienes todos los roles y todos los valores que da el grupo;
• una regla la tienes si una de tus propias reglas permite lo mismo, sobre las mismas cosas, y ninguna regla que deniega le quita nada.

Una concesión rechazada no cambia nada, y OS indica lo que no tienes. Una invitación se comprueba al enviarla y de nuevo al aceptarla.

No puedes escribir una regla que deniegue sobre la administración (organizaciones, miembros, invitaciones, grupos, roles, reglas y atributos). Una regla así también podría quitar derechos a los propios administradores. Sobre las funciones de IA sí puedes denegar.

Dentro del servicio de la organización¶

Todo lo que permiten roles, grupos y reglas vale solo dentro del servicio de la organización: lo que contienen sus planes y excepciones. Una regla sobre algo que no está en el servicio no permite nada. El servicio hace, pues, más pequeños los roles, nunca más grandes, y una regla que deniega sigue valiendo siempre.

Quien concede un rol propio, un grupo o una regla que llega más allá del servicio recibe 403 con This is not part of your organisation's service, incluso antes de comprobar si tienes lo que das (más arriba). Los roles integrados siempre puedes darlos: son iguales en todas partes y el servicio solo los hace más pequeños. La propia administración de la organización (miembros, invitaciones, grupos, roles, atributos, reglas, el registro de auditoría y la lectura del servicio) está siempre en el servicio (Siempre en el servicio).

Lo que ves en OS¶

OS muestra botones y menús exactamente para lo que puedes hacer, dentro del servicio de la organización: en cada cosa figura qué acciones puedes hacer sobre ella, y por tipo, qué acciones puedes hacer sobre al menos una cosa de ese tipo. Lo que no ves, no puedes hacerlo. Cómo lo lee un programa está en La API de acceso.

El registro de auditoría¶

Todo cambio en las personas, grupos, roles, atributos, reglas, invitaciones y ajustes de una organización queda en su registro de auditoría: cuándo, quién, desde qué organización y qué cambió. El registro no contiene contraseñas, claves ni direcciones de correo electrónico. Consulta Leer el registro de auditoría.