Data Pipeline é o fluxo controlado de ingestão, validação, transformação e disponibilização de dados entre sistemas de origem e consumidores analíticos. Sua arquitetura t
Confira!
Data Pipeline é o fluxo controlado de ingestão, validação, transformação e disponibilização de dados entre sistemas de origem e consumidores analíticos. Sua arquitetura também precisa contemplar Data Contracts, monitoramento, segurança, tratamento de falhas e reprocessamento. ETL e ELT descrevem etapas e estratégias desse percurso, mas não substituem a coordenação ponta a ponta.
Fundamentos e arquitetura do Data Pipeline
Arquitetura e Data Contracts
O contrato define origem, owner, schema, identificadores, timezone, granularidade, unidades, latência aceitável e retenção. Mudanças de estrutura devem passar por avaliação de impacto antes da atualização dos consumidores. Sistemas industriais e corporativos mantêm semânticas e ciclos diferentes, portanto a solução analítica precisa documentar reconciliação e limites de uso. Uma conexão funcionando não prova integridade do indicador.
A definição do escopo deve considerar risco, governança e limites técnicos. Uma regra insuficientemente especificada pode gerar resultados plausíveis porém contraditórios. As responsabilidades e os parâmetros de aceite precisam ser explícitos para permitir rastreabilidade e revisão independente.
Arquitetura lógica, física e zonas de confiança
A arquitetura lógica descreve entidades, fluxos, contratos e responsabilidades sem pressupor uma ferramenta. A arquitetura física especifica onde os componentes executam, como se comunicam, quais redes atravessam e quais controles protegem as credenciais. É importante manter essas representações separadas: um fluxo lógico único pode ser implementado com conectores distintos, e um mesmo serviço pode transportar dados de várias origens com requisitos de segurança incompatíveis. Para processos industriais, o desenho deve indicar claramente a zona OT, as fronteiras IT/OT e os mecanismos autorizados de troca. Nenhuma necessidade analítica justifica automaticamente acesso de escrita a PLC ou SCADA. O projeto deve registrar portas, protocolos, direção de comunicação, autenticação, continuidade e quem aprova cada interface.
Inventário de fontes e criticidade
Uma integração que atende múltiplos departamentos deve manter inventário que relacione cada fonte com os indicadores que a utilizam. Para cada sistema, registrar administrador, disponibilidade contratada, janela de manutenção, interfaces, frequência, restrições de licenciamento e condições de acesso. O inventário evita que uma API tratada como secundária se torne dependência crítica sem gestão. Também permite distinguir dados mestres de eventos transacionais e séries temporais. Um cadastro de equipamentos pode ser atualizado diariamente, enquanto o estado operacional muda em segundos; exigir a mesma frequência de extração para ambos eleva custo sem melhorar a análise. A criticidade deve ser atribuída conforme a decisão suportada, a possibilidade de reconstruir dados e o risco de interrupção. Informações irreproduzíveis exigem controles e retenção diferentes de dados obtidos por reconsulta. Na análise de impacto, uma fonte com poucos registros pode ser mais crítica que uma fonte volumosa, caso determine o denominador ou o contexto de um KPI.
Data Contracts e evolução de schema
O Data Contract é um acordo entre responsáveis pela fonte e pelo consumo. Além de tipos de campos, deve documentar identificadores, regras de nulidade, unidades, domínios, periodicidade, compatibilidade, garantias e procedimentos de mudança. Adicionar coluna opcional pode ser compatível, mas alterar o significado de um código sem modificar o nome representa ruptura semântica. É preciso analisar impacto em transformações, Facts, Dimensions, dashboards e consumidores externos. Uma mudança controlada inclui aviso, ambiente de teste, versão, comparação de resultados e estratégia de reversão. A inspeção do contrato em produção deve registrar exceções, não simplesmente assumir que o catálogo descreve o comportamento real da fonte.
Mecanismos de captura e alterações na origem
Extração por API, consulta periódica, Change Data Capture e publicação de eventos possuem semânticas diferentes. Uma API paginada pode omitir registros quando o conjunto muda durante a leitura; uma coleta periódica pode perder alterações transitórias; CDC depende de mecanismos confiáveis para interpretar commits e deletes. A seleção precisa considerar disponibilidade da origem, limitação de chamadas, custo, autorização e necessidade de reconstruir histórico. O contrato deve indicar como distinguir inserção, alteração e cancelamento. Uma exclusão lógica de transação não equivale a apagar uma linha sem evidência. Testes devem incluir alterações concorrentes, interrupção no meio da captura e retomada com checkpoint comprovado.
Estratégia de armazenamento e retenção
Nem todo dado precisa ficar permanentemente disponível no formato recebido. Uma zona raw preserva evidência da captura, enquanto camadas curadas permitem aplicação de regras consistentes; os nomes e a quantidade de camadas dependem da plataforma. É necessário definir classificação de sensibilidade, retenção, custo e necessidade de replay. Dados de vídeo podem incluir informações pessoais ou sensíveis conforme finalidade e configuração, o que requer avaliação específica de acesso e minimização. A análise não deve reter indiscriminadamente imagens quando eventos agregados são suficientes. O desenho precisa distinguir retenção operacional, retenção para auditoria e tratamento de dados após encerramento contratual.
Um Data Contract com responsáveis, semântica e regras de atualização documentadas reduz erros de integração entre fontes corporativas e operacionais.
Processamento, tempo e orquestração
Batch e streaming
Batch processa janelas delimitadas; streaming acompanha eventos conforme chegam. A decisão depende da necessidade de atualização e da qualidade da origem. Event time, processing time e registros tardios precisam ter tratamento separado para não alterar períodos de maneira silenciosa. Baixa latência pode elevar custo sem melhorar a decisão quando os dados da fonte somente são consolidados ao final de um período operacional.
A escolha de ferramentas deve ocorrer depois da definição das necessidades e das evidências esperadas. O projeto precisa preservar a separação entre a função de cada sistema e a interpretação posterior das informações. Mudanças de interface, critérios e período exigem registro e validação antes da produção.
Semântica temporal e janelas de apuração
Em um Data Pipeline, três tempos podem coexistir: quando o evento ocorreu, quando chegou ao sistema de integração e quando foi processado. Relatórios podem divergir sem erro de transporte se usam tempos diferentes. A definição do KPI deve explicitar qual relógio governa a apuração, qual timezone é adotado, como lidar com horário de verão quando pertinente e se períodos são recalculados após chegada tardia. Para operação por turnos, o calendário empresarial pode atravessar meia-noite e não coincidir com o calendário civil. Isso altera disponibilidade, produtividade, ocupação e metas. Uma homologação deve criar exemplos que cruzem turnos, fechamentos e atrasos, comparando resultados previstos com a saída.
Tratamento de dados atrasados
O fechamento de uma janela analítica exige decisão explícita sobre a chegada tardia. Uma estratégia é publicar resultados provisórios e atualizá-los até um prazo definido; outra é reter a publicação até que a completude esperada seja alcançada. Ambas têm impactos em latência e estabilidade dos indicadores. O prazo não deve ser um número escolhido apenas por conveniência tecnológica: precisa considerar comportamento das fontes e finalidade da decisão. Um evento recebido no dia seguinte pode pertencer ao turno anterior; uma correção de ERP pode alterar o mês já fechado. Nesse caso, é necessário definir quem autoriza reabrir o período, como registrar a revisão e se relatórios históricos serão recalculados. Dashboards que exibem resultados sujeitos a mudança precisam indicar o estado dos dados. O aceite deve incluir cenários em que o evento chega após o fechamento, em que o registro é corrigido e em que o conjunto de origem é republicado integralmente.
Orquestração, DAGs e idempotência
Uma DAG explicita dependências de ingestão, limpeza, carga e publicação. Retries, timeouts, checkpoints e responsáveis fazem parte do desenho. Idempotência impede que a repetição de uma tarefa duplique eventos; backfill reprocessa períodos históricos com critérios e evidência das mudanças. Uma conclusão técnica de tarefa não significa que o conjunto esteja completo ou que as métricas estejam reconciliadas com a origem.
Exemplos operacionais devem ser tratados como hipóteses de projeto, não como resultado real da empresa. O valor de um método se demonstra por controles verificáveis, reconciliação e capacidade de explicar divergências. A análise de risco deve orientar o nível de documentação e de teste.
Integridade, monitoramento e recuperação
Exatamente uma vez e deduplicação prática
A expressão exactly-once é frequentemente interpretada como garantia universal, mas o comportamento depende da combinação entre captura, processamento e escrita. Reentregas de mensagens e retries podem ser normais. O controle deve explicitar identificadores de evento, checkpoints, transações de destino e políticas de upsert. Quando faltam chaves confiáveis, algoritmos por hash ou composição de campos podem introduzir falsos positivos e falsos negativos. O teste deve reproduzir queda antes e depois de cada checkpoint relevante, confirmando se aparecem registros perdidos ou contados em duplicidade. A evidência não é só o log de sucesso: são totais reconciliados por janela e por chave de negócio.
Desenho de checkpoints e recuperação
Checkpoints precisam representar uma fronteira segura entre aquilo que foi confirmado e aquilo que pode ser reprocessado. Se a execução registra sucesso antes de persistir a saída, uma queda pode causar perda; se confirma a saída e falha antes do checkpoint, pode produzir duplicação na retomada. A arquitetura deve explicar como resolver essa diferença por transações, chaves idempotentes ou reconciliação. Em fontes paginadas, o cursor precisa manter significado estável durante alterações; em captura de mudanças, offsets devem respeitar ordem e política de retenção do log de origem. O runbook deve permitir restaurar desde um checkpoint conhecido sem refazer indiscriminadamente todo o histórico. Testes de resiliência devem interromper o processo em pontos selecionados e verificar não apenas que voltou a operar, mas que os totais e as versões dos registros estão corretos. Essa evidência é mais relevante que uma simples demonstração de reinício automático.
Data Quality, segurança e observabilidade
Regras de schema, completude, unicidade, integridade e faixa são aplicadas de modo proporcional ao risco. Registros inválidos devem receber classificação e trilha de tratamento. Freshness, volume de chegada, rejeição, duração de processamento e erros ajudam a observar a operação. Em OT, a coleta a partir de SCADA ou Data Historian não pode abrir caminho indevido de controle entre redes corporativas e industriais.
A definição do escopo deve considerar risco, governança e limites técnicos. Uma regra insuficientemente especificada pode gerar resultados plausíveis porém contraditórios. As responsabilidades e os parâmetros de aceite precisam ser explícitos para permitir rastreabilidade e revisão independente.
Monitoramento de SLA e SLO de dados
Acordos de serviço podem incluir disponibilidade de plataforma, mas isso não garante que as informações estejam atualizadas ou corretas. Um SLO de freshness deve especificar fonte, janela, método e exceções; um SLO de completude deve definir universo esperado e denominador. A medição precisa distinguir falha de integração de ausência legítima de eventos. Alertas devem refletir consequências sobre os consumidores e escalonar a equipe competente. Em operações que usam dados para decisões diárias, é necessário comunicar quando um indicador está provisório ou não confiável. O histórico de incidentes deve alimentar mudanças no processo, sem mascarar falhas por ajustes de thresholds.
A revisão dos checkpoints, de replay e dos critérios de aceite permite identificar riscos antes de uma implantação depender operacionalmente dos fluxos de dados.
Segurança, interfaces e governança
Acesso e proteção das informações
A segurança deve seguir o princípio do menor privilégio do ponto de captura ao destino. Uma identidade usada para leitura analítica não precisa ter permissão de alterar transações operacionais. Credenciais devem possuir rotação, armazenamento seguro, auditoria e plano de revogação. Na transferência, classificar dados pessoais e confidenciais ajuda a decidir criptografia, pseudonimização, mascaramento e retenção. É igualmente importante controlar quem pode consultar zonas raw, pois elas podem conter campos posteriormente removidos das camadas analíticas. Nos ambientes OT, regras de comunicação e segregação exigem participação dos responsáveis pela segurança e pela continuidade operacional. Os logs precisam permitir investigar acessos indevidos sem expor segredos. Uma avaliação de segurança deve documentar fronteiras, dependências externas, permissões, fornecedores e comportamento esperado quando a conexão falhar.
Conciliação entre origens heterogêneas
Um pipeline que correlaciona vendas, circulação, manutenção e energia precisa adotar identidade compartilhada para unidades e períodos. O mapeamento de identificadores não deve ser inserido de forma ad hoc em cada transformação. Um catálogo governado deve indicar chaves válidas, período de vigência, casos de fusão e desativação, além de registros sem correspondência. Eventuais agregações devem preservar o grão mínimo necessário à auditoria. Se uma loja possui dois sistemas de venda, consolidar transações exige comprovar que não são duplicatas e que cancelamentos são tratados de modo uniforme. Eventos de vídeo, por sua vez, podem ser estimativas e não registros de indivíduos. A reconciliação deve declarar quais comparações são permitidas e quais relações não podem ser inferidas. Essa documentação permite responder por que um relatório mostra números diferentes de outro, sem escolher arbitrariamente a fonte mais conveniente. Um teste útil seleciona pequenas amostras com casos conhecidos e reproduz a transformação até o indicador.
Modelo operacional e custos
A operação de Data Pipelines envolve custo de captura, transferência, processamento, armazenamento, monitoramento e suporte. Streaming contínuo pode consumir recursos mesmo quando poucas decisões exigem baixa latência; por outro lado, grandes cargas batch podem competir com janelas operacionais críticas. A estimativa precisa considerar volume atual, crescimento, reprocessamento e períodos de pico. A execução também deve estabelecer responsável por Data Contracts, atualização de conectores, alterações de regras e atendimento a incidentes. O SLA da plataforma é apenas uma parte do serviço: freshness e completude de indicadores dependem das fontes e podem exigir compromissos próprios. A contratação deve distinguir obrigações do produtor, do integrador, do provedor de infraestrutura e do consumidor analítico. Sem essas interfaces, falhas ficam sem proprietário, aumentando o tempo de recuperação e comprometendo a confiança na informação.
| Critério | Verificação | Evidência |
|---|---|---|
| Integridade | Reconciliação por chave e janela | Relatório comparativo |
| Freshness | Atraso entre evento e disponibilidade | Séries de latência |
| Recuperação | Falha simulada e replay | Logs e totais após reinício |
| Segurança | Permissões e acesso de conectores | Matriz de acesso |
Implantação e critérios de aceite
Testes de integração e critérios de aceite
Um pacote de aceite deve demonstrar dados normais, duplicados, atrasados, ausentes e fora de ordem. A equipe deve reconstruir indicadores, comprovar reconciliação, simular interrupções e testar recuperação sem novas duplicações. Os entregáveis incluem desenho da arquitetura, Data Contracts, logs, runbook, catálogo de testes e responsabilidade de operação. O escopo de integração deve separar o que cabe ao integrador, ao Data Owner e ao operador.
A escolha de ferramentas deve ocorrer depois da definição das necessidades e das evidências esperadas. O projeto precisa preservar a separação entre a função de cada sistema e a interpretação posterior das informações. Mudanças de interface, critérios e período exigem registro e validação antes da produção.
Ensaios de desempenho representativos
O teste de performance precisa simular perfis reais de carga, incluindo lote inicial volumoso, operação regular, backlog após indisponibilidade e reprocessamento de histórico. Medir apenas o tempo de uma carga pequena não representa o comportamento em produção. O ensaio deve verificar vazão, latência, memória, custo, número de conexões e possíveis impactos sobre o sistema produtor. Em alguns ambientes, consultas analíticas executadas diretamente no ERP podem degradar aplicações críticas; o projeto deve prever limites, janelas ou mecanismos de extração adequados. Resultados devem registrar configuração e tamanho da amostra para permitir comparação posterior. A capacidade de crescimento precisa ser testada com hipóteses explícitas, não promessas genéricas de escalabilidade. Um plano de contingência deve indicar o comportamento quando a capacidade contratada é ultrapassada e quais consumidores recebem prioridade.
A continuidade da informação sobre ativos exige disciplina de manutenção, rastreabilidade e gestão de mudanças, sem confundir disponibilidade da plataforma com confiabilidade dos indicadores.
Plano de implantação e transição operacional
A implantação deve começar por fontes e indicadores representativos, com hipóteses de integração, testes e responsabilidades registradas. Um piloto útil exercita dados históricos e eventos atuais, períodos com falhas, identificadores ausentes e necessidade de reprocessamento. Antes de promover a produção, é necessário conferir configuração, segurança, monitoração, documentação e capacidade de suporte. A transição inclui treinamento de responsáveis, runbooks, contatos de escalonamento, gestão de mudanças e aceite formal de entregáveis. Métricas de operação devem ser revisitadas após estabilização. A contratação deve delimitar suporte ao conector, suporte à plataforma e responsabilidade pelos dados da origem, evitando lacunas entre equipes.
Matriz de aceite para governança
Uma matriz de aceite deve conectar requisito, método de ensaio, evidência, responsável e resultado esperado. Para integridade, usar contagens e reconciliação por chave; para qualidade, aplicar casos de campos inválidos e duplicação; para recuperação, interromper o fluxo e reprocessar; para segurança, validar permissões e trilhas de acesso. Para freshness, medir períodos regulares e condições degradadas. Cada teste precisa declarar o ambiente, a massa de dados, o resultado observado e as restrições. Itens críticos não devem ser aceitos exclusivamente por demonstração visual. A documentação final pode incluir arquitetura lógica e física, catálogo de contratos, procedimentos de operação, indicadores de saúde, configuração de alertas e histórico de não conformidades. O aceite deve diferenciar aprovação de desenvolvimento, implantação e início da operação assistida. Isso evita que uma entrega tecnicamente conectada seja confundida com um serviço confiável já estabilizado.
Uma matriz de responsabilidades deve acompanhar cada interface e descrever quem autoriza alterações de schema, mudanças de frequência e interrupções planejadas. Os requisitos não podem depender de conhecimento informal da equipe. Durante uma investigação, o operador precisa identificar a origem afetada, o intervalo comprometido, o último checkpoint válido e os consumidores que receberam dados possivelmente incompletos. Um plano de resposta deve prever congelamento de publicação, comunicação de indicador provisório, correção e reconciliação. Essa sequência permite avaliar impacto sem apagar eventos ou simular continuidade inexistente. A engenharia de integração deve estabelecer como documentos de configuração, diagramas e testes são atualizados após modificações, garantindo coerência entre o que foi contratado e o que efetivamente opera. Um indicador de disponibilidade do Pipeline só é útil quando acompanhado por evidência de integridade do conteúdo disponibilizado.
Um Data Pipeline também precisa ser projetado considerando dados mestres. A integração de eventos de produção, circulação e manutenção depende de entidades persistentes, como equipamento, unidade física e calendário. Alterações de cadastro podem causar inconsistências mesmo quando todos os registros são recebidos. O desenho deve definir como as chaves das origens se relacionam, como versões são armazenadas e qual área responde pela validação. Sem esse controle, um mesmo ativo pode aparecer duplicado em relatórios ou desaparecer de séries históricas após uma mudança de código. O teste deve incluir renomeação, migração de unidade e substituição de equipamentos.
A rastreabilidade deve alcançar não apenas registros, mas regras de cálculo. Quando uma transformação passa a excluir determinado tipo de evento, os consumidores precisam saber a partir de qual versão a regra vale. A informação sobre lineage, versão do código e momento do processamento é indispensável para comparar indicadores calculados em datas diferentes. Se um ajuste retroativo modificar um período já encerrado, é necessário conservar a razão da mudança e os totais anterior e posterior. Isso evita que divergências pareçam erro de operação quando foram produzidas por revisão autorizada da regra analítica.
Uma equipe de operação deve possuir procedimentos claros para falhas parciais. Pode ocorrer de um conector parar enquanto outros continuam alimentando o dashboard; nesse caso, o resultado agregado precisa indicar cobertura incompleta. A arquitetura deve definir dependências bloqueantes e condições em que a atualização prossegue com ressalvas. O estado de saúde de cada origem não pode ser escondido por um único indicador geral de disponibilidade da plataforma. A decisão sobre publicar dados parciais pertence ao negócio, apoiado pela avaliação técnica de criticidade e da possibilidade de interpretar o resultado.
Ensaios de segurança precisam considerar também o comportamento das ferramentas em caso de erro. Uma credencial expirada deve provocar falha identificável, não uma sucessão silenciosa de tentativas sem limite. A perda de conexão com OT não deve resultar em sobrecarga da rede por retries agressivos. Os logs não devem expor tokens, senhas ou informações pessoais desnecessárias. O projeto deve documentar procedimentos para revogar acesso, trocar credenciais, restaurar configurações e revisar permissões após mudança de fornecedor. Um desenho bem-sucedido protege os sistemas produtores enquanto conserva a capacidade de análise.
O contrato técnico deve prever entrega de conhecimento para a equipe que vai operar o fluxo. Diagramas desatualizados e procedimentos incompletos tornam o sistema dependente de pessoas específicas. O handover precisa incluir inventário das interfaces, Data Contracts, critérios de qualidade, runbooks, indicadores de observabilidade, parametrizações e histórico dos testes. Durante a operação assistida, incidentes reais devem ser usados para verificar a suficiência da documentação e ajustar os mecanismos de monitoramento. A aceitação definitiva precisa considerar tanto o cumprimento dos requisitos originais quanto a capacidade operacional de manter e recuperar o serviço.
Considerações finais
O aceite de um Data Pipeline não é demonstrado pela simples atualização de um dashboard. A equipe precisa provar que cada informação pode ser rastreada da origem à publicação, com regras de transformação e estados de validação conhecidos. Ensaios de falhas, duplicações, alterações de schema e chegada tardia devem produzir resultados reconciliados e repetíveis.
A escolha entre batch e streaming deve resultar da latência efetivamente útil ao processo, dos limites dos sistemas produtores e do custo de operação. Interfaces IT/OT requerem isolamento e controles de acesso coerentes com a criticidade do processo. Sem ownership e runbooks, mesmo uma arquitetura tecnicamente sofisticada permanece vulnerável à indisponibilidade e a interpretações incorretas.
A decisão de implantação deve exigir Data Contracts, matriz de responsabilidades, resultados de testes, critérios de frescor, estratégia de replay e evidências de recuperação. O objetivo é uma cadeia de informação que possa ser auditada e mantida em operação, não apenas um fluxo de registros que parece funcionar nos casos favoráveis.
Referências técnicas
[1] APACHE SOFTWARE FOUNDATION. Core Concepts — Apache Airflow 3 Documentation. Disponível em: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/. Acesso em: 26 out. 2026.
[2] GOOGLE CLOUD. Streaming pipelines — Cloud Dataflow Documentation. Disponível em: https://docs.cloud.google.com/dataflow/docs/concepts/streaming-pipelines. Acesso em: 26 out. 2026.
[3] GOOGLE CLOUD. Work with Dataflow Data Pipelines. Disponível em: https://docs.cloud.google.com/dataflow/docs/guides/data-pipelines. Acesso em: 26 out. 2026.
[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Guide to Operational Technology (OT) Security. SP 800-82 Rev. 3. Disponível em: https://csrc.nist.gov/pubs/sp/800/82/r3/final. Acesso em: 26 out. 2026.
Perguntas frequentes
É o fluxo controlado que recebe dados das fontes, aplica validações e transformações, e disponibiliza resultados para análise. Também contempla execução, monitoramento, segurança e recuperação, permitindo comprovar a origem de cada indicador.
Não. ETL e ELT descrevem a ordem da transformação e carga. O Data Pipeline inclui também conectores, Data Contracts, orquestração, observabilidade, tratamento de exceções e suporte operacional.
Batch trabalha com conjuntos de dados em janelas definidas; streaming processa eventos em fluxo contínuo. A escolha depende da latência útil, do comportamento da origem e do custo, não apenas da capacidade da plataforma.
Para formalizar campos, chaves, regras de significado, periodicidade, timezone, ownership e procedimentos de mudança. Sem esse acordo, uma alteração na origem pode produzir dados tecnicamente válidos com interpretação gerencial incorreta.
A solução define chaves estáveis de evento, checkpoints, regras idempotentes e reconciliação entre origem e destino. É necessário testar interrupções antes e depois da persistência para comprovar que reexecuções não alteram os totais.
O projeto diferencia event time e processing time, define janelas de apuração e determina quando períodos podem ser revisados. Eventos tardios precisam de trilha de correção e, quando afetam resultados divulgados, comunicação aos consumidores.
É a atualidade dos dados disponíveis para determinado uso. Uma execução concluída não garante freshness nem completude; a medição deve considerar fonte, janela, atraso aceitável e estado das informações.
Isolar registros que violam regras críticas, preservando o valor original, a fonte, o motivo e o lote. A correção e o replay devem ocorrer com rastreabilidade e sem criar eventos duplicados.
Pode, quando a arquitetura permitir e os controles de OT forem respeitados. A coleta deve observar segregação, menor privilégio, capacidade da origem e restrições de segurança, sem abrir um canal de comando indevido.
Data Contracts, resultados de reconciliação, testes de eventos atrasados e duplicados, simulações de falha, runbooks e registros de segurança. Um dashboard com dados exibidos não comprova sozinho a integridade do fluxo.
