Verificaçāo Formal: A Única Via para Satisfazer os Reguladores de IA
A conversa que nunca corre bem
Imagine esta cena. Acontece todas as semanas em salas de reuniões por toda a Europa, em reuniões de revisão da FDA, em escritórios de subscrição de seguros. Um engenheiro de IA apresenta o seu sistema mais recente a reguladores, advogados ou avaliadores de risco.
«A nossa bomba de insulina autónoma atingiu 99,97% de precisão em 50 milhões de cenários de teste», anuncia o engenheiro com orgulho, clicando para um diapositivo cheio de métricas impressionantes. «Estado da arte. Melhor do que qualquer endocrinologista humano.»
A sala fica em silêncio. A reguladora inclina-se para a frente.
«Então está a dizer-me», diz ela lentamente, «que de cada 10.000 doses de insulina que este dispositivo administra... três podem estar erradas?»
O engenheiro mexe-se, desconfortável. «Bem, estatisticamente falando...»
«Só na Alemanha, cerca de 7 milhões de pessoas têm diabetes que requer terapia com insulina. Se cada pessoa receber apenas quatro doses por dia, são 28 milhões de administrações diárias. Com a sua taxa de erro de 0,03%...» Ela faz as contas no bloco de notas. «São 8.400 potenciais erros de dosagem. Todos os dias.»
«Mas a maioria deles não seria clinicamente significativa...»
«Consegue dizer-me quais seriam?»
Silêncio.
«Consegue dizer-me quando ocorrerá a próxima falha? Consegue dizer-me por que motivo irá falhar?»
Mais silêncio.
«Então, receio que não possamos aprovar este dispositivo.»
Esta conversa, sob várias formas, repete-se constantemente à medida que a IA passa dos laboratórios de investigação para o mundo físico. E revela um fosso epistemológico fundamental entre a forma como os engenheiros de IA pensam sobre segurança e a forma como os reguladores, advogados e tribunais pensam sobre ela.
A Barreira da Linguagem Que Não É Sobre Linguagem
Quando o engenheiro de IA diz "99,97% de precisão", acredita genuinamente que está a descrever algo impressionante e seguro. No mundo dos benchmarks de aprendizagem automática, esse número seria celebrado. Publicavam-se artigos. Os investidores ficariam entusiasmados.
Mas o regulador ouve algo completamente diferente. Ouve: "Existe uma probabilidade pequena, mas não nula, de este sistema falhar de forma catastrófica, e não temos ideia de quando, onde ou porquê isso acontecerá."
Isto não é um problema de comunicação. Não é que os engenheiros precisem de melhores competências de apresentação ou que os reguladores precisem de formação técnica. É um conflito fundamental entre dois conceitos diferentes do que significa realmente "saber que algo funciona".
No software de consumo, as abordagens probabilísticas são perfeitamente aceitáveis. Se a Netflix recomendar um filme que odeia, ninguém morre. Se o Spotify sugerir uma música que não corresponde ao seu gosto, o pior cenário é um ligeiro aborrecimento. Estes sistemas podem dar-se ao luxo de errar por vezes porque o custo da falha é trivial.
Mas a IA está rapidamente a ultrapassar as recomendações de consumo para domínios onde a falha tem consequências físicas, legais e morais: veículos autónomos a tomar decisões em frações de segundo sobre peões, dispositivos médicos a calcular dosagens de medicamentos, robôs industriais a operar ao lado de trabalhadores humanos, sistemas financeiros a aprovar ou recusar crédito que determina se as famílias podem comprar casa.
Nestes domínios, "é bastante provável que funcione" não é suficiente. Os tribunais não aceitam distribuições de probabilidade como prova. Os atuários de seguros não podem definir preços para modos de falha desconhecidos. Os reguladores não podem aprovar dispositivos que possam matar pessoas por razões que ninguém consegue explicar.
Porque É Que os Testes, Por Mais Extensos Que Sejam, Não Podem Garantir Segurança
O paradigma dominante na avaliação de IA hoje é o teste empírico em conjuntos de dados reservados. Treina o modelo no Conjunto de Dados A e depois avalia-o no Conjunto de Dados B. Se tiver um bom desempenho em B, assume que "aprendeu" a tarefa subjacente e que generalizará para a implementação no mundo real.
Esta abordagem tem três problemas fundamentais que nenhuma quantidade de testes consegue resolver.
Problema Um: O Espaço de Entrada Infinito
Os testes só podem demonstrar a presença de erros, nunca a sua ausência. Por mais casos de teste que execute, está a amostrar de um espaço de entrada infinito. Um sistema que controla um dispositivo médico tem de lidar não apenas com os cenários de teste que imaginou, mas com todas as combinações possíveis de fisiologias de pacientes, condições ambientais, leituras de sensores e casos extremos que o mundo real acabará por produzir.
Imagine tentar provar que não há agulhas num palheiro pegando aleatoriamente em pedaços de palha. Depois de examinar um milhão de pedaços e não encontrar agulhas, não pode concluir que o palheiro está livre de agulhas. Só pode dizer que ainda não encontrou nenhuma. Os testes funcionam da mesma forma. Por mais cenários que passem, o próximo pode falhar.
Problema Dois: A Vulnerabilidade Adversarial
As redes neuronais profundas são particularmente vulneráveis a entradas adversariais. São perturbações cuidadosamente concebidas que fazem os modelos falhar de forma catastrófica enquanto parecem normais aos observadores humanos.
Um modelo pode classificar corretamente sinais de stop 99,99% das vezes, mas um pequeno autocolante colocado num local específico pode levá-lo a classificar o sinal com confiança como um sinal de limite de velocidade. Um modelo pode identificar com precisão condições médicas em milhares de radiografias, mas um padrão específico de ruído, invisível para radiologistas humanos, pode fazê-lo falhar tumores óbvios.
Estas não são preocupações teóricas. Os investigadores demonstraram ataques adversariais contra todas as principais classes de arquiteturas de redes neuronais. E os ataques estão a tornar-se mais fáceis de construir, enquanto as defesas permanecem incompletas.
Os testes não podem proteger contra vulnerabilidades adversariais porque a superfície de ataque é infinita. Seria necessário testar não apenas entradas normais, mas todas as perturbações possíveis de cada entrada normal. Isso é matematicamente impossível.
Problema Três: A Mudança Distribucional
O mundo real não fica parado. A distribuição de dados com que o seu modelo foi treinado vai mudar ao longo do tempo. As populações de pacientes mudam. As condições de condução evoluem. Os processos de fabrico variam. Ocorre degradação dos sensores.
Um modelo que tem um desempenho perfeito nos dados de hoje pode falhar silenciosamente quando os dados de amanhã saem da sua distribuição de treino. E, ao contrário de erros explícitos que fazem os programas falhar, estas falhas produzem frequentemente resultados confiantes, plausíveis, mas errados.
Testar com os dados de hoje não lhe diz nada sobre o desempenho de amanhã. Quando a falha é observada em produção, o dano já ocorreu.
Verificação Formal: a Matemática como Linguagem Universal da Segurança
A verificação formal oferece uma abordagem completamente diferente. Em vez de perguntar "o sistema funcionou nestes casos de teste?", pergunta "podemos provar matematicamente que o sistema satisfará uma propriedade para todas as entradas possíveis?"
A distinção é profunda. Os testes amostram o espaço de entradas. A verificação raciocina exaustivamente sobre todo o espaço.
Considere um braço robótico a trabalhar junto de humanos numa fábrica. Queremos garantir uma propriedade de segurança: "O braço nunca deve exceder 2 metros por segundo quando um humano for detetado a menos de 1 metro."
A abordagem de teste executa o braço em milhares de cenários com humanos simulados em várias posições e velocidades, medindo se o limite de segurança é alguma vez violado. Se não forem observadas violações, o sistema é declarado "seguro". Mas o cenário seguinte, aquele que não foi testado, pode ser o que fere um trabalhador.
A abordagem de verificação é fundamentalmente diferente. Pegamos no modelo matemático do sistema de controlo, incluindo a rede neural que processa os dados dos sensores e o controlador que gera os comandos motores. Expressamos a propriedade de segurança como uma restrição formal. Depois usamos algoritmos especializados chamados solvers SMT (Satisfiability Modulo Theories) para responder a uma pergunta precisa: "Existe ALGUMA configuração de entrada, dentro do intervalo operacional válido, para a qual a velocidade de saída exceda 2 m/s quando a proximidade humana for detetada?"
O solver não testa pontos aleatórios. Analisa a estrutura matemática de todo o sistema. Raciocina sobre a geometria do espaço de funções. Se devolver "UNSAT" (insatisfazível), temos uma prova matemática de que não existe tal entrada violadora. A propriedade de segurança não se aplica apenas aos casos que testámos, mas a todos os casos possíveis que possam alguma vez ocorrer.
Esta é a diferença entre "verifiquei muitas pontes e nenhuma colapsou" e "a física destes materiais garante matematicamente que esta ponte não pode colapsar sob esta carga". Uma é uma observação empírica sujeita a revisão. A outra é uma certeza lógica.
Porque é que a IA Moderna Resiste à Verificação
Se a verificação formal é tão poderosa, porque não a usa toda a gente? Porque é que empresas como a OpenAI e a Google dependem de "red teaming" (humanos a tentar partir o modelo) em vez de provas matemáticas?
A resposta está nas escolhas arquiteturais que a indústria fez. Os grandes modelos de linguagem modernos e as redes neuronais profundas são concebidos para expressividade, não para verificabilidade. São otimizados para gerar resultados criativos, não para serem matematicamente analisáveis.
Um modelo transformer típico tem milhares de milhões ou biliões de parâmetros. Usa funções de ativação complexas e não lineares como GeLU ou Swish. A complexidade matemática de verificar tal sistema escala exponencialmente com o número de neurónios e a profundidade da rede.
Provar uma propriedade num transformer com milhares de milhões de parâmetros é computacionalmente intratável. O universo atingiria a morte térmica antes de o solver explorar todos os ramos matemáticos. A indústria construiu sistemas tão complexos que nem os seus criadores os conseguem analisar completamente.
Esta é uma escolha de design, não uma inevitabilidade. A indústria otimizou-se para demonstrações impressionantes e pontuações de referência sem considerar se os sistemas resultantes poderiam alguma vez ser implementados com segurança em ambientes regulamentados.
A Arquitetura Dweve: Verificável por Conceção
Na Dweve, fizemos escolhas arquitetónicas diferentes. Concebemos os nossos sistemas de raiz para serem verificáveis, porque compreendemos que os clientes empresariais e industriais acabariam por precisar de satisfazer os reguladores, e não apenas impressioná-los.
A nossa abordagem combina duas inovações fundamentais que tornam a verificação exequível.
Descoberta de Restrições Binárias: Matemática Simples
Em vez de redes neuronais massivas de vírgula flutuante com milhares de milhões de parâmetros contínuos, os sistemas Dweve utilizam a Descoberta de Restrições Binárias. O conhecimento é representado como restrições lógicas discretas, em vez de pesos contínuos aprendidos.
A nossa biblioteca Dweve Core contém 1.937 algoritmos otimizados para hardware, construídos sobre operações binárias: XNOR, AND, OR, POPCNT. Estas operações têm propriedades matemáticas simples e bem compreendidas. Uma restrição binária ou se verifica ou não se verifica. Não há incerteza probabilística.
Ao restringir a matemática a relações lineares simples e lógica booleana, reduzimos drasticamente o espaço de pesquisa da verificação. Problemas que seriam intratáveis para redes neuronais contínuas tornam-se solucionáveis para os nossos sistemas de restrições binárias. O problema da verificação transforma-se de uma otimização não linear impossível em problemas solucionáveis de Programação Linear Inteira Mista (MILP) ou SAT.
Estes continuam a ser problemas computacionalmente difíceis, mas para a dimensão dos sistemas que implementamos em aplicações críticas de segurança, os solvers modernos conseguem lidar com eles em segundos ou minutos, em vez de séculos.
A Arquitetura de Autonomia Limitada em Seis Camadas
Não tentamos verificar todos os aspetos da perceção de IA. Reconhecer que "uma grelha de píxeis representa um ser humano" é inerentemente um julgamento difuso e probabilístico. Não se pode provar formalmente que o reconhecimento de padrões está sempre correto, porque a correção depende de definições subjetivas.
Em vez disso, implementamos uma arquitetura de segurança em camadas, onde os componentes probabilísticos de IA são limitados por restrições lógicas formalmente verificadas. A IA pode sugerir ações, mas essas sugestões têm de passar por portões de segurança verificados antes da execução.
O Dweve Nexus implementa seis camadas de aplicação de segurança:
- Verificação de Intenções: Valida se as ações da IA estão alinhadas com os objetivos declarados
- Autonomia Limitada: Limites rígidos sobre quais ações são permitidas, independentemente das sugestões da IA
- Moderação de Conteúdo: Filtra os resultados para garantir segurança e adequação
- Aplicação de Ética: Garante a conformidade com restrições éticas definidas
- Deteção de Anomalias: Identifica quando o comportamento da IA se desvia dos padrões esperados
- Monitorização em Tempo Real: Verificação contínua de que os invariantes de segurança são mantidos
A perceção crítica é que só precisamos de verificar formalmente as camadas de segurança, não todo o sistema de IA. Mesmo que a IA subjacente cometa um erro, a camada de autonomia limitada garante matematicamente que comandos perigosos nunca chegam aos atuadores.
A Matemática Regulamentar: Porque é que a Verificação Cria Valor Empresarial
Para os nossos clientes, a verificação formal não é um exercício académico. É uma vantagem competitiva que se traduz diretamente em resultados empresariais.
Aprovação Regulamentar Mais Rápida
Quando um fabricante de dispositivos médicos apresenta um sistema baseado em IA à FDA ou à EMA, os reguladores são naturalmente cautelosos. Sabem que a IA pode ser imprevisível. Os processos de aprovação padrão exigem anos de ensaios clínicos para demonstrar a segurança de forma estatística.
Mas um fabricante que utilize componentes Dweve formalmente verificados pode mudar a conversa. Em vez de apresentar resultados de testes que demonstram "ainda não observámos falhas", pode apresentar provas matemáticas que demonstram "as falhas são impossíveis dentro destes limites".
"Não nos limitamos a achar que esta bomba de insulina não vai administrar uma overdose aos pacientes. Aqui está a prova formal de que a dosagem de saída é matematicamente limitada pelas restrições de peso do paciente e de níveis de glucose. A violação não é apenas improvável. É logicamente impossível."
Isto permite vias de revisão aceleradas. Os reguladores podem verificar a prova de forma independente. Não precisam de confiar no processo de testes; podem examinar a matemática diretamente.
Prémios de Seguro Reduzidos
Os atuários de seguros enfrentam um problema impossível com os sistemas de IA tradicionais. Como se precifica o risco de modos de falha que não se conseguem prever ou explicar? O resultado são prémios extremamente elevados para cobrir riscos desconhecidos, ou cláusulas de exclusão que tornam o seguro praticamente inútil.
Os sistemas verificados alteram o cálculo atuarial. Se uma prova matemática garante que certos tipos de falhas não podem ocorrer, esses modos de falha podem ser excluídos do modelo de risco. Os riscos restantes são quantificáveis. Os prémios diminuem em conformidade.
Alguns dos nossos clientes viram os custos do seguro de responsabilidade civil cair 40-60% após implementarem camadas de segurança verificadas, simplesmente porque as seguradoras agora conseguem calcular riscos limitados em vez de precificar incerteza ilimitada.
Defensibilidade Legal
Quando os sistemas de IA causam danos, seguem-se litígios. Nas implementações tradicionais de IA, defender o sistema é quase impossível. "Como é que o seu sistema tomou esta decisão?" "Não sabemos exatamente, é uma rede neural com milhares de milhões de parâmetros..." Esta resposta não satisfaz nenhum juiz ou júri.
Os sistemas verificados oferecem uma defesa diferente: "Aqui está a restrição de segurança. Aqui está a prova matemática de que a restrição não pode ser violada. O dano ocorreu fora do limite verificado, indicando fatores externos, não uma falha do sistema."
Não se trata de evitar responsabilidade. Trata-se de conseguir demonstrar exatamente que garantias foram dadas e se foram cumpridas. Os tribunais compreendem lógica formal. Compreendem provas matemáticas. Não compreendem intervalos de confiança probabilísticos.
O Regulamento da UE sobre IA: A Verificação Torna-se Obrigatória
As vantagens teóricas da verificação formal estão a tornar-se requisitos práticos. O Regulamento da UE sobre IA, que entrou em vigor em 2024 com implementação faseada até 2027, altera fundamentalmente o que é legalmente exigido para as implementações de IA na Europa.
Para os sistemas de IA de "risco elevado", que incluem dispositivos médicos, decisões de emprego, avaliações de solvabilidade e muitas aplicações industriais, o Regulamento exige:
- Sistemas de gestão de riscos que identifiquem e mitiguem riscos previsíveis
- Dados de formação de alta qualidade com proveniência documentada
- Capacidades de registo que permitam rastrear o comportamento do sistema
- Transparência para os utilizadores sobre decisões tomadas por IA
- Mecanismos de supervisão humana que permitam intervenção
- Exatidão, robustez e cibersegurança adequadas à aplicação
Repare na linguagem: "riscos previsíveis", "comportamento rastreável", "exatidão adequada à aplicação". Não são aspirações vagas. São requisitos legais com força coerciva, incluindo multas até 35 milhões de euros ou 7% do volume de negócios global.
Como demonstra que identificou e mitigou "riscos previsíveis" numa rede neuronal com milhares de milhões de parâmetros, cujo processo de decisão é opaco até para os seus criadores? Como mostra que o comportamento é "rastreável" quando o sistema produz resultados através de multiplicações matriciais incompreensíveis?
As arquiteturas de IA tradicionais não conseguem satisfazer estes requisitos apenas com documentação e testes. Mas os sistemas verificados conseguem. A prova é a documentação. A garantia matemática é a mitigação. As restrições lógicas são a rastreabilidade.
Os 456 Especialistas de Domínio: Escala Verificável
Uma objeção comum à IA verificada é que a verificação não tem escala. Para sistemas simples com poucas regras, sim, a verificação funciona. Mas a IA do mundo real precisa de lidar com perceção e raciocínio complexos. Como pode a verificação funcionar à escala?
O Dweve Loom demonstra que verificação e capacidade não são mutuamente exclusivas. O nosso modelo de fundação utiliza 456 conjuntos de restrições especializados, cada um contendo 64-128MB de restrições binárias. Mas apenas 4-8 especialistas de domínio são ativados para qualquer consulta específica.
Esta arquitetura, que designamos por ativação ultra-esparsa, significa que o esforço de verificação aumenta com o subconjunto ativo, não com o modelo completo. Não precisamos de verificar todas as combinações dos 456 especialistas de domínio simultaneamente. Verificamos a lógica de encaminhamento que seleciona os especialistas de domínio e verificamos o conjunto de restrições de cada especialista de domínio de forma independente.
O sistema de encaminhamento Permuted Agreement Popcount (PAP) utiliza deteção de padrões estruturais para selecionar os especialistas de domínio relevantes. Esta camada de encaminhamento é, em si mesma, formalmente verificável porque opera em operações binárias discretas com propriedades matemáticas bem definidas.
O resultado é um sistema que consegue lidar com tarefas complexas do mundo real, mantendo a tratabilidade da verificação. Obtemos os benefícios de capacidade das arquiteturas de mistura de especialistas com os benefícios de segurança da verificação formal.
Implementação: Como é Realmente a Verificação
Para as organizações que consideram a implementação de IA verificada, o processo prático envolve várias fases.
Fase 1: Especificação de Propriedades
Antes de a verificação começar, tem de definir que propriedades precisam de ser verificadas. Este é frequentemente o passo mais difícil, exigindo uma colaboração estreita entre especialistas de domínio, engenheiros e equipas jurídicas/de conformidade.
As propriedades têm de ser precisas e matematicamente expressáveis. "O sistema deve ser seguro" não é uma propriedade verificável. "O comando de velocidade do motor não deve exceder V_max quando o sensor de proximidade indicar uma distância inferior a D_min" é verificável.
Na Dweve, ajudamos os clientes neste processo de especificação através do Spindle, a nossa plataforma empresarial de governação do conhecimento. A hierarquia de 32 agentes inclui especialistas em conformidade regulamentar que ajudam a traduzir requisitos legais em restrições formais.
Etapa 2: Mapeamento da Arquitetura
A arquitetura do sistema de IA tem de ser mapeada num modelo formal que as ferramentas de verificação possam analisar. Para os sistemas Dweve, este mapeamento é simples porque a nossa arquitetura de restrições binárias foi concebida para a verificabilidade.
Para organizações com implementações de redes neuronais existentes, esta etapa pode exigir modificações arquiteturais. Adicionar camadas de autonomia limitada em torno dos modelos existentes, implementar restrições de segurança como invólucros verificados ou, em alguns casos, substituir componentes não verificáveis por equivalentes Dweve.
Etapa 3: Execução da Verificação
Os resolvedores SMT modernos e as ferramentas de verificação formal analisam o modelo do sistema para provar as propriedades especificadas ou identificar contraexemplos. Os contraexemplos são inestimáveis, pois revelam exatamente quais entradas podem violar as restrições de segurança, permitindo correções direcionadas.
Para os sistemas Dweve, a verificação normalmente demora entre minutos e horas, dependendo da complexidade das restrições. Os 1.937 algoritmos no Dweve Core foram pré-verificados para propriedades de segurança comuns, pelo que a verificação envolve frequentemente a composição de componentes pré-verificados em vez de começar do zero.
Etapa 4: Certificação e Documentação
As propriedades verificadas geram artefactos de prova que servem como evidência de certificação. Estas provas são verificáveis por máquina, o que significa que os reguladores podem verificá-las de forma independente usando ferramentas padrão de verificação de provas, sem terem de confiar no processo de verificação original.
O Dweve Fabric, o nosso painel de controlo unificado da plataforma, gera documentação de conformidade automaticamente a partir dos resultados da verificação. As mesmas provas que satisfazem o resolvedor tornam-se no pacote de evidências para a submissão regulamentar.
O Futuro: IA Verificada como Prática Padrão
Estamos num ponto de inflexão na implementação de IA. A era de "mover rápido e partir coisas" está a terminar para aplicações de alto risco. O ambiente regulamentar está a apertar. A exposição à responsabilidade está a aumentar. Os desafios dos seguros estão a crescer.
As organizações que implementam IA em indústrias regulamentadas enfrentam uma escolha. Podem continuar com arquiteturas tradicionais e enfrentar fricção crescente: processos de aprovação mais longos, custos de seguro mais elevados, maior exposição legal e potencial exclusão do mercado à medida que os regulamentos entram em vigor.
Ou podem adotar arquiteturas verificadas que satisfazem os reguladores com certeza matemática em vez de esperança estatística.
A revolução da verificação não se trata de tornar a IA menos capaz. Trata-se de tornar a IA fiável de formas que importam para todos além do laboratório de investigação: pacientes, operadores, seguradoras, reguladores e tribunais. Trata-se de construir IA que os humanos possam realmente implementar com confiança.
Na Dweve, acreditamos que o futuro pertence a sistemas de IA que conseguem provar a sua segurança, não apenas prometê-la. A nossa arquitetura, desde os 1.937 algoritmos verificados no Core até à autonomia limitada de seis camadas no Nexus e aos 456 conjuntos de restrições especializadas por domínio no Loom, é construída de raiz para este futuro.
The mathematics of certainty isn't a constraint on AI progress. It's the foundation for AI deployment at scale.
Ready to deploy AI that regulators can approve? Dweve's formally verified architecture provides the mathematical guarantees that transform regulatory obstacles into competitive advantages. Contact us to discuss how verification can accelerate your path to market while reducing your liability exposure.