A arquitetura de referência de IA corporativa sobre Bedrock

O erro não é técnico, é organizacional: tratar IA como feature de produto em vez de capacidade de plataforma. Cada squad integra direto no bedrock-runtime com sua própria IAM role e seu próprio jeito. Funciona no primeiro trimestre. Os sintomas aparecem no segundo:

• Ninguém sabe o custo por time. O Cost Explorer mostra uma linha só: "Amazon Bedrock". Chargeback vira rateio político.
• Cada squad escolheu um modelo diferente por gosto, não por medida. Dois deles usam o modelo mais caro do catálogo para classificar texto de 40 tokens.
• Guardrails existem em um app e não existem nos outros seis. A primeira resposta ruim que vaza define a política da empresa inteira — na base do susto.
• Prompt vive hardcoded em sete repositórios. Trocar uma frase de compliance é um projeto de duas semanas com sete deploys.
• Cada RAG subiu seu próprio índice sobre a mesma base de conhecimento. Você paga três vezes pelo mesmo documento e as três respostas divergem.
• Quando o comitê de risco pergunta "onde estão os logs de tudo que o modelo respondeu?", a resposta honesta é: depende do app.

A arquitetura corporativa de IA sobre Bedrock se decompõe em sete camadas. Elas não são opcionais — toda empresa acaba tendo as sete. A escolha real é se elas vão ser projetadas ou acidentais. Leia de cima (perto do usuário) para baixo (perto da operação):

Repare no que não está na coluna de canais: nenhum canal fala com o bedrock-runtime diretamente. Essa é a regra estrutural da arquitetura inteira — tudo passa pelo gateway. É o que torna possível trocar de modelo, medir custo por time e aplicar guardrail sem tocar em sete repositórios.

O AI Gateway é um serviço interno fino — normalmente uma Lambda ou um container atrás de API Gateway — por onde passa toda chamada de IA da empresa. Ele não faz inteligência nenhuma: ele resolve identidade, aplica política e atribui custo. Cinco responsabilidades e nada além disso, senão vira monolito.

import os, time, json, boto3

br = boto3.client("bedrock-runtime")
cw = boto3.client("cloudwatch")

# Política central: cada app declara o que pode usar.
# Na prática isto vive no DynamoDB/AppConfig, não no código.
POLICY = {
    "credito-copiloto": {
        "profile_arn": os.environ["PROFILE_CREDITO"],  # application inference profile
        "tier": "raciocinio",
        "guardrail": {"id": os.environ["GR_PII"], "version": "3"},
        "max_output": 1200,
    },
    "atendimento-triagem": {
        "profile_arn": os.environ["PROFILE_ATENDIMENTO"],
        "tier": "volume",
        "guardrail": {"id": os.environ["GR_ATENDIMENTO"], "version": "7"},
        "max_output": 300,
    },
}


def handler(event, _ctx):
    app = event["requestContext"]["authorizer"]["app_id"]   # 1-2. identidade e tenant
    pol = POLICY.get(app)
    if pol is None:
        return {"statusCode": 403, "body": "app sem politica de IA"}

    if quota_estourada(app):                                 # 3. quota
        return {"statusCode": 429, "body": "quota de IA do periodo esgotada"}

    body = json.loads(event["body"])
    started = time.monotonic()

    resp = br.converse(                                      # 4-5. chamada padronizada
        modelId=pol["profile_arn"],                          # o profile carrega a tag de custo
        system=[
            {"text": prompt_versionado(app)},
            {"cachePoint": {"type": "default"}},             # prefixo estavel = cache barato
        ],
        messages=body["messages"],
        inferenceConfig={"maxTokens": pol["max_output"]},
        guardrailConfig={
            "guardrailIdentifier": pol["guardrail"]["id"],
            "guardrailVersion": pol["guardrail"]["version"],
        },
    )

    u = resp["usage"]                                        # 6. observabilidade
    cw.put_metric_data(
        Namespace="Plataforma/IA",
        MetricData=[{
            "MetricName": "TokensSaida",
            "Value": u["outputTokens"],
            "Unit": "Count",
            "Dimensions": [{"Name": "app", "Value": app}],
        }],
    )
    audit(app, u, latencia_ms=int((time.monotonic() - started) * 1000))

    return {"statusCode": 200, "body": json.dumps(resp["output"])}

Escolher o orquestrador errado é o erro de arquitetura mais caro depois do vector store ocioso. O critério não é "o que é mais moderno" — é duração do fluxo e quanto do caminho precisa ser determinístico.

A plataforma não expõe "o catálogo do Bedrock" para os squads. Ela expõe tiers: três a quatro perfis nomeados por tipo de tarefa, cada um apontando para um modelo concreto que o time de plataforma pode trocar sem que ninguém mude código. É a mesma ideia de instance family no EC2 — o squad pede a classe, não o SKU.

A camada de conhecimento é onde o desperdício se esconde. Três squads que respondem perguntas sobre a mesma base de produtos não precisam de três Knowledge Bases — precisam de uma por domínio de conhecimento, com filtro de metadados na consulta. O critério de fronteira não é o app: é quem é dono do dado e quem pode ler.

A camada de confiança não se justifica sozinha para o time de engenharia — ela se justifica quando alguém de fora pergunta. Comitê de risco, auditoria interna, DPO, ou o questionário de segurança do seu maior cliente. Cada pergunta tem um artefato que a responde; se o artefato não existe, a resposta é uma opinião.

A primeira onda de IA em uma empresa é aprovada por entusiasmo. A segunda é aprovada por número. Estas são as métricas que você precisa estar coletando desde o primeiro app — instrumentar depois significa não ter histórico quando o orçamento for discutido.

Não construa as sete camadas antes do primeiro caso de uso — isso é plataforma sem cliente, e morre na revisão de orçamento. Construa a espinha mínima junto com o primeiro caso real, e engrosse conforme o segundo e o terceiro chegam.

• Plataforma sem cliente: seis meses construindo o gateway perfeito antes do primeiro caso de uso. Ninguém aprova a segunda fase.
• Gateway que virou monolito: começou resolvendo identidade e acabou com lógica de negócio de quatro squads dentro. Agora é single point of failure e ninguém quer mexer.
• Um vector store por app: três índices sobre a mesma base, três faturas de OCU e três respostas diferentes para a mesma pergunta.
• Modelo escolhido por gosto: o squad usou o modelo mais caro do catálogo para classificar texto curto porque "é o melhor". Sem eval, ninguém consegue argumentar o contrário.
• Permissão via prompt: pedir ao modelo que ignore documentos confidenciais em vez de filtrar no retrieval. Falha no primeiro teste de intrusão sério.
• Logging ligado depois do incidente: a auditoria pergunta sobre uma resposta de março e o log começa em maio.
• Prompt sem versão: alguém melhora uma frase em produção na sexta, a qualidade cai, e não existe diff para reverter.
• Nenhum baseline: o projeto entrega, todo mundo sente que melhorou, e não há um número anterior para comparar. O ROI vira narrativa.