Uma boa proposta de arquitetura de IA não é a que contém mais caixas, modelos ou produtos. É a que explica, com evidências, por que cada decisão atende ao resultado, quais premissas ainda precisam ser testadas, como o sistema falha e se recupera, quanto custa operar e como componentes podem ser substituídos. Antes de contratar, compare registros de decisão e artefatos executáveis — não a beleza do diagrama.
A arquitetura deve permanecer proporcional à decisão. Para um assistente interno com revisão humana, uma integração simples e um serviço gerenciado podem ser suficientes. Para um agente que executa ações, dados sensíveis ou alto volume, controles, avaliação, observabilidade e caminhos de desativação precisam ser mais fortes. Complexidade sem risco ou valor correspondente é passivo, não sofisticação.
AI Architecture Decision Proof-8: matriz de 32 pontos
Pontue cada dimensão de zero a quatro: zero é ausente; um é afirmação; dois é desenho parcial; três é decisão justificada com evidência e owner; quatro é decisão reproduzida em ambiente representativo, com alternativa e gatilho de revisão. Como corte ilustrativo, avance com 24 de 32, nenhum zero e nota mínima três em dados, segurança, avaliação e operação.
- Resultado e fronteiras — usuário, tarefa, autonomia, não objetivos, baseline, erro tolerável e alternativa sem IA estão explícitos.
- Dados e contexto — fontes, direitos, qualidade, recuperação, memória, atualização, retenção e proveniência sustentam o uso real.
- Modelos e ferramentas — critérios para serviço gerenciado, RAG, ferramentas, fine-tuning ou código próprio são comparados por evidência.
- Integrações e interfaces — sistemas de registro, APIs, eventos, identidade, limites, idempotência e tratamento de falhas estão definidos.
- Segurança e cadeia — ambientes, segredos, acessos, componentes, subcontratados, versões, vulnerabilidades e incidentes são controláveis.
- Avaliação e supervisão — conjuntos, métricas, casos adversos, revisão humana, aprovação, regressão e critérios de parada são executáveis.
- Confiabilidade e operação — observabilidade, SLOs, fallback, rollback, mudança de modelo, continuidade, suporte e retirada têm owners.
- Economia e saída — custo por resultado, capacidade, concentração, portabilidade, formatos, documentação e transição são demonstráveis.
Cinco filtros eliminatórios antes do score
- A arquitetura depende de dados, acesso ou integração que ninguém verificou.
- Uma ação irreversível ou de alto impacto não tem autorização, limite e intervenção humana proporcionais.
- Não existe conjunto de avaliação representativo nem critério de aceite reproduzível.
- Um componente crítico de terceiro não tem owner, monitoramento, contingência ou direito de substituição.
- O fornecedor não consegue exportar código, configuração, dados, prompts, avaliações, logs e documentação necessários à transição.
Um filtro reprovado não exige descartar o caso. Ele muda o objeto da compra: discovery técnico limitado, spike de integração, avaliação independente ou piloto controlado. Não assine uma implementação completa para financiar a descoberta tardia de uma premissa arquitetural crítica.
Compare quatro padrões sem escolher tecnologia por moda
- Serviço gerenciado e configuração — acelera entrega e reduz operação própria; exige entender limites, dados, preço, disponibilidade e saída.
- RAG e integração empresarial — melhora grounding em conteúdo autorizado; qualidade depende de ingestão, recuperação, permissões, avaliação e atualização.
- Agentes e orquestração — permitem executar fluxos e ferramentas; ampliam superfície de ação, exceções, identidade, observabilidade e controle.
- Componentes customizados ou fine-tuning — podem atender desempenho, domínio ou escala específicos; pedem dados, avaliação, MLOps, capacidade e custo sustentáveis.
Exija sete artefatos comparáveis
- Diagrama de contexto com usuários, sistemas, dados, terceiros e fronteiras de confiança.
- Registros das decisões críticas, alternativas rejeitadas, evidência, owner e gatilho de revisão.
- Modelo de ameaças e cadeia de componentes, incluindo versões, acessos e contingências.
- Plano de avaliação ligado a requisitos, risco, condições reais e critérios de aceite.
- Modelo operacional com telemetria, SLOs, incidentes, mudanças, fallback, rollback e retirada.
- Modelo de custo e capacidade por cenário, com volume, latência, revisão humana e margem de incerteza.
- Pacote de portabilidade e transição com formatos, repositórios, documentação, dependências e teste de substituição.
Faça uma defesa adversarial de 90 minutos
Dê o mesmo brief aos finalistas. Peça que defendam três decisões e uma alternativa. Depois injete perda do modelo principal, degradação da recuperação, mudança no esquema de uma API, pico de volume e exigência de apagar dados. Exija diagnóstico, isolamento, fallback, impacto em custo e prazo e registro da decisão. Avalie clareza de premissas, capacidade de mudar componentes e comportamento diante de incerteza — não velocidade para desenhar novas caixas.
Red flags comerciais e técnicas
- Uma tecnologia aparece antes do problema e dos requisitos.
- Toda decisão é chamada de padrão ou best practice sem comparação.
- Custos de integração, avaliação, observabilidade, revisão humana e suporte ficam fora do preço.
- O diagrama ignora identidade, ambientes, dados sensíveis, terceiros ou operação.
- A solução depende de um modelo específico, mas não há teste de substituição.
- O fornecedor promete escala sem modelo de carga, gargalo e custo por resultado.
- O cliente só recebe documentação no encerramento.
Contexto brasileiro
No Brasil, peça que a proposta mapeie finalidade, necessidade, agentes de tratamento, suboperadores, transferências internacionais, retenção e resposta a incidentes conforme o caso. Inclua requisitos setoriais, contratuais e de soberania tecnológica relevantes, sem confundir processamento local com segurança. Defina também como variação cambial, tributos, consumo de nuvem e modelos, suporte e revisão humana entram no custo total. Jurídico, privacidade, segurança e arquitetura devem revisar a mesma versão do desenho.
Leve a arquitetura para o RFP e o contrato
Forneça a todos o mesmo cenário, restrições e volumes. Exija premissas separadas de fatos, opções arquiteturais, dependências do cliente, critérios de aceite e preço por cenário. Vincule marcos a artefatos reproduzíveis, reserve direito de revisar decisões quando contexto ou modelo mudar e defina propriedade, licenças, repositórios, exportação, assistência de transição e limites de subcontratação.
Conecte a decisão às demais diligências
Use https://makinai.co/insights/pt/comprar-configurar-ou-desenvolver-solucao-ia para definir a fronteira tecnológica, https://makinai.co/insights/pt/avaliar-prontidao-dados-antes-contratar-empresa-ia para testar entradas, https://makinai.co/insights/pt/due-diligence-seguranca-contratar-empresa-ia para aprofundar controles e https://makinai.co/insights/pt/como-evitar-lock-in-contratar-parceiro-ia para validar portabilidade e saída.
Quando envolver a MAKINAI
A MAKINAI pode transformar propostas arquiteturais em decisões comparáveis, conduzir a defesa adversarial e converter premissas em discovery, gates, critérios de aceite e plano de transição. Conheça https://makinai.co/services/pt/consultoria-estrategia-ia-transformacao.