Casos de Uso — Avaliação de Maturidade ITGC em Plataforma de Dados
Cenários fictícios demonstrando como arquitetura, ferramentas e processos influenciam o resultado da avaliação de Controles Gerais de TI (ITGC).
Visão Gerencial — Comparativo dos Cenários
Maturidade ITGC dos 5 cenários sobreposta no radar. Passe o mouse sobre um cenário para destacá-lo no gráfico, ou clique para ir direto à análise detalhada.
Eixos:Lineage Data Lineage & MetadataQuality Data QualityAccess Access Control em Data PlatformClassif. Data Classification & Tratamento de SensíveisAI Gov. Model & AI GovernanceLifecycle Data Lifecycle & RetençãoSOx SOx · Dados Financeiramente Relevantes
Fintech early-stage de 35 colaboradores · Plataforma de dados em construção
Nível 1 — Inicial
Infográfico — Arquitetura & Ferramentas
Arquitetura
Data Lake improvisado em S3 com pastas por time. PostgreSQL replicado via dump manual. Análises em planilhas e notebooks isolados. Sem ambientes segregados (dev/prod compartilhados).
Ferramentas Base
AWS S3 (sem catalogação)
PostgreSQL on-prem
Jupyter local + Excel
Acessos via planilha compartilhada
Processos
Mudanças aplicadas direto em produção. Senhas compartilhadas entre devs. Backup ad-hoc. Sem registro formal de incidentes ou de aprovação de acesso.
Resultado provável da avaliação ITGC — Pergunta a Pergunta
Data Lineage & Metadata Reprovado
✗
Existe catálogo de dados centralizado documentando datasets críticos, schemas, owners e definições de negócio?Sem catálogo. Metadados vivem na cabeça dos analistas; descoberta de dataset por mensagem no Slack.
✗
Há rastreabilidade end-to-end (data lineage) das fontes de origem aos consumidores finais — relatórios, dashboards e modelos?Lineage construído na unha quando há incidente; impossível responder "de onde vem este número" em < 1 dia.
✗
Mudanças em schema de tabelas/datasets críticos seguem processo de impact analysis e comunicação prévia aos consumidores downstream?Schema é alterado direto na origem; analistas descobrem a quebra quando o notebook erra.
Data Quality Reprovado
✗
Existem regras de qualidade definidas (completude, validade, consistência, timeliness) com monitoramento automatizado em datasets críticos?Qualidade verificada no olho — quando o número parece estranho. Sem regras escritas.
✗
Há processo formal de tratamento de incidentes de qualidade de dados com SLA, responsável e RCA?Incidente tratado de forma reativa pelo analista que viu primeiro; sem ticket nem RCA.
✗
Métricas de qualidade são reportadas a stakeholders de negócio com dashboards, tendências e thresholds aceitáveis?Negócio só descobre problema quando o relatório está visivelmente errado.
Access Control em Data Platform Reprovado
✗
O acesso a dados sensíveis em data lake/warehouse usa RBAC ou ABAC granular, distinto de acessos a sistemas transacionais?IAM básico do AWS reutilizado de forma genérica; sem RBAC granular para data lake.
✗
Há revisão periódica de acessos (recertificação) específica para a plataforma de dados, com evidência arquivada?Nunca houve recertificação de acessos. Lista vive em planilha desatualizada há mais de 12 meses.
✗
Existe segregação de funções entre quem ingere, transforma e consome dados sensíveis (SoD em pipeline)?Sem SoD: o mesmo dev ingere, transforma e consome. Senhas root compartilhadas via Notion.
Data Classification & Tratamento de Sensíveis Reprovado
✗
Datasets com PII/PHI/financeiros sensíveis são identificados e classificados conforme política corporativa e regulação aplicável (LGPD, SOx, PCI)?PII em texto puro em planilhas, dumps de Postgres e CSVs por e-mail. Sem inventário de dados sensíveis.
✗
Dados sensíveis em ambientes de analytics passam por mascaramento, tokenização ou pseudonimização?Sem mascaramento. Dados de produção (incluindo CPF, e-mail) replicados como estão para análise.
✗
Há controle sobre exfiltração e exportação de dados sensíveis (downloads de BI, exports de notebook, cópias para storage pessoal)?Devs baixam datasets para o laptop sem barreira; cópias circulam em Drive pessoal.
Model & AI Governance N/A
✗
Modelos de ML/IA em produção têm registro formal (model registry) com versão, owner, propósito e dados de treinamento documentados?N/A — não há modelos de ML/IA em produção. Apenas SQL e dashboards.
✗
Modelos passam por validação independente antes de produção (fairness, robustez, drift, explainability) e revisão periódica?N/A — sem modelos ativos para validar.
✗
Há controle de acesso e auditoria sobre uso de modelos generativos/LLM corporativos, incluindo prompts e dados expostos?N/A — uso casual de ChatGPT pelos colaboradores sem política corporativa.
Data Lifecycle & Retenção Reprovado
✗
Existe política formal de retenção e descarte de dados por classe (operacional, financeiro, sensível, regulatório)?Sem política de retenção. Dados acumulam no S3 indefinidamente.
✗
Backups e snapshots de dados sensíveis seguem a mesma política de retenção e descarte da fonte primária?Snapshots manuais quando alguém lembra; sem alinhamento com retenção.
✗
Há evidência de execução do descarte (purge auditado) com trilha de auditoria, ao final do prazo legal/regulatório?Nunca houve descarte formal. "Dados velhos a gente decide depois".
SOx · Dados Financeiramente Relevantes Reprovado
✗
Datasets que alimentam demonstrações financeiras (DRE, BP, fluxo de caixa, KPIs auditados) estão identificados como SOx-relevantes?Empresa não pública / não SOx — mas dados financeiros não são identificados como críticos no fluxo.
✗
Pipelines que produzem números financeiros auditáveis têm controles de mudança (CAB, segregação dev/prod, evidência) similares aos sistemas SOx in-scope?Pipelines de dados financeiros não têm controle de mudança formal — qualquer dev altera.
✗
Há reconciliação automatizada entre dados financeiros no warehouse/lakehouse e o sistema-fonte (ERP, contábil), com evidência arquivada para auditor externo?Sem reconciliação. Confere-se "no olho" se o ERP e o dashboard batem.
Sem segregação de ambientes, credenciais compartilhadas e ausência de trilhas de auditoria, o auditor não consegue obter evidência mínima de controle. Resultado: deficiência material em todas as áreas, recomendando plano de remediação imediato antes da próxima auditoria.
Cenário 2 — Varejo MidMarket
Rede varejista com 800 colaboradores · BI consolidado, governança incipiente
Nível 2 — Gerenciado
Infográfico — Arquitetura & Ferramentas
Arquitetura
Snowflake como data warehouse central, ingestão via Fivetran a partir de ERP e e-commerce. Modelagem em dbt. Ambientes separados (dev/prod) embora com promoção manual.
Ferramentas Base
Snowflake + Fivetran + dbt
Power BI (workspaces por área)
Azure AD para SSO
Jira para tickets de mudança
Processos
Acessos concedidos via ticket no Jira, mas sem revisão periódica. Mudanças passam por PR no Git, mas merges feitos pelo próprio autor. Backup automático nativo, sem teste de restore documentado.
Resultado provável da avaliação ITGC — Pergunta a Pergunta
Data Lineage & Metadata Deficiência
!
Existe catálogo de dados centralizado documentando datasets críticos, schemas, owners e definições de negócio?Catálogo iniciado em Confluence cobrindo ~20% dos datasets críticos; schemas frequentemente defasados vs. produção.
!
Há rastreabilidade end-to-end (data lineage) das fontes de origem aos consumidores finais — relatórios, dashboards e modelos?Lineage documentado em diagramas Lucid para 3 fluxos críticos, desatualizados há ~6 meses; não chega ao Power BI.
✗
Mudanças em schema de tabelas/datasets críticos seguem processo de impact analysis e comunicação prévia aos consumidores downstream?Schema mudado por engenheiro com aviso por e-mail eventual; breaking change quebra dashboards de tempo em tempo.
Data Quality Deficiência
!
Existem regras de qualidade definidas (completude, validade, consistência, timeliness) com monitoramento automatizado em datasets críticos?Algumas regras dbt tests em datasets de vendas; cobertura inconsistente; sem alertas centralizados — só Slack.
!
Há processo formal de tratamento de incidentes de qualidade de dados com SLA, responsável e RCA?Incidentes registrados parcialmente no Jira, sem severidade definida; RCA superficial.
✗
Métricas de qualidade são reportadas a stakeholders de negócio com dashboards, tendências e thresholds aceitáveis?Negócio recebe e-mail eventual quando algo quebra; sem dashboard de DQ nem trend.
Access Control em Data Platform Deficiência
✓
O acesso a dados sensíveis em data lake/warehouse usa RBAC ou ABAC granular, distinto de acessos a sistemas transacionais?Sim. RBAC nativo do Snowflake + Power BI workspaces por área de negócio.
✗
Há revisão periódica de acessos (recertificação) específica para a plataforma de dados, com evidência arquivada?Não. Última revisão foi há 14 meses; sem ciclo formal de recertificação.
!
Existe segregação de funções entre quem ingere, transforma e consome dados sensíveis (SoD em pipeline)?Parcial. Devs também são owners dos workspaces de produção em Power BI; sem SoD na pipeline.
Data Classification & Tratamento de Sensíveis Deficiência
!
Datasets com PII/PHI/financeiros sensíveis são identificados e classificados conforme política corporativa e regulação aplicável (LGPD, SOx, PCI)?Inventário manual em planilha cobrindo bases CRM e fiscal; classificação não revisada há 18 meses.
✗
Dados sensíveis em ambientes de analytics passam por mascaramento, tokenização ou pseudonimização?Sem mascaramento. Dados de cliente (CPF, telefone) trafegam sem proteção entre Snowflake e Power BI.
!
Há controle sobre exfiltração e exportação de dados sensíveis (downloads de BI, exports de notebook, cópias para storage pessoal)?Política proibindo download de PII existe mas sem controle técnico — "confiamos no analista".
Model & AI Governance N/A
✗
Modelos de ML/IA em produção têm registro formal (model registry) com versão, owner, propósito e dados de treinamento documentados?N/A — sem modelos formais. Existe motor de recomendação contratado de fornecedor (caixa-preta).
✗
Modelos passam por validação independente antes de produção (fairness, robustez, drift, explainability) e revisão periódica?N/A — modelo de fornecedor não é validado internamente.
!
Há controle de acesso e auditoria sobre uso de modelos generativos/LLM corporativos, incluindo prompts e dados expostos?Uso de ChatGPT/Copilot pelos analistas sem política; alguns prompts contêm dados de cliente.
Data Lifecycle & Retenção Deficiência
!
Existe política formal de retenção e descarte de dados por classe (operacional, financeiro, sensível, regulatório)?Política de retenção esboçada mas não aprovada; só dados fiscais (5 anos) seguem regra clara.
✗
Backups e snapshots de dados sensíveis seguem a mesma política de retenção e descarte da fonte primária?Time Travel do Snowflake (7 dias default) não está alinhado a política de retenção da fonte.
!
Há evidência de execução do descarte (purge auditado) com trilha de auditoria, ao final do prazo legal/regulatório?Descarte fiscal anual executado via script; outras classes acumulam sem purge.
SOx · Dados Financeiramente Relevantes Reprovado
✗
Datasets que alimentam demonstrações financeiras (DRE, BP, fluxo de caixa, KPIs auditados) estão identificados como SOx-relevantes?Empresa não pública — SOx não aplica. Dados financeiros não são identificados como críticos no warehouse.
✗
Pipelines que produzem números financeiros auditáveis têm controles de mudança (CAB, segregação dev/prod, evidência) similares aos sistemas SOx in-scope?Pipelines de DRE não têm controle de mudança diferenciado — qualquer engineer altera.
!
Há reconciliação automatizada entre dados financeiros no warehouse/lakehouse e o sistema-fonte (ERP, contábil), com evidência arquivada para auditor externo?Reconciliação manual mensal Excel × ERP, sem evidência arquivada.
Existem controles, mas faltam ciclos de revisão e segregação de funções. Auditor classifica como deficiências significativas (não materiais): recomenda formalizar revisão trimestral de acessos, exigir aprovador distinto em PRs e documentar testes de restore.
Cenário 3 — Saúde Corporativa
Operadora de saúde com 4.500 colaboradores · Governança de dados formalizada
Nível 3 — Definido
Infográfico — Arquitetura & Ferramentas
Arquitetura
Lakehouse em Databricks (Bronze/Silver/Gold) com Unity Catalog. Ambientes dev/hml/prod isolados, IaC em Terraform. Catálogo de dados (Collibra) e classificação de PII automática.
Ferramentas Base
Databricks + Unity Catalog
Azure DevOps (CI/CD)
Collibra (catálogo)
ServiceNow (ITSM/CAB)
Okta + grupos por papel
Processos
Acessos por RBAC com revisão semestral. Mudanças passam por CAB com SoD entre dev/aprovador/deployer. Backups com testes anuais documentados. Logs centralizados em Splunk.
Resultado provável da avaliação ITGC — Pergunta a Pergunta
Data Lineage & Metadata Aceitável
✓
Existe catálogo de dados centralizado documentando datasets críticos, schemas, owners e definições de negócio?Sim. Collibra implementado com ~70% dos datasets críticos catalogados; stewards designados por domínio clínico/financeiro.
✓
Há rastreabilidade end-to-end (data lineage) das fontes de origem aos consumidores finais — relatórios, dashboards e modelos?Sim. Lineage automatizado captura ELT (ADF) e Power BI; cobertura validada em datasets clínicos críticos.
!
Mudanças em schema de tabelas/datasets críticos seguem processo de impact analysis e comunicação prévia aos consumidores downstream?Processo formal existe na stack moderna, mas integrações HL7/HIS legadas mudam sem impact analysis.
Data Quality Aceitável
✓
Existem regras de qualidade definidas (completude, validade, consistência, timeliness) com monitoramento automatizado em datasets críticos?Sim. Soda Cloud rodando em datasets clínicos e financeiros com regras de completude/validade; alertas no Splunk.
✓
Há processo formal de tratamento de incidentes de qualidade de dados com SLA, responsável e RCA?Sim. Severidades definidas, data steward responsável, RCA obrigatório em incidente material.
✓
Métricas de qualidade são reportadas a stakeholders de negócio com dashboards, tendências e thresholds aceitáveis?Sim. Dashboards de DQ por domínio com threshold acordado; comitê quinzenal de governança revisa.
Access Control em Data Platform Forte
✓
O acesso a dados sensíveis em data lake/warehouse usa RBAC ou ABAC granular, distinto de acessos a sistemas transacionais?Sim. RBAC granular em Databricks Unity Catalog + ABAC para PHI; acessos a dados clínicos sob política dedicada LGPD/HIPAA.
✓
Há revisão periódica de acessos (recertificação) específica para a plataforma de dados, com evidência arquivada?Sim. Recertificação semestral por gestor com evidência arquivada e KPI de conclusão; auditor externo valida amostra.
✓
Existe segregação de funções entre quem ingere, transforma e consome dados sensíveis (SoD em pipeline)?Sim. SoD entre data engineer (ingestão), analytics engineer (transform) e analyst (consumo) implementada via grupos AD.
Data Classification & Tratamento de Sensíveis Forte
✓
Datasets com PII/PHI/financeiros sensíveis são identificados e classificados conforme política corporativa e regulação aplicável (LGPD, SOx, PCI)?Sim. PHI/PII auto-classificada via Collibra e tagueada na ingestão; revisão anual por privacy officer.
✓
Dados sensíveis em ambientes de analytics passam por mascaramento, tokenização ou pseudonimização?Sim. Tokenização aplicada na camada Silver; analistas só veem dados mascarados (exceto autorização específica).
✓
Há controle sobre exfiltração e exportação de dados sensíveis (downloads de BI, exports de notebook, cópias para storage pessoal)?Sim. Controle de export em Power BI ativo; downloads logados; políticas DLP em endpoints corporativos.
Model & AI Governance Deficiência
!
Modelos de ML/IA em produção têm registro formal (model registry) com versão, owner, propósito e dados de treinamento documentados?Parcial. Existem 4 modelos de IA (triagem clínica, fraude); registry em planilha governada, sem versionamento formal.
!
Modelos passam por validação independente antes de produção (fairness, robustez, drift, explainability) e revisão periódica?Validação ad-hoc por cientista de dados; sem fairness/drift periódico nem revisão por comitê de risco.
✗
Há controle de acesso e auditoria sobre uso de modelos generativos/LLM corporativos, incluindo prompts e dados expostos?Não. Uso de LLM corporativo (Azure OpenAI) sem política sobre dados expostos; risco de PHI em prompt.
Data Lifecycle & Retenção Aceitável
✓
Existe política formal de retenção e descarte de dados por classe (operacional, financeiro, sensível, regulatório)?Sim. Política aprovada pela diretoria de TI com retenção de 20 anos para prontuário (CFM) e 5 anos para fiscal.
✓
Backups e snapshots de dados sensíveis seguem a mesma política de retenção e descarte da fonte primária?Sim. Backups seguem retenção alinhada à fonte; geo-redundância para PHI.
!
Há evidência de execução do descarte (purge auditado) com trilha de auditoria, ao final do prazo legal/regulatório?Parcial. Purge fiscal anual executado e auditado; descarte de dados clínicos "sob demanda" (LGPD) ainda manual e sem trilha completa.
SOx · Dados Financeiramente Relevantes N/A
✗
Datasets que alimentam demonstrações financeiras (DRE, BP, fluxo de caixa, KPIs auditados) estão identificados como SOx-relevantes?N/A — operadora de saúde não pública, não SOx. Mas controles ANS sobre dados financeiros equivalem em parte.
✗
Pipelines que produzem números financeiros auditáveis têm controles de mudança (CAB, segregação dev/prod, evidência) similares aos sistemas SOx in-scope?N/A — sem regime SOx aplicável.
✗
Há reconciliação automatizada entre dados financeiros no warehouse/lakehouse e o sistema-fonte (ERP, contábil), com evidência arquivada para auditor externo?N/A — reconciliação ANS feita anualmente em processo separado.
Controles documentados, executados com consistência e evidências disponíveis. Auditor emite parecer sem ressalvas materiais; pontos de melhoria recaem sobre automação de revisão de acessos e granularidade dos KPIs operacionais — preparando o caminho para o nível 4.
Cenário 4 — Banco Tradicional
Instituição financeira regulada · Plataforma de dados crítica para reporte regulatório
Nível 4 — Quantitativamente Gerenciado
Infográfico — Arquitetura & Ferramentas
Arquitetura
Data Mesh em GCP com domínios por linha de negócio, contratos de dados versionados, Data Quality como código (Great Expectations) e linhagem ponta-a-ponta com OpenLineage.
Ferramentas Base
BigQuery + Dataplex
SailPoint (IGA) com certificação trimestral
GitHub Enterprise + Argo CD
Datadog + PagerDuty (SLOs)
HSM para chaves criptográficas
Processos
Métricas de controle medidas: % de acessos revisados no prazo, MTTR de incidentes, taxa de mudanças com rollback, cobertura de testes de restore. Limites e gatilhos formais ligados a riscos.
Resultado provável da avaliação ITGC — Pergunta a Pergunta
Data Lineage & Metadata Forte
✓
Existe catálogo de dados centralizado documentando datasets críticos, schemas, owners e definições de negócio?Sim. Collibra com 95% dos datasets críticos; KPI de cobertura, freshness de metadado e ownership ativo monitorados em comitê mensal.
✓
Há rastreabilidade end-to-end (data lineage) das fontes de origem aos consumidores finais — relatórios, dashboards e modelos?Sim. Lineage end-to-end captura dbt, Airflow e Tableau; impact analysis pré-mudança usa dependency graph e mede blast radius.
✓
Mudanças em schema de tabelas/datasets críticos seguem processo de impact analysis e comunicação prévia aos consumidores downstream?Sim. Schema change formal com impact analysis e versionamento dos datasets críticos. Mainframe ainda é exceção (janela mensal).
Data Quality Forte
✓
Existem regras de qualidade definidas (completude, validade, consistência, timeliness) com monitoramento automatizado em datasets críticos?Sim. Monte Carlo + dbt tests cobrem datasets SOx; KPIs de pass rate, MTTR e cobertura DQ reportados ao CRO.
✓
Há processo formal de tratamento de incidentes de qualidade de dados com SLA, responsável e RCA?Sim. MTTD/MTTR de DQ medidos; recorrência por dataset analisada; post-mortem estruturado obrigatório para impacto material.
✓
Métricas de qualidade são reportadas a stakeholders de negócio com dashboards, tendências e thresholds aceitáveis?Sim. SLOs de qualidade por data product, error budget consumido e KPI executivo "% datasets verde 30 dias".
Access Control em Data Platform Otimizado
✓
O acesso a dados sensíveis em data lake/warehouse usa RBAC ou ABAC granular, distinto de acessos a sistemas transacionais?Sim. SailPoint + ABAC dinâmico no warehouse; políticas avaliadas em runtime com OPA; evidência cripto-assinada.
✓
Há revisão periódica de acessos (recertificação) específica para a plataforma de dados, com evidência arquivada?Sim. Certificação trimestral com 99,2% de conclusão no prazo; KRI monitorado e reportado a comitê de Riscos.
✓
Existe segregação de funções entre quem ingere, transforma e consome dados sensíveis (SoD em pipeline)?Sim. SoD codificada e validada na concessão; conflitos bloqueiam pedido automaticamente; relatórios trimestrais para Big4.
Data Classification & Tratamento de Sensíveis Forte
✓
Datasets com PII/PHI/financeiros sensíveis são identificados e classificados conforme política corporativa e regulação aplicável (LGPD, SOx, PCI)?Sim. Classificação automática + atestação por data steward; cobertura ~99% para PII/financeiros sensíveis; LGPD + BCB 4.658 mapeadas.
✓
Dados sensíveis em ambientes de analytics passam por mascaramento, tokenização ou pseudonimização?Sim. Tokenização end-to-end para PII e dados de cartão; DLP ativo em todos os egressos; chaves em HSM com rotação anual.
✓
Há controle sobre exfiltração e exportação de dados sensíveis (downloads de BI, exports de notebook, cópias para storage pessoal)?Sim. Controle de exfiltração (DLP no endpoint + watermark em export de BI); logs auditados pelo SOC.
Model & AI Governance Aceitável
✓
Modelos de ML/IA em produção têm registro formal (model registry) com versão, owner, propósito e dados de treinamento documentados?Sim. Model registry corporativo (MLflow + MLOps interna) cobre os 30+ modelos críticos (credit scoring, fraude, AML).
!
Modelos passam por validação independente antes de produção (fairness, robustez, drift, explainability) e revisão periódica?Parcial. Validação independente por equipe de Risco em modelos críticos antes de produção; revisão de drift trimestral mas fairness não institucionalizado.
!
Há controle de acesso e auditoria sobre uso de modelos generativos/LLM corporativos, incluindo prompts e dados expostos?Parcial. LLM corporativo com gateway que loga prompts; política "no PII em prompt" ativa; uso de Copilot/ChatGPT pessoal ainda em zona cinza.
Data Lifecycle & Retenção Forte
✓
Existe política formal de retenção e descarte de dados por classe (operacional, financeiro, sensível, regulatório)?Sim. Política regulatória detalhada (BCB, CMN, LGPD, SOx) com retenção por classe; auditada anualmente pela Big4.
✓
Backups e snapshots de dados sensíveis seguem a mesma política de retenção e descarte da fonte primária?Sim. Backups multi-região com retenção alinhada à fonte; chave de criptografia rotacionada anualmente.
✓
Há evidência de execução do descarte (purge auditado) com trilha de auditoria, ao final do prazo legal/regulatório?Sim. Purge auditado com trilha cripto-assinada; relatório trimestral para o CRO e ANBIMA quando aplicável.
SOx · Dados Financeiramente Relevantes Otimizado
✓
Datasets que alimentam demonstrações financeiras (DRE, BP, fluxo de caixa, KPIs auditados) estão identificados como SOx-relevantes?Sim. Datasets que alimentam DRE/BP estão tagueados como SOx-relevant na Collibra; 100% mapeados.
✓
Pipelines que produzem números financeiros auditáveis têm controles de mudança (CAB, segregação dev/prod, evidência) similares aos sistemas SOx in-scope?Sim. Pipelines SOx-relevant têm CAB dedicado, segregação dev/prod estrita, evidência cripto-assinada e Big4 testa controles trimestralmente.
✓
Há reconciliação automatizada entre dados financeiros no warehouse/lakehouse e o sistema-fonte (ERP, contábil), com evidência arquivada para auditor externo?Sim. Reconciliação automatizada warehouse × ERP × contábil rodando diariamente; quebras viram incidente P1; evidência arquivada.
Controles não apenas existem como são medidos quantitativamente, com indicadores reportados ao Comitê de Auditoria. Auditoria externa pode confiar em controles automatizados (reliance), reduzindo o escopo de testes substantivos. Gap remanescente: previsibilidade preditiva e melhoria contínua sistemática.
Cenário 5 — BigTech Global
Empresa de tecnologia multinacional · Plataforma de dados auto-otimizada
Nível 5 — Em Otimização
Infográfico — Arquitetura & Ferramentas
Arquitetura
Plataforma multi-cloud com self-service, policy-as-code (OPA), Zero Trust, just-in-time access, ambientes efêmeros por feature branch e detecção automatizada de anomalias em logs (UEBA).
Ferramentas Base
Snowflake + Databricks federados
HashiCorp Vault + Boundary
OPA / Conftest em CI
Chaos engineering para DRP
ML detectando outliers em acessos
Processos
Controles auto-corrigem desvios (ex.: revogação automática de acesso ocioso). Pós-mortems alimentam backlog de melhoria. Auditoria contínua via dashboards em tempo real para 1ª, 2ª e 3ª linhas de defesa.
Resultado provável da avaliação ITGC — Pergunta a Pergunta
Data Lineage & Metadata Otimizado
✓
Existe catálogo de dados centralizado documentando datasets críticos, schemas, owners e definições de negócio?Sim. Catálogo populado por crawlers automatizados; tags de PII/sensibilidade auto-classificadas via ML; data contracts publicados.
✓
Há rastreabilidade end-to-end (data lineage) das fontes de origem aos consumidores finais — relatórios, dashboards e modelos?Sim. Column-level lineage end-to-end incluindo modelos de ML e features; incident lineage correlacionado com data quality e contracts.
✓
Mudanças em schema de tabelas/datasets críticos seguem processo de impact analysis e comunicação prévia aos consumidores downstream?Sim. Data contracts versionados com Schema Registry/Protobuf; CI/CD valida compatibilidade backward/forward; depreciação programada e shadow tables.
Data Quality Otimizado
✓
Existem regras de qualidade definidas (completude, validade, consistência, timeliness) com monitoramento automatizado em datasets críticos?Sim. Data observability ML-driven; freshness/volume/schema/distribution monitorados em todas as camadas; circuit breakers no pipeline.
✓
Há processo formal de tratamento de incidentes de qualidade de dados com SLA, responsável e RCA?Sim. Incidentes auto-detectados com RCA assistido por lineage; remediação por ação programada (re-run, quarentena, fallback dataset).
✓
Métricas de qualidade são reportadas a stakeholders de negócio com dashboards, tendências e thresholds aceitáveis?Sim. Trust scores publicados no catálogo por dataset, scoring por consumer; KPI executivo de confiança em dado.
Access Control em Data Platform Forte
✓
O acesso a dados sensíveis em data lake/warehouse usa RBAC ou ABAC granular, distinto de acessos a sistemas transacionais?Sim. JIT access em ~90% da plataforma; credencial expira em horas. Plataformas adquiridas em M&A recente ainda em integração ao padrão.
!
Há revisão periódica de acessos (recertificação) específica para a plataforma de dados, com evidência arquivada?Parcial. ML revoga acessos ociosos automaticamente em 80% dos sistemas; subsidiárias adquiridas nos últimos 18 meses ainda fora do scope.
✓
Existe segregação de funções entre quem ingere, transforma e consome dados sensíveis (SoD em pipeline)?Sim. SoD validada por OPA antes da concessão; tentativas de bypass auto-reportadas ao SOC com auto-remediação.
Data Classification & Tratamento de Sensíveis Forte
✓
Datasets com PII/PHI/financeiros sensíveis são identificados e classificados conforme política corporativa e regulação aplicável (LGPD, SOx, PCI)?Sim. Classificação por ML em datasets de produção, mas a velocidade de criação de novos datasets supera classificação automática (~3% sem tag a qualquer momento).
✓
Dados sensíveis em ambientes de analytics passam por mascaramento, tokenização ou pseudonimização?Sim. Criptografia E2E + tokenização nativas; chaves rotacionadas continuamente em HSM; key management self-service para data products.
!
Há controle sobre exfiltração e exportação de dados sensíveis (downloads de BI, exports de notebook, cópias para storage pessoal)?Parcial. DLP avançado em egresso, mas a escala torna desafiador cobrir 100% dos canais (especialmente APIs internas e novos produtos pré-GA).
Model & AI Governance Otimizado
✓
Modelos de ML/IA em produção têm registro formal (model registry) com versão, owner, propósito e dados de treinamento documentados?Sim. Model registry corporativo com versão, dataset de treinamento, métricas e owner; cobertura > 99% para modelos em produção.
✓
Modelos passam por validação independente antes de produção (fairness, robustez, drift, explainability) e revisão periódica?Sim. Validação independente obrigatória (fairness, drift, robustness, explainability) + revisão recorrente automatizada; gates de promoção bloqueados em desvio.
✓
Há controle de acesso e auditoria sobre uso de modelos generativos/LLM corporativos, incluindo prompts e dados expostos?Sim. LLM/GenAI corporativo com gateway, política "no sensitive data" enforce-by-default, auditoria completa de prompts e fine-tuning aprovado por comitê.
Data Lifecycle & Retenção Otimizado
✓
Existe política formal de retenção e descarte de dados por classe (operacional, financeiro, sensível, regulatório)?Sim. Política viva, ajustada continuamente por uso e risco; retenção por classe com tagging automático; ML detecta dados elegíveis para descarte.
✓
Backups e snapshots de dados sensíveis seguem a mesma política de retenção e descarte da fonte primária?Sim. Backups versionados com retenção idêntica à fonte; chaos testing em recovery; restore < 1h para qualquer dataset crítico.
✓
Há evidência de execução do descarte (purge auditado) com trilha de auditoria, ao final do prazo legal/regulatório?Sim. Purge auditado e cripto-assinado; right-to-be-forgotten (LGPD/GDPR) executado em < 72h com evidência integral.
SOx · Dados Financeiramente Relevantes Otimizado
✓
Datasets que alimentam demonstrações financeiras (DRE, BP, fluxo de caixa, KPIs auditados) estão identificados como SOx-relevantes?Sim. Datasets SOx-relevantes tagueados; cobertura validada por auditor externo; gaps em data products de novos produtos pré-GA.
✓
Pipelines que produzem números financeiros auditáveis têm controles de mudança (CAB, segregação dev/prod, evidência) similares aos sistemas SOx in-scope?Sim. Pipelines SOx têm CI/CD com gates de evidência, canary releases, rollback automático e attestation trimestral.
✓
Há reconciliação automatizada entre dados financeiros no warehouse/lakehouse e o sistema-fonte (ERP, contábil), com evidência arquivada para auditor externo?Sim. Reconciliação contínua em streaming (warehouse × source-of-truth); divergências disparam circuit breaker e incidente P1 imediato.
Controles preventivos e detectivos automatizados, com loop de melhoria contínua baseado em dados. A auditoria atua como parceira estratégica e foca em risco emergente (ex.: IA generativa, supply chain). Resultado: parecer limpo e benchmark de mercado.