Consolidação das reuniões de 07/04/2026 — reunião com a Yamaha Brasil e alinhamento interno da Robbu. Piloto de IA para cobrança com potencial de escala global.
Videoconferência realizada em 07/04/2026, com foco no detalhamento do piloto de IA para cobrança e no alinhamento de expectativas para a visita do head da Yamaha USA.
Entender o contexto é essencial — a aprovação depende menos de performance técnica e mais de confiança institucional.
A Yamaha Global está em um momento de abertura controlada para adoção de IA. Por ser uma empresa japonesa, a governança pesa muito e a postura é conservadora — a única IA oficialmente liberada pela matriz até o momento é o Microsoft Copilot.
O Brasil tem puxado a frente nesse tema, pressionando a matriz e desenvolvendo inclusive a política interna de IA da Yamaha Brasil junto com o Pezani. A ideia de utilizar o bot de cobrança (faixa de 5 a 15 dias de atraso) como piloto foi levada à Yamaha USA em um encontro global de SI na semana anterior, com recepção positiva.
O head dos EUA é um executivo japonês baseado nos Estados Unidos. Apesar da Yamaha Brasil responder aos EUA, a mentalidade decisória continua conservadora e orientada a governança.
Na semana de 14/04, representantes da Yamaha USA virão ao Brasil avaliar o projeto. Haverá também uma visita da Microsoft na mesma semana.
O ponto central da reunião não foi performance de modelo. Foi confiança institucional. Não basta a solução funcionar — ela precisa ser politicamente aprovável. O patrocinador interno precisa de material que consiga usar para "defender" a proposta perante a matriz.
O executivo não é do mundo de tecnologia e é bastante visual. Precisa de diagramas, não de explicações abstratas.
Ganhos e benefícios do piloto — a Yamaha Brasil já consegue montar isso internamente.
Como os dados trafegam, que tipo de dado entra no bot, como se comunica via API, que informações a IA acessa, até onde pode ir.
Diagrama com sistemas, infra, fluxo de dados e pontos de dados sensíveis. Referência: projeto "Phoenix" da Yamaha Financial Services.
O benchmark visual deles não é um texto longo — é um mapa operacional compreensível por executivo não técnico. A apresentação precisa ser diagramática, orientada a caixas e setas, com ambientes/sistemas claramente identificados.
Três preocupações centrais emergiram da reunião — cada uma exige uma resposta clara no material.
"Os dados da Yamaha ou dos clientes vão parar em algum lugar fora de controle por causa da IA?" — esse receio apareceu de várias formas: tráfego entre ambientes, IA "aprendendo" com dados inseridos, informações indo "pra fora".
A Yamaha explicitou desconforto com a ideia de a IA chegar sozinha à decisão final de negociação. A matriz japonesa deixou claro: não querem que a IA tome a decisão final sozinha.
Se estiver na Robbu, a sustentação é óbvia. Se estiver no ambiente da Yamaha, a responsabilidade precisa estar bem amarrada: observabilidade, acesso a logs, fronteira entre problema de aplicação e de infra.
A separação em camadas torna a solução "auditável" na cabeça do cliente. A IA não toca em tudo — esse é o ponto mais importante.
Consulta de CPF, integrações, recuperação de dados, regras fechadas e chamadas sistêmicas. Sem IA.
Etapas onde faz sentido usar IA: interpretar contexto, apoiar negociação, estruturar proposta, auxiliar decisão.
Conferência final no piloto inicial. Impede decisão totalmente autônoma. Mesa de crédito leve.
O piloto pode ser controlado pelo final do CPF — isso permite iniciar com volume pequeno e aumentar gradualmente conforme os resultados se comprovem. Mecanismo já utilizado pela Robbu em outros contextos.
A proposta mais estratégica da reunião: rodar tudo no tenant Azure da Yamaha.
O Pezani trouxe uma proposta estratégica: que todo o desenvolvimento seja feito dentro do tenant Azure da Yamaha. O raciocínio:
"Se a gente conseguir viabilizar isso, está praticamente pré-aprovado. É questão de implementar." — Marco, Yamaha
A resposta madura não é "sem problema". A resposta madura é: "Sim, é viável. Mas precisa de desenho claro de responsabilidade, observabilidade, acesso, operação e suporte."
A Robbu não depende de um único provedor. Hoje usa majoritariamente OpenAI por praticidade, mas migrar para Copilot, Grok ou qualquer outro não traz complexidade significativa. O desenho é agnóstico por design.
Além do fluxograma, a Yamaha pediu que a Robbu apresente o set de proteções padrão e flexibilidade para camadas exclusivas.
O Azure permite deploy de modelos de IA além do Copilot na própria infraestrutura — por exemplo, modelos da OpenAI rodando nativamente, sem que os dados saiam do ambiente. Na reunião global anterior, uma representante do Japão mencionou que estão estudando a possibilidade de usar outras IAs além do Copilot. Isso abre portas. A Microsoft será convidada a apresentar toda a stack de IA embarcada no Azure na visita da semana seguinte.
A narrativa mais forte para convencer o head japonês.
Antes de falar de automação ou produtividade, começar por: tenant/ambiente, fluxo de dados, criptografia, logs, guard-rails, decisão humana final, separação entre etapas com IA e sem IA.
Não vender n8n se gera ruído. Vender Logic Apps, Power Automate, serviços Azure equivalentes. Mostrar que a Robbu leva o know-how mas respeita o ecossistema deles. Deixa de ser "trazer caixa externa" e vira "construir dentro do padrão corporativo".
Fluxo delimitado, regras delimitadas, população controlada (CPF), checkpoints claros, validação humana, observabilidade desde o início. Não tentar vender plataforma completa logo de saída.
Conjunto-base de proteções + controles adicionais exclusivos da Yamaha. Muda a conversa de "produto fechado" para "base padronizada + proteção customizada por cliente".
Alinhamento pós-reunião com a Yamaha. O objetivo: sair do entusiasmo e colocar o pé no chão. Transformar a conversa em estratégia concreta de oferta, arquitetura e posicionamento comercial.
O ponto mais importante do alinhamento não foi "qual modelo usar". O ponto central foi outro: se a Yamaha quiser que a solução rode no tenant dela, a Robbu precisa vender know-how, desenho, implantação e governança — e não só um bot pronto hospedado do nosso lado.
Verificar se desenvolver dentro da infraestrutura da Yamaha é realmente factível — não apenas em teoria, mas na prática.
Mapear problemas de suporte, logs, manutenção e incidentes caso o ambiente não seja nosso.
Mover de "produto operado pela Robbu" para algo mais próximo de consultoria + implantação + know-how.
Transformar o alinhamento em material tangível até sexta-feira — fluxogramas, desenhos, documentação.
Não existe bloqueio técnico intrínseco. O desafio é muito mais de fronteira contratual, operacional e de responsabilidade do que impedimento tecnológico.
Se ficar no ambiente Yamaha, a Robbu deixa de vender "operação de bot" e passa a vender:
A analogia que surgiu na reunião: a Robbu constrói o carro, instala sensores, ensina como opera, e depois o cliente traz o diagnóstico quando precisar de ajuste.
Se o ambiente não for nosso, não teremos acesso livre ao servidor. Logs apenas do lado deles = sustentação dependente de eles coletarem e compartilharem evidências. Sem isso, a Robbu pode ser cobrada por problema que não consegue enxergar.
Sem observabilidade minimamente padronizada, não faz sentido prometer SLA forte em ambiente do cliente.
Mesmo nos ambientes da Robbu já existem problemas reais: crédito acabando em provedor, ferramentas não aguentando carga, indisponibilidade. Se isso acontece no nosso lado, pode acontecer no da Yamaha. A diferença: lá, infra mínima e monitoramento são responsabilidade deles.
A mensagem correta não é "fiquem tranquilos, a gente resolve tudo". É: "A solução é viável, mas precisa de modelo claro de ownership entre aplicação, infraestrutura, observabilidade e suporte."
O caso Yamaha passou a ser lido como ensaio de um modelo que pode se repetir com grandes contas. A BV já está numa movimentação similar. Isso pode virar uma linha estratégica da Robbu: levar know-how e integrar no ambiente do cliente quando a exigência política e regulatória pedir.
Um dos melhores alinhamentos da reunião. Se a proposta é rodar dentro da estrutura Yamaha/Azure, insistir em n8n adiciona ruído desnecessário. O mais inteligente é traduzir para equivalentes já aceitos:
A venda não é "deixar nosso stack igualzinho lá dentro". A venda é: pegar a lógica, os guard-rails e o know-how da Robbu e reimplementar dentro do ecossistema que já faz sentido para eles.
O desenho não deve explicar "IA em abstrato". Deve partir do bot de cobrança de 5 a 15 dias — caso real, já reconhecido pela Yamaha.
A reunião deixou claro: não é outsourcing puro, licenciamento puro, nem body shop.
Yamaha talvez seja só o primeiro caso mais explícito de uma demanda que tende a crescer. Se bem tratado, vira template para outros clientes grandes com o mesmo perfil — e pode reposicionar a Robbu num nível mais sofisticado de exigência corporativa.
| Entrega | Responsável | Prazo | Status |
|---|---|---|---|
| Fluxograma do bot de cobrança com IA — como funciona hoje | Felipe + Luiz | 11/04/2026 | Pendente |
| Proposta de arquitetura adaptada para o tenant da Yamaha | Felipe | 11/04/2026 | Pendente |
| Detalhamento de segurança (guard-rails, criptografia, proteções) | Felipe | 11/04/2026 | Pendente |
| Traduzir stack para ecossistema Yamaha (Logic Apps, Power Automate, etc.) | Felipe | 11/04/2026 | Pendente |
| Envio do material ao Marco/Pezani | Rodrigo | Após conclusão | Aguardando |
| Viabilizar reunião técnica com time dos EUA | Marco / Pezani | Semana 14/04 | Aguardando |
| Articular viabilidade contratual (tenant Yamaha) | Pezani + Fernando | Em paralelo | Aguardando |
| Preparar narrativa em inglês para reunião técnica | Felipe | Antes da reunião | Planejado |
Antes da próxima conversa, preciso ter respostas objetivas para estes pontos.
1. Qual é exatamente o recorte do fluxo de cobrança de 5 a 15 dias que vamos mostrar?
2. Em quais etapas a IA entra hoje e com qual finalidade?
3. Quais integrações seguem puramente determinísticas?
4. Qual seria o desenho mínimo de human-in-the-loop?
5. Se rodar no tenant deles, qual a fronteira exata de responsabilidade Robbu × Yamaha?
6. Quais logs e métricas são indispensáveis para suporte?
7. Quais controles de segurança já temos e quais poderíamos oferecer como customização?
8. Qual discurso oficial sobre modelo: Copilot primeiro, Azure alternatives como plano B, ou ambos desde o começo?
Formulações testadas e prontas para a próxima conversa com a Yamaha.
O projeto Yamaha não deve ser tratado apenas como implantação de bot com IA — deve ser tratado como desenho de solução enterprise sob governança do cliente.
Levar uma proposta visual, simples e segura, mostrando um piloto de cobrança com IA entrando apenas onde agrega valor, operando com guard-rails, validação humana final e possibilidade concreta de execução dentro do tenant da Yamaha, usando o ecossistema Azure/Microsoft como base de confiança.
O melhor caminho:
Esse é o tipo de projeto em que a Robbu não ganha só pela tecnologia. Ganha por mostrar que sabe operar no nível de exigência de uma empresa global, conservadora e orientada por governança.