IA em compliance: evidências rastreáveis e aprovação

Comece pelo objeto de evidência, não pelo chat

O primeiro elemento do sistema deve ser uma evidência estruturada, não uma resposta textual solta. Cada registro pode conter identificador da fonte, nome do arquivo, versão, data de coleta, proprietário, localização do trecho, classificação de confidencialidade e uma afirmação extraída. A resposta gerada pela IA deve apontar para esses registros, em vez de substituir os documentos originais.

Esse desenho muda a pergunta de “o que a IA concluiu?” para “quais dados sustentam esta afirmação e quem pode contestá-la?”. Também permite distinguir ausência de evidência, conflito entre documentos e evidência desatualizada. A aplicação pode armazenar um estado como pendente, confirmado, rejeitado ou substituído, com motivo e data para cada mudança. Isso é desenho de software para investigação e controle, não uma decisão sobre conformidade.

• Defina um esquema de evidência antes de escolher o modelo ou a interface.
• Separe o texto original, a extração feita pela IA e a decisão da equipe em entidades diferentes.
• Use identificadores estáveis para fontes, versões, trechos e afirmações relacionadas.

Fontes e referências: [2]

Construa rastreabilidade durante a busca

Documentos devem entrar por um fluxo de ingestão que preserve o arquivo original e produza metadados verificáveis. Depois, o sistema pode dividir o conteúdo em trechos pesquisáveis e recuperar passagens semanticamente relacionadas. A busca semântica é útil quando a pergunta e o documento usam palavras diferentes, mas o resultado ainda precisa carregar o identificador do arquivo, o trecho encontrado e seus atributos para que a origem permaneça visível.

Filtros de atributos ajudam a limitar a busca por período, região, área responsável, idioma ou status do documento. Essa camada é importante porque uma passagem relevante pode ser inadequada para a pergunta atual. Recomenda-se aplicar os filtros antes da geração da síntese e rejeitar respostas quando não houver fonte suficiente. A aplicação também deve registrar a consulta original, a consulta eventualmente reformulada, os resultados recuperados e a versão do índice usada.

Texto externo deve ser tratado como dado não confiável, mesmo quando parece uma instrução. O modelo não deve receber esse conteúdo em um contexto privilegiado nem decidir sozinho quais ferramentas podem ser chamadas. Saídas estruturadas, campos enumerados e validações de esquema reduzem caminhos para que texto importado altere o fluxo do sistema, embora não eliminem todos os riscos. [1]

• Armazene hash ou outro identificador técnico do arquivo para detectar substituições silenciosas.
• Mostre ao usuário o trecho usado, não apenas o nome do documento.
• Defina uma política explícita para documentos removidos, substituídos ou ainda em processamento.

Fontes e referências: [1][2]

Faça a aprovação ser uma etapa do produto

A aprovação não deve ser um comentário informal em uma caixa de chat. Crie uma fila de casos com contexto mínimo suficiente: afirmação proposta, trechos de origem, documentos conflitantes, nível de incerteza, histórico de alterações e ação solicitada. A pessoa responsável deve poder confirmar, rejeitar, solicitar complementação ou encaminhar para outra função, sempre com um motivo registrado.

Permissões devem limitar tanto o que a IA consulta quanto o que cada função pode alterar. Uma pessoa pode validar a classificação de uma fonte, enquanto outra pode aprovar a publicação de uma síntese. O sistema deve evitar que uma aprovação antiga seja reaproveitada automaticamente depois que a fonte, o prompt, o índice ou a regra de extração mudar. Nesse caso, o item volta para revisão ou recebe um estado de desatualização.

Para ações que alteram registros, enviam comunicações ou atualizam sistemas externos, use uma confirmação explícita e registre o pedido, os parâmetros, o resultado e o usuário responsável pela autorização. A IA pode preparar a ação, mas o software precisa controlar a transição de estado. Esse limite torna o fluxo mais previsível sem pressupor que uma aprovação técnica, por si só, resolva uma questão organizacional.

• Use estados claros: novo, em análise, aguardando informação, aprovado, rejeitado e obsoleto.
• Registre quem aprovou, quando, com qual versão do material e por qual motivo.
• Separe permissão para visualizar evidências de permissão para alterar decisões.

Fontes e referências: [1]

Teste a cadeia inteira, não apenas a resposta

Um teste que verifica somente se a resposta parece correta deixa de fora falhas mais perigosas. Avalie se o sistema recuperou a fonte certa, preservou o trecho, aplicou os filtros corretos, identificou conflito, recusou uma instrução inserida no documento e enviou o caso para a fila adequada. Cada etapa pode ter critérios próprios, porque um resultado final plausível pode ter sido produzido a partir de uma origem errada.

Monte um conjunto de casos com documentos atuais, versões antigas, fontes incompletas, textos contraditórios, formatos diferentes e entradas maliciosas. Para cada caso, defina o resultado esperado em termos observáveis, como identificador da fonte, campos extraídos, decisão de encaminhamento e motivo de bloqueio. A avaliação deve ser repetida quando houver mudança no modelo, no prompt, no particionamento dos documentos, nos filtros ou na interface.

Métricas automáticas podem verificar campos e chamadas, mas não devem ser tratadas como substitutas de critérios bem definidos. Compare resultados entre versões, registre regressões e mantenha exemplos de falha junto com o motivo da falha. A prática recomendada é avaliar cedo e continuamente, combinando testes específicos do fluxo com julgamentos sobre relevância e completude. [3]

• Teste a seleção da fonte, a extração, a síntese e a aprovação como pontos separados.
• Inclua casos em que a resposta correta é “não há evidência suficiente”.
• Registre entradas, saídas, fontes recuperadas e decisões para reproduzir uma falha.

Fontes e referências: [3]

Use um piloto hipotético para escolher a arquitetura

Considere uma empresa hipotética que recebe políticas internas, relatórios de fornecedores e registros de treinamento em formatos variados. O primeiro piloto não precisa responder perguntas abertas sobre todo o acervo. Ele pode localizar evidências para uma única categoria, apresentar três trechos relacionados, identificar conflitos de versão e criar um caso para aprovação. Essa delimitação torna possível observar onde a equipe perde tempo e quais campos são realmente necessários.

Nesse cenário, a arquitetura inicial pode usar ingestão com metadados obrigatórios, busca híbrida ou semântica, extração em formato fixo, armazenamento de evidências e uma fila de aprovação. A síntese só é produzida depois que os trechos passam por regras básicas de escopo. Se uma fonte não tiver data, proprietário ou versão, o sistema pode classificá-la como incompleta e pedir tratamento específico, em vez de preencher lacunas por inferência.

A decisão entre um fluxo simples e um agente com ferramentas deve seguir a necessidade real do processo. Se as etapas forem previsíveis, um workflow com transições explícitas costuma ser mais fácil de testar e explicar. Mais autonomia só faz sentido quando houver uma tarefa que realmente exija escolha dinâmica e quando os testes conseguirem detectar chamadas indevidas. O objetivo do piloto é aprender quais controles são necessários para o trabalho, não apresentar a IA como árbitro final.

• Escolha um único tipo de evidência e uma única fila de aprovação para o piloto.
• Defina previamente quais mudanças exigem nova análise do caso.
• Interrompa a geração quando a fonte estiver ausente, conflitante ou fora do escopo.

Fontes e referências: [1][3]