Capítulo 16 — Arquitetura de Inteligência Artificial

16.1 Objetivo do Capítulo

Este capítulo apresenta a Arquitetura de Inteligência Artificial da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como capacidades de IA são disponibilizadas de forma governada, segura e isolada por tenant.

A IA é implementada como plataforma corporativa — não como integração pontual de cada aplicação com um modelo. Os serviços de negócio consomem capacidades por contratos; a plataforma resolve provedores, modelos, bases de conhecimento, políticas e guardrails de forma transparente.

Este capítulo cobre: AI Platform, AI Gateway, capacidades de IA, RAG, bases de conhecimento, modelos, prompts, guardrails, automação inteligente, tool calling, agentes, metering, avaliação e governança.

16.2 Princípios da Arquitetura de IA

1. Desacoplamento de provedores — aplicações de negócio nunca dependem diretamente de SDKs ou APIs de provedores de modelo;
2. Isolamento multi-tenant obrigatório — bases de conhecimento, vetores, configurações, quotas e métricas são segregados por tenant;
3. IA como apoio à decisão humana — ações transacionais irreversíveis não são executadas pelo modelo sem confirmação e autorização no backend;
4. RAG antes de conhecimento implícito — respostas institucionais são fundamentadas em conteúdo controlado, não em memória do modelo;
5. Autorização fora do LLM — o modelo nunca decide o que um usuário pode fazer; a autorização pertence ao IAM e aos serviços de domínio;
6. Rastreabilidade — toda execução de IA é rastreável: tenant, capacidade, versão do prompt, modelo, base utilizada, tokens consumidos e resultado;
7. Governança de mudanças — alterações em modelos, prompts, bases de conhecimento e ferramentas passam por avaliação antes de produção;
8. Resiliência — falha de IA não bloqueia o núcleo transacional da plataforma; degradação controlada define o comportamento alternativo;
9. Minimização de dados — dados pessoais são minimizados antes de enviados a modelos; redaction é aplicado conforme classificação;
10. Kill switch — capacidades, provedores, modelos e ferramentas podem ser suspensos sem alteração de código.

16.3 Visão Geral da AI Platform

React / React Native / Serviços de Negócio
                │
            AI Gateway
                │
    ┌───────────┼───────────┐
    │           │           │
  Chat       Search    Processing
    │           │           │
    └───────────┼───────────┘
                │
       AI Capability Layer
                │
    ┌───────────┼───────────┐
    │           │           │
   RAG    Classification Summarization
    │           │           │
    └───────────┼───────────┘
                │
      Model Abstraction Layer
                │
       ┌────────┴────────┐
       │                 │
  Modelos Locais    Modelos em Nuvem

A camada de IA oculta das aplicações consumidoras os detalhes específicos de cada provedor.

16.4 AI Gateway

O AI Gateway é a porta de entrada governada para todas as capacidades de IA. Nenhum serviço de domínio chama diretamente um provedor de modelo.

Responsabilidades:

• autenticação e autorização do consumidor;
• resolução e validação do Tenant Context;
• identificação da capacidade solicitada;
• aplicação de políticas do tenant e da plataforma;
• rate limiting e quotas por tenant, capacidade e modelo;
• correlação e propagação de AI Request ID;
• metering de consumo;
• roteamento para o serviço de IA correspondente;
• aplicação de políticas de dados antes do encaminhamento;
• observabilidade end-to-end.

Fluxo:

Consumer
    │
AI Gateway
    │
Policy Evaluation (tenant + capability + data)
    │
Capability Resolution
    │
AI Service
    │
Model Abstraction Layer
    │
Provider Adapter
    │
Model (local ou cloud)

O AI Gateway não concentra lógica de RAG, chat ou classificação. Ele governa o acesso e roteia para o serviço especializado.

16.5 Capacidades de IA

Uma AI Capability representa uma finalidade de inteligência artificial governada. Cada capacidade possui: identificador, propósito, escopo de tenant, política de prompt, política de conhecimento, política de modelo, política de dados, quota e política de avaliação.

Capacidades disponíveis na plataforma:

Cada capacidade tem escopo declarado: plataforma (configuração centralizada) ou tenant (configuração e conhecimento específicos do órgão).

16.6 Configuração de IA por Tenant

Cada tenant tem configuração de IA própria dentro dos limites da política institucional da plataforma:

Platform Policy
      │
Tenant AI Configuration
  enabledCapabilities
  allowedProviders
  allowedModels
  knowledgeBases
  quotas
  dataPolicies
  featureFlags
      │
Capability Policy

A política efetiva é a interseção das permissões aplicáveis — tenant não pode ampliar o que a política de plataforma restringe.

16.7 Model Abstraction Layer

A Model Abstraction Layer desacopla os serviços de IA dos provedores específicos.

AI Service
    │
Model Abstraction Interface
    │
Model Router
    │
┌───────────────────────┐
│                       │
Provider Adapter A     Provider Adapter B (local)
│
External Model

Model Router: seleciona o modelo conforme capacidade, tenant, classificação dos dados, features necessárias, disponibilidade e custo. Modelos locais e em nuvem coexistem. A troca de provedor não exige alteração em nenhum serviço de negócio.

Model Registry: cataloga modelos e deployments aprovados com: nome, provedor, versão, capacidades suportadas, classificação de dados compatível, latência esperada, custo por token, política de retenção do provedor e data de aprovação.

Provider Adapters: encapsulam protocolos, autenticação, formato de requisição e resposta de cada provedor. A compatibilidade com a interface OpenAI é avaliada para padronizar adapters quando possível.

16.8 Gestão de Prompts

16.8.1 Prompt Registry

Prompts são versionados e governados. O Prompt Registry armazena templates com: identificador, capacidade associada, versão, status (draft, active, deprecated), few-shot examples, política de uso e histórico de avaliação.

16.8.2 Ciclo de Vida do Prompt

Draft → Evaluation → Approval → Active → Deprecated

Alteração de prompt ativo em produção sem versionamento é vedada. Cada execução registra a versão do prompt usada para correlacionar comportamento com configuração.

16.8.3 Few-Shot Examples

Exemplos few-shot são avaliados quanto a: presença de dados pessoais, representatividade, viés potencial e tamanho de contexto. Exemplos de produção não são copiados indiscriminadamente para prompts sem revisão.

16.9 Arquitetura RAG

16.9.1 Visão Geral

RAG (Retrieval-Augmented Generation) é utilizado quando respostas dependem de conhecimento institucional controlado. O LLM não é considerado fonte autoritativa — o conhecimento recuperado da base do tenant fundamenta a resposta.

Pipeline RAG:

Pergunta do usuário
    │
Query Normalization
    │
Query Expansion (opcional)
    │
Embedding da query
    │
Retrieval no vector store do tenant
    │
Filtering (autorização, classificação, vigência)
    │
Reranking
    │
Context Selection (Context Budget)
    │
Prompt Assembly
    │
LLM
    │
Output Processing (guardrails de saída)
    │
Resposta com citações (quando aplicável)

Cada estágio emite métricas.

16.9.2 Knowledge Base

Uma Knowledge Base representa um conjunto governado de conhecimento com: identificador, tenant, propósito, classificação, status e política de retrieval.

Exemplos:

SERVICE_CATALOG          → catálogo de serviços públicos do tenant
CITIZEN_FAQ              → perguntas frequentes dos cidadãos
INTERNAL_PROCEDURES      → procedimentos internos do órgão
TENANT_REGULATIONS       → normativas e regulamentos do tenant

Bases podem ter escopo de plataforma ou de tenant. Uma capacidade pode consultar múltiplas bases autorizadas simultaneamente.

16.9.3 Isolamento Multi-Tenant no RAG

O isolamento é estrutural e obrigatório:

Requisição de RAG com Tenant Context validado
    │
Knowledge Policy resolve bases autorizadas para o tenant
    │
Vector retrieval com filtro de tenant antes da busca
    │
Context Assembly apenas com conteúdo do tenant

Nunca: busca em todas as bases com filtro aplicado após recuperação. O filtro de tenant ocorre no nível do vector store.

Cada vetor armazena metadados mínimos:

{
  "tenantId": "tenant-abc",
  "knowledgeBaseId": "citizen-faq",
  "documentId": "doc-uuid",
  "documentVersion": 3,
  "chunkId": "chunk-uuid",
  "embeddingModel": "model-id-v2",
  "classification": "INTERNAL",
  "effectiveFrom": "2026-01-01",
  "effectiveTo": null,
  "indexedAt": "2026-07-15T10:00:00Z"
}

16.9.4 Knowledge Builder

Responsável pela construção e atualização assíncrona das bases de conhecimento:

Fonte autorizada (GED, Data Lake, API, catálogo)
    │
Source Connector
    │
Ingestion (rastreável com ingestionId)
    │
Extração de conteúdo (OCR quando necessário)
    │
Normalização
    │
Chunking (tamanho e overlap configurados por tipo de conteúdo)
    │
Geração de embeddings (modelo aprovado)
    │
Indexação no vector store do tenant
    │
Publicação da versão do índice
    │
Publicação de ai.knowledge-indexed.v1

O processamento é acionado por evento RabbitMQ (ai.knowledge.index.v1). A existência técnica de acesso à fonte não constitui autorização para indexação — cada fonte requer política explícita.

16.9.5 Context Budget

Cada capacidade tem orçamento de contexto configurado, equilibrando:

• instruções de sistema;
• contexto conversacional;
• conteúdo recuperado via RAG;
• resultados de ferramentas;
• entrada do usuário.

O budget considera a janela de contexto do modelo. Conteúdo é selecionado por relevância e autorização, nunca concatenado cegamente.

16.9.6 Citações e Groundedness

Capacidades RAG institucionais suportam citações à fonte recuperada. A groundedness — aderência da resposta ao contexto fornecido — é monitorada por avaliação contínua. Respostas que extrapolam o conteúdo recuperado são sinalizadas.

16.10 Capacidades de IA por Tipo

16.10.1 Assistente do Cidadão (CITIZEN_ASSISTANT)

Interpreta perguntas em linguagem natural; localiza serviços no catálogo; explica requisitos; orienta preenchimento; recupera situação de protocolo quando autorizado; transfere para atendimento humano com contexto preservado.

Restrições: não executa ação transacional sem confirmação explícita; não acessa base de outro tenant; não afirma como fato informação ausente da base; indica incerteza quando necessário.

16.10.2 Copiloto do Atendente (ATTENDANT_COPILOT)

Resume histórico relevante do cidadão antes do atendimento; busca procedimentos na base de conhecimento; sugere resposta para revisão do atendente; identifica informações faltantes; apoia classificação de intenção.

A sugestão é claramente diferenciada de ação executada. O atendente decide o que usar. Ações transacionais requerem confirmação no serviço de domínio.

16.10.3 Classificação (REQUEST_TRIAGE)

Identifica intenção, assunto, prioridade, serviço relacionado, fila de destino e urgência. Resultados são tratados como apoio à decisão, exceto quando o tenant define e aprova formalmente uma regra de classificação automática com auditoria.

O Classification Service retorna resultado estruturado com confidence score. Quando o score está abaixo do threshold configurado, o item vai para fila de revisão humana (Human-in-the-Loop).

16.10.4 Sumarização (DOCUMENT_SUMMARY)

Sumariza documentos autorizados com template específico por finalidade. Sumarização hierárquica para documentos longos. Structured Output para extração de campos específicos. Avaliação de fidelidade ao conteúdo original.

16.10.5 Extração Estruturada

Extrai campos definidos por schema a partir de documentos. O output é validado contra o schema antes de ser retornado. O LLM não é o validador final — a aplicação valida o output estruturado.

16.10.6 Busca Semântica (SEMANTIC_SERVICE_SEARCH)

Busca por similaridade semântica no catálogo de serviços e na base de conhecimento do tenant. Busca híbrida (vetorial + textual) para combinar relevância semântica com correspondência lexical quando o contexto justifica.

16.11 Tool Calling

Tool calling é usado quando o modelo precisa executar ações fora de seu contexto de geração de texto.

16.11.1 Tool Registry

Ferramentas são registradas com: identificador, propósito, parâmetros, classificação de risco, política de autorização e política de idempotência. Ferramentas de alto risco requerem confirmação humana antes da execução.

16.11.2 Tool Execution Gateway

Toda execução de ferramenta passa pelo Tool Execution Gateway, que: valida a autorização do modelo para usar a ferramenta, aplica Tenant Context, valida parâmetros, executa em ambiente controlado, garante idempotência de side effects e registra auditoria.

O modelo propõe — o gateway autoriza e executa. A autorização não é delegada ao modelo.

16.11.3 Confirmação Humana

Operações sensíveis exigem confirmação explícita do usuário antes da execução:

IA propõe ação
    │
Apresentado ao usuário para confirmação
    │
Usuário confirma
    │
Backend valida autorização
    │
Executa

A confirmação não substitui autorização — ambas são necessárias.

16.12 Agentes de IA

Agentes são adotados em capacidades específicas com escopo restrito. Um agente genérico com acesso amplo não é padrão arquitetural.

Cada agente possui:

AI Agent
  goal (objetivo específico)
  scope (domínio restrito)
  tools (lista explícita de ferramentas permitidas)
  maxSteps (limite de iterações)
  budget (tokens, chamadas, tempo, custo)
  timeout
  dataPolicy
  approvalPolicy

Agent Runtime:

Objetivo
    │
Plan / Reasoning Loop
    │
Tool Gateway (autorizado e governado)
    │
Observação do resultado
    │
Próximo passo ou conclusão

O runtime impõe limites externos ao modelo. O agente não pode aumentar seu próprio escopo ou budget. Long-running agents usam processamento assíncrono com AI Jobs.

16.13 Automação Inteligente

16.13.1 Event-Driven AI

RabbitMQ dispara processamentos de IA assíncronos:

document.uploaded.v1
    │
AI Processing Queue
    │
Knowledge Indexer (chunking, embeddings, indexação)
    │
ai.knowledge-indexed.v1

Outro exemplo:

request.submitted.v1
    │
AI Classification Queue
    │
REQUEST_TRIAGE
    │
classification-result.v1 (consumido pelo Workflow Service)

A execução segue os padrões de mensageria, idempotência e retry definidos no Capítulo 13.

16.13.2 AI Jobs

Processamentos longos usam AI Jobs:

AI Job
  id
  tenantId
  capability
  inputReference  ← referência, nunca o documento integral
  status
  createdAt

Estados: PENDING → RUNNING → COMPLETED | FAILED | CANCELLED

Payloads transportam referências — nunca documentos binários integrais. O Job é idempotente quando a repetição pode gerar custo ou efeito duplicado.

16.13.3 Integração com BPM

A IA apoia processos BPM por proposta, nunca por alteração direta de estado:

AI Suggestion (classificação, extração, sumarização)
    │
BPM Rule Evaluation
    │
Validated Transition (autorizada pelo serviço de domínio)

A IA não altera o estado de instâncias de processo sem contrato e política formal.

16.14 Guardrails

Guardrails são aplicados em múltiplas camadas:

Input Policy        → tamanho, tipo, classificação, detecção de padrões
    │
Capability Policy   → verificação do tenant e da capacidade
    │
Retrieval Policy    → autorização e classificação do conteúdo recuperado
    │
Model               → geração controlada pelo prompt de sistema
    │
Output Policy       → schema, classificação, presença de PII, groundedness
    │
Domain Validation   → validação final pelo serviço de domínio (nunca pelo LLM)

Não existe dependência de um único filtro.

16.14.1 Prompt Injection

Prompt injection é tratada como risco arquitetural. A plataforma assume que entrada do usuário, documentos, páginas recuperadas por RAG e resultados de ferramentas podem conter instruções maliciosas.

Controles: separação estrutural entre instruções de sistema e conteúdo do usuário; delimitação explícita de contextos; classificação de ferramentas; autorização fora do modelo; validação de saídas; allowlist de ações.

16.14.2 Indirect Prompt Injection via RAG

RAG amplifica a superfície de indirect prompt injection:

Documento com instrução maliciosa → indexado → recuperado → LLM segue instrução

Mitigações: o conteúdo recuperado é tratado como dado, não como instrução; delimitação no prompt de sistema; restrição de ferramentas no contexto de RAG; avaliação de saída.

16.14.3 Redação e Minimização

Dados pessoais são identificados e removidos ou mascarados antes do envio ao modelo quando a finalidade não requer o dado original. A política de redação é configurada por capacidade e por tenant.

16.15 Metering e Custos

16.15.1 Metering

O metering registra por execução: tenant, capacidade, modelo, provedor, tokens de entrada, tokens de saída, latência, custo estimado e resultado.

O AI Gateway centraliza o metering antes de encaminhar ao serviço de IA. O custo é calculado a partir de preços versionados por modelo e provedor.

16.15.2 Cost Allocation

Custos são atribuídos por: tenant, capacidade, modelo, provedor e ambiente. Dashboards apresentam consumo por dimensão. Budget policies definem alertas e limites de gastos por tenant e por capacidade.

16.15.3 Quotas

Quotas configuráveis por tenant: requisições por período; concorrência máxima; tokens mensais; modelos permitidos; capacidades habilitadas.

16.16 Avaliação Contínua

16.16.1 Evaluation Framework

A qualidade é medida por avaliação específica por capacidade — não por score único opaco. Cada capacidade possui:

• Evaluation Dataset com casos representativos versionados;
• Golden Dataset com respostas esperadas aprovadas;
• Métricas específicas: RAG avalia groundedness, retrieval precision e completude; classificação avalia precision, recall e F1; sumarização avalia fidelidade e cobertura.

16.16.2 Governance de Mudanças

Mudanças em modelos, prompts, bases de conhecimento e ferramentas passam por:

Avaliação no Evaluation Dataset
    │
Comparação com versão atual (A/B ou shadow evaluation)
    │
AI Release Gate (critério de qualidade mínimo)
    │
Aprovação
    │
Deploy controlado (canary quando aplicável)

Prompt alterado diretamente em produção sem avaliação é vedado.

16.16.3 Feedback

Feedback de usuários (cidadãos e atendentes) alimenta datasets de avaliação. Feedback qualitativo é revisado por humano antes de uso em avaliação. Dados pessoais nos feedbacks são removidos antes do uso analítico.

16.17 Observabilidade de IA

16.17.1 AI Request ID

Cada execução recebe um AI Request ID propagado entre gateway, serviço de capacidade, model router, provider adapter e result. Permite rastreamento ponta a ponta de uma interação de IA.

16.17.2 Métricas por Capacidade

16.17.3 Logs de IA

Logs de IA nunca incluem: prompts completos com dados pessoais, conteúdo de documentos recuperados, tokens de usuário, segredos de provedor. Registros incluem IDs de referência para correlação sem expor conteúdo sensível.

16.17.4 Provider Health

O estado de saúde dos provedores é monitorado continuamente. Métricas: disponibilidade, latência, taxa de erro, taxa de rate limiting e estado do circuit breaker. Fallback para modelo alternativo aprovado quando o primário degrada.

16.18 Resiliência

16.18.1 Timeout

Toda operação de IA tem timeout configurado por capacidade e por operação: embedding, chat, reranking, classificação, execução de ferramenta.

16.18.2 Circuit Breaker

Circuit breakers isolam provedores degradados. Quando o limiar de falhas é excedido, o circuit breaker abre e direciona para fallback aprovado sem pressionar o provedor.

16.18.3 Fallback

Fallback é governado — não automático para provedor não autorizado:

Modelo primário indisponível
    │
Política de fallback aprovada para a capacidade e classificação dos dados
    │
Modelo alternativo compatível

Dados restritos nunca migram para provedor sem política de dados compatível apenas por disponibilidade.

16.18.4 Degradação Controlada

A indisponibilidade de IA não bloqueia o núcleo transacional da plataforma. Cada capacidade define seu fallback funcional:

Busca semântica indisponível → busca textual
Sumarização indisponível     → apresentar documento original
Classificação indisponível   → fila de classificação manual
Assistente indisponível      → mensagem de redirecionamento ao atendimento

16.18.5 Kill Switch

Qualquer dimensão pode ser desabilitada sem alteração de código:

• capacidade específica (ex.: ATTENDANT_COPILOT);
• provedor (ex.: desabilitar Provedor X para todos os tenants);
• modelo específico;
• tenant específico;
• ferramenta específica.

O kill switch é operado por administrador da plataforma e registrado em auditoria.

16.19 Segurança em IA

16.19.1 Proteção de Credenciais

Chaves de API de provedores são gerenciadas pelo cofre de segredos. Nenhum serviço de negócio armazena credenciais de provedor. A rotação de chaves não exige deploy de aplicações.

16.19.2 Política de Dados por Provedor

Cada provedor tem política de dados registrada: retenção, região, uso em treinamento, referência contratual. A seleção de modelo considera a classificação dos dados e a compatibilidade com a política do provedor.

Dados classificados como restritos não são enviados a provedores sem política de dados compatível, mesmo para capacidades de fallback.

16.19.3 Incidentes de IA

Incidentes específicos de IA são catalogados e possuem runbooks: cross-tenant retrieval, exposição de prompt, tool execution indevida, violação de política de dados do provedor, resposta sistematicamente incorreta em capacidade crítica.

16.20 Decisões Confirmadas

1. IA é implementada como plataforma corporativa com AI Gateway como ponto de entrada;
2. serviços de negócio nunca dependem diretamente de SDKs ou APIs de provedores;
3. toda capacidade de IA requer Tenant Context validado antes de execução;
4. bases de conhecimento, vetores e configurações são isolados por tenant de forma estrutural;
5. RAG é o mecanismo para respostas baseadas em conhecimento institucional;
6. o filtro de tenant no vector store ocorre antes da busca, nunca após;
7. prompts são versionados no Prompt Registry com ciclo de vida formal;
8. guardrails são aplicados em múltiplas camadas: entrada, retrieval, saída e validação de domínio;
9. prompt injection e indirect prompt injection são riscos arquiteturais tratados pelo pipeline;
10. tool calling é mediado pelo Tool Execution Gateway com autorização independente do modelo;
11. agentes têm escopo, ferramentas, maxSteps e budget definidos explicitamente;
12. processamentos assíncronos de IA usam RabbitMQ e AI Jobs com payload por referência;
13. metering registra consumo por tenant, capacidade, modelo e provedor;
14. qualidade é avaliada por Evaluation Framework com datasets versionados por capacidade;
15. falha de IA não bloqueia o núcleo transacional; degradação controlada é definida por capacidade;
16. kill switch está disponível por capacidade, tenant, provedor, modelo e ferramenta.

16.21 Benefícios da Arquitetura

• desacoplamento de provedores — troca de modelo sem alterar código de negócio;
• isolamento multi-tenant em todos os estágios: bases, vetores, configurações, quotas;
• RAG governado com bases de conhecimento versionadas e citações rastreáveis;
• guardrails em múltiplas camadas sem dependência de filtro único;
• fallback funcional definido para cada capacidade;
• metering e cost allocation por tenant para gestão de custos;
• avaliação contínua com regression testing antes de mudanças em produção;
• kill switch operacional sem deploy de código;
• modelos locais e em nuvem coexistindo sob a mesma abstração.

16.22 Riscos e Mitigações

16.23 Decisões Arquiteturais

16.24 Rastreabilidade com o Anexo III

• Bloco 1 — Relacionamento e Atendimento: CITIZEN_ASSISTANT para autoatendimento; ATTENDANT_COPILOT para atendimento humano; REQUEST_TRIAGE para classificação e roteamento.
• Bloco 2 — BPM: integração IA/BPM por proposta; classificação automatizada com Human-in-the-Loop; Event-Driven AI para enriquecimento de processos.
• Bloco 3 — Gestão Documental: DOCUMENT_SUMMARY para sumarização; extração estruturada para indexação; Knowledge Builder para ingestão de documentos do GED.
• Bloco 4 — Dados e Inteligência: busca semântica, RAG, insights analíticos; Evaluation Framework para qualidade contínua; metering e cost allocation.
• Bloco 5 — Integração: AI Gateway como API de IA; contratos de capacidades; Event-Driven AI por RabbitMQ.
• Bloco 6 — Infraestrutura e Governança: isolamento multi-tenant em todas as camadas; kill switch; guardrails; Prompt Registry; Model Registry; auditoria de execuções.

16.25 Considerações Finais

A Arquitetura de IA estabelece um modelo que permite à plataforma incorporar inteligência artificial como capacidade transversal e governada, sem criar dependências diretas entre serviços de negócio e fornecedores de modelos. O isolamento multi-tenant, os guardrails distribuídos, o RAG com bases de conhecimento por tenant e a avaliação contínua garantem que a evolução tecnológica de IA — troca de provedores, adoção de modelos locais, melhoria de prompts — ocorra sem comprometer segurança, privacidade ou rastreabilidade.

O Capítulo 17 detalha a Arquitetura de Segurança, Identidade e Proteção de Dados.

16.26 Controle de Versão

16.27 Rastreabilidade PRODEMGE

• [ANX-III] — Blocos 1 a 6 cobertos conforme seção 16.24.
• [ANX-IV] — Capacidades técnicas de IA conversacional, busca semântica, RAG, classificação, sumarização, automação inteligente e governança de modelos.
• [ANX-V] — Sustentabilidade: desacoplamento de provedores por Model Abstraction Layer, versionamento de prompts e datasets, avaliação contínua com Evaluation Framework, degradação controlada e kill switch.
• [PNR] — Plano de Negócio Referencial: assistente digital ao cidadão, copiloto de atendimento, classificação automática e insights analíticos como capacidades da plataforma.
• [EDITAL] — Edital CP001/2026: plataforma com capacidades de inteligência artificial integradas, governadas e com isolamento por tenant.