No outono de 2022, um amigo meu que dirige um armazém de distribuição de peças automotivas em Fontana me ligou, animado. Eles tinham acabado de implantar inspeção visual por IA no recebimento: câmeras industriais sobre a via de entrada, detectando peças faltantes, etiquetas erradas e caixas danificadas automaticamente, muito mais rápido que as verificações manuais. Eu o parabenizei, mas algo me incomodava: a empresa por trás do sistema era uma startup que tinha acabado de fechar sua Série A.
Um ano depois, essa startup faliu. Os serviços em nuvem foram desligados, as atualizações do modelo pararam e, o pior de tudo, o sistema de inspeção estava atrelado à API em nuvem do fornecedor. Quando o serviço morreu, toda a linha de inspeção apagou de um dia para o outro. Meu amigo passou mais de três meses fazendo nova licitação e reimplantando. A alta temporada veio e passou. O que ele perdeu, ele me disse depois, não foi o custo do sistema: foram três meses de retrabalho manual durante a alta temporada e os clientes que foram embora.
Desde então, adicionei uma pergunta obrigatória para todo cliente que considera IA: o que acontece se o seu fornecedor desaparecer? Não se trata de ser negativo. Comprar IA não é como comprar equipamento. Quando você compra uma esteira transportadora, ela é sua. Com um sistema de IA, os modelos, os dados e o código-fonte pertencem ao fornecedor por padrão. Enquanto o fornecedor existe, está tudo bem. Quando ele some, você não consegue nem abrir o sistema.
Um contrato sem cláusulas de saída não é um contrato
A maioria dos contratos com fornecedores de IA tem exatamente uma linha sobre a saída: "Os serviços cessarão em até 30 dias após a rescisão." Isso é o mesmo que nada. Na verdade, quatro coisas precisam estar incluídas.
Primeiro, escrow do código-fonte. O código-fonte, os pesos do modelo e a documentação de implantação vão para um agente de escrow neutro, com gatilhos de liberação bem definidos: falência do fornecedor, interrupções de manutenção além de um número acordado de dias, linha de produto descontinuada após uma aquisição. Se qualquer uma dessas ocorrer, o escrow é liberado para você. Sem isso, no dia em que seu fornecedor falir, você não consegue nem ver como o sistema é por dentro.
Segundo, devolução dos dados. Formato, prazo e completude precisam ser especificados: em que formato os conjuntos de dados brutos e rotulados retornam (não algum formato proprietário que você não consegue abrir), quantos dias após a rescisão, e o fornecedor deve apagar suas cópias depois. Pule esta cláusula e seus dados operacionais são um presente gratuito.
Terceiro, propriedade dos pesos do modelo. Um modelo treinado com seus dados: de quem são os pesos? Muitos contratos os atribuem ao fornecedor por padrão, ou usam evasivas como "propriedade conjunta". Insista em uma linguagem clara: modelos e pesos derivados treinados com os dados do cliente pertencem ao cliente. Se o fornecedor não concordar, consiga no mínimo uma licença perpétua e irrevogável que sobreviva à rescisão.
Quarto, suporte de transição. Após a rescisão, o fornecedor oferece vários meses de suporte operacional somente leitura, ou concede o direito de auto-hospedar. A migração não acontece da noite para o dia. Sem uma janela de transição, o sistema antigo morre antes de o novo entrar no ar, e ninguém cobre o intervalo entre os dois.
Os vendedores vão dizer na assinatura que são uma empresa grande, que acabaram de levantar capital, que nunca vão falir. Não acredite. Muitas startups de IA bem financiadas morreram nos últimos anos, e muitas outras foram adquiridas apenas para terem suas linhas de produto descontinuadas. O resultado para você é o mesmo: ninguém mantém seu sistema.
A única coisa verdadeiramente sua são os dados
Recuemos um passo: mesmo com um contrato perfeito, se o fornecedor realmente sumiu, o que mantém sua operação funcionando? Os dados. Modelos podem ser substituídos, fornecedores podem ser substituídos. O que não pode ser substituído são os dados rotulados e as regras de negócio que você acumulou ao longo dos anos.
Dados rotulados são seu ativo principal. Amostras de defeitos da inspeção visual, logs de correção do picking por voz, pedidos históricos que alimentam a previsão de demanda: o fornecedor construiu tudo isso sobre o seu negócio, e o contrato deve dizer que pertencem a você. Com os dados em mãos, o retreinamento com um novo fornecedor leva meses. Sem eles, você começa do zero, e isso leva anos. Durante a alta temporada, essa diferença é o que separa sobreviver de não sobreviver.
As regras de negócio são igualmente valiosas. Os limiares, a lógica de tratamento de exceções e as regras específicas do processo embutidas no sistema de IA — quais categorias de produto têm quais padrões de inspeção, por exemplo — devem ser exportadas como documentação em um cronograma regular, não ficar paradas no sistema do fornecedor. O pior caso que já vi não foi um modelo perdido; foram três anos de padrões de inspeção vivendo inteiramente no banco de dados de configuração do fornecedor. Quando o fornecedor saiu, os padrões saíram com ele, e o fornecedor substituto teve que reaprender tudo.
Então os modelos open-source podem assumir? Minha opinião: depende do caso de uso. Cenários maduros como inspeção visual e OCR têm muitas opções open-source, e o custo de migração é majoritariamente re-rotular e re-integrar: um par de engenheiros de ML internos pode cuidar disso. Mas casos de uso profundamente acoplados como otimização de agendamento ou previsão de demanda, onde a lógica de negócio está emaranhada com seus sistemas de armazém, são outra história. Trocar de fornecedor ali significa reconstruir metade do projeto. Pergunte isto durante a seleção: se este fornecedor desaparecesse, eu conseguiria assumir a um custo razoável? Se a resposta for não, ou não implante, ou coloque o custo de saída no custo total de propriedade.
Faça um exercício de saída todo ano — de verdade
Cláusulas escritas, dados garantidos, falta um passo: praticar. Ninguém acha que um simulado de incêndio é um mau agouro, e um exercício de saída é a mesma coisa. Uma vez por ano, exercício simples: suponha que o fornecedor suma amanhã, e passe alguns dias verificando três coisas: os dados podem ser exportados por completo, os modelos podem rodar no seu próprio ambiente, e os processos críticos de negócio têm uma alternativa manual que não depende do fornecedor?
O primeiro exercício quase sempre falha: os dados exportados estão sem campos, o modelo depende das bibliotecas proprietárias do fornecedor, algum relatório crítico só existe no portal do fornecedor. Falhar é boa notícia: significa que o plano tem falhas, e você pode corrigi-las enquanto o fornecedor ainda existe. Tentar corrigi-las depois que o fornecedor sumiu é tarde demais.
Não precisa ser elaborado. Seu líder de TI conduz, as operações participam, uma vez por ano, de meio dia a um dia inteiro. Seguro barato, e a única prova de que o plano não é só papel. Um benefício extra: guarde o relatório do exercício arquivado. Na próxima renovação, é alavancagem: quando o fornecedor sabe que você pode sair, os aumentos de preço ficam muito mais modestos.
Então, voltando à pergunta original: a IA vale a pena? Sim — mas só se você tiver uma saída. Durante a seleção do fornecedor, não fique só maravilhado com a demo. Faça mais uma pergunta: se sua empresa não existir no ano que vem, o que acontece com meu sistema? A resposta diz se este fornecedor merece sua assinatura.
Três coisas que você pode fazer amanhã: primeiro, adicione uma cláusula de escrow de código-fonte com gatilhos de liberação a qualquer contrato de IA que você esteja negociando; segundo, para sistemas já em produção, solicite uma exportação completa dos dados e verifique se ela é realmente utilizável; terceiro, coloque um exercício de saída anual no calendário, com o primeiro no próximo mês. Não espere: quando esse dia chegar, ninguém vai te enviar um aviso.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
