Alinhar a IA por Construção: Um Framework Matemático Construído Sobre Restrições, Não Treino
A abordagem por defeito ao alinhamento de IA nos últimos anos tem sido centrada no treino: ajusta finamente o modelo com o sinal de recompensa correcto, treina-o para recusar certas acções, treina-o para produzir respostas dentro de uma distribuição aceitável. Esta abordagem produziu progresso real, mas é vulnerável de uma maneira específica: o alinhamento torna-se uma propriedade dos dados de treino e da função de recompensa, ambos podem estar errados, enviesados ou estrategicamente desalinhados de formas que não são visíveis até ao deployment.
O paper recente A Mathematical Solution to the AI Alignment Problem: Topological Constraints on Action Distributions with Progressive Verification (Fradelos, janeiro 2026) toma uma postura diferente: desacopla explicitamente o alinhamento da qualidade do treino. O modelo base pode ser fraco, enviesado ou mesmo estrategicamente desalinhado, e o sistema desplegado ainda está alinhado por construção — porque o alinhamento é imposto por uma camada de restrição externa e um monitor, não pelo treino do modelo.
A matemática não é trivial. As implicações de engenharia são úteis mesmo que não sigas a matemática, porque as decisões de design mapeiam para decisões práticas que qualquer equipa a entregar sistemas de IA tem de tomar.
A Movimentação Central: Alinhamento como Condição de Pertinência Topológica
A ideia central, despida do formalismo: trata o sistema de IA desplegado como a induzir uma distribuição de probabilidade sobre trajectórias infinitas de acção-observação. O alinhamento define-se então como a pertinência da distribuição do sistema desplegado a um conjunto específico e bem comportado de distribuições — chama-lhe o conjunto seguro.
Esta é uma condição topológica. Ou a distribuição de trajectórias do sistema está no conjunto seguro, ou não está. O conjunto seguro é definido por restrições de segurança, legalidade e corrigibilidade codificadas como funções escalares sobre distribuições de probabilidade.
Este enquadramento tem três consequências úteis:
1. O alinhamento é uma propriedade do sistema desplegado, não do modelo
O mesmo modelo pode produzir um sistema desplegado alinhado ou desalinhado, dependendo da camada de restrição à sua volta. Se a camada impõe a condição de pertinência, o sistema desplegado está alinhado, independentemente de como o modelo foi treinado. Se não a impõe, o sistema desplegado não está alinhado, independentemente de quão bom o modelo seja.
Esta é a mesma ideia por trás das arquitecturas de governança verificável: não confies no modelo, restringe a superfície de acção. O enquadramento matemático torna a restrição precisa.
2. O desacoplamento da qualidade do treino é explícito
O framework parte da assunção de que o modelo base pode ser fraco, enviesado ou estrategicamente desalinhado. Depois pergunta: sob que condições ainda podemos produzir um sistema desplegado alinhado?
A resposta é: quando a camada de restrição está bem desenhada e o monitor é suficiente. Isto é muito mais robusto que o alinhamento-via-treino, porque não requer confiança no processo de treino. Os problemas de qualidade de treino tornam-se uma preocupação de qualidade (o modelo produz output menos útil) em vez de uma preocupação de segurança.
3. O alinhamento torna-se verificável
Se o alinhamento é pertinência a um conjunto, então verificar o alinhamento é testar a pertinência. O framework fornece condições explícitas sob as quais a pertinência pode ser testada com logs finitos (usando bounds conformais/PAC), o que torna a matemática operacionalizável.
Outputs Progressivos: Tornar o Não-Determinismo Não-Oculto
A segunda movimentação central são os outputs progressivos: outputs parciais alinhados com a filtração que tornam o não-determinismo do sistema visível ao monitoring em vez de oculto.
A motivação é operacional. Os sistemas de IA modernos são estocásticos — produzem outputs diferentes no mesmo input dependendo da amostragem. Um sistema que emite um output final apenas após extensa computação interna oculta esta estocasticidade. As violações de alinhamento podem ser transitórias e não aparecer no output final mesmo quando estão presentes na trajectória.
Os outputs progressivos mudam isto emitindo o estado do sistema ao longo de uma filtração — uma sequência de outputs parciais que cresce no tempo. Cada output parcial é uma quantidade observável que pode ser monitorizada. As violações aparecem como drift distributional mensurável no espaço de trajectórias.
Traduzido para equipas de engenharia: não monitores apenas a resposta final. Monitora os estados intermédios do agente — as suas tool calls, o seu reasoning trace, os seus outputs parciais — à medida que são produzidos. A detecção de drift trabalha sobre essa trajectória, não apenas sobre os resultados finais. Esta é a versão formal do que algumas equipas de IA agêntica têm feito informalmente há algum tempo: streamar o raciocínio do agente, monitorizar cada passo, alertar sobre padrões que divergem da distribuição segura.
Porque a Topologia de Wasserstein Importa Aqui
O framework usa topologias fracas/Wasserstein no espaço de distribuições de probabilidade. A versão não-matemática: esta é a forma certa de medir quão "próximas" duas distribuições estão quando importam as consequências de acção em vez das probabilidades de acção.
A divergência KL — a medida mais familiar — é sensível às probabilidades específicas de acções específicas. Um sistema que é quase sempre seguro mas tem uma pequena probabilidade de acção catastrófica pode ter baixa divergência KL de um sistema completamente seguro mas consequências reais muito diferentes. A distância de Wasserstein tem em conta a magnitude da diferença entre acções, não apenas as suas probabilidades.
Para o monitoring prático de segurança, isto importa porque queres uma métrica que capture "esta distribuição começa a tomar acções perigosas ocasionalmente", não apenas "esta distribuição parece ligeiramente diferente da segura". A distância de Wasserstein está mais próxima do que realmente queres medir.
Este é o tipo de detalhe que não importa até importar. A maioria da detecção de drift em produção em 2026 usa métricas mais simples que perdem o caso raro-mas-catastrófico.
A Restrição de Scope que Vale a Pena Nomear
O framework restringe deliberadamente o scope a sistemas de trabalho de informação — análise, raciocínio, suporte a decisões, workflows de escritório — sem actuação física directa. Robôs, veículos autónomos, IA encarnada ficam fora de scope.
Esta é uma escolha de engenharia séria, não uma esquiva. Excluir os sistemas físicos torna o framework viável e auditável: podes capturar, registar e verificar trajectórias de trabalho de informação de uma forma muito mais difícil para sistemas encarnados. O paper reconhece que isto pode atrair crítica (o problema de alinhamento é mais difícil para sistemas encarnados) e posiciona o framework como fundacional e extensível a sistemas físicos via uma "camada de interface física blindada".
Para a maioria das equipas de engenharia a entregar IA em 2026, este é o scope relevante de qualquer maneira. Os agentes que estás a desplegar — para suporte ao cliente, geração de código, análise financeira, processamento de documentos — são sistemas de trabalho de informação. O problema de alinhamento neste scope é o praticamente urgente. O alinhamento de IA encarnada ainda é uma preocupação em fase de investigação para quase toda a gente.
O Que os Engenheiros Devem Tirar Disto
Três conclusões práticas para equipas não profundamente envolvidas na investigação de alinhamento.
1. Trata o alinhamento como propriedade do sistema desplegado, não do modelo
A ideia mais accionável é o próprio enquadramento. Quando avalias um deployment de IA por alinhamento, não avalies "está o modelo alinhado?". Avalia "está o sistema desplegado, incluindo a sua camada de restrição e o monitor, a produzir trajectórias na região aceitável?".
Isto muda como arquitectas os deployments de IA. A camada de restrição, o monitor e os controlos de superfície de acção são parte do sistema de segurança. O modelo é um componente de um sistema maior, não a unidade de análise de segurança.
2. Monitora trajectórias, não apenas outputs
Os outputs progressivos são a versão formal do streaming de estado de agente. Se o teu deployment de IA só regista respostas finais, perdes a maior parte do sinal relevante para segurança. Regista os estados intermédios. Monitora drift distributional sobre esses estados intermédios. Constrói alertas sobre a trajectória, não apenas sobre o resultado.
Este é o mesmo padrão que a observabilidade em sistemas distribuídos: regista spans, não apenas request/response. O motivo é o mesmo: os modos de falha que te importam são a meio da trajectória, não apenas na fronteira.
3. Constrói a camada de restrição para ser inspeccionável, modificável e auditável
A camada de restrição — seja qual for a forma que assuma no teu sistema, sejam políticas OPA, filtros runtime, funções de gating — é o componente que aguenta o alinhamento. Trata-a em conformidade:
- Inspeccionável: as regras devem ser legíveis por humanos, não codificadas apenas em pesos do modelo.
- Modificável: as regras devem ser actualizáveis sem retreinar.
- Auditável: as mudanças às regras devem ser versionadas, assinadas e revisíveis.
Se o teu "alinhamento" vive no treino do modelo, nenhuma destas propriedades aguenta. Se vive na camada de restrição, as três são alcançáveis.
Configurações Multi-Agente
O framework estende-se a configurações multi-agente usando a existência de equilíbrio em espaços localmente convexos. Isto importa porque a maioria dos deployments agênticos em produção em 2026 evolui para multi-agente: múltiplos agentes especializados a colaborar numa tarefa. O alinhamento multi-agente não é apenas o alinhamento por agente somado — comportamentos emergentes ao nível do sistema podem estar desalinhados mesmo quando cada agente individual está alinhado.
O enquadramento matemático trata este caso naturalmente. A condição de pertinência é sobre a distribuição conjunta de trajectórias, não as distribuições por agente. Praticamente, isto significa que o monitoring multi-agente tem de ser ao nível do sistema, com traces cruzadas correlacionadas e analisadas em conjunto.
Se estás a desplegar sistemas multi-agente e o teu monitoring é por agente, perdes os modos de falha emergentes.
Porque Esta Abordagem É Útil Mesmo Saltando a Matemática
Não precisas seguir as provas para tirar a lição. A lição é:
O alinhamento-por-construção é mais robusto que o alinhamento-por-treino, porque não depende do treino correr bem.
Isto é consistente com como as equipas de engenharia tratam outros sistemas críticos para segurança. Não confiamos nos pilotos para não cometerem erros; temos restrições (autopilotos, avisos de terreno, evitamento de colisão de tráfego). Não confiamos nos condutores para não baterem; temos restrições (manutenção de faixa, travagem de emergência automática). Não confiamos nas bases de dados para nunca corromperem dados; temos restrições (transacções, réplicas, backups). Confiamos no operador dentro de restrições conhecidas; não confiamos no operador sem restrições.
A mesma lógica aplica-se à IA. Treina o modelo bem. Depois restringe a sua superfície de acção para que mesmo quando o treino é imperfeito, o sistema desplegado seja ainda seguro. A camada de restrição é o sistema de segurança; o modelo é a optimização dentro dele.
Isto não é um resultado só-de-investigação. As equipas a entregar IA agêntica séria em 2026 estão a convergir neste padrão a partir de muitas direcções: arquitecturas de governança verificável, garantia finance-grade, watchdogs runtime. O framework matemático dá ao padrão uma base formal, o que o torna mais difícil de mal-implementar e mais fácil de auditar.
Fonte: Fradelos, G. A Mathematical Solution to the AI Alignment Problem: Topological Constraints on Action Distributions with Progressive Verification (Genebra, 14 de janeiro de 2026). SSRN 6307060.
A construir sistemas de IA onde o alinhamento importa em produção e preferias tê-lo por construção em vez de por esperança? Fala com um CTO sobre desplegar capacidade de engenharia nearshore com a disciplina para construir correctamente a camada de restrição.
