Agentes de AI governados de vários fornecedores — cada chamada autorizada e registada como evidência

O problema

Os agentes de AI de diferentes fornecedores chegam às operações um a um: um agente de assurance de um fornecedor, um agente de rede de outro, um assistente de ticketing de um terceiro. Cada um precisa de acesso aos sistemas, e o mais simples é atribuir-lhe direitos permanentes. Depois, ninguém consegue dizer que agente fez o quê, com que autoridade e porquê.

O que muda

1. Cada agente é registado com um responsável, uma versão e as funções que pode executar.
2. Uma avaria atravessa domínios; o agente de assurance encontra os agentes responsáveis pela rede e pelo OSS pela finalidade, e não por um endereço fixo no código.
3. Cada chamada entre agentes passa pelo Trusted Gateway, que a autoriza para essa finalidade e protege contra comandos em texto livre e injeção de dados.
4. As ações que o operador marca como sensíveis aguardam a aprovação de uma pessoa; a aprovação fica registada como evidência e o gateway autoriza apenas essa ação.
5. Cada chamada autorizada fica registada como evidência para auditoria.

O que vale

• Agentes de fornecedores diferentes trabalham em conjunto sem acesso permanente aos sistemas do operador.
• As equipas de segurança e auditoria veem quem fez o quê e com que autoridade.
• Os agentes são acrescentados um a um, sem reconstruir o stack de operações.
• A auditoria por domínio do TM Forum eTOM — Assurance, Fulfillment, Billing — é uma única consulta: cada dispatch transporta o seu processo eTOM.

O que a MEF.DEV traz

Agent Fabric-T com o Trusted Gateway como policy enforcement point, e Knowledge Graph, que pode fornecer aos agentes relações e regras a partir dos dados do próprio operador, com a fonte de cada facto (funciona no Product Offering AI para pacotes tarifários do WideCoup Convergent BSS; o modelo de rede é uma abordagem que propomos, não um conjunto de dados pronto). A aprovação humana de ações sensíveis faz parte dos Enterprise Modules.