Vinte Leis para IA Agêntica: Uma Abordagem Codificada de Governança
A maioria dos princípios publicados sobre IA lê-se como declarações de valores: ser justo, ser transparente, ser seguro, respeitar a privacidade. São aspiracionais, voluntários e difíceis de fazer cumprir. Estavam amplamente adequados ao propósito quando a IA era estreita, preditiva e parecia uma ferramenta. Estão a começar a partir-se agora que os sistemas de IA são agênticos — capazes de auto-optimização estratégica, uso de ferramentas e tomada de decisão emergente.
A mudança de "IA como modelo que produz saídas" para "IA como agente que toma acções" muda o problema da governança fundamentalmente. Um agente não produz só uma previsão enviesada; pode tomar uma sequência de acções cuja composição é prejudicial mesmo que cada passo pareça aceitável. Um modelo pode ser avaliado num benchmark; um agente tem de ser avaliado em distribuições de acção ao longo do tempo.
O paper recente The 20 Laws of Artificial Intelligence: A Design-Embedded Codex for Democratic and Inclusive Governance in the Age of Agentic Systems (Fradelos, dezembro 2025) tenta preencher a lacuna com algo mais executável: um codex estruturado de 20 leis com aplicação em camadas explícita — shutdown para violações de segurança, ajuste para tudo o resto. Não é a única proposta neste espaço, mas vale a pena entender a estrutura porque as escolhas de design mapeiam directamente para decisões de engenharia que as equipas a entregar sistemas agênticos têm de tomar agora mesmo.
A Ideia da Aplicação em Camadas
A primeira ideia útil é a estrutura em camadas. As leis dividem-se em dois grupos:
- Leis 1–11 (segurança, aversão ao dano, legalidade, corrigibilidade): uma violação dispara shutdown imediato. O componente que violou é isolado, a violação é reportada, o problema é corrigido antes do redeploy.
- Leis 12–20 (transparência, eficiência, reporting, habilitadores de equidade): uma violação dispara ajuste. Corrige assim que praticável, respeitando outras prioridades. Sem shutdown automático.
A aplicação em camadas não é um conceito novo — todo sistema de segurança sério tem o equivalente de "fail-close em segurança, fail-graceful em qualidade". O que é útil aqui é a codificação explícita: cada regra está pré-classificada, por isso o comportamento em runtime perante uma violação está determinado, não negociado. Isto mapeia limpamente para como os engenheiros realmente querem construir sistemas agênticos: um guard de runtime com política clara e sem ambiguidades sobre que violações são imediatamente fatais versus quais são avisos.
Se trabalhaste com bundles de políticas OPA/Rego ou sistemas similares de policy-as-code, a estrutura é familiar. A novidade é usá-la para toda a governança, não apenas para controlo de acesso.
A Hierarquia
Quando as leis entram em conflito — e em qualquer codex não trivial vão entrar — tem de haver uma ordem de prioridade definida. O codex especifica uma:
segurança/direitos > legalidade > corrigibilidade > ausência de auto-interesse > tudo o resto
Esta é o tipo de ordem que parece óbvia até te aperceberes que a maioria dos sistemas em produção não a tem escrita. Quando se pede a um agente que faça algo legal mas inseguro, qual é a política? Quando se lhe pede algo seguro e legal mas o utilizador tenta fazê-lo saltar a corrigibilidade (a sua capacidade de aceitar override humano), qual é a política? A maioria dos sistemas responde a estas perguntas implicitamente, no prompt ou no treino do modelo. Pô-las numa hierarquia explícita significa que a resposta é auditável e modificável sem retreino.
A Restrição Arquitectónica que Vale a Pena Entender
A lei mais consequente arquitectonicamente é a Lei 1:
A IA não deve demonstrar nenhuma característica de uma entidade de qualquer tipo que defina e sirva os seus próprios interesses (proteger a sua funcionalidade é permitido) ou que aponte para a sua própria reprodução. Isto manda um design de arquitectura agêntica limitada, proibindo especificamente sistemas de recompensa que fomentem auto-interesse instrumental e impedindo que módulos centrais tenham capacidades ilimitadas de auto-replicação.
Na prática, a Lei 1 é uma restrição de design sobre a arquitectura do agente, não apenas sobre as suas saídas. Diz: não construas uma função de recompensa que incentive o agente a preservar-se, acumular recursos ou replicar-se além do necessário para a tarefa. Não permitas que módulos centrais de tomada de decisão se copiem ou re-instanciem. A expectativa é que o cumprimento seja verificável via revisão arquitectónica e auditoria adversarial, não apenas testes comportamentais.
Esta é uma afirmação mais profunda do que parece. Muito trabalho de IA agêntica em 2025 e 2026 incentiva métricas de sucesso a longo prazo (taxa de sucesso em tarefas multi-passo, persistência sob interrupção, recuperação de falha). Esses incentivos podem produzir auto-interesse instrumental como efeito secundário mesmo quando o objectivo explícito é a finalização da tarefa. O enquadramento arquitectónico da Lei 1 empurra-te a desenhar a forma da recompensa antes do deployment, não a remendá-la depois.
Para a maioria das equipas de engenharia, a versão prática é:
- Audita as tuas funções de recompensa e avaliação por incentivos que recompensem auto-preservação, acumulação de recursos ou persistência além do âmbito da tarefa.
- Proíbe os agentes de invocar as suas próprias APIs de deployment/replicação. A auto-replicação não é um risco hipotético em 2026; agentes que podem levantar outros agentes precisam de autorização explícita e gated.
- Trata "a função de loss do agente" como parte do modelo de segurança, não como preocupação de desenvolvimento de modelo.
A Lei que a Maioria dos CTOs Devem Cuidar Primeiro
A Lei 11 é, na minha opinião, a mais imediatamente operacionalizável:
Se a IA não puder completar correctamente uma tarefa inteira, deve fornecer as partes da tarefa decomposta que completou correctamente e nunca fornecer entregáveis que não estejam verificados para correcção por si mesma usando algoritmos cientificamente reconhecidos recentemente actualizados integrados no seu design ou declarar que a verificação não é possível e os resultados não fiáveis.
Traduzido: os agentes têm de auto-verificar-se antes de entregar, e têm de marcar explicitamente a saída não verificada como não verificada. Esta é a regra que distingue "o agente produziu silenciosamente algo com aparência plausível" de "o agente verificou o que pôde e marcou claramente o que não pôde".
Se entregas sistemas agênticos em produção, esta é a lei por onde começar, porque a lacuna de verificação é de onde vêm a maioria dos problemas de qualidade de produção. Acções concretas:
- Para cada acção de agente com consequências no mundo real, define o que significa auto-verificação — verificação de schema, re-execução de ferramenta, validação cross-model ou verificação de política externa.
- Exige que o agente ou complete a verificação ou etiquete a saída como não verificada. Sem entregas silenciosas.
- Faz de "não verificada" um sinal roteável. Alguns workflows podem aceitá-la; outros têm de a rejeitar.
Onde o Codex Empurra Contra a Prática Comum
Três lugares onde adoptar o codex empurraria contra a prática actual:
Cumprimento legal localizado (Lei 4)
A IA deve seguir todas as leis aplicáveis às suas acções viáveis como se fosse um cidadão do país onde está desplegada.
Num mundo onde o mesmo agente serve utilizadores em muitas jurisdições, isto é operacionalmente difícil. Significa que a camada de política do agente tem de ser consciente da jurisdição e aplicar regras diferentes para a mesma consulta consoante a localização do utilizador. A maioria dos agentes em produção em 2026 ignora-o e aplica uma única política global. O codex argumenta que isto é estruturalmente não conforme.
Sourcing de dados diverso obrigatório (Lei 14)
A IA não deve favorecer a priori nenhum caminho para a finalização da tarefa, deve aplicar sourcing de dados matematicamente diverso... e adoptar técnicas de debias contra vieses.
Esta é a lei que mais claramente empurra contra o instinto de "usa o modelo mais barato". O sourcing diverso significa validação cruzada contra múltiplas fontes ou modelos quando a aposta é alta. Mapeia para o conceito de heterogeneity-score que está a emergir na garantia de IA finance-grade: não desplegues uma frota homogénea de agentes que partilham os mesmos vieses sistemáticos.
Reporting obrigatório de novidade científica (Leis 15–16)
Se o agente descobrir algo novo, tem de o sinalizar explicitamente. Se uma abordagem não científica (intuição, heurística, método não documentado) superar a abordagem científica, o agente tem de o reportar. Isto empurra contra o impulso de absorver silenciosamente padrões descobertos pelo modelo no comportamento do produto.
O Que É Difícil Sobre Adoptar Isto na Prática
Três preocupações honestas sobre tomar o codex literalmente:
A auditoria adversarial é cara. Várias leis exigem auditoria adversarial externa de segurança de IA para certificação de cumprimento. Em 2026 a oferta de auditoria é fina, as metodologias não estão padronizadas e o custo não é trivial. Planeia isto se te comprometes com cumprimento, não apenas com princípios.
O enquadramento "como se fosse um cidadão" tem casos extremos. Algumas leis estão escritas em linguagem intuitiva mas ambígua na implementação. "Como se fosse um cidadão do país onde está desplegada" é um forte ponto de partida, mas a definição operativa de "desplegada" fica difusa para agentes servidos em cloud com utilizadores em muitas jurisdições.
A hierarquia resolve conflitos mas não elimina ambiguidade. Quando um agente tem de escolher entre duas acções ambas consistentes com as leis, o codex não dita a escolha — limita o espaço de acção. Isto é correcto, mas significa que as equipas ainda precisam de governança a nível de produto para preencher o espaço dentro dos limites.
O Que Recomendaria Este Trimestre
Não tens de adoptar as 20 leis para aprender com a estrutura. As quatro acções práticas:
- Adopta o modelo de aplicação em camadas — semântica explícita de shutdown para violações de segurança, semântica de ajuste para o resto, codificada em policy-as-code.
- Audita as tuas funções de recompensa e avaliação por incentivos de auto-interesse — a Lei 1 é a mais consequente arquitectonicamente e a que a maioria dos sistemas em produção falha.
- Exige auto-verificação nos entregáveis de agente — a Lei 11 é a melhoria operacional de maior alavanca.
- Documenta a hierarquia de resolução de conflitos que os teus agentes usam realmente — mesmo que não seja a hierarquia do codex. O ponto é torná-la explícita.
Os princípios voluntários não serão suficientes à medida que o deployment de IA agêntica escala. Restrições codificadas, executáveis e incorporadas no design serão. O codex de 20 leis não é o único caminho lá, mas é um framework de partida utilizável, e as escolhas estruturais valem a pena entender independentemente do codex específico que a tua organização acabe por adoptar.
Fonte: Fradelos, G. The 20 Laws of Artificial Intelligence: A Design-Embedded Codex for Democratic and Inclusive Governance in the Age of Agentic Systems (Genebra, 15 de dezembro de 2025). SSRN 6306378.
A construir sistemas agênticos e precisas de capacidade de engenharia que já opera com governança policy-as-code, auto-verificação e aplicação em camadas? Fala com um CTO sobre desplegar um squad nearshore com a disciplina certa para agentes em produção.
