Compliance como política executável

A maioria das organizações trata o compliance como um documento. Escreve-se uma política, revê-se, assina-se e arquiva-se. O sistema é construído à parte, e algures pelo meio o dono de um controlo atesta que os dois estão alinhados. Para software determinístico, atualizado num calendário de entregas, o arranjo até funciona.

Só que um agente não lê o seu PDF de política e não faz uma pausa para a sua revisão trimestral de controlos. Atua sobre contexto em tempo real, de forma probabilística, potencialmente milhares de vezes por dia, e pode comportar-se de outra maneira depois de uma atualização noturna do modelo para a qual ninguém abriu um pedido de alteração. Um regime de compliance que vive num documento ao lado do sistema não consegue governar um sistema que se move a essa velocidade. A obrigação tem de correr dentro do sistema, ou não corre de todo.

É esta a viragem que o EU AI Act, a DORA e o RGPD impõem discretamente às empresas reguladas: o compliance deixa de ser um PDF e passa a ser código que executa, emite veredictos que o fluxo tem de obedecer e deixa evidência que um regulador consegue reconstruir.

A política é código de que a equipa de compliance é dona

O instinto é os engenheiros embeberem a lógica de compliance no código do agente. É o dono errado. As pessoas que respondem perante o regulador são a sua equipa de compliance, por isso têm de ser donas das regras e de o conseguir provar.

Na prática, isso significa política como código: um ponto de decisão de políticas, um motor OPA ou Rego, que a sua equipa de compliance versiona, testa, assina criptograficamente e aprova antes do deployment. O mecanismo está limpamente separado da decisão. Os engenheiros constroem a maquinaria que pergunta ao motor de políticas "isto pode avançar?". A equipa de compliance é dona das regras que respondem. Nenhum dos lados consegue passar por cima do outro em silêncio, e a própria separação é auditável.

O dividendo é que uma regra de compliance passa a ser um artefacto testável e versionado, com assinatura e dono, e não uma interpretação na cabeça de alguém ou enterrada no código da aplicação. Quando um regulador pergunta "quem decidiu que isto era permitido, e quando?", a resposta é uma versão assinada da política, não uma reunião de que ninguém fez ata.

As políticas também expiram por tempo de vida. Cada regra tem de ser revista, reaprovada e reassinada no prazo, o que torna a desatualização visível e governável em vez de silenciosa. Uma regra que envelheceu discretamente até deixar de fazer sentido deixa de ser risco invisível e passa a ser um item sinalizado que alguém tem de voltar a assinar.

Cada gate resolve-se num de quatro veredictos

Para o fluxo obedecer à política, a política tem de falar em veredictos sobre os quais o fluxo consegue agir. Cada gate de compliance resolve-se num de quatro.

• ALLOW. Todas as condições satisfeitas. O agente avança sem intervenção humana.
• ALLOW-WITH-CONDITIONS. Parcialmente satisfeitas. O agente avança sob restrições documentadas, como registo adicional, um limite de âmbito ou uma marca de revisão.
• DENY. Uma condição rígida falha. A transação é bloqueada, sem caminho de exceção.
• REQUIRE-HUMAN. A decisão tem peso regulatório que não pode ser delegado. O agente apenas analisa; decide uma pessoa.

Os quatro veredictos são o que converte "o sistema está conforme" de uma garantia num mecanismo. Uma garantia não se testa. Um veredicto sim: consegue apontar para qualquer transação e ver que veredicto disparou, sob que versão da política, e porquê.

REQUIRE-HUMAN é o veredicto que sustenta o trabalho regulado

Dos quatro, um carrega o peso do caso de uso regulado, e vale a pena ligá-lo diretamente à lei.

Ao abrigo do artigo 22.º do RGPD, uma pessoa tem o direito de não ficar sujeita a uma decisão baseada unicamente em tratamento automatizado quando esta produza efeitos jurídicos ou a afete significativamente. A decisão de crédito, a recusa de um sinistro, a aprovação de compliance: não podem ser inteiramente delegadas numa máquina. Nesta arquitetura, resolvem-se em REQUIRE-HUMAN por política. O agente prepara, verifica e orquestra. A decisão regulada fica com uma pessoa.

É fácil ler isto como uma limitação aparafusada para satisfazer um jurista. É o contrário. É o desenho que torna todo o sistema lícito. Um agente que tomasse ele próprio a decisão com consequência seria mais rápido e ilegal. Um agente que faz todo o trabalho até à decisão e entrega a uma pessoa um dossiê completo e evidenciado é rápido e lícito. REQUIRE-HUMAN não é a fraqueza do agente. É a fronteira que torna a autonomia defensável em todo o resto.

Sem evidência, não há decisão

Uma política que corre é apenas metade da obrigação. A outra metade é provar, depois do facto, o que aconteceu. Face às expectativas de registo do EU AI Act (artigo 12.º), tem de conseguir reconstruir porque é que uma decisão foi tomada.

Por isso cada decisão de um agente deixa um trilho de evidências append-only, encadeado por hash, em armazenamento de escrita única, escrito antes de a decisão se concretizar. A ordem importa: o registo é escrito primeiro, e só depois a decisão produz efeito. Se a evidência não puder ser escrita, a decisão não acontece. O sistema falha fechado.

Essa única regra, sem evidência não há decisão, é o que torna um agente inspecionável em vez de uma caixa negra. O registo de qualquer decisão guarda quem atuou, sob que autoridade, sobre que dados, contra que versão assinada da política, a que nível de autonomia, e com que evidência. O encadeamento por hash significa que o trilho não pode ser discretamente editado depois: adulterar parte a cadeia. Quando os seus auditores apontam para uma transação, entrega-lhes um registo, não uma reconstituição.

É também esta a resposta à pergunta que um comité de risco faz mesmo: como aprovamos uma caixa negra? A resposta honesta é que, para o comité, não é uma caixa negra. É um sistema em que cada decisão chega já evidenciada, contra uma política que a equipa de compliance assinou, com as decisões com consequência reservadas a pessoas. O comité aprova um controlo documentado e testável, não uma promessa.

Construído para o horizonte regulatório, não só para a regra de hoje

Os regulamentos não estão parados, e esse é o argumento final para tornar o compliance executável em vez de documental.

O artigo 4.º do EU AI Act já está em vigor: desde fevereiro de 2025, as organizações que implementam IA têm de assegurar literacia em IA suficiente nos seus operadores, e as autoridades nacionais começaram a supervisionar isso a partir de agosto de 2025. As obrigações de alto risco, as regras de resiliência operacional da DORA, o direito a explicação e os requisitos de residência de dados vão chegando nos seus próprios calendários. Um regime de compliance codificado como política assinada, versionada e com prazo adapta-se à medida que as regras evoluem, porque mudar um controlo é mudar um artefacto de política, e não reconstruir o sistema. Um regime de compliance que vive em PDFs adapta-se à velocidade de um ciclo de revisão documental, ou seja, devagar demais.

Por isso, o reenquadramento a levar à próxima auditoria não é "estamos conformes com a regra atual?". É conseguimos executar as nossas obrigações como política assinada e testável, provar cada decisão com evidência escrita antes de se concretizar, e mudar um controlo sem reconstruir o sistema? Se o compliance ainda vive num documento ao lado do sistema, está a atestar um alinhamento que não consegue demonstrar quando lhe pedirem.

Se quiser ver uma obrigação transformada num controlo a correr sobre um processo real, marque uma reunião.