Parte 2: DevOps AI-Native

IaC gerada por IA: humano revisa, IA escreve boilerplate

DevOps ai-native não é "deixar a IA subir em produção". É mudar quem escreve o boilerplate.

O padrão que funciona na prática é:

1. O humano descreve a infraestrutura pretendida em linguagem natural ou em um schema declarativo.
2. A IA gera o Terraform/Pulumi correspondente.
3. O humano revisa o plano (terraform plan), avalia o diff e aprova.
4. O apply só roda em CI, com approval gate e estado versionado.

Exemplo de prompt que gera HCL útil:

Gere um módulo Terraform para um bucket S3 com:
- nome prefixado por projeto
- versionamento habilitado
- criptografia SSE-S3
- lifecycle policy movendo para Glacier após 90 dias
- bloqueio de acesso público

Use convenções da AWS, sem providers deprecated.
Saída em HCL válido, sem comentários explicativos.

A IA devolve algo como:

resource "aws_s3_bucket" "dados" {
  bucket_prefix = "${var.projeto}-dados-"
  force_destroy = false
}

resource "aws_s3_bucket_versioning" "dados" {
  bucket = aws_s3_bucket.dados.id

  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "dados" {
  bucket = aws_s3_bucket.dados.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "dados" {
  bucket                  = aws_s3_bucket.dados.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_lifecycle_configuration" "dados" {
  bucket = aws_s3_bucket.dados.id

  rule {
    id     = "move-to-glacier"
    status = "Enabled"

    transition {
      days          = 90
      storage_class = "GLACIER"
    }
  }
}

O que muda aqui não é o HCL. É o fluxo. O guia de Terraform sobre modules segue sendo a referência canônica para estrutura. O que a IA agrega é velocidade na escrita do recurso que você já sabe que precisa.

O anti-pattern é o inverso: humano descreve intenção vaga, IA gera 400 linhas de HCL com providers deprecated, ninguém revisa, apply vira jogo de azar. A documentação oficial do Terraform e o relatório DORA State of DevOps são claros em um ponto: automação sem revisão humana piora confiabilidade, não melhora.

CI/CD com gates de eval

O pipeline de CI para um sistema ai-native tem um step a mais que o pipeline tradicional: o eval gate.

A lógica é simples: depois dos testes determinísticos e antes do deploy, roda a suíte de evals. Se a taxa de sucesso regrediu em relação ao baseline, o deploy é bloqueado.

O exemplo abaixo é um step de GitHub Actions que implementa esse gate. A suíte devolve um JSON com as taxas; o step decide se bloqueia.

name: ci-ai-native

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm typecheck
      - run: pnpm lint
      - run: pnpm test -- --coverage

  eval-gate:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile

      - name: Rodar eval suite
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: pnpm eval:run -- --report=json > eval-report.json

      - name: Comparar com baseline
        run: |
          node scripts/eval-gate.mjs \
            --report=eval-report.json \
            --baseline=.evals/baseline.json \
            --min-taxa-faithfulness=0.9 \
            --min-taxa-relevance=0.9 \
            --regressao-maxima=0.02

      - name: Upload do relatório
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: eval-report
          path: eval-report.json

  deploy:
    needs: eval-gate
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Deploy canary
        run: ./scripts/deploy-canary.sh
      - name: Promover se estável
        run: ./scripts/promote-if-stable.sh

O script eval-gate.mjs faz o trabalho real de ler o JSON, comparar com o baseline e falhar o step se a regressão passar do tolerado. A regra de ouro é: regressão de 2% na taxa de faithfulness já é suficiente para bloquear. Não espere regressões grandes.

Observabilidade de LLM: trace, tokens, latência, custo

Em produção, você não sabe o que aconteceu se não registrou. Para sistemas ai-native, OpenTelemetry e ferramentas especializadas como Langfuse são o padrão.

Cada request para um LLM deve gerar um trace contendo:

• ID do trace, ligado ao ID do request HTTP.
• Modelo versionado (não apenas "gpt-4o"; sim "gpt-4o-2024-08-06").
• Prompt de entrada (com PII redigido).
• Output do modelo.
• Tokens de entrada e saída.
• Latência por fase (TTFT, tempo até primeiro token; total).
• Custo estimado em dólares.
• Status: sucesso, erro, timeout, block por guardrail.

Exemplo de hook de observabilidade em TypeScript, usando a convenção OpenTelemetry:

import { trace, context, SpanKind, SpanStatusCode } from '@opentelemetry/api';

const tracer = trace.getTracer('llm-runner');

type LLMRequest = {
  modelo: string;
  prompt: string;
  contexto?: string;
  maxTokens: number;
};

type LLMResponse = {
  output: string;
  tokensEntrada: number;
  tokensSaida: number;
  latenciaMs: number;
  custoEstimado: number;
};

export async function chamarLLMComTrace(req: LLMRequest): Promise<LLMResponse> {
  return tracer.startActiveSpan(
    `llm.call ${req.modelo}`,
    { kind: SpanKind.CLIENT, attributes: { 'llm.model': req.modelo } },
    async (span) => {
      const inicio = Date.now();
      try {
        const promptRedigido = redigirPII(req.prompt);
        span.setAttribute('llm.prompt.length', promptRedigido.length);

        const resultado = await providerLLM(req.modelo, promptRedigido, req.maxTokens);
        const latenciaMs = Date.now() - inicio;
        const custoEstimado = calcularCusto(req.modelo, resultado.tokensEntrada, resultado.tokensSaida);

        span.setAttributes({
          'llm.tokens.input': resultado.tokensEntrada,
          'llm.tokens.output': resultado.tokensSaida,
          'llm.latency_ms': latenciaMs,
          'llm.cost_usd': custoEstimado,
          'llm.ttft_ms': resultado.ttftMs,
        });

        return {
          output: resultado.output,
          tokensEntrada: resultado.tokensEntrada,
          tokensSaida: resultado.tokensSaida,
          latenciaMs,
          custoEstimado,
        };
      } catch (erro) {
        span.recordException(erro as Error);
        span.setStatus({ code: SpanStatusCode.ERROR, message: (erro as Error).message });
        throw erro;
      } finally {
        span.end();
      }
    },
  );
}

Custo não é detalhe. Em sistemas ai-native, custo por request é métrica de SLO tanto quanto latência. Sem ele, você descobre o problema só quando a fatura chega.

Canary e shadow para modelos novos

Trocar de modelo é uma das operações mais arriscadas em sistemas ai-native. O novo pode estar mais barato e pior em faithfulnes, e o bug só aparece semanas depois.

Duas técnicas reduzem esse risco:

Shadow traffic envia a mesma requisição para o modelo novo, mas não devolve o output ao usuário. Compara-se offline as duas saídas em um conjunto de métricas (similaridade, custo, latência). Se após N dias o novo está alinhado ou melhor, promove.

Canary direciona uma fração pequena (1%, depois 5%, depois 25%) do tráfego real para o novo modelo, com rollback automático se qualquer SLO deteriorar: aumento de latência p95, crescimento de custo por request, queda de score nos evals online, aumento de reclamação de usuário.

A diferença com deploy canary tradicional é o conjunto de sinais. Em DevOps clássico, observa-se error rate e latência. Em ai-native, adiciona-se score de faithfulness calculado assincronamente pelo judge e custo por request.

Guardrails em produção

Produção ai-native precisa de guardrails que a aplicação clássica não precisa:

O detalhe operacional é: guardrail falha também. Todo guardrail precisa ser tratado como sistema, com observabilidade própria. Se o detector de prompt injection tem falso positivo alto, ele virou ataque de disponibilidade contra seus próprios usuários.

Anti-patterns comuns

Tratar cobertura de testes como métrica única para LLM

Cobertura mede linhas executadas. Não mede qualidade do output do modelo. Um arquivo com 100% de cobertura e faithfulness 0.6 em produção é um incidente esperando acontecer.

Deploy sem eval gate

Deployar prompt novo ou modelo novo sem gate de eval é a forma mais comum de introduzir regressão silenciosa. O CI passa, a fatura diminui, e três semanas depois descobre-se que faithfulness caiu de 0.92 para 0.78.

Sem observabilidade de tokens

Se o trace não registra tokens de entrada, tokens de saída e custo por request, você não consegue nem debugar nem otimizar. A fatura vira caixa-preta.

Confiar cegamente em LLM-as-judge

LLM-as-judge é rápido, barato e tendencioso. Todo judge precisa ser calibrado contra um conjunto rotulado por humanos. Sem calibração, o score 0.9 do judge pode significar 0.6 na realidade.

Guardrails que ninguém testa

Guardrails são código. Precisam de testes. Se o detector de prompt injection nunca recebeu um corpus de ataques conhecidos, ele é esperança, não defesa.

IaC gerada por IA sem revisão humana

A IA gera 400 linhas de Terraform, ninguém lê, o apply roda em prod e abre acesso público a um bucket. O terraform plan foi feito exatamente para esse momento. Use.

Como aplicar hoje

Comece pequeno. Em uma semana:

1. Escolha um fluxo ai-native que tenha golden dataset pequeno (20 a 50 casos).
2. Implemente um eval runner mínimo no formato mostrado acima, com uma métrica só (faithfulness ou relevance).
3. Adicione um step de eval gate no CI, comparando contra um baseline inicial.
4. Instrumente traces com tokens, latência e custo para o fluxo escolhido.
5. Defina um SLO: por exemplo, faithfulness p50 maior que 0.9 e custo p95 abaixo de X dólares por request.

Em um mês:

1. Estenda para 3 métricas e adicione shadow traffic para o próximo modelo.
2. Implemente guardrails de rate limit e PII filtering.
3. Adicione avaliação online (LLM-as-judge assíncrono sobre amostra de tráfego).

Checklist de QA e DevOps ai-native

• Existe golden dataset versionado para os fluxos principais.
• Evals offline rodam em todo PR.
• Eval gate bloqueia deploy quando taxa regrediu mais que o limiar.
• LLM-as-judge é calibrado contra rotulagem humana periódica.
• Testes probabilísticos rodam N amostras e aceitam X% de sucesso.
• IaC gerada por IA passa por plan e revisão humana antes do apply.
• Traces registram modelo versionado, prompt redigido, tokens, latência e custo.
• Custo por request é SLO monitorado, não só latência.
• Deploy de modelo novo usa canary ou shadow com rollback automático.
• Guardrails de rate limit, prompt injection e PII estão ativos e testados.
• Existe baseline de evals e processo de atualizá-lo com aprovação.
• Avaliação online roda sobre amostra de tráfego real.

Conclusão

QA e DevOps ai-native não substituem o que já existe. Eles adicionam uma camada que mede comportamento probabilístico onde testes determinísticos não enxergam.

A diferença entre um sistema ai-native que escala e um que vira incidente recorrente está em três perguntas que o time consegue responder com dados:

1. Qual a taxa de faithfulness do modelo em produção hoje?
2. Qual o custo por request e qual o SLO definido?
3. O que acontece se trocarmos de modelo amanhã?

Se a resposta para alguma dessas for "não sei", o trabalho começa ali. Eval primeiro. Trace sempre. Gate no CI. Canary no deploy. Guardrails em produção. O resto é DevOps que já conhecemos, agora com uma variável nova: o modelo que muda sozinho.

A próxima parada desta série é Métricas, Cultura e Segurança AI-Native: como medir o time ai-native, quais KPIs importam quando código é gerado por IA, e como cultura e segurança acompanham essa mudança.

Referências

• Demystifying evals for AI agents — Anthropic
• Building effective agents — Anthropic
• Evals guide — OpenAI
• DORA State of DevOps Report
• Terraform documentation — HashiCorp
• Terraform modules
• OpenTelemetry documentation
• Prometheus monitoring
• Langfuse — observability for LLMs
• Langfuse model-based evaluations
• RAGAS — evaluation framework for RAG
• GenAI observability patterns