A maioria das universidades não decidiu adotar a IA; ela chegou. Os docentes redigem com ela, os estudantes programam com ela, os grupos de investigação ligam agentes a contas de laboratório partilhadas e a dados departamentais, e a TI central só descobre depois. A investigação da EDUCAUSE (2025) descreve a lacuna sem rodeios: a utilização de IA é hoje generalizada entre docentes e funcionários do ensino superior, enquanto a governação formal da IA e a cobertura da política de utilização aceitável ficam para trás. Uma política que ninguém consegue ver, e que nada aplica, não é um controlo — é um PDF.
Essa lacuna não é exclusiva do campus, mas o campus torna-a mais aguda. As contas são partilhadas por conceção. A integridade da investigação depende de saber o que tocou o quê. E as pessoas que mais quer capacitar — os investigadores — são exatamente aquelas que um controlo demasiado pesado empurraria para ferramentas-sombra.
O problema, em concreto
Três coisas tendem a ser verdade ao mesmo tempo numa rede de campus:
- A política de utilização aceitável existe, mas não é aplicada. Há uma regra sobre que sistemas a IA pode tocar e o que pode fazer. Nada transforma essa regra numa decisão no momento em que um agente tenta atuar.
- As contas partilhadas apagam a atribuição. Os agentes de um laboratório correm como uma única conta de serviço por trás de um pool de ligações. A auditoria nativa atribui o acesso a essa credencial — não à pessoa ou ao agente que realmente o fez.
- Os investigadores precisam de avançar depressa. Querem experimentar hoje um novo agente contra dados quase-reais, não abrir um ticket e esperar. Se a governação for uma barreira que têm de implorar para ultrapassar, contornam-na.
Esta é a mesma forma com que o mercado mais alargado se está a deparar. Das organizações que sofreram uma violação relacionada com IA, cerca de 97% não tinham controlos de acesso de IA adequados (IBM Cost of a Data Breach 2025, Ponemon), e a Gartner espera que mais de 40% dos projetos de IA agêntica sejam cancelados até ao final de 2027 — a dívida de governação é grande parte da razão. A versão de campus é mais barata de corrigir cedo, enquanto os agentes são poucos e o raio de impacto é pequeno.
Como a Olivares AI ajuda
A Olivares AI é uma plataforma aberta e self-hostable que descobre agentes de IA na sua infraestrutura, mapeia o que cada um pode ler e escrever, e permite-lhe governar e auditar esse acesso. É read-first: observa e regista fora de banda antes de barrar o que quer que seja, e é deny-closed onde efetivamente barra. Para um campus, isso significa que pode começar por ver a verdade — e só depois decidir o que aplicar.
Aplicar a política de utilização aceitável, deny-closed
A camada de governação transforma a AUP numa política que produz uma decisão. O seu motor ABAC corre depois do acesso baseado em papéis e só pode restringir ainda mais: nega quando uma regra de negação corresponde, caso contrário a decisão existente mantém-se, e uma política malformada falha fechada em vez de aberta. Assim, uma regra de “nenhum agente de IA pode escrever no sistema de notas” ou “os agentes de sandbox não podem alcançar o SIS” torna-se uma negação aplicada, não um memorando.
Seja preciso quanto ao que a v1 corresponde. As regras de negação assentam hoje no principal, na permissão/verbo e no recurso — os atributos que efetivamente chegam ao avaliador. As regras que se ramificam em função da sensibilidade do recurso (por exemplo, “qualquer coisa etiquetada como FERPA”) precisam de uma costura de atributos de recurso que é um seguimento documentado, ainda não disponibilizado. Onde precisar de um humano no circuito, a plataforma regista um pedido de aprovação mais um rasto de decisões apenas-acrescentável, para que “quem aprovou este agente alcançar aquele conjunto de dados” tenha resposta mais tarde.
Consulte /docs/concepts/governance para o modelo read-first, deny-closed e onde a atuação está ativa versus sob pedido.
Atribuir quem-fez-o-quê em contas partilhadas
Esta é a capacidade estruturante para o campus. O mapa de acessos regista, com níveis de confiança honestos, que agente lê ou escreve que recurso e se esse acesso é permitido ou apenas observado. A governação de identidade (/product/identity) liga um agente à identidade canónica que a sua credencial apresenta, para que um acesso possa ser atribuído com firmeza.
A regra da honestidade importa aqui mais do que em qualquer outro lado: a atribuição só é firme quando uma identidade por agente ou por sessão é propagada para o acesso. Quando vários agentes correm como uma única conta de laboratório partilhada por trás de um pool, a atribuição colapsa para essa identidade única — e o produto di-lo, expondo a ligação partilhada como um achado de governação em vez de adivinhar uma pessoa. Uma identidade ligada a mais do que um agente é sinalizada, não disfarçada. O remédio é operacional: propague identidade por agente (por exemplo, para o nome de aplicação da ligação) e a atribuição ganha nitidez. Não vamos imprimir um nome que os sinais não conseguem sustentar.
Sandboxes governadas para investigadores
Os investigadores obtêm execução isolada e efémera de cenários de agentes contra recursos simulados — não produção. O executor de sandbox por omissão é isolado por construção: não detém qualquer handle para o seu armazenamento, rede ou segredos, e um passo que peça um recurso que o cenário não simulou devolve um marcador determinístico de mock-miss em vez de alcançar algo real. As execuções são efémeras; cada uma regista o executor real e se foi isolado, pelo que um backend degradado fica visível, nunca oculto. Um isolamento mais forte ao nível do SO (um contentor reforçado ou uma microVM) é um backend conectável que o operador self-host integra.
Isto dá a um laboratório um lugar seguro para experimentar um novo agente antes de este sequer tocar em dados reais — é assim que mantém investigadores em ritmo acelerado dentro da governação em vez de a contornarem. Para agentes que de facto governam sistemas reais, uma bateria de red-team defensiva, sujeita a consentimento (injeção de prompt, jailbreak, exfiltração), pode sondar a resistência de um agente, pontuada face ao OWASP Top 10 para Aplicações Agênticas. Corre apenas contra agentes que possui e autorizou — é um conjunto de testes, não uma ferramenta ofensiva.
Evidências para integridade da investigação e auditorias
As avaliações pontuam saídas de agentes candidatos face a suites golden versionadas — úteis quando um grupo de investigação precisa de um registo reproduzível de que um agente cumpriu um critério, execução após execução. O juiz é honesto: se nenhum backend de pontuação estiver ligado, uma execução é registada como ignorada, nunca uma aprovação silenciosa, e as saídas em bruto nunca são persistidas — apenas um hash unidirecional e uma etiqueta higienizada. Consulte /product/evals.
Para a instituição, a camada de conformidade (/product/compliance) agrega o que a plataforma já observa e audita num pacote de evidências selado e apenas-acrescentável, ancorado a um livro-razão encadeado por hash. Um controlo com evidências de suporte é marcado como satisfeito; um sem elas é marcado como lacuna, nunca uma aprovação falsificada. Isto é um mapeamento técnico para enquadramentos como o Regulamento da IA da UE e a ISO/IEC 42001 — não é aconselhamento jurídico e o produto não reivindica certificação.
O que isto é — e não é
- É uma camada aberta e self-hostable de governação e observação para IA na sua infraestrutura. O control plane pode correr offline / air-gapped no seu próprio hardware, pelo que os dados de atribuição e de política nunca saem do campus.
- É read-first e deny-closed. Observa e governa de forma alargada; não atua de forma alargada. Onde pode tomar uma ação, essa superfície está ativa, sob pedido ou é uma costura declarada — e o catálogo de módulos assinala qual.
- É pré-1.0. O catálogo tem 23 módulos com cerca de 20 ligados; algumas das capacidades acima estão presentes, outras são sob pedido, outras são seguimentos documentados. Indicamos qual.
- Não executa os seus modelos, e não é inferência air-gapped. O air gap é o control plane. Apenas os modelos self-hosted (vLLM, Ollama) correm offline; modelos alojados como o Claude não.
- Não é uma certificação. Sem certificação SOC 2 / ISO / Regulamento da IA da UE — o mapeamento de conformidade está “concebido para” esses enquadramentos e produz evidências, não um selo. Consulte /security para a postura e /docs/concepts/governance para o modelo de governação.
A adoção é generalizada; o que fica para trás é a supervisão (EDUCAUSE, 2025). O ponto de partida honesto é ver o que a sua IA já toca, decidir o que pode fazer e prová-lo — por essa ordem.