APRENDER. PRATICAR. EVOLUIR.Inventariar a solução, não apenas o modelo
Um assistente empresarial combina mais do que um modelo de linguagem. No exemplo fictício, lê runbooks, pesquisa um índice, prepara tickets e consulta regras de aprovação. O inventário deve identificar essas componentes, versões, dados, responsáveis e capacidades. Uma alteração ao conector pode ampliar a autoridade sem mudar o nome do modelo ou o aspeto da interface. A governação deve acompanhar o sistema integrado durante aquisição, configuração, utilização, mudança e retirada. Define primeiro o caso de uso autorizado: ajudar a redigir uma proposta em teste não é o mesmo que executar uma mudança em produção. Identifica benefícios esperados, pessoas afetadas, consequências de erro, condições de paragem e quem decide sobre alterações de âmbito. Uma política sobre IA deve ser traduzida em requisitos observáveis, incluindo dados permitidos, permissões, revisão humana e comunicação de limitações. O AI RMF oferece funções de governação, contextualização, medição e gestão para organizar este trabalho; não é uma certificação automática da solução. No plano do projeto, associa cada risco a uma decisão e à evidência necessária. Mantém uma distinção entre o que foi ensaiado localmente, o que foi declarado pelo fornecedor e o que ainda precisa de validação no ambiente alvo. Esta distinção evita que uma demonstração convincente seja confundida com prontidão operacional.
Separar ameaças para escolher controlos
As ameaças à IA atuam em momentos e objetos diferentes. Alterar exemplos antes do ajuste é envenenamento dos dados de treino; tentar influenciar uma execução através de texto recebido é outra via. Inferir atributos sensíveis associados aos dados é um objetivo de inversão, enquanto construir uma réplica funcional procura extrair capacidades do modelo. Nenhuma destas descrições deve ser usada como rótulo automático sem evidência. Regista o que foi observado, onde ocorreu a alteração e que objetivo o exercício está a investigar. Numa aplicação que pesquisa runbooks, o índice também é um depósito de dados. Uma classificação antiga pode permitir recuperar um fragmento depois de o documento original se tornar restrito. A política atual de acesso deve acompanhar a recuperação e o tratamento de cópias. Uma instrução maliciosa num documento não deve atribuir autoridade a uma ferramenta. Filtros de entrada podem reduzir exposição em casos testados, mas dez bloqueios não demonstram que todas as manipulações futuras falharão. Controlos de saída, permissões e validação dos destinos continuam necessários. No nosso modelo Python, texto é apenas uma string sem intérprete: o facto de não alterar permissões demonstra separação local entre dados e regras, não resistência de um LLM a prompt injection. Esta limitação deve acompanhar qualquer apresentação dos resultados.
Autoridade e aprovação ligadas ao conteúdo
O caso de uso do laboratório só permite criar um rascunho de mudança em teste. O plano inclui ticket, tenant, ambiente, ferramenta, versão do modelo, classificação de dados e unidades de custo. A aprovação guarda um resumo canónico desses parâmetros e a identidade do aprovador. Antes de registar o rascunho sintético, o programa compara o plano, verifica o prazo, a autoridade atual e a versão da política. Mudar T7 para T9 invalida a correspondência; mudar o ambiente para produção também viola o âmbito permitido. A ordem dos campos JSON não altera o resumo, mas uma alteração de argumento altera-o. Isto ensina por que uma frase como «aprovado para hoje» é insuficiente para ações diferentes. A aprovação deve referir a operação concreta, e o destino deve impor a autorização independentemente de uma resposta gerada. No modelo, a aprovação é usada uma única vez e a retirada do aprovador impede nova execução. São verificações locais sobre identidades fornecidas pela fixture. Não existe assinatura criptográfica da aprovação, autenticação corporativa ou armazenamento durável. Um processo reiniciado perderia o estado, e não foi ensaiada concorrência. Para um conector real, a equipa teria de definir uma implementação que preserve estas propriedades, incluindo atomicidade entre verificação e execução, e testá-la no contexto autorizado.
Executar e interpretar o modelo original
O ficheiro run.py executa aritmética de risco e uma máquina de decisão local, sem rede ou serviços externos. Corre-o com Python e um caminho de saída para evidence.json; repete com outro nome para conservar as duas observações. As 34 verificações incluem benefício esperado, probabilidade condicional, alterações de ticket e ambiente, classificação restrita, versão nova, aprovação ausente, revogação e expiração. O relógio lógico começa em 1000 e a aprovação expira em 1100: em 1099 pode ser válida; em 1100 já não é. Estes valores são dados do exercício e não segundos medidos num serviço. O orçamento usa unidades abstratas: há 80 consumidas e limite de 100. Um plano aprovado que pede 20 chega exatamente ao limite e passa; um plano aprovado que pede 21 é recusado sem alterar rascunhos, consumo ou aprovações utilizadas. A classificação dos dados e as identidades são entradas confiadas à fixture, não resultados de inspeção automática. O relatório conserva versão de Python, hash do script e resultado de cada verificação. As duas execuções observadas passaram 34 verificações cada. Isso demonstra a implementação deste modelo e os casos ensaiados; não valida preços de fornecedor, desempenho de IA, política jurídica, integração empresarial ou proteção contra ataques desconhecidos.
Avaliação representativa e revisão humana praticável
Um resultado obtido nos mesmos exemplos usados para ajustar o sistema pode sobrestimar a capacidade de responder a incidentes novos. Prepara casos separados, representativos do contexto APS, incluindo instruções incompletas, documentos desatualizados, fontes contraditórias e situações em que a resposta correta é pedir investigação adicional. Define critérios antes de avaliar. Uma explicação fluente ou uma citação com título plausível não prova correção; o exercício exige comparar a recomendação com logs e documentos realmente existentes. Regista também falhas e diferenças entre versões, em vez de conservar apenas demonstrações favoráveis. A revisão humana precisa de condições reais. Se o piloto propõe quatrocentas ações por hora e o turno só consegue analisar trinta com qualidade, um botão de aprovação não resolve a diferença. Considera volume, contexto apresentado, tempo, possibilidade de recusa e tratamento de filas. Aprovação automática por silêncio altera o controlo e deve ser avaliada como tal. O modelo local recusa propostas quando a taxa declarada ultrapassa a capacidade declarada; não mede a produtividade de pessoas reais. No projeto, um ensaio com utilizadores e tarefas autorizadas teria de demonstrar que o processo é viável. Mantém os limites de generalização visíveis e não converte uma taxa observada numa amostra pequena numa promessa universal de eficácia.
Mudança, suspensão e retirada controladas
A passagem a RUN deve definir quem acompanha o comportamento e quem pode suspender capacidades. No exemplo fictício, um limite do piloto é ultrapassado após a atualização do modelo. Manter a mesma interface não prova continuidade do comportamento. Aciona o processo de suspensão acordado, conserva a evidência e reavalia antes de retomar. Aumentar o limite para que o resultado passe pode ser uma nova decisão de risco, mas não deve apagar a falha nem ser apresentado como cumprimento ininterrupto. Um rollback também precisa de compatibilidade com conectores, dados e políticas atuais. Na retirada, desativar a página não elimina o índice, os tokens, os jobs ou as cópias de avaliação. Identifica os componentes remanescentes, revoga capacidades sem finalidade autorizada e aplica retenção ou exceções documentadas a cada cópia. Conserva evidência suficiente para reconstruir decisões sem guardar desnecessariamente documentos restritos nos logs. O laboratório regista apenas resumo do plano, resultado, motivos e relógio lógico; isso reduz o conteúdo persistido mas não constitui uma arquitetura de auditoria empresarial. Antes de encerrar o projeto, confirma contactos, critérios de incidente, reversão e responsabilidades de revisão. Os exemplos e modelos deste percurso são originais e fictícios: não representam procedimentos BNP Paribas nem atribuem uma certificação oficial ao participante.
python3 content/labs/securityx-governance-contracts/run.py --output /tmp/securityx-governance-evidence.json
python3 content/labs/securityx-governance-contracts/run.py --output /tmp/securityx-governance-evidence-repeat.jsonUm plano aprovado para T7 em teste não autoriza T9 em produção; a alteração deve ser recusada antes de qualquer efeito.
Armadilhas comuns
Prompt como controlo de autorização; título de fonte como prova; botão como revisão efetiva; modelo local como execução de IA real.
Tópicos relacionados: Governance, risco e exceções · Fornecedores, dados e ameaças
Uma resposta gerada pode propor; a autoridade, a evidência e a aceitação pertencem a processos verificáveis.
Referência: Artificial Intelligence Risk Management Framework · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17