Quem é responsável quando a IA erra? O que a ficção científica deixou de fora

Quem é responsável quando a IA erra? Não é o modelo. A responsabilidade fica com pessoas e organizações: quem desenvolveu o sistema, a organização que o implementou, o operador que o mantém em funcionamento e, dentro de certos limites, o utilizador que age com base no que ele produz. Nomear estes papéis é fácil. O difícil é decidir, antes do lançamento, qual deles responde por cada decisão.

A ficção científica passou oitenta anos a descrever máquinas que constroem, calculam e falam. A maior parte chegou: o computador que responde a perguntas, o assistente que escreve código, o agente que executa um fluxo de trabalho durante a noite. O género acertou na capacidade e calou-se quanto à responsabilização. Em 2026 a capacidade é barata, por isso a responsabilização é a parte que o dono de um negócio tem de desenhar.

As regras de Asimov (1942)

Em 1942, no conto «Runaround», Isaac Asimov escreveu três regras para os robôs. As histórias clássicas que se seguiram giram em torno de uma regra que encontra uma situação que não previu. O robô obedece à letra, falha o propósito, e ninguém resolveu quem é responsável pelo que acontece a seguir. As regras existiam. Um responsável que respondesse pelo resultado, não.

HAL (1968)

O HAL, o computador de 2001: Odisseia no Espaço (1968), fala, planeia e comanda uma nave espacial. Não tem um dono que assine por ele. Quando o seu juízo e os interesses da tripulação se separam, não há rasto de auditoria que alguém leia, nem condição de paragem acordada, nem via de escalamento. A única supervisão humana que resta é um tripulante desligá-lo à mão. A capacidade chegou primeiro; a responsabilização nunca chegou.

As pessoas que constroem, implementam e operam o sistema, cada uma pelo que controlava. Quem desenvolve responde pela forma como o modelo e o software foram feitos. A organização que implementa responde perante os seus clientes por ter posto IA no seu produto. O operador responde pela operação. O utilizador final responde por agir com base em resultados que podia ter verificado.

Isto não é aconselhamento jurídico. A responsabilidade civil pela IA depende da jurisdição, do contrato e dos factos, e uma reclamação pode assentar no contrato, na negligência ou na responsabilidade do produtor; consulte um advogado antes de confiar em qualquer parte disto. Os enquadramentos públicos apontam no mesmo sentido: os Princípios da OCDE sobre IA responsabilizam os atores de IA de acordo com o seu papel, o NIST AI Risk Management Framework pede às organizações que tornem equipas e pessoas com nome responsáveis pelo risco de IA, e o Regulamento Europeu da IA (AI Act) reparte as obrigações entre prestadores e responsáveis pela implantação.

As lacunas surgem onde os papéis se sobrepõem. Uma empresa que constrói a sua própria ferramenta de IA e a usa com clientes é, ao mesmo tempo, quem desenvolve, a organização que implementa e o operador, e cada equipa parte do princípio de que o risco está com outra. Então, quem responde quando a IA falha nesse caso? Quem tiver sido nomeado antecipadamente, ou ninguém.

A parte barata

Uma plataforma de IA consegue produzir um protótipo funcional numa noite. Nós próprios usamos essas ferramentas, na nossa engenharia e dentro do Vendo AI, o nosso próprio produto de vendas. O resultado continua a precisar de verificação: o 2026 GenAI Code Security Report da Veracode registou uma taxa de aprovação de 56% em segurança em mais de 100 modelos, e no Stack Overflow Developer Survey a confiança dos programadores na exatidão dos resultados de IA caiu de 40% para 29%. Nada disto torna as ferramentas más. Torna-as ferramentas.

A parte cara

O que uma empresa precisa depois do protótipo é de um sistema que continue a funcionar: uma arquitetura que sobreviva ao crescimento, dados tratados corretamente, segurança verificada em vez de presumida e uma pessoa com nome que responda quando algo se avaria às duas da manhã. Para o dono de um produto, a governação da IA resume-se a quatro decisões, registadas por escrito antes do lançamento:

• →Um responsável com nome: uma pessoa, não um comité, que pode parar o sistema e responde pelo resultado.
• →Um rasto de auditoria: o que o sistema recebeu, o que produziu e quem o aprovou, guardado para efeitos de rastreabilidade e explicabilidade.
• →Condições de paragem: onde a IA não pode agir sozinha, como pagamentos, decisões automatizadas sobre pessoas ou qualquer coisa fora do seu âmbito documentado.
• →Uma via de escalamento: quem é chamado, com que rapidez e o que o utilizador vê enquanto uma pessoa assume o controlo.

Nenhuma destas decisões é uma cláusula que um advogado acrescenta no fim. Cada uma muda a arquitetura, a interface, a documentação e o custo de operação, pelo que cada uma pertence à lógica de produto desde o início. Ter uma pessoa no circuito (human in the loop) só significa alguma coisa quando essa pessoa tem autoridade, informação e tempo para contrariar a máquina.

A nossa regra é curta: nenhum desenvolvimento sem lógica de produto. Um operador de produto decide o que merece ser construído, constrói-o para operar e responde pelo resultado. Num produto novo, a responsabilização começa antes da primeira linha de código.

O Leadership Gate é onde a responsabilização se torna uma decisão. Tem um único responsável, o CEO, e termina com razões: avançar, reformular ou recusar. Recusamos quando a lógica de produto não se sustenta, quando o modelo comercial não consegue suportar a operação ou quando não poderíamos assumir a responsabilidade pelo resultado. A sequência completa está descrita em como funciona o nosso processo.

Aplicamos as mesmas regras à nossa própria IA. O caso de estudo do Vendo AI mostra um produto de IA com responsabilização em produção: cada fonte de sinais é um módulo separado, ativado por opção e com a sua própria analítica, e uma conversa pode passar para uma pessoa em tempo real. Neste site, o Vendo AI recolhe contexto e ajuda a marcar uma chamada; não toma decisões comerciais nem emite propostas.

Faça-as à sua própria equipa, a qualquer fornecedor e a qualquer construtor de aplicações com IA que esteja a comparar. As respostas devem ficar por escrito.

• →Quem é o responsável com nome por este sistema em produção?
• →Que decisões pode a IA tomar sozinha e quais precisam da aprovação de uma pessoa?
• →O que fica registado, durante quanto tempo, e quem o lê quando algo corre mal?
• →Que condições param o sistema, e quem é chamado quando isso acontece?
• →Se está a escolher entre um construtor de aplicações com IA e uma equipa: quem responde pelo sistema depois do lançamento?

Se ninguém souber responder à primeira pergunta, o projeto termina no protótipo, por muito depressa que tenha sido feito. Se um produto construído com IA já está em funcionamento, tem utilizadores e estagnou, o Existing Product Review é o percurso em que analisamos o código, a lógica de negócio e o mercado, e decidimos se investimos.

A ficção científica previu as máquinas. As regras para as pessoas à volta delas foram sempre a parte difícil.