Décimo quarto post da série. No anterior, usamos AI pro nosso próprio trabalho de infra. Agora: como levar uma organização inteira de “vamos usar AI” pra uma plataforma governada e escalável.
As melhores intenções, os piores resultados
Seu CTO entra no all-hands e diz: “Estamos indo all-in em AI.” A sala vibra. Times brainstormam use cases antes do meeting acabar. Em duas semanas, Slack está cheio de threads sobre disponibilidade de GPU.
Fast-forward três meses. Cinco times provisionaram GPU VMs independentemente em quatro subscriptions. Ninguém sabe dizer quais modelos estão em produção versus experimento de fim de semana. Dois times pagam reserved instances em clusters que ficam idle 80% do tempo. Segurança não revisou nenhum deployment. CFO quer saber por que a fatura Azure subiu 40%.
O entusiasmo existia. O framework não.
O modelo de 6 fases
Inspirado no Cloud Adoption Framework da Microsoft, mas reconstruído especificamente pra infra teams. Cada fase tem deliverables concretos e critérios de saída claros.
Diagnóstico → Capacitação → Preparação de Infra → Experimentação → Scale e Governança → Adoção Contínua
Pense como o lifecycle de infraestrutura aplicado a AI: avaliar, construir, validar, escalar, operar, iterar.
Fase 1: diagnóstico (onde estamos hoje?)
Antes de construir qualquer coisa, assessment honesto. A pergunta: se um time precisasse deployar um modelo em produção amanhã, sua infraestrutura suportaria com segurança?
Readiness scorecard
| Área | Perguntas-chave | Rating (1-5) |
|---|---|---|
| Skills do time | Time consegue provisionar e gerenciar GPU compute? | ___ |
| GPU readiness | Quotas aprovadas? Regiões selecionadas? | ___ |
| Networking | Private endpoints, bandwidth, DNS? | ___ |
| Segurança | Managed identity, Key Vault, isolamento de rede? | ___ |
| Automação | Cobertura IaC, maturidade CI/CD, GitOps? | ___ |
| Shadow AI | Deployments não autorizados identificados? | ___ |
Score abaixo de 3 em qualquer área = trabalho focado na Fase 2 antes de prosseguir. Não esconda scores baixos; eles são o output mais valioso dessa fase.
Shadow AI detection
O audit que todo mundo pula e todo mundo precisa. Procure: times rodando modelos em subscriptions pessoais, API keys em repos de código, GPU VMs provisionados fora de pipelines IaC, ferramentas SaaS AI processando dados da empresa sem review de segurança.
Shadow AI não é só problema de governança. É exposição de segurança. Cada endpoint de modelo não revisado é um data leak potencial. Trate com a mesma urgência de servidores sem patch.
Fase 2: capacitação (construindo a base)
Fecha os gaps do Diagnóstico. Investimento em pessoas, processos e tooling de base.
Upskilling do time
Engineers de infra não precisam entender backpropagation. Precisam de: GPU memory management, patterns de inference scaling, pricing baseado em tokens. Três tiers:
- Foundational: Conceitos AI em linguagem de infra (esse glossário visual que vem no próximo post)
- Operational: Deploying e monitoring AI workloads (posts 3-8 desta série)
- Advanced: Performance tuning, cost optimization (posts 9-12)
Security baseline (inegociável)
- Todos os serviços autenticam via managed identity (sem exceção)
- Todos os secrets vivem em Key Vault com rotação automatizada
- Todos os model endpoints atrás de private endpoints
- Todo acesso a dados segue least-privilege RBAC
Documente como policies, não sugestões.
Fase 3: preparação de infraestrutura (construindo a plataforma)
Aqui seus skills de IaC viram superpoder. Transforma o baseline em plataforma self-service repetível. Tudo codificado; se não pode ser deployado de um git commit, não deveria existir.
Templates pra padrões comuns
- GPU VM clusters pra training (Bicep/Terraform)
- AKS clusters com GPU node pools pra inference
- Azure ML workspaces com networking
- Azure OpenAI deployments com diagnostic settings
Cada template inclui controles de segurança baked in: private endpoints, managed identity, diagnostic settings, resource tagging.
Monitoring stack (deploy antes dos workloads)
- GPU utilization e memória (DCGM exporter)
- Inference endpoint latency (P50/P95/P99)
- Token consumption tracking
- Cost attribution por time e projeto
- Model health indicators
Cost governance (implemente antes de custar caro)
Budgets por time, alertas em 50%/75%/90%, tagging obrigatório, GPU quota governance. Se não existe antes dos workloads, não vai existir depois.
Fase 4: experimentação (exploração controlada)
Plataforma pronta, times podem experimentar com guardrails.
Sandbox environments
- Resource groups dedicados com cost caps via Azure Policy
- GPU quotas dimensionadas pra experimentação
- Cleanup automático: sandboxes inativos 14 dias = flagged, 30 dias = decommissioned
- Tag única por experimento desde o dia 1
Success criteria obrigatórios
Antes de iniciar um experimento, o time define:
- O que sucesso se parece (accuracy threshold, latency target, cost ceiling)
- Que sinais de infra indicam viabilidade em escala
- Próximo passo se funcionar
Experimentos sem success criteria não são experimentos; são hobbies.
Fase 5: scale e governança (indo pra produção)
A transição de “funciona no sandbox” pra “roda com SLAs de forma confiável.”
Multi-tenancy e isolamento
- Namespace ou resource group isolation por time
- GPU quota enforcement por tenant
- Network segmentation entre workloads
- Dashboards de monitoring por time
SLA/SLO design pra AI
Defina SLOs pra: availability, latency (P99), throughput, error budget. Endpoints AI têm failure modes únicos (model loading delays, GPU memory exhaustion, token rate limiting) que seu SLO design precisa contemplar.
Tradução infra ↔ AI: “SLA de inference endpoint” é exatamente como SLA de web API. A diferença: cold start pode ser 30 segundos (carregando GBs de model weights em GPU memory), e resource exhaustion geralmente é GPU memory, não CPU. Mesma disciplina, recursos diferentes.
Fleet management e runbooks
Documente procedimentos pra: scaling durante traffic spikes, model version rotation zero-downtime, GPU hardware failure response, token rate limiting (429s), cost overrun management.
Fase 6: adoção contínua (nunca termina)
AI infra não é projeto com data de fim. É capability que evolui continuamente.
Cadência trimestral
- Review de utilization trends
- Ações de cost optimization
- Updates de segurança
- Technology radar changes
- Métricas de adoção self-service
- Roadmap do próximo quarter
Technology radar
Categorize ferramentas e serviços como:
- Adopt: Provado, padronizar
- Trial: Promissor, avaliação time-boxed
- Assess: Interessante, monitorar
- Hold: Não pronto
Os 5 anti-patterns que matam adoção
| Anti-pattern | O que acontece | Como evitar |
|---|---|---|
| Big Bang | 6 meses construindo plataforma perfeita, ninguém usa | Comece com MVP, itere |
| Shadow AI | Times deployam sem envolvimento de infra | Torne o caminho governado o mais fácil |
| GPU Hoarding | Times reservam quota “por precaução” | Use-it-or-lose-it: <20% utilização por 30 dias = reclaimed |
| Security Afterthought | “Adicionamos segurança depois” | Templates com managed identity e private endpoints por default |
| Build Everything | Framework custom quando managed service existe | Default pra managed services |
Esses anti-patterns se compõem. Big Bang causa Shadow AI (times não esperam). Shadow AI cria Security Afterthought (deployments pulam review). Reconhecer o padrão é o primeiro passo.
No próximo post
Framework de adoção completo. No último post da série, o glossário visual: sua Pedra de Roseta infra ↔ AI. Todo termo de AI mapeado pra um conceito de infraestrutura que você já domina.