Contrato e SLAs para fornecedor end-to-end: checklist decisório antes de assinar

Escolher um fornecedor end-to-end não termina na proposta comercial. O contrato e os SLAs precisam deixar claro quem descobre o problema, quem toma decisões de arquitetura, quem desenvolve, quem publica em produção e quem responde quando o produto não entrega o resultado esperado. Para CTOs, a pergunta central não é apenas quanto custa desenvolver, mas qual risco permanece dentro da empresa depois da assinatura. Um contrato de fornecedor end-to-end bem desenhado reduz ambiguidade sem transformar o projeto em uma disputa burocrática. Em projetos sob medida, há uma diferença prática entre entregar funcionalidades e entregar capacidade operacional. Uma tela pode estar pronta, mas a integração com SAP pode falhar em cenários reais. Um modelo de IA pode responder bem em demonstrações e perder precisão com dados de produção. Uma experiência de realidade aumentada pode funcionar em um aparelho específico, mas não atender às condições de iluminação e conectividade do ambiente industrial. Por isso, o contrato deve combinar entregáveis, critérios de aceite, métricas técnicas e indicadores de negócio. A recomendação mais segura é separar três camadas. A primeira descreve o produto e seus objetivos, incluindo hipóteses, público, jornadas e limites do MVP. A segunda define como a solução será construída e operada, com requisitos de segurança, desempenho, disponibilidade, observabilidade e documentação. A terceira estabelece governança, responsabilidades, propriedade intelectual, transferência de conhecimento, mudanças de escopo e encerramento. Esse desenho também facilita a prestação de contas em projetos apoiados por FAPESC, FINEP ou BNDES. Antes de comparar propostas, use um guia para escolher uma software house para seu projeto e verifique se o fornecedor começa por discovery e auditoria técnica, ou se simplesmente transforma o briefing em uma estimativa de horas. Na prática da OrbeSoft, o diagnóstico vem antes do contrato definitivo porque vender uma squad sem entender arquitetura, dados, dependências e demanda é assumir um risco que depois aparece como atraso, retrabalho ou mudança contratual.

SLA não é sinônimo de disponibilidade. Em um projeto end-to-end, o acordo pode conter compromissos de entrega, suporte, segurança, recuperação e qualidade técnica. O primeiro passo é definir o serviço coberto: ambiente de produção, suporte à aplicação, infraestrutura gerenciada, modelo de IA, dispositivos IoT ou todos esses componentes. Sem essa delimitação, o fornecedor pode alegar que uma falha pertence à nuvem, ao cliente ou a um terceiro. Para software corporativo, os SLIs mais úteis costumam incluir disponibilidade mensal, latência no percentil 95, taxa de erro, tempo para reconhecer um incidente, tempo para iniciar a contenção, prazo para restaurar o serviço e percentual de mudanças com rollback seguro. O percentil 95 é mais informativo do que uma média, pois mostra a experiência de usuários que enfrentam as respostas mais lentas. Cada indicador precisa indicar fonte de medição, janela de apuração, exclusões justificadas e responsável pelo monitoramento. Em IA, acrescente métricas compatíveis com o caso de uso. Podem ser taxa de respostas sem evidência, cobertura de avaliação, precisão em um conjunto de referência, latência de inferência, custo por transação, taxa de intervenção humana e tempo para desativar uma versão problemática. Não prometa uma precisão universal: o contrato deve definir conjunto de avaliação, frequência de atualização, tolerância, viés relevante para o domínio e procedimento de rollback. Para aprofundar essa negociação, consulte o guia de SLAs para modelos de IA. Em AR e VR, o desempenho percebido depende de dispositivo, sistema operacional, renderização, rede e ambiente físico. O aceite deve especificar aparelhos suportados, taxa mínima de quadros quando aplicável, tempo de carregamento, estabilidade da sessão, acessibilidade, condições de iluminação e procedimento para testar diferentes configurações. Em IoT, defina taxa de mensagens recebidas, perda tolerada, tempo de processamento de eventos, autonomia esperada, sincronização, comportamento offline e substituição de dispositivos. Para requisitos de privacidade e segurança, o contrato deve indicar papéis de controlador e operador quando aplicável, subcontratados, localização e retenção de dados, gestão de credenciais, registro de acessos, comunicação de incidentes e exclusão ao término. A Lei Geral de Proteção de Dados, em fonte oficial da ANPD deve orientar a análise jurídica, mas não substitui uma matriz técnica de riscos. Em produtos com IA, o NIST AI Risk Management Framework oferece uma referência pública para organizar identificação, medição e tratamento de riscos.

A cláusula de propriedade intelectual precisa diferenciar ativos preexistentes, componentes de terceiros, bibliotecas de código aberto, materiais genéricos do fornecedor e entregas desenvolvidas especificamente para o cliente. Em geral, o cliente deve ter direito suficiente para usar, modificar, manter e evoluir o produto contratado. O fornecedor, por sua vez, precisa preservar ferramentas, métodos e componentes reutilizáveis que não foram criados exclusivamente para aquele projeto. Essa distinção evita conflitos e torna a negociação mais justa. Peça que o código específico fique em repositório acessível ao cliente desde o início, com histórico de commits, revisão de pull requests e execução de integração contínua. As contas de nuvem, domínios, certificados, lojas de aplicativos, serviços de terceiros e chaves de recuperação também devem estar sob controle do cliente ou em uma estrutura com acesso compartilhado. Se tudo estiver na conta do fornecedor, a empresa pode ter propriedade contratual do código e, ainda assim, não conseguir operar o produto. O code escrow é uma proteção adicional, não um substituto para acesso operacional contínuo. O acordo deve indicar o que será depositado, periodicidade, versão mínima, documentação, scripts de implantação, dependências e eventos que liberam o material, como insolvência, encerramento sem transição ou incapacidade prolongada de suporte. Para contratos com equipes alocadas, o checklist de saída e code escrow para squads ajuda a separar transferência de ativos de continuidade do serviço. A saída deve prever aviso prévio proporcional, inventário de pendências, exportação de dados, revogação de acessos, transferência de conhecimento e suporte durante a migração. Um prazo de 30 a 60 dias pode ser adequado em muitos projetos, mas sistemas críticos ou integrados a operações industriais exigem planejamento diferente. Inclua uma tabela de responsabilidades para os primeiros 15, 30 e 60 dias após o aviso, com pessoas nomeadas, ambientes, documentação e critérios de encerramento. Para não perder time-to-market, não transforme todas essas garantias em uma aprovação jurídica interminável. Use anexos vivos e objetivos: matriz de responsabilidades, catálogo de serviços, critérios de aceite, plano de transição e registro de decisões. A boa governança protege cliente e squad sênior, porque reduz mudanças arbitrárias, evita cobranças contraditórias e dá ao fornecedor condições reais de entregar.