Do Monólito ao "AI Mesh": Quebrando Capacidades em Serviços de IA Reutilizáveis

Neste artigo · 10 seções

1. O padrão que aparece em toda empresa com mais de uma feature de IA
2. O que é um "AI Mesh", sem marketing
3. Identificando capacidades: o exercício que vale a pena fazer
4. O contrato de um serviço de IA reutilizável
5. Boundaries: o que vai pra dentro do serviço e o que fica fora
6. O padrão "capability + consumer": composição em vez de features monolíticas
7. Quando NÃO quebrar em serviços
8. Governança: quem cuida do mesh
9. Conclusão
10. Insights & Takeaways

O padrão que aparece em toda empresa com mais de uma feature de IA

A primeira feature de IA vai pra produção. Funciona. Seis meses depois, o time implementa a segunda. Um ano depois, a terceira. E aí você olha o codebase e descobre uma coisa desconfortável: cada feature tem seu próprio prompt pra classificar texto, sua própria integração com provedor de LLM, sua própria lógica de retry, seu próprio parser de saída, suas próprias métricas (quando tem). Três implementações ligeiramente diferentes da mesma coisa, todas operando em produção, todas exigindo manutenção.

É a versão IA de um problema velho. No mundo de microserviços, a gente aprendeu a não duplicar lógica de autenticação em cada serviço; extrai pra um componente compartilhado. Com IA, a maioria dos times ainda não fez essa virada. Cada feature nasce como uma ilha, e o débito técnico se acumula silenciosamente.

Esse artigo é sobre como sair desse padrão. Como identificar capacidades de IA que se repetem, extraí-las como serviços reutilizáveis, e desenhar uma arquitetura onde novas features se beneficiam do que já foi construído em vez de começar do zero.

O que é um "AI Mesh", sem marketing

Tirando o nome bonito, AI Mesh é uma arquitetura onde capacidades de IA são expostas como serviços bem definidos, com contratos claros, versionamento e SLAs internos. Aplicações consomem esses serviços em vez de integrar direto com provedores de LLM.

A ideia não é nova. É a aplicação de princípios de arquitetura de serviços (baixo acoplamento, alta coesão, contratos explícitos) a uma nova classe de componente. O que muda é o tipo de capacidade que está sendo encapsulada: classificar, resumir, extrair, gerar, traduzir, responder a partir de conhecimento. Essas são as unidades de composição, não "chamar a API da OpenAI".

A diferença fica clara num diagrama:

No "antes", três features, três integrações, três formas de fazer a mesma coisa. No "depois", três features consumindo capacidades bem definidas. O AI Gateway (que discutimos no artigo sobre arquitetura de backend) continua existindo como infraestrutura transversal, mas agora tem uma camada de serviços de domínio de IA em cima dele.

Identificando capacidades: o exercício que vale a pena fazer

O primeiro passo é identificar quais capacidades fazem sentido extrair. E aqui tem uma armadilha comum: achar que cada feature é uma capacidade. Não é. A capacidade é a abstração por trás da feature.

Um exemplo concreto. Suponha que sua empresa tem três features de IA:

Feature 1: triagem automática de tickets de suporte. Recebe o texto do ticket e decide a categoria (cobrança, técnico, comercial) e a prioridade (alta, média, baixa).

Feature 2: roteamento de e-mails do SAC. Recebe o e-mail e decide o departamento responsável.

Feature 3: classificação de avaliações de produto. Recebe a avaliação e decide o sentimento (positivo, negativo, neutro) e os temas abordados (preço, qualidade, entrega).

Num olhar descuidado, são três features diferentes. Numa análise de capacidade, são todas variações de um mesmo padrão: classificação de texto em categorias pré-definidas. A capacidade extraível é "classificação", com parâmetros configuráveis (quais categorias, quantos rótulos por input, se exige justificativa).

Fazer esse exercício pras features existentes costuma revelar que 70-80% do que parecia específico é, na verdade, composição de 4-5 capacidades genéricas. As mais comuns que aparecem em quase toda empresa:

Classificação: texto de entrada → categoria de saída. Variações em número de categorias, múltiplos rótulos, confiança exigida.

Extração estruturada: texto livre → dados estruturados (JSON). Nomes, datas, valores, campos específicos. É o coração de features de processamento de documentos.

Resumo: texto longo → texto curto com os pontos principais. Variações em tamanho-alvo, foco (executivo, técnico, simples).

Geração de resposta a partir de contexto: pergunta + documentos → resposta em linguagem natural. É o que alimenta a maioria das features conversacionais.

Transformação de formato: texto num formato → texto em outro. Tradução, mudança de tom, simplificação, formalização.

Comparação e análise: dois ou mais textos → análise de similaridade, diferença, compatibilidade.

Cada uma dessas vira um serviço candidato no mesh.

O contrato de um serviço de IA reutilizável

Um serviço de IA reutilizável não é só um prompt embalado numa API. Ele precisa de um contrato que o torne consumível sem que cada cliente tenha que entender detalhes internos.

O contrato tem quatro dimensões que importam.

Schema de entrada bem definido. Não basta aceitar "texto". Um serviço de classificação precisa receber texto, lista de categorias possíveis, opcionalmente exemplos few-shot, e metadados de contexto. Quanto mais explícito o schema, menos surpresa o consumidor tem.

Schema de saída garantido. Isso é crítico. O consumidor precisa saber que vai receber uma resposta com formato previsível, sempre. Um campo category, um campo confidence, um campo opcional reasoning. Se o modelo retorna algo fora desse formato, o serviço trata internamente (retry, validação, fallback) e só retorna pro cliente quando está correto. O cliente nunca vê a variabilidade natural do LLM.

SLA explícito. Latência p95, disponibilidade, taxa de erro aceitável. Um serviço de classificação pode ter SLA de "200ms p95, 99.5% de disponibilidade". Isso muda como o consumidor integra (síncrono ou não, com timeout, com fallback).

Versionamento. O prompt interno vai evoluir. O modelo subjacente vai mudar. Novas categorias vão ser adicionadas. Sem versionamento explícito, cada mudança vira um risco de quebrar consumidores. Versionamento semântico aplicado: mudança no schema de saída é breaking change, mudança só no prompt que melhora acurácia sem mudar contrato é patch.

Um exemplo concreto de contrato pra um serviço de extração:

{
  "service": "document-extraction",
  "version": "2.3.0",
  "input": {
    "document_text": "string, obrigatório",
    "fields_to_extract": "array de objetos com name, type, description",
    "language": "string, default 'pt-BR'"
  },
  "output": {
    "extractions": "array de objetos com field_name, value, confidence, source_span",
    "overall_confidence": "número entre 0 e 1",
    "extraction_id": "uuid para rastreamento"
  },
  "sla": {
    "latency_p95_ms": 1200,
    "availability": "99.5%"
  }
}

Repara em detalhes importantes: o campo source_span no retorno permite ao consumidor rastrear de onde cada extração veio no texto original (útil pra validação e auditoria); o extraction_id amarra essa chamada ao log interno do serviço (rastreabilidade); a presença de confidence permite ao consumidor decidir se usa ou rejeita a resposta.

Boundaries: o que vai pra dentro do serviço e o que fica fora

A decisão mais sensível no design é onde traçar a fronteira. O que o serviço assume como responsabilidade e o que delega ao consumidor?

Algumas decisões que tendem a funcionar bem:

Validação do formato de saída vai pra dentro. O serviço garante que o output está no schema prometido. Se o modelo gerou algo fora do formato, o serviço faz retry, usa um parser mais tolerante, ou aciona fallback. O consumidor não lida com JSON mal formatado.

Retry e circuit breaker vão pra dentro. Falhas transitórias do provedor são problema do serviço, não do consumidor. Isso simplifica massivamente o código de quem consome.

Escolha de modelo vai pra dentro. O serviço de classificação decide se usa GPT-4, Claude Haiku ou um modelo local por trás. O consumidor não sabe e não precisa saber. Isso permite trocar provedor sem quebrar ninguém.

Conhecimento de domínio do consumidor fica fora. Se a classificação exige conhecer as categorias específicas de um produto, o consumidor passa essas categorias como parâmetro. O serviço não deveria ter lógica hardcoded pra domínios específicos.

Autenticação do usuário final fica fora. O serviço autentica o consumidor (outro serviço interno), mas não lida com "esse usuário pode fazer essa chamada?" Isso é responsabilidade do consumidor.

Decisões de negócio ficam fora. Se a classificação retorna "prioridade alta", o que fazer com isso é do consumidor. O serviço classifica; não decide o workflow.

Uma fronteira saudável deixa o serviço reutilizável em contextos que ninguém previu quando ele foi criado. Se a regra "prioridade alta dispara escalation pro gestor" está dentro do serviço de classificação, o próximo consumidor que não quer esse comportamento vai precisar fork ou reescrever.

O padrão "capability + consumer": composição em vez de features monolíticas

Com os serviços no lugar, o desenvolvimento de novas features muda de natureza. Em vez de "vamos implementar do zero", vira "vamos compor capacidades existentes".

Um exemplo. O time de produto pede uma feature: "quando o cliente envia um e-mail de reclamação, extrair os pontos principais, classificar a gravidade, e sugerir uma resposta inicial".

Sem AI Mesh, isso vira um projeto: prompts, integrações, validações, testes, deploy. Semanas de trabalho.

Com AI Mesh, é composição:

Cada caixinha é um serviço existente. O trabalho do time fica em compor, configurar e adicionar lógica de negócio específica (qual template usar, quem notificar, quando escalar). Dias de trabalho, não semanas.

Esse é o ganho real do AI Mesh: ele inverte a economia da implementação. A primeira feature é cara porque cria as capacidades. A décima feature é barata porque só compõe. Se você nunca chega na décima, o mesh não compensa. Se a empresa vai ter dezenas de features de IA, compensa.

Quando NÃO quebrar em serviços

Nem toda empresa precisa de AI Mesh. Alguns sinais que indicam que é cedo demais:

Menos de três features de IA em produção. Extrair capacidades com uma ou duas features é chute. Você ainda não viu variações suficientes pra saber o que é realmente reutilizável. Começar pelo mesh pode levar a abstrações erradas que depois precisam ser reescritas.

Features muito diferentes entre si. Se as features não compartilham padrões (uma é chatbot, outra é geração de imagem, outra é análise de áudio), talvez não exista capacidade comum de fato. Forçar a abstração cria acoplamento artificial.

Time pequeno e ritmo acelerado de experimentação. Serviços reutilizáveis têm custo de manutenção, coordenação, versionamento. Em estágio de validação, a velocidade de experimentar individualmente vence a eficiência de reusar.

Ausência de plataforma interna madura. AI Mesh pressupõe que você já tem observabilidade, deploy, versionamento de serviços funcionando bem. Se isso ainda está sendo construído, adicionar a camada de IA complica demais.

A regra é: extraia capacidade quando ela já foi reimplementada duas ou três vezes. Antes disso, é especulação.

Governança: quem cuida do mesh

Uma pergunta prática que aparece rápido: quem é dono desses serviços compartilhados?

Três modelos funcionam em empresas diferentes.

Time de plataforma de IA dedicado. Um time cuja responsabilidade é construir e manter as capacidades do mesh. Os times de produto consomem. Funciona em empresas maiores onde o volume de uso justifica o investimento.

Modelo federado com ownership distribuído. Cada capacidade tem um time owner que é tipicamente o primeiro que construiu. Outros times contribuem via pull requests. Funciona em empresas com cultura de open source interno, mas exige disciplina pra não virar bagunça.

Comitê de arquitetura com implementação distribuída. Decisões de design (contratos, SLAs, versionamento) passam por um comitê pequeno. Implementação fica com os times. Funciona quando você precisa de consistência sem ter time dedicado.

Independente do modelo, algumas coisas são inegociáveis: cada capacidade precisa de um owner identificável, um SLA público, um canal pra reportar problemas, e um processo claro pra evolução. Sem isso, o mesh vira um conjunto de serviços órfãos que ninguém mantém, e voltamos ao ponto de partida.

Conclusão

AI Mesh não é uma tecnologia; é uma decisão de arquitetura. É aplicar princípios de serviços bem definidos ao domínio de IA, com o reconhecimento de que capacidades de IA são abstrações úteis que transcendem features específicas.

O valor aparece em escala, não no começo. Se você está construindo sua primeira feature, não precisa de mesh. Se está construindo a quinta e percebe que está reimplementando classificação de texto pela quarta vez, é hora de parar e extrair. A disciplina que separa código bem arquitetado de código que vai virar dívida técnica é a mesma de sempre: identificar abstrações repetidas e promovê-las a componentes de primeira classe.

O que me chama atenção é como muitas empresas que já fizeram isso com sucesso pra microserviços tradicionais travam na hora de fazer com IA. Talvez seja porque IA ainda parece "nova", "diferente", algo que não se encaixa nos padrões conhecidos. Mas os padrões se aplicam. São só componentes novos dentro de uma arquitetura que a gente já sabe construir.

Insights & Takeaways

1. A maioria das features de IA numa empresa são composições de 4-5 capacidades genéricas: classificação, extração, resumo, geração a partir de contexto, transformação, comparação. Identificar essas capacidades é o primeiro passo pro mesh.

2. Um serviço de IA reutilizável não é um prompt embalado numa API. Precisa de schema de saída garantido, SLA explícito e versionamento. O consumidor nunca deveria ver a variabilidade natural do LLM.

3. Validação, retry, circuit breaker e escolha de modelo vão pra dentro do serviço. Conhecimento de domínio específico do consumidor e decisões de negócio ficam fora. Essa fronteira define reusabilidade de verdade.

4. AI Mesh inverte a economia: a primeira feature é cara porque cria capacidades; a décima é barata porque só compõe. Se você não vai chegar na décima, não compensa o investimento.

5. Não extraia capacidades com menos de três features em produção. Antes disso, é especulação. A regra é: reimplementou duas ou três vezes, vira serviço.