Capítulo 65 — Atendimento às Capacidades (Anexo IV)
Este capítulo demonstra o atendimento integral da Plataforma de Relacionamento Digital com o Cidadão aos requisitos de capacidade definidos no Anexo IV do Chamamento Público CP001/2026.
65.1 Objetivo do Capítulo
Este capítulo demonstra o atendimento integral da Plataforma de Relacionamento Digital com o Cidadão aos requisitos de capacidade definidos no Anexo IV do Chamamento Público CP001/2026.
O Anexo IV organiza a avaliação de capacidades em quatro blocos: Experiência em Soluções Digitais (Bloco 1), Experiência em Contextos Complexos e/ou Setor Público (Bloco 2), Capacidade de Implantação, Operação e Escala (Bloco 3), e Capacidade de Atuação em Parceria (Bloco 4). Cada bloco contém requisitos com peso específico e critério de aceitação definido pela PRODEMGE.
A demonstração aqui apresentada é estrutural: para cada item do Anexo IV, identifica o requisito exato, apresenta a evidência documental disponível neste Documento Mestre, aponta os capítulos onde a capacidade é descrita em profundidade e declara o grau de atendimento. O propósito é eliminar qualquer ambiguidade sobre o que a plataforma é capaz de fazer e onde essa capacidade está documentada — facilitando o trabalho de validação técnica da PRODEMGE.
65.2 Contexto
O Anexo IV representa 30% da pontuação total do processo de qualificação técnica. A avaliação combina autodeclaração da interessada e validação independente pela PRODEMGE. Os pesos estratégicos atribuídos a cada bloco refletem as prioridades da parceria: o Bloco 1 (Experiência em Soluções Digitais) tem peso estratégico Muito Alto (15 pontos), o Bloco 3 (Capacidade de Implantação, Operação e Escala) tem peso Alto (12 pontos), o Bloco 2 (Experiência em Contextos Complexos) tem peso Médio (9 pontos), e o Bloco 4 (Capacidade de Atuação em Parceria) tem peso Baixo (6 pontos).
A estrutura de pontuação estabelece três graus de atendimento para cada requisito: Não atende (0), Atende parcialmente (0,5) e Atende integralmente (1). A pontuação de cada item resulta da multiplicação do grau de atendimento pelo peso do item.
Este capítulo integra a Parte IX — Qualificação PRODEMGE, que consolida, em um único lugar, a demonstração sistemática de aderência da proposta a todos os instrumentos avaliativos do chamamento. O Capítulo 64 tratou o Anexo III (Funcionalidades); este capítulo trata o Anexo IV (Capacidades); o Capítulo 66 tratará o Anexo V (Sustentabilidade).
65.3 Escopo
Este capítulo abrange todos os itens dos quatro blocos do Anexo IV, apresentando para cada um: o requisito conforme definido no anexo, o critério de aceitação exato, a evidência de atendimento com referência ao capítulo específico deste documento, e a declaração formal de grau de atendimento.
Não são objeto deste capítulo os Blocos do Anexo III (tratados no Capítulo 64), os critérios de sustentabilidade do Anexo V (tratados no Capítulo 66) nem os critérios do Anexo II (Qualificação Técnica Geral). O Capítulo 67 consolidará a matriz completa de aderência cruzando todos os instrumentos.
65.4 Estrutura do Anexo IV
O Anexo IV é organizado conforme a tabela a seguir, que estabelece os parâmetros gerais antes do detalhamento item a item.
| Bloco | Descrição | Peso Estratégico | Itens | Peso por Item | Peso Total do Bloco |
|---|---|---|---|---|---|
| 1 | Experiência em Soluções Digitais | Muito Alto | 3 | 5 | 15 |
| 2 | Experiência em Contextos Complexos e/ou Setor Público | Médio | 3 | 3 | 9 |
| 3 | Capacidade de Implantação, Operação e Escala | Alto | 3 | 4 | 12 |
| 4 | Capacidade de Atuação em Parceria | Baixo | 3 | 2 | 6 |
| Total | 12 | 42 |
A pontuação máxima atingível é 42 pontos quando todos os itens recebem grau de atendimento integral. A avaliação da PRODEMGE é soberana e considera as evidências apresentadas pela interessada mais análise técnica independente.
65.5 Bloco 1 — Experiência em Soluções Digitais
Descrição do Bloco: avalia a experiência da interessada na concepção, desenvolvimento e operação de soluções digitais compatíveis com o objeto da parceria.
O Bloco 1 tem o maior peso estratégico do Anexo IV. A avaliação neste bloco determina se a interessada possui experiência concreta e demonstrável no tipo de solução que a parceria exige — não apenas familiaridade tecnológica genérica, mas capacidade comprovada de produzir e operar soluções digitais com múltiplos módulos integrados, integrações sistêmicas reais e uso aplicado de dados e inteligência.
65.5.1 Item 1.1 — Soluções Digitais com Múltiplos Módulos Integrados
Requisito: Comprovar experiência no desenvolvimento ou fornecimento de soluções digitais com múltiplos módulos integrados.
Forma de Comprovação: atestado técnico, contrato ou documentação da solução.
Critério de Avaliação: será considerado atendido mediante comprovação de solução com, no mínimo, 2 componentes funcionais integrados (ex: CRM, BPM, ECM, dados ou equivalente).
Peso: 5.
Evidência de Atendimento:
A plataforma é composta por 18 grupos funcionais integrados, organizados em módulos com responsabilidades distintas e contratos estáveis de comunicação. Os módulos não operam de forma isolada — são arquitetados para interoperação contínua por meio de eventos RabbitMQ, APIs REST e dados compartilhados sob governança de tenant.
Os módulos funcionais incluem, entre outros: CRM — Gestão de Relacionamento (Capítulo 18), BPM — Gestão de Processos (Capítulo 19), ECM e GED — Gestão Documental (Capítulo 20), Comunicação Omnichannel (Capítulo 21), Analytics e Data Lake (Capítulo 23), Dashboards e Business Intelligence (Capítulo 24), Portal Web (Capítulo 25), Aplicativo Mobile (Capítulo 26), Gestão de Usuários e Identidade (Capítulo 28), e Gestão Multi-Tenant (Capítulo 30).
A integração entre módulos é estrutural e não ornamental. O fluxo de uma solicitação de serviço público exemplifica isso: o cidadão acessa pelo portal (Capítulo 25) ou aplicativo (Capítulo 26), se autentica via IAM (Capítulo 28), submete uma solicitação que dispara um processo BPM (Capítulo 19), gera documentação armazenada no ECM (Capítulo 20), dispara comunicações via omnichannel (Capítulo 21), registra dados no CRM (Capítulo 18) e alimenta o Data Lake para análise posterior (Capítulo 23). Cada módulo executa sua responsabilidade sem acoplamento direto; a integração ocorre por contratos de eventos e APIs documentados na Arquitetura de Mensageria (Capítulo 13) e na Arquitetura de APIs e Integrações (Capítulo 14).
Referências neste documento: Capítulos 10, 12, 13, 14, 18, 19, 20, 21, 23, 24, 25, 26.
Grau de Atendimento Declarado: Atende integralmente.
65.5.2 Item 1.2 — Integração de Sistemas por Meio de APIs
Requisito: Comprovar experiência em soluções com integração de sistemas por meio de APIs ou mecanismos equivalentes.
Forma de Comprovação: documentação técnica, arquitetura da solução ou atestado técnico.
Critério de Avaliação: será considerado atendido mediante evidência de integração sistêmica com uso de APIs, serviços web ou mecanismos equivalentes.
Peso: 5.
Evidência de Atendimento:
A Arquitetura de APIs e Integrações (Capítulo 14) descreve em profundidade o modelo de integração da plataforma. A solução expõe e consome APIs REST com versionamento explícito, contratos OpenAPI documentados (Capítulo 71), e mecanismos de autenticação por OAuth 2.0 e JWT. A camada de APIs é mediada por API Gateway com controle de taxa, autenticação, roteamento e observabilidade.
As integrações com o ecossistema externo cobrem: autenticação de cidadãos via GOV.BR (integração federada com o IAM da plataforma, descrita no Capítulo 43), SEI!MG para gestão documental governamental, MG API como concentrador de APIs do ecossistema estadual, DATALAKE MG para compartilhamento de dados analíticos, Portal de Municípios, Agenda Minas, PRO SMTP para entrega de e-mail transacional e SEG.ID para verificação de identidade.
As integrações entre módulos internos operam por eventos RabbitMQ (Capítulo 13) para comunicação assíncrona e por chamadas REST internas para comunicação síncrona. O modelo de eventos garante desacoplamento: um módulo publica um evento sem conhecer os consumidores; os consumidores se inscrevem por tipo de evento sem depender do publicador. Esse padrão, descrito nos Capítulos 12 e 13, é evidência de maturidade de integração sistêmica que vai além da simples interoperabilidade por APIs.
A Arquitetura de Microsserviços (Capítulo 12) documenta os contratos de API de cada serviço, incluindo endpoints candidatos, modelos de dados de entrada e saída, e eventos produzidos e consumidos. Isso representa documentação técnica de integração em nível de detalhe superior ao exigido pelo critério de aceitação do item.
Referências neste documento: Capítulos 12, 13, 14, 43, 71, 72.
Grau de Atendimento Declarado: Atende integralmente.
65.5.3 Item 1.3 — Uso de Dados, Automação ou Inteligência Aplicada
Requisito: Comprovar experiência no uso de dados, automação ou inteligência aplicada à solução.
Forma de Comprovação: documentação técnica, case ou atestado.
Critério de Avaliação: será considerado atendido mediante evidência de uso de analytics, automação de processos ou inteligência aplicada.
Peso: 5.
Evidência de Atendimento:
A plataforma integra capacidades de dados, automação e inteligência em três camadas distintas e complementares.
A camada de dados é estruturada em torno de um Data Lake segregado por tenant, descrito na Arquitetura de Dados, Persistência e Cache (Capítulo 15) e no capítulo Analytics e Data Lake (Capítulo 23). O DATALAKE MG é utilizado como repositório de longa retenção para dados analíticos agregados. Dashboards e Business Intelligence (Capítulo 24) transformam os dados operacionais em visibilidade gerencial para os órgãos, com indicadores de desempenho de atendimento, volume de solicitações, tempo de ciclo de processos e satisfação do cidadão.
A camada de automação é implementada pelo módulo BPM (Capítulo 19), que suporta modelagem BPMN, execução de fluxos, gestão de tarefas, controle de SLA de processo e automação de transições por eventos. A integração entre o BPM e o módulo de Comunicação Omnichannel (Capítulo 21) permite notificações automáticas de progresso de processo sem intervenção manual. A Arquitetura de Inteligência Artificial (Capítulo 16) descreve o uso de automação por classificação semântica: solicitações recebidas são classificadas automaticamente e roteadas ao processo BPM correspondente.
A camada de inteligência é baseada em LLM com arquitetura RAG (Retrieval-Augmented Generation), descrita no Capítulo 16. O copiloto de atendimento opera sobre a base de conhecimento do tenant, respondendo dúvidas, consultando protocolos e orientando o cidadão em linguagem natural. O pacote @brasfy/core/assistente com roteamento semântico está implementado e operacional no código-fonte da plataforma. A busca vetorial e indexação semântica (Capítulo 36) suporta recuperação de documentos por similaridade, não apenas por correspondência de termos.
Referências neste documento: Capítulos 15, 16, 19, 21, 23, 24, 36.
Grau de Atendimento Declarado: Atende integralmente.
65.5.4 Consolidação do Bloco 1
| Item | Descrição | Peso | Grau de Atendimento | Pontuação |
|---|---|---|---|---|
| 1.1 | Soluções digitais com múltiplos módulos integrados | 5 | Atende integralmente | 5,0 |
| 1.2 | Integração de sistemas por APIs | 5 | Atende integralmente | 5,0 |
| 1.3 | Dados, automação ou inteligência aplicada | 5 | Atende integralmente | 5,0 |
| Subtotal Bloco 1 | 15 | 15,0 |
65.6 Bloco 2 — Experiência em Contextos Complexos e/ou Setor Público
Descrição do Bloco: avalia a experiência da interessada em ambientes com maior complexidade operacional, preferencialmente no setor público.
A complexidade operacional aqui avaliada não é apenas técnica. Ela inclui: multiplicidade de usuários com perfis distintos, processos de governança e controle, ambientes regulados com rastreabilidade obrigatória, e atendimento digital a usuários finais em contextos de serviço público. O edital reconhece que soluções voltadas ao setor público impõem restrições e responsabilidades que ambientes corporativos genéricos não exigem.
65.6.1 Item 2.1 — Projetos com Múltiplos Usuários, Processos ou Sistemas Integrados
Requisito: Comprovar experiência em projetos com múltiplos usuários, processos ou sistemas integrados.
Forma de Comprovação: atestado técnico ou contrato.
Critério de Avaliação: será considerado atendido mediante comprovação de solução com múltiplos usuários ativos ou integração de sistemas distintos.
Peso: 3.
Evidência de Atendimento:
A plataforma foi projetada desde a concepção para suportar múltiplos tenants simultâneos, cada um representando um órgão público com seus próprios usuários, processos, configurações, integrações e dados. A arquitetura multi-tenant nativa (Capítulo 30) garante segregação completa por tenant sem duplicação de infraestrutura — cada órgão opera em ambiente logicamente isolado sobre a mesma plataforma compartilhada.
Os usuários da plataforma pertencem a categorias distintas com jornadas diferentes: cidadãos (acesso via portal e aplicativo), usuários internos dos órgãos (atendentes, gestores, analistas), usuários administrativos da PRODEMGE (gestão da plataforma e dos tenants) e sistemas externos que se integram via APIs. A Gestão de Usuários e Identidade (Capítulo 28) e a Gestão de Perfis e Permissões (Capítulo 29) cobrem a complexidade de múltiplos perfis em múltiplos tenants, com controle de acesso baseado em papéis e herança de permissões configurável por tenant.
A integração com múltiplos sistemas distintos é documentada no Capítulo 14, incluindo GOV.BR, SEI!MG, Portal de Municípios, PROBPMS, Agenda Minas, SEG.ID, MG API e DATALAKE MG. Cada integração representa um sistema externo com protocolo, modelo de dados e requisitos de autenticação próprios — a plataforma opera como orquestradora de todos eles sem criar dependência singular.
Referências neste documento: Capítulos 14, 28, 29, 30.
Grau de Atendimento Declarado: Atende integralmente.
65.6.2 Item 2.2 — Experiência em Ambientes Regulados ou Setor Público
Requisito: Comprovar experiência em ambientes regulados ou setor público (desejável).
Forma de Comprovação: atestado técnico ou declaração.
Critério de Avaliação: será considerado atendido mediante comprovação de atuação em ambiente público ou regulado.
Peso: 3.
Evidência de Atendimento:
A plataforma é construída sobre os requisitos normativos e regulatórios do setor público brasileiro. Isso não é uma adaptação de uma solução corporativa genérica — é uma decisão de projeto que atravessa todas as camadas da arquitetura.
A conformidade com a LGPD (Lei 13.709/2018) é tratada com profundidade no Capítulo 44, que cobre: lawful basis por tipo de tratamento, portabilidade de dados, direito ao esquecimento, consentimento granular, privacidade por design, relatório de impacto à proteção de dados (RIPD) e mecanismos técnicos de anonimização e pseudonimização. A plataforma opera como Controladora de dados dos cidadãos no contexto da prestação de serviços públicos digitais — papel que traz obrigações legais específicas cumpridas pela arquitetura.
A integração nativa com GOV.BR (Capítulo 43) coloca a plataforma dentro do ecossistema digital do governo federal, com uso do padrão de identidade digital governamental brasileiro. O SEI!MG, sistema de gestão de processos administrativos eletrônicos do governo de Minas Gerais, é integrado como repositório documental para processos que exigem tramitação formal (Capítulo 20 e Capítulo 14).
A rastreabilidade e auditoria (Capítulo 45) são implementadas em nível de evento: toda ação de usuário, toda transição de estado de processo e toda operação com dados pessoais gera registro imutável com metadados de contexto. Esse nível de rastreabilidade é exigência de ambientes regulados e serve tanto à conformidade legal quanto à supervisão de órgãos de controle.
Referências neste documento: Capítulos 14, 20, 43, 44, 45.
Grau de Atendimento Declarado: Atende integralmente.
65.6.3 Item 2.3 — Soluções Voltadas ao Atendimento Digital de Usuários
Requisito: Comprovar experiência em soluções voltadas ao atendimento digital de usuários.
Forma de Comprovação: documentação da solução ou atestado.
Critério de Avaliação: será considerado atendido mediante evidência de solução com interface de atendimento digital (portal, app, chatbot ou equivalente).
Peso: 3.
Evidência de Atendimento:
O atendimento digital ao cidadão é o propósito central da plataforma — não um módulo secundário. A plataforma oferece múltiplos canais de atendimento digital operando de forma integrada e com continuidade de sessão.
O Portal Web (Capítulo 25) é a interface principal de acesso do cidadão aos serviços do órgão: solicitação de serviços, acompanhamento de protocolos, consulta de documentos, agendamento, manifestações de ouvidoria e acesso ao histórico de interações. O portal é responsivo e acessível, seguindo as diretrizes de acessibilidade digital.
O Aplicativo Mobile (Capítulo 26) oferece as mesmas capacidades em plataforma nativa para iOS e Android, com suporte a notificações push, autenticação biométrica e funcionamento em modo offline para consultas. O módulo Copiloto, confirmado no código-fonte com o pacote @brasfy/core/assistente, está integrado ao aplicativo mobile e oferece atendimento em linguagem natural por voz e texto.
A Comunicação Omnichannel (Capítulo 21) cobre canais ativos de atendimento: e-mail, SMS, WhatsApp e notificações push. A plataforma não apenas recebe demandas pelos canais digitais, mas também inicia comunicações com o cidadão em todos os canais configurados pelo tenant.
O chatbot de atendimento opera sobre a infraestrutura de IA (Capítulo 16), com RAG sobre a base de conhecimento do tenant, histórico de interações do cidadão e integração com o módulo de solicitações — podendo consultar o status de um protocolo em tempo real durante a conversa. Esses três canais — portal, aplicativo e chatbot — operam sobre o mesmo registro de cidadão e o mesmo histórico de interações no CRM (Capítulo 18).
Referências neste documento: Capítulos 16, 18, 21, 25, 26.
Grau de Atendimento Declarado: Atende integralmente.
65.6.4 Consolidação do Bloco 2
| Item | Descrição | Peso | Grau de Atendimento | Pontuação |
|---|---|---|---|---|
| 2.1 | Projetos com múltiplos usuários, processos ou sistemas | 3 | Atende integralmente | 3,0 |
| 2.2 | Ambientes regulados ou setor público | 3 | Atende integralmente | 3,0 |
| 2.3 | Atendimento digital de usuários | 3 | Atende integralmente | 3,0 |
| Subtotal Bloco 2 | 9 | 9,0 |
65.7 Bloco 3 — Capacidade de Implantação, Operação e Escala
Descrição do Bloco: avalia a capacidade da interessada de implantar e operar soluções em ambiente produtivo.
O Bloco 3 distingue entre ter construído uma solução e ser capaz de colocá-la em produção de forma repetível, sustentá-la operacionalmente e escalá-la à medida que novos tenants e volumes de uso aumentam. Essa distinção é relevante para a PRODEMGE: a parceria não termina na entrega da plataforma — ela inclui onboarding de tenants, operação contínua e escala ao longo de toda a vigência do contrato.
65.7.1 Item 3.1 — Implantação de Soluções em Ambiente de Produção
Requisito: Comprovar experiência na implantação de soluções tecnológicas em ambiente de produção.
Forma de Comprovação: atestado técnico ou contrato.
Critério de Avaliação: será considerado atendido mediante comprovação de implantação efetiva da solução.
Peso: 4.
Evidência de Atendimento:
A plataforma possui modelo de implantação estruturado e documentado, descrito no Capítulo 48 (Implantação e Onboarding de Tenants). O processo de onboarding de um novo tenant cobre: provisionamento de infraestrutura isolada por namespace Kubernetes (Capítulo 38), configuração de banco de dados com schema segregado (Capítulo 34), parametrização do tenant no painel administrativo (Capítulo 27), configuração de domínio e certificado TLS, ativação de integrações selecionadas pelo órgão, carga de dados iniciais e configuração de canais de comunicação.
A infraestrutura de implantação é baseada em Kubernetes (Capítulo 38) com containers Docker (Capítulo 39). Os manifests de implantação são versionados junto ao código-fonte (Capítulo 58) e aplicados por pipeline CI/CD (Capítulo 40). A pipeline de entrega contínua executa testes automatizados, análise estática de segurança, escaneamento de vulnerabilidades em imagens de container, e deploy progressivo com suporte a rollback automático em caso de falha de health check.
A Migração e Transição Operacional (Capítulo 49) documenta o processo de transição do ambiente legado do órgão para a plataforma, incluindo mapeamento de dados, estratégia de migração, período de operação em paralelo e critérios de aceite da transição. A Capacitação e Transferência de Conhecimento (Capítulo 50) estrutura a formação das equipes dos órgãos antes e durante a implantação.
Referências neste documento: Capítulos 27, 34, 38, 39, 40, 48, 49, 50, 58.
Grau de Atendimento Declarado: Atende integralmente.
65.7.2 Item 3.2 — Operação e Sustentação Contínua
Requisito: Comprovar capacidade de operação e sustentação contínua da solução.
Forma de Comprovação: documentação de suporte, SLA ou atestado.
Critério de Avaliação: será considerado atendido mediante evidência de operação contínua ou suporte técnico estruturado.
Peso: 4.
Evidência de Atendimento:
A estrutura de operação e sustentação é descrita em três capítulos articulados: Operação e Gestão de Serviços (Capítulo 51), Sustentação e Suporte Técnico (Capítulo 52) e SLA — Acordos de Nível de Serviço (Capítulo 53).
O modelo de suporte opera em três níveis com competências, canais e SLAs distintos. O N1 é operado pela PRODEMGE como ponto de contato primário dos órgãos. O N2 é operado pela parceira com especialização funcional e de integração. O N3 é operado por engenheiros de plataforma com acesso ao código-fonte, à arquitetura de dados e à infraestrutura de produção. Cada nível tem competências precisamente delimitadas para evitar escalações desnecessárias e garantir que cada tipo de problema chegue ao profissional com capacidade de resolvê-lo.
Os compromissos de SLA cobrem disponibilidade (99,5% para serviços críticos, medida sobre a camada de experiência do usuário), tempo de resposta (incidente S1: 15 minutos), tempo de resolução (S1: 4 horas), e latência de aplicação (P95 ≤ 500ms para autenticação). A medição de disponibilidade usa probes sintéticos externos e métricas de taxa de erro via OpenTelemetry (Capítulo 41), garantindo que a medição reflete a experiência real do usuário, não apenas a disponibilidade da infraestrutura interna.
A sustentação cobre quatro modalidades: manutenção corretiva (falhas e incidentes), manutenção preventiva (degradação antecipada identificada via observabilidade), manutenção adaptativa (adequações a mudanças externas, como versões de APIs de sistemas integrados) e manutenção evolutiva (melhorias funcionais e técnicas dentro do escopo da parceria).
Referências neste documento: Capítulos 41, 51, 52, 53.
Grau de Atendimento Declarado: Atende integralmente.
65.7.3 Item 3.3 — Capacidade de Operação em Escala
Requisito: Comprovar capacidade de operação em escala.
Forma de Comprovação: atestado técnico ou métricas operacionais.
Critério de Avaliação: será considerado atendido mediante evidência de operação com volume relevante de usuários ou transações.
Peso: 4.
Evidência de Atendimento:
A escala operacional da plataforma é garantida por decisões arquiteturais estruturais que permeiam toda a pilha tecnológica — não por superdimensionamento estático de recursos.
O backend em microsserviços (Capítulo 12) permite escalonamento independente por serviço: o serviço de autenticação pode escalar de forma diferente do serviço de BPM ou do serviço de analytics, dependendo do perfil de carga de cada tenant e de cada período. O orquestrador Kubernetes (Capítulo 38) opera com Horizontal Pod Autoscaler (HPA) baseado em métricas de CPU, memória e latência de aplicação — o escalonamento é automático e reativo ao volume real de demanda.
O Cache Distribuído (Capítulo 35) baseado em Redis reduz a pressão sobre o banco de dados para operações de alta frequência: sessões de usuário, dados de tenant frequentemente lidos, catálogo de serviços e perfis de cidadão são servidos por cache com TTL configurável por tipo de dado. Para operações de leitura de alta demanda, o cache mantém a latência abaixo de 10ms independentemente da carga sobre o banco relacional.
A Busca, Vetores e Indexação Semântica (Capítulo 36) é implementada com banco vetorial separado do banco relacional, garantindo que operações de busca — especialmente as semânticas usadas pelo copiloto de IA — não competem por recursos com as operações transacionais.
A Arquitetura de Dados, Persistência e Cache (Capítulo 15) descreve o modelo de segregação por tenant em nível de schema PostgreSQL, com pool de conexões dimensionado por tenant para garantir isolamento de desempenho: a degradação em um tenant com pico de carga não se propaga para outros tenants na mesma instância de banco.
A RabbitMQ (Capítulo 13) opera como buffer de absorção de carga para fluxos assíncronos: notificações, processamento de documentos, indexação de dados para analytics e envio de comunicações são processados por consumidores escaláveis sem bloqueio da camada de APIs. Em cenários de pico, a fila absorve o excedente; os consumidores escalam horizontalmente para processar o backlog.
Referências neste documento: Capítulos 12, 13, 15, 35, 36, 38.
Grau de Atendimento Declarado: Atende integralmente.
65.7.4 Consolidação do Bloco 3
| Item | Descrição | Peso | Grau de Atendimento | Pontuação |
|---|---|---|---|---|
| 3.1 | Implantação em ambiente de produção | 4 | Atende integralmente | 4,0 |
| 3.2 | Operação e sustentação contínua | 4 | Atende integralmente | 4,0 |
| 3.3 | Operação em escala | 4 | Atende integralmente | 4,0 |
| Subtotal Bloco 3 | 12 | 12,0 |
65.8 Bloco 4 — Capacidade de Atuação em Parceria
Descrição do Bloco: avalia a aptidão da interessada para atuar em modelo colaborativo e de risco compartilhado.
O Bloco 4 reconhece que a parceria com a PRODEMGE não é uma relação de contratação de produto ou serviço — é um modelo de colaboração em que a interessada divide responsabilidades, riscos e resultados com a contratante. A aptidão para operar nesse modelo exige: capacidade de evolução tecnológica contínua da solução, experiência em projetos colaborativos com outras organizações, e disposição formal para compartilhar riscos.
65.8.1 Item 4.1 — Evolução Contínua da Solução
Requisito: Comprovar capacidade de evolução contínua da solução.
Forma de Comprovação: roadmap, histórico ou documentação.
Critério de Avaliação: será considerado atendido mediante evidência de evolução tecnológica contínua da solução.
Peso: 2.
Evidência de Atendimento:
A evolução contínua da plataforma é um processo estruturado, não uma intenção declaratória. O Roadmap Tecnológico (Capítulo 54) e a Gestão da Evolução da Plataforma (Capítulo 55) descrevem como a plataforma evolui ao longo do tempo: ciclos de planejamento, priorização, desenvolvimento, homologação e implantação de novas capacidades.
O modelo de evolução distingue entre manutenção evolutiva — melhorias dentro do escopo funcional existente — e evolução estratégica — novas capacidades derivadas do roadmap tecnológico da plataforma e das demandas identificadas nos órgãos participantes. A Gestão de Mudanças (Capítulo 59) estrutura como alterações na plataforma são avaliadas quanto ao impacto, aprovadas, comunicadas e implantadas sem interrupção dos serviços existentes.
O DevSecOps e Entrega Contínua (Capítulo 40) é o mecanismo operacional da evolução: cada ciclo de desenvolvimento culmina em uma entrega deployável, testada automaticamente e aplicada por pipeline sem janela de indisponibilidade planejada para a maioria das mudanças. O versionamento de APIs (Capítulo 14) garante que a evolução das interfaces não quebra integrações existentes: versões anteriores são mantidas com suporte por período definido enquanto os consumidores migram.
A Gestão de Configuração e Custódia de Código (Capítulo 58) formaliza o processo de custódia do código-fonte, garantindo que o acervo tecnológico da parceria está protegido e disponível para a PRODEMGE em qualquer cenário de descontinuidade.
Referências neste documento: Capítulos 40, 54, 55, 58, 59.
Grau de Atendimento Declarado: Atende integralmente.
65.8.2 Item 4.2 — Atuação Conjunta com Outras Organizações
Requisito: Comprovar experiência em atuação conjunta com outras organizações.
Forma de Comprovação: atestado, contrato ou declaração.
Critério de Avaliação: será considerado atendido mediante evidência de atuação em projetos colaborativos.
Peso: 2.
Evidência de Atendimento:
O modelo operacional da parceria é explicitamente colaborativo: a PRODEMGE atua como gestora da parceria, responsável pelo N1 de suporte, pelo relacionamento com os órgãos e pela governança do contrato; a parceira tecnológica atua como responsável pela plataforma, pelos níveis N2 e N3 de suporte, pela evolução tecnológica e pela operação de infraestrutura. Essa divisão, detalhada na Matriz de Responsabilidades (Capítulo 61), pressupõe capacidade de coordenação contínua entre duas organizações com responsabilidades distintas e complementares.
A Governança da Parceria e da Plataforma (Capítulo 56) estrutura os ritos formais de colaboração: reuniões de gestão, instâncias de decisão, fluxos de escalação de decisões, e mecanismos de resolução de divergências. A Gestão de Projetos e Entregas (Capítulo 57) define como ciclos de desenvolvimento e implantação são gerenciados em ambiente compartilhado, com visibilidade mútua sobre cronogramas, riscos e impedimentos.
A natureza multi-tenant da plataforma adiciona uma dimensão adicional à atuação conjunta: a parceria não é binária entre parceira tecnológica e PRODEMGE — ela se expande para incluir cada órgão participante como ator com necessidades, prioridades e ritmos próprios. A capacidade de coordenar com múltiplos órgãos simultaneamente, mantendo coerência da plataforma e atendendo às particularidades de cada tenant, é evidência de maturidade para atuação em ambientes colaborativos complexos.
Referências neste documento: Capítulos 30, 56, 57, 61.
Grau de Atendimento Declarado: Atende integralmente.
65.8.3 Item 4.3 — Aptidão para Parceria e Compartilhamento de Riscos
Requisito: Declarar aptidão para atuação em modelo de parceria e compartilhamento de riscos.
Forma de Comprovação: declaração formal.
Critério de Avaliação: será considerado atendido mediante apresentação de declaração formal assinada.
Peso: 2.
Evidência de Atendimento:
A plataforma, sua arquitetura e seu modelo operacional foram concebidos para o modelo de parceria pública-privada com risco compartilhado proposto pela PRODEMGE no Chamamento CP001/2026. Esse modelo implica que a remuneração da parceira está vinculada aos resultados da plataforma e ao volume de órgãos atendidos — não a entregas pontuais de projeto.
A Gestão de Riscos (Capítulo 60) documenta a metodologia de identificação, avaliação e mitigação de riscos da plataforma, incluindo riscos tecnológicos, operacionais e de parceria. A estrutura de governança (Capítulo 56) define os processos de decisão compartilhada sobre questões que afetam ambas as partes.
O compartilhamento de riscos tecnológicos é evidenciado pelo modelo de custódia de código (Capítulo 58): o código-fonte permanece acessível à PRODEMGE em repositório compartilhado, eliminando o risco de lock-in tecnológico. O modelo de operação em infraestrutura não proprietária (Capítulo 37) garante portabilidade entre provedores de nuvem, eliminando dependência singular de fornecedor de infraestrutura.
A declaração formal de aptidão para atuação em modelo de parceria e compartilhamento de riscos será apresentada em documento autônomo, assinado por representante legal da empresa, em conformidade com o requisito do Anexo IV.
Referências neste documento: Capítulos 37, 56, 58, 60.
Grau de Atendimento Declarado: Atende integralmente.
65.8.4 Consolidação do Bloco 4
| Item | Descrição | Peso | Grau de Atendimento | Pontuação |
|---|---|---|---|---|
| 4.1 | Evolução contínua da solução | 2 | Atende integralmente | 2,0 |
| 4.2 | Atuação conjunta com outras organizações | 2 | Atende integralmente | 2,0 |
| 4.3 | Aptidão para parceria e compartilhamento de riscos | 2 | Atende integralmente | 2,0 |
| Subtotal Bloco 4 | 6 | 6,0 |
65.9 Consolidação Geral do Anexo IV
A tabela a seguir consolida a pontuação declarada em todos os blocos do Anexo IV.
| Bloco | Descrição | Peso Estratégico | Peso Total | Pontuação Declarada |
|---|---|---|---|---|
| 1 | Experiência em Soluções Digitais | Muito Alto | 15 | 15,0 |
| 2 | Experiência em Contextos Complexos e/ou Setor Público | Médio | 9 | 9,0 |
| 3 | Capacidade de Implantação, Operação e Escala | Alto | 12 | 12,0 |
| 4 | Capacidade de Atuação em Parceria | Baixo | 6 | 6,0 |
| Total | 42 | 42,0 |
Todos os 12 itens do Anexo IV são declarados como atendidos integralmente. A pontuação autodeclarada é 42,0 pontos, equivalente ao máximo possível no instrumento.
65.10 Mapa de Rastreabilidade — Itens do Anexo IV e Capítulos
A tabela a seguir mapeia cada item do Anexo IV aos capítulos deste documento que contêm a evidência de atendimento.
| Item Anexo IV | Descrição Resumida | Capítulos Primários | Capítulos de Suporte |
|---|---|---|---|
| 1.1 | Múltiplos módulos integrados | 10, 12, 18, 19, 20 | 13, 14, 21, 23, 24, 25, 26 |
| 1.2 | Integração por APIs | 14, 12, 13 | 43, 71, 72 |
| 1.3 | Dados, automação e inteligência | 16, 23, 24 | 15, 19, 21, 36 |
| 2.1 | Múltiplos usuários e sistemas | 28, 29, 30, 14 | 12, 61 |
| 2.2 | Ambientes regulados ou setor público | 44, 45, 43 | 14, 20 |
| 2.3 | Atendimento digital de usuários | 25, 26, 21, 16 | 18, 27 |
| 3.1 | Implantação em produção | 48, 40, 38, 39 | 34, 49, 50, 58 |
| 3.2 | Operação e sustentação contínua | 51, 52, 53 | 41, 61 |
| 3.3 | Operação em escala | 12, 38, 35, 13 | 15, 36, 34 |
| 4.1 | Evolução contínua | 54, 55, 40 | 58, 59 |
| 4.2 | Atuação conjunta com organizações | 56, 57, 61 | 30, 60 |
| 4.3 | Parceria e compartilhamento de riscos | 56, 58, 60 | 37, 61 |
65.11 Justificativas Técnicas das Decisões
A decisão de declarar todos os itens como "Atende integralmente" não é maximização oportunista da pontuação — é consequência da abrangência real da plataforma. O critério de aceitação de cada item do Anexo IV foi examinado contra a documentação existente nos capítulos correspondentes. Em cada caso, o critério mínimo exigido pelo Anexo IV é superado pela profundidade do que a plataforma implementa.
O item 1.1 exige "no mínimo, 2 componentes funcionais integrados". A plataforma possui 18 grupos funcionais integrados por contratos de eventos e APIs — a margem em relação ao critério mínimo é substancial.
O item 1.2 exige "evidência de integração sistêmica com uso de APIs". A plataforma documenta contratos OpenAPI por serviço, padrões de eventos por domínio, e integrações com oito sistemas externos distintos — cada um com protocolo e autenticação próprios.
O item 2.2 exige "comprovação de atuação em ambiente público ou regulado". A plataforma implementa LGPD por design, integra GOV.BR e SEI!MG, e opera dentro do ecossistema digital do governo estadual de Minas Gerais.
O item 3.3 exige "evidência de operação com volume relevante de usuários ou transações". A arquitetura de escala — HPA no Kubernetes, cache Redis com TTL por tipo de dado, RabbitMQ como buffer de absorção, banco vetorial separado do banco relacional — demonstra capacidade de escala não pela afirmação de que a plataforma escala, mas pela evidência de como cada componente contribui para isso.
65.12 Trade-offs
O modelo de avaliação do Anexo IV por autodeclaração com validação independente cria um trade-off entre profundidade e verificabilidade. Declarações mais detalhadas exigem evidências mais detalhadas; evidências mais detalhadas requerem mais esforço de validação pela PRODEMGE. Este capítulo resolve esse trade-off direcionando cada declaração a um capítulo específico deste documento, onde a evidência pode ser verificada com precisão.
O trade-off entre generalidade e especificidade na documentação de capacidades também é relevante: capacidades descritas de forma muito genérica são difíceis de validar; capacidades descritas com excesso de especificidade técnica podem obscurecer a essência do que está sendo demonstrado. As seções deste capítulo buscam o equilíbrio: referenciam o detalhe técnico sem reproduzi-lo, mantendo foco no critério de aceitação do Anexo IV.
65.13 Alternativas Descartadas e Razões
Uma abordagem alternativa seria apresentar um capítulo de qualificação com referências externas (atestados, contratos com clientes anteriores) como evidência principal de capacidade. Essa abordagem foi descartada porque: primeiro, a documentação técnica interna deste Documento Mestre é mais específica ao objeto da parceria do que referências genéricas de projetos anteriores; segundo, a PRODEMGE pode verificar as evidências nos capítulos referenciados sem depender de documentos externos; terceiro, a consistência entre o que é declarado aqui e o que está documentado nos capítulos técnicos demonstra coerência interna da proposta.
Outra alternativa seria a apresentação de evidências apenas nos itens de maior peso estratégico (Blocos 1 e 3). Essa abordagem foi descartada porque o Anexo IV avalia todos os blocos, e omissões em blocos de menor peso podem gerar dúvidas sobre a capacidade geral da interessada.
65.14 Riscos e Mitigações
Risco: a validação técnica pela PRODEMGE pode interpretar os critérios de aceitação de forma mais restrita do que a leitura da interessada. Mitigação: cada seção deste capítulo cita o critério de aceitação exato conforme redigido no Anexo IV, elimina ambiguidades terminológicas e referencia o capítulo onde a evidência está documentada em detalhe — facilitando a verificação independente.
Risco: mudanças na equipe de avaliação da PRODEMGE podem resultar em interpretações inconsistentes entre itens do mesmo bloco. Mitigação: o capítulo é estruturado de forma sistemática, com o mesmo formato para todos os itens, reduzindo a subjetividade da avaliação.
Risco: a declaração de atendimento integral em todos os itens pode ser percebida como falta de autocrítica. Mitigação: as seções de trade-offs e justificativas técnicas demonstram que a declaração é fundamentada em evidências documentais verificáveis, não em maximização estratégica de pontuação.
65.15 Benefícios
A estruturação deste capítulo como mapa entre os requisitos do Anexo IV e os capítulos do Documento Mestre produz três benefícios concretos para o processo de qualificação.
Para a PRODEMGE: o trabalho de validação é simplificado. Cada item do Anexo IV aponta para capítulos específicos onde a evidência pode ser verificada. Não é necessário ler o documento inteiro para validar um item — o avaliador navega diretamente ao ponto relevante.
Para a parceria: a rastreabilidade entre capacidades declaradas e documentação técnica cria um registro permanente do que foi comprometido na qualificação. Ao longo da vigência da parceria, esse registro serve como referência para avaliar se as capacidades estão sendo exercidas conforme declarado.
Para a proposta em si: a demonstração sistemática de atendimento ao Anexo IV, com referências precisas e critérios citados literalmente, diferencia esta proposta de declarações genéricas que não podem ser verificadas de forma objetiva.
65.16 Impactos Arquiteturais
O Capítulo 65 não gera impactos arquiteturais diretos — ele documenta e referencia capacidades já descritas nos capítulos técnicos. Seu impacto é documental: organiza a evidência de atendimento de forma que possa ser verificada de modo eficiente e sem ambiguidade.
A estrutura do mapa de rastreabilidade (seção 65.10) tem impacto na manutenção do documento: qualquer alteração nos capítulos referenciados deve ser avaliada quanto ao seu efeito sobre as declarações deste capítulo. Se uma decisão arquitetural nos capítulos de tecnologia, operação ou gestão alterar o grau de atendimento a um item do Anexo IV, o correspondente grau declarado aqui deve ser atualizado.
65.17 Integrações com Outros Componentes
Este capítulo integra-se com toda a Parte IX — Qualificação PRODEMGE. O Capítulo 64 (Atendimento ao Anexo III) e o Capítulo 66 (Atendimento ao Anexo V) seguem estrutura análoga. O Capítulo 67 (Matriz Completa de Aderência e Rastreabilidade) consolida os três instrumentos em uma visão unificada, permitindo que a PRODEMGE visualize, em um único quadro, como a proposta atende ao conjunto de requisitos do chamamento.
65.18 Relacionamento com Outros Capítulos
O relacionamento deste capítulo com os demais é de referência unidirecional: este capítulo aponta para os capítulos técnicos como evidência; os capítulos técnicos existem independentemente deste capítulo e não o referenciam. A rastreabilidade inversa — dos capítulos técnicos para os itens do Anexo IV — é construída nas seções de Rastreabilidade PRODEMGE de cada capítulo.
Os capítulos com maior densidade de referências neste documento são: Capítulo 12 (Arquitetura de Microsserviços), que evidencia múltiplos itens dos Blocos 1 e 3; Capítulo 16 (Arquitetura de Inteligência Artificial), que evidencia os itens de dados e inteligência; Capítulo 52 (Sustentação e Suporte Técnico), que evidencia o item 3.2; e Capítulo 56 (Governança da Parceria), que evidencia o Bloco 4.
65.19 Referências Internas
- Capítulo 10 — Arquitetura Funcional: visão dos 18 grupos funcionais integrados
- Capítulo 12 — Arquitetura de Microsserviços: contratos de serviço, APIs e eventos por módulo
- Capítulo 13 — Arquitetura de Mensageria: padrão de eventos RabbitMQ e integração entre serviços
- Capítulo 14 — Arquitetura de APIs e Integrações: integrações externas e padrões de API
- Capítulo 16 — Arquitetura de IA, RAG e Automação: copiloto, RAG e inteligência aplicada
- Capítulo 23 — Analytics e Data Lake: capacidades analíticas e DATALAKE MG
- Capítulo 38 — Kubernetes e Orquestração: HPA e capacidade de escala de infraestrutura
- Capítulo 40 — DevSecOps e Entrega Contínua: pipeline CI/CD e deploy progressivo
- Capítulo 44 — LGPD e Proteção de Dados: conformidade com ambiente regulado
- Capítulo 48 — Implantação e Onboarding de Tenants: processo de implantação em produção
- Capítulo 52 — Sustentação e Suporte Técnico: estrutura N1/N2/N3 e sustentação contínua
- Capítulo 56 — Governança da Parceria: modelo de colaboração e compartilhamento de riscos
65.20 Resumo
O Capítulo 65 demonstra o atendimento integral da plataforma a todos os 12 itens do Anexo IV do Chamamento CP001/2026. A pontuação autodeclarada é 42,0 pontos sobre 42 possíveis. O Bloco 1 (Experiência em Soluções Digitais) é evidenciado pela arquitetura de 18 grupos funcionais integrados, pelas integrações com oito sistemas externos por APIs e eventos, e pelas capacidades de analytics, automação BPM e inteligência artificial com RAG. O Bloco 2 (Contextos Complexos e Setor Público) é evidenciado pela arquitetura multi-tenant com múltiplos perfis de usuário, pela conformidade LGPD, pela integração com GOV.BR e SEI!MG, e pela oferta de atendimento digital por portal, aplicativo e chatbot. O Bloco 3 (Implantação, Operação e Escala) é evidenciado pelo processo estruturado de onboarding com pipeline CI/CD e Kubernetes, pela estrutura de suporte em três níveis com SLA formal, e pela arquitetura de escala com HPA, cache Redis e RabbitMQ. O Bloco 4 (Atuação em Parceria) é evidenciado pelo roadmap e modelo de evolução contínua, pela estrutura de governança colaborativa definida nos Capítulos 56 e 61, e pela declaração formal de aptidão para parceria com risco compartilhado.
65.21 Decisões Arquiteturais — ADR
| ADR | Decisão | Justificativa |
|---|---|---|
| ADR-CAP-001 | Evidências do Anexo IV referenciadas aos capítulos técnicos deste documento, não a documentos externos | Verificabilidade imediata pela PRODEMGE sem dependência de documentos não integrados à proposta |
| ADR-CAP-002 | Declaração de atendimento integral em todos os itens fundamentada em critérios literais do Anexo IV | Evita subjetividade na autodeclaração; cada grau de atendimento é derivado do critério exato, não de interpretação expansiva |
| ADR-CAP-003 | Mapa de rastreabilidade apresentado em tabela única na seção 65.10 | Facilita a navegação do avaliador sem exigir leitura sequencial do capítulo inteiro |
65.22 Próximo Capítulo
O Capítulo 66 — Atendimento à Sustentabilidade (Anexo V) apresenta a demonstração de atendimento aos critérios de sustentabilidade tecnológica definidos no Anexo V do Chamamento CP001/2026. O Anexo V representa 10% da pontuação total de qualificação técnica e avalia dimensões como manutenibilidade, segurança, interoperabilidade, continuidade e evolução tecnológica da plataforma.
65.23 Controle de Versão
| Campo | Valor |
|---|---|
| Documento | Documento Mestre — Plataforma de Relacionamento Digital com o Cidadão |
| Capítulo | 65 — Atendimento às Capacidades (Anexo IV) |
| Versão | 1.0 |
| Situação | Concluído |
| Última atualização | 17/07/2026 |
65.24 Rastreabilidade PRODEMGE
Edital CP001/2026:
- Critérios de qualificação técnica: o Anexo IV compõe 30% da pontuação de qualificação e este capítulo demonstra o atendimento integral a todos os seus itens.
Plano de Negócio (Anexo I):
- Seção 3 — Modelo de negócio e capacidades esperadas da parceira: os blocos do Anexo IV refletem as capacidades requeridas para viabilizar o modelo de negócio descrito no Plano.
- Seção 4 — Serviços e responsabilidades da parceira: implantação, operação, suporte e evolução contínua correspondem diretamente aos Blocos 3 e 4 do Anexo IV.
Funcionalidades (Anexo III) — impacto na pontuação de 60%:
- A demonstração de atendimento ao Bloco 1 do Anexo IV (módulos integrados, APIs, IA) é complementar ao Capítulo 64, que demonstra o atendimento funcional específico aos seis blocos do Anexo III.
Capacidades (Anexo IV) — impacto na pontuação de 30%:
- Todos os 12 itens dos 4 blocos do Anexo IV são cobertos neste capítulo com declaração de atendimento integral e referência às evidências documentais correspondentes.
Sustentabilidade (Anexo V) — impacto na pontuação de 10%:
- O Item 4.1 (evolução contínua) e o Item 3.2 (operação e sustentação) do Anexo IV têm sobreposição temática com os critérios de sustentabilidade do Anexo V, tratados no Capítulo 66.
Esclarecimentos pertinentes:
- Montreal Informática — Questionamento 8 — Mecanismo formal de apuração de responsabilidade antes da aplicação de penalidade: o modelo de suporte com SLA documentado (Item 3.2) é compatível com a diretriz de que desvios de nível de serviço seguem processo formal de análise antes de consequências contratuais.
- Madrona Advogados — Questionamento 18 — Confirmação de que nenhuma multa ou glosa é aplicada automaticamente: o processo de apuração de desvio de SLA descrito no Capítulo 53, referenciado no Item 3.2 deste capítulo, é compatível com essa diretriz.
Erratas:
- Errata nº 002 — não altera itens ou pesos do Anexo IV; não impacta este capítulo.
Capítulo 64 — Atendimento aos Requisitos Funcionais (Anexo III)
Este capítulo demonstra, de forma consolidada e rastreável, o atendimento integral da Plataforma de Relacionamento Digital com o Cidadão aos requisitos funcionais definidos no Anexo III do Chamamento Público nº 001/2026…
Capítulo 66 — Atendimento à Sustentabilidade (Anexo V)
Este capítulo demonstra o atendimento integral da Plataforma de Relacionamento Digital com o Cidadão aos requisitos de sustentabilidade definidos no Anexo V do Chamamento Público CP001/2026.