Nos últimos dois anos, vi a inteligência artificial em transportes deixar de ser apenas preditiva — antecipar congestionamentos, classificar incidentes, otimizar fluxos — para começar a executar ações sobre sistemas reais. É o paradigma de Agentic AI: agentes baseados em LLMs que saem da predição passiva e passam a invocar ferramentas, consultar bases e disparar operações administrativas. A pergunta que me incomodava era simples e desconfortável: como deixar um agente desses agir sobre os sistemas de um DETRAN sem que ele erre de sistema, vaze um CPF ou tome uma decisão que ninguém consegue auditar depois?

Foi dessa inquietação que nasceu a UEL-MAS (Unified Execution Layer for Multi-Agent Systems). Este post é uma divulgação do meu projeto de pesquisa autoral, desenvolvido em coautoria com João Afonso Gunza na disciplina PEA5003 (Componentes de Automação em ITS) da Escola Politécnica da USP. Quero contar aqui, em primeira pessoa, qual é o problema, como abordamos e o que efetivamente propomos.

O problema: três correntes que nunca conversaram

A IA ágil em transportes já provou que funciona em tarefas estreitas. Trabalhos recentes aplicaram o Model Context Protocol (MCP) ao controle semafórico adaptativo, com reduções relevantes de consumo energético e de tempo de viagem; outros montaram plataformas multiagente para dados de sensores, detecção de acidentes e previsão de fluxo. Tudo isso para escopos bem delimitados.

O problema aparece quando o agente precisa operar sobre a paisagem real e fragmentada do setor público brasileiro e latino-americano. Autoridades de trânsito, operadores rodoviários, sistemas de fiscalização eletrônica, cadastros de veículos, bases de multas e registros de habilitação expõem dados semanticamente inconsistentes. O mesmo conceito — "veículo", "infração", "débito", "situação" — aparece sob nomes, codificações e regras diferentes em cada sistema. Some a isso a ausência de governança contextual, a auditabilidade limitada das cadeias de decisão e as exigências da LGPD, e você tem o terreno perfeito para ações executadas sobre o sistema errado ou chamadas de ferramenta alucinadas.

A lacuna que motiva o trabalho é a integração de três correntes que evoluíram em paralelo: (a) Agentic AI aplicada a ITS; (b) representação semântica e integração baseada em ontologias; e (c) governança, auditabilidade e IA confiável. Na nossa revisão, nenhuma referência articulava as três numa única arquitetura adequada aos ambientes corporativos de ITS da região.

O método: Design Science e uma revisão PRISMA-like

Adotamos o método Design Science Research restrito às suas três primeiras etapas — identificação do problema, definição de objetivos e projeto conceitual. Quero ser honesto sobre o escopo: a contribuição é exclusivamente conceitual. Não há protótipo, simulação ou medição empírica; expressões como "reduz" ou "melhora" referem-se a proposições falsificáveis, não a achados.

A base teórica veio de uma revisão bibliográfica PRISMA simplificada na Web of Science: 967 registros brutos, deduplicados para 855 únicos, filtrados por um score de aderência por palavras-chave até chegarmos a 29 trabalhos de alta aderência (2019–2026), lidos integralmente e balanceados entre sete eixos temáticos.

A arquitetura: seis camadas, nenhuma descartável

A UEL-MAS é composta por seis camadas, e nossa tese é que nenhuma delas pode ser removida sem perder uma das quatro propriedades-chave (coerência semântica, auditabilidade distribuída, governança orientada a propósito e resiliência semântica):

  • MCP Gateway — expõe habilidades, recursos e prompts aos agentes via Model Context Protocol; autentica chamadas e mantém o registro de ferramentas disponíveis.
  • Agent Skill Runtime — materializa como habilidades nominais os comportamentos legítimos do agente, desacoplando significado de invocação.
  • Policy Engine — autoriza, nega ou condiciona a execução com base em identidade, propósito declarado, classe LGPD do dado e contexto temporal/geográfico. É o "para quê", não só o "o quê".
  • Semantic Execution Layer (SEL) — resolve termos ambíguos por um pipeline determinístico de três estágios (mapeamento explícito → índice vetorial → regras de domínio), anexando um score de confiança a cada resolução.
  • Connector Layer — interfaceia os sistemas-alvo heterogêneos e isola a heterogeneidade tecnológica das camadas superiores.
  • Audit/Observability — registra identidade, propósito, decisão, classe de dado e latência por chamada. Nenhuma execução ocorre fora da trilha de auditoria.

O coração: o Modelo Canônico Universal

No centro da SEL está o Modelo Canônico Universal (UCM), formalizado como uma tripla ⟨E, R, V⟩ — entidades canônicas, relações tipadas e valores controlados — serializado em JSON-LD. Sobre ele opera uma função de resolução semântica res: T × C → Ω × [0,1], que recebe um termo bruto e um contexto e devolve a entidade canônica resolvida junto de um escalar de confiança. O pipeline é determinístico e usa fallback sequencial: cada estágio só roda quando o anterior falha, e termos desconhecidos não param o sistema — disparam um evento auditável e retornam confiança zero.

Da construção derivam quatro axiomas (determinismo, correção sob curadoria, propagação e auditabilidade) e quatro invariantes operacionais, incluindo a classificação LGPD em tempo de projeto: todo campo pessoal ou sensível recebe sua classe LGPD na própria definição do UCM, garantindo determinismo regulatório em tempo de execução.

O estudo de caso: DETRAN

Escolhemos o domínio DETRAN como cenário ilustrativo justamente por concentrar o pior dos mundos: múltiplos sistemas legados com vocabulários distintos, codificações sobrepostas, regulação estrita sobre dados pessoais e demanda institucional por trilhas auditáveis. Pense na consulta "quais débitos e infrações pendentes tem o veículo de placa XYZ-0000?". Sem mediação, o campo "SIT" pode significar situação de habilitação num sistema e situação da infração em outro — e o agente aplica uma interpretação única às duas fontes, errando. Com a UEL-MAS, a SEL resolve cada código por fonte, o Policy Engine avalia propósito e classe LGPD (mascarando o CPF automaticamente) e o Audit Trail registra a cadeia inteira.

Reflexão e próximos passos

Tenho clareza do limite deste trabalho: ele é conceitual, e seu maior risco é permanecer no papel. Por isso propusemos um protocolo de avaliação com nove métricas — latências P95, confiança semântica média, taxa de execução correta, cobertura de auditoria e de classificação LGPD — pronto para ser reutilizado por estudos empíricos. Os próximos passos que mais me animam são a implementação executável, a extensão para controle semafórico e gestão de incidentes, e a verificação formal das regras do Policy Engine. Governar agentes autônomos no setor público não é detalhe de engenharia — é requisito estrutural. E é exatamente aí que pretendo continuar trabalhando.