# Quatro tipos de conteúdo, uma resposta: como desenhar um detector multimodal de desinformação

> Princípios de design para um sistema que analisa texto, imagem, vídeo e áudio sob um orçamento de latência: contratos, paralelismo, evidências e revisão humana.

- Autor: Adriano Leão (https://adrianoleao.com/pt)
- Publicado: 2026-10-28
- Tempo de leitura: 3 min de leitura
- Temas: IA, Arquitetura, Backend
- URL: https://adrianoleao.com/pt/writing/multimodal-disinformation-detection-design

**Em resumo:** Um detector multimodal é mais fácil de construir, operar e confiar quando cada tipo de conteúdo fica atrás de um contrato único, roda em paralelo sob um limite de tempo e devolve evidências com confiança para uma pessoa revisar. São os princípios que aplico, a partir do trabalho no GuaIA.

![Slide de apresentação perguntando se o vídeo de dois homens uniformizados é real ou falso](https://adrianoleao.com/images/writing/multimodal-disinformation-detection-design-og.jpg)

*Capa: [Deepfake, Ministerie van Buitenlandse Zaken, CC BY-SA 2.0, via Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Deepfake.jpg)*

## Por que isto é um problema de arquitetura

Quando se fala em "IA contra desinformação", o pensamento vai para os modelos. Na prática, a maior parte das decisões difíceis em um sistema como o GuaIA foi sobre tudo ao redor dos modelos: como os formatos são roteados, quanto tempo cada etapa pode levar, como os resultados são combinados e o que uma pessoa vê no final.

Este artigo é um conjunto de princípios de design, não uma descrição do funcionamento interno do GuaIA. São os que uso depois de trabalhar no sistema como coarquiteto, onde as restrições eram quatro tipos de conteúdo (texto, imagem, vídeo e áudio), resposta em menos de quatro segundos e serviços em Python e NestJS que precisavam se comportar como um produto único.

## 1. Coloque cada tipo de conteúdo atrás do mesmo contrato

Cada modalidade exige uma análise própria, mas o resto do sistema não deveria se importar. Se a camada de API precisa saber como um vídeo é analisado, cada nova capacidade vira mudança em cinco lugares.

Um contrato pequeno e explícito mantém essa fronteira limpa:

```typescript
type Evidence = {
  signal: string // ex.: "manipulated-audio", "known-false-claim"
  confidence: number // 0..1
  detail?: string // explicação legível por pessoas
}

type AnalysisResult = {
  modality: 'text' | 'image' | 'video' | 'audio'
  status: 'ok' | 'timeout' | 'error'
  evidence: Evidence[]
}

interface Analyzer {
  readonly modality: AnalysisResult['modality']
  analyze(content: Buffer, signal: AbortSignal): Promise<AnalysisResult>
}
```

O trecho é ilustrativo, não é código de produção. O que importa é o formato: todo analisador devolve evidências com confiança, e a falha é um valor (`timeout`, `error`), não uma exceção que derruba a requisição inteira.

## 2. Trate a latência como um orçamento a gastar

"Menos de quatro segundos" só é alcançável se você decidir antes quanto cada parte pode consumir. Eu penso em um orçamento: uma fatia para a ingestão, uma para o analisador mais lento, uma para combinar os resultados.

Duas consequências. Analisadores independentes devem rodar em paralelo, e cada um precisa de seu próprio prazo, para que um caminho lento não consuma o orçamento dos outros:

```typescript
const withDeadline = (analyzer: Analyzer, content: Buffer, ms: number) =>
  analyzer.analyze(content, AbortSignal.timeout(ms)).catch(
    (): AnalysisResult => ({ modality: analyzer.modality, status: 'timeout', evidence: [] })
  )

const results = await Promise.all(analyzers.map(a => withDeadline(a, content, 2500)))
```

Uma resposta parcial que chega a tempo costuma ser mais útil do que uma completa que não chega.

## 3. Devolva evidências, não vereditos

Para um sistema que toca o debate público, um rótulo seco de "falso" ou "verdadeiro" é a saída errada. O que ajuda quem revisa são as evidências: quais sinais dispararam, com que confiança e o que está faltando porque um analisador estourou o prazo.

Isso também mantém o sistema honesto sobre a incerteza. Um resultado com evidências de baixa confiança em duas modalidades deve ser lido de outro jeito que um com alta confiança em uma só, e o formato da resposta precisa deixar isso visível.

## 4. Mantenha uma pessoa no fim do ciclo

O GuaIA foi concebido como ferramenta de apoio: a decisão final sobre qualquer medida é de um agente humano. Esse princípio tem consequências de engenharia. Você precisa de identificadores estáveis para cada análise, de uma trilha de auditoria do que o sistema disse e quando, e de uma interface que apoie a revisão em vez de automatizar uma conclusão.

## 5. Separe os dados que você guarda dos dados que você analisa

Um detector acaba tocando vários bancos: material de referência, análises passadas, metadados operacionais. Prefiro esconder cada um atrás do serviço que o possui, para que o caminho de análise seja testável sem todo o parque de dados e cada base possa mudar no seu ritmo.

## Resumo

- Um contrato para todas as modalidades mantém o sistema extensível.
- Latência é orçamento: paralelize, defina prazos por analisador, aceite resultados parciais.
- Devolva evidências e confiança, nunca um veredito seco.
- Desenhe primeiro a revisão humana. A automação se encaixa em volta dela.

## Referências

- [GuaIA, página do projeto no Instituto de Informática da UFG](https://guaia.inf.ufg.br/)
- [Estudo de caso do GuaIA em adrianoleao.com](https://adrianoleao.com/pt/case-study/guaia)
- [MDN: AbortSignal.timeout() (em inglês)](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/timeout_static)

[Todos os artigos](https://adrianoleao.com/pt/writing.md)