Sistemas de IA que permanecem funcionando

O piloto que impressionou todo mundo

Você provavelmente já viu um morrer. Aquele que iluminou a sala na demonstração – o redator de propostas, a caixa de entrada que fazia a própria triagem – já não importava para ninguém três meses depois. O estagiário que o construiu foi contratado em outro lugar. O prompt foi ficando desatualizado. Ninguém confiava o bastante na saída para parar de conferir à mão; a conferência continuou, e a certa altura virou o trabalho inteiro. Ninguém anunciou um fracasso. Não havia fracasso a anunciar. A equipe simplesmente voltou ao jeito antigo e, depois de um tempo, ninguém se lembrou de cancelar a assinatura.

Quando audito as tentativas anteriores de IA de uma empresa, esse é o padrão que encontro com mais frequência. O modelo quase nunca era o problema. A engenharia em volta do modelo era. Manter IA funcionando em uma empresa de médio porte não é um problema de pesquisa; é um problema de responsabilidade, e responsabilidade é coisa que se projeta.

Seis maneiras de um sistema morrer

Na minha experiência, projetos de IA em empresas de médio porte morrem de formas previsíveis.

• Nenhum dono nomeado. Quem construiu vai embora – o estagiário, a agência, o associado entusiasmado – e ninguém herda o sistema. Software sem dono decai com hora marcada.
• Nenhum monitoramento. As falhas são silenciosas. O sistema para de funcionar numa terça-feira e a empresa só descobre três semanas depois, quase sempre por um cliente.
• Nenhuma suíte de avaliação. Alguém ajusta um prompt, ou o modelo subjacente muda, e a qualidade regride em silêncio. Nada acusa a queda, porque nada estava medindo.
• Nenhum plano de contingência e nenhum kill switch (interruptor de desligamento sob seu controle). A primeira saída ruim chega a um cliente e a confiança morre de vez. Não havia uma forma elegante de pausar o sistema, então a empresa o abandonou.
• Nenhum treinamento. A equipe nunca aprendeu a operá-lo, então passa a contorná-lo, e o processo manual antigo volta em poucas semanas.
• Construído como demonstração. Vivia numa ferramenta paralela que ninguém abre, em vez de dentro do fluxo onde o trabalho de fato acontece. A integração ficou sempre para depois, e o depois nunca chegou.

Repare que nenhum desses seis pontos diz respeito à inteligência do modelo.

Um sistema que falha em silêncio perde a confiança exatamente uma vez. Depois disso, ninguém mais para de conferir à mão.”

O padrão de entrega

A disciplina que evita isso não tem nada de exótico. Uma implantação de IA funcionando merece a mesma engenharia que qualquer software sério recebe – a mesma que costumam vender às empresas de médio porte sem nunca entregar. Todo sistema que coloco no ar sai com esta lista completa, sem exceção, antes de eu considerar o trabalho pronto:

• Implantação funcionando na sua infraestrutura. Versionada e reproduzível, dentro das ferramentas que sua empresa já usa – não uma demonstração no meu notebook.
• Observabilidade. Cada chamada rastreada, cada erro registrado. Quando algo falha, falha em voz alta, diante de alguém que tem a obrigação de ver.
• Uma suíte de avaliação. Um conjunto fixo de casos de teste executado antes de qualquer mudança entrar no ar, para que uma edição de prompt ou uma atualização de modelo não regrida a qualidade em silêncio.
• Um kill switch sob seu controle. Um único botão, sem chamados, sem esperar por mim. Se você quiser o sistema desligado às onze da noite, ele está desligado às onze e um.
• Um runbook (guia operacional de uma página). O que o sistema faz, quem é o dono, o que fazer se algo der errado. Uma página, porque um runbook que ninguém lê é só mais uma falha silenciosa.
• Treinamento da equipe. As pessoas que vão operar o sistema, treinadas antes de eu me afastar. Essa é a diferença entre um sistema que sua empresa usa e um que ela contorna.
• Um compromisso de estabilidade de trinta dias. Depois da entrega, sigo responsável. Se quebrar nos primeiros trinta dias, o problema é meu, não seu.

Nada disso é um argumento para construir tudo do zero. Às vezes o sistema certo se compra, em vez de se construir – expliquei como faço essa escolha em construir ou comprar IA para empresas de médio porte. Mas sistemas comprados morrem das mesmas seis mortes quando ninguém é dono deles. O padrão vale nos dois casos.

O teste

Há um teste que importa, e ele é direto: o sistema continua rodando quando quem o construiu sai da cadeira. Tudo na lista acima existe para passar nele. O dono nomeado, o runbook e o treinamento respondem quem o mantém rodando. O monitoramento e a suíte de avaliação respondem como você sabe que ainda funciona. O kill switch e o plano de contingência respondem o que acontece quando não funciona. Remova qualquer um deles e você volta ao ponto de partida: um piloto que impressionou todo mundo, morto em um trimestre.

Qualquer um consegue entregar uma demonstração. A disciplina é o que ainda roda um ano depois.

Como isso se traduz em noventa dias

Em um projeto Jovadan, esse padrão não é uma aspiração; é a definição de entregue. Ao longo de cerca de noventa dias, coloco em torno de três sistemas funcionando, um por mês, e nenhum conta antes de sair com a lista completa. Responder por IA funcionando, e não por IA em demonstração, é boa parte do que separa o papel de um fornecedor de pilotos, como expliquei em o que faz um Head de IA & Automação (um diretor de IA em regime fracionado).

É também o que torna os resultados duráveis. Os números que aparecem numa revisão de 90 dias – cerca de vinte horas por semana recuperadas, a capacidade de uma contratação em tempo integral liberada, um ganho de 15–25% na margem – só significam alguma coisa se os sistemas ainda estiverem rodando no sexto mês, com a mão do fundador no interruptor e a equipe operando sem mim. O primeiro projeto documentado, Carol Coelho Náutica, foi conduzido exatamente nesse padrão e está publicado de ponta a ponta, para você conferir em vez de acreditar.