Usar IA com o dado da empresa: o que decidir antes

Alguém da operação descobriu que dá para colar o relatório no chat e pedir um resumo. Funcionou. Em poucas semanas, parte da equipe está colando contrato, planilha de custo e lista de cliente em alguma ferramenta, cada um na própria conta. A diretoria pergunta se aquilo é seguro e ouve duas respostas opostas no mesmo dia. Quando o assunto finalmente chega ao time de tecnologia, ele chega em forma de projeto: queremos usar IA com o dado da empresa. O pedido parece técnico. As decisões que ele esconde não são.

A arquitetura é consequência, não ponto de partida

A primeira resposta que o mercado oferece é um nome. RAG, fine tuning, agente, assistente interno. Cada um vem com uma promessa e um orçamento, e a conversa é confortável porque tem alternativas claras e uma decisão no fim. O problema é a ordem. Essa escolha só faz sentido depois de respondidas três perguntas que quase nunca entram na reunião de abertura: qual dado entra, quem responde quando a resposta sai errada, e quem mantém aquilo de pé no sexto mês.

A diferença técnica entre as abordagens já foi tratada em quando usar RAG, MCP ou fine tuning na empresa. Ela importa, mas importa depois. Antes dessas três respostas, escolher arquitetura é escolher ferramenta para um problema que ainda não tem contorno.

Qual dado entra, e quem autorizou

Dado da empresa não é uma categoria única. Vale separar em três, porque o custo de cada uma sair de casa é diferente.

O primeiro grupo descreve o que já aconteceu: razão contábil, histórico de pedido, movimentação de estoque. É o grupo mais fácil de liberar e normalmente o mais útil, porque é onde estão as perguntas que a gestão repete todo mês. O segundo descreve pessoas: folha, cadastro de cliente, contrato. Aqui entra base legal, e a decisão deixa de ser de TI. O terceiro descreve a regra do negócio: política de desconto, critério de aprovação, margem por linha. É o grupo que ninguém classifica como sensível e é o que a concorrência mais gostaria de ler.

A pergunta prática não é se o dado pode sair. É quem responde por ele hoje. Se a empresa não consegue nomear a pessoa responsável por uma dessas bases, também não vai conseguir aprovar a saída dela. Projeto sem responsável por dado costuma parar na véspera do piloto, quando alguém lê o termo de uso do fornecedor pela primeira vez e descobre que a decisão nunca foi tomada, apenas assumida.

Quem responde quando a resposta está errada

Modelo de linguagem erra com confiança. O erro não se parece com erro: vem bem escrito, no formato pedido, com a mesma segurança da resposta correta. Em processo de controladoria isso é diferente de errar numa planilha, porque na planilha o erro tem fórmula, origem e autor. Dá para auditar. A saída de um modelo, sem desenho adicional, não deixa esse rastro.

Por isso a decisão a tomar antes não é sobre precisão, é sobre alçada. Vale classificar as decisões em três níveis, não em dois. As que podem usar a saída do modelo direto, porque o erro é barato e visível, como rascunho de texto e organização de informação. As que exigem conferência humana antes de virar número oficial, como conciliação, classificação contábil e qualquer coisa que entre no fechamento. E as que não entram, porque o erro só aparece depois do prejuízo.

Quase todo caso útil em empresa média cai no nível do meio. É aí que mora o trabalho real, e é aí que a maioria dos projetos falha por omissão: a conferência não é desenhada, então ela acontece de improviso e consome mais tempo do que a automação devolveu. Quem define a conferência junto com o fluxo chega no fim do mês com ganho. Quem deixa para depois descobre que criou mais uma etapa manual.

Quem sustenta no sexto mês

O custo visível de um projeto desses é o da montagem. O custo que derruba é o da manutenção. Dado muda de formato. Documento é atualizado e ninguém reindexa. Aparece pergunta nova que a base não cobre e o modelo responde de todo jeito, porque é isso que ele faz. O fornecedor troca a versão do modelo e a resposta muda junto, sem aviso.

A pergunta é direta e desconfortável: qual pessoa, com nome, vai olhar isso toda semana, e o que ela deixa de fazer para olhar. Se a resposta for o fornecedor, a empresa está contratando dependência, não capacidade. Se a resposta for ninguém, o projeto já tem data de validade, e ela é mais curta que a do contrato.

Quando a resposta certa é esperar

Existe um caso em que nenhuma arquitetura se justifica, e ele é mais comum do que o mercado admite: quando o dado que alimentaria o modelo ainda não é confiável sem ele. Se o relatório que a diretoria usa hoje já é reconciliado à mão antes de circular, a IA vai acelerar a produção de um número em que ninguém confia. O problema não está na camada de resposta, está na origem.

Nesse caso o projeto de IA é a segunda etapa de um projeto de processo. Inverter a ordem não economiza tempo, apenas torna o erro mais rápido e mais difícil de rastrear. O sinal de alerta é fácil de reconhecer: se a pergunta que se quer fazer ao modelo hoje é respondida por uma planilha que alguém ajusta na mão, o dado ainda não está pronto para sair de casa.

O que fica com a empresa

Decidir antes não é adiar. As três perguntas produzem, por si, material que a empresa não tinha: um inventário do dado que importa, um mapa de quem responde por cada decisão, e uma estimativa honesta do que custa manter. Esse material continua valendo mesmo que nada seja contratado, porque ele descreve o processo da empresa, não a ferramenta do fornecedor.

E quando a decisão de arquitetura chegar, ela chega com critério. A empresa deixa de avaliar demonstração e passa a avaliar aderência: este caminho resolve a pergunta que importa, com o dado que posso liberar, no nível de conferência que meu fechamento exige, com alguém daqui sustentando depois. É essa ordem que a Zyon Lab usa para capacitar o time: a decisão vem antes da ferramenta, e a TI continua no controle do que entra e do que fica.