Quando uma decisão automatizada causa prejuízo, é comum surgir uma resposta aparentemente simples: “foi o sistema”. Uma pessoa teve uma operação legítima bloqueada, um candidato foi eliminado automaticamente, um conteúdo importante deixou de circular ou uma recomendação produziu uma consequência grave. Como houve participação de software ou inteligência artificial, a máquina parece ocupar o lugar de quem tomou a decisão. O problema é que um sistema computacional não surge sozinho, não escolhe por conta própria onde será utilizado e não define de maneira independente todas as condições de seu funcionamento. A responsabilidade precisa ser procurada na rede de pessoas e organizações que criou, colocou em funcionamento e utilizou aquele sistema.

Isso não significa que sempre exista um único culpado. Sistemas automatizados modernos podem envolver desenvolvedores, empresas fornecedoras de tecnologia, organizações que compram o sistema, profissionais que utilizam seus resultados, gestores que definem políticas, pessoas responsáveis pelos dados e instituições encarregadas de estabelecer regras. Dependendo do caso, diferentes participantes podem ter responsabilidades diferentes.

Para entender essa distribuição, é importante começar pelo próprio significado de decisão automatizada. Algumas decisões são inteiramente realizadas por software. Um sistema verifica determinadas condições e executa uma ação sem pedir autorização a uma pessoa naquele momento. Outras são parcialmente automatizadas: a máquina produz uma classificação, pontuação ou recomendação, mas alguém toma a decisão final.

Essa diferença importa. Um sistema que apenas organiza documentos para facilitar o trabalho de um funcionário não possui o mesmo papel de outro que automaticamente recusa uma solicitação. Entre esses extremos existem muitas possibilidades. Uma recomendação automática pode, na prática, ter tanta influência que raramente é contrariada, mesmo que formalmente exista uma pessoa responsável pela decisão final.

Imagine um banco utilizando um modelo para detectar possíveis fraudes. O sistema analisa uma transação e atribui uma pontuação de risco. Se o valor ultrapassa determinado limite, a operação é bloqueada automaticamente. Um cliente pode então ter uma compra legítima recusada.

Quem causou esse resultado? O desenvolvedor que escreveu parte do código participou da construção do sistema, mas provavelmente não decidiu sozinho que aquela compra deveria ser bloqueada. Cientistas de dados podem ter criado o modelo. Gestores podem ter escolhido o nível de risco aceitável. A instituição financeira decidiu utilizar a tecnologia naquele processo. Dados históricos influenciaram o comportamento do modelo. Outras equipes podem ter definido o procedimento utilizado para corrigir falsos bloqueios.

A resposta, portanto, não está em encontrar uma única linha de código responsável pelo resultado. É necessário reconstruir a cadeia de decisões que permitiu que aquele resultado acontecesse.

Os desenvolvedores possuem uma parte importante dessa cadeia. Eles transformam requisitos em software, escolhem soluções técnicas e implementam mecanismos que podem aumentar ou reduzir determinados riscos. Um erro de programação pode causar danos diretamente. Se um cálculo deveria utilizar determinado valor e, por uma falha no código, utiliza outro, existe um problema técnico relativamente identificável.

Mas nem todo dano causado por software resulta de um erro de programação. O código pode executar perfeitamente aquilo que foi solicitado e ainda produzir consequências inadequadas. Nesse caso, a questão passa da implementação para o projeto do sistema.

Imagine um programa criado para selecionar automaticamente quais solicitações receberão prioridade. Se a regra estabelecida pela organização é inadequada, o software pode aplicá-la sem nenhum defeito técnico. Corrigir o código não resolveria o problema, porque o código está representando corretamente uma política problemática.

Essa diferença é fundamental para discutir responsabilidade. Desenvolvedores não deveriam ser tratados automaticamente como responsáveis por todas as consequências de qualquer sistema que ajudaram a construir. Muitas decisões sobre objetivos, orçamento, prazos, critérios e formas de utilização são tomadas por outras pessoas dentro da organização.

Ao mesmo tempo, a expressão “eu apenas implementei o que pediram” nem sempre elimina toda responsabilidade profissional. Dependendo da função e do contexto, profissionais técnicos podem ter deveres relacionados à segurança, à qualidade e à comunicação de riscos conhecidos. Se alguém identifica uma falha grave e previsível, esconder o problema é diferente de simplesmente não ter autoridade para definir a política da organização.

A empresa que desenvolve um produto também pode possuir responsabilidades próprias. Ela decide como testar o sistema, quais limitações comunicar, quais controles oferecer e em quais condições recomendar seu uso. Se vende uma ferramenta para uma finalidade importante, as afirmações feitas sobre sua confiabilidade podem influenciar a maneira como clientes a utilizam.

Um fornecedor que apresenta um modelo experimental como se fosse praticamente infalível cria uma situação diferente de outro que documenta claramente suas limitações e orienta que determinadas decisões sejam revisadas. Informar riscos não resolve todos os problemas, mas a maneira como uma tecnologia é apresentada faz parte da cadeia de responsabilidade.

A organização que decide utilizar o sistema também possui papel central. Comprar uma ferramenta de outra empresa não transfere automaticamente toda a responsabilidade pelas consequências de seu uso. Quem implanta uma tecnologia precisa avaliar se ela é adequada para a finalidade escolhida e como será integrada ao processo.

Uma ferramenta desenvolvida para ajudar a organizar informações pode não ser adequada para decidir automaticamente quem receberá um benefício. Se uma instituição amplia o uso além das condições para as quais o sistema foi avaliado, novos riscos podem aparecer.

Esse ponto é especialmente importante com inteligência artificial de uso geral. Um modelo capaz de trabalhar com texto pode ser utilizado para resumir documentos, gerar ideias, classificar mensagens ou apoiar inúmeras outras atividades. O fato de conseguir produzir uma resposta sobre determinado assunto não significa que esteja validado para tomar decisões importantes naquele campo.

A responsabilidade também depende de quanto poder foi entregue à automação. Se um modelo apenas oferece uma sugestão que será cuidadosamente analisada por um profissional, existe uma camada adicional de julgamento. Se sua resposta é executada automaticamente, a necessidade de confiabilidade e controle tende a ser maior.

Entretanto, colocar uma pessoa no processo não resolve automaticamente o problema. Existe uma grande diferença entre supervisão real e supervisão apenas formal. Um funcionário pode receber centenas de recomendações por dia e ter poucos segundos para analisar cada uma. Nessas condições, talvez simplesmente aceite o resultado produzido pelo sistema.

Esse comportamento é compreensível. Quando uma ferramenta costuma acertar, pessoas podem desenvolver confiança excessiva em suas recomendações. Além disso, organizações podem estruturar o trabalho de maneira que discordar do sistema seja difícil, demorado ou desencorajado.

Por isso, dizer que “um humano toma a decisão final” não é suficiente. É necessário perguntar se essa pessoa possui informação, tempo, conhecimento e autoridade para realmente revisar a recomendação. Caso contrário, a decisão pode continuar sendo predominantemente automatizada, apesar da presença formal de um funcionário.

Os usuários também podem ter responsabilidades em alguns contextos. Uma pessoa que utiliza uma ferramenta precisa respeitar determinadas limitações e procedimentos, especialmente quando trabalha profissionalmente com ela. Um médico, engenheiro ou outro profissional não deveria tratar automaticamente qualquer saída de um sistema como correta apenas porque veio de uma tecnologia sofisticada.

Mas a responsabilidade do usuário também possui limites. Não é razoável exigir que alguém descubra sozinho falhas técnicas que estavam escondidas ou que compreenda limitações que nunca foram adequadamente comunicadas. Quanto mais difícil é detectar um problema, maior pode ser a responsabilidade daqueles que possuem conhecimento e controle sobre o sistema.

A diferença de poder e informação importa. Uma pessoa comum utilizando um serviço digital geralmente possui muito menos conhecimento sobre seu funcionamento do que a empresa que o desenvolveu. Transferir toda a responsabilidade para o usuário por ter clicado em “aceitar” não representa adequadamente essa diferença.

Os dados formam outra parte da cadeia. Sistemas de aprendizado de máquina podem apresentar comportamentos inadequados porque os dados utilizados no treinamento ou na operação possuem problemas. Informações podem estar incorretas, desatualizadas, incompletas ou representar alguns grupos melhor do que outros.

Se um sistema toma uma decisão errada porque recebeu um cadastro incorreto, é necessário descobrir como aquela informação entrou no processo. Talvez o usuário tenha fornecido o dado errado. Talvez uma organização tenha registrado a informação incorretamente. Talvez dois registros tenham sido confundidos durante uma integração.

Quando modelos aprendem a partir de dados históricos, a situação pode ser ainda mais complexa. O problema pode não estar em um registro individual, mas em padrões presentes em milhares ou milhões de exemplos. Se esses padrões refletem práticas anteriores inadequadas, o sistema pode reproduzi-los.

Nesse caso, não existe necessariamente uma pessoa que decidiu explicitamente produzir cada resultado problemático. Isso não torna a consequência inevitável ou sem responsável. Significa que organizações precisam avaliar os dados e o comportamento dos modelos em vez de assumir que padrões históricos são automaticamente adequados para orientar decisões futuras.

Testes possuem papel importante nessa responsabilidade. Antes de colocar um sistema em uma atividade relevante, é necessário verificar como ele funciona em situações representativas. Isso inclui não apenas medir o desempenho médio, mas procurar tipos de erro que possam produzir danos.

Uma taxa geral de acerto pode esconder diferenças importantes. Um sistema pode funcionar muito bem para a maioria dos casos e apresentar falhas frequentes justamente em um grupo menor. Se ninguém procura por essa diferença, ela pode permanecer invisível até que pessoas sejam afetadas.

A gravidade dos possíveis danos também deveria influenciar a quantidade de cuidado. Um sistema que recomenda músicas pode tolerar erros que seriam inaceitáveis em um equipamento médico. Quanto maior o risco, maior tende a ser a necessidade de testes, supervisão, registros e mecanismos de recuperação.

Esse princípio é comum muito além da inteligência artificial. Elevadores, veículos, equipamentos industriais e medicamentos são tratados de maneiras diferentes de acordo com seus riscos. Não existe razão para imaginar que sistemas automatizados deveriam ser avaliados apenas pela novidade tecnológica.

As instituições públicas e os reguladores entram justamente nesse ponto. Nem todos os riscos podem ser administrados apenas por decisões voluntárias das empresas. Quando uma tecnologia afeta segurança, direitos, relações de trabalho, crédito, saúde ou outros interesses relevantes, regras coletivas podem estabelecer responsabilidades mínimas.

Essas regras podem determinar obrigações sobre proteção de dados, segurança, transparência, revisão humana, documentação ou possibilidade de contestação. As exigências concretas variam entre países e setores, mas a lógica é semelhante: certas responsabilidades precisam existir independentemente da preferência de cada organização.

Isso também impede que a complexidade técnica se transforme em desculpa. Uma empresa não deveria poder escapar de toda responsabilidade simplesmente afirmando que nem seus próprios funcionários conseguem explicar perfeitamente o comportamento de um modelo. Se uma organização decide utilizar um sistema complexo em uma atividade importante, a dificuldade de compreendê-lo é parte do risco que precisa administrar.

Em alguns casos, pode ser necessário limitar a automação justamente porque o sistema não oferece garantias suficientes. A pergunta não deve ser apenas “a IA consegue fazer isso?”, mas “é apropriado permitir que faça isso nessas condições?”.

Essa distinção entre capacidade e autorização é essencial. Um modelo pode conseguir classificar pessoas segundo determinado critério, mas isso não significa que qualquer organização deveria poder utilizar essa classificação para qualquer finalidade. A sociedade já estabelece limites semelhantes para muitas outras tecnologias.

Outro aspecto importante é a possibilidade de contestação. Quando uma decisão automatizada afeta significativamente alguém, a pessoa pode precisar de uma maneira de questionar o resultado. Isso é especialmente relevante quando existem dados incorretos ou situações que o modelo não conseguiu representar adequadamente.

Um bom mecanismo de contestação não pode ser apenas um formulário que envia o caso novamente para o mesmo sistema produzir a mesma resposta. Deve existir alguma forma de examinar a situação e corrigir erros quando necessário.

Para isso, registros podem ser importantes. Se ninguém consegue descobrir quais informações estavam disponíveis no momento da decisão ou qual versão do sistema foi utilizada, investigar um problema se torna muito mais difícil. Sistemas importantes podem precisar manter informações suficientes para permitir auditoria e reconstrução de acontecimentos, respeitando também requisitos de privacidade e segurança.

A possibilidade de corrigir danos depois que acontecem, porém, não substitui a prevenção. Alguns prejuízos não podem ser completamente desfeitos. Uma oportunidade perdida, uma exposição indevida de informação ou um acidente pode produzir consequências permanentes. Por isso, sistemas de alto risco precisam ser projetados pensando também em como impedir falhas graves.

Uma estratégia é não permitir que uma única previsão controle todo o processo. Podem existir limites de segurança, confirmações adicionais e verificações independentes. Em sistemas críticos, redundância significa justamente evitar que uma única falha seja suficiente para causar uma consequência grave.

Também é possível limitar aquilo que o sistema está autorizado a fazer. Um assistente pode preparar uma transferência financeira sem ter permissão para concluí-la. Pode escrever uma mensagem sem enviá-la. Pode identificar uma situação de risco sem tomar sozinho uma decisão definitiva.

Essas restrições não significam que a tecnologia seja pouco capaz. Elas representam escolhas sobre como distribuir autoridade. Quanto maior a capacidade de um sistema produzir consequências no mundo, mais importante se torna decidir quais ações exigem confirmação.

A chegada de sistemas capazes de executar tarefas mais longas torna essa questão ainda mais relevante. Um programa que responde a uma pergunta possui um alcance relativamente limitado. Um agente capaz de acessar serviços, modificar arquivos, fazer compras ou enviar comunicações pode produzir uma sequência muito maior de consequências.

Nesses casos, pequenos erros podem se acumular. Uma interpretação incorreta no início pode orientar várias ações posteriores. Por isso, sistemas mais autônomos precisam de mecanismos para verificar resultados, reconhecer situações inesperadas e pedir ajuda quando necessário.

A autonomia da máquina não deveria ser confundida com independência de responsabilidade. Quanto mais uma organização automatiza um processo, mais importante se torna definir quem acompanha o funcionamento e quem pode interrompê-lo quando algo dá errado.

Existe ainda uma questão cultural dentro das organizações. Quando um sistema funciona bem durante muito tempo, equipes podem parar de questioná-lo. Procedimentos temporários tornam-se permanentes e decisões que antes eram revisadas passam a ser aceitas automaticamente. Aos poucos, ninguém se sente realmente responsável pelo resultado porque “sempre foi assim que o sistema fez”.

Esse fenômeno pode ser tão importante quanto uma falha técnica. Responsabilidade exige que existam pessoas ou estruturas com autoridade clara para acompanhar resultados, receber reclamações e modificar o sistema.

Também é necessário evitar o extremo oposto: procurar uma pessoa individual para culpar por qualquer problema complexo. Sistemas grandes são produzidos por equipes e instituições. Um programador pode ter escrito uma pequena parte sem conhecer todas as condições de uso. Um funcionário pode estar seguindo um procedimento obrigatório. Concentrar toda a culpa no participante mais visível pode impedir que causas estruturais sejam corrigidas.

Uma investigação adequada procura descobrir quais decisões contribuíram para o dano e quais controles poderiam tê-lo evitado. Talvez exista um defeito no código. Talvez os dados sejam inadequados. Talvez a empresa tenha ignorado resultados de testes. Talvez o modelo tenha sido utilizado para uma finalidade diferente daquela para a qual foi desenvolvido. Talvez a supervisão humana fosse apenas nominal.

Muitas vezes haverá mais de uma causa. A responsabilidade pode, portanto, ser compartilhada sem se tornar inexistente. Dizer que várias partes contribuíram para um problema não significa dizer que ninguém responde por ele.

A distribuição concreta de responsabilidade jurídica depende das leis, contratos, setor e circunstâncias de cada caso. Não existe uma regra universal segundo a qual desenvolvedores, fornecedores ou usuários sejam sempre responsáveis. Essa determinação precisa considerar quem tinha deveres, conhecimento, controle e capacidade de evitar o dano.

Ainda assim, existe um princípio útil para compreender o problema: quanto maior o poder de um participante para escolher como um sistema é construído, implantado ou utilizado, maior é a importância de examinar sua responsabilidade pelas consequências previsíveis dessas escolhas.

Isso inclui as instituições que definem as regras do ambiente. Governos, órgãos reguladores, empresas, associações profissionais e outras organizações determinam padrões dentro dos quais tecnologias operam. Se um setor permite automação de alto risco sem requisitos adequados, o problema não está apenas em uma empresa ou desenvolvedor isolado.

A responsabilidade por decisões automatizadas é, portanto, uma questão de organização social tanto quanto de engenharia. Software define processos, mas pessoas definem onde o software terá autoridade. Modelos fazem previsões, mas instituições decidem quais consequências essas previsões podem produzir.

Quando uma decisão automatizada causa dano, perguntar “quem apertou o botão?” muitas vezes é insuficiente. É preciso perguntar quem definiu o objetivo, quem escolheu os dados, quem construiu o sistema, quem avaliou seus riscos, quem decidiu colocá-lo em uso, quem tinha autoridade para supervisioná-lo e quem poderia ter evitado ou corrigido o resultado.

A resposta pode envolver várias partes, em graus diferentes. O que não deveria acontecer é a tecnologia funcionar como um vazio de responsabilidade. Uma máquina pode executar uma decisão, mas não pode servir como explicação final para ela. Quanto mais decisões são automatizadas, mais importante se torna tornar visível a cadeia humana e institucional que concedeu poder ao sistema.