Em fevereiro de 2023, eu publiquei um artigo no Data Hackers descrevendo o Data Translator: o guardião do plano conjunto na tríade Produto, Engenharia e Negócio. O profissional que opera entre squads, traduz sistemas e pessoas em ambas as direções, e garante que investimento em dados se converta em decisão organizacional.
O artigo foi lido por milhares de pessoas. Dois anos depois, as ferramentas ao redor do Translator mudaram em velocidade que eu não antecipava. Agentes autônomos de código estão sendo adotados por equipes técnicas em escala. Protocolos de conexão direta entre agentes e fontes de dados eliminaram semanas de trabalho de integração. E a prática de avaliar qualidade de output de AI, que antes vivia restrita a laboratórios de pesquisa, virou ferramenta operacional.
A missão do Translator permanece a mesma. O campo onde ele opera ganhou instrumentos novos. Preciso atualizar o que escrevi porque os eixos do radar ganharam disciplinas que não existiam quando publiquei o artigo original.
O que o Translator sempre foi
O conceito não nasceu comigo. Em 2018, a McKinsey publicou na Harvard Business Review o que chamou de "the new must-have role" (o novo papel indispensável): o Analytics Translator. O McKinsey Global Institute estimou que a demanda por esse perfil chegaria a 2 a 4 milhões de profissionais só nos Estados Unidos até 2026. Estamos em 2026. A demanda existe. O volume de profissionais formados pra atendê-la, não.
O que aconteceu entre 2018 e hoje foi que o mercado reinterpretou essa demanda. Quando Zhamak Dehghani cunhou o conceito de Data Mesh em 2019 e introduziu a figura do "domain data product owner", o mercado gradualmente formalizou o título de Data Product Manager. O DPM é um papel valioso, bem definido, e resolve um problema real: ownership de data products dentro de squads.
O Translator resolve um problema diferente. Ele opera entre squads, entre business units, entre a operação e o C-level. O horizonte dele conecta os trimestres com os objetivos de longo prazo: definir programas orientados a resolver problemas reais onde os dados são figura central pra tomada de decisão estratégica, tática e operacional.
O ciclo de trabalho do Translator funciona assim: ele trabalha com a tríade de managers de engenharia, negócio e produto pra entender os problemas e leva essas questões pro time de dados, pra avaliar o que é possível fazer e quais são os riscos. Com esse diagnóstico em mãos, a tríade e o Translator levam as propostas pra diretores como novas iniciativas e apostas. Se aprovado, descem novamente pros times pra fazer definições detalhadas e trabalhar nas hipóteses que valem a pena dentro das apostas e iniciativas definidas. Durante todo o processo, o Translator orquestra a tríade e representa o andamento das coisas nas reuniões de acompanhamento, reportando métricas de sucesso e thresholds pra decidir se continua ou abandona uma hipótese e segue pra próxima dentro do programa.
Pelo seu perfil generalista, ele consegue transmitir necessidades com clareza pra engenheiros de dados, analistas, cientistas de ML, times de governança, e retornar com o diagnóstico do que é possível, do que precisa de negociação, e do que inviabiliza a hipótese como formulada.
O DPM cuida de produto de dados. O Translator cuida de Data as a Product. É o profissional capaz de levar a cultura data-centric pra uma empresa, porque entende o impacto dos dados no negócio e sabe articular isso em todos os níveis. Se quiser uma analogia com produto: pense no DPM como quem executa as funções clássicas de ownership de produto de dados dentro do squad. O Translator é quem absorveu essas funções e expandiu o escopo, saindo do tático-operacional de um squad ou múltiplos squads pra algo organizacional, com impacto em várias áreas ao mesmo tempo através de diplomacia e coordenação. As competências do DPM estão contidas no Translator, que adiciona a camada estratégica e a visão transversal que conecta tudo.
Na prática, quando a liderança de dados precisa responder "Investimos R$3 milhões em dados no ano passado, qual foi o retorno?", é o Translator quem monta o plano pra chegar nessa métrica e explica o porquê. Quando duas business units usam definições diferentes de "cliente ativo" e isso causa divergência nos reports executivos, é o Translator quem traz esse problema da tríade, tendo identificado a raiz no trabalho com os times de dados de cada BU que geraram produtos de dados de fontes diferentes, e facilita a mediação envolvendo as áreas de negócio, engenharia e produto, porque dados nunca toma decisão sozinho que não seja de infraestrutura.
Eu tive a oportunidade de ser um Translator antes de me tornar executivo de dados. Trabalhei com mais de 10 empresas nesse conceito e tive a chance de implementar isso numa fintech, liderando uma operação de dados com mais de 60 pessoas, num ecossistema com várias unidades de negócio diferentes entre si, em estrutura híbrida entre Brasil e México. A princípio não tínhamos nem plataforma unificada. Quando começamos a organizar times de data product, a figura do DPM apareceu naturalmente pra cuidar da plataforma como produto e dos produtos de dados de cada unidade de negócio. O que ficou evidente rápido é que não conseguíamos justificar o investimento em plataforma, sendo que o negócio era sedento nos produtos de dados pra ontem. Foi aí que a figura do Translator fez diferença: ele conseguiu começar a mensurar o quanto um outcome entregue na plataforma tinha impacto multiplicado pra todas as BUs, habilitando entregas que antes eram impossíveis, e como isso retornava como ROI. O principal gargalo daquela operação era traduzir o investimento em infraestrutura em valor percebido pelo negócio, e essa tradução era exatamente o trabalho que ninguém estava fazendo de forma sistemática antes do Translator entrar em cena.
Os 7 eixos que definem o perfil
O Translator precisa entender bem 7 eixos de competência diferentes. A profundidade de especialista ele precisa ter em pelo menos um dos eixos técnicos, e obrigatoriamente no eixo de estratégia de negócio. Nos demais, precisa saber o suficiente pra tomar decisão, negociar escopo, e garantir coerência sistêmica entre todas as disciplinas envolvidas.
O primeiro eixo é Engenharia de Dados. É a conversa com Data Engineers sobre pipelines, ETL, processamento. A situação real: o time de dados diz que precisa de 3 meses pra entregar o pipeline. O negócio quer em 3 semanas. O Translator negocia escopo sem destruir qualidade, porque entende os trade-offs técnicos e sabe explicar pro negócio a razão concreta pela qual aquele prazo existe.
O segundo é Arquitetura de Dados. A conversa com Architects e Platform teams sobre Data Warehouse, Lakehouse, cloud, modelagem dimensional. A situação real: o CEO contratou uma tecnologia nova porque foi convencido de que aquilo transformaria a empresa em data-driven. O executivo de dados pediu análise ao time e o Translator trouxe os prós e contras de implementação técnica junto com o risco financeiro, e propôs uma prova de conceito antes de comprometer orçamento de migração completa.
O terceiro é Análise, BI e Comunicação. A conversa com analistas e stakeholders que consomem dados. A situação real: a empresa tem 200 dashboards. Ninguém sabe quais são confiáveis. O VP pede "um dashboard único com tudo". O Translator redireciona porque sabe que o problema não é consolidação visual, é governança de métricas.
O quarto é ML e IA. A conversa com ML Engineers e Data Scientists. A situação real: o time construiu um modelo de churn com 92% de acurácia, mas o negócio não confia nos resultados. O Translator constrói a narrativa que gera adoção porque sabe explicar o que 92% de acurácia significa no contexto específico daquele negócio, incluindo o custo de cada falso positivo.
O quinto é Governança e Qualidade. A conversa com Data Stewards, CDO, e obrigatoriamente envolvendo as áreas de negócio, engenharia e produto. A situação real: duas BUs usam definições diferentes de "cliente ativo". Isso causa divergência nos reports executivos. O Translator facilita a mediação entre os domínios pra chegar numa definição que funcione pra ambos, sempre trazendo as áreas de negócio junto, porque dados nunca resolve esse tipo de questão sozinho.
O sexto é Privacidade e Compliance. A conversa com jurídico, CISO e DPO. A situação real: marketing quer cruzar dados de navegação com CRM pra personalização. Jurídico levanta risco de LGPD. O Translator media porque entende o suficiente de ambos os lados pra encontrar o caminho viável.
O sétimo é Estratégia de Negócio. A conversa com C-level, VPs e Diretores. É o eixo obrigatório: todo Translator precisa desenvolver profundidade aqui. A situação real: a liderança de dados precisa construir a estratégia de como a empresa se torna data-driven. Consulta os Translators porque eles são quem conhece os gaps reais entre o que o negócio pede e o que os times de dados conseguem entregar.
O radar que desenvolvi permite mapear a posição de cada profissional nesses 7 eixos com precisão e montar um plano de desenvolvimento individualizado. A regra: fluência em todos, profundidade real no eixo de estratégia de negócio, e especialização em pelo menos um dos eixos técnicos.
O que mudou em dois anos
Três mudanças técnicas entraram no jogo desde 2023, e cada uma altera como o Translator opera sem alterar o que ele é.
A primeira é a chegada de agentes autônomos como ferramenta de trabalho em times de dados e engenharia. Segundo o Gartner, 40% das aplicações enterprise terão agentes task-specific integrados até o final de 2026, comparado com menos de 5% em 2025. A projeção de longo prazo é que agentic AI gere mais de 450 bilhões de dólares em receita de software enterprise até 2035. Esses números significam que o Translator vai operar num ambiente onde parte significativa da execução técnica é feita por agentes. Os times que ele orquestra vão incluir agentes como membros de fato.
A segunda é o MCP, Model Context Protocol. Protocolos que permitem conectar agentes diretamente a fontes de dados como BigQuery, Segment, Salesforce, sem integrações customizadas. Na prática, isso muda a velocidade com que times de dados podem validar hipóteses. O que antes exigia semanas de construção de pipeline agora pode ser feito em horas. O Translator não executa essa validação. Ele formula a hipótese certa e traz o time de dados pro jogo estratégico. Se ele passa a testar todas as hipóteses sozinho com agentes, ele deixa de orquestrar os 7 eixos pro negócio e vira um Product Owner com acesso a ferramentas mais sofisticadas. O papel do Translator é garantir que o time certo está olhando pro problema certo com os dados certos.
A terceira é a formalização de evals como prática de engenharia. Eval é o processo de medir se o output de um agente atende critérios específicos de qualidade. Antes, "o modelo funciona" era impressão subjetiva. Agora, equipes maduras definem critérios binários e testáveis. O Translator precisa saber definir esses critérios no nível do negócio. Ele é quem sabe que 92% de acurácia pode ser excelente ou inútil dependendo do custo de falso positivo naquele domínio específico. Essa competência de traduzir julgamento tácito em critério verificável é nova no radar.
O custo de escalar sem julgamento
Agentes estão absorvendo funções operacionais em times de dados e engenharia: geração de código, testes, documentação, QA. O que essa migração coloca em evidência é justamente o trabalho que resta quando a execução é automatizada: formular a hipótese de negócio que orienta o trabalho, definir o que "correto" significa no contexto daquela unidade de negócio, e perceber quando o output está tecnicamente correto mas usa premissas comerciais que não se aplicam.
Esse trabalho é o que o Translator faz. E a razão pela qual ele se torna mais importante com a automação, e não menos, é que o volume de output cresce enquanto a curadoria de qualidade continua dependendo de repertório humano acumulado ao longo de anos de convivência com o domínio.
Em julho de 2024, pesquisadores da Universidade de Oxford e da Universidade de Toronto publicaram na Nature um estudo demonstrando o que chamaram de model collapse. A conclusão do paper: "indiscriminate use of model-generated content in training causes irreversible defects in the resulting models, in which tails of the original content distribution disappear". Em português: usar output de AI indiscriminadamente como insumo pra mais AI causa defeitos irreversíveis nos modelos resultantes. As caudas da distribuição original desaparecem. O modelo perde diversidade e gera output cada vez mais homogêneo e distante da realidade.
POR QUE ISSO É IMPORTANTE: Interpretar informação errada com AI dá o poder de escalar o erro como nunca antes, sem tempo de voltar atrás. Se um agente consulta dados com a definição errada de "cliente ativo" e gera um relatório que parece correto, e esse relatório alimenta a decisão de um VP, e essa decisão vira diretriz pra 3 business units, o erro se propaga em cadeia. Cada camada amplifica. Reverter exige reconstruir a cadeia inteira.
O Translator é a linha de defesa contra isso. Ele conhece o domínio o suficiente pra saber que "cliente ativo" tem 3 definições diferentes dependendo da BU. Conhece o sistema técnico o suficiente pra saber onde o agente provavelmente não recebeu o contexto certo. E tem a posição organizacional pra intervir antes que o output vire decisão.
Vale entender por que mesmo um SPEC bem escrito não resolve esse problema sozinho. O conhecimento implícito de domínio que faz diferença na interpretação dos dados quase sempre vive na cabeça de quem opera o negócio há anos, fora de qualquer documento. A regra de negócio que diz "cliente ativo na unidade de assinaturas é quem acessou nos últimos 90 dias, mas na unidade de serviços é quem tem contrato vigente" existe na prática dos times, não nos repositórios de especificação. Nenhum SPEC prevê todos os edge cases que surgem quando você cruza fontes de dados de BUs diferentes. O julgamento contextual do Translator funciona porque ele acumula esse repertório ao vivo, conversando com os 7 eixos simultaneamente, e percebe os conflitos que nenhum documento antecipou.
O ciclo completo
Frameworks como Scrum começam no backlog, por design. Tudo que acontece antes fica invisível pro processo: sinais de cliente que alguém interpretou, diretivas de liderança que alguém traduziu em escopo, incidentes que criaram urgência, ideias que alguém articulou e conectou com dados disponíveis.
O Translator opera em todo o ciclo. Está presente na definição do objetivo, na construção da iniciativa, na aposta estratégica que gera as hipóteses. Está presente no backlog, garantindo que as hipóteses estão bem formuladas e que os critérios de sucesso fazem sentido. E acompanha a execução, fechando o ciclo entre o que foi construído, o que foi medido, e o que isso significa pra próxima rodada de decisões.
PANORAMA GERAL: O DPM cuida do ciclo dentro do squad, garantindo que o produto de dados está sendo construído com qualidade. O Translator cuida do ciclo entre o negócio e os dados, garantindo que o que está sendo construído resolve o problema certo e que o resultado volta como aprendizado pra próxima iniciativa. Um opera o produto de dados. O outro opera o programa. E os dois se complementam: o DPM que entende o trabalho do Translator ganha contexto estratégico. O Translator que tem DPMs fortes nos squads ganha velocidade de execução. Se você é DPM e já faz parte do que estou descrevendo aqui, conectar o produto de dados com o resultado de negócio, mediar entre times técnicos e liderança, pensar além do backlog, você já está no caminho de se tornar um Translator.
Com agentes acelerando a execução, o ciclo completo ficou mais rápido. A qualidade da formulação, da curadoria de contexto e do fechamento de loop continua dependendo de gente que entende o negócio, entende os dados, e sabe onde os dois se desencontram.
Três competências novas no radar
Os 7 eixos continuam válidos. Mas dentro deles, três competências se tornaram necessárias.
A primeira é julgamento contextual sobre output de AI, que impacta diretamente os eixos de ML/IA (Eixo 4) e Governança e Qualidade (Eixo 5). O Translator sempre precisou avaliar se uma análise fazia sentido. Agora ele precisa avaliar output que parece correto na superfície mas pode estar errado de formas sutis. Um relatório que usa dados tecnicamente válidos mas mistura definições de duas business units sem avisar. Um agente que gera código funcional mas ignora edge cases que só alguém com contexto de negócio perceberia. A competência é saber onde o agente provavelmente erra dado o tipo de tarefa e o contexto que ele recebeu. Pense como funciona revisão de código em engenharia de software: o sênior não lê cada linha, ele sabe quais partes do sistema são frágeis e quais premissas o autor provavelmente assumiu sem perceber. O Translator de 2026 precisa do equivalente disso pra output de AI em contexto de negócio.
A segunda é design de evals pro domínio de negócio, que conecta o Eixo 7 (Estratégia de Negócio) com o Eixo 4 (ML/IA). Se o Translator consegue especificar o que "correto" significa em termos que podem ser testados automaticamente, o time de dados pode avaliar output de agentes em escala sem revisão humana em cada caso. Se não consegue, todo output vira dependência manual, e a promessa de produtividade com AI vira gargalo disfarçado. O Translator traduz julgamento tácito de negócio em critério verificável de qualidade.
A terceira é especificação de workflows com agentes, que atravessa os eixos de Engenharia (Eixo 1), Arquitetura (Eixo 2) e Governança (Eixo 5). O Translator já orquestrava programas e iniciativas de dados com pessoas. Agora parte da execução nesses programas é feita por agentes. Saber especificar o que o agente recebe como input, quais restrições de segurança e qualidade aplicar, onde colocar gates de aprovação humana, e como estruturar feedback loops que melhorem o processo ao longo do tempo. O SPEC é o produto. O output do agente é consequência da qualidade do SPEC. Quem especifica bem recebe resultado que funciona. Quem especifica mal recebe resultado que parece funcionar, e a distância entre esses dois cenários pode custar meses de retrabalho.
Nenhuma dessas três competências aparece em descrições de vaga hoje. O mercado ainda procura "analista de dados sênior" ou "PM com experiência em AI", como se o gap fosse de título e não de perfil.
O teto que continua invisível
Segundo o MIT Sloan Management Review de 2025, mais da metade dos Chief Data Officers nas maiores empresas do mundo fica menos de 3 anos no cargo. A pesquisa, baseada no AI & Data Leadership Executive Benchmark Survey, identifica o motivo principal: esses líderes não conseguem demonstrar retorno tangível do investimento em dados. Investimento está acelerando em praticamente todas as organizações, mas quem lidera dados não está conseguindo traduzir esse investimento em resultado que o board entende. O gap é de tradução, e ele existe até no C-level.
Se você é DPM hoje, vale se perguntar: depois de Sênior DPM, qual é o próximo cargo? Até onde a trilha vai? Com as competências do Translator, você começa a ter habilidade pra chegar a cargos estratégicos: Head of Data Strategy, Director of Data, VP of Data, CDO. Porque não vai estar mais só no tático e no operacional cuidando de produto de dados, e sim entendendo o que esses produtos podem proporcionar pro negócio e articulando sua importância em linguagem que quem controla orçamento consegue avaliar.
O Gartner projeta que mais de 40% dos projetos de agentic AI serão cancelados até o final de 2027. Os motivos listados: custos escalando, valor de negócio indefinido, controles de risco inadequados. Estima ainda que apenas cerca de 130 dos milhares de vendors são reais, cunhando o termo "agentwashing". Olhe pra cada um desses motivos de cancelamento e perceba: custos escalando porque ninguém conectou o investimento com o outcome de negócio esperado antes de começar. Valor indefinido porque ninguém definiu métricas de sucesso junto com a tríade. Controles inadequados porque ninguém envolveu governança desde o dia zero. São três problemas de tradução entre tecnologia e negócio. O Translator existe pra resolver exatamente isso: ele garante que o programa de agentic AI começa com a hipótese certa, as métricas certas, e o envolvimento da tríade desde o primeiro dia. Sem essa figura, o projeto se torna exatamente o tipo de iniciativa que o Gartner está prevendo que será cancelada.
O perfil é antifrágil. Quanto mais automação existe no operacional, mais valioso fica quem garante coerência no estratégico. E o número de profissionais preparados pra fazer isso continua muito abaixo da demanda que a McKinsey previu em 2018.
A McKinsey identificou a demanda por milhões de Translators em 2018 e o mercado respondeu criando DPMs. A Nature documentou em 2024 que AI sem curadoria humana degrada de forma irreversível, e mesmo assim a maioria das empresas continua escalando agentes sem ninguém garantindo a qualidade do que sai do outro lado. O Gartner prevê que quase metade dos projetos de agentic AI vai ser cancelada até 2027, e os motivos são todos problemas de tradução entre tecnologia e negócio. O mercado tem um talento consistente pra diagnosticar o problema certo e investir na solução vizinha. Pelo menos agora o perfil que resolve isso tem nome, radar, programa de formação, e sete anos de evidência acumulada de que a demanda só cresce. O tempo nunca esteve tão propício pra se tornar um Translator.
Referências que valem a pena
- Analytics translator: The new must-have role (McKinsey / Harvard Business Review, 2018)
- AI models collapse when trained on recursively generated data (Shumailov et al., Nature 631, 2024)
- The Chief Data Officer Role: What's Next (MIT Sloan Management Review, 2025)
- Gartner Predicts 40% of Enterprise Apps Will Feature AI Agents by 2026 (Gartner, 2025)
- Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (Gartner, 2025)
- Você sabe o que é um Data Translator? (Vinícius Coimbra, Data Hackers, 2023)