Diagnóstico Preliminar As-Is — Matriz de Riscos Consolidada¶
Riscos unificados das doze atas e da conversa de equipe de 11/07, ordenados por severidade, com duplicidades eliminadas e convergências indicadas. Severidade combina probabilidade e impacto conforme discutido nas sessões; onde a ata de origem atribuiu severidade, ela foi preservada. Ver também a matriz de achados e lacunas.
Distribuição por severidade
45 riscos consolidados
Fonte: 080-diagnostico/matriz-riscos-consolidada.md
Concentração por domínio
Onde os riscos se acumulam, por severidade
Acompanha o filtro abaixo · Fonte: 080-diagnostico/matriz-riscos-consolidada.md
Exibindo 45 de 45 registros
Clique numa severidade, aqui ou nos gráficos acima (fatia ou legenda), para filtrar as tabelas abaixo.
Críticos¶
| # | Sev. | Risco | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R01 | crítico | Dependência WAN inter-datacenter do G1 em produção, sem precedente e sem resiliência evidenciada por testes antes do go-live de 01/09. Latência interdatacenter confirmada em 60–70ms pela Ata 13 — corrobora o risco, não muda a severidade já crítica. | Infra / Telecom (D11) | Indisponibilidade ou degradação da operação G1 em falha ou latência da WAN. | Atas 01, 03, 05; corroborado pela Ata 13 |
| R02 | crítico | Ausência de estratégia de backup, replay e DR do barramento de eventos. | Barramento (D5) | Perda de eventos e impossibilidade de reconstruir estado após desastre. | Ata 10 |
| R03 | crítico | Failover incompleto da cadeia de dados: replicação presa ao site primário e continuidade do job de captura sem tratamento (convergência CV1). | CDC / Continuidade (D9, D11) | ADMS opera em contingência enquanto consumidores corporativos ficam sem dados. | Atas 05, 12 |
| R04 | crítico | Atualização do fornecedor quebra a materialização das views e a captura em produção, sem comunicação prévia de mudanças de esquema. | ADMS / CDC (D1) | Indisponibilidade de integrações e retrabalho emergencial a cada upgrade. | Ata 12 |
| R05 | crítico | Atraso de captura de 10 a 30 minutos nas tabelas de alta volumetria compromete processos operacionais de tempo quase real. | CDC / Dados (D9) | Decisões operacionais sobre estado defasado nos horários de pico. | Ata 12 |
| R06 | crítico | Contenção single-thread do adaptador ADMS sob crescimento de volume, com defeito de produto em aberto. | ADMS / OMS (D1) | Saturação do processamento de eventos em picos e em cenários de tempestade. | Atas 01, 08 |
| R07 | crítico | Tráfego interno ao cluster trafegando por rota externa (F5, firewall, API Gateway), adicionando latência, custo e pontos de falha desnecessários. | OpenShift / Rede (D6) | Falha em componente externo interrompe comunicação que deveria ser interna. | Ata 10 |
Altos¶
| # | Sev. | Risco | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R08 | alto | Dual write sem Outbox e ausência de correlation ID nos fluxos de incidentes. | CRM / Barramento (D3) | Divergência de estado entre sistemas e diagnóstico lento de falhas. | Ata 09 |
| R09 | alto | Janela de sincronização GIS-ADMS gera eventos tardios, duplicidades e incidentes com granularidade insuficiente. Figura original de "~12 horas" (Ata 06) já havia sido revista para "2-3h" verbal (extração) e "~8h" por screenshot operacional; follow-up de 31/08/2026 refina ainda mais: 2-3h é confirmado como média entre Unidades sem meta formal (dado real de 30 extrações: EMR≈54min/EMS≈1h53/ESS≈1h29), e a Etapa 3 (sincronização de ChangeSets) é manual, não roda no mesmo dia da importação, e não tem SLA definido — confirmado por escrito pela equipe do GIS ("não tenho conhecimento se foi definido um SLA para esta etapa"). É essa etapa manual sem SLA, não a extração em si, que hoje mais infla o tempo total de propagação e mais diretamente gera o risco de eventos tardios. Ver integracao-gis-adms.md, seção "Confirmações e achados novos (31/08/2026)". |
GIS / ADMS (D2) | Reaberturas, deslocamentos indevidos e perda de confiança na informação. | Ata 06, conv. 11/07; refinado por follow-up escrito, 31/08/2026 |
| R10 | alto | Carga full de equipes WFM com falhas, timeouts e ausência de confirmação (convergência CV2). Confirmado por evidência real em 29/08/2026 (log de gateway e de adapter, não mais só relato de sessão) — ver 030-artefatos/integracao-wfm-adms.md. |
WFM (D4) | Dessincronização de equipes entre WFM e ADMS em janelas críticas. | Ata 08; confirmado por evidência real (29/08/2026) |
| R11 | alto | Chaveamento manual multiequipe no F5 e monitores que não enxergam o serviço (convergência CV3). | F5 (D7) | Tempo de indisponibilidade elevado e tráfego direcionado a nós sem serviço. | Ata 05 |
| R12 | alto | APIs publicadas sem testes de contrato: quebras de compatibilidade chegam à produção. | API / Sensedia (D8) | Falhas em consumidores e retrabalho de backend após publicações. | Ata 05, conv. 11/07 |
| R13 | alto | Governança de eventos ausente: tópicos duplicados e eventos equivalentes multiplicando tráfego (convergência CV5). Confirmado com exemplo concreto no domínio WFM: tópico interno (wfm_ordem_servico) sem controle de assinatura — qualquer equipe pode assinar sem que o time produtor saiba, e uma mudança de schema já quebrou consumidor invisível. |
Barramento (D5) | Custo e processamento crescentes sem valor correspondente. | Ata 10; corroborado por reunião WFM/eForce, 12/08 — ver integracao-wfm-eforce-ordem-servico.md |
| R14 | alto | Consumidores frágeis pós-reinício, exigindo intervenção manual e induzindo a postergação de atualizações da plataforma. Confirmado ao vivo pelo desenvolvedor responsável pelo eForce (WFM): não existe DLQ em nenhuma fila do domínio — tratamento de erro é retry seguido de observação manual de log — classificado por ele mesmo como "problema crítico de infraestrutura". | Aplicações (D5) | Exposição prolongada a vulnerabilidades e dependência de operação manual. | Atas 04, 10; confirmado ao vivo em reunião WFM/eForce, 12/08 — ver integracao-wfm-eforce-ordem-servico.md |
| R15 | alto | Capacidade e licenciamento do barramento — resposta ao Bloco 2 (29/08/2026) soma ~79,6 a ~81,4 cores de CPU (limits por pod, três ambientes), abaixo da "ordem de 120 cores dedicados" da Ata 10; indício de que a cifra pode estar superestimada, não confirmação (limits de pod e reserva de core a nível de node podem não ser a mesma medida) — ver D6 e evidencias-producao-confluent-kafka.md seção F.2. |
OpenShift / Custo (D6) | Crescimento de custo sem remoção das causas estruturais. | Ata 10; resposta Bloco 2, 29/08/2026 |
| R16 | alto | Observabilidade ausente na OT e cobertura parcial (três de nove unidades) do APM. | Observabilidade (D10) | Demora para localizar falhas entre domínios e experiência desigual entre empresas. | Ata 11 |
| R17 | alto | Plataforma de logs com storage compartilhado: incidentes do ELK propagam para outros serviços. | Observabilidade (D10) | Indisponibilidade sistêmica a partir do ambiente de logs. | Ata 11 |
| R18 | alto | Telemetria de 151 aplicações em um único tópico, sem propriedade nem gestão de volumetria (convergência CV5). | Observabilidade (D10) | Custo, degradação e ausência de responsável identificável. | Ata 11 |
| R19 | alto | Dados pessoais potencialmente indexáveis no pipeline de logs e criptografia em trânsito incompleta na telemetria. | Segurança / LGPD (D10) | Incidente de conformidade e exposição de dados sensíveis. | Ata 11 |
| R20 | alto | Monitoramento do ambiente API-RADAR (Azure/Databricks) em revisão de arquitetura, mas sem PoC, precificação ou cronograma acordado com a equipe de Observabilidade; telemetria multicloud segue não consolidada (atualizado 28/08/2026 — descrição original "sem monitoramento previsto" não é mais precisa, ver nota metodológica e monitoramento-observabilidade-adms.md). ⚠ candidato a elevação — a Ata 14 confirma, de forma independente, que esse mesmo elo (integração ambiente-próprio↔nuvem) é ponto único de falha da cadeia regulatória e operacional; ver nota metodológica. |
Observabilidade (D10, D12) | Pontos cegos em dados e aplicações na nuvem. | Ata 11; corroborado pela Ata 14; atualizado por resposta ao Bloco 11 (28/08/2026) |
| R21 | alto | Procedimentos customizados da cadeia de captura sem responsável formal, SLA ou ciclo de vida (convergência CV5). | CDC / Governança (D1, D9) | Sustentação dependente de pessoas específicas e resposta lenta a falhas. | Ata 12 |
| R22 | alto | Mudança de esquema pode causar perda silenciosa de dados entre origem e consumidores. ⚠ candidato a elevação — a Ata 14 registra o mesmo padrão de falha (schema breaking sem contrato, detecção reativa) atravessando uma segunda cadeia de dados independente (data lake); ver nota metodológica. | CDC / Dados (D1, D9) | Divergência de dados detectada tardiamente, sem alerta de desvio. | Ata 12; corroborado pela Ata 14 |
| R23 | alto | Consumidores de dados não identificados ou sem acordo de nível de serviço. | Dados / Governança (D9) | Impossibilidade de dimensionar e priorizar corretamente a cadeia de dados. | Ata 12 |
Médios¶
| # | Sev. | Risco | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R24 | médio | Comandos DDL não interpretados pelo conector interrompem a captura em operações rotineiras de banco. | CDC (D9) | Paradas de fluxo por manutenção comum de banco. | Ata 12 |
| R25 | médio | Duplicidade de leitura sobre as bases do ADMS por múltiplas ferramentas de integração. | Dados (D9) | Complexidade, custo operacional e pressão redundante sobre a fonte. | Ata 12 |
| R26 | médio | Dependência de componentes proprietários do fornecedor para as views e bibliotecas. | ADMS (D1) | Limitação das alternativas de replicação e acoplamento ao produto. | Ata 12 |
| R27 | médio | Ciclo de versões do OpenShift e do operador Confluent defasado; atualização em curso, mas sem processo institucionalizado. | Plataforma (D6) | Exposição a vulnerabilidades e upgrades acumulados de maior risco. | Ata 10 |
| R28 | médio | Schema Registry parcial e divergência de esquemas entre empresas do grupo. | Barramento (D5) | Incompatibilidades silenciosas entre produtores e consumidores. | Atas 04, 09 |
| R29 | médio | Retenção de logs de quinze dias em produção e resposta a incidentes predominantemente manual. Mesma causa-raiz de governança (retenção definida por conveniência de custo/storage, não por criticidade) reaparece na retenção de sete dias da área de aterrissagem do data lake — ver R37. | Observabilidade (D10) | Perda de evidência forense e tempo de recuperação elevado. | Ata 11 |
| R30 | médio | Requisitos "real-time" sem formalização de SLA de negócio direcionam custo de Databricks e streaming sem necessidade comprovada (convergência CV4). | Dados / Custo (D9, D4, D10) | Custo estrutural elevado para requisitos que tolerariam batch ou micro-batch. | Conv. 11/07, Atas 11, 12 |
Riscos adicionais propostos (Atas 13 e 14 — fora da consolidação v1.10)¶
Diferente de R01–R30, que passaram pela consolidação e eliminação de duplicidade das doze Atas originais, os itens abaixo são propostos nesta revisão (04/08/2026) diretamente a partir das severidades já atribuídas pelas próprias Atas 13 (seção 1.14.11) e 14 (seção 1.15.16) em suas tabelas de risco. Não passaram por rodada de validação — tratar como entrada de trabalho para a próxima consolidação formal, não como risco confirmado no mesmo grau que R01–R30. Dois achados das Atas 13 e 14 propositalmente não geraram linha nova aqui — a resiliência da integração ambiente-próprio↔nuvem e a evolução de esquema no data lake — porque já são tratados como corroboração de R20 e R22 acima, respectivamente, para não duplicar o mesmo risco sob dois números. Itens de severidade Média mais operacionais da Ata 14 (custo de processamento, disparo integrado da camada de visualização, padronização de documentação arquitetural) também ficaram de fora por serem de impacto mais restrito à própria equipe de dados — podem ser incorporados na consolidação formal se a validação com as áreas indicar relevância maior.
| # | Risco | Severidade (Ata de origem) | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R31 | Conector de captura (Debezium) roda no OpenShift corporativo, distante do banco de origem no ambiente operacional — achado ainda não formalizado como linha em D9. | alta | CDC (D9) | Maior sensibilidade a variações de rede, atraso na captura e dificuldade de recuperação após interrupções — soma-se às causas já registradas em R05. | Ata 13 |
| R32 | Replicação do banco corporativo entre sites via Data Guard, sem modo de proteção nem transporte (síncrono/assíncrono) confirmados. | alta | Continuidade (D11) | Objetivo de ponto de recuperação desconhecido; possível perda ou defasagem de dados em failover. | Ata 13 |
| R33 | Testes de recuperação de desastre dos sistemas corporativos restritos a ambiente isolado ("bolha"); nunca houve chaveamento integral de produção. RTO declarado de 24h (sessão de DR) não tem essa cobertura exercitada. | alta | Continuidade (D11) | Dependências reais — resolução de nomes, rotas, autenticação, integrações — podem não estar sendo exercitadas. | Ata 13; sessão de DR (03/08) |
| R34 | Entrada em produção do OMS (01/09) sem critérios objetivos de aceite de integração definidos. | alta | G1 / Integrações | Problemas de desempenho ou continuidade podem só se manifestar após o go-live, sem gate prévio para barrá-los. | Ata 13 |
| R35 | Ocupação dos enlaces interdatacenter sem linha de base formal — números variam entre menos de 50% e 70% conforme o critério de medição. | média | Rede / Telecom (D11) | Decisões sobre margem de capacidade apoiadas em números divergentes; risco de saturação não percebida. | Ata 13 |
| R36 | Segmentação entre redes TI e OT apoiada apenas em identificador de VLAN, até a conclusão do projeto de interconexão de data centers (migração prevista até março de 2027). | média | Rede / Segurança | Limitações de isolamento e governança entre os dois domínios de rede durante toda a janela de implantação do G1 e G2. | Ata 13 |
| R37 | Retenção uniforme de sete dias na área de aterrissagem do data lake, sem diferenciação por criticidade; caso concreto de perda de dados já ocorrido por reprocessamento solicitado fora da janela. | alta | Dados / Data Lake (D12) | Impossibilidade de reprocessar incidentes descobertos tardiamente, inclusive em fluxos regulatórios. | Ata 14 |
| R38 | Ausência de framework formal de qualidade de dados (completude, validade, consistência, quarentena) no data lake. | alta | Dados / Data Lake (D12) | Pipeline pode concluir com sucesso enquanto o dado publicado está semanticamente incorreto — inclusive em API regulatória com penalidade por atraso ou erro. | Ata 14 |
| R39 | Ausência de idempotência nos consumidores de eventos do data lake; conectores sem mecanismo de reconstrução de estado além da janela de retenção. Segunda ocorrência independente da lacuna já registrada em R08 (Ata 09). | alta | Dados / Data Lake (D12) | Reenvio de dados corrigidos cria risco de duplicidade; recarga histórica indisponível fora da janela de sete dias. | Ata 14 |
| R40 | Upgrade de licenciamento Oracle para replicação de grande volume estimado em cerca de R$ 6 milhões, considerado inviável para um único projeto. | média | Dados / Custo | Fluxos que dependem dessa capacidade recorrem a releituras históricas volumosas, elevando custo e carga sobre o ambiente de origem. | Ata 14 |
| R41 | Serviço de gravação em Go, desenvolvido sob pressão de prazo regulatório para substituir conector comercial não adquirido a tempo, mantido em produção sem propriedade formal. | alta | Dados / Governança (D12) | Mesmo padrão de risco já registrado para a materialização de views do ADMS (R26, Ata 12) — componente crítico sem dono nem sustentação formal. | Ata 14 |
Riscos adicionais propostos (evidência de produção real — 05/08/2026, fora da consolidação v1.10)¶
Diferente de R01–R41, este item não vem de uma Ata, mas da leitura direta de relatórios reais do Confluent Control Center/Kafka Connect e de payloads de evento reais fornecidos pelo cliente, analisados em
030-artefatos/evidencias-producao-confluent-kafka.md. Não passou por rodada de validação com as áreas — tratar como entrada de trabalho, no mesmo grau de maturidade que R31–R41, não como risco confirmado.
| # | Risco | Severidade (proposta) | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R42 | Dados pessoais (CPF, telefone) trafegando em texto puro em tópicos operacionais de CRM (ex.: crm_chamada_ocorrencia_tecnica) sem Schema Registry nem contrato formal, sem mascaramento nem controle de acesso por schema. |
alta | CRM / LGPD (D3) | Exposição de dado pessoal sem trilha de governança; qualquer consumidor do tópico recebe o dado sem filtro. | Análise de payload real de produção, 05/08/2026 |
Riscos adicionais propostos (wiki técnica interna da Energisa — 08/08/2026, fora da consolidação v1.10)¶
Diferente de R01–R42, este item vem da leitura direta de duas páginas da wiki técnica interna da Energisa (devops.energisa.com.br, Canais Digitais) fornecidas pelo cliente em 08/08/2026 — não de uma Ata nem de evidência de produção. Não passou por rodada de validação com as áreas — tratar como entrada de trabalho, no mesmo grau de maturidade que R31–R42, não como risco confirmado. Ver
030-artefatos/fluxos-atendimento-adms.md, seção "Achado novo — caminho duplo ADMS/RabbitMQ".
| # | Risco | Severidade (proposta) | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R43 | Abertura de ocorrência técnica bifurca por distribuidora conforme o parâmetro global 70 do SIATT: quem ainda não migrou para o ADMS segue por um caminho legado (RabbitMQ → sistema MSGOT) sem nenhuma cobertura documental em ata, artefato ou diagrama deste assessment. | alta | G1 / Integrações | Sem inventário de quantas distribuidoras ainda dependem do caminho legado nem processo formal de corte/decomissionamento do MSGOT, uma falha de configuração do parâmetro 70 ou uma distribuidora não migrada corretamente pode passar despercebida durante a janela de rollout do G1. | Wiki técnica Energisa — "Abertura de Ocorrência Técnica pelo ADMS - Overview" (Canais Digitais), fornecida em 08/08/2026 |
Riscos adicionais propostos (transcrição de reunião DevOps — 08/08/2026, fora da consolidação v1.10)¶
Diferente de R01–R43, este item vem da leitura direta da transcrição (VTT) da sessão de DevOps de 06/08/2026, sem Ata consolidada correspondente ainda — ver
010-evidencias/160-devops-pipeline-seguranca.mde030-artefatos/devops-pipeline-confluent-kafka.md. Não passou por rodada de validação com as áreas — tratar como entrada de trabalho, no mesmo grau de maturidade que R31–R43, não como risco confirmado.
| # | Risco | Severidade (proposta) | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R44 | Criação de streams e queries do ksqlDB é feita manualmente direto no Confluent Control Center, fora do pipeline automatizado de CI/CD que cobre os demais componentes do Barramento — sem Pull Request, revisão de código, aprovação de Gestão de Mudanças ou versionamento equivalente. Motivo declarado: ausência de solução suportada pela Confluent para esse tipo de objeto; confirmado por Castellani em 08/08/2026 que o gap persiste na versão da Confluent atualmente utilizada pela Energisa. | média | DevOps / Barramento (D5, D6) | Mudanças em streams/queries de produção sem trilha de auditoria, sem peer review e sem rollback via pipeline; risco cresce em relevância junto com o volume de estruturas ksqlDB já mapeado na Ata 04 (seção KSQLDB e consolidação multiempresa — estimativa de centenas a mil estruturas). | Transcrição de reunião DevOps, 06/08/2026; confirmação de Castellani, 08/08/2026 |
Riscos adicionais propostos (síntese analítica cruzada de artefatos — 08/08/2026, fora da consolidação v1.10)¶
Diferente de R01–R44, este item não vem de uma nova sessão, Ata, evidência de produção ou documento fornecido pelo cliente — é uma lacuna identificada por leitura cruzada de artefatos já publicados deste assessment (
030-artefatos/dominio-funcional-adms.md,030-artefatos/integracao-gis-adms.mde030-artefatos/business-model-canvas.md) confrontada com a arquitetura de aquisição de dados de campo descrita no manual técnico do fabricante (Anexo A — Manual Técnico do EcoStruxure ADMS 3.8, seção 5 "SCADA"), a pedido de Castellani em 08/08/2026. Não passou por rodada de validação com as áreas — tratar como pergunta a levantar, no mesmo grau de maturidade que R31–R44, não como risco confirmado.
| # | Risco | Severidade (proposta) | Domínio | Impacto principal | Origem |
|---|---|---|---|---|---|
| R45 | A única relação de entrada de dados no SCADA documentada em todo o assessment é Automação de campo → SCADA (dominio-funcional-adms.md), e esse componente está classificado no próprio diagrama como "fora de escopo do projeto ADMS". Não há inventário de protocolo de campo (DNP3 / IEC 104 / IEC 101 / Modbus — únicos suportados pelo produto conforme o manual do fabricante), de quantidade/localização de RTUs e IEDs, nem confirmação de como e se os SCADAs legados por fornecedor/regional (Siemens — EPB/ESE/EMG, e EFACEC — EMS, citados em business-model-canvas.md como parte da meta "de 6 fornecedores para 1") estão em cutover para o SCADA do ADMS, e sob qual modelo de transição (RTU de porta dupla, listen-only, ou integração ICCP entre sistemas — os três modelos que o próprio manual do fabricante descreve como possíveis, sem que nenhum artefato do assessment confirme qual foi adotado). O G1 já está em operação com "SCADA recém implantado" (rede-telecom-adms.md), o que torna essa lacuna atual, não apenas prospectiva. |
alta | ADMS / SCADA (D1) | Durante uma janela de cutover sem modelo confirmado, pontos de telemetria de campo podem ficar órfãos (fora do sistema legado e ainda não reconhecidos pelo novo) ou operar em modo dual sem que a operação saiba qual sistema tem a informação válida no momento — mesmo padrão de risco de continuidade operacional de R33/R34, aqui na camada de aquisição de dados de campo em vez de rede ou critério de aceite de integração. | Síntese analítica cruzada de dominio-funcional-adms.md, integracao-gis-adms.md, business-model-canvas.md e Anexo A (Manual Técnico EcoStruxure ADMS 3.8), a pedido de Castellani, 08/08/2026 |
Nota metodológica¶
A severidade de R03 foi elevada de alta (classificação isolada da Ata 12) para crítica na visão consolidada, porque a convergência com o gap de failover do CDC identificado na Ata 05 mostra que o problema atravessa toda a cadeia de dados e coincide com o cenário de contingência do G1. Elevações ou rebaixamentos como esse estão sinalizados e devem ser confirmados na rodada de validação.
Propostas de elevação em aberto (revisão de 04/08/2026, pendentes de validação — não decididas unilateralmente por esta consultoria):
- R20 (observabilidade ausente em Azure/Databricks, Ata 11) tem hoje uma segunda fonte independente — a Ata 14 — confirmando que o mesmo componente (integração ambiente-próprio↔nuvem) é "ponto único de falha" para toda a cadeia analítica e regulatória, na formulação da própria equipe de dados. É o mesmo padrão de evidência que justificou elevar R03: duas sessões distintas, ângulos diferentes (observabilidade vs. resiliência), mesmo componente crítico. Candidato a elevação de Alto para Crítico.
- R22 (mudança de esquema causa perda silenciosa de dados, Ata 12) tem o mesmo padrão de falha — quebra sem contrato, detecção reativa — confirmado de forma independente pela Ata 14 do lado do data lake, uma cadeia de dados distinta da que originou o achado em D1/D9. Candidato a virar uma sexta convergência transversal (CV6) na matriz de achados, com possível reavaliação de severidade.
Essas duas propostas foram deixadas como candidatas, não como decisão, seguindo a regra de ouro do assessment: divergências e reclassificações são levadas às áreas como questões de validação, nunca arbitradas pela consultoria.
Nota de revisão (28/08/2026): a resposta da Energisa ao Bloco 11 do questionário [R20] mostra que a premissa original ("sem monitoramento previsto") estava desatualizada — existe hoje uma iniciativa em revisão de arquitetura para o ambiente API-RADAR, com integração multicloud nativa disponível na plataforma (Datadog). A severidade foi mantida em Alto e a proposta de elevação para Crítico segue em aberto (não decidida nesta revisão): a existência de uma iniciativa embrionária, sem PoC, precificação ou cronograma acordado entre os times de Cloud/Dados e Observabilidade, não constitui mitigação concreta do ponto único de falha já confirmado pela Ata 14 — mas também não é mais correto descrever o risco como "nada previsto". Ver detalhamento em
030-artefatos/monitoramento-observabilidade-adms.md.Nota da migração (03/08/2026): esta matriz reflete o estado do assessment em 28/07 (base v1.10, Atas 01–12). As sessões de Rede/Telecom (Ata 13), Engenharia de Dados (Ata 14) e DR (sem Ata formal) trouxeram achados adicionais — notavelmente a assimetria de continuidade entre ADMS e sistemas corporativos e o ponto único de falha na integração com a nuvem — que ainda não foram incorporados a esta matriz consolidada. Ver
030-artefatos/rede-telecom-adms.md,030-artefatos/engenharia-dados-adms.mde030-artefatos/dr-adms-sistemas-corporativos.md.Nota de revisão (04/08/2026): esta revisão fez quatro alterações. Primeiro, anotou a referência de domínio (Dx) da matriz de achados em cada uma das trinta linhas originais, para rastreabilidade entre os dois documentos. Segundo, sinalizou R15 como número ainda não confirmado por inventário. Terceiro, abriu a seção "Riscos adicionais propostos" (R31–R41) transcrevendo as severidades já atribuídas pelas Atas 13 e 14 em suas próprias tabelas de risco. Quarto, registrou duas propostas de elevação por convergência (R20 e R22) seguindo o precedente metodológico já usado em R03, deixadas explicitamente como candidatas pendentes de validação. Nenhuma severidade de R01–R30 foi alterada nesta revisão.
Nota de revisão (05/08/2026): aberta uma segunda seção de "Riscos adicionais propostos", separada de R31–R41 porque a origem é diferente — análise direta de evidência de produção (relatórios reais + payloads reais), não uma Ata. Proposto R42 (PII em texto puro em tópico CRM sem Schema Registry). Nenhuma severidade de R01–R41 foi alterada nesta revisão.
Nota de revisão (08/08/2026): aberta uma terceira seção de "Riscos adicionais propostos", separada das anteriores porque a origem é, de novo, diferente — leitura direta de duas páginas da wiki técnica interna da Energisa, fornecidas pelo cliente. Proposto R43 (caminho duplo ADMS/RabbitMQ-MSGOT sem visibilidade documental, via parâmetro global 70 do SIATT). Nenhuma severidade de R01–R42 foi alterada nesta revisão.
Nota de revisão (08/08/2026 — sessão de DevOps): aberta uma quarta seção de "Riscos adicionais propostos", a partir da transcrição da sessão de DevOps de 06/08/2026. Proposto R44 (ksqlDB fora do pipeline automatizado de CI/CD — streams e queries criadas manualmente no Control Center). Nenhuma severidade de R01–R43 foi alterada nesta revisão.
Nota de revisão (08/08/2026 — confirmação de participantes e do gap): Castellani confirmou os quatro participantes da sessão de DevOps (Guilherme da Silva Lima, Cláudio Ferreira Carneiro, Norberto da Silva Prado, Rômulo Maini Pinto — ver
010-evidencias/160-devops-pipeline-seguranca.md) e confirmou que o gap de R44 (ksqlDB fora do pipeline) persiste na versão da Confluent atualmente utilizada pela Energisa — não foi endereçado por atualização recente. Severidade de R44 mantida em média; sem alteração de outras linhas.Nota de revisão (08/08/2026 — lacuna de aquisição de dados do SCADA): aberta uma quinta seção de "Riscos adicionais propostos", de origem diferente de todas as anteriores — não uma sessão nova nem documento fornecido pelo cliente, e sim leitura cruzada de artefatos já publicados (dominio-funcional-adms.md, integracao-gis-adms.md, business-model-canvas.md) confrontada com o manual técnico do fabricante, a pedido de Castellani. Proposto R45 (ausência de inventário de protocolo/RTU/IED e de modelo de cutover confirmado para o SCADA do ADMS). Severidade proposta como alta pela proximidade com o go-live do G1 (SCADA já implantado), seguindo o mesmo racional de R33/R34 — pendente de validação. Nenhuma severidade de R01–R44 foi alterada nesta revisão.
Nota de revisão (29/08/2026 — resposta da Energisa ao Bloco 2): a resposta ao Bloco 2 [E1] trouxe as versões exatas de OpenShift/Confluent por ambiente e os recursos dedicados (limits por pod, confirmados por recomputação contra o Totalizador declarado). A soma de CPU dos três ambientes (~79,6 a ~81,4 cores, conforme inclusão ou não de um componente temporário) fica abaixo dos "~120 cores dedicados" da Ata 10 — tratado como indício de que a cifra pode estar superestimada, não como confirmação ou refutação, porque limits de pod não são necessariamente a mesma medida que reserva de core a nível de node. Severidade de R15 mantida em Alto. Três novas perguntas de acompanhamento foram levantadas a partir desta resposta (divergência de versão de PRD no texto vs. tabela; duplicação Control Center/Control Center NG; se a cifra de "~120 cores" da Ata 10 é a mesma medida da soma de limits de CPU por pod calculada aqui) — ver
030-artefatos/evidencias-producao-confluent-kafka.md, seção F.