Every Data Pipeline Is A Governance Decision – Olamide Bakare

Data governance is often viewed as a compliance function something owned by legal teams, auditors, risk managers, or privacy officers. Data engineering, by contrast, is typically viewed as a technical discipline focused on building reliable systems that move, transform, and store information.


In practice, however, the distinction is largely artificial.


Having worked with healthcare data systems between 2019 and 2022, I have repeatedly observed that many governance failures originate not from inadequate policies, but from implementation decisions made during system design and data integration.
Every data pipeline embodies a series of governance decisions. The moment a data engineer determines what data will be collected, how long it will be retained, who will have access to it, where it will be stored, how it will be transformed, and under what circumstances it may be deleted, governance has already occurred. The only question is whether those decisions were made deliberately or accidentally.


Consider a common example. A reporting dashboard requires only aggregated metrics, yet a pipeline continues to transfer personally identifiable information into downstream environments. From an engineering perspective, the pipeline functions correctly. From a governance perspective, however, an unnecessary privacy risk has been introduced. Similarly, when a pipeline automatically overwrites historical records, a retention decision has been made. When unrestricted access is granted to a reporting environment, an access-control decision has been made. These may appear to be technical implementation choices, but they are fundamentally governance choices.


I learned this lesson firsthand in 2019 while working with healthcare data systems at a large teaching hospital. During the development of a reporting workflow, patient information was successfully transferred from a restricted clinical environment into a reporting database with broader permissions than intended. The pipeline operated flawlessly from a technical standpoint, yet the design unintentionally expanded access to sensitive information beyond those with a legitimate need to view it. Although the issue was identified and corrected before any harm occurred, it reinforced a critical lesson: governance failures often originate not from malicious intent, but from technical decisions made without governance considerations.


This challenge is increasingly relevant as organisations collect larger volumes of sensitive information and operate within complex regulatory environments. Policies may specify who should have access to data, how long information should be retained, or what quality standards must be maintained. Yet policies alone do not enforce themselves. If those requirements are not embedded directly into data pipelines, they remain aspirational rather than operational.


For this reason, organisations should begin treating governance as a design requirement rather than a compliance afterthought. Data quality validation, access controls, lineage tracking, retention rules, encryption, and auditability should be incorporated into pipeline architecture from the outset. Governance should be engineered into systems in the same way that performance, scalability, and reliability are engineered into systems.


As organisations continue investing in cloud platforms, artificial intelligence, and advanced analytics, the importance of governance-aware engineering will only increase. AI systems are only as trustworthy as the data that powers them, and trustworthy data requires governance throughout the data lifecycle.


The future of data governance will not be determined solely by policies and regulatory frameworks. It will be determined by the engineers who design the systems that operationalise those policies every day. Every data pipeline is a governance decision. Recognising this reality is the first step toward building more secure, compliant, and trustworthy data ecosystems.

Related Articles