A Responsabilidade pelo Fato da Coisa Inanimada: Aplicações e Implicações

A Questão Central: Pode a IA ser uma "Coisa"?

A aplicação do regime de responsabilidade pelo fato da coisa inanimada aos sistemas de inteligência artificial pressupõe uma questão prévia de ordem ontológica: pode um sistema de IA ser qualificado como "coisa" para fins de direito civil? A resposta a essa pergunta determina, em larga medida, qual regime de responsabilidade se aplica e quem é o sujeito passivo da obrigação de indenizar.

A tradição jurídica civil entende por "coisa" — no sentido do art. 82 e seguintes do Código Civil — os bens corpóreos ou incorpóreos que possam ser objeto de relações jurídicas patrimoniais. Sob essa perspectiva ampla, um software ou um sistema de inteligência artificial poderia, em princípio, ser enquadrado como coisa incorpórea. Essa qualificação teria consequências práticas imediatas: o guardião do sistema — aquele que exerce o controle sobre ele — responderia objetivamente pelos danos que ele causasse, cabendo ao guardião demonstrar a ocorrência de força maior, caso fortuito externo ou culpa exclusiva da vítima para afastar a responsabilidade.

Por outro lado, muitos afirmam que "a IA não é uma coisa" no sentido que o direito civil, ao menos em sua tradição clássica, contempla. Nessa leitura, o dano deve ser decorrente de uma coisa vista como ente passivo — de modo que a culpa recai sobre falhas de manutenção ou omissões de controle do custodiante. Entretanto, na IA, o dano pode nascer de uma "impulsão" artificial — remetendo a uma esfera mais complexa, em que o comportamento do sistema não depende somente de descuido humano, mas de processos decisórios autônomos que o próprio guardião pode não ser capaz de compreender ou controlar.

A Distinção Francesa: Guarda da Estrutura e Guarda do Comportamento

A jurisprudência e a doutrina francesas desenvolveram uma distinção que pode ser útil para enfrentar esse problema: a distinção entre a guarda da estrutura (garde de la structure) e a guarda do comportamento (garde du comportement). A guarda da estrutura refere-se ao controle sobre os elementos físicos e materiais da coisa; a guarda do comportamento refere-se ao controle sobre o modo como a coisa se comporta e sobre os riscos que ela cria pelo seu funcionamento dinâmico.

Essa distinção foi originalmente desenvolvida para resolver conflitos de responsabilidade em casos envolvendo veículos automotores cedidos a terceiros: o proprietário que cede o veículo ao locatário transfere a guarda do comportamento (e, portanto, a responsabilidade pelos danos causados pelo uso), mas pode manter a guarda da estrutura (e, portanto, a responsabilidade por danos decorrentes de defeitos estruturais preexistentes à cessão).

Transposta para o campo da inteligência artificial, essa distinção oferece possibilidades analíticas interessantes. O desenvolvedor de um sistema de IA detém, em princípio, a guarda da estrutura — pois é ele quem concebeu a arquitetura do sistema, definiu seus objetivos de otimização e realizou o treinamento inicial. O operador que implanta e utiliza o sistema detém, por sua vez, a guarda do comportamento — pois é ele quem decide em que contextos e com quais dados o sistema opera. Quando o dano decorre de um defeito estrutural, a responsabilidade recairia sobre o desenvolvedor; quando decorre de uso inadequado ou de contextualização imprópria, sobre o operador.

Dificuldades Práticas: Quem Detém o Controle Efetivo?

A dificuldade está em determinar, na prática, quem detém o controle efetivo sobre um sistema de IA. Se agregarmos à análise as atualizações realizadas pelos desenvolvedores após o lançamento — e o compartilhamento de bases de dados de treinamento e aprendizado em tempo real a que tais tecnologias são submetidas —, a atribuição de controle a um único agente torna-se praticamente inviável.

Considere-se o caso de um sistema de IA utilizado em diagnóstico médico. O desenvolvedor treinou o modelo com um determinado conjunto de dados e o disponibilizou na forma de uma API (interface de programação de aplicações). O hospital contratou o serviço e o integrou ao seu fluxo de trabalho clínico. O médico utilizou a saída do sistema para embasar sua decisão diagnóstica. O paciente sofreu dano. Quem é o guardião do sistema? O desenvolvedor que mantém o modelo atualizado remotamente? O hospital que decidiu implantar e utilizar a ferramenta? O médico que, ao utilizá-la, assumiu responsabilidade pela decisão clínica final?

A resposta varia conforme a natureza do dano: se o erro decorreu de um defeito no modelo de treinamento, o desenvolvedor é o responsável primário; se decorreu de aplicação do sistema a um contexto para o qual não foi projetado, o hospital é o responsável primário; se decorreu de falta de supervisão clínica adequada, o médico compartilha a responsabilidade. Mas em muitos casos concretos, essas distinções são difíceis de traçar — e o dano pode decorrer da combinação de fatores imputáveis a múltiplos agentes.

Sistemas Fechados e Sistemas Abertos: Uma Distinção Relevante

Parte da doutrina sustenta que a configuração da responsabilidade sofre variações conforme a natureza do sistema de IA. Em sistemas fechados — em que o produtor detém maior controle sobre o hardware e o software —, a responsabilidade do desenvolvedor tende a ser mais acentuada, pois ele tem maior capacidade de prever e controlar o comportamento do sistema. Já em sistemas abertos — sujeitos a interferências externas, como a inserção de dados por usuários ou a integração com APIs de terceiros —, o utilizador ou custodiante fica mais exposto ao dever de vigilância.

Nesse contexto, o instrutor ou "treinador" da IA também pode ser responsabilizado se suas interações induzirem comportamentos danosos. Essa hipótese é particularmente relevante para sistemas de IA generativa que são "ajustados" por operadores com dados específicos de determinado domínio: se o ajuste fino (fine-tuning) introduz comportamentos inadequados ou perigosos que não estavam presentes no modelo base, o operador que realizou o ajuste pode ser considerado co-responsável pelos danos resultantes.

A Dupla Barreira: Ontológica e Prática

Diante de tais dificuldades, aplicar o conceito de guarda diretamente a um software ou a uma IA suscita uma dupla barreira: a ontológica, pela ausência de controle contínuo e material sobre o sistema; e a prática, pela própria autonomia do sistema, que pode agir de formas não previstas nem controladas por qualquer dos agentes envolvidos.

Tentar "corporificar" a IA em um robô ou veículo autônomo tampouco resolve integralmente o problema, pois o proprietário do equipamento físico pode apenas ligá-lo ou desligá-lo, sem necessariamente interferir no comportamento interno — controlado por regras elaboradas por terceiros e executadas em locais remotos. A separação entre o substrato físico (o hardware) e o agente decisório (o software e o modelo de IA) é uma característica estrutural desses sistemas que não encontra equivalente preciso nos institutos clássicos da responsabilidade pelo fato da coisa.

Regimes Mistos: Uma Solução Possível

Em alguns casos, a solução talvez resida em regimes mistos — como a combinação de responsabilidade por produto e atividade perigosa, aliada à figura do "fabricante" ou do "programador" principal. O PL 2.338/23 sinaliza nessa direção ao distinguir entre fornecedores e operadores de sistemas de IA e ao atribuir a cada categoria obrigações específicas, criando uma estrutura de responsabilidade que distribui o ônus ao longo da cadeia de agentes em função do controle que cada um exerce.

Em outros casos, seriam demandadas adaptações legislativas específicas — seja para definir presunções de guarda em relação a sistemas de IA, seja para distribuir a responsabilidade em cadeia, como já ocorre no CDC em relação à cadeia de fornecimento de produtos. A experiência de diferentes ordenamentos mostra que o direito dispõe de reflexos históricos que podem, com o devido cuidado e a necessária criatividade hermenêutica, iluminar as questões contemporâneas — ainda que as respostas definitivas estejam, por ora, em processo de formação.