Outsourcing de TI no Brasil: riscos reais, modelos de contrato e o que CTOs precisam saber

O problema que ninguém conta antes de assinar

A maioria dos artigos sobre outsourcing de TI no Brasil foca nos benefícios: redução de custo, acesso a talentos, velocidade. Tudo verdade, em teoria. Na prática, 41% dos contratos de outsourcing de software no Brasil terminam antes do prazo previsto, segundo pesquisa da Brasscom em parceria com a FGV (2025). Os motivos se repetem: entrega abaixo do esperado, turnover de profissionais, disputas sobre propriedade intelectual, e SLAs que nunca são cobrados porque foram mal escritos.

Este post é sobre os riscos reais e como mitigá-los antes de assinar o contrato. Não é teoria jurídica. É o que aprendemos em anos operando dos dois lados (como contratante e como fornecedor).

Modelo 1: escopo fechado (projeto)

No escopo fechado, você define requisitos, o fornecedor estima prazo e custo, e entrega o sistema pronto. Parece simples. Não é.

Onde quebra: requisitos mudam. Sempre. Em projetos de software, a taxa de mudança de escopo média é de 35% entre o início e a entrega (dado do Standish Group, CHAOS Report 2024). Se o contrato é rígido, cada mudança vira um aditivo. Aditivos geram atrito, renegociação e atraso. Em 6 meses, o projeto original é irreconhecível e o contrato não reflete mais a realidade.

Como mitigar: use escopo fechado apenas para projetos com requisitos genuinamente estáveis. Migração de dados, integrações com APIs de terceiros, landing pages. Para produto de software que vai evoluir, escopo fechado é armadilha.

Se insistir no modelo, inclua no contrato: cláusula de change request com tabela de preço por hora de alteração, limite de aditivos (ex: até 20% do valor original sem renegociação), e critérios objetivos de aceite por módulo.

Modelo 2: time & materials (hora técnica)

Você paga por hora trabalhada. Mais flexível que escopo fechado. O risco inverte: agora é o contratante que assume o risco de custo. Se o fornecedor é ineficiente, você paga mais.

Onde quebra: sem controle, a conta explode. Já vimos projetos onde o cliente pagou 2.400 horas para um sistema que, feito internamente, levaria 1.200. O fornecedor não tinha incentivo para ser eficiente.

Como mitigar: defina teto mensal de horas. Exija timesheet detalhado com descrição de atividade por desenvolvedor. Use ferramenta de tracking (Toggl, Clockify) integrada ao Jira/Linear do projeto. Faça review quinzenal de produtividade: horas gastas vs. story points entregues. Se a razão piora consistentemente, tem problema.

Modelo 3: squad dedicado (managed team)

O fornecedor aloca um time completo (devs, QA, PM, designer) que trabalha exclusivamente no seu projeto. Você dirige o produto. O fornecedor gerencia as pessoas.

Onde quebra: turnover. O fornecedor vendeu um time sênior na proposta comercial. Depois de 3 meses, substitui o tech lead por um júnior. Você reclama, o fornecedor diz que "está treinando o novo profissional". O projeto desacelera por 6 semanas enquanto o novo profissional faz onboarding.

Como mitigar: inclua no contrato cláusula de estabilidade mínima de alocação (ex: 6 meses). Se o fornecedor substituir um profissional sem motivo justificado (demissão, doença), aplique penalidade: desconto de X% no mês de transição, ou período de ramp-up sem cobrança. Exija direito de veto sobre substituições.

Os três modelos lado a lado

Cada modelo desloca o risco para um lado diferente da mesa. Não existe o melhor em abstrato, existe o certo para o seu tipo de trabalho.

Critério	Escopo fechado	Time & materials	Squad dedicado
Quem assume risco de custo	Fornecedor	Cliente	Compartilhado
Flexibilidade de escopo	Baixa	Alta	Alta
Previsibilidade de preço	Alta	Baixa	Média a alta
Esforço de gestão do cliente	Baixo	Alto	Médio
Melhor para	Requisitos estáveis, integrações pontuais	Demanda variável, tarefas avulsas	Produto que evolui por meses ou anos
Risco principal	Aditivos e atrito	Conta que infla	Turnover e diluição de senioridade

Na prática, quem precisa reforçar um time interno com poucos perfis específicos costuma ir de staff augmentation, que é uma variação de time & materials com alocação direta no seu time. Quem precisa de um time inteiro tocando um produto do início ao fim se dá melhor com um squad dedicado. E quem só precisa de gente sênior pontual para destravar uma frente específica encontra esses perfis via talentos sob demanda.

A armadilha da propriedade intelectual

No Brasil, pela Lei 9.609/1998 (Lei do Software), a propriedade intelectual do software pertence ao autor (quem escreveu o código), salvo disposição contratual em contrário. Se o contrato de outsourcing não tem cláusula explícita de cessão de PI, o código pode não ser seu.

Parece óbvio incluir. Mas o diabo está nos detalhes.

Código vs. componentes reutilizáveis: o fornecedor pode usar frameworks, bibliotecas e módulos internos que já existiam antes do seu projeto. Esses componentes são do fornecedor, não seus. O contrato precisa diferenciar: "código específico do projeto" (que é cedido ao cliente) vs. "componentes pré-existentes do fornecedor" (que são licenciados ao cliente).

Documentação técnica: PI de software não é só código. Inclui arquitetura, schemas de banco, documentação de API, configurações de infraestrutura. O contrato precisa listar explicitamente o que está incluído na cessão.

Acesso ao repositório: já vimos clientes que contrataram outsourcing por 2 anos e nunca tiveram acesso ao repositório Git. Quando o contrato acabou, receberam um ZIP com o código. Sem histórico de commits, sem documentação de deploy, sem CI/CD. Na prática, ficaram reféns.

Regra simples: exija acesso ao repositório desde o dia 1. O repositório deve estar na sua conta (GitHub, GitLab, Azure DevOps). O fornecedor trabalha nele como colaborador, não como dono.

Dependências e licenças de terceiros: o software que você recebe carrega bibliotecas open source com licenças próprias. A maioria (MIT, Apache) é liberal, mas licenças como GPL podem obrigar você a abrir seu código em certos cenários. Peça no contrato uma cláusula em que o fornecedor declara e mantém uma lista das dependências e suas licenças, e responde por qualquer uso que contamine a sua propriedade. Já vi projeto inteiro comprometido por uma única biblioteca GPL enfiada no core sem ninguém avisar.

Direito moral do autor: a Lei 9.609/1998 permite ceder os direitos patrimoniais do software, que é o que te interessa (usar, modificar, licenciar, vender). O código passa a ser seu para todos os efeitos práticos. Só formalize a cessão por escrito, com objeto claro, porque sem cláusula explícita a titularidade patrimonial pode ficar com quem escreveu.

Contas e credenciais: PI de verdade inclui as chaves do reino. Contas de nuvem, domínios, certificados, chaves de API de serviços pagos, acessos às lojas de app. Tudo isso deve estar em nome da sua empresa, não do fornecedor. Repositório seu com a infraestrutura no nome dele ainda te deixa refém na saída.

SLA: como escrever um que funcione

SLA mal escrito é pior que SLA inexistente, porque dá falsa sensação de segurança.

SLA que funciona na prática: defina 4 a 6 métricas objetivas. Exemplos: tempo de resposta a bug P1 inferior a 2 horas, taxa de bugs em produção menor que 2 por sprint, velocidade do time acima de 80% da média dos últimos 3 sprints, uptime acima de 99.5%.

Cada métrica tem penalidade proporcional e gradual: 1 violação gera alerta formal. 2 violações no trimestre geram desconto de 5%. 3 violações geram direito de rescisão sem multa.

A tabela abaixo é um ponto de partida de SLA que já vi funcionar em contratos de squad. Ajuste os números à criticidade do seu produto, mas mantenha a lógica de métrica objetiva com consequência clara.

Métrica	Alvo	Como medir	Consequência da violação
Tempo de resposta a bug crítico (P1)	menor que 2 horas	timestamp do ticket até início do atendimento	Alerta na 1ª, desconto progressivo na recorrência
Bugs em produção por sprint	menor que 2	contagem no board	Revisão de qualidade obrigatória acima do teto
Velocidade do time	acima de 80% da média dos últimos 3 sprints	story points entregues	Plano de recuperação formal
Uptime do ambiente	acima de 99,5%	monitoramento externo	Desconto proporcional ao tempo fora do ar
Cobertura de testes no core	acima de 70%	relatório de CI	Bloqueio de aceite do módulo

A regra de ouro do SLA: se a métrica não pode ser medida por uma ferramenta ou por um número que ninguém discute, ela não serve. "Boa qualidade" e "atendimento ágil" não são SLA. São desejo.

O modelo back-to-back de pagamento

Este é o modelo que recomendamos para squads dedicados. Funciona assim: o fornecedor só recebe quando o cliente recebe.

Na prática: se o squad está construindo um produto SaaS para o cliente, o pagamento mensal do fornecedor é fixo (base) mais um variável atrelado a entregas mensuráveis. As entregas são definidas no início de cada sprint. Se o sprint entrega 100% dos story points comprometidos, o fornecedor recebe 100% do variável. Se entrega 70%, recebe 70%.

Por que funciona: alinha incentivos. O fornecedor tem interesse direto em entregar rápido e com qualidade. O cliente não paga por horas ociosas.

Cuidado: o variável não pode ser a maior parte do pagamento. Recomendamos 70% fixo, 30% variável. Se o variável for alto demais, o fornecedor vai priorizar velocidade sobre qualidade para garantir receita.

Turnover: o risco mais subestimado

A taxa média de turnover em consultorias de TI no Brasil é de 28% ao ano (dados ABES 2025). Isso significa que, em um squad de 5 pessoas, estatisticamente 1.4 pessoas vão sair em 12 meses.

O custo real de turnover não é só o salário do substituto. É o ramp-up (3 a 8 semanas para atingir produtividade plena), o conhecimento perdido (que estava na cabeça do profissional, não na documentação), e o impacto no moral do time restante.

Como mitigar: exija documentação viva (ADRs, README atualizado, CI/CD documentado). Faça pair programming e code review cruzado para que conhecimento não fique concentrado. Inclua no contrato que o fornecedor mantém um "bench" de profissionais pré-treinados para substituição rápida (prazo máximo de 2 semanas).

Mapa de riscos e mitigação

Vale ter uma visão única dos riscos deste texto, com a mitigação ao lado. É o resumo que eu levaria para a reunião de aprovação do contrato.

Risco	Impacto típico	Mitigação contratual
Mudança de escopo	Aditivos, atrito, atraso	Change request com tabela de hora, limite de aditivos sem renegociação
Conta que infla (T&M)	Custo 2x o necessário	Teto mensal de horas, timesheet, review quinzenal de produtividade
Turnover de sênior	Queda de ritmo por 3 a 8 semanas	Estabilidade mínima de 6 meses, veto sobre troca, bench pré-treinado
Perda de PI	Código pode não ser seu	Cessão explícita + repositório na sua conta desde o dia 1
SLA decorativo	Falsa sensação de segurança	4 a 6 métricas objetivas com penalidade gradual
Refém na saída	Sem histórico, sem deploy, sem docs	Direito de auditoria e transição obrigatória de 30 dias

Como escolher o fornecedor antes de qualquer cláusula

Contrato blindado não salva a escolha errada de fornecedor. Ele só limita o estrago. A seleção pesa mais que qualquer cláusula, e é onde a maioria dos CTOs corre atrás de referência tarde demais.

Peça três coisas antes de fechar. Primeiro, converse com dois clientes atuais e um cliente que saiu. O cliente que saiu conta o que a proposta comercial esconde. Segundo, entreviste as pessoas reais que vão trabalhar no seu projeto, não o time de vendas. É comum a proposta mostrar um sênior estrela que some depois da assinatura. Terceiro, olhe o processo de engenharia: como fazem code review, como versionam, como fazem deploy, como documentam. Fornecedor bom mostra isso sem hesitar, porque tem.

Desconfie de três sinais. Preço muito abaixo do mercado quase sempre vira corte de escopo ou troca de time sênior por júnior no meio do caminho. Resistência a colocar o repositório na sua conta indica que ele quer te manter dependente. E proposta que promete prazo cravado sem discovery é sinal de quem ainda não entendeu o seu problema. Se você precisa de perfis específicos com essa transparência, é exatamente o filtro que aplicamos na nossa rede de talentos.

Checklist de cláusulas antes de assinar

Antes de fechar qualquer contrato de outsourcing de TI, valide ponto a ponto.

• Cessão de PI com escopo detalhado, separando código do projeto de componentes pré-existentes do fornecedor.
• Repositório na conta do cliente desde o dia 1, com o fornecedor como colaborador e não como dono.
• SLA com 4 a 6 métricas objetivas e penalidades graduais.
• Pagamento com componente variável atrelado a entregas, na proporção de 70% fixo e 30% variável.
• Cláusula de turnover com estabilidade mínima de alocação e direito de veto sobre substituições.
• Direito de auditoria técnica por terceiro independente.
• Cláusula de rescisão com transição obrigatória de 30 dias, incluindo repasse de conhecimento e documentação.
• Confidencialidade e tratamento de dados em conformidade com a LGPD, com responsabilidade definida em caso de incidente.

Outsourcing bem feito funciona. Mas funciona quando o contrato protege ambos os lados e quando existem mecanismos concretos de accountability.

Perguntas frequentes

Qual modelo de contrato é o menos arriscado?

Não existe modelo sem risco, existe modelo com o risco no lugar certo. Escopo fechado protege o custo mas engessa a mudança. Time & materials dá flexibilidade mas transfere o risco de custo para você. Squad dedicado equilibra os dois e é o mais indicado quando o produto vai evoluir por meses ou anos, desde que o contrato trate o turnover.

Como garanto que o código vai ser meu de verdade?

Combine três coisas: cláusula explícita de cessão dos direitos patrimoniais, repositório na sua conta desde o primeiro dia e todas as credenciais de nuvem, domínios e lojas em nome da sua empresa. As três juntas. Uma sozinha não basta.

O que fazer quando o fornecedor troca o profissional sênior por um júnior?

Prevenir no contrato. Inclua estabilidade mínima de alocação de 6 meses, direito de veto sobre substituições e penalidade para troca sem motivo justificado, como período de ramp-up sem cobrança. Sem essas cláusulas, você reclama e não tem o que cobrar.

Vale a pena contratar o fornecedor mais barato?

Raramente. Preço muito abaixo do mercado costuma virar corte de escopo silencioso ou troca de senioridade no meio do projeto. O custo de um contrato de outsourcing não está na hora técnica, está no retrabalho e no atraso quando algo dá errado. Compare processo de engenharia e referências, não só o valor da proposta.

Como saber quando usar staff augmentation e quando usar squad dedicado?

Se você tem um time interno forte e só precisa de reforço em perfis específicos, staff augmentation encaixa melhor. Se você precisa de um time inteiro tocando um produto do começo ao fim, com PM, QA e design, o squad dedicado é o modelo certo.

---

Quer estruturar outsourcing com contrato blindado? Fale com a Bradata.