Decisões automatizadas: como garantir revisão humana e explicabilidade

O que conta como decisão automatizada

Conta como decisão automatizada toda decisão que um sistema toma sozinho, ou com participação humana apenas simbólica, e que produz efeito sobre uma pessoa. O ponto de partida operacional é reconhecer que isso acontece em mais lugares do que a empresa costuma imaginar — e que cada um desses pontos gera o dever de poder explicar e revisar. A autoridade de proteção de dados colocou a regulação e a fiscalização desse tema entre suas prioridades^[1].

A definição prática, sem entrar no mérito jurídico

Na prática, é decisão automatizada quando o resultado sai do sistema e vira efeito sem que um humano tenha, de fato, avaliado o caso. Se uma pessoa apenas homologa o que o sistema já decidiu, sem poder ou informação para mudar, a decisão continua sendo automatizada para efeitos de responsabilidade. O que importa para a TI não é a definição legal, mas o teste operacional: houve avaliação humana real e significativa, ou o sistema decidiu e a pessoa só carimbou?

Onde a decisão automatizada acontece na empresa

Ela aparece em crédito, antifraude, recrutamento e priorização, entre outros. Um score que aprova ou nega financiamento, um antifraude que bloqueia uma compra, uma triagem que descarta currículos antes de um humano ver, um sistema que define limite ou prioridade de atendimento — todos são decisões automatizadas que afetam pessoas. O primeiro trabalho da TI é mapear esses pontos: listar onde, na empresa, um sistema decide sozinho algo que impacta um cliente, um candidato ou um usuário. Esse inventário costuma revelar mais pontos do que os gestores esperavam.

O direito do titular em termos operacionais

Traduzido para a TI, o direito do titular é: a pessoa afetada pode pedir revisão da decisão e receber uma explicação do critério que a produziu. Isso não se resolve com uma cláusula na política de privacidade — é requisito de sistema. Não adianta a política dizer que o titular pode contestar se o sistema não registrou por que decidiu daquele jeito, com quais dados e em que momento. O direito só existe de verdade se a arquitetura o sustentar: registro, explicação e caminho de revisão.

Logging da decisão, não só do acesso

O registro que importa aqui é o da decisão em si — não apenas o de quem acessou o quê. Log de acesso conta quem entrou no sistema; log de decisão conta o que o sistema decidiu, quando, para qual titular, com quais dados de entrada e qual regra ou modelo produziu o resultado. Sem esse segundo registro, não há como explicar nem revisar uma decisão depois que ela foi tomada.

Por que o log de acesso não basta

Porque saber quem acessou não diz nada sobre por que o sistema decidiu. Um log de acesso robusto registra sessões, logins e consultas — informação útil para segurança, inútil para explicar uma negativa de crédito. Para responder "por que esta pessoa foi negada?", é preciso um registro do evento de decisão: o resultado, o titular, o carimbo de tempo, os dados que entraram e a lógica que os processou. É um tipo de log diferente, com propósito diferente, e precisa ser projetado de propósito.

O registro das variáveis que pesaram

Registrar quais dados de entrada influenciaram a decisão é o insumo bruto da explicabilidade. Sem saber o que entrou, ninguém explica por que saiu aquele resultado. Isso significa guardar não só o resultado, mas as variáveis relevantes que o sistema considerou — renda informada, histórico, comportamento, sinais de risco. O equilíbrio é registrar o suficiente para reconstruir a lógica da decisão sem transformar o log em um novo depósito de dados sensíveis sem propósito. Guarda-se o que é necessário para explicar e revisar.

Versionamento de modelo e regra

Saber qual versão do modelo ou do conjunto de regras decidiu em cada momento é o que permite revisar uma decisão passada. Modelos e regras mudam; para reconstruir por que alguém foi negado há três meses, é preciso saber qual versão vigorava então — não a atual. Esse controle é especialmente relevante para média e grande empresa com modelos próprios.

Explicabilidade: traduzir o critério para quem foi afetado

Explicabilidade é a capacidade de transformar o critério técnico da decisão em uma explicação que o titular entenda. Não é publicar o modelo nem virar uma equação para o usuário: é dizer, em linguagem acessível, quais fatores levaram àquele resultado. É o ponto em que o registro vira comunicação — e onde mora a tensão mais delicada do tema.

Explicabilidade em linguagem do titular

A explicação precisa fazer sentido para uma pessoa que não é técnica. "Seu pedido foi negado porque o histórico de pagamentos e a renda informada ficaram abaixo do critério para este limite" é uma explicação; despejar pesos de variáveis ou o output cru do modelo não é. O trabalho da TI é fornecer a matéria-prima — as variáveis que pesaram e a lógica geral — de um jeito que a área de atendimento ou privacidade consiga traduzir em linguagem cotidiana. Explicabilidade que só um cientista de dados entende não cumpre o requisito.

Explicabilidade sem entregar o segredo de negócio

Existe uma tensão real entre explicar o suficiente e proteger o modelo, e ela precisa ser tratada com honestidade. Explicar a decisão não obriga a revelar o algoritmo proprietário nem o peso exato de cada variável — mas também não autoriza esconder tudo atrás de "é confidencial"^[4]. O caminho defensável é explicar os principais fatores que levaram ao resultado, em nível que permita ao titular entender e contestar, sem expor a engenharia interna. É um equilíbrio, não um extremo: nem transparência total do código, nem opacidade completa.

O fluxo de revisão humana

O fluxo de revisão humana é o caminho que leva um pedido de contestação a uma reavaliação de verdade por uma pessoa. Ele define quem recebe o pedido, com que informação, em quanto tempo responde e como a resposta volta ao titular. Revisão humana só é real se o humano tiver informação suficiente para, de fato, reavaliar a decisão — caso contrário, é outro carimbo.

Como desenhar o fluxo de revisão

O desenho responde a quatro perguntas: quem recebe o pedido, com que informação, em quanto tempo e como devolve a resposta. Quem revisa precisa receber a decisão, as variáveis que pesaram e o critério — sem esse pacote, não há reavaliação possível. Deve haver um prazo definido para a resposta e um caminho claro de retorno ao titular, informando o resultado da revisão. No menor porte, isso pode ser um canal simples e um responsável que aciona o fornecedor; no maior, um fluxo formal com papéis definidos e SLA.

Revisão da decisão não é supervisão do ciclo de vida da IA

São duas coisas diferentes que não devem ser confundidas. A revisão humana da decisão é reavaliar um resultado específico que afetou um titular, a pedido dele. A supervisão humana no ciclo de vida da IA é o acompanhamento contínuo de como o modelo é construído, treinado e monitorado ao longo do tempo^[2]. Uma não substitui a outra: ter governança do modelo não dispensa oferecer revisão caso a caso, e oferecer revisão não dispensa governar o modelo. Posicionar o fluxo de revisão como direito individual do titular evita tratá-lo como mera etapa de MLOps.

Transparência ao titular

Transparência é informar o titular, de forma acessível, que há decisão automatizada, em que ela se baseia em linhas gerais e como pedir revisão. Isso é parte do requisito, não um extra opcional. A pessoa afetada precisa saber que um sistema participou da decisão e ter um caminho claro para contestar — sem isso, o direito à revisão fica no papel. A transparência não exige revelar o modelo; exige avisar que ele existe e apontar a porta da revisão.

Sistemas de terceiros, auditoria e onde este tema se conecta

Terceirizar o modelo não terceiriza a responsabilidade: quando a decisão vem de um fornecedor, o dever de explicar e revisar continua sendo da empresa que usa o resultado. E tudo isso só funciona se os registros ficarem guardados de forma recuperável. Este é o recorte técnico de decisões automatizadas — os temas gerais de LGPD são tratados à parte.

Quando a decisão vem de um fornecedor

Quando a decisão vem de um bureau de crédito, um antifraude ou um ATS de RH, o dever de explicar e revisar não desaparece. A empresa que usa o resultado responde por ele perante o titular — mesmo sem ter construído o modelo. Na prática, isso significa exigir do fornecedor o que ele registra, o que consegue expor sobre o critério e em que prazo responde a um pedido de revisão, e formalizar isso em contrato. A cláusula de explicabilidade deixa de ser detalhe e vira requisito de contratação.

Trilha de auditoria e retenção

Os registros de decisão precisam ser mantidos pelo tempo necessário para atender pedidos de revisão e eventual fiscalização, de forma consultável e protegida. Log que existe mas ninguém consegue recuperar não cumpre a função — a trilha de auditoria só vale se for possível reconstruir uma decisão específica quando ela for questionada. Isso implica pensar retenção (por quanto tempo guardar), recuperabilidade (como localizar a decisão de um titular) e proteção (o registro contém dados que precisam de segurança própria).

Onde este tema encosta na LGPD geral

Este artigo é o recorte técnico — o que a TI implementa. Os fundamentos gerais de proteção de dados são temas vizinhos cobertos à parte: os direitos do titular em geral, as bases legais que fundamentam o tratamento, o relatório de impacto para avaliação de risco e o papel da autoridade de proteção de dados complementam esta leitura sem se repetir aqui. Quando a decisão vier de um agente autônomo de IA, vale também a conexão com a governança de agentes, que trata do sistema que decide — enquanto este artigo trata do direito de quem foi afetado pela decisão.