Governança de IA precisa de arquitetura, não de mais uma lista de verificação

A maior parte da governança de IA começa perto do fim do sistema. Uma política é redigida, um registro de riscos é aberto, um comitê se reúne, e uma lista de verificação anota o que o sistema deveria fazer. Cada um desses artefatos tem sua função. Nenhum deles responde à pergunta que a arquitetura, cedo ou tarde, precisa responder: que propriedade do sistema torna verdadeira a afirmação de governança?

Uma política pode dizer que resultados incertos passam por revisão humana. Em algum lugar do código, algo decide o que conta como incerto, e outra coisa decide se um resultado incerto pode seguir adiante mesmo assim. Se essas decisões não forem projetadas, elas existem do mesmo jeito; só são tomadas por acidente. A governança passa a ser mais do que documentação quando a arquitetura consegue impô-la.

Três afirmações aparecem em quase todo documento de governança de IA.

"Pessoas devem revisar resultados incertos." Como política, é uma intenção. Como arquitetura, exige um lugar onde a incerteza esteja representada de forma explícita, uma fronteira que resultados incertos não possam atravessar, uma pessoa definida que decida e um registro dessa decisão que continue preso ao resultado. Sem a fronteira, a revisão é uma cortesia que a esteira concede quando não está ocupada.

"A rastreabilidade é mantida." Como política, isso costuma significar que existem logs. Como arquitetura, significa que o sistema preserva as relações necessárias para reconstruir como uma saída específica passou a existir: em que evidência ela se apoia, que passos a tocaram, que decisões foram tomadas sobre ela e por quem. Logs que nunca foram projetados para ser reunidos de novo são armazenamento, não rastreabilidade.

"O modelo não pode fazer X." Como política, é um pedido dirigido a um componente probabilístico. Como arquitetura, é uma fronteira determinística que não depende da colaboração do modelo: X é inalcançável a partir de onde o modelo está, ou um componente capaz de recusar X faz essa verificação. Uma regra dirigida a um modelo é uma esperança. Uma fronteira em volta de um modelo é uma restrição.

Uma afirmação em um documento pode ser verdadeira ou falsa sobre um sistema, e ler o documento não diz qual das duas. Uma restrição na arquitetura pode ser inspecionada, testada e, quando se rompe, notada.

O COADF, Compliance-Oriented AI Development Framework, é um framework de desenvolvimento documentado publicamente para sistemas de IA que precisam se sustentar diante da regulação. Ele nasceu do trabalho de arquitetura do projeto de pesquisa e desenvolvimento AnyLAI e de sua demonstração de passaportes de produto, o AnyDPP, mas seu propósito vai além de um produto, de uma regulação ou de uma implementação específicos.

Ele enuncia oito princípios de arquitetura, cada um preso à obrigação para a qual foi escrito, com modelos de governança, entre eles uma escada de autonomia para agentes de IA que escrevem código de produção, e um modelo legível por máquina para relatar quais controles um projeto de fato executa. Seu objeto são as fronteiras entre processamento determinístico, IA probabilística, evidência, confiança, revisão humana, regras, rastreabilidade, normas externas e aquilo que o sistema publica.

O nome descreve uma orientação, não um resultado. O método de desenvolvimento é orientado para os requisitos regulatórios; o nome nunca afirma que um sistema construído com ele os cumpre.

Cada princípio responde a um modo específico pelo qual sistemas de IA deixam de ser governáveis.

P-1 · Primeiro determinístico, o probabilístico em quarentena. Tudo o que chega a uma pessoa, a um documento ou a outro sistema é determinístico por padrão. Um componente probabilístico fica restrito a uma tarefa delimitada e devolve um valor, uma confiança e o método pelo qual o valor foi extraído, nunca um valor nu, porque um valor nu não pode ser barrado, declarado nem revisado.

P-2 · Saída controlada por confiança. A confiança se prende a um único atributo, não a um documento inteiro, porque uma só nota para um arquivo esconde qual fato dentro dele está fracamente evidenciado. Confiança baixa nunca chega a uma saída publicada. Sem evidência não há valor: nem um valor padrão, nem uma estimativa.

P-3 · Revisão humana por arquitetura. A revisão é disparada pela confiança, não por um calendário. Quem revisa vê um fato ao lado do trecho da fonte de onde ele veio e decide sobre esse fato; um valor rejeitado deixa o atributo vazio em vez de abrir espaço para um segundo palpite.

P-4 · Um rastro, de ponta a ponta. Um identificador, criado quando um documento é recebido, acompanha cada passo de processamento, cada avaliação de confiança e cada decisão humana até a saída publicada, em uma trilha à qual só se acrescenta.

P-5 · Declaração da extração automática. Uma saída com dados extraídos por máquina diz isso de forma visível, na própria saída, e nomeia os atributos em questão.

P-6 · O sistema de fences. Uma barreira que vive em um documento é um conselho. Uma barreira que roda na esteira e bloqueia uma entrega é um fence.

P-7 · Isolamento das dependências de normas. Sistemas de classificação, bases terminológicas e serviços externos de validação vivem em adaptadores fora do modelo de dados central. Um serviço externo pode elevar a confiança. Nenhum deles pode bloquear uma saída.

P-8 · Regras como dados, com autonomia graduada. As regras com que uma decisão é medida são dados versionados, o motor não muda quando uma regra muda, e cada decisão fica presa à versão de regras que a produziu. O quanto o sistema pode fazer sem uma pessoa é definido nessas regras, nunca acima do teto que a lei fixa.

Um a um, vários desses princípios parecem higiene de engenharia comum. Juntos, formam uma disciplina em que cada princípio cobre uma fraqueza que os outros deixariam aberta. Confiança sem rastro não pode ser auditada; um rastro sem barreira registra fielmente valores que ninguém revisou; uma barreira sem declaração esconde o que a máquina contribuiu. Nada disso sobrevive à próxima refatoração se o build não perceber quando algo se rompe.

Nada disso é um argumento contra aprendizado de máquina. Componentes probabilísticos são valiosos onde é preciso interpretar: ler um documento não estruturado, reconhecer uma entidade em um texto com formato irregular, classificar o que nenhuma regra previu. Componentes determinísticos são valiosos onde importam a repetibilidade, a imposição de fronteiras e a validação reproduzível. O erro está em deixar implícita a divisão de responsabilidades entre os dois.

Para cada caminho pelo sistema, uma arquitetura que leva a fronteira a sério consegue dizer qual componente pode inferir, qual decide, qual verifica, qual pode bloquear e que estado ou que saída se torna visível do lado de fora. Quando essas respostas vivem no código e não em um diagrama, quem revisa pode verificá-las, e uma mudança que desloca uma decisão para o outro lado da fronteira aparece na revisão.

Um valor de confiança descreve com que força algo está sustentado. Ele não torna nada verdadeiro. Um modelo muito confiante sobre um valor lido do documento errado fez uma afirmação precisa sobre a coisa errada.

A consequência arquitetural é que a confiança deveria mudar o que o sistema pode fazer, não só o que ele exibe. No COADF, a confiança pertence a um atributo e à evidência por trás dele, e confiança baixa vira uma pergunta para uma pessoa em vez de um valor publicado. O framework também trata um fato como portador de várias leituras ao mesmo tempo, por exemplo se a fonte é autêntica e o que ela de fato cobre, e nunca as funde em um único número. Uma nota em um painel informa. Uma nota que decide para onde um valor pode ir governa.

"Há um humano no circuito" é a forma mais fraca de uma afirmação de supervisão, porque deixa em aberto todas as perguntas que importam. O Regulamento de IA da UE coloca o requisito no próprio projeto do sistema: o artigo 14 exige que sistemas de IA de alto risco sejam concebidos e desenvolvidos de modo que pessoas naturais possam supervisioná-los de forma eficaz durante o período em que estão em uso.

Do ponto de vista da arquitetura, a supervisão precisa responder a quatro perguntas. O que dispara a necessidade de uma pessoa? O que essa pessoa decide: um caso inteiro, ou um fato diante de sua fonte? O que não pode seguir até que a decisão exista? E como a decisão, com quem a tomou e por quê, passa a fazer parte do mesmo rastro que o valor a que se refere? Uma etapa de revisão que a esteira pode pular sob carga não é supervisão. É uma fila.

A rastreabilidade costuma ser auditada como a existência de logs. Um teste mais útil é saber se uma única saída publicada pode ser seguida de volta: do resultado visível do lado de fora à decisão que o liberou, ao processamento que o produziu e à evidência em que ele se apoia. Evidência, processamento, decisão, resultado. Se algum elo desse caminho precisa ser reconstruído no palpite, o sistema não é rastreável, por mais que registre.

É por isso que o COADF trata o rastro como arquitetura, e não como operação: um identificador da entrada até a saída, uma trilha à qual se acrescenta e que nunca é reescrita, e uma cadeia que se exporta em uma forma que alguém que não construiu o sistema consegue ler. O artigo 12 do Regulamento de IA da UE trata a manutenção de registros da mesma forma, como algo que um sistema de alto risco precisa permitir tecnicamente.

Uma regra de governança que nada verifica se degrada na velocidade do código. Algumas regras só podem ser julgadas por pessoas. Muitas podem ser verificadas pelo build: uma dependência que não pode existir entre duas camadas, uma formulação que uma superfície pública nunca pode usar, uma entrega que não pode avançar enquanto uma verificação obrigatória falha. O COADF trata essas regras como condições diante das quais um build ou uma entrega devem poder falhar, e organiza seus fences em dados, arquitetura, texto e processo.

Um fence também precisa mostrar que funciona. O COADF chama essa prática de prova de dentes: planta-se o defeito real no arquivo real, o fence dispara, e a plantação é removida. Um fence que ninguém jamais viu falhar é um comentário com um executor de testes ao lado. Os relatórios seguem a mesma regra: um controle só conta como imposto quando sua evidência rodou em uma execução identificada e teve sucesso.

A regulação dá forma a requisitos; ela não é um projeto. Textos legais são alterados, e normas técnicas são revisadas em ciclos próprios. No Regulamento de Ecodesign para Produtos Sustentáveis, o que um Passaporte Digital de Produto precisa conter é definido por atos delegados, grupo de produtos por grupo de produtos. Um dicionário semântico como o ECLASS, ou um modelo de gêmeo digital como a Asset Administration Shell, segue seu próprio calendário de versões.

Um sistema que grava esse vocabulário na lógica central fica frágil exatamente onde a regulação se move. O COADF mantém as normas externas em adaptadores que podem somar confiança mas não decidir, e as regras em dados versionados, de modo que uma mudança de regra deixa o motor intacto e as decisões anteriores continuam nomeando a versão de regras sob a qual foram tomadas. Ligar um princípio ao artigo a que ele responde explica por que o princípio existe. Se esse artigo se aplica a um sistema específico continua sendo uma questão jurídica.

O COADF é um framework de desenvolvimento documentado publicamente. Não é uma certificação, não é uma norma de auditoria e não é um esquema de avaliação da conformidade. Não é uma aprovação regulatória, nem uma garantia de cumprimento, nem aconselhamento jurídico. Nenhuma autoridade o avaliou, auditou ou endossou. Aqui ninguém emite, concede nem retira nada, e aplicá-lo não produz selo nem marca de espécie alguma.

O trabalho de arquitetura fica mais útil quando suas premissas e fronteiras podem ser inspecionadas. Um framework privado só pode ser descrito; um framework publicado pode ser lido, comparado e contestado.

A publicação dá às ideias um vocabulário estável, para que uma conversa sobre barreiras de confiança ou fences não precise começar redefinindo os termos. Ela torna as decisões de projeto inspecionáveis, inclusive as que podem se revelar erradas. Dá a outros arquitetos algo concreto para questionar, e às implementações uma referência a partir da qual explicar onde concordam e onde divergem de propósito. E deixa um registro técnico público e datado do que foi afirmado, e de quando.

Um framework de arquitetura público não precisa publicar cada mecanismo de implementação. O COADF documenta os princípios e as práticas destinados à inspeção pública, enquanto determinados mecanismos específicos de implementação ficam fora da edição pública. Suas páginas dizem, princípio por princípio, que partes são enunciadas por inteiro e quais apenas como princípio, de modo que a própria fronteira fica visível mesmo onde o detalhe não fica.

O COADF versão 2.2 está documentado publicamente em inglês, alemão, espanhol, francês e português do Brasil: os oito princípios, os modelos de governança, o relatório de controles e um mapa regulatório lido nas fontes primárias, além do framework completo em edições para download. A resposta mais útil a um framework de arquitetura não é a concordância. É uma leitura atenta e uma objeção específica.