Arquitetura de software na era da IA: quatro fatores, novas tensões
Os 4 pilares da arquitetura ainda se sustentam na era da IA?
Quem me conhece sabe que não fui um entusiasta precoce da IA generativa. Pelo contrário: acompanhei os primeiros anúncios com desconfiança, vendo mais hype do que substância. O que me fez mudar de postura não foi a avalanche de manchetes ou os vídeos impressionantes, mas sim o momento em que as ferramentas começaram a oferecer respostas mais assertivas — quando deixaram de ser curiosidade de laboratório e passaram a resolver problemas concretos. Foi aí que tive o click: percebi que a IA não era apenas mais uma onda tecnológica, mas uma força capaz de redefinir a forma como pensamos e construímos produtos de software.
E é justamente nesse ponto que volto a Neal Ford e Mark Richards. No clássico Fundamentals of Software Architecture, eles defendem que arquitetura não é apenas diagrama ou estilo arquitetural, mas a combinação de quatro fatores: estrutura do sistema, características da arquitetura, decisões de arquitetura e princípios de design. Esses fatores já eram suficientes para enquadrar os dilemas de um arquiteto. A chegada da IA, no entanto, não os substitui: ela os expande, adicionando tensões inéditas.
A estrutura em mutação: das linhas pretas aos pipelines de IA
Ford e Richards definem estrutura como a organização física e conceitual do sistema — os estilos arquiteturais como camadas, microserviços ou microkernel. Na prática, sempre que desenhamos diagramas de caixas e setas, estamos lidando com estrutura. No início da carreira, eu via essa atividade como o coração da arquitetura: escolher se a aplicação seria monolítica ou distribuída, onde colocar o banco de dados, quais serviços poderiam se comunicar diretamente. A chegada da IA, porém, modificou o tabuleiro.
Modelos de IA exigem pipelines de dados para coleta, limpeza, versionamento e treinamento. Eles também demandam infraestruturas específicas (GPUs, TPUs, clusters distribuídos) e integração com serviços externos. Em outras palavras, são componentes que não se encaixam nas estruturas tradicionais. Arquiteturas modernas precisam comportar pipelines que treinam e fazem fine-tuning de modelos, sistemas de observabilidade para monitorar drift, e mecanismos de inferência servindo modelos em tempo real.
Essa imprevisibilidade tem impactos profundos. Códigos gerados por IA são probabilísticos e desafiam as suposições determinísticas de arquiteturas tradicionais, levando a testes instáveis e divergências de comportamento. Percebi isso quando um microserviço, alimentado por um LLM para normalizar dados bancários, gerou três versões diferentes do mesmo algoritmo durante o desenvolvimento. O problema não era o estilo arquitetural em si, mas a incorporação de uma nova “camada” probabilística dentro da estrutura. A solução que tem emergido é adotar uma camada intermediária de orquestração — um guardrail que direciona chamadas, controla contexto e filtra resultados. De repente, a estrutura não é apenas sobre caixas estáticas; é sobre fluxos de aprendizado, índices vetoriais e sidecars de raciocínio que protegem o restante do sistema.
Características expandidas: além dos “-ilities” clássicos
O segundo fator, as características da arquitetura, abrange atributos como disponibilidade, escalabilidade, desempenho e segurança. Esses “-ilities” funcionam como critérios de sucesso: definem o que precisa ser preservado, mesmo que a funcionalidade mude.
No contexto de IA, os atributos clássicos continuam válidos, mas novos entram em cena:
Explicabilidade e ética: usuários e reguladores querem saber por que um modelo tomou certa decisão.
Confiabilidade de inferência: lidar com alucinações e resultados inconsistentes exige estratégias de fallback, testes de robustez e monitoramento de acurácia.
Privacidade e compliance: dados sensíveis usados em treinamento ou inferência precisam de cuidados adicionais.
Custo operacional: modelos de linguagem de última geração são caros; arquiteturas precisam equilibrar latência e custo de GPUs ou chamadas a APIs.
Esses atributos influenciam a estrutura. Se a privacidade é essencial, talvez seja necessário treinar modelos localmente; se a confiabilidade é crítica, um mecanismo de validação humana (human in the loop) pode ser obrigatório. As novas características também criam trade-offs: priorizar explicabilidade pode reduzir desempenho; garantir privacidade pode limitar a qualidade do modelo. A arquitetura vira um exercício constante de negociação entre requisitos clássicos e emergentes.
Decisões de arquitetura em um mar de incertezas
Ford e Richards definem decisões de arquitetura como regras ou restrições que determinam como o sistema deve ser construído. Elas protegem a integridade da estrutura e das características, impondo limites claros.
A IA amplia e complica esse universo de decisões. Uma das primeiras perguntas tornou-se: treinar ou consumir modelos? Decidir entre um modelo próprio, que exige curadoria de dados e infraestrutura pesada, ou um serviço externo, que oferece menor controle e custos variáveis, é hoje uma decisão arquitetural. Outras questões incluem:
On-device ou cloud? Modelos executados localmente têm menor latência e preservam privacidade, mas podem ser limitados em tamanho.
Modelo geral ou especializado? Usar um LLM poderoso para tarefas genéricas ou um modelo pequeno e afinado para domínios específicos.
Forma de integração: IA como módulo interno, como serviço externo ou como interface principal (chatbots, voz).
Políticas de prompt e governança: definir padrões de engenharia de prompt, selecionar modelos apropriados e estabelecer pipelines de avaliação.
Decisões agora se tornam mais frequentes e efêmeras. Como os modelos evoluem rápido, regras que valem hoje podem se tornar obsoletas em meses. Por isso, muitas organizações adotam o conceito de fitness functions: métricas automatizadas que avaliam continuamente se as decisões ainda entregam os atributos desejados. Em vez de decidir uma única vez e documentar, o arquiteto cria guardrails e mecanismos de revisão constantes.
Princípios de design: da separação de responsabilidades ao responsible AI
O quarto fator, os princípios de design, fornece orientações para os desenvolvedores tomarem boas decisões sem que tudo seja imposto. Esses princípios funcionam como uma bússola: se uma decisão não for explícita, o desenvolvedor sabe qual caminho seguir.
Na era da IA, esses princípios precisam evoluir. Alguns exemplos:
Responsible AI: adotar diretrizes éticas e sociais desde a concepção, evitando vieses e assegurando uso transparente de dados.
Data-centric design: tratar dados como produto central, com pipelines e catálogos governados.
Observabilidade de modelos: monitorar acurácia, deriva (model drift) e fairness.
Simplicidade e modularidade: princípios clássicos como separação de responsabilidades tornam-se ainda mais valiosos para encapsular componentes imprevisíveis.
Esses princípios, assim como os tradicionais SOLID ou DRY, ajudam a manter a coerência quando novas integrações surgem. Em projetos recentes, percebi que instruir equipes a encapsular chamadas de IA em adaptadores e expor apenas contratos estáveis evitava propagação de mudanças. Outro princípio importante é não confiar cegamente em saídas de modelos; sempre que possível, adicionar validação humana ou lógica determinística.
Entre o fascínio e a prudência
Escrever este ensaio foi um exercício de reflexão sobre como os quatro fatores de Ford & Richards continuam fundamentais, mesmo quando somos seduzidos pela magia da IA. A arquitetura de software permanece ancorada na estrutura, nas características, nas decisões e nos princípios, mas cada um desses elementos ganhou novas camadas de significado. A IA não dissolveu os pilares; ela os esticou e, em alguns casos, os tensionou até quase romper.
A estrutura agora inclui fluxos de dados e pipelines de IA. As características expandiram-se com explicabilidade, ética e custo de inferência. As decisões tornaram-se mais voláteis e sujeitas a revisões constantes. Os princípios de design passaram a incorporar a noção de responsible AI e a centralidade de dados.
As bases que Ford & Richards propuseram, no entanto, oferecem uma estrutura mental sólida para navegar nessa nova era. Entender que cada decisão é um trade-off e que cada característica requer concessões torna mais fácil discutir, por exemplo, por que vale a pena sacrificar latência para ganhar mais privacidade.
Arquitetos não serão substituídos por um “ArchitectGPT”, mas por outros arquitetos que souberem usar IA com inteligência e responsabilidade. Para mim, isso significa abraçar a IA como companheira de trabalho, não como rival — e adaptar os quatro fatores da arquitetura a um mundo onde o software já não é apenas feito por humanos, mas em colaboração com máquinas inteligentes.
E você, como a IA tem influenciado as suas decisões arquiteturais? Quero ouvir suas opiniões nos comentários.