Um centro de IA com 4 cientistas atende uns 4 pedidos por trimestre, e as áreas mandam 10. Contratar mais cientistas de dados e pendurá-los na diretoria de tecnologia não transforma uma empresa numa organização de produto de IA. A unidade de trabalho deixa de ser uma funcionalidade com resultado conhecido e passa a ser um modelo de comportamento probabilístico: muda quando o mundo muda, depende de dados que alguém precisa obter e defender e carrega obrigações legais que o ágil clássico nunca precisou colocar no preço.
Errar o desenho organizacional faz cada uma dessas pressões voltar mais tarde, como fila de seis meses, base de dados sem rastreabilidade ou modelo que ninguém tem coragem de aprovar. Quem responde por um modelo que falha às duas da manhã? Se a resposta demora, o organograma já está errado.
Três topologias, e a fila decide entre elas
A maioria das empresas se acomoda em uma de três estruturas.
Muitas começam com um centro de excelência, que concentra o talento escasso, define padrões e prototipa rápido.
Depois vem a plataforma sob as equipes de aplicação: a plataforma é dona das ferramentas comuns (onde ficam os dados usados pelos modelos, como eles são treinados, o registro de versões, os testes de qualidade e os controles automáticos). As equipes de aplicação respondem pelo problema de produto de ponta a ponta, pelos experimentos e pelo resultado de negócio.
A estrutura em que a maioria das grandes empresas termina é a federada: plataforma central dona de infraestrutura e governança, equipes de domínio com cientistas de dados integrados e uma autoridade única para as definições de métrica e de custo.
Para traçar a linha entre plataforma e aplicação, a frequência de mudança ajuda mais do que a tecnologia, porque o atrito nasce de quem precisa mexer em quê e com que pressa. O que muda toda semana fica com quem atende o cliente; o que muda uma vez por trimestre vai para a plataforma.
A transição entre as formas quase sempre é decidida pela fila. Faça a conta com números redondos. Um centro de excelência com 4 cientistas tem 52 pessoas-semana por trimestre. Se cada pedido das áreas consome em média 2 pessoas durante 6 semanas, isto é, 12 pessoas-semana, o centro entrega pouco mais de 4 pedidos por trimestre. Chegam 10.
A fila cresce cerca de 6 pedidos a cada trimestre, e quem pede em julho espera até o ano seguinte. Nenhuma diretoria aguenta isso por muito tempo, e as áreas montam times paralelos fora dos padrões. O centro que garantia a qualidade vira o motivo pelo qual a qualidade some.
Federar cedo demais tem o custo oposto: espalha competência escassa e ninguém aprofunda. Federar tarde demais deixa a dívida de padrões crescer até que reconciliar três definições de "cliente ativo" custe mais do que teria custado defini-las juntas no começo.
Quando cada topologia serve, e quando trocar
- Centro de excelência: serve enquanto o talento de IA é raro demais para espalhar e a espera cabe no ciclo de planejamento de quem pede. O gatilho de saída é a espera passar de um trimestre; o número de cientistas contratados, que costuma ser a métrica que a diretoria acompanha, diz pouco aqui.
- Plataforma sob as equipes de aplicação: serve quando duas ou mais equipes de produto usam a mesma maquinaria (avaliação, deploy, monitoramento) e a duplicação começa a doer. Com um único produto, só se justifica se houver trabalho realmente compartilhado; sem reutilização, acrescenta custo e uma camada de coordenação.
- Federada: serve quando vários domínios precisam iterar em paralelo e uma autoridade central ainda segura as definições de métrica e custo. Se essas definições não existem, a federação apenas troca o gargalo de fila pela dívida de padrões.
Regra de troca: se a espera média na fila central passar de um trimestre e pelo menos duas áreas já tiverem contratado gente de IA por conta própria, federe; se a espera for menor que um ciclo de planejamento, fique onde está e invista em padrões.
Cada papel responde por uma pergunta diferente
Produtos de IA exigem papéis que o software clássico não tem ou define de outro jeito, porque alguém precisa ser dono do ciclo de vida do modelo, dos dados, da avaliação e da governança. A forma mais útil de descrevê-los é pela pergunta que cada um responde quando algo dá errado.
O product manager de IA responde "por que este modelo existe e como sabemos que funciona?". Ele enquadra o problema e a hipótese, verifica se os dados existem, define critérios de avaliação e salvaguardas (limites que o modelo não pode cruzar, como taxa máxima de recusa indevida), é dono do plano de experimentação e mantém engenharia, ciência de dados e jurídico olhando para o mesmo alvo.
O cientista de dados responde "o que dá para aprender com estes dados?". Prepara os dados, testa o modelo antes do lançamento, cuida do rigor estatístico e monta protótipos que dizem cedo se uma ideia é viável. O engenheiro de ML responde "funciona em produção, na escala real?". Integra e coloca o modelo no ar, garante que ele responda rápido e acompanha o drift: a mudança de comportamento quando os dados de entrada mudam.
O engenheiro de MLOps cuida do que ninguém vê: que o modelo possa ser acompanhado, que seja retreinado quando precisa e que cada versão fique registrada. Os especialistas em avaliação e segurança constroem os conjuntos de referência (exemplos rotulados que não mudam entre versões, para que a comparação seja justa) e testam o modelo contra alucinações, vieses e ataques antes do lançamento.
Os designers tornam a incerteza legível, com indicadores de confiança e etapas de revisão humana. O líder de governança de dados responde de onde veio cada dado e com qual base legal pode ser usado.
No Brasil esse último papel conversa de perto com o encarregado pelo tratamento de dados pessoais, o DPO previsto na LGPD. Em muitas empresas os dois são a mesma pessoa no início, o que funciona enquanto há poucos modelos em produção. Quando o número cresce, o encarregado precisa de alguém dentro do time de produto que entenda a cadeia de dados, ou cada pergunta de um titular vira uma investigação de semanas.
A revisão humana tem uma armadilha própria. Quem revisa tende a aceitar a recomendação automatizada mesmo quando ela está errada, ainda mais quando o volume é alto e o modelo costuma acertar. Se o revisor aprova 99% das sugestões do modelo, a etapa humana existe no fluxograma e não na prática. Vale medir a taxa de discordância do revisor e desconfiar quando ela fica perto de zero.
Contratar esses perfis também tem uma particularidade local. Engenheiros de ML e de MLOps experientes no Brasil disputam vagas remotas de empresas estrangeiras que pagam em dólar, e a comparação de remuneração costuma ser feita nessa moeda. Para uma empresa brasileira, a resposta raramente é cobrir a oferta. Funciona melhor oferecer problema relevante, autonomia sobre o modelo em produção e uma carreira técnica que não obrigue o engenheiro a virar gestor para crescer.
O trabalho anda em círculos até o rollout
O caminho até a produção tem oito passos, e a ordem difere da do software clássico:
- O PM define problema, hipóteses e critérios de avaliação.
- O cientista de dados avalia a viabilidade dos dados.
- Engenheiros de ML constroem protótipos com o cientista de dados.
- PM e cientista de dados avaliam os resultados offline.
- A engenharia integra o modelo à experiência do usuário.
- O PM conduz experimentos online.
- A equipe de segurança valida a prontidão.
- MLOps implanta, monitora e retreina.
Chamar isso de sequência engana, porque as setas voltam. Uma avaliação offline fraca no passo quatro devolve o trabalho ao passo dois, não ao cinco. Um experimento online que não move a métrica no passo seis pode revelar que a hipótese do passo um estava errada, e não o modelo. No software, um requisito aprovado tende a continuar aprovado; aqui, o que parecia viável na prova de conceito deixa de ser quando o dado real chega. O time precisa estar montado para voltar barato.
A distância entre o offline e o online é maior do que parece. Ganho na métrica offline nem sempre vira ganho de negócio, e a espera que o usuário sente na tela pode anular o que o modelo ganhou em precisão. Daí duas consequências práticas: o passo seis não é opcional, e a latência entra nos critérios de avaliação do passo um, ao lado da precisão.
A avaliação também não é uma fase no fim. Toda semana, o PM olha quantas respostas o modelo acerta e quantas deixa escapar, quanto ele demora, quantas vezes inventa, o custo por inferência e os sinais de drift, como um PM de SaaS olha um funil. O código do modelo é a parte pequena do sistema; dados, configuração e monitoramento acumulam a maior parte da dívida técnica, e é ali que um modelo envelhece sem que ninguém perceba. Um time que só olha a métrica do modelo está olhando para a menor parte do problema.
O artigo 20 da LGPD exige um dono antes do primeiro lançamento
A LGPD tem uma regra que define parte do desenho do time. O artigo 20 garante ao titular o direito de pedir a revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses, inclusive as que definem o perfil pessoal, profissional, de consumo e de crédito. O controlador também precisa fornecer, quando solicitado, informações claras sobre os critérios e procedimentos usados, respeitados os segredos comercial e industrial, e a Autoridade Nacional de Proteção de Dados pode fazer auditoria para verificar aspectos discriminatórios.
Na prática, isso exige três coisas que muitos times descobrem tarde. Alguém precisa receber e responder os pedidos de revisão num prazo razoável, com acesso ao histórico da decisão. O modelo precisa registrar as entradas e a versão usada em cada decisão relevante, ou a revisão vira adivinhação. E a explicação dos critérios tem de existir em linguagem que um cliente e um fiscal entendam.
Quanto trabalho isso dá? Um cálculo ilustrativo: uma fintech que toma 50 mil decisões de crédito automatizadas por mês e recebe pedidos de revisão em 0,5% delas tem 250 pedidos mensais. Com 20 minutos por pedido, quando o registro da decisão está completo, são cerca de 83 horas, metade de uma pessoa em tempo integral. Sem registro, cada pedido leva duas ou três horas de investigação entre ciência de dados e atendimento, e o mesmo volume consome mais de três pessoas. A diferença entre meia pessoa e três pessoas é decidida no passo oito, quando alguém escolhe se o log de decisão entra no deploy.
Um framework de IA responsável transforma esse tipo de exigência em verificação de rotina. O checklist de partida pode ser curto: quem governa cada modelo, que riscos ele cria, como esses riscos são medidos e quem age quando algo sai do lugar.
O ponto central é atribuir a cada caso de uso um nível de risco que determina o escrutínio: um modelo que recomenda artigos no blog não passa pelo mesmo comitê que um modelo que nega crédito. Documentação de dados e logs de auditoria tornam esses julgamentos reexamináveis, e é isso que separa uma política real de uma declaração de intenção.
A governança também não termina no lançamento: cada modelo é registrado, monitorado, retreinado num cronograma definido e, um dia, desligado com saída documentada.
O marco legal de IA em tramitação no Congresso, o PL 2338/2023, aprovado pelo Senado em dezembro de 2024 e ainda sem votação na Câmara em outubro de 2026, aponta na mesma direção, com obrigações maiores para sistemas de alto risco. Um time que já responde bem ao artigo 20 terá menos a mudar quando a lei sair.
Todo o time precisa ler o que o modelo entrega
A IA eleva o piso de competência do time inteiro. Todo papel de produto precisa entender, em linhas gerais, como os modelos funcionam: quando inventam respostas, como recebem instruções, como buscam em documentos, como se mede a qualidade e que riscos éticos trazem. O suficiente para decidir, não para treinar o modelo. Sobre isso vem a fluência em dados, ler painéis de desempenho e sinais de drift bem o bastante para discordar deles. Saber quando um resultado de teste A/B é real é habilidade compartilhada.
Como a IA tem custo variável, o PM segura estratégia e unit economics juntos, modelando custo de inferência e o equilíbrio entre precisão e custo antes que eles apareçam numa fatura em dólar.
Esse piso mais alto muda o perfil de quem se contrata. Não adianta somar um especialista brilhante em modelos a um time de produto que não consegue ler o que ele entrega: o gargalo deixa de ser a modelagem e passa a ser a tradução entre a linguagem estatística e a decisão de produto. Times que investem nessa alfabetização compartilhada discutem trade-offs em reuniões curtas. Times que a ignoram terceirizam toda decisão técnica a uma pessoa e ficam reféns da agenda dela.
Um teste rápido: peça ao PM que explique, em dois minutos, por que o modelo com 94% de precisão foi rejeitado em favor de um com 91%. Se a resposta mencionar custo do erro (um falso positivo que bloqueia um cliente bom custa mais do que um falso negativo revisado manualmente) ou latência, o piso está no lugar. Se a resposta for "o cientista de dados recomendou", ainda não está.
O mesmo piso muda a colaboração, que começa no discovery e se sustenta num ritual. O cientista de dados entra no discovery enquanto o problema ainda está se formando, e o PM define os critérios de avaliação antes de o modelo existir. Viabilidade e sucesso ficam combinados de antemão. Depois, os engenheiros de ML transformam protótipos em versões de produção, os designers moldam a camada de explicação e o MLOps mantém o resultado observável.
O roadmap é planejado em camadas de capacidade: o que as cadeias de dados precisam suportar, como o modelo deve evoluir, quais dependências de plataforma condicionam o trabalho. Custo de inferência e latência entram nele antes de qualquer desenho, porque decidem o que é realista.
Como um sistema probabilístico não promete resultado fixo, a comunicação com a diretoria também muda: ela precisa de uma faixa de comportamento esperado e dos cenários de risco, e uma data com um número só cria falsa certeza.
Um ritual simples mantém o grupo honesto: uma revisão quinzenal de modelos em produção, de trinta minutos, com uma única pergunta por modelo, "quem responde por ele e o que mudou desde a última vez?".
O cientista de dados traz a métrica offline, o MLOps traz drift e custo, o PM traz o efeito no produto e o responsável por governança traz os pedidos de revisão e reclamações. Quando algum modelo fica sem resposta para a primeira parte da pergunta, a reunião cumpriu sua função. Não é raro aparecer, logo nas primeiras semanas, ao menos um modelo que ninguém lembrava que ainda estava ligado.
Três números dizem se o desenho funciona. A espera média na fila de IA, que deve ficar abaixo de um ciclo de planejamento. A parcela de modelos em produção com dono nomeado, que deve ser 100%. E o tempo de resposta a um pedido de revisão do artigo 20. A salvaguarda é o custo por inferência por cliente ativo: se ele sobe trimestre após trimestre enquanto a fila cai, a federação está comprando velocidade com margem.
E se a empresa for pequena demais para tudo isso?
A dúvida aparece logo em empresas com um único produto e cinco ou seis pessoas de tecnologia. Para elas, plataforma, comitê de risco e revisão quinzenal parecem cerimônia copiada de quem tem mil engenheiros. Em parte, elas têm razão. Com um produto e um modelo, um time multifuncional único, em que o mesmo engenheiro faz ML e MLOps, entrega mais rápido do que qualquer topologia. Montar plataforma antes da segunda equipe de produto é pagar coordenação sem ter o que coordenar.
O que não escala para baixo é a responsabilidade. Mesmo uma startup de oito pessoas que decide crédito ou preço com um modelo responde ao artigo 20 da mesma forma que um banco. A versão mínima cabe numa página: um dono por modelo, o registro de entradas e versão em cada decisão, um caminho para o pedido de revisão. O resto pode esperar.
Para quem já passou desse tamanho, a ordem das operações pesa mais do que qualquer escolha isolada. Combine o modelo operacional (quem é dono da plataforma, como a governança funciona, quais métricas são definidas de forma central) antes de aumentar o quadro, porque uma reorganização depois custa muito mais do que um plano de contratação desenhado para caber. A medição vem antes da estrutura: primeiro as definições de avaliação e de custo padronizadas, para que todos meçam com a mesma régua; depois os componentes compartilhados separados da equipe mais sobrecarregada; por último, as linhas de reporte.
A decisão mais barata de todo esse desenho é nomear quem responde aos pedidos de revisão do artigo 20 antes de o primeiro modelo decidir sobre pessoas.