Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
Em resumo
Uma demonstração de IA costuma ir bem na sala de reunião. A equipe aprova, e o projeto entra em uma fila de ajustes que dura meses. Depois, outro time começa um novo piloto de IA, com outra base e outra integração. O ciclo se repete porque o teste foi desenhado para demonstrar, sem as condições que a produção exige. O ponto de partida muda quando o piloto nasce sobre o Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
O piloto coloca a IA em um processo de negócio, com usuários reais e prazo definido. A prova de conceito vem antes e verifica se a técnica funciona. O piloto decide se o caso vai para produção, com o volume e os dados do dia a dia.
Em julho de 2024, a Gartner previu que 30% dos projetos de IA generativa seriam abandonados depois da prova de conceito até o fim de 2025. Os motivos apontados foram qualidade de dados ruim, controles de risco inadequados, custos crescentes e valor de negócio pouco claro. Os três padrões a seguir mostram como esses motivos entram no desenho de um piloto de IA.
Para ganhar tempo, o time exporta uma amostra de chamados ou pedidos e corrige os campos à mão. A demonstração vai bem porque o dado foi escolhido por pessoas.
Em produção, o dado vem dos sistemas vivos. O mesmo fornecedor tem dois cadastros e o motivo de cancelamento está vazio em parte dos registros. A qualidade cai, e a integração que o teste evitou precisa ser construída do zero.
O caminho é conectar a fonte real desde o primeiro dia, com escopo menor se for preciso: um tipo de chamado, uma linha de produto, uma região. Os problemas de dado aparecem no teste, quando ainda custam pouco.
O piloto nasce em inovação ou em tecnologia, e a área que vai operar o processo acompanha de longe. A avaliação usa critérios técnicos ou a impressão deixada pela demonstração.
No fim do prazo, ninguém tem autoridade para dizer que o resultado basta. Sem uma linha de base medida antes, não há como mostrar o que mudou no processo, e o piloto fica em extensão permanente.
Antes de começar, a área que herda o processo indica um responsável, escolhe uma métrica de negócio (prazo de fechamento, retrabalho em notas fiscais, tempo de resposta ao cliente) e mede o valor atual. O critério de avanço para a produção fica escrito no início.
Para andar rápido, o piloto usa uma conta de serviço com acesso amplo ou uma cópia dos dados em outro ambiente, sem a participação de segurança, jurídico e privacidade.
Na hora de ir para produção, essas áreas fazem as perguntas adiadas: quem pode ver cada resposta, onde o dado fica, como a LGPD se aplica e como auditar o que o sistema fez. Responder exige redesenhar o acesso, e o redesenho tem o tamanho de um projeto novo.
A segurança entra no desenho desde o início, e cada pessoa acessa o que já pode ver nos sistemas de origem. Cada resposta aponta a fonte, o que dá à revisão algo concreto para avaliar.
O investimento perdido é a parte visível. A maior aparece no projeto seguinte, que refaz a extração de dados, a integração com o mesmo CRM ou ERP, a revisão de segurança e o texto de contexto montado para o modelo. A empresa paga várias vezes pela mesma fundação e nunca a conclui.
Há também o custo por chamada. Com contexto desorganizado, o teste compensa com prompts maiores e modelos mais caros, e o custo por resposta fica acima do que a operação aceita.
A cada teste que não chega à produção, fica mais difícil conseguir tempo e um responsável da área de negócio para o próximo.
O Company Brain conecta CRM, ERP, helpdesk e contratos uma vez, dentro do ambiente da empresa. O grafo de conhecimento liga registros da mesma entidade, a ontologia define cada termo e a camada semântica traduz a pergunta para a consulta certa. O piloto nasce sobre a fonte real.
A permissão é herdada do sistema de origem, e cada resposta aponta o registro de onde veio. A revisão de segurança avalia uma arquitetura única, que vale também para os casos de uso seguintes.
O contexto é servido via MCP a qualquer modelo ou agente. O segundo piloto reaproveita as fontes, as definições e as permissões do primeiro e acrescenta apenas o que falta. Como o modelo recebe só o recorte que a pergunta exige, o custo por resposta cai e a mesma tarefa pode rodar em um modelo mais barato.
A camada de contexto trata o primeiro e o terceiro padrão na arquitetura. O segundo é organizacional. Sem uma área que assuma o processo e uma métrica medida antes, um piloto de IA sobre o Company Brain também termina sem decisão.
As fontes precisam estar acessíveis por API ou banco de dados, e as definições da ontologia dependem do acordo das áreas. Problemas de qualidade aparecem mais cedo e pedem correção na origem.
Antes de aprovar o próximo teste, três perguntas precisam de resposta por escrito: de qual sistema vem o dado real, quem responde pelo processo e com qual métrica medida hoje, e qual permissão cada usuário herda. Uma resposta em branco indica qual padrão o projeto vai repetir.
Para pilotos já parados, o mesmo exercício funciona como diagnóstico. O padrão que travou o projeto indica se o caminho é conectar a fonte real, nomear um responsável ou trazer a segurança para o desenho, e por onde começar o primeiro recorte do Company Brain.