Habr AI explicou por que o ChatGPT não deve escrever a especificação técnica de uma empresa para a implementação de AI

A tentação de confiar à IA não apenas a implementação da IA, mas também a preparação de uma especificação técnica parece lógica: rápido, barato e sem longas entrevistas. Mas é precisamente neste passo que o negócio frequentemente recebe um documento bonito que tem pouca conexão com a tarefa real, os processos e as restrições da equipe.

Por que o template não funciona

Quando um gerente ou cliente pede ao ChatGPT para escrever uma especificação para implementação de IA, o modelo geralmente monta um template universal plausível. Ele contém muitas palavras corretas: análise de dados, seleção de modelo, segurança, integração, métricas de qualidade. O problema é que tal texto é construído na probabilidade, não no conhecimento de uma empresa específica.

Ele não sabe como as aprovações são estruturadas, onde os dados estão localizados, quem é responsável pelo suporte e quais soluções já falharam dentro do negócio. Por isso, o documento pode parecer maduro mas permanecer vazio no nível de execução. Frequentemente faltam prioridades, limites do projeto, critérios de aceitação e descrição de exceções.

Ainda pior se a especificação foi escrita por alguém que não entende completamente o domínio, e a IA apenas embrulha essas lacunas em estilo oficial. O resultado não é um documento de engenharia, mas uma imitação convincente. Isso é perigoso desde o início do projeto.

Que problemas surgem

O material discute como a geração de IA é especialmente perigosa para projetos de implementação de IA. Há muitas dependências aqui: qualidade dos dados de origem, restrições legais, custos de infraestrutura, integração com sistemas internos, requisitos de explicabilidade dos resultados. Um texto universal quase inevitavelmente suaviza essas arestas agudas e cria a ilusão de que a tarefa já foi formalizada. Isso significa que os riscos reais do projeto surgem muito tarde, quando o dinheiro já foi parcialmente gasto.

• Formulações permanecem muito genéricas e permitem dezenas de interpretações
• Requisitos de dados e sua qualidade são descritos superficialmente
• Métricas de sucesso são substituídas por KPIs abstratos sem ligação ao negócio
• Prazos e orçamento parecem realistas apenas no papel
• Comparar contratados por tal especificação distorce a imagem, porque todos respondem a um pedido vago

Isso afeta não apenas o estágio de seleção de contratado. Se você distribuir uma especificação fraca para várias equipes e depois ainda pedir à IA para avaliar suas propostas, o erro se expande. O sistema irá comparar respostas com o mesmo template superficial e recompensará os que melhor capturaram as palavras formais, em vez daqueles que entenderam melhor o problema. Como resultado, você pode selecionar um contratado com uma bela apresentação e arquitetura fraca.

Onde a IA é útil

Isso não significa que a IA deve ser removida do processo de preparação de especificação. Ela tem um papel útil, mas é um papel de suporte. O modelo pode ser usado para estruturar informações já coletadas: transformar entrevistas com o cliente em rascunhos de seções, sugerir uma lista de perguntas esclarecedoras, ajudar a verificar lacunas lógicas, padronizar a terminologia.

Ou seja, a IA é bom onde você precisa de um acelerador para trabalho editorial e analítico, não um substituto para a investigação do projeto. Uma abordagem funcional se parece assim: primeiro, a equipe documenta manualmente o objetivo do negócio, o processo atual, restrições, dados disponíveis, proprietários da solução e critérios de sucesso. Depois a IA ajuda a trazer isso para uma forma compreensível, mas não substitui a expertise dos especialistas em domínio, analistas e líder técnico.

Quanto mais caro é o erro de implementação, mais perigoso é confiar ao modelo a formulação de requisitos iniciais sem revisão humana. Apenas depois disso ele passa o texto ao modelo para revisão e edição.

O que isso significa

A conclusão principal é simples: a IA pode acelerar a preparação de especificação, mas não consegue por si só determinar de forma confiável o que precisa ser implementado e como funcionará dentro de uma organização específica. Se você usar o modelo como autor dos requisitos, o negócio corre o risco de comprar não uma solução mas uma incerteza belamente formatada. Especialmente em projetos onde você precisará depois mudar processos, orçamentos e responsabilidades das pessoas. Isso é o que torna tais documentos particularmente caros.