# Diagnóstico de Arquitetura: Como Identificar Gargalos Antes que Eles Custem Caro

**Categoria:** Consultoria | **Tempo de leitura:** 12 min | **Autor:** Equipe ITC Service

---

Sistemas com IA falham de formas que sistemas tradicionais não falham. Latência imprevisível, custos que explodem sem aviso, modelos que degradam silenciosamente e filas de inferência que travam o produto inteiro. A maioria desses problemas é detectável antes de virar incidente — se você souber onde olhar. Este guia apresenta um framework prático de diagnóstico de arquitetura para sistemas com IA, baseado em casos reais de consultoria.

## Por que diagnósticos tradicionais não servem para IA

Frameworks clássicos (AWS Well-Architected, C4 Model) cobrem escalabilidade, segurança e custo. Mas ignoram dimensões críticas de sistemas com IA:

- **Custo variável por request**: uma query mal escrita pode custar R$ 0,50 em vez de R$ 0,001
- **Latência não determinística**: mesmo input, tempos diferentes dependendo do load do provedor
- **Degradação silenciosa**: modelo atualizado pelo vendor muda comportamento sem changelog
- **Dependência externa crítica**: API fora = produto parado (sem fallback óbvio)
- **Dados como código**: prompt/versionamento de dados é tão crítico quanto versionamento de software

Um diagnóstico de arquitetura para IA precisa cobrir essas dimensões além das tradicionais.

## Framework de Diagnóstico em 5 Camadas

### Camada 1: Fluxo de Dados e Privacidade

**Perguntas-chave:**
- Onde os dados pessoais entram no sistema?
- Quais componentes processam/armazenam dados sensíveis?
- Há transferência internacional de dados?
- Os prompts contêm PII? Como é feito o masking?
- Retenção de logs inclui conteúdo de prompts/respostas?

**Ferramentas de avaliação:**
- Mapeamento de fluxo de dados (DFD) específico para LLMs
- Matriz de risco LGPD por componente
- Inventário de vendors com acesso a dados pessoais

**Sinais de alerta:**
- Prompts enviados a APIs externas sem anonymização
- Logs de produção armazenando conteúdo completo de conversas
- Storage de embeddings em região fora do Brasil sem avaliação de impacto
- Ausência de DPA (Data Processing Agreement) com provedores de IA

### Camada 2: Arquitetura de Inferência

**Perguntas-chave:**
- Qual o padrão de chamadas LLM? (sync/async/streaming/batch)
- Há cache de respostas? De que tipo? (exact match / semantic / embedding)
- Como é feito o rate limiting e retry?
- Existe fallback entre modelos/provedores?
- Qual o timeout configurado vs SLA real do provedor?

**Métricas a coletar:**
- Latência p50/p95/p99 por endpoint/modelo
- Taxa de cache hit
- Error rate por provedor
- Custo médio por request (com e sem cache)
- Tempo de fila em picos

**Sinais de alerta:**
- Chamadas síncronas bloqueando threads de usuário
- Zero cache para prompts recorrentes
- Retry sem backoff exponencial (amplificação de incidentes)
- Timeout > 30s em endpoints de UI (usuário já abandonou)
- Single point of failure em provedor único

### Camada 3: RAG e Base de Conhecimento

**Perguntas-chave:**
- Como os documentos são ingeridos e chunked?
- Qual estratégia de embedding? Modelo? Dimensões?
- Como é feita a busca? (vector only / hybrid / reranking)
- Há validação de qualidade dos resultados?
- Com que frequência a base é atualizada/reindexada?

**Testes práticos:**
- Query set de 50 perguntas conhecidas → medir precisão/recall
- Teste de "documento novo" → tempo até estar disponível para busca
- Teste de "documento deletado" → confirma remoção do índice
- Benchmark de latência de busca sob carga

**Sinais de alerta:**
- Chunks > 1000 tokens perdendo contexto
- Embedding model incompatível com vector DB dimensions
- Busca puramente vetorial sem keyword fallback (perde queries exatas)
- Sem reranking em top-K > 5 (resultados irrelevantes no topo)
- Base desatualizada (>30 dias sem reindexação)

### Camada 4: Observabilidade e Custos

**Perguntas-chave:**
- Há tracing completo de cada request LLM? (input/output/tokens/latency/cost)
- Alertas estão configurados para anomalias de custo?
- Dashboard mostra custo por feature/user/cliente?
- Há budget alerts por projeto/departamento?
- Logs de prompt/response são retidos? Por quanto tempo?

**Ferramentas recomendadas:**
- LangSmith / Helicone / Braintrust para LLM observability
- AI Gateway da Cloudflare para cache + métricas nativas
- Custom dashboards Grafana com exporter de métricas LLM

**Sinais de alerta:**
- Custo mensal imprevisível (>30% variação mês a mês)
- Sem alertas de spike de uso (descobre só na fatura)
- Impossível atribuir custo a feature/cliente específico
- Logs de produção expirando em <7 dias (debugging impossível)
- Sem baseline de "custo normal" para detectar anomalias

### Camada 5: Resiliência e Fallback

**Perguntas-chave:**
- O que acontece quando o provedor LLM fica fora?
- Há modelo fallback? É testado regularmente?
- Circuit breaker está configurado? Com que thresholds?
- Degraded mode existe? O usuário percebe?
- Disaster recovery para base vetorial/documentos?

**Testes obrigatórios:**
- Chaos testing: derrubar provedor primário em staging
- Medir tempo de failover automático
- Validar qualidade do fallback vs primário
- Testar recuperação de base vetorial corrompida

**Sinais de alerta:**
- Sem fallback definido ("se cair, cai")
- Fallback nunca testado em produção/staging
- Circuit breaker com threshold alto demais (>50% errors para abrir)
- Degraded mode retorna erro genérico em vez de resposta útil limitada
- Backup da base vetorial não testado nos últimos 90 dias

## Executando o Diagnóstico

### Preparação (1 semana)
1. Coletar acesso a repositório, infra, métricas e logs
2. Entrevistar 3-5 stakeholders (dev, product, ops, business)
3. Mapear fluxos críticos de usuário
4. Definir janela de teste não destrutivo

### Execução (2-3 semanas)
1. Avaliação documental das 5 camadas
2. Testes práticos (load, chaos, qualidade RAG)
3. Análise de métricas históricas (3-6 meses)
4. Sessões de validação com time técnico

### Entrega (1 semana)
1. Relatório executivo (5 páginas, foco em riscos e ROI)
2. Relatório técnico detalhado (findings + evidências + recomendações)
3. Roadmap priorizado (quick wins vs projetos estruturais)
4. Sessão de apresentação e Q&A com stakeholders

## Output Típico de um Diagnóstico

### Findings Categorizados
| Severidade | Categoria | Finding | Impacto | Esforço |
|------------|-----------|---------|---------|---------|
| CRÍTICA | Resiliência | Sem fallback para provedor LLM | Produto indisponível em outage | 2 dias |
| ALTA | Custos | Zero cache em prompts recorrentes | Custo 5x acima do necessário | 1 dia |
| MÉDIA | RAG | Chunks muito grandes perdendo contexto | Precisão de busca <60% | 3 dias |
| BAIXA | Observabilidade | Logs expiram em 3 dias | Debugging lento pós-incidente | 0.5 dia |

### Roadmap Priorizado
- **Semana 1-2:** Quick wins (cache, fallback básico, alertas de custo)
- **Mês 1:** Projetos estruturais (rechunking RAG, tracing completo)
- **Trimestre 1:** Evolução contínua (testes automatizados, otimização de modelo)

## Quanto Custa Não Diagnosticar

| Cenário | Custo do Incidente | Custo do Diagnóstico |
|---------|-------------------|---------------------|
| Outage de 4h em horário comercial | R$ 50k-200k (receita perdida + churn) | R$ 15k-30k (diagnóstico completo) |
| Spike de custo não detectado (1 mês) | R$ 20k-80k (fatura surpresa) | Incluso no diagnóstico |
| Vazamento de dados via prompt | Multa LGPD até R$ 50M + reputação | R$ 15k-30k (avaliação privacidade) |
| Retrabalho por arquitetura errada | 2-4 meses de dev senior | Prevenido no diagnóstico inicial |

**ROI típico:** Diagnóstico paga-se evitando 1 incidente crítico ou 1 mês de custo descontrolado.

## Checklist de Autoavaliação Rápida

Responda sim/não para cada item. Cada "não" é um finding potencial:

- [ ] Temos fallback testado para provedor LLM primário
- [ ] Cache semântico ativo para prompts recorrentes
- [ ] Alertas de custo configurados por projeto/feature
- [ ] Tracing completo de requests LLM em produção
- [ ] Base RAG reindexada automaticamente a cada X dias
- [ ] Testes de qualidade de RAG rodando semanalmente
- [ ] DPA assinado com todos os vendors de IA
- [ ] Prompts anonimizados antes de envio a APIs externas
- [ ] Budget mensal definido e monitorado
- [ ] Plano de disaster recovery documentado e testado

**Score:** 8-10 = saudável. 5-7 = atenção. 0-4 = risco iminente.

## Como a ITC Service Executa Esse Diagnóstico

Diagnóstico completo de arquitetura para sistemas com IA em 4 semanas. Inclui avaliação das 5 camadas, testes práticos, relatório executivo e técnico, roadmap priorizado e sessão de apresentação. Sessão diagnóstica inicial gratuita para avaliar escopo.

**[Agendar diagnóstico de arquitetura →](/contato)**

---

*Tags: arquitetura, diagnóstico, sistemas IA, gargalos, resiliência, custos, RAG*
*CTA: Solicitar diagnóstico técnico*