O SIA Não É um Chatbot com Arquitetura: É uma Plataforma com Inteligência
Quando alguém me pergunta qual é a diferença entre um produto que "usa IA" e um produto que "é inteligente", eu respondo com arquitetura.
Qualquer sistema consegue chamar um endpoint do OpenAI. O que separa um protótipo de uma plataforma em produção é o que fica entre a mensagem do usuário e a resposta gerada. É aí que a arquitetura mostra seu valor, ou sua ausência.
O SIA foi desenhado para ser uma plataforma de atendimento inteligente com capacidade agentic real. Não um wrapper de LLM com interface de chat. Isso exigiu uma série de decisões de arquitetura que vou detalhar aqui, explicando o raciocínio por trás de cada uma.
Por que monólito modular, não microservices desde o início
A primeira decisão que precisei tomar foi sobre a estrutura geral do sistema. E a resposta foi monólito modular com núcleo hexagonal.
Essa escolha vai contra o instinto de quem foi exposto a muita conversa sobre microservices. A narrativa padrão diz que sistemas modernos deveriam nascer distribuídos, com cada capacidade em seu próprio serviço. Na prática, essa abordagem tem um custo de complexidade operacional que projetos em fase inicial raramente conseguem absorver sem prejuízo para a velocidade de desenvolvimento e para a qualidade do produto.
Microservices resolvem problemas de escala e de times. No início do SIA, o problema é de produto: entender os limites de domínio corretamente antes de distribuí-los. Quando você distribui um modelo de domínio mal compreendido, distribui também os erros. E erros distribuídos são muito mais difíceis de corrigir do que erros contidos em um monólito.
O monólito modular do SIA mantém os módulos com fronteiras claras internamente: conversas, conhecimento, workflows, decisões e auditoria. Cada módulo tem sua própria lógica, seus próprios casos de uso, suas próprias regras. Mas todos compartilham o mesmo processo de implantação. Isso simplifica o deploy, facilita o refactor de fronteiras quando o entendimento do domínio amadurece, e ainda permite extrair microservices no futuro quando houver necessidade técnica real, não antecipada.
A decisão de extrair um serviço deve ser guiada por pressão de escala ou por autonomia de time, não por arquitetura pré-emptiva.
O núcleo hexagonal como proteção do domínio
Dentro do monólito, o núcleo do SIA segue arquitetura hexagonal. Isso não é uma escolha estética. É o mecanismo que impede que o domínio de negócio vaze para os detalhes de infraestrutura.
O Domain Layer do SIA concentra regras de atendimento, fluxo de conversa, guardrails, políticas e validações. Essas regras representam o conhecimento de negócio do produto. Elas definem como o SIA deve se comportar, o que é permitido, o que precisa de aprovação humana, o que deve ser escalado.
Esse núcleo não sabe nada sobre banco de dados. Não sabe qual LLM está em produção. Não conhece o schema do Redis ou o endpoint do Qdrant. Ele conhece contratos, expressados como ports, e espera que implementações concretas sejam fornecidas de fora.
Acima do núcleo fica a Application Layer, responsável pelos casos de uso do SIA. É ela que orquestra o fluxo de uma requisição: recebe a entrada, chama o domínio com os dados corretos, solicita capacidades externas via ports e retorna o resultado. A Application Layer sabe que existem ports. Não sabe o que está do outro lado deles.
Na borda do sistema, os Adapters implementam esses ports com tecnologia concreta. O adapter de banco de dados escreve no Postgres. O adapter de cache fala com o Redis. O adapter de fila publica no RabbitMQ ou SQS. O adapter de IA chama o LLM Gateway. Cada adapter é uma fronteira entre o domínio e o mundo externo.
Essa separação tem consequências práticas diretas. Consigo testar o núcleo do SIA completamente sem banco de dados, sem Redis, sem LLM. Os testes de domínio são rápidos, determinísticos e não dependem de infraestrutura rodando. Quando uma regra de negócio precisa mudar, o impacto fica contido no núcleo. Quando a tecnologia precisa mudar, o impacto fica contido nos adapters.
O BFF/API Gateway como primeira linha de controle
O SIA opera com múltiplos canais de entrada: Web, WhatsApp, API externa e painel administrativo. Cada canal tem características diferentes de protocolo, formato de payload, requisitos de autenticação e padrões de uso.
Colocar toda essa diversidade diretamente na Application Layer criaria um código de entrada cheio de condicionais e transformações específicas de canal. O BFF/API Gateway resolve isso.
Na borda do sistema, o BFF centraliza autenticação, controle de sessão e rate limiting antes que qualquer requisição chegue ao núcleo. Uma mensagem do WhatsApp, uma chamada de API externa e uma ação do painel administrativo passam pela mesma camada de controle antes de se tornarem eventos de domínio normalizados.
O rate limiting nessa posição não é só uma questão de performance. Em um sistema com IA, é também uma questão de custo. Chamadas de LLM têm preço por token. Sem controle de taxa na entrada, um cliente mal configurado ou um ataque de automação pode gerar custos inesperados antes que qualquer alerta seja disparado.
A autenticação centralizada no gateway significa que o domínio nunca precisa lidar com tokens JWT, sessões OAuth ou chaves de API. Quando uma requisição chega ao núcleo, ela já carrega um contexto de identidade resolvido. O domínio opera sobre identidades, não sobre credenciais.
A camada de IA como conjunto de capabilities externas
Essa é a parte da arquitetura onde as decisões de design têm maior impacto sobre a longevidade do produto.
A camada de IA do SIA é estruturada em dois níveis: Ports de IA e Adapters de IA. Os ports são os contratos que o núcleo e a application layer conhecem. Os adapters são as implementações concretas que ninguém dentro do hexágono conhece.
O AIOrchestratorPort é o ponto de entrada para fluxos agentic complexos. Quando o domínio precisa acionar um processo de raciocínio multi-etapa, ele chama esse port sem saber se do outro lado existe um agente LangGraph, um sistema CrewAI, um fluxo custom ou uma implementação híbrida. A decisão sobre o orquestrador de agentes é um detalhe de infraestrutura de IA, não uma regra de negócio.
O LLMPort abstrai o acesso a modelos de linguagem. O adapter concreto pode apontar para o LLM Gateway que roteia entre OpenAI, Claude, ou outros provedores conforme disponibilidade e custo. Trocar de provedor de LLM, migrar para um modelo mais econômico para determinadas tarefas, ou rodar um modelo local para dados sensíveis são decisões que acontecem no adapter, nunca no domínio.
O EmbeddingPort e o VectorSearchPort abstraem a pipeline de RAG. O adapter de busca vetorial pode apontar para Qdrant, Pinecone ou qualquer outra solução. O núcleo sabe que pode solicitar contexto relevante dado um input. Não sabe como esse contexto é indexado, em qual banco vetorial, com qual modelo de embedding.
O GuardrailPort merece atenção especial. Guardrails em produção não são apenas filtros de conteúdo. Eles implementam as políticas do produto sobre o que o SIA pode e não pode dizer, quais tópicos devem ser escalados para humanos, quais respostas precisam de revisão antes de serem entregues. Essa é uma regra de negócio crítica. O GuardrailPort garante que essa regra seja aplicada de forma consistente independentemente de qual modelo gerou a resposta.
O EvaluationPort é o que transforma o SIA de um sistema que gera respostas em um sistema que aprende sobre a qualidade do que gera. Ele conecta o fluxo de produção a pipelines de avaliação automática que medem relevância, coerência, aderência às políticas e qualidade percebida. Sem avaliação sistemática, não há como saber se o sistema está melhorando ou degradando ao longo do tempo.
O fluxo agentic em produção
O fluxo completo de uma mensagem no SIA passa por sete etapas que deixam clara a separação entre domínio e inteligência.
A mensagem chega pelo canal e passa pelo BFF, onde autenticação e rate limiting são aplicados. A Application Layer recebe o evento normalizado e entra no módulo de conversas. O primeiro port de IA acionado é o de classificação de intenção: o que o usuário está tentando fazer? Com a intenção classificada, o sistema busca contexto no RAG via VectorSearchPort, recuperando informações relevantes da base de conhecimento configurada para aquele cliente ou domínio de atendimento.
Com contexto e intenção disponíveis, o AIOrchestratorPort é acionado quando o fluxo exige raciocínio mais elaborado. O orquestrador pode acionar ferramentas externas via AgentPort, como consultas a sistemas legados, verificações em bases externas ou execução de ações concretas. A resposta gerada passa pelo GuardrailPort antes de qualquer outra coisa. Se o guardrail rejeita, o fluxo de fallback é acionado. Se aprova, a resposta é entregue.
Toda a operação é registrada via ObservabilityPort: timestamp de cada etapa, latência por componente, modelo e versão usados, documentos recuperados pelo RAG com seus scores de similaridade, resultado do guardrail, tokens consumidos e custo estimado. Esses dados não são logs de debug. São o insumo principal para a evolução do sistema.
Quando esse desenho faz sentido
Esse nível de arquitetura não se justifica para qualquer projeto. Ele faz sentido quando algumas condições estão presentes simultaneamente.
Primeiro, quando existem regras de negócio fortes que precisam ser protegidas de mudanças tecnológicas. Um sistema de atendimento com políticas de compliance, regras de escalamento e guardrails operacionais precisa dessa proteção.
Segundo, quando o produto opera em múltiplos canais com características diferentes. A camada de BFF e os adapters de entrada absorvem essa diversidade sem contaminar o núcleo.
Terceiro, quando a IA apoia decisão e execução, não apenas gera texto. Um sistema que só precisa de respostas estáticas não precisa de AIOrchestratorPort nem de EvaluationPort. Mas quando agentes precisam acionar ferramentas, verificar condições e tomar sequências de ação, a abstração do orquestrador se torna necessária.
Quarto, quando rastreabilidade e auditoria são requisitos, não opcionais. Em produtos de atendimento com volume real, saber exatamente o que o sistema fez, por qual razão e com qual resultado não é um diferencial. É uma necessidade operacional básica.
O que muda quando você resolve evoluir
O argumento mais forte para essa arquitetura não é o que ela permite fazer hoje. É o que ela permite mudar amanhã sem pagar um custo proibitivo.
Quando um novo modelo de linguagem fica disponível com melhor custo-benefício para classificação de intenção, o LLMPort já tem o contrato definido. Criar um novo adapter que aponta para o novo modelo leva horas, não semanas. O domínio não é tocado.
Quando o volume de conversas cresce ao ponto onde o módulo de workflows justifica extração como microservice, as fronteiras do módulo já estão definidas internamente no monólito. A extração é uma decisão de deployment, não uma refatoração de arquitetura.
Quando um cliente exige que dados sensíveis não trafeguem para provedores externos, o VectorSearchPort e o LLMPort permitem apontar para instâncias privadas sem alterar uma linha do domínio.
Cada uma dessas mudanças, em um sistema acoplado, exigiria cirurgia no núcleo do produto. Na arquitetura do SIA, cada uma é uma decisão de adapter.
O princípio que não muda
Tecnologia de IA vai continuar evoluindo em ritmo que nenhum roadmap consegue acompanhar de forma precisa. Modelos melhores vão aparecer. Frameworks de agentes vão mudar. Bancos vetoriais vão evoluir. Provedores vão entrar e sair do mercado.
O que não pode mudar na mesma velocidade são as regras que definem como o SIA atende, o que pode ser dito, o que precisa de revisão humana, como conversas são gerenciadas e como decisões são auditadas. Esse conhecimento de negócio precisa de estabilidade.
A arquitetura do SIA foi desenhada para garantir exatamente isso: que o núcleo do produto seja imune a mudanças de infraestrutura de IA, enquanto a camada de IA seja livre para evoluir sem comprometer a estabilidade operacional do sistema.
Monólito modular com núcleo hexagonal e camada de IA separada não é a arquitetura mais simples de explicar em um slide. Mas é a que entrega um produto que consegue operar em produção, evoluir sem risco e ser mantido por um time que não precisa entender todo o sistema para trabalhar em qualquer parte dele.
Isso é o que separa um produto de IA de um protótipo de IA.
Alexsander Valente é engenheiro e arquiteto de software com 15 anos de experiência em sistemas de produção. É fundador da Threeger, criador do SIA, e professor de desenvolvimento de agentes conversacionais no MBA do Ibmec.
