AI Admin Console: o que cada uma das seis capacidades faz, na realidade

As capacidades estão listadas pela ordem em que aparecem no menu lateral do Console. Cada secção abaixo nomeia a pergunta de compras, o que o Console faz a respeito dela e onde vivem os dados.

Membros e acesso

A pergunta: quem na nossa organização está autorizado a usar o AI Suite, e em que nível de licença?

O Console permite a um administrador convidar colegas por email, atribuir lugares de licença Pessoal ou Comercial (Mensal, Anual ou Pontual) e revogar acessos quando colaboradores saem. Convite em massa a partir de CSV. A lista é a única fonte de verdade do deployer para "quem tem acesso" — a mesma resposta que a equipa de conformidade produz quando lhe é pedido para demonstrar supervisão humana.

O que vive no backend da Software Tailor: a lista da organização. O que não vive: qualquer registo do que esses membros fizeram dentro do modelo. O Console é a superfície de acesso; a inferência acontece localmente.

Licenças

A pergunta: que nível tem cada membro e como é aplicado offline?

Chaves de licença por utilizador validam offline. Útil quando os lugares precisam de continuar a funcionar sem uma viagem à rede — um requisito comum em setores regulados em que a estação de trabalho de IA está numa rede segmentada. O Console emite e revoga chaves; as substituições de nível por utilizador são visíveis a par do padrão da organização.

Esta é a única capacidade em que o Console escreve um valor que tem de viajar até à máquina do utilizador. Tudo o resto são metadados sobre a implantação, não sobre o conteúdo.

Inscrição de AI Server

A pergunta: em que hardware está a nossa organização a confiar para correr inferência?

As instalações do AI Suite comunicam com um processo aisuite-server local; esse processo pode comunicar com um modelo no dispositivo ou com um AI Server controlado pelo cliente em execução dentro da rede do cliente. A inscrição de AI Server é a forma como o Console liga essas instâncias de servidor à organização para que aceitem pedidos assinados de instalações de AI Suite aprovadas. Emparelhar, rodar credenciais, revogar sem tocar na própria caixa do servidor.

O ângulo de compras: o hardware de inferência é do deployer. A inscrição prova-o. O Console nunca vê a entrada ou a saída do modelo.

Política

A pergunta: que modelos, providers e regras de tratamento de dados se aplicam às instalações de AI Suite da nossa organização?

A política é a configuração de toda a organização que cada aplicação AI Suite respeita: que modelos são permitidos, dicas de residência de dados, providers de início de sessão e configuração do tenant OIDC. As alterações propagam-se a cada instalação no próximo arranque. É para isto que o deployer aponta a equipa de conformidade quando perguntam "que salvaguardas estão em vigor?" — e é o que edita quando uma alteração ao EU AI Act é publicada (mais recentemente, o acordo omnibus de 7 de maio de 2026 apertou a definição de sistema de alto risco ^[1]).

Auditoria

A pergunta: o que aconteceu, quando, por quem — e conseguimos produzir isso a pedido?

Cada ação administrativa aterra numa linha de auditoria JSONL: timestamp, email do ator, verbo da ação, recurso afetado, o X-App-Id do cliente originador. Nenhum prompt. Nenhuma resposta. Nenhum conteúdo de documentos. O armazenamento de conteúdo do deployer guarda o conteúdo da inferência; a linha de auditoria do Console guarda a prova de que a ação aconteceu.

Essa separação é o que faz com que a linha satisfaça o critério do NIST AI RMF de "registos das ações do sistema suficientes para reconstruir decisões" ^[2] sem reter conteúdo do modelo que o deployer não quer reter. A arquitetura e o formato da linha estão documentados no nosso artigo sobre registos de auditoria sem conteúdo.

Utilização por organização

A pergunta: o que está, na realidade, a acontecer em toda a nossa organização, em agregado?

Uma consolidação de telemetria só de leitura, com âmbito na organização: instalações ativas, eventos principais, duração média da inferência, classificações de modelos. Nenhum prompt em bruto. Tudo é agregado e sem conteúdo por desenho. A equipa de TI do deployer usa-o para planeamento de capacidade; a equipa de conformidade usa-o para "a política está realmente a ser cumprida?"

Este é o único lugar onde aparece um número que atravessa membros e o único lugar onde o Console resume comportamentos ao longo do tempo.

Porquê uma única ferramenta

O NIST AI RMF ^[2] pede "registos das ações do sistema suficientes para reconstruir decisões". O EU AI Act pede aos deployers que demonstrem supervisão humana, monitorizem o funcionamento do sistema, conservem registos e os produzam a pedido ^[1]. Em ambos os quadros, é o deployer — não o fornecedor — que detém a obrigação. O Console existe porque a equipa de TI do deployer precisa de um único sítio para a cumprir.

As seis capacidades não são uma lista de funcionalidades. São a resposta às seis perguntas que um revisor de compras fará em sequência. Equipas que estão a iniciar essa due diligence sobre uma implantação de IA on-prem devem começar pelo enquadramento em Porque é que as implantações de IA on-prem ficam paradas em compras; o Console é onde vivem as respostas.

Referências

1. Comissão Europeia. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Acedido a 2026-07-01.
2. NIST. "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Acedido a 2026-07-01.

Artigos relacionados

• EU AI Act em 2026: o que a implantação on-prem altera em matéria de conformidade
• Porque é que as implantações de IA on-prem ficam paradas em compras (e o enquadramento que resolve a situação)
• Registos de auditoria sem conteúdo: como provamos o que o modelo fez sem guardar prompts
• Todos os artigos →