OpenAI vagas em SP: como virar Applied AI Engineer

Quando vi a notícia da OpenAI abrindo vagas de engenharia em São Paulo, meu primeiro pensamento foi: o jogo mudou. Não estamos mais falando de “empresa americana que atende o Brasil de longe”. Estamos falando de squad local, com brasileiros trabalhando em sistemas de IA que rodam em produção para Stripe, Uber e Reddit. Segundo o Olhardigital.com.br, são quatro vagas abertas, duas delas técnicas na equipe de Applied AI Engineering. E é aqui que mora o detalhe que pouca gente prestou atenção: essas vagas não são para “pesquisadores de IA”. São para engenheiros que sabem levar protótipo à produção.

Por que “Applied AI Engineer” não é “AI Engineer”

Na minha experiência, vejo muita gente confundindo os dois papéis. O AI Engineer tradicional foca em treinar, ajustar e avaliar modelos. O Applied AI Engineer faz outra coisa: integra modelos existentes em sistemas reais, com usuários reais, latência real e SLAs reais. É a diferença entre rodar um Jupyter Notebook no seu laptop e manter um serviço atendendo 50 milhões de requests por dia.

Essa distinção importa porque a OpenAI não está contratando gente para “brincar com GPT”. Está contratando gente que entende de pipelines, observabilidade, fallback, rate limiting, segurança corporativa e governança de dados. Quando você trabalha com clientes como Stripe e Uber, qualquer decisão técnica vira decisão de negócio. Um token a menos aqui, um retry a mais ali, e a conta no fim do mês explode.

O que as duas vagas realmente pedem (e o que isso significa)

Vaga 1: Parceiros de tecnologia (Stripe, Uber, Reddit)

Essa posição é focada em empresas de tech que já têm produto maduro e querem adicionar IA. O engenheiro vai trabalhar lado a lado com os times dessas empresas para integrar as APIs em produtos existentes. Isso significa:

• Entender a arquitetura do cliente antes de sugerir qualquer integração
• Projetar fallbacks quando a API da OpenAI está fora ou lenta
• Implementar cache inteligente (não é só Redis — é saber quando invalidar)
• Monitorar custo por requisição e por feature

Vaga 2: Grandes corporações com ambiente complexo

Essa é a vaga mais difícil, na minha opinião. Você vai lidar com arquiteturas legadas, times de segurança pedindo reunião, compliance exigindo logs, e stakeholders que mudam de prioridade toda semana. O candidato precisa saber traduzir “queremos usar IA” em “queremos reduzir churn em 15% usando classificação automática de tickets”. Domínio de Python é obrigatório, experiência em levar protótipo à produção é obrigatória, e o diferencial é saber avaliar sistemas de IA de forma sistemática — não é “achismo”, é métrica.

Na Prática: o que um Applied AI Engineer precisa saber de cor

Vou te dar um cenário real que aparece toda semana em produção. Você precisa integrar a API da OpenAI em um sistema que processa documentos jurídicos. O usuário faz upload de um PDF, e o sistema precisa resumir, classificar e extrair cláusulas. Parece simples até você descobrir que o documento tem 200 páginas, a OpenAI tem limite de tokens, e o cliente corporativo proíbe enviar dados confidenciais para APIs externas.

A solução passa por três decisões técnicas que você precisa dominar:

1. Chunking strategy: como dividir o documento sem perder contexto entre chunks
2. RAG vs. fine-tuning: quando usar cada um (spoiler: quase sempre RAG)
3. Observabilidade: como saber quando o modelo está alucinando ou degringolando em produção

Aqui vai um exemplo funcional de pipeline RAG com chunking semântico e fallback robusto:

import asyncio
from openai import AsyncOpenAI
from typing import List, Dict
from dataclasses import dataclass
import hashlib

@dataclass
class DocumentChunk:
    text: str
    embedding: List[float]
    metadata: Dict
    chunk_id: str

class ProductionRAGPipeline:
    def __init__(self, model: str = "gpt-4o-mini"):
        self.client = AsyncOpenAI()
        self.model = model
        self.cache = {}
        self.metrics = {"cache_hits": 0, "api_calls": 0, "errors": 0}

    async def embed(self, text: str) -> List[float]:
        cache_key = hashlib.sha256(text.encode()).hexdigest()
        if cache_key in self.cache:
            self.metrics["cache_hits"] += 1
            return self.cache[cache_key]

        self.metrics["api_calls"] += 1
        response = await self.client.embeddings.create(
            input=text,
            model="text-embedding-3-small"
        )
        self.cache[cache_key] = response.data[0].embedding
        return response.data[0].embedding

    async def semantic_chunk(self, text: str, max_tokens: int = 800) -> List[str]:
        paragraphs = [p.strip() for p in text.split("\n\n") if p.strip()]
        chunks = []
        current = ""
        current_count = 0

        for p in paragraphs:
            tokens = len(p.split())
            if current_count + tokens > max_tokens and current:
                chunks.append(current.strip())
                current = p
                current_count = tokens
            else:
                current = f"{current}\n\n{p}" if current else p
                current_count += tokens

        if current:
            chunks.append(current.strip())
        return chunks

    async def query(self, question: str, context_chunks: List[DocumentChunk]) -> str:
        context = "\n\n".join([c.text for c in context_chunks[:5]])

        try:
            response = await self.client.chat.completions.create(
                model=self.model,
                messages=[
                    {"role": "system", "content": "Responda apenas com base no contexto. Se não souber, diga 'não encontrado'."},
                    {"role": "user", "content": f"Contexto:\n{context}\n\nPergunta: {question}"}
                ],
                temperature=0.1,
                max_tokens=500,
                timeout=10.0
            )
            return response.choices[0].message.content
        except Exception as e:
            self.metrics["errors"] += 1
            return f"Erro temporário: {type(e).__name__}"

# Uso
async def main():
    pipeline = ProductionRAGPipeline()
    chunks = await pipeline.semantic_chunk("Texto do documento aqui...")
    for chunk in chunks:
        await pipeline.embed(chunk)
    resposta = await pipeline.query("Qual o prazo de pagamento?", [])
    print(resposta)

asyncio.run(main())

Esse código tem três coisas que separaram o júnior do sênior: cache por hash do conteúdo, timeout explícito, e system prompt que força o modelo a admitir quando não sabe. Em produção, sem isso, você vai queimar budget e vai ter alucinações vazando para o usuário final.

Erros Comuns que vejo em candidatos (e em produção)

1. Tratar a API da OpenAI como se fosse determinística

Cuidado com essa armadilha. Mesmo com temperature 0, o modelo pode dar respostas diferentes entre chamadas. Se seu sistema depende de output idêntico, você precisa de validação de schema, retry com feedback, ou um modelo mais simples para tarefas estruturais. Testei isso em produção e a diferença entre “funciona no demo” e “funciona com 10 mil usuários” é brutal.

2. Ignorar custo até o fim do mês

Na minha experiência, o erro mais caro é não instrumentar custo por feature desde o dia 1. Cada chamada de embedding, cada completion, cada retry por timeout — tudo isso multiplica. Um sistema mal projetado pode custar 10x mais que o necessário sem que ninguém perceba até a fatura chegar.

3. Confundir “vetorizar tudo” com “boa arquitetura”

Muitos devs jogam tudo no banco vetorial e acham que está resolvido. Não está. Você precisa de pré-filtragem por metadata, re-ranking com cross-encoders, e avaliação contínua da qualidade das respostas. Sem isso, seu RAG vira um Google lento e caro.

4. Subestimar governança e segurança

Quando você entra em corporativo, o time de segurança vai pedir: logs de auditoria, PII masking, data residency, e direito de apagar dados de treino. Se você não pensou nisso antes de vender a solução, vai voltar para a prancheta. Por isso a OpenAI pede experiência com “navegação em requisitos de segurança corporativa” — não é firula, é requisito.

Como se preparar para essas vagas (e por que a barreira é alta)

A OpenAI pede 8 anos de experiência técnica, mas isso é só o filtro inicial. O que realmente separa quem passa de quem fica pelo caminho é a capacidade de demonstrar três coisas:

1. System design com IA: como você projetaria um sistema que atende 1 milhão de usuários usando LLMs sem estourar orçamento?
2. Trade-offs concretos: quando você escolheu fine-tuning em vez de RAG, por qué? Qual foi o ganho mensurável?
3. Falhas e aprendizados: qual sistema de IA você colocou em produção que falhou, e como você corrigiu?

Se você está começando agora, foque em construir projetos open source com LLM, publique no GitHub com README bem escrito, documente decisões técnicas em blog posts, e contribua para projetos como LangChain, LlamaIndex ou OpenAI Cookbook. Isso vale mais que um MBA em IA.

Comparativo: por que Applied AI na OpenAI é diferente de outras empresas

Vou comparar com o que vejo no mercado brasileiro:

Aspecto	OpenAI (Applied AI)	Empresa brasileira típica
Escala	Milhões de usuários globais	Milhares a centenas de milhares
Stack	Python, TS, infra própria	Python, LangChain, vector DB comum
Foco	Parceria técnica com clientes enterprise	Feature única dentro do produto
Decisão técnica	Alta (define padrões globais)	Média (segue arquitetura do time)
Remuneração	Pacote internacional em USD	Real, abaixo do mercado americano

Não estou dizendo que uma é melhor que a outra. Estou dizendo que são músculos diferentes. A vaga na OpenAI te expõe a problemas que você só vê em escala global. A vaga em empresa brasileira te dá mais autonomia e proximidade com produto.

FAQ — Perguntas que devs me fazem sobre essa vaga

1. Preciso morar em São Paulo para me candidatar?

Segundo a descrição, o regime é híbrido com três dias presenciais por semana em São Paulo. Então sim, presencial em SP é parte do contrato. Se você está em outra capital, vai precisar se mudar.

2. Preciso de PhD ou mestrado para passar?

Não. A vaga pede 8 anos de experiência técnica e histórico comprovado em sistemas de IA em produção. PhD ajuda, mas portfolio com código em produção e contribuições open source pesam mais.

3. Quais linguagens são obrigatórias?

Python é obrigatório nas duas vagas. Para a vaga de parceiros de tech, proficiência em JavaScript ou TypeScript também é exigida, porque muito do trabalho envolve SDK e tooling para clientes.

4. Vale mais a pena tentar essa vaga ou ir para empresa brasileira de IA?

Depende do seu momento de carreira. Se você quer exposição global e aprendizado em escala, vá para OpenAI. Se você quer construir do zero, ter equity e crescer rápido em startup, fique no Brasil. Não existe resposta certa.

5. Como faço um portfolio que se destaque para essa vaga?

Publique 2-3 projetos no GitHub que resolvam problemas reais com LLMs. Documente decisões técnicas no README. Escreva um blog post explicando o que você aprendeu. Isso vale mais do que certificado de curso da Udemy.

Considerações finais

A abertura dessas vagas sinaliza algo maior: a OpenAI está tratando o Brasil como mercado estratégico, não como usuário casual. Para nós, devs, isso significa que existe um caminho real de trabalhar em IA de fronteira sem precisar emigrar. Mas — e isso é importante — a barra de entrada é alta. Não é posição para quem aprendeu LangChain no fim de semana.

Se você quer chegar lá, comece hoje: construa um projeto com LLM, coloque em produção, monitore métricas reais, e documente tudo. Em 2-3 anos, você terá o portfolio que essas vagas pedem. Na minha experiência, quem chega preparado não precisa de sorte.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.