Série PMLE - 1 de 5
Publicado a 18 de Abril de 2026
Antes de decorar serviços, convém perceber a forma do território. O exame da Professional Machine Learning Engineer não é uma lista aleatória de produtos: é um teste à tua capacidade de ligar dados, modelação, serving, automação, monitorização e, agora, generative AI, numa arquitetura coerente.
Neste post
- Como ler esta certificação sem estudar por silos
- Os seis domínios oficiais
- A stack mínima que tens de reconhecer
- APIs pré-treinadas: quando não precisas de treinar
- Matriz de decisão low-code vs custom
- Cenários típicos de exame
- Equipas, governance e contexto organizacional
- IAM, VPC Service Controls e segurança
- O que precisas de saber para o exame
Como ler esta certificação sem estudar por silos
A PMLE não testa se sabes escrever um modelo de raiz em TensorFlow sem olhar para a documentação. A Google diz explicitamente que o exame não avalia diretamente coding skill. O que é testado é a tua capacidade de reconhecer a arquitetura certa, escolher a ferramenta certa para o nível de maturidade do problema, antecipar riscos de produção e raciocinar sobre trade-offs.
Essa nuance interessa muito. A certificação mistura caminhos low-code, como BigQuery ML e partes do Vertex AI, com cenários mais clássicos de ML engineering: datasets grandes, pipelines reprodutíveis, model registry, serving, monitorização e retraining. E a versão atual ainda acrescenta um bloco explícito de generative AI, com referência direta a Model Garden e Vertex AI Agent Builder.
1. Dados e features
Qualidade, acessos, splits, leakage, pipelines e consistência entre treino e serving.
2. Modelação e avaliação
Escolher o caminho certo, treinar de forma reprodutível, medir a coisa certa e promover modelos com critério.
3. Serving e operação
Endpoints, batch prediction, pipelines, monitorização, retraining, rollout e custo operacional.
4. GenAI e Responsible AI
Foundation models, agentes, avaliação generativa, safety, privacy e governação de sistemas AI.
Os seis domínios oficiais, lidos como sistema
Na página oficial, a Google resume o exame em seis verbos. Lidos isoladamente, parecem tópicos separados. Lidos em conjunto, descrevem o ciclo de vida inteiro.
| Domínio | O que realmente implica | Onde reaparece na série |
|---|---|---|
| Arquitetar soluções de IA low-code | Escolher quando BigQuery ML, AutoML, foundation models geridos ou outros caminhos mais rápidos são suficientes. | Partes 1, 3 e 5 |
| Colaborar dentro e entre equipas para gerir dados e modelos | Versionamento, governance, papéis de equipa, acesso a dados, avaliação e handoff entre stakeholders. | Partes 1, 2 e 4 |
| Escalar protótipos para modelos de ML | Sair do notebook, treinar de forma reprodutível, avaliar bem e preparar o modelo para produção. | Parte 3 |
| Servir e escalar modelos | Batch, online, endpoints, latência, throughput, custo e robustez operacional. | Parte 4 |
| Automatizar e orquestrar pipelines de ML | Pipeline design, MLOps, retraining, automação e governança do ciclo de vida. | Partes 2, 3 e 4 |
| Monitorizar soluções de IA | Skew, drift, performance, segurança, avaliação contínua e melhoria do sistema. | Partes 4 e 5 |
O mais importante aqui é evitar estudar cada domínio como se fosse uma gaveta autónoma. No exame, quase todas as perguntas interessantes atravessam duas ou três gavetas ao mesmo tempo.
A stack mínima que tens de reconhecer
Se alguém te acordar a meio da noite e te pedir a stack base da PMLE, a resposta curta é esta: dados, modelação, serving, pipelines, monitorização e generative AI, tudo organizado sobretudo à volta de Vertex AI e serviços de dados adjacentes.
| Bloco | Serviços que tens de reconhecer | Porque aparecem no exame |
|---|---|---|
| Plataforma central | Vertex AI, Vertex AI Workbench/Notebooks, Model Registry, Pipelines, Endpoints | É a espinha dorsal da maioria dos cenários modernos na Google Cloud. |
| Dados e analytics | BigQuery, BigQuery ML, Cloud Storage, Dataflow, Dataproc | O exame assume que dados e features não vivem isolados do resto do sistema. |
| Low-code AI | BigQuery ML, AutoML/serviços geridos do Vertex AI | Escolher o nível certo de abstração é parte da avaliação. |
| Pre-built APIs | Vision API, Natural Language API, Translation API, Speech-to-Text, Document AI | Para problemas comuns (OCR, classificação de imagem, análise de sentimento), uma API pronta pode ser a melhor resposta. O exame testa se sabes quando não precisas sequer de treinar. |
| Generative AI | Model Garden, Gemini via Vertex AI, Agent Builder | Está explicitamente incluído na versão atual da certificação. |
| Controlo e governance | IAM, projetos, APIs, Dataplex, monitorização, práticas de Responsible AI | Produção sem governance é uma forma cara de improviso. Dataplex ajuda com catálogo, lineage e qualidade de dados à escala. |
APIs pré-treinadas: quando não precisas de treinar
Antes de saltar para AutoML ou treino customizado, o exame espera que consideres se uma API pré-treinada resolve o problema diretamente. Estas APIs usam modelos mantidos pela Google e não exigem dados de treino, pipeline nem infraestrutura de serving. A decisão é: o teu problema é suficientemente genérico para que um modelo universal já o resolva?
| API | O que faz | Quando usar em vez de treinar |
|---|---|---|
| Cloud Vision API | Deteção de objetos, classificação de imagem, OCR, landmarks. | Quando as categorias são genéricas ("pessoa", "carro") e não precisas de classes customizadas. |
| Natural Language API | Análise de sentimento, reconhecimento de entidades, classificação de texto. | Quando o domínio é genérico e não tens jargão específico (médico, jurídico) que exija treino. |
| Speech-to-Text / Text-to-Speech | Transcrição de áudio, síntese de voz. | Quando a língua e o sotaque estão cobertos pelos modelos padrão da Google. |
| Document AI | Extração de texto e dados de formulários, faturas, contratos. | Quando o layout do documento segue padrões comuns. Para layouts muito específicos, pode exigir fine-tuning. |
| Translation API | Tradução automática entre idiomas. | Quando a precisão genérica é suficiente. Para terminologia técnica, considerar glossaries ou fine-tuning. |
Matriz de decisão low-code vs custom
Se uma API pré-treinada não resolve o problema, a próxima decisão é o nível de controlo que precisas sobre o treino. Uma das tensões mais importantes da PMLE é saber quando não precisas de construir tudo do zero. Se o problema é bem estruturado, os dados já vivem em BigQuery e a pergunta é preditiva, BigQuery ML pode ser suficiente. Se precisas de algo mais elaborado, controlado ou escalável, entras no universo mais amplo do Vertex AI com treino customizado, pipelines, registry e serving dedicado.
O exame gosta desta distinção porque ela é profundamente prática. Muito trabalho de ML falha não por falta de modelos sofisticados, mas por excesso de sofisticação prematura. Saber escolher o caminho mais simples que resolve o problema é uma competência de engenharia, não uma concessão.
| Condição do problema | Sinal a favor de low-code | Sinal a favor de abordagem custom |
|---|---|---|
| Dados tabulares em warehouse | BigQuery ML permite iterar depressa, com SQL e menor overhead operacional. | Se precisares de arquiteturas específicas, controlo fino de treino ou integrações fora do warehouse. |
| Problema bem definido e métrica conhecida | AutoML ou serviços geridos podem resolver mais rapidamente. | Se a avaliação exigir lógica própria, métricas customizadas ou governança mais elaborada. |
| Equipa pequena e urgência alta | Menos moving parts, menos infra para manter. | Se a simplicidade inicial vier a bloquear serving, tuning, explainability ou controlo de custos. |
| GenAI / foundation models | Model Garden e Agent Builder reduzem tempo até ao primeiro protótipo funcional. | Se precisares de controlo apertado sobre grounding, segurança, tuning ou integração profunda com sistemas internos. |
Cenários típicos de exame
Cenário A: churn com dados já em BigQuery
O negócio quer um baseline rápido, com equipa reduzida e dados historicamente bem estruturados.
- Primeira pergunta: há leakage temporal nas features?
- Segunda pergunta: BigQuery ML resolve o problema sem complexidade desnecessária?
- Terceira pergunta: como vais monitorizar drift e re-treino depois?
Cenário B: visão ou NLP com treino mais exigente
Precisas de treino mais controlado, tuning e artefactos governados num ciclo MLOps real.
- Vertex AI passa a ser o centro da arquitetura.
- Model Registry e pipelines deixam de ser luxo e passam a ser requisito.
- Serving e monitorização têm de ser pensados desde cedo.
Cenário C: assistente corporativo com grounding
O pedido parece ser “um chatbot”, mas o problema real é recuperar contexto credível e controlar segurança.
- Model Garden e Agent Builder podem acelerar o arranque.
- Evaluation, safety e privacy tornam-se partes centrais da resposta.
- Não basta “o modelo funcionar”; precisa de funcionar dentro da política da organização.
Cenário D: organização regulada
Mesmo um modelo simples pode exigir mais governance do que um modelo complexo num contexto mais livre.
- IAM, lineage, aprovações e rastreabilidade influenciam a opção correta.
- Explainability e documentação podem pesar tanto como a métrica final.
- O caminho tecnicamente “mais elegante” pode ser o menos defensável.
Equipas, governance e contexto organizacional
Outro ponto importante: a PMLE não é uma certificação de data science académica. É uma certificação de sistemas operacionais dentro de uma organização. Isso implica colaboração com equipas de dados, produto, segurança, operações e negócio. Implica também perguntar quem pode aceder a quê, como se versiona um modelo, como se valida uma mudança e como se mede se a solução continua saudável em produção.
Por isso, conceitos como IAM, separação entre ambientes, lineage, rastreabilidade e governance de dados/modelos importam. Nem sempre aparecem como o tema principal de uma pergunta, mas condicionam a opção correta.
Dados
Quem pode ler dados brutos, quem publica features e como separar ambientes de exploração, treino e produção.
Modelos
Quem promove versões, quem aprova rollout e como registar lineage, artefactos e métricas de aceitação.
Operação
Quem responde a incidentes, monitoriza degradação e decide retraining, rollback ou revisão de arquitetura.
Em linguagem de exame, isto traduz-se em perguntas como: a equipa precisa de rapidez ou de controlo? O dado já está em BigQuery ou exige pipeline dedicado? O risco de produção é técnico, económico ou regulatório? Quem precisa de ver o quê? Sempre que um cenário menciona colaboração entre equipas, assume que a arquitetura e o modelo de acesso fazem parte da resposta.
IAM, VPC Service Controls e segurança
O exame não espera que sejas especialista em segurança, mas espera que saibas como a segurança afeta decisões de ML. Dois conceitos aparecem com frequência suficiente para merecer atenção:
IAM roles relevantes para Vertex AI
| Role | O que permite | Quando usar |
|---|---|---|
| Vertex AI User | Criar e gerir modelos, endpoints, pipelines. Não gere permissões. | Data scientists e ML engineers que trabalham no dia-a-dia. |
| Vertex AI Admin | Tudo do User + gerir permissões, configurar monitoring, aprovar deploys. | Team leads e responsáveis por governance do projeto. |
| Service Account User | Permite que um utilizador aja em nome de uma service account. | Necessário para submeter training jobs ou pipeline runs que precisam de aceder a recursos com a identidade da service account. |
VPC Service Controls
VPC Service Controls criam um perímetro de segurança à volta de recursos Google Cloud, impedindo que dados saíam do perímetro mesmo que um utilizador com permissões tente aceder de fora. É particularmente relevante em cenários com dados sensíveis (PII, PHI, dados regulados).
Perímetro
Define quais projetos e serviços estão protegidos. Dados dentro do perímetro não podem ser exportados para fora.
Dry Run Mode
Simula o perímetro sem o impor. Permite identificar que acessos seriam bloqueados antes de ativar em produção.
Access Levels
Permitem exceções controladas: ex: permitir acesso de IPs corporativos específicos mesmo de fora do perímetro.
O que precisas de saber para o exame
- Reconhecer os seis domínios oficiais e perceber como eles se sobrepõem em cenários reais.
- Entender Vertex AI como plataforma unificada: exploração, treino, registry, pipelines, serving e monitorização.
- Perceber quando BigQuery ML e outros caminhos low-code fazem mais sentido do que um pipeline totalmente customizado.
- Saber quando uma API pré-treinada (Vision, NLP, Document AI, Speech) resolve o problema sem treino.
- Conhecer a stack de dados adjacente: BigQuery, Cloud Storage, Dataflow e Dataproc.
- Raciocinar com matrizes de decisão: requisitos, custo, maturidade da equipa, governança e necessidade de controlo.
- Perceber que o currículo atual inclui generative AI, Model Garden e Vertex AI Agent Builder.
- Distinguir IAM roles (Vertex AI User vs Admin vs Service Account User) e o impacto nos workflows.
- Perceber VPC Service Controls, perímetros, dry run mode e como afetam acesso a dados em produção.
- Tratar governance, IAM, colaboração entre equipas e monitorização como partes do sistema, não como acessórios.
Praticar na documentação e nos labs oficiais
- Página oficial da certificação PMLE
- Learning path oficial da PMLE na Google Skills
- Visão geral do Vertex AI
- Introdução ao BigQuery ML
- Arquitetura MLOps na Cloud Architecture Center
Na próxima parte, entramos no bloco que mais facilmente arruína um sistema antes mesmo de haver modelo: qualidade de dados, preparação, feature engineering e pipelines.