O impasse do garantismo excessivo: lições do sistema jurídico para o desenvolvimento de IA

João Valle e Azevedo, em entrevista ao programa Comissão de Inquérito, descreveu o sistema jurídico português como dominado por uma “tendência para o empate”. A expressão, usada no contexto do excesso de garantismo, aponta para um impasse institucional onde o excesso de proteção a direitos processuais impede decisões rápidas e eficazes. Essa mesma dinâmica, embora surja no Direito, ecoa de forma surpreendente no desenvolvimento de sistemas de inteligência artificial, sobretudo quando equipes de engenharia enfrentam camadas excessivas de validação, conformidade e revisão de requisitos. O resultado, em ambos os cenários, é a paralisia disfarçada de rigor.

A afirmação de Valle e Azevedo de que “governar por duodécimos não é um drama” acrescenta outra camada à discussão. A governança provisória, feita por fatias orçamentárias, pode ser encarada como um mal menor, mas revela um padrão de adiamento de decisões estruturais. No universo da IA, essa lógica aparece quando times optam por releases incrementais que nunca entregam o valor completo do sistema, ou quando a integração de modelos é postergada por indefinições regulatórias. O empate não é apenas jurídico; é uma armadilha cultural que também aprisiona projetos tecnológicos.

A metáfora do impasse jurídico serve, portanto, para iluminar um problema pouco debatido na engenharia de software: o custo oculto do excesso de zelo. Em nome da segurança, da privacidade ou da ética, processos de revisão podem se multiplicar a ponto de inviabilizar entregas. O desafio não é abandonar controles, mas calibrá-los. Assim como no Direito, onde o garantismo extremo leva à ineficiência, na IA o medo de errar pode gerar sistemas superprojetados, lentos e, paradoxalmente, menos confiáveis por falta de ciclos reais de teste em produção.

Contexto técnico ou de negócio

O garantismo jurídico, na definição clássica, visa proteger o cidadão contra abusos do Estado, assegurando amplo direito de defesa e recursos processuais. No entanto, quando aplicado sem limites, transforma-se em obstrução. A Justiça portuguesa, segundo Valle e Azevedo, vive esse paradoxo: tantas salvaguardas que o sistema emperra. Transferindo essa análise para o campo da IA, vemos paralelos diretos na forma como equipes de produto lidam com compliance, auditoria de modelos e aprovação de dados de treinamento.

Empresas que desenvolvem sistemas de machine learning sob regulações como a LGPD ou a futura Lei de IA Europeia frequentemente instauram comitês de ética, revisões jurídicas e trilhas de aprovação que podem durar meses. Cada etapa adiciona um “ponto de cheque” que, se não for desenhado com agilidade, gera o mesmo efeito de empate. O time de engenharia aguarda pareceres, enquanto os modelos se tornam obsoletos e as bases de dados perdem relevância temporal. O garantismo regulatório, neste caso, não protege o usuário; apenas adia os benefícios da inovação.

Por que isso importa

A importância do tema transcende a crítica ao excesso de burocracia. Em produtos digitais baseados em IA, o tempo de ciclo desde a ideação até o lançamento é um fator competitivo central. Quando o “empate” se instala, startups perdem janelas de mercado e grandes corporações veem seus investimentos em P&D renderem abaixo do esperado. Além disso, a própria reputação do setor é afetada, pois o discurso público de “IA responsável” muitas vezes esconde uma paralisia disfarçada de prudência. O mercado precisa de um equilíbrio real entre proteção e experimentação, e a experiência jurídica portuguesa oferece um alerta concreto.

Desenvolvimento

Na prática, o garantismo excessivo em projetos de IA manifesta-se de várias formas. Uma delas é a exigência de que cada decisão do modelo seja explicável ao mais ínfimo detalhe, mesmo em cenários de baixo risco, como recomendações de conteúdo. Isso força o uso de modelos interpretáveis menos precisos, sacrificando acurácia em nome de uma transparência que, na maioria dos casos, poucos auditores realmente compreendem. Outra manifestação é a multiplicação de guardrails de segurança que disparam alarmes falsos, travando fluxos inteiros de atendimento ao cliente. O resultado é um sistema que raramente erra porque raramente age – o equivalente jurídico de um processo que nunca chega a sentença.

A governança por duodécimos, mencionada por Valle e Azevedo, também tem seu eco tecnológico. Projetos de IA que operam com orçamentos trimestrais ou “fatias” de investimento tendem a priorizar entregas fragmentadas. Um modelo de recomendação pode ser lançado com apenas 30% dos sinais planejados, porque o próximo duodécimo ainda não foi aprovado. Isso gera sistemas que funcionam, mas nunca atingem o desempenho projetado, alimentando a percepção de que a IA “não entrega”. O problema não é técnico, é de governança financeira e decisória – exatamente como no direito, onde os duodécimos orçamentários impedem reformas estruturais.

Implicações operacionais

Para times de engenharia, o impacto é direto. A necessidade de atender a múltiplos stakeholders jurídicos, de compliance e de negócios gera um fenômeno conhecido como “death by review”. Cada revisão introduz latência e, muitas vezes, contradições entre exigências. Um departamento jurídico pede mais explicação; o time de produto pede entrega rápida; o de segurança pede testes adicionais. Sem uma autoridade central de decisão, o projeto empaca. A analogia com a Justiça portuguesa é clara: quando todos os atores têm poder de veto, o processo nunca avança.

• Revisão contínua de requisitos de privacidade: Cada nova funcionalidade de IA precisa de uma avaliação de impacto à privacidade (DPIA). Em empresas sem processos maduros, essa etapa pode consumir semanas, enquanto o time de dados aguarda aprovação para coletar variáveis essenciais. O resultado é um modelo treinado com dados antigos e menos preditivo.
• Especificações contraditórias entre compliance e produto: Enquanto o jurídico exige que todo output do modelo seja auditável, o time de produto quer latência mínima. A conciliação dessas demandas sem uma arquitetura adequada leva a um design inchado que atende mal a ambos os lados – o verdadeiro “empate técnico”.
• Ausência de fallback humano em sistemas críticos: O medo de responsabilização leva equipes a projetar IA como mera assistente, com fluxos de escalonamento humano excessivos. Em vez de automatizar, criam-se filas de validação manual que anulam os ganhos de eficiência, repetindo o garantismo processual observado no direito.

O risco do empate técnico

O conceito de “empate” não se limita a atrasos; pode significar também perda de qualidade. Quando um modelo é submetido a tantas restrições de viés, explicação e segurança que sua capacidade preditiva despenca, estamos diante de um empate funcional. O sistema não é bom nem ruim – é medíocre. Esse risco é especialmente agudo em aplicações de alto impacto, como diagnóstico médico ou concessão de crédito, onde a pressão regulatória é máxima. A tentação de adicionar mais camadas de controle sem pensar na dinâmica do sistema inteiro cria uma “dívida de governança” que compromete o valor do produto.

Decisões técnicas ou editoriais

Diante desse cenário, times de engenharia precisam adotar uma postura ativa contra o garantismo excessivo. A primeira decisão editorial é separar claramente os níveis de risco do sistema, aplicando controles proporcionais. Um modelo de recomendação de notícias não deve exigir o mesmo rigor de um modelo de triagem hospitalar. Essa hierarquização, baseada em matrizes de risco documentadas, reduz gargalos desnecessários e permite que times foquem energia onde realmente importa.

Outra decisão crítica é estabelecer um “ritual de desempate” dentro do processo de desenvolvimento. Assim como no direito existem tribunais superiores para resolver conflitos processuais, na IA deve haver uma figura ou comitê com poder de decisão terminal sobre disputas entre compliance, engenharia e produto. Sem essa instância, cada divergência vira um impasse eterno.

Por fim, é preciso repensar o uso de duodécimos orçamentários em projetos de IA. Em vez de planos anuais rígidos, recomenda-se a adoção de ciclos trimestrais de investimento com revisão de prioridades baseada em resultados. Isso não elimina o impasse, mas dá flexibilidade para realocar recursos quando um modelo não atinge os KPIs esperados. A governança por fatias, se bem gerenciada, pode ser um instrumento ágil – desde que não se confunda prudência com paralisia.

Riscos, limitações e perguntas em aberto

Um risco real ao combater o garantismo excessivo é cair no extremo oposto: a negligência regulatória. Remover controles sem critério pode expor a empresa a multas, danos reputacionais e falhas éticas graves. A calibragem ideal exige métricas objetivas de risco e revisões periódicas independentes – algo que poucas organizações implementam de forma consistente. A analogia jurídica serve para alertar, não para justificar descontrole.

Outra limitação é que o conceito de “empate” depende do contexto cultural e regulatório de cada país. O que é excesso de garantismo em Portugal pode ser insuficiência no Brasil, onde o sistema jurídico enfrenta outros gargalos, como morosidade estrutural. Aplicar a lição sem adaptação local é arriscado. Times de IA que operam globalmente precisam mapear as exigências de cada jurisdição e criar camadas de compliance modulares, evitando que a regra mais restritiva contamine todo o pipeline.

Perguntas em aberto incluem: Como medir o ponto de inflexão onde a proteção se torna paralisia? Existe um framework matemático para calcular o custo do garantismo em produtividade de IA? Até que ponto a regulação deve intervir para evitar inércia, e quando a indústria deve autorregular-se? Essas questões não têm resposta única; cada organização precisará construir sua própria bússola, usando tanto dados de desempenho quanto lições de outras áreas, como o direito.

Aprendizados práticos

O primeiro aprendizado é que times de engenharia devem tratar o garantismo como um risco de projeto, tão real quanto bugs ou débitos técnicos. Incluir no roadmap sprints dedicados a revisar e simplificar processos de compliance, eliminando redundâncias. Isso requer métricas – quantas aprovações um modelo precisa até o deploy? Qual o tempo médio de cada etapa? Sem dados, não há como identificar os gargalos que geram o empate.

Outra lição importante é a necessidade de prototipação regulatória. Assim como se faz proof-of-concept técnico, recomenda-se testar novas abordagens de governança em um sandbox controlado antes de expandir para toda a organização. Uma seguradora pode, por exemplo, implementar um modelo de crédito com regras de explicabilidade flexíveis em um estado específico, monitorar resultados e ajustar antes de aplicar nacionalmente. Isso evita que o medo do erro paralise todo o rollout.

Por fim, o aprendizado mais sutil é aceitar que o “empate” é, em parte, inevitável. Nem toda decisão de IA precisa ser rápida; algumas requerem ponderação cuidadosa. A arte do engenheiro de software responsável é discernir quando o impasse é legítimo (protege o usuário de danos reais) e quando é burocrático (protege o gestor de responsabilidade). Construir essa capacidade de discernimento dentro do time é o maior legado que a experiência jurídica pode deixar para o desenvolvimento de inteligência artificial.

Conclusão

A tendência para o empate que João Valle e Azevedo diagnostica no sistema jurídico português não é uma exclusividade do direito. Ela se reproduz em todas as áreas onde o excesso de salvaguardas, sem uma visão sistêmica de eficiência, gera paralisia. No desenvolvimento de IA, esse fenômeno ameaça transformar a promessa de inovação em um ciclo interminável de revisões, validações e relatórios. Reconhecer o padrão é o primeiro passo para rompê-lo.

A saída não está em abandonar a proteção, mas em redesenhar os processos de governança com a mesma disciplina com que projetamos algoritmos. Matrizes de risco proporcionais, comitês de desempate, ciclos de decisão rápidos e aceitação calculada de riscos residuais podem devolver fluidez aos projetos sem comprometer a ética. No fundo, tanto na justiça quanto na IA, o objetivo não é evitar todo erro; é garantir que as decisões certas sejam tomadas no tempo certo. O empate técnico, afinal, nunca é um bom resultado para ninguém.