Plano de saída de provedor de nuvem: o que avaliar antes de contratar

O que é um plano de saída de provedor de nuvem e por que ele é obrigatório

Plano de saída de provedor de nuvem, ou cloud exit strategy, é o conjunto de procedimentos, garantias contratuais e especificações técnicas que asseguram a uma organização a capacidade de recuperar seus dados, desativar suas aplicações e transferir sua operação para outro provedor ou para infraestrutura própria sem perda de informação, indisponibilidade crítica ou custos proibitivos. Ele não é um desejo de mudança: é um seguro contra falha do fornecedor, encerramento de serviço, reajuste abusivo ou mudança regulatória.

A maioria das empresas só pensa no plano de saída quando já está insatisfeita com o provedor. Nesse momento, é tarde: os dados estão em formatos proprietários, o contrato impõe multas por rescisão antecipada, e o custo de transferência dos dados (egress fee) é suficiente para inviabilizar a migração. A avaliação do plano de saída deve acontecer antes da assinatura, como cláusula de sobrevivência do contrato.

Em mercados maduros de TI, o plano de saída é item obrigatório de governança. A ISO 27017, que trata de segurança da informação em nuvem, recomenda que as partes definam responsabilidades em caso de encerramento do contrato. A LGPD brasileira, embora não mencione explicitamente a palavra nuvem, impõe ao controlador de dados a obrigação de garantir a recuperação e a portabilidade das informações pessoais. Se o provedor não entrega seus dados em formato utilizável, a empresa contratante é quem responde pelo descumprimento legal.

Quais dados e formatos avaliar antes de assinar o contrato

O primeiro elemento de um plano de saída robusto é a clareza sobre o que pertence a você e em que formato você recebe de volta. Muitos contratos de nuvem pública tratam os dados como se fossem da empresa, mas na prática a extração é tão complexa que a propriedade teórica não vale nada.

Dados estruturados: bancos de dados, planilhas, registros de CRM e ERP devem ser exportáveis em formatos abertos como SQL dump, CSV, Parquet ou JSON. Se o provedor só oferece exportação em formato proprietário, exija a conversão ou descarte o fornecedor. O tempo que você levará para converter dados de um formato fechado para um formato aberto pode ser maior do que o tempo de migração em si.

Dados não estruturados: documentos, imagens, vídeos, logs e backups devem ser acessíveis via protocolos padrão (SFTP, rsync, S3-compatible API). A capacidade de fazer download direto, sem intermediários, é fundamental. Se o acesso aos arquivos exige ferramentas exclusivas do provedor, você está construindo uma dependência.

Metadados e configurações: além dos dados em si, é preciso recuperar as configurações de rede, regras de firewall, políticas de acesso, templates de máquina virtual e automações. Sem isso, a migração exige reconstrução manual de todo o ambiente, o que multiplica o tempo de indisponibilidade. Exiga que o contrato garanta acesso a esses metadados em formato documentado.

Chaves de criptografia: se seus dados são criptografados em repouso, quem detém as chaves? Em modelos de criptografia gerenciada pelo provedor (SSE-C, por exemplo), a saída pode ser impossível sem a cooperação do fornecedor. O ideal é adotar criptografia com chaves gerenciadas pelo cliente (CMEK), onde você detém as chaves e pode descriptografar os dados independentemente do provedor.

Como identificar riscos de lock-in tecnológico e contratual

Lock-in é a dependência que impede uma empresa de trocar de provedor sem custo ou esforço desproporcional. Ele pode ser tecnológico (quando a arquitetura depende de serviços exclusivos) ou contratual (quando o acordo impõe barreiras à rescisão).

Lock-in tecnológico: acontece quando você utiliza serviços que não seguem padrões abertos. Bancos de dados proprietários, APIs exclusivas, ferramentas de orquestração específicas e formatos de arquivo fechados criam uma camada de dependência que não existe em infraestrutura baseada em padrões. Um exemplo clássico é o uso de serviços serverless ou de inteligência artificial integrada que só funcionam naquele ecossistema. Quando você decide sair, precisa reescrever aplicações inteiras.

Lock-in contratual: aparece em cláusulas de fidelidade, multas por rescisão antecipada, prazos de notificação excessivos ou obrigatoriedade de pagamento pelo período restante do contrato. Alguns provedores exigem aviso prévio de 90 a 180 dias para cancelamento, o que dificulta respostas rápidas a problemas. Outros incluem cláusulas de renovação automática que prendem o cliente por mais um ciclo completo.

Lock-in econômico: é o mais insidioso. Mesmo que o contrato permita saída e a arquitetura seja padrão, o custo de transferir terabytes ou petabytes de dados pode ser proibitivo. Egress fees de hyperscalers chegam a centavos de dólar por gigabyte, o que em volume grande se transforma em dezenas ou centenas de milhares de reais. O lock-in econômico não precisa de cláusula contratual: a fatura já impede a saída.

Por que os custos de egress podem inviabilizar a saída

Egress fee, ou taxa de saída de dados, é o valor cobrado pelo provedor quando você transfere dados dele para fora, seja para outro provedor, seja para sua própria infraestrutura. Enquanto a entrada de dados (ingress) é quase sempre gratuita, a saída é um dos principais mecanismos de retenção dos hyperscalers.

Em projetos de IA, big data ou streaming, onde o volume de dados processado é enorme, o egress fee pode representar 30% a 50% da fatura mensal. Se a empresa decide migrar, precisa pagar essa taxa uma única vez, mas sobre todo o volume acumulado. Uma empresa com 500 TB de dados pode enfrentar uma conta de egress de centenas de milhares de reais, o que transforma uma decisão técnica em um impasse financeiro.

A avaliação do plano de saída deve incluir uma simulação de custo de egress. Peça ao provedor uma estimativa baseada no seu volume atual e projetado. Se o valor for significativo, negocie isenção ou redução para cenários de rescisão por justa causa, ou prefira provedores que não cobram egress fee. A comparação entre servidor dedicado e servidor nuvem deve incluir essa variável: provedores nacionais como a EVEO operam sem egress fee, o que torna o plano de saída economicamente viável desde o início.

Prazos de migração e divisão de responsabilidades

Um plano de saída sem prazo claro é um plano inexistente. O contrato deve especificar: (1) em quanto tempo o provedor deve disponibilizar seus dados após o pedido de rescisão; (2) em que formato; (3) por quais canais; e (4) quem arca com os custos de infraestrutura durante o período de transição.

Prazo de devolução: o padrão de mercado varia de 30 a 90 dias após o pedido formal. Prazos superiores a 60 dias são inaceitáveis para negócios que dependem de disponibilidade contínua. Além disso, o contrato deve prever que, durante esse prazo, o serviço continua funcionando normalmente, sem degradação intencional.

Divisão de responsabilidades: em modelo de nuvem pública, a responsabilidade é compartilhada. O provedor garante a infraestrutura; o cliente garante os dados e as aplicações. Na saída, essa divisão se complica: quem faz o backup final? Quem desativa as contas? Quem certifica que nenhum dado permanece nos servidores do provedor? O contrato deve deixar claro que a exclusão definitiva dos dados no ambiente do provedor é responsabilidade dele, com prazo e comprovação.

Assistência técnica na transição: alguns provedores oferecem suporte especializado para migração de saída, com engenheiros dedicados por período determinado. Isso é valioso, mas deve estar no contrato, não ser uma gentileza discricionária. Outros provedores oferecem créditos para cobrir parte do egress, o que também deve ser formalizado.

Aspectos regulatórios no Brasil: LGPD e setores críticos

No Brasil, o plano de saída deixa de ser boa prática e se torna obrigação legal quando dados pessoais estão envolvidos. A LGPD estabelece que o controlador de dados deve garantir a portabilidade dos dados pessoais ao titular, o que implica, por extensão, que o controlador deve ser capaz de acessar e transferir esses dados a qualquer momento. Se o provedor de nuvem impede essa portabilidade, o controlador está em descumprimento.

Setor público: órgãos governamentais estão sujeitos às diretrizes do CGI.br e do IN4, que exigem que dados de cidadãos permaneçam em infraestrutura nacional e sob controle da administração pública. Um plano de saída que dependa de aprovação de provedor estrangeiro ou que exija transferência de dados para fora do país em momento de migração viola essas diretrizes.

Setor de saúde: a Resolução Normativa n 467/2012 da ANS exige que dados de beneficiários e prontuários estejam disponíveis para fiscalização no Brasil. Se o plano de saída envolver transferência internacional, mesmo temporariamente, a operadora de saúde pode estar em infração.

Setor financeiro: a Resolução CMN n 4.893/2021 e as normas do Banco Central exigem que instituições financeiras mantenham governança sobre dados de clientes, incluindo a capacidade de recuperação e migração. O plano de saída deve ser auditable e demonstrar que a instituição não perde o controle sobre os dados em nenhuma fase do ciclo de vida do contrato.

Para esses setores, a escolha de um provedor nacional com Data Centers no Brasil e sem egress fee não é apenas estratégica: é uma forma de simplificar a conformidade regulatória. A soberania de dados é mais fácil de demonstrar quando a infraestrutura está sob jurisdição nacional desde o início.

Comparativo: o que hyperscalers e provedores nacionais oferecem

Critério	Hyperscalers Internacionais	Provedores Nacionais
Egress fee	Cobrado por GB transferido; custo proibitivo em volume	Geralmente ausente; saída sem custo adicional
Formato dos dados	Padrão, mas disperso em múltiplos serviços gerenciados	Direto ao servidor; acesso físico ou lógico simplificado
Prazo de devolução	30 a 90 dias; depende do suporte internacional	Negociável diretamente; atendimento local
Soberania de dados	Dados no Brasil, mas controle administrativo no exterior	Dados e controle no Brasil; auditável localmente
Multa por rescisão	Comum em contratos de longo prazo	Rara; modelos de previsibilidade em reais
Assistência na saída	Suporte ticket-based; escalonamento lento	Engenharia local dedicada; resposta ágil
Custo previsível	Variável; fatura afetada por egress, API calls, storage	Fixo mensal em reais; sem surpresas

Esse comparativo não sugere que provedores internacionais sejam ruins. Eles oferecem escala global, ecossistema vasto e inovação acelerada. Mas para empresas brasileiras que priorizam previsibilidade, soberania de dados e facilidade de saída, provedores nacionais apresentam vantagens estruturais que os contratos de hyperscalers raramente oferecem.

A abordagem da EVEO

A EVEO, com mais de 10 anos de mercado, 5.000 clientes e 130 colaboradores, oferece infraestrutura de nuvem privada e servidores bare metal em Data Centers Tier III localizados em Cotia/SP, Osasco/SP, Curitiba/PR, Fortaleza/CE e Miami/FL. Todos os ambientes são operados mediante CNPJ, com foco corporativo e sem atendimento a pessoa física.

O plano de saída da EVEO é simples por design: seus dados estão em servidores que você controla, em formato aberto, com acesso direto via protocolos padrão. Não há formatos proprietários, não há APIs fechadas e não há egress fee. Se você precisa migrar para outro provedor ou voltar para infraestrutura própria, os dados são seus para mover a qualquer momento, sem taxa de saída e sem prazo de espera.

Essa abordagem reflete um princípio de arquitetura: a confiança não é construída com bloqueios, mas com transparência. A EVEO não retém clientes por meio de taxas de saída ou formatos fechados; retém pela qualidade do serviço, pelo suporte técnico local e pela previsibilidade de custos. O custo é fixo em reais, o contrato é flexível e o time de engenharia acompanha a transição quando necessário.

Se você está avaliando um provedor de nuvem e quer garantir que o contrato tenha um plano de saída real, não apenas promessas, a EVEO pode mostrar como isso funciona na prática. O processo de onboard inclui a documentação completa dos formatos de dados, dos canais de acesso e das responsabilidades em caso de migração futura.

Perguntas frequentes