Não comece negociando um limite genérico de responsabilidade. Primeiro descreva os cenários de falha, identifique quem controla cada causa, defina a evidência preventiva e associe um remédio executável. Em um contrato de IA, responsabilidade, garantia, indenização, seguro, service credit, correção e saída cumprem funções diferentes. A arquitetura comercial deve conectá-las sem duplicar penalidades nem deixar um risco material sem owner.
A regra prática é alocar o risco à parte com maior capacidade de preveni-lo, detectá-lo e reduzir seu impacto. O fornecedor pode controlar código, configuração, práticas de segurança e subcontratados; o cliente controla dados que fornece, decisões humanas, contexto de uso e mudanças em seus sistemas. Modelos de terceiros, regulação e comportamento emergente podem exigir risco compartilhado. Transferir tudo ao fornecedor normalmente aumenta preço, reduz concorrência ou cria uma obrigação impossível de cumprir.
AI Contract Risk Allocation Proof-8: matriz de 32 pontos
Pontue cada classe de zero a quatro: zero é ignorada; um, linguagem genérica; dois, responsabilidade nomeada sem evidência ou remédio; três, controle, evidência, resposta e limite documentados; quatro, cenário testado e remédio operacional. Exija pelo menos 24 de 32, nenhum zero e aprovação dos bloqueadores. O jurídico valida a redação; a matriz garante que negócio, tecnologia, risco e compras negociem o mesmo sistema.
- Resultado e uso — finalidade, usuários, decisões proibidas, supervisão e perdas plausíveis.
- Dados e privacidade — origem, instruções, papéis, uso, retenção, incidente, exclusão e terceiros.
- Segurança — acessos, desenvolvimento, vulnerabilidades, notificações, contenção e recuperação.
- Propriedade intelectual — materiais de entrada, componentes, outputs, defesa de reclamações e substituição.
- Modelos e cadeia de fornecedores — termos, mudanças, disponibilidade, região, versões e subcontratados.
- Qualidade e segurança de IA — avaliações, limites conhecidos, revisão humana, drift e correção.
- Operação e continuidade — SLA, falhas repetidas, suporte, backup, transição e desligamento seguro.
- Regulação e mudança — obrigações de cada parte, cooperação, auditoria, mudança de lei e replanejamento.
Use uma escada de remédios, não uma cláusula única
Para cada risco, percorra sete camadas: prevenção verificável; garantia específica; prazo de correção; service credit ou retenção quando fizer sentido; indenização para categorias definidas de reclamações de terceiros; perdas diretas sujeitas ao limite aplicável; e terminação ou saída assistida quando a falha comprometer a operação. Seguro financia alguns riscos, mas não substitui obrigação, controle ou remédio.
A orientação de garantias do FAR é útil como disciplina: declare exatamente o que está garantido, a obrigação em caso de violação, os remédios, a duração e o processo de aviso. Para IA, evite promessas absolutas como precisão perfeita, ausência total de alucinação ou conformidade automática com toda lei. Prefira garantias testáveis ligadas ao SOW, aos critérios de aceite, às políticas de uso e às avaliações combinadas.
Oito perguntas para construir a matriz de risco
- Qual evento concreto dispara a obrigação?
- Quem controla a causa e quem controla a decisão final?
- Que evidência demonstra prevenção e cumprimento?
- Qual é a primeira resposta: corrigir, substituir, repetir, reembolsar ou interromper?
- Que perdas diretas são plausíveis e como serão calculadas?
- Existe uma reclamação de terceiro que justifique indenização específica?
- Há seguro disponível e ele cobre realmente esse evento?
- Qual acesso, cooperação e documentação sobrevivem ao término?
Separe limite geral, superlimites e exceções
Um limite geral pode cobrir descumprimentos ordinários. Categorias com exposição diferente — por exemplo, privacidade, confidencialidade, segurança ou propriedade intelectual — podem exigir superlimites próprios. Responsabilidade ilimitada deve ser rara, vinculada ao que a lei não permite limitar ou a condutas deliberadamente excluídas do cap. Não copie múltiplos de mercado sem modelar impacto, probabilidade, seguro e capacidade financeira do fornecedor.
O guidance britânico atualizado em 2026 recomenda uma relação explicável entre limite e risco avaliado e alerta que risco excessivo pode virar prêmio de preço ou contrato oneroso. Também distingue proteção de dados de perdas gerais. A matriz deve registrar para cada cenário: owner, controle, faixa de impacto, limite, evidência de seguro, exclusões e risco residual aceito pelo comprador.
Faça garantias que sobrevivam ao aceite
O aceite confirma que uma entrega passou nos testes daquele momento; não elimina defeitos latentes nem obrigações posteriores. Defina prazo, como o defeito será registrado, severidade, tempo de resposta, custo de correção e repetição dos testes. Vincule garantia a especificações controláveis: conformidade com documentação, desenvolvimento profissional, autorizações e licenças declaradas, ausência de uso proibido de dados, controles de acesso e entrega dos artefatos combinados.
Use indenizações para reclamações definidas
Indenização não deve significar 'qualquer coisa que der errado'. Delimite o evento, quem pode reclamar, dever de notificação, controle da defesa, cooperação, aprovação de acordo, exclusões por materiais ou instruções do cliente e relação com o limite aplicável. Reclamações de propriedade intelectual, violação causada por um subcontratado ou uso não autorizado de dados podem exigir tratamento diferente de um defeito de desempenho entre as partes.
Verifique o seguro além do certificado
Solicite coberturas compatíveis com os riscos reais, como responsabilidade profissional/technology E&O, cyber e responsabilidade geral quando aplicáveis. Confirme segurado, território, limite por evento e agregado, franquia, exclusões relevantes, natureza claims-made ou occurrence, data retroativa, subcontratados e obrigação de avisar cancelamento. Um certificado sem exclusões pode criar segurança falsa; ausência de seguro também não torna automaticamente um fornecedor incapaz se houver autofinanciamento demonstrável e risco proporcional.
Três cenários para testar antes de assinar
- Decisão incorreta: o sistema recomenda uma ação que gera perda. Verifique se o fornecedor descumpriu avaliação ou guardrail e se o cliente ignorou revisão humana combinada.
- Incidente de dados: separe dado fornecido incorretamente pelo cliente, falha de acesso do fornecedor e evento em um provedor de modelo. Teste notificação, contenção, investigação, cooperação e custo.
- Interrupção ou mudança de modelo: simule indisponibilidade, aumento de preço, alteração de termos ou retirada de versão. Verifique fallback, substituição, aceite do novo comportamento e direito de saída.
No Brasil, alinhe contrato, DPA e operação aos papéis e deveres efetivamente assumidos no tratamento de dados sob a LGPD; nomenclatura contratual não corrige uma operação incoerente. Regras de responsabilidade, validade de limites, indenizações, seguro e proteção de dados dependem dos fatos e da jurisdição. Este framework não substitui aconselhamento jurídico local.
Conecte risco, SOW, segurança, direitos e aceite
Use https://makinai.co/insights/pt/o-que-incluir-contrato-sow-servicos-ia para estruturar o acordo, https://makinai.co/insights/pt/due-diligence-seguranca-contratar-empresa-ia para validar controles, https://makinai.co/insights/pt/direitos-codigo-dados-prompts-contratar-empresa-ia para ativos e licenças e https://makinai.co/insights/pt/criterios-aceite-marcos-pagamento-projeto-ia para vincular evidência a pagamentos.
Quando envolver a MAKINAI
A MAKINAI pode transformar escopo, arquitetura, dependências e modos de falha em uma matriz de risco negociável antes do contrato, conectando evidência técnica, critérios de aceite, operação e saída. Conheça https://makinai.co/services/pt/consultoria-estrategia-ia-transformacao. A redação final e as decisões sobre responsabilidade devem ser revisadas por assessoria jurídica nas jurisdições aplicáveis.