O problema da transferência de conhecimento: o que a sua equipa deve possuir antes que os consultores partam.

O que realmente significa ser proprietário de um sistema de IA

Um projeto de IA tem dois desfechos. O primeiro é o lançamento, celebrado por todos. O segundo é mais silencioso e chega meses depois, quando um fornecedor altera uma forma, uma regulamentação muda ou uma versão do modelo é aposentada, e o sistema começa a fornecer respostas piores. Neste ponto, a pergunta é simples: quem conserta isso?

Se a resposta honesta for "teríamos que chamar os consultores de volta", você não comprou um sistema; alugou um, e o medidor ainda está rodando.

O que significa realmente ser proprietário

Ser proprietário não é uma pasta de documentos entregue no último dia. É ter quatro capacidades práticas dentro da sua empresa:

Operar: Alguém sabe como verificar se o sistema está funcionando hoje e é notificado quando não estiver.
Modificar: Alguém pode ajustar uma regra, adicionar uma fonte de documento ou atualizar um prompt sem abrir um ticket de suporte.
Avaliar: Alguém pode distinguir uma saída boa de ruim, com evidências em vez de impressões.
Substituir: Você sabe o que o sistema depende, o que custaria mover e quem mais poderia fazer o trabalho.

A maioria das transferências entrega apenas a primeira capacidade e pula as outras três. É por isso que os sistemas driftam.

A documentação que importa

A documentação é escrita para cumprir uma cláusula contratual, então descreve arquitetura que ninguém tocará e omite as coisas de que as pessoas realmente precisam. Mantenha a lista curta e exija estas:

Um guia de execução em caso de falha: Os cinco problemas mais prováveis, como cada um parece do lado de fora e os três primeiros passos para cada um. Escrito para a pessoa de plantão, não para um engenheiro.
Um conjunto de avaliação: 100 a 200 casos reais com a resposta correta para cada um, acordados pelas pessoas que fazem o trabalho. Este é o artefato mais valioso de todo o projeto.
Um log de mudanças com motivos: Não apenas o que foi configurado, mas por que uma regra existe. Regras sem motivos são deletadas pelo próximo responsável.
Uma planilha de dependências e custos: Todos os modelos, APIs e fornecedores; o custo mensal de cada um; datas de renovação de contratos; o que quebra se ele desaparecer.
Um mapa de dados: O que dados vão para onde, quem pode vê-los e por quanto tempo eles são retidos. As equipes legais e de segurança precisarão disso sem aviso prévio.

Tudo o mais é opcional. Se um documento não ajudar alguém a operar, modificar, avaliar ou substituir o sistema, é decoração.

As três pessoas que você precisa

Você não precisa contratar uma equipe de aprendizado de máquina. Precisa de três indivíduos nomeados, e deve nomear antes do início do projeto, não durante o último mês.

Um proprietário de negócio que decide o que o sistema deve fazer e mantém o orçamento. Eles aprovam mudanças e dizem não ao escopo expandido. Esta não é uma função técnica.
Um guardião técnico que pode ler a configuração, fazer uma alteração controlada, testá-la e colocá-la em produção. Frequentemente um desenvolvedor existente ou um engenheiro de TI com capacidade reservada. Eles não precisam construir modelos; precisam ser capazes de modificar e implantar o que existe.
Um proprietário de qualidade da área que o sistema atende - o principal manipulador de reivindicações, a enfermeira líder, o chefe de suporte. Eles mantêm o conjunto de avaliação e decidem o que significa "bom". Sem esta função, a qualidade se torna uma questão de opinião em semanas.

O custo total interno: geralmente uma fração de um papel integral para cada um, uma vez que o sistema esteja estável. O modo de falha não é o custo; é que ninguém foi nomeado.

Teste a transferência enquanto ainda pode reclamar

Não aceite documentação como prova da transferência. Faça um teste ao vivo durante as últimas semanas do contrato, enquanto os consultores ainda estão sob contrato.

Escolha uma mudança real - adicione um novo produto à base de conhecimento, aperte uma regra sobre o que o sistema se recusa a responder, troque uma tabela de preços atualizada. Peça à sua própria equipe para fazê-lo, com os consultores na sala mas em silêncio. Cronometre. Então, peça ao seu proprietário de qualidade para executar o conjunto de avaliação e confirmar nada mais quebrou.

Se a sua equipe completar isso em um dia, você é dono do sistema. Se levar uma semana e três perguntas, você identificou exatamente as lacunas a serem fechadas antes que as faturas terminem. Qualquer resultado é muito mais valioso do que um formulário de transferência assinado.

Escreva isso no contrato desde o início. Milestones de transferência, uma equipe de recebimento nomeada e um teste de mudança supervisionado são todos mais fáceis de negociar antes do trabalho começar do que depois.

É assim que construímos na Hercules A, e significa que nossos projetos terminam. E esse é o ponto. A medida de um bom projeto de IA não é a profundidade da integração dos consultores um ano depois - é a confiança com que as suas próprias pessoas alteram o sistema sem chamar ninguém.