Gobernanza: quién puede hacer qué y cuánto cuesta

Por qué una plataforma de IA necesita su propia gestión de permisos

Una plataforma de IA necesita su propia gestión de permisos, porque una ventana de chat sin reglas traslada cada pregunta a cada sistema conectado. En cuanto la IA está conectada a un sistema de la empresa, la pregunta ya no es si alguien puede chatear, sino qué registros puede leer la IA en nombre de esa persona.

Una prohibición solo desplaza el uso, no lo termina

Quien no tiene una vía autorizada toma la siguiente mejor. Una prohibición traslada el uso a cuentas privadas de proveedores públicos, donde no rigen ni contrato, ni registro, ni derecho de supresión. Los datos de la empresa acaban entonces en un servicio que nadie de su organización administra y cuyo tratamiento no puede acreditar.

La contramedida que funciona es una vía autorizada mejor que la privada. Pero debe hacer controlables cuatro cosas; de lo contrario, solo se traslada el riesgo hacia dentro:

• Qué personas pueden usar la plataforma y mediante qué inicio de sesión.
• Qué sistemas conectados y qué herramientas individuales están disponibles para una persona.
• Qué ha ocurrido realmente, de forma demostrable y exportable.
• Cuánto cuesta la operación, desglosado y limitable, antes de que llegue la factura.

Precisamente estos cuatro puntos de control forman las áreas del panel de administración de Kisuno: gestión de usuarios, reglas de acceso, auditoría y consumo.

De dónde vienen los usuarios, los roles y los grupos

Los usuarios, los roles y los grupos se gestionan en el panel de administración o se toman de Entra ID. Un rol agrupa permisos funcionales, es decir, lo que alguien puede hacer en la interfaz. Un grupo agrupa personas para las reglas de acceso y de presupuesto. Ambos se combinan de forma independiente.

Usuarios locales y conexión con Entra ID

Sin proveedor de identidad, Kisuno funciona con cuentas locales: invitación por enlace y contraseña definida por la persona invitada. El inicio de sesión mediante Entra ID u otro proveedor OIDC es compatible con la plataforma y se configura para su instancia. Una vez configurado, cada persona inicia sesión mediante OIDC, la cuenta se crea en el primer acceso y los datos de grupo y rol del token de inicio de sesión se asignan a sus grupos en Kisuno.

La retirada de acceso ocurre así en la puerta de entrada: quien esté desactivado en Entra ID ya no entra y pierde con ello todo acceso, también a los sistemas conectados. El aprovisionamiento y desaprovisionamiento automáticos de cuentas mediante SCIM están previstos, pero hoy todavía no están disponibles.

Qué define un rol y qué define un grupo

Un rol controla los permisos funcionales en la plataforma, por ejemplo si alguien puede crear agentes, usar la búsqueda web o abrir el panel de administración. Un grupo controla a qué datos y herramientas se accede y a qué presupuesto se imputa el consumo.

Invitación, asignación, desactivación

Una invitación se envía por correo o enlace y puede incluir ya el grupo de destino. La pertenencia se aplica en cuanto la persona invitada completa el registro. Así nadie empieza en un estado intermedio sin permisos y usted no tiene que añadir nada después de cada registro.

Hay dos formas de finalizar el acceso. El bloqueo mantiene la cuenta pero deniega el inicio de sesión. La eliminación borra la cuenta, las conversaciones y las entradas del índice de búsqueda; antes es posible una exportación de datos para la persona afectada, de modo que se atiendan tanto las solicitudes de acceso como las de supresión.

Permisos hasta el nivel de herramienta

Las llamadas a herramientas pasan por la pasarela MCP, un componente situado entre el chat y el sistema conectado. Para la persona que hace la solicitud, la pasarela comprueba si el servidor y la herramienta concreta están permitidos, registra la decisión y solo transmite la llamada si hay autorización. Las herramientas bloqueadas no aparecen en la lista de herramientas del usuario; tras un cambio de permisos, esto surte efecto con un breve retardo. El verdadero cerrojo es la comprobación en cada llamada.

Los sistemas se conectan mediante MCP, el estándar abierto para el acceso a herramientas por parte de modelos de IA. La pasarela se sitúa delante para que la autorización se decida de forma centralizada por persona, rol y grupo, y no quede dispersa en el sistema conectado. Qué sistemas se pueden conectar y cuáles están preparados figura en la página Integraciones; los permisos sin herramientas carecen de objeto.

El ejemplo: leer facturas sí, leer nóminas no

Un ERP conectado no ofrece a la IA un único acceso, sino muchas herramientas individuales: buscar facturas, leer datos de clientes, leer datos salariales, escribir registros. Al grupo de Contabilidad se le habilitan las herramientas de facturación, mientras que las de nóminas quedan reservadas a Recursos Humanos. Mismo servidor, herramientas distintas, decisiones separadas.

Debajo hay un segundo límite. Si Kisuno inicia sesión en su ERP con la identidad de cada persona, siguen siendo decisivas las reglas de acceso de ese ERP: quien allí solo puede ver determinados registros tampoco ve más a través de la IA. Si la conexión funciona con una cuenta de servicio compartida, la pasarela es el único punto de aplicación y la selección de herramientas debe recortarse en consecuencia.

Los permisos dentro de una herramienta, es decir, sobre campos o filas concretos, no los aplica Kisuno. De ello se encarga la gestión de permisos del sistema conectado. Por eso, una herramienta con un alcance funcional amplio no debe habilitarse en absoluto o solo a un grupo que de todos modos puede ver esos datos.

La cadena de reglas: usuario antes que rol, que grupo y que valor predeterminado

Los permisos se evalúan en un orden fijo: usuario individual, luego rol, luego grupo y por último el valor predeterminado del servidor. Decide la primera regla que coincide y la búsqueda se detiene ahí. Así, cada decisión es explicable y una autorización puntual no necesita un rol especial. Que los permisos se apliquen por herramienta individual es el rasgo diferenciador en la comparativa con otras plataformas.

Qué ocurre cuando no se aplica ninguna regla

Si no se aplica ninguna regla de usuario, rol o grupo, decide el valor predeterminado del servidor correspondiente. Configure ese valor como «denegar» justo después de conectar un sistema y habilite después grupos concretos. Así, un sistema recién conectado no puede mostrar por descuido más de lo previsto.

Si falla la propia comprobación de permisos, por ejemplo porque la base de datos de reglas no es accesible, la pasarela deniega la llamada en lugar de dejarla pasar. Una avería produce, por tanto, un mensaje de error en el chat y no un acceso abierto. Está previsto un interruptor de solo lectura por servidor que bloquee de forma general las herramientas de escritura.

Auditoría: cada acceso trazable

Cada llamada a una herramienta a través de la pasarela se registra con la hora, la persona, el sistema de destino, la herramienta y la decisión, también las denegadas. Además, la plataforma lleva un registro encadenado de forma continua de las acciones de administración, los inicios de sesión y los cambios de permisos. Ambos registros residen en su propia instancia y se pueden exportar como CSV.

Qué se registra

• Las llamadas a herramientas de sistemas conectados, con la decisión tomada, permitida o denegada.
• Los inicios de sesión en la plataforma y en el panel de administración.
• Los cambios en roles, grupos, permisos y reglas de acceso.
• Los cambios en la configuración de la instancia.
• La creación, invitación, bloqueo y eliminación de cuentas.

El registro de auditoría es una prueba de acceso, no una transcripción de las conversaciones. Responde a quién llamó a qué herramienta, en qué sistema y cuándo. Las conversaciones se guardan aparte, en la base de datos de su instancia, y están sujetas al periodo de conservación configurado.

Cuánto se conserva y adónde se puede exportar

Los registros permanecen en su instancia, en su base de datos. En autoalojamiento no salen de su infraestructura. La exportación se realiza en CSV, filtrada por periodo y persona, y puede entregarse directamente a una revisión, al departamento jurídico o a una herramienta de auditoría.

El registro de acciones de administración está encadenado: cada entrada lleva una suma de comprobación de la anterior y una verificación integrada avisa cuando la cadena deja de cuadrar. Así se detecta la eliminación posterior de entradas concretas. Para las conversaciones, el periodo de conservación es configurable; los contenidos vencidos se eliminan junto con el índice de búsqueda.

Hacer visibles los costes y limitarlos

El consumo se registra por persona, grupo, modelo y día, y se indica tanto en tokens como en euros. Un presupuesto mensual común limita el total de toda la organización; un límite mensual opcional por persona limita las cuentas individuales. Cuando un presupuesto se agota, entra en vigor un bloqueo blando (soft block).

Consumo por persona, grupo y modelo

El panel de administración muestra el consumo en euros, desglosado por persona, por modelo y por día, junto con las solicitudes individuales con modelo y hora. Los importes y el desglose los ve la administración; los usuarios finales solo reciben un aviso en el chat cuando el presupuesto está agotado. Así se saca la presión de los costes del trabajo diario y las cifras siguen visibles donde corresponde.

Los precios se registran por modelo para que el análisis no se base en una aproximación. Esto importa más de lo que parece: con la misma conversación, entre un modelo económico y uno muy grande el coste se multiplica. Por eso, una selección curada de modelos forma parte del control de costes y no es solo una cuestión de usabilidad.

Presupuesto mensual común en lugar de límites individuales

El presupuesto mensual se aplica a la organización en su conjunto, no por persona. La razón es práctica: el consumo nunca se reparte de forma uniforme. Quien usa la plataforma de forma intensiva se quedaría atascado en un límite individual rígido, mientras que a otros les caducaría el cupo sin usar. Un fondo común compensa eso sin que nadie tenga que reajustar límites.

Para los casos atípicos existe además un límite mensual opcional por persona. Está desactivado mientras usted no lo configure y se aplica de forma estricta en la misma comprobación que el presupuesto global. Uso típico: una sola cuenta que envía solicitudes automatizadas no debe vaciar por sí sola el fondo común.

Bloqueo blando en lugar de un exceso silencioso

Cuando el presupuesto se agota, entra en vigor el bloqueo blando: la siguiente solicitud se rechaza, con un aviso en el chat en lugar de seguir facturando en silencio. Una respuesta en curso se termina igualmente. El administrador puede aumentar el presupuesto en cualquier momento y el servicio continúa de inmediato. Sin ese aumento no se genera ningún cargo adicional.

La comparación entre el consumo registrado y el presupuesto se ejecuta cada minuto, y la estimación previa de una solicitud no conoce su longitud exacta. Por eso, una respuesta concreta puede superar ligeramente el límite. Se trata de un bloqueo blando que evita una explosión de costes, no de una reserva previa al segundo.

Autorizar agentes en lugar de prohibirlos

Los agentes y las skills se habilitan de forma curada, ni se permiten ni se prohíben en bloque. Las cuentas normales usan los agentes que se les han asignado y no ven el constructor de agentes. Un rol con privilegios crea y comparte agentes, y el administrador habilita las skills persona por persona.

El motivo está en los permisos: un agente incorpora unas instrucciones fijas y un conjunto de herramientas. Si cualquiera pudiera crear y compartir sus propios agentes, junto a su cadena de permisos surgiría un segundo canal de distribución sin control. La comprobación de permisos en la pasarela seguiría aplicándose en cada llamada, pero se perdería la visión de conjunto sobre quién trabaja con qué.

En la práctica, esto da como resultado unos pocos agentes bien mantenidos por grupo en lugar de muchos a medias: uno para elaborar ofertas, uno para análisis del ERP y uno para la búsqueda de conocimiento interno.

Preguntas frecuentes