Rob Collie, CEO e Fundador da P3 Adaptive e Autor de Fair Game – Série de Entrevistas

Rob Collie é o fundador e CEO da P3 Adaptive, um Microsoft Solutions Partner para Dados e IA que atende a centenas de clientes de médio porte e da Fortune 1000. Ex‑líder de engenharia da Microsoft nas equipes de Excel, Bing e Power BI, Rob conduziu a onda do Power BI após deixar a Microsoft e escreveu três livros anteriores sobre negócios e tecnologia (mais de 92 000 cópias vendidas). Ele também apresenta o podcast Raw Data with Rob Collie. Seu quarto livro, Fair Game: Customizing AI to Your Business Is Easier Than You Think (agosto de 2026), coloca essa credibilidade de praticante no momento da IA.

Você passou mais de uma década na Microsoft ajudando a desenvolver recursos de business intelligence no Excel e no Power BI antes de fundar a P3 Adaptive em 2013. Como essa transição de construir software dentro da Microsoft para resolver problemas de dados dos clientes moldou sua visão atual sobre IA corporativa?

Quando eu liderava equipes de produto na Microsoft, estávamos construindo software que precisava funcionar para o mundo inteiro, e que não podia ser adaptado às necessidades de um cliente específico. Costumávamos chamar isso de “pedir uma pizza cujos ingredientes fossem aceitáveis para 300 milhões de pessoas”. Há inevitavelmente uma sensação de “denominador comum mais baixo” nesse trabalho, bem como certa distância dos clientes individuais.

Havia um prestígio evidente em trabalhar nesse grande palco, mas não era tão gratificante emocionalmente quanto ajudar clientes específicos a realizarem suas ambições únicas. Ao trabalhar de perto com um cliente, temos a chance de nos envolver em seu sucesso e explorar soluções criativas que nunca se encaixariam no modelo “tamanho único” de grandes softwares. De muitas maneiras, isso é mais estimulante intelectualmente, e a conexão direta com nossos clientes torna as vitórias muito mais satisfatórias.

Mas há também uma responsabilidade maior. Na Microsoft, um único cliente insatisfeito era apenas uma estatística, e eu descartava as reclamações diariamente como parte do simples cumprimento do meu trabalho. Na P3 Adaptive, um cliente insatisfeito significa que falhamos. Não há estatísticas. Temos responsabilidade com cada relacionamento.

Aprendi muitas coisas valiosas na Microsoft e não trocaria essa experiência por nada, mas frequentemente me descrevo como um “engenheiro de software em recuperação”, porque o sucesso agora significa operar de forma muito diferente.

E é exatamente essa perspectiva que levo para a IA corporativa. A IA pronta‑para‑usar é a pizza definitiva para 300 milhões de pessoas – uma verdadeira maravilha, projetada para ser individualmente valiosa para todos, sem ser personalizada para ninguém. Mas os ganhos de IA organizacional virão da personalização – ao se aproximar de uma empresa específica e adaptar a IA aos seus dados, seus processos, suas definições. Passei minha carreira em ambos os lados dessa divisão, e isso me deixa absolutamente certo de que o lado onde a IA corporativa vencerá é o da personalização.

No Fair Game, você argumenta que muitas empresas abordaram a inteligência artificial de forma invertida, distribuindo licenças de chatbots de uso geral em vez de construir sistemas que compreendam suas operações. Onde os assistentes de IA prontos‑para‑usar chegam ao limite, e quais sinais indicam que um negócio precisa de algo customizado?

A IA pronta‑para‑usar tem um PhD em tudo, exceto no seu negócio. Ela leu toda a internet, mas a internet não contém a definição da sua empresa de “cliente ativo”, sua lógica de precificação, seus processos operacionais e qual dos seus dois sistemas deve ser confiado quando discordam. Esse conhecimento nunca será público. Portanto, a IA genérica que é imbatível para uso pessoal fica aquém para uso real em negócios, e a diferença entre as duas experiências é tanto desanimadora quanto confusa.

Hoje, basicamente a resposta de todos a “o que fazer com IA” tem sido “comprar assinaturas e descobrir”. Acho que esse é um primeiro passo natural, então não critico quem já fez isso. Em vez disso, sinto empatia – ninguém realmente dedica tempo para explicar que as assinaturas prontas‑para‑usar não são suficientes, nem por quê. Por isso, acredito que as empresas estão basicamente onde deveríamos esperá‑las estar – experimentando o que está disponível e começando a perceber que isso é insuficiente.

A solução não está em mexer no modelo de IA – você não precisa se tornar um pesquisador de LLM. Tudo gira em torno do que você envolve ao redor do modelo: seus dados, suas instruções escritas em linguagem simples e o software convencional. Quando você se pega digitando o mesmo contexto em um chatbot pela quinta vez nesta semana, isso é o sinal. Tudo o que você continua reexplicando é exatamente o que um sistema customizado já deveria saber – toda vez que ele “acorda”.

Você usa o termo “Crafters” para descrever profissionais de negócios familiarizados com dados que podem construir sistemas de IA customizados valiosos sem serem desenvolvedores de software tradicionais. Quais características distinguem um Crafter e como os líderes podem identificar essas pessoas dentro da força‑de‑trabalho existente?

Um Crafter é alguém nascido com a inquietação de resolver problemas com ferramentas. Aproximadamente um em cada 16 trabalhadores do conhecimento tem isso, na minha experiência. Eles foram os usuários avançados do Excel, depois a geração do Power BI, depois as pessoas que o TI rotulava como “TI sombra”. São seus analistas, modeladores financeiros, líderes de operações – pessoas que cresceram no negócio e descobriram um talento para ferramentas.

Dois traços os tornam ideais para trabalhos de IA. Primeiro, pensamento sistêmico: eles decompõem instintivamente um processo confuso em entradas, regras e saídas, muito parecido com desenvolvedores de software profissionais. Segundo, enraizamento no negócio: sabem quais números o CFO realmente acompanha e o que a pessoa que faz a pergunta realmente quer saber. Você não pode ensinar nenhum dos dois em um bootcamp.

Como encontrá‑los: siga as planilhas. Agora, na sua empresa, há planilhas, dashboards e automações no coração de fluxos críticos. Nenhum deles foi construído pelo TI, e cada um tem um autor. Comece por aí. E então avalie como eles poderiam direcionar seus talentos para soluções de IA customizadas.

Por que você acredita que os Crafters, em vez de apenas desenvolvedores, estão melhor posicionados para liderar muitos projetos internos de IA, e como as responsabilidades devem ser divididas entre especialistas de negócio, equipes de dados, engenheiros de software, departamentos de TI e equipes de segurança?

Porque a parte difícil da IA customizada não é o código – é o contexto. A atividade de maior alavancagem em um projeto de IA é decidir o que o sistema precisa saber sobre o seu negócio, e os Crafters carregam esse conhecimento nativamente. Um engenheiro brilhante que chega de três níveis hierárquicos acima tem que conduzir meses de entrevistas para aprender o que seu líder de operações já sabe por reflexo.

Mas isso não é, de forma alguma, uma história de que desenvolvedores são obsoletos. A divisão de trabalho que recomendo tem três fatores, e nenhum deles é senioridade ou personalidade: o trabalho tende a migrar para desenvolvedores profissionais à medida que reusabilidade, complexidade e sensibilidade aumentam. Qualquer coisa voltada ao cliente, qualquer coisa que toque dados sensíveis, qualquer coisa que tome decisões autônomas – isso é território de desenvolvedor, e à medida que os agentes se multiplicam, essas habilidades escassas de engenharia se tornam mais valiosas, não menos. O trabalho tende a Crafters onde a nuance dos processos de negócio domina.

Existe também um meio‑termo subestimado: o Crafter constrói, o desenvolvedor audita. TI e segurança não devem ser guardiões que aprovam projetos para existir – eles devem possuir a estrada pavimentada. Forneça as plataformas sancionadas, as regras de acesso a dados, os pontos de verificação, e deixe as pessoas mais próximas dos problemas fazerem a construção. Trate tudo como um modelo de maturidade, não como uma cerca.

IA customizada precisa de acesso à terminologia, métricas, processos e conhecimento institucional específicos da empresa. Qual o papel dos modelos semânticos e da infraestrutura de business intelligence existente em proporcionar à IA uma compreensão precisa da empresa?

São o anel decodificador. Atualmente, as definições da sua empresa – o que conta como cliente ativo, quais custos entram no lucro bruto – vivem na cabeça das pessoas e em mil planilhas ligeiramente inconsistentes. Um agente de IA não pode raciocinar de forma confiável sobre seus dados até que essas definições estejam registradas em um formato que a máquina possa confiar. A indústria começou a chamar essa disciplina de “engenharia de contexto”, e eu traduziria o termo assim: é o trabalho de estruturar o que seu negócio sabe para que a IA possa realmente usá‑lo. Os analistas fizeram soar como algo novo. Praticantes de BI vêm fazendo uma versão disso há quinze anos.

Essa é a boa notícia que está à vista: se você investiu na era do BI (e particularmente se investiu no Power BI), pode já ter uma vantagem inicial. Um modelo semântico bem construído é exatamente a captura legível por máquina do significado de negócio que os agentes precisam. As empresas que trataram sua camada semântica como um detalhe posterior estão descobrindo que o trabalho “chato” de definição que pularam agora é a pedágio na estrada para a IA. E, crucialmente, esse trabalho é profundamente específico ao seu negócio – o que o torna a vantagem durável. Todo fornecedor pode vender o mesmo modelo. Ninguém pode vender as suas próprias definições.

Você criou um editor de IA customizado, conhecido como Eddie, para ajudar a desenvolver o Fair Game. O que o sistema realmente fez durante o processo de escrita, e o que seus sucessos e falhas lhe ensinaram sobre projetar IA em torno de um fluxo de trabalho altamente pessoal?

Para ficar claro, eu escrevi cada parágrafo do livro do zero, enquanto Eddie ficava basicamente sentado e esperando. Em algumas ocasiões eu passava horas elaborando uma seção inteira de um capítulo antes de pedir que “ele” a lesse. Em outras eu o consultava a cada poucos minutos. Mas, crucialmente, Eddie estava de plantão 24 h por dia. Eu podia obter feedback tão facilmente às três da manhã quanto à uma da tarde, e ele devolvia em um minuto ou menos. No total, suspeito que Eddie leu o manuscrito pelo menos trinta vezes. Nenhum ser humano poderia fazer esse trabalho, porque nenhum ser humano quereria isso.

Ele acompanhou as promessas que fiz no Capítulo Três e me chamou a atenção quando o Capítulo Doze as esqueceu. Ele aprendeu meu estilo de escrita e então o impôs – mantendo-me na melhor versão da minha própria voz ao invés de me deixar cair no modo “Autor de Negócios Sem Humor”. Ele me avisou quando eu estava sendo preguiçoso e quando eu estava batendo em cavalo morto. Tivemos discussões reais, e às vezes ele venceu.

A maior lição de design: o “cérebro” de Eddie está escrito em inglês e vive em uma pasta. Cada vez que ele dava um feedback que falhava – muito genérico, registro errado, esquecendo uma regra que eu já havia declarado – a solução era escrever a correção e torná‑la parte do seu contexto permanente. As falhas não eram falhas de IA; eram lacunas no que eu havia me esforçado para ensinar a ele. Esse ciclo – notar a falha, codificar a lição, observar que ela fixa – é todo o ofício da IA customizada em miniatura. E é por isso que acabei construindo Eddies especializados para publicidade, pesquisa competitiva e mensagens de sites. O mesmo LLM por baixo. Mas especialistas diferentes.

Muitas organizações acreditam que precisam limpar e centralizar completamente seus dados antes de tentar IA customizada. Quão pronto os dados realmente precisam estar para começar, e como as empresas podem começar a gerar valor sem esperar por uma base perfeita?

“Perfeição” dos dados não é pré‑requisito, e isso é uma boa notícia porque a perfeição nunca chega. Se você pretende primeiro construir um data estate perfeito, como muitos consultores aconselham, estará construindo o que eu chamo de “encanamento por si só” – tubos caros por toda parte, mas quando finalmente instalar um torneira, descobrirá que não há tubo onde você precisa.

Nossa empresa, por outro lado, defende uma abordagem “torneiras primeiro”. Escolha um caso de uso específico e trabalhe de trás para frente a partir do impacto de negócio, em vez de avançar a partir da infraestrutura. Construa um MVP a partir desse caso de uso, e faça isso com o mínimo de nova infraestrutura. Itere no MVP até que esteja pronto para produção, e então dê um passo atrás e avalie como você pode reforçar sua infraestrutura para suportá‑lo. Isso entrega impacto de negócio mais rapidamente, minimiza custos e informa projetos futuros – tanto no nível da torneira quanto do encanamento.

Um protótipo de IA customizada pode parecer impressionante durante uma demonstração, mas tornar‑se pouco confiável quando exposto a funcionários reais, dados em mudança e casos extremos. Que avaliação, monitoramento e supervisão humana devem ser estabelecidos antes que um sistema interno de IA se torne operacional?

Com algumas exceções notáveis, acho que demonstrações são menos valiosas na era da IA do que eram na era do software. Demonstrações de software sempre exageraram e todos sabíamos disso. Mas as demonstrações de IA estarão ainda mais distantes da sua realidade.

IA trata de fluxo de trabalho. E não há nada mais customizado do que os milhares de fluxos que alimentam as operações de uma organização específica. Volte à metáfora “novo contratado com PhD em tudo”. Quanto treinamento – e experiência prática na sua empresa – um novo contratado precisa antes de ser eficaz na sua companhia? Como uma demonstração pode levar isso em conta?

Então usamos demonstrações para fazer as pessoas refletirem. Para mostrar a elas a arte do possível. Não para vender um produto. A demonstração real começa com o protótipo da solução customizada. O MVP. E então iteramos e melhoramos. Rapidamente.

Em algum ponto está pronto para um lançamento suave ou programa piloto. E novamente, aprendemos – juntos – e melhoramos rapidamente com base nesse aprendizado. Essa costuma ser a fase onde monitoramento, avaliação e supervisão começam a ganhar foco. As coisas que você acaba precisando são muitas vezes muito diferentes do que você teria adivinhado inicialmente.

Como as empresas podem capacitar os Crafters a experimentar sem criar uma nova geração de sistemas de IA sombra, fluxos de trabalho duplicados, vulnerabilidades de segurança e ferramentas que ninguém se responsabiliza por manter?

Lembre‑se de onde veio o TI sombra: não foi malícia, foi a necessidade de suprir uma demanda não atendida. Crafters constroem porque os problemas os incomodam – esse é o gene. Se o caminho sancionado significa esperar um ano, a IA sombra preencherá a lacuna – e o fará de forma discreta, onde é mais perigoso.

Portanto, torne a pista sancionada a pista fácil. Dê aos Crafters uma plataforma aprovada com as barreiras de segurança já incorporadas – identidade, acesso a dados, registro – para que a escolha em conformidade seja também a conveniente. Mantenha um registro leve: tudo que passa de experimento pessoal para algo que uma segunda pessoa depende deve ser anotado, com um proprietário nomeado. Essa regra única elimina a maior parte do problema de ferramentas órfãs, porque ferramentas com nomes associados não são abandonadas silenciosamente.

Em seguida, aplique o modelo de escalonamento: experimentos rodam livremente, mas à medida que algo se torna crítico para a missão – mais usuários, mais sensibilidade, mais autonomia – ganha revisões de engenharia progressivamente maiores. O Crafter mantém a propriedade da lógica de negócio; um desenvolvedor reforça o que precisa ser reforçado. O objetivo é um pipeline de maturidade, não um processo de permissão. As empresas já fizeram esse mesmo filme com planilhas, e os vencedores não foram os que proibiram o Excel.

Para uma empresa que está iniciando sua primeira iniciativa de IA customizada, como deve selecionar o caso de uso inicial, medir se o projeto está entregando valor de negócio significativo e decidir se deve expandir, redesenhar ou abandoná‑lo?

Temos duas abordagens de ponto de partida que usamos com nossos clientes.

Opção um, procure pelos trabalhos que ninguém está fazendo – não os trabalhos que você gostaria de eliminar. Há uma pergunta que adoro fazer aos gerentes: onde você já pensou, “se eu tivesse uma pessoa monitorando isso constantemente e pensando nisso, as coisas melhorariam significativamente – mas eu nunca poderia justificar uma contratação inteira para isso”? Esses são frequentemente os melhores pontos de partida. Eles são seguros, constroem confiança, ninguém se sente alvo, e o contrafactual é honesto: a alternativa não era um humano fazendo bem, era ninguém fazendo nada (como meu amigo editor Eddie).

Opção dois, considere substituir dashboards por agentes de dados. Por simples que pareçam, os dashboards ficaram muito aquém na prática de cumprir sua promessa. Quando alguém tem uma pergunta de negócio, é muito trabalho traduzi‑la para o cenário dos dashboards. Onde está o dashboard que responde a essa pergunta? Como ele é nomeado? Esse dashboard sequer existe? E se você conseguir encontrar o “certo”, ele é claro e conveniente de usar? Você precisa manipulá‑lo repetidamente, anotando ou capturando telas de múltiplas versões para montar o panorama geral que precisa?

Na era da IA, você simplesmente pega sua pergunta de negócio – com suas próprias palavras – e a digita (ou dita!) para um agente de dados que então cuida de tudo isso para você, retornando uma resposta certificada, bem pesquisada – com visualizações incluídas – em um ou dois minutos. Quando você tem uma pergunta de acompanhamento, ele responde rapidamente também – na reunião, enquanto as decisões ainda podem ser tomadas.

O ponto em comum entre essas duas opções iniciais? Ambas abordam dores que os funcionários vão abraçar ao invés de resistir. Você não quer que suas primeiras iniciativas de IA semeiem desconfiança. Você quer que, ao contrário, elas tragam os funcionários para a mesa. Você quer que os funcionários sugiram melhorias e novas ideias de projetos. Porque, novamente, sua empresa é composta por milhares de fluxos, e seus funcionários os conhecem melhor que você.

Sobre expandir, redesenhar ou abandonar – seja gentil consigo mesmo, porque a pesquisa sobre isso é realmente reconfortante: a maioria das implantações de IA bem‑sucedidas teve falhas antes delas. Um primeiro projeto que produz uma lição ao invés de um retorno é um aprendizado, não evidência de que a IA não funciona. Minha regra prática: se as pessoas estão usando, expanda. Se as pessoas não estão usando, descubra por quê, e isso pode variar de “porque não funciona bem” a “porque eu não entendo” a “isso me assusta”. A resposta informa se você deve melhorar, redesenhar ou abandonar. Você não precisa prever onde tudo isso vai chegar. Você só precisa começar em algum lugar honesto.

Obrigado pela ótima entrevista, os leitores também devem ler Fair Game: Customizing AI to Your Business Is Easier Than You Think.