A forma mais segura de evitar lock-in não é proibir toda tecnologia proprietária. É exigir, antes da contratação, uma saída executável: inventário de dependências, direitos claros sobre dados e artefatos, formatos de exportação, documentação, custos previsíveis e um teste de transição. O parceiro pode usar serviços proprietários quando eles gerarem valor, mas precisa mostrar como sua empresa manterá poder de escolha.
Trate portabilidade como requisito de arquitetura e operação, não como uma cláusula genérica no final do contrato. O NIST AI RMF pede políticas para riscos de terceiros e processos de contingência quando dados ou sistemas externos falham. O Sourcing Playbook do governo britânico recomenda ligar o plano de saída do fornecedor à mobilização do sucessor ou à internalização do serviço. Em IA, isso precisa incluir modelos, prompts, avaliações, dados derivados, ferramentas, observabilidade e conhecimento operacional.
AI Exit Readiness Proof-8: a matriz de 32 pontos
Pontue cada dimensão de zero a quatro. Zero significa ausência; um, promessa comercial; dois, mecanismo descrito; três, artefato verificável; quatro, mecanismo testado no seu contexto. Exija pelo menos 24 de 32 pontos, nenhum zero e aprovação nos cinco critérios eliminatórios. Defina os pesos antes de receber propostas para que uma demonstração atraente não esconda dependência estrutural.
- Mapa de dependências — modelos, clouds, bancos vetoriais, ferramentas, APIs, identidades, licenças e subcontratados.
- Portabilidade de dados — dados de entrada, saída, metadados, embeddings, logs, avaliações, histórico e políticas de retenção.
- Portabilidade da aplicação — código, prompts, configurações, workflows, esquemas, infraestrutura como código e testes.
- Direitos e acesso — propriedade, licenças, segredos, repositórios, contas, chaves, documentação e acesso administrativo.
- Equivalência funcional — quais resultados devem ser preservados ao trocar componentes, mesmo quando a implementação muda.
- Economia da saída — egress, migração, reconstrução, licenças, suporte, dupla operação e capacidade interna necessária.
- Transição operacional — responsáveis, marcos, continuidade, incidentes, treinamento, reteste e comunicação.
- Evidência e atualização — ensaios, inventário versionado, relatório de lacunas e gatilhos para rever o plano.
Cinco critérios eliminatórios
Elimine ou devolva para esclarecimento qualquer proposta que não permita recuperar dados e artefatos essenciais em formato utilizável; deixe repositórios e contas críticas exclusivamente sob controle do fornecedor; não identifique dependências e subcontratados; cobre pela saída sem uma fórmula e um teto verificáveis; ou se recuse a executar um ensaio de transição proporcional ao risco. Uma boa nota média não corrige nenhuma dessas falhas.
Lock-in não é binário. Há dependência técnica, econômica, contratual, operacional e de conhecimento. Um modelo pode ser substituível, mas os prompts, avaliações e dados de feedback podem não estar documentados. Uma arquitetura pode ser modular, mas somente duas pessoas do fornecedor sabem operá-la. O scorecard deve registrar cada tipo separadamente e indicar quem aceita o risco residual.
O que precisa estar no mapa de dependências
Peça um registro que conecte cada função de negócio ao componente que a suporta: modelo, endpoint, camada de recuperação, banco, ferramenta, fila, política, biblioteca e ambiente. Para cada item, registre proprietário, região, versão, dado processado, permissão, SLA, custo, alternativa e impacto da substituição. Atualize o registro a cada mudança relevante, não apenas na entrega final.
O NIST destaca que riscos podem vir tanto do componente de terceiro quanto da forma como ele é usado. Por isso, a alternativa não precisa produzir código idêntico; ela precisa preservar decisões e controles essenciais. Defina resultados observáveis: qualidade mínima, latência, custo, trilha de auditoria, permissões, recuperação de falhas e intervenção humana.
Dados exportáveis não significam sistema portátil
Solicite amostras reais de exportação durante a seleção. CSV ou JSON pode carregar registros, mas não necessariamente relações, contexto, versões de prompt, proveniência, políticas ou julgamentos humanos. Peça dicionário de dados, esquema, identificadores estáveis, timestamps, origem e documentação das transformações. Verifique também como dados pessoais, segredos e conteúdo licenciado serão excluídos ou retidos ao final.
A Comissão Europeia explica que o Data Act exige, para certos serviços de processamento de dados, interfaces abertas e exportação em formato comum e legível por máquina. Isso é uma referência útil mesmo fora da União Europeia, mas não substitui análise jurídica local nem garante portabilidade de todo sistema de IA. O comprador deve transformar o princípio em artefatos e critérios específicos.
Compare o custo total da dependência
O menor preço inicial pode esconder alto custo de mudança. Modele três cenários: substituição de um modelo, troca de uma plataforma central e término completo do parceiro. Inclua egress, engenharia, revalidação, observabilidade, licenças simultâneas, treinamento, indisponibilidade e apoio pós-saída. Separe valores controlados pelo fornecedor de preços definidos por clouds e plataformas.
Peça taxas unitárias, premissas de volume e um teto para assistência de saída. Registre quais artefatos já estão incluídos na remuneração normal. O objetivo não é obter migração gratuita, mas impedir que informação básica, documentação ou acesso à própria operação se tornem moeda de negociação quando a relação terminar.
Conduza um ensaio pago de saída
Antes de um contrato amplo, contrate um exercício de duas semanas com uma fatia não crítica. Exporte dados e configurações, recrie o fluxo em uma conta controlada pelo cliente, troque um componente, execute o conjunto de testes e produza um runbook. O fornecedor deve registrar tempo, falhas, etapas manuais, custos e diferenças de resultado. Não peça uma migração completa como trabalho gratuito.
Use o mesmo roteiro para finalistas. Pontue completude dos artefatos, tempo até restaurar o fluxo, equivalência funcional, clareza sobre limitações e independência da equipe interna. Um fornecedor maduro não promete portabilidade perfeita; ele identifica o que é transferível, o que exige reconstrução e qual valor justifica uma dependência deliberada.
Trade-offs que a decisão precisa tornar explícitos
- Serviço gerenciado versus autonomia: menor esforço operacional agora contra maior dependência de pessoas e processos externos.
- Plataforma integrada versus arquitetura modular: velocidade e consistência contra substituição mais granular.
- Modelo proprietário versus aberto: capacidade e suporte contra controle e opções de hospedagem.
- Padronização versus diferenciação: formatos comuns facilitam troca; customização profunda pode criar vantagem e custo de saída.
- Conta do fornecedor versus conta do cliente: início rápido contra menor controle sobre histórico, limites, logs e acesso.
Transforme o plano em operação contínua
O contrato deve nomear entregáveis, formatos, frequência de atualização, responsáveis, prazo de acesso, exclusão de dados, assistência, custos e critérios de equivalência. O plano de saída precisa ser revisado quando houver novo modelo, plataforma, integração, subcontratado ou categoria de dados. O modelo britânico de Exit Management reforça a preparação contínua para manter o serviço ao fim do contrato.
Para converter essas provas em obrigações, consulte https://makinai.co/insights/pt/o-que-incluir-contrato-sow-servicos-ia. Para avaliar operação contínua, veja https://makinai.co/insights/pt/como-escolher-parceiro-servicos-gerenciados-ia e, para dependências corporativas, https://makinai.co/insights/pt/como-escolher-empresa-integracao-ia-sistemas-legados.
Quando envolver a MAKINAI
A MAKINAI pode ajudar a mapear dependências, estruturar o scorecard e conduzir um ensaio técnico-comercial de saída antes da contratação maior. O objetivo não é eliminar toda dependência, mas escolher conscientemente onde ela cria valor e preservar alternativas reais onde ela aumenta risco.