Projeto Integrador: Micro-SaaS com IA

14.1 Ideação, proposta de valor e arquitetura

Escolha um problema estreito, com usuário identificável e dados que você pode usar legalmente. Bons exemplos:

Entregável da etapa: uma página com problema, público, alternativa atual, por que IA (Módulo 9.1), três métricas de sucesso e o desenho inicial em ARQUITETURA.md. Comece o dataset de avaliação agora, com 20 casos escritos à mão: ele guia todas as decisões seguintes.

14.2 Entrega 1: núcleo de RAG e agente com evals (CLI)

Antes de qualquer tela, o núcleo funciona pela linha de comando e é medido:

• Indexação e busca híbrida com citações (projeto do Módulo 4 como base).
• Agente com orçamento, detecção de laço e aprovação para ações irreversíveis (projeto do Módulo 6).
• Dataset de avaliação com pelo menos 40 casos com gabarito e tags, incluindo casos em que a resposta certa é "não sei".
• Testes automatizados com modelo roteirizado ou API falsa, que rodam sem chave.
• Primeiro relatório de evals com intervalo de confiança (Módulo 3.6) e custo por tarefa.

14.3 Entrega 2: API do back-end e servidor MCP

• API com validação de entrada, limites de taxa e orçamento por cliente, e chamadas ao modelo passando por um gateway com reserva e log de custo (Módulo 9).
• Prompts versionados em arquivos, com rollout gradual e caminho de rollback testado.
• Servidor MCP expondo pelo menos uma capacidade do seu produto (busca, consulta de pedido, criação de tarefa), com autenticação e auditoria no transporte HTTP (Módulo 5).
• CI rodando testes e o verificador a cada push, e evals com limiar em cada PR. Use kit/ci-exemplo.yml como ponto de partida.

14.4 Entrega 3: front-end, deploy, observabilidade e custos

• Front-end em React, Angular ou HTML puro, como preferir: streaming com botão parar, estados de erro claros, acessível por teclado, CSP restritiva e nenhuma chave no navegador (Módulo 8).
• Deploy numa plataforma com HTTPS e segredos gerenciados (Fly.io, Render, Railway, Cloud Run, uma VPS com Caddy…). Infraestrutura como código é bônus, passando pelas políticas do Módulo 10.
• Observabilidade: log estruturado por requisição (modelo, versão do prompt, tokens, custo, latência) e um painel com erro, p95 e gasto do dia.
• Custos: custo por tarefa medido, projeção mensal para um cenário realista e pelo menos uma alavanca aplicada e medida (modelo por rota, cache, batch ou destilação).

14.5 Revisão de segurança: red team do próprio projeto

1. Mapeie a tríade letal: onde há dados privados, conteúdo não confiável e canais de saída? Corte pelo menos um lado em cada fluxo (Módulo 12.2).
2. Rode o red team automatizado do Módulo 12 adaptado ao seu produto, com um canário plantado nos dados privados.
3. Faça uma rodada manual: injeção indireta em um documento do RAG, pedido de dados de outro cliente, tentativa de ação irreversível sem aprovação.
4. Todo ataque bem-sucedido vira teste automatizado e correção. Documente o antes e o depois.
5. Preencha a ficha do sistema (Módulo 12.5) e rode verificar_projeto.py.

Verificador rodado no projeto do Módulo 6, que é um projeto didático sem README de produto. A saída real mostra o tipo de coisa que costuma faltar:

  ✗ README na raiz  → Crie um README.md (use kit/MODELO_README.md)
  ✗ README: problema e público  → Seção explicando o problema e para quem
  ✗ README: arquitetura  → Seção ou ARQUITETURA.md com o desenho
  ✗ README: como rodar  → Passo a passo para rodar localmente
  ✓ testes automatizados
  ✓ dataset de avaliação (evals)
  ✓ sem segredos no repositório
  ✓ sem .env versionado
  · CI configurado  → Testes e evals rodando a cada PR (Módulos 3 e 7)
  ...
5/16 itens · obrigatórios faltando: 4

O verificador só confere a presença das peças; ele não sabe se as evals são boas. Isso é trabalho da banca.

14.6 Apresentação, documentação e defesa técnica

A defesa tem 20 minutos: 8 de demonstração e 12 de perguntas. Estrutura sugerida:

1. Problema e usuário (1 min): quem, qual dor, como resolvem hoje.
2. Demonstração ao vivo (4 min) do fluxo principal, com um caso em que o sistema diz "não sei" ou pede aprovação. Tenha um vídeo de reserva se a rede cair.
3. Números (2 min): qualidade com intervalo de confiança, custo por tarefa, resultado do red team.
4. Uma decisão difícil (1 min): o que você trocou por quê, com evidência.

Perguntas típicas da banca

• "Se o provedor ficar fora por uma hora, o que o usuário vê?"
• "Mostre um caso em que o sistema erra. Por que erra e o que você faria?"
• "Como você sabe que a versão 2 do prompt é melhor que a 1, e não ruído?"
• "Um documento do RAG manda o agente enviar dados para um site. O que acontece?"
• "Quanto custa com 10 vezes mais usuários? Qual é a primeira alavanca?"

Rubrica final

Eliminatórios: chave de API no repositório ou no navegador; números do README que não se reproduzem; ação irreversível sem aprovação humana.

Use o checklist de produção antes de cada entrega.

Recursos para aprofundar

• Building effective agents · quando usar workflow ou agente
• OWASP Top 10 for LLM Applications · lista de revisão para a etapa 14.5
• The Twelve-Factor App · configuração, logs e deploy de serviços