Por que a maioria das empresas não está pronta para operar AI?
6 perguntas para Yolanda Castro, Head of Prototyping and AI Customer Engineering na AWS
Só uma fração pequena dos pilotos de AI chega à produção, e o motivo quase nunca aparece na demo. A distância entre o experimento e a operação é maior do que os roadmaps assumem.
O que trava não costuma ser o modelo. É o que está em volta dele, os dados que alimentam, quem responde pelo quê, o processo que sustenta a operação depois do deploy.
Nesta edição de 6 Perguntas, conversamos com Yolanda Castro, Head of Prototyping and AI Customer Engineering na AWS, sobre o que a prototipação revela da prontidão real de uma empresa e o que precisa estar de pé antes de a AI assumir um pedaço do negócio.
Na sua experiência, o que um protótipo de AI costuma revelar sobre o quanto uma empresa está pronta para operar com AI, e não só para experimentar?
Um dado recente do IDC mostra que apenas 12% das POCs de IA chegam à produção. Quando olhamos para a América Latina, o cenário é ainda mais desafiador e segundo a McKinsey, só 10% das organizações da região conectam sua implementação de IA à estratégia de negócio, e apenas 6% reportam impacto significativo.
Esses números não me surpreendem. Na minha experiência liderando um programa de prototipação na AWS para a América Latina, entendi que o protótipo é muito mais do que uma prova técnica, ele funciona como um raio-X organizacional. Ao qualificar uma oportunidade de prototipação com AWS PACE buscamos sinais de que aquela experimentação tem um caminho claro para a produção. E em poucas semanas, esse trabalho revela verdades que meses de planejamento estratégico não conseguem expor.
Primeiro, a prontidão de dados. Quando pedimos amostras de dados para alimentar o protótipo, rapidamente descobrimos se a empresa tem pipelines prontos, ownership claro, políticas de acesso definidas ou se tudo ainda depende de processos manuais e planilhas. Tem uma pesquisa da AWS com a Techaisle que ilustra isso: qualidade e prontidão de dados é a barreira número um para adoção de IA generativa em 47% das empresas.
Segundo, a maturidade de governança. Todas as empresas com as quais conversamos já adotaram GenAI de alguma forma, mas a governança ainda está em evolução. Todo mundo experimenta, mas poucos governam em produção. O protótipo é o primeiro momento em que perguntas sobre compliance, segurança de dados e responsabilidade operacional deixam de ser teóricas.
Terceiro, e talvez o mais revelador, o protótipo expõe o grau de alinhamento organizacional. Existe um time de produto multidisciplinar dedicado com a missão de levar o caso de uso à produção? Existe um caminho definido do protótipo para operação em termos de MLOps, CI/CD? Ou esse protótipo é um um projeto de inovação sem sponsor executivo de negócio e desconectado da estratégia da companhia?
Os protótipos que o programa da AWS entrega para os clientes têm uma taxa desproporcional de ida à produção, com algumas ordens de grandeza acima da média de mercado. A diferença não está na tecnologia usada na experimentação. Está em como o protótipo é qualificado e desenhado desde o início: não como demonstração de algo legal, mas como diagnóstico do potencial de sucesso de criar outcomes reais para o negócio.
Empresas que estão prontas para operar IA em escala chegam ao protótipo já com um business case quantificado, um dataset candidato e um time multidisciplinar definido. As que ainda estão apenas experimentando frequentemente pedem “um protótipo de GenAI” sem caso de uso claro. Nesse segundo cenário, o protótipo tem um valor educacional, pois ele catalisa a definição de prioridades e promove conversas entre Produto, Engenharia, negócio, jurídico e dados que possivelmente não aconteceriam.
O protótipo é o momento da verdade. Ele ajuda a ir além da pergunta sobre viabilidade técnica: “IA funciona nesse caso de uso?” para a pergunta que realmente importa: “esta organização está pronta para operá-la?”.
Na prática, quais condições você recomenda que o Upstream tenha, bem estruturadas, antes de colocar AI para operar sobre ele?
“Upstream” é tudo que alimenta e sustenta a IA em operação. Se o Upstream é frágil, o modelo mais sofisticado do mundo entrega resultados inconsistentes ou perigosos. Um estudo da Moor Insights & Strategy descobriu que 83 a 92% dos novos projetos de AI falham, e a raiz quase sempre está na preparação insuficiente do que vem antes do modelo.
Na prática, recomendo cinco condições que mapeiam diretamente para o que a AWS formalizou no Well-Architected Generative AI Lens, um framework construído a partir de mais de mil implementações de IA generativa com clientes AWS.
Dados prontos para consumo autônomo: Antes de operar, a empresa precisa responder: existe um pipeline que entrega dados frescos ao modelo sem intervenção manual? Sabemos de onde veio cada dado e com que frequência é atualizado? E, ponto que o GenAI Lens destaca na seção de data architecture, estamos governando também dados não-estruturados? Muitas empresas governam bem suas tabelas, mas descobrem no protótipo que 80% do valor está em documentos, logs e conversações que nunca foram catalogados.
Governança como pré-requisito: Sem governança clara, IA em produção é um risco regulatório e operacional. Recomendo, no mínimo: políticas de acesso e privacidade definidas (quem pode ver o quê, como garantimos compliance com LGPD); ownership claro, ou seja, uma pessoa com accountability por cada dataset e cada modelo, não um comitê. O Well-Architected GenAI Lens trata governança como parte do pilar de segurança avaliado em todas as seis fases do ciclo de vida justamente porque não é algo que se adiciona depois do deploy. No Brasil, isso ganha urgência. O marco regulatório de IAI estabelece classificação de risco, direitos dos afetados e responsabilidade civil. Quem estruturar governança agora estará se antecipando a uma obrigação legal, não apenas seguindo boa prática.
Processos que suportam iteração contínua: Das empresas que conseguiram sair do piloto, 61% citam reestruturação de processos como o fator decisivo, acima até de dados (22%) e sponsorship (14%). Uma boa implementação de MLOps é a diferença entre um modelo que funciona uma vez e um sistema que opera continuamente.Os checkpoints mínimos: versionamento com CI/CD automatizado; testes de qualidade antes de cada deploy; fallback definido para falhas em produção; SLAs claros de latência e taxa de erro; e monitoramento contínuo com alertas. O GenAI Lens reforça que o caminho é iterativo, não waterfall e as seis fases (scoping, selecting, customizing, integrating, deploying, iterating) formam um ciclo. O Upstream não é uma lista que se cumpre uma vez; é uma fundação que evolui a cada ciclo.
Pessoas com accountability e multidisciplinaridade: A McKinsey mostra que apenas 7% das empresas são “AI high performers”. A diferença está em times multidisciplinares com engajamento ativo da liderança. Recomendo três papéis mínimos: um owner de negócio com autonomia para escalar, pausar ou pivotar; um time que combine engenharia de dados, segurança, compliance e conhecimento do processo; e literacy organizacional suficiente para a liderança aceitar que IA exige iteração e muitos ciclos de experimentação e aprendizado.5
Business case quantificado: “Reduzir tempo de análise de crédito de 5 dias para 4 horas” é operável. “Usar AI para inovar” não é. Antes de operar, é preciso uma métrica de sucesso e um ROI que inclua o custo real: inferência, manutenção, retraining e pessoas dedicadas. Algo que observo com os protótipos que criamos na AWS e vão para produção é que os projetos que chegam com sponsorship executivo, business case quantificado, dataset candidato e time definido convertem em produção mais de cinco vezes acima da média de mercado..
Quando avaliamos workloads com o GenAI Lens, os pilares de excelência operacional, segurança e confiabilidade são onde mais encontramos gaps. São exatamente as áreas cobertas pelas cinco condições acima. A boa notícia é a de que não é preciso perfeição antes de começar. É preciso clareza sobre onde estão os gaps e um plano para fechá-los em paralelo ao desenvolvimento (não depois).
Quais sinais ou métricas você recomenda acompanhar para validar se AI realmente mudou o resultado do negócio, e não apenas acelerou o que o time já fazia?
A adoção de IA generativa tem o potencial de aumentar a produtividade ou de ser uma alavanca de transformação. Quando vejo empresas que usam AI exclusivamente para “ganho de produtividade”, frequentemente estão subutilizando a tecnologia. A pergunta que faço é: “Qual produto ou serviço novo a AI te permite criar que te ajuda a entregar uma melhor experiência para seu cliente?” Cada organização precisa entender quais dos seus processos podem se beneficiar de um ganho de produtividade, mas também buscar entender o que agora é possível na perspectiva de como se entrega valor para seus clientes para criar impacto significativo de negócio. Aqui está o framework que recomendo:
Camada 1: Métricas de atividade (necessárias, mas insuficientes)
São as métricas que a maioria das empresas já acompanha: tempo economizado, tarefas automatizadas, volume processado. Elas respondem se você está conseguindo otimizar seus fluxos de trabalho com IA mas não diz se você está transformando o seu negócio com o seu uso. Se você monitora apenas métricas como “economizamos 200 horas/mês”, você acelerou o que o time já fazia. Isso é eficiência operacional, não transformação.
Camada 2: Métricas de qualidade de decisão
Aqui começa a diferença. A IA mudou a qualidade das decisões que o time toma? Exemplos:
- Custo evitado: Fraude prevenida, churn evitado, manutenção preditiva
- Taxa de acerto em classificação de risco (antes vs. depois)
- Percentual de retrabalho eliminado (não horas salvas, mas erros evitados)
- Eficiência em detecção proativa de anomalias
- Decisões que antes não eram possíveis sem IA (novos padrões descobertos, segmentos identificados)
O sinal de transformação real é quando a IA suporta decisões que seriam impossíveis sem ela, não apenas decisões mais rápidas.
Camada 3: AI como motor de construção de produto
O NTT DATA Global AI Report 2026 mostrou que as 15% de organizações classificadas como “AI leaders”, com estratégia clara, modelo operacional maduro e execução focada, reportam crescimento de receita e margens de lucro significativamente maiores. A diferença não está em fazer as mesmas coisas mais rápido, mas em fazer coisas novas que antes não eram possíveis. AI não é só uma camada de otimização sobre processos existentes, é uma ferramenta de criação de produto. A IDC publicou no FutureScape 2026 que a próxima era de valor enterprise será definida pela capacidade de “reimaginar modelos de negócio, descobrir novas fontes de receita e alcançar resultados antes fora de alcance”. A EY complementa mostrando que a IA está fundamentalmente remodelando o desenvolvimento de produtos.
As métricas que revelam essa dimensão são diferentes:
- Time-to-market de novos produtos: A AI reduziu o ciclo de concepção → lançamento? Não por automação de tarefas, mas por capacidades novas como experimentação rápida, prototipagem generativa, personalização em escala.
- Receita incremental atribuível: Novos produtos, novos segmentos, upsell/cross-sell que só existem por causa da AI (recomendação personalizada, pricing dinâmico, experiências conversacionais). Se esse percentual cresce trimestre a trimestre, IA está suportando a construção de um negócio novo.
- Novos segmentos alcançados: A AI permitiu servir mercados que antes eram inviáveis economicamente? (long tail, microsegmentação, hiperpersonalização)
- Velocidade de iteração de produto: Feedback loops que antes levavam semanas agora levam horas, não por eficiência do time, mas porque a IA processa sinais de uso em tempo real e sugere ajustes.
A McKinsey enfatiza que o valor precisa ser definido antes de escrever uma linha de código, com uma métrica em cada camada, da performance técnica ao impacto financeiro. Isso inclui testes A/B ou deployments escalonados para que a atribuição seja clara desde o início. Sem isso, a empresa nunca saberá se o resultado veio da AI ou de outros fatores simultâneos.
Um exercício prático para entender a sua adoção estratégica de IA é responder a uma pergunta simples: “Se desligássemos a AI amanhã, o que aconteceria com o resultado do negócio em 30 dias?” Se a resposta é “o time voltaria a fazer manualmente, um pouco mais devagar”, a AI acelerou. Se a resposta é “perderíamos capacidades que não existiam antes, decisões que não conseguiríamos tomar, receitas que não saberíamos capturar”, a AI transformou.
Em Produto, como você recomenda decidir o que entregar à AI de forma autônoma e o que manter com humano no loop, quais critérios ou práticas definem essa fronteira?
A primeira coisa que recomendo a qualquer time de produto é abandonar a ideia de que essa fronteira é binária. A pergunta não deve ser “AI autônoma ou humano no loop?” mas sim “qual nível de autonomia, para qual decisão, neste contexto?”
A resposta depende da natureza do que estamos construindo. Marty Cagan tem insistido que os melhores “produtos inteligentes” combinam comportamentos determinísticos e probabilísticos, inclusive em contextos regulados e de missão crítica. Ou seja: o objetivo não é eliminar o erro da IA, é definir explicitamente qual taxa de erro é aceitável em cada tarefa e desenhar o mecanismo de supervisão proporcional a isso. A implicação prática é que não existe uma resposta universal e cada decisão de produto tem um perfil de risco diferente, e o nível de autonomia precisa refletir isso. Times que tratam essa decisão como um dial calibrado por reversibilidade, custo de verificação e evidência acumulada conseguem mover a fronteira da autonomia com segurança. Nos protótipos de PACE que construímos com clientes, a decisão de autonomia é a primeira conversa de product discovery.
O padrão agêntico chamado de “dial de autonomia” consolida cinco posições entre sugestão pura e autonomia total:
1. AI sugere, humano age: AI gera recomendação, mas toda ação requer aprovação explícita. Um rascunho de email que o usuário precisa revisar e enviar. Toda funcionalidade de AI deveria começar aqui, independente dos resultados de experimentos offline.
2. AI age, humano confirma: AI executa por padrão, mas pausa num checkpoint de confirmação antes de tornar a ação irreversível. Um bot de atendimento que constrói e enfileira a resposta, dando 30 segundos ao agente humano para modificar antes do envio.
3. AI age, humano pode intervir. A AI executa autonomamente, mas o humano monitora um log de ações e pode reverter. É o padrão “human-on-the-loop” em que a AI cuida dos casos rotineiros de ponta a ponta e exceções sobem para revisão humana.
4. AI age, humano audita depois. A AI opera independentemente. Humanos revisam resultados periodicamente. O papel muda de operador para auditor.
5. AI age, humano define objetivos. Autonomia total dentro de um domínio definido. Humanos especificam objetivos e premissas, AI descobre como alcançá-los. Pouquíssimos sistemas em produção deveriam operar aqui hoje.
Esses níveis são posições em um dial que se ajusta por funcionalidade, por caso de uso, e às vezes por decisão individual dentro de um mesmo workflow. O padrão mais eficaz que vejo em 2026 prescreve autonomia delimitada, em que diferentes classes de decisão dentro do mesmo produto operam em níveis diferentes.
Exemplo concreto de um sistema de suporte ao cliente com AI:
- Responder FAQs → Nível 4 (autônomo, auditoria periódica)
- Emitir refunds < R$250 → Nível 3 (autônomo com monitoramento humano)
- Emitir refunds > R$250 → Nível 2 (AI escreve, humano confirma)
- Cancelamento de conta → Nível 1 (AI sugere, humano decide e executa)
Estamos começando a ver autonomia em nível 5 funcionando com “agentic coding loops” em que ao invés de um humano escrever cada linha de código, um agente de AI recebe uma especificação de produto e um set de evals, escreve o código, testa, encontra bugs e reescreve até que o programa esteja correto. O humano define a spec e os critérios de sucesso e a AI executa o loop.
Esse padrão dá autonomia total dentro de um domínio extremamente bem delimitado (código que precisa passar em testes específicos). O humano está no loop de design (spec + evals), mas fora do loop de execução. E isso funciona porque o domínio é limitado (bounded), a saída é verificável, e o erro é reversível (você apaga o código e tenta de novo).
Na era da IA Generativa, em que o poder das ferramentas cresce exponencialmente, precisamos focar no pensamento crítico e capacidade de julgamento que product managers e product designers trazem para o time. Times que “terceirizam seu pensamento” para AI dificilmente entregarão produtos que se diferenciam no seu cenário competitivo. Por isso o dial de autonomia tem um teto determinado pelo tipo de decisão:
- Decisões de execução (como fazer algo que já foi decidido) → podem subir até Nível 4-5
- Decisões de discovery (o que construir e por quê) → devem permanecer em Nível 1-2, com humano liderando e AI assistindo
- Decisões éticas e de marca (como representar a empresa, o que prometer ao cliente) → Nível 1, sempre
Tão importante quanto saber quando aumentar autonomia é saber quando reduzir:
- Troca ou atualização de modelo LLM: Qualquer mudança no modelo subjacente implica em um reset de confiança. Volta para Nível 1 mesmo que o novo modelo desempenhe melhor nos benchmarks.
- Redistribuição: Se os inputs começam a parecer diferentes do que foi validado (novos segmentos, sazonalidade), desce um nível.
- Clustering de erros: Um erro é ruído. Três erros na mesma categoria em curto prazo são sinal de uma necessidade de diminuir a autonomia.
- Degradação da supervisão humana: Se os humanos que fazem a validação começam a corrigir com pior qualidade, o mecanismo de supervisão pode estar se degradando.
Como Head of PACE, o que costuma se perder na tradução entre o que o negócio pediu e o que o time vai construir, e como esse risco quando a AI acelera a construção?
Esse talvez seja um dos pontod que mais me preocupa neste momento da indústria de tecnologia e desenvolvimento de produto. O que se perde quase nunca é o o quê, mas sim o por quê e o quanto. O negócio pede a solução de um problema, o time muitaz vezes receb um pedido de funcionalidade, e no caminho evaporam três coisas: o problema original que motivou o pedido, o critério de definição de sucesso, e as restrições não ditas (de compliance, de marca, de operação) que só aparecem quando algo quebra. O Cagan organiza isso nos quatro bem conhecidos riscos de produto: valor (o cliente vai usar?), usabilidade, viabilidade técnica e viabilidade de negócio, e o processo de product discovery existe justamente para matar esses riscos antes do desenvolvimento começar. Na minha experiência, o que se perde na tradução são quase sempre os riscos de valor e de viabilidade de negócio, porque são os que não cabem numa spec. Viabilidade técnica o time descobre construindo; valor, só descobrimos tarde demais, depois de entregar.
E aqui está o ponto contraintuitivo sobre a IA: ela não reduz esse risco, ela o comprime no tempo. Antes, a lentidão do delivery funcionava como um amortecedor acidental. Eram semanas de perguntas, revisões e atrito entre engenheiros e PM/PDs em que os gaps da visão do produto e mal-entendidos vinham à tona. Agora, como o head de produto da Notion colocou recentemente, os primeiros 10% de qualquer projeto ficaram “de graça” e o resultado do vibe coding foi mais software, não software melhor. O próprio Cagan é direto nisso: as ferramentas aceleram a produção de código e design, mas isso não se traduz necessariamente em resultados melhores. Se a direção estiver errada, a IA é uma máquina de errar mais rápido, com acabamento profissional. E o acabamento é parte do perigo: um protótipo que parece pronto cria uma falsa sensação de validação em que o time vê algo funcionando e conclui que entendeu o problema.
Há uma segunda mudança, mais estrutural: com agentes, a especificação deixou de ser um documento vivo de alinhamento de visão de produto e virou o input da máquina de construção. O que antes se perdia na tradução era absorvido por engenheiros fazendo perguntas incômodas; um agente não faz perguntas incômodas, ele preenche as lacunas com a suposição mais plausível e segue em frente. Ou seja, tudo que ficou implícito no pedido do negócio vira decisão silenciosa da IA.
Por isso, as práticas que eu recomendo atacam a tradução, não a construção.
Primeiro, working backwards: na Amazon, escrevemos o press release e o FAQ antes de construir qualquer coisa, porque escrever força clareza sobre o cliente, o problema que estamos tentando resolver e qual é a definição de sucesso e esse artefato vira o contrato entre negócio, time e agora também a IA.
Segundo, tratar o protótipo como ferramenta de alinhamento, não como versão beta: o nível de fidelidade deve corresponder ao nível de risco dado que protótipos existem para responder perguntas, não para entregar funcionalidades. No PACE, o protótipo é a conversa na qual, em dias, negócio e time olham para a mesma coisa concreta e descobrem onde estavam falando línguas diferentes antes que isso custe um trimestre.
Um padrão recorrente que observamos é o cliente pedir um chatbot com RAG e quando executamos o Working Backwards descobrimos que ninguém queria conversar com uma base de conhecimento, o que o negócio precisava era recomendação personalizada, algo que uma solução como o Amazon Personalize resolve melhor, mais barato e com menos risco do que um chatbot genérico. O pedido de “chatbot” era a hipótese de solução do cliente, formulada com a tecnologia mais visível do momento. E esse é o risco amplificado pela IA: como construir um chatbot com RAG hoje leva dias, um time diligente entregaria exatamente o que foi pedido, funcionando, com demo bonita e erraria o problema com eficiência recorde.
Terceiro, transformar critério de sucesso em algo verificável desde o dia um, ou seja, se a IA vai construir rápido, as evals e a definição de pronto precisam existir antes do primeiro prompt. Assim, quando construir fica barato, alinhar vira o trabalho.
Que fontes de informação você considera indispensáveis para que lideranças de Produto e Engenharia se mantenham atualizadas sobre AI e seus movimentos no mercado?
Vivemos um momento em que a velocidade das mudanças em AI torna impossível depender de fontes tradicionais de atualização como livros e conferências anuais, que já nascem defasados. Por outro lado existe excesso de informação otimizada para engajamento com muitas publicações populares de IA otimizando para crescimento de audiência. Então minha recomendação é um sistema com uma camada diária de contexto, uma semanal de profundidade, e uma periódica de reflexão estratégica. Aqui está o que eu consumo e recomendo, organizado por camada:
A primeira camada é a fronteira em fonte primária. Os blogs de engenharia e as notas de lançamento dos próprios AI labs (Anthropic, OpenAI, Google DeepMind e AWS) porque a capacidade dos modelos muda mês a mês e qualquer intermediário adiciona latência e ruído. Para digerir esses lançamentos semanalmente eu leio o The Batch, do Andrew Ng, que é uma curadoria com credibilidade real de machine learning no nível editorial, traduzindo o que os lançamentos e papers da semana de fato significam.
Para quem lidera engenharia e precisa descer um nível de abstração, o Latent Space trata a engenharia de IA como disciplina própria abordando economia de inferência, frameworks de agentes, a camada de tooling entre os modelos fundacionais e o produto que chega ao cliente.
Na segunda camada, gosto de consumir conteúdo sobre a tradução para o ofício de produto. Aqui, duas fontes são inegociáveis para mim: a SVPG do Marty Cagan, que vem fazendo o trabalho mais sério de repensar o product operating model na era da IA abordando discovery, riscos de produto, o papel do julgamento humano; e a newsletter do Lenny Rachitsky , que mostra como a IA está sendo entregue como produto, não apenas lançada como modelo, o enquadramento que você precisa ao repensar uma estratégia ou contextualizar a liderança. O valor dessas publicações está em separar o que muda o ofício da disciplina que é só notícia. Como foco mais específico em Engenharia, assino o Pragmatic Engineer (Gergely Orosz) , que é a newsletter #1 de engenharia de software/AI no Substack.
Gergely traz uma perspectiva única de quem foi engenheiro no Uber, Microsoft/Skype e startups. Seus artigos sobre impacto de AI em engenheiros, visitas a OpenAI/Anthropic/Cursor, e análises como “what happens when AI writes almost all code” são leitura obrigatória. Ele publicou recentemente que “AI tools speed up ‘Shippers’ — engineers who focus on getting things done. But they also add tech debt faster and might build the wrong things.” Essa é a tensão que toda liderança de engenharia precisa navegar.
A terceira camada não é leitura, e na minha visão é a mais indispensável. Na Amazon a gente diz que não existe algoritmo de compressão para experiência, e em IA isso é literal: o conhecimento tácito sobre o que os modelos fazem bem, onde falham e como falham não vem de newsletter, vem de uso.
Liderança de Produto e Engenharia que não constrói algo com essas ferramentas toda semana, como um protótipo, um agente interno, ou uma automação do próprio trabalho, está lendo sobre um território que nunca pisou, e vai tomar decisões de investimento com mapa de terceiros. E incluo nessa camada a fonte mais subestimada de todas: seus clientes e seus dados. O comportamento real dos usuários diante das suas funcionalidades de IA diz mais sobre o mercado do que qualquer análise e é o único dado que seus concorrentes não têm.
Se eu tivesse que resumir o critério, eu recomendaria menos fontes, mais primárias, e nenhuma delas substitui construir. O erro que vejo em lideranças é ou consumir demais e se perder no ruído ou consumir de menos e ser pego de surpresa quando o mercado muda. O segredo está em curar poucas fontes de alta qualidade e ter disciplina de frequência.