Limitação de responsabilidade em contrato de serviços de IA

Em um contrato de serviços de IA, a cláusula de limitação de responsabilidade define o valor máximo que o fornecedor pagará se algo der errado e lista os tipos de perda pelos quais ele não pagará em hipótese alguma. O que dá para negociar é o tamanho e a base do teto, as exclusões que podem esvaziá-lo e as exceções (vazamento de dados, confidencialidade, propriedade intelectual, conduta dolosa) que deveriam ficar fora dele. Leia a cláusula como um mapa de quem carrega cada risco, não como texto padrão para passar o olho.

Principais pontos

• O teto é o termo mais visível, mas a base de cálculo (valores pagos ou a pagar, por evento ou no total) é o que decide se ele tem algum significado na prática.
• Exclusões de lucros cessantes e danos indiretos podem retirar justamente os prejuízos que um erro de IA tem mais chance de causar. Leia-as à luz do seu caso de uso real.
• Vazamento de dados, confidencialidade, reclamações de propriedade intelectual e dolo normalmente pertencem fora do teto comum, ou sob um teto separado e mais alto.
• A responsabilidade acompanha o controle: quanto mais claro o contrato sobre quem configura, quem aprova e quem opera, mais fácil fica ver quem responde pelo quê.
• Peça a cláusula cedo, discuta em linguagem simples e peça a um advogado que revise o texto final. Este artigo traz informação geral, não aconselhamento jurídico.

O que uma cláusula de limitação de responsabilidade realmente faz?

Todo contrato de serviços distribui riscos. A cláusula de limitação de responsabilidade é o ponto em que essa distribuição vira números e listas. Em geral ela faz três coisas: estabelece um teto para o total que o fornecedor pode dever a você, exclui por completo certas categorias de perda e indica as exceções em que o teto ou as exclusões não se aplicam.

Ela não decide se o fornecedor errou. Culpa, descumprimento e remédios contratuais são tratados em outras partes do acordo. A cláusula apenas limita até onde as consequências chegam depois que uma reclamação é aceita. É por isso que dois fornecedores com descrições de serviço parecidas podem deixar você com riscos muito diferentes.

Também não substitui controles operacionais. Uma boa cláusula no papel é um péssimo substituto para limites de aprovação, permissões restritas e registros que mostrem o que o agente fez. Para o lado operacional, o guia sobre donos, permissões e rotas dos agentes de IA ajuda a organizar a revisão.

A pergunta mais útil para ter em mente durante a leitura é simples.

Um teto é uma declaração sobre risco, então pergunte para quais riscos ele foi escrito.

Como funcionam os tetos de responsabilidade e qual base é razoável?

Um teto costuma ser expresso de uma de três formas: um valor fixo, um múltiplo da remuneração ou os valores pagos ou a pagar em um período definido. Cada uma se comporta de modo diferente, e as diferenças importam mais do que o número em destaque.

Verifique estes pontos:

• Base: valores pagos tendem a ser baixos no início da relação, porque pouco foi pago até então. Valores a pagar durante todo o prazo são mais estáveis. Pergunte qual deles a minuta usa.
• Período: um teto atrelado a um período recente de pagamentos encolhe se você reduzir o uso ou começar com um projeto inicial pequeno.
• Global ou por evento: um teto global é um único fundo para toda a relação. Um teto por evento se renova, o que favorece você se houver risco de mais de um incidente.
• Reciprocidade: um teto que limita o fornecedor, mas deixa a sua responsabilidade aberta, é um termo unilateral que merece questionamento.
• Relação com a exposição: um piloto pequeno, com pagamentos pequenos, pode gerar um teto muito abaixo do que o agente poderia alcançar se tivesse acesso a cadastros de clientes ou a e-mail de saída.

Esse último ponto é a tensão central. O valor pago mede o que você paga pelo serviço. A exposição mede o que o serviço pode afetar. Um agente que redige notas internas tem exposição baixa. Um agente que envia mensagens a clientes ou altera registros tem mais. Conduza a discussão do teto pelo papel do agente, não pela fatura. A lógica de delimitação por trás disso está em o que incluir no escopo de trabalho de um agente de IA.

Quais exclusões mais importam em um contrato de IA?

A maioria dos fornecedores exclui danos indiretos, incidentais e consequenciais, muitas vezes junto com lucros cessantes, perda de receita e dano à reputação. Em software comum isso é rotina. Em IA merece uma segunda leitura, porque uma resposta errada costuma causar exatamente esse tipo de prejuízo: um negócio perdido, uma entrega atrasada, um custo de imagem depois de uma mensagem errada a um cliente.

Dificilmente você removerá essas exclusões por inteiro. Mas pode pedir ajustes específicos, como prever que o custo de corrigir dados, reenviar comunicações e notificar as pessoas afetadas conta como dano direto.

Outras exclusões e isenções para ler com atenção:

• Isenções sobre resultados: declarações de que as respostas podem ser imprecisas e de que a revisão é sua responsabilidade. Razoável em princípio, mas o contrato deve dizer quais resultados exigem revisão humana e quem a faz.
• Fornecedores de modelos de terceiros: muitos serviços de IA rodam sobre modelos de outras empresas. Cláusulas que negam qualquer responsabilidade por esses modelos deixam uma lacuna. Pergunte o que o fornecedor deve a você quando o modelo subjacente falha ou muda.
• Perda causada pelo cliente: exclusões para prejuízos causados por suas instruções, dados ou configuração são justas. Deixam de ser justas se foi o fornecedor quem desenhou a configuração.
• Mudanças no serviço: verifique se o fornecedor pode alterar o comportamento sem aviso e o que acontece com a responsabilidade quando isso ocorre.

A lista de riscos da OWASP para aplicações com modelos de linguagem é uma referência neutra útil sobre os tipos de falha que acontecem na prática, incluindo injeção de prompt e autonomia excessiva. Lê-la ajuda a decidir quais falhas você quer que o contrato trate.

O que deve ficar fora do teto?

As exceções são o que torna um teto justo. Algumas são quase padrão, outras são negociadas e outras são substituídas por um limite separado e mais alto, às vezes chamado de teto ampliado (super-cap).

Candidatas comuns:

• Dolo e culpa grave: normalmente sem teto, e muitos ordenamentos jurídicos nem permitem limitá-los.
• Quebra de confidencialidade: se o agente guarda o conhecimento interno da sua empresa, o vazamento é o risco central. Peça que fique fora do teto comum ou sob um teto mais alto.
• Proteção de dados e incidentes de segurança: obrigações da LGPD e, quando aplicável, do GDPR europeu podem gerar custos para os quais o teto comum nunca foi dimensionado. O local onde os dados ficam também pesa, e a avaliação de segurança de fornecedor de IA ajuda a levantar essas perguntas.
• Indenização por propriedade intelectual: se um terceiro alegar que o trabalho entregue ou os resultados violam seus direitos, quem se defende e quem paga? Fornecedores costumam oferecer isso para os próprios materiais, mas não para os dados e conteúdos que você fornece.
• Fraude e violações da lei: em geral não podem ser excluídas.

Um meio-termo prático é uma estrutura em níveis: um teto comum para falhas gerais do serviço, um teto mais alto para incidentes de dados e confidencialidade e nenhum teto para conduta dolosa. Se o fornecedor recusar qualquer escalonamento, peça que explique qual risco específico ele não consegue precificar. A resposta é reveladora.

A regulação também influencia o que é negociável. Se o seu uso de IA se enquadrar em um regime como o AI Act da União Europeia, alguns deveres não podem ser afastados por contrato, e a divisão entre fornecedor e quem implanta o sistema passa a importar.

Um cenário ilustrativo: três cláusulas, um incidente

Este cenário é ilustrativo, não um caso real. Uma empresa de serviços tem um agente que redige respostas a consultas de fornecedores e, após aprovação humana, as envia. Um dia o agente usa uma política de entrega desatualizada e sai uma resposta que compromete a empresa com condições que ela não pretendia oferecer. Um fornecedor age com base nela e a empresa arca com o custo.

A cláusula A limita a responsabilidade a uma pequena fração de um período recente de pagamentos, exclui todo dano consequencial e diz que os resultados são de responsabilidade do cliente. O fornecedor deve quase nada, e o custo recai sobre a empresa.

A cláusula B tem o mesmo teto, mas estabelece que o cliente aprova as mensagens de saída e que o fornecedor mantém a base de conhecimento. Aqui a pergunta passa a ser factual: a política desatualizada foi uma falha de manutenção ou um aprovador deixou passar? O contrato ao menos aponta para as evidências certas, como registros de alterações e de aprovações.

A cláusula C acrescenta um dever definido de manter atualizadas as fontes de conhecimento do agente, um processo de aviso de incidentes e um limite mais alto para falhas nesse dever. Isso não torna o fornecedor responsável por todo erro, mas alinha a responsabilidade ao controle.

A lição: a divisão de deveres no contrato muitas vezes importa mais do que o número do teto. Clareza operacional é o que torna as cláusulas de responsabilidade aplicáveis.

Passo a passo para negociar a cláusula

Use esta ordem para manter a conversa prática.

• Descreva o papel e o alcance do agente. Anote o que ele pode ler, gravar e enviar e quais ações exigem aprovação. Essa é a sua declaração de exposição.
• Ordene as falhas que você mais teme. Normalmente: exposição de dados, comunicação externa errada, alteração incorreta de registros e indisponibilidade de um processo importante.
• Peça a minuta da cláusula cedo, antes de fechar as condições comerciais, para que a responsabilidade não seja espremida no final.
• Confira a base do teto, o período e se ele é global ou por evento.
• Leia as exclusões à luz da sua lista de falhas. Marque qualquer falha que caia dentro de uma exclusão.
• Proponha exceções ou um limite mais alto para as falhas mais relevantes, com uma justificativa ligada ao papel do agente.
• Alinhe os deveres: garanta que as responsabilidades de configuração, aprovação, monitoramento e aviso de incidentes estejam escritas no documento de escopo, e não só na cláusula de responsabilidade.
• Verifique como o seu seguro responde. Um corretor pode dizer o que está coberto e o que o contrato precisa sustentar, inclusive em relação a erros de agentes de IA.
• Defina um ponto de revisão. Quando o agente ganhar novos acessos ou o projeto crescer, revise a cláusula. O mesmo vale na renovação ou saída do contrato.
• Peça a um advogado que revise o texto final antes da assinatura.

Como a Be Human aborda o tema

A Be Human define um papel útil por projeto inicial, com a memória, as ferramentas, as permissões e os limites de aprovação que esse papel exige, e registra tudo isso no escopo para que as responsabilidades fiquem visíveis. A operação gerenciada inclui monitoramento, avaliações recorrentes, revisão de permissões e resposta a incidentes, que geram os registros capazes de tornar as conversas sobre responsabilidade factuais. Os termos de responsabilidade são definidos no contrato e é melhor levantá-los durante a definição do escopo, quando o papel e o alcance do agente estão sendo desenhados.

Perguntas frequentes

É possível negociar o teto de responsabilidade com um fornecedor de IA? Muitas vezes sim, ao menos em parte. Fornecedores raramente eliminam um teto, mas podem ajustar sua base, acrescentar um limite mais alto para incidentes de dados e confidencialidade ou incluir exceções. A negociação funciona melhor quando cada pedido está ligado a um risco específico do papel do agente.

O teto deve ser mais alto para IA do que para software comum? Ele deve refletir o que o sistema pode afetar, não a categoria da tecnologia. Um agente com acesso a dados de clientes ou a canais de saída exige mais atenção do que um restrito a rascunhos internos. Descreva o alcance do papel e deixe que isso oriente a discussão.

O fornecedor responde por falhas no modelo subjacente? Depende do contrato. Muitos fornecedores se isentam de responsabilidade por modelos de terceiros, então pergunte o que eles devem a você se um modelo falhar, mudar ou for retirado, e quais são os deveres deles em testes e monitoramento.

Quem é responsável quando um agente toma uma ação errada? O contrato deve dizer quem configura, quem aprova e quem opera. Quando uma pessoa aprova as ações, a responsabilidade costuma ser compartilhada entre aprovador e operador. Limites de aprovação claros e registros permitem estabelecer o que aconteceu e quem controlava cada etapa.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.