Beyond Turing
Any contemporary machine learning architecture in production - a credit scoring system, a diagnostic image classifier, a recommender embedded in a corporate information system - is today composed of two operationally distinct yet normatively inseparable layers: a computational pipeline, which orchestrates the transformation of data into models and of models into decisions, and a governance apparatus, which disciplines its design, operation, monitoring, and revision.
The categorial shift is subtle but decisive. The pipeline is an engineering artefact - DAG, stages, dependencies, lineage, throughput, latency. It is specifiable, versionable, reproducible, optimisable. It works or does not work, according to measurable metrics. Governance is not another stage of the pipeline, nor an extension of it: it is the regulatory environment within which the pipeline becomes designable. It does not function. It answers.
This article maps the architecture of this tension from the standpoint of the information systems engineer who designs, validates, and governs ML pipelines under EU Regulation 2024/1689 (AI Act), EU Regulation 2016/679 (GDPR), and ISO/IEC 42001:2023. The methodological thesis is that pipeline-governance integration is not the superposition of two views on the same object, but the recognition of two planes that require distinct engineering primitives.
1. The pipeline as engineering artefact
In the consolidated MLOps literature (Sculley et al., 2015; Paleyes, Urma, Lawrence, 2022; Kreuzberger, Kühl, Hirschl, 2023), a machine learning pipeline is a directed acyclic graph - a DAG - whose nodes are computational units and whose edges encode data and execution dependencies. The operational primitives are well-known: data ingestion, feature engineering, training, validation, evaluation, packaging, deployment, monitoring, retraining. Each stage corresponds to verifiable engineering metrics: throughput, latency, freshness, model drift, prediction skew, feature staleness.
The maturity of the field has produced standardised tools. Apache Airflow, Kubeflow Pipelines, MLflow, Tecton, Feast are not merely frameworks: they are concrete embodiments of an operational epistemology in which every data transformation must be traceable, reproducible, deterministic within feasible limits. The DataOps methodology integrates this approach on the data side (Atwal, 2019); the feature store practice imposes a verifiable catalogue abstraction on training and inference material.
So far the pipeline is, to all effects, a neutral engineering artefact: a sequence of operations with inputs, outputs, service metrics, and SLAs. Accurate engineering management is a necessary condition for any production system. It is not, however, a sufficient condition for anything regarding the imputability of the decisions the pipeline produces. A pipeline can be impeccably built - reproducible, monitored, performant - and yet produce decisions whose legitimacy is not deducible from its engineering correctness.
2. Governance as legal-technical category
EU Regulation 2024/1689 - the AI Act, in force since 1 August 2024 with staged applicability through August 2027 - introduces a stratification of risk (art. 6 and Annex III) and a specific apparatus of obligations for systems classified as high-risk. Articles 9-15 form the operational core: continuous risk management system (art. 9), data and data governance for training, validation, and test sets (art. 10), technical documentation conforming to Annex IV (art. 11), automatic logging of execution records (art. 12), transparency to deployers (art. 13), architected human oversight (art. 14), accuracy, robustness, and cybersecurity (art. 15).
Standard ISO/IEC 42001:2023 - the first international standard for AI Management Systems - provides the certifiable framework for implementing a compliant management system. ISO/IEC 23053:2022 defines the architectural framework for ML-based AI systems; ISO/IEC 23894:2023 specifies risk management; ISO/IEC 5338:2023 normalises the life cycle. Together, these four standards build the technical infrastructure that translates AI Act obligations into verifiable engineering deliverables: risk register, conformity assessment, post-market monitoring plan, incident reporting procedure.
The overlap with Regulation 2017/745 on medical devices is particularly dense: a Software as a Medical Device incorporating learning components falls simultaneously under MDR and AI Act, generating a dual compliance regime whose coordination is currently the subject of specific European Commission guidance (MDCG 2019-11, under revision). Mökander et al. (2022) have shown how AI Act conformity assessments require a level of engineering documentation typically absent from pre-existing ML pipelines - generating, in many organisations, substantial technical-regulatory debt.
These are not abstract frameworks. They are, literally, checklists of engineering deliverables: versioned technical documents, automatic logging procedures, traceable audit trails, drift and accuracy logs over time, evidence of human consultation at architecturally identified decision points. Governance, in this sense, is not a conceptual meta-level: it is a second operational layer requiring its own engineering primitives.
3. Human oversight architectures and auditability
Article 14 of the AI Act - human oversight - is perhaps the most architecturally relevant provision. It requires that high-risk systems be designed to enable effective human supervision, scaled to the use context. The technical literature distinguishes three consolidated topologies: human-in-the-loop, human-on-the-loop, human-out-of-the-loop with periodic review (Schmidt, 2022; Sterz et al., 2024).
Human-in-the-loop has a human operator validate each decision before execution: it is the most conservative model, applicable where allowable latency permits and decision volume is manageable. Human-on-the-loop places the operator in active monitoring mode, with possibility of asynchronous intervention and correction - the typical model for high-volume recommender systems. Human-out-of-the-loop with periodic review allows autonomous system execution, compensated by systematic ex-post sample audit.
The choice among the three topologies is not purely normative: it is system sizing. It affects allowable latency, sustainable throughput, operational costs, supervisory staff organisation, log storage dimensioning. The architecture document must justify the choice - the AI Act is explicit on this point: oversight must be proportionate to risk, and proportionality is documentable.
Human oversight further requires that the model be explainable within the limits imposed by the task. The Explainable AI literature (Guidotti et al., 2019; Arrieta et al., 2020) distinguishes global explanations (characterisation of model behaviour over the entire distribution) from local explanations (justification of a specific prediction). Techniques such as LIME, SHAP, Integrated Gradients are now industrial standards. The choice between intrinsic approaches (intrinsically interpretable models) and post-hoc approaches (explanations applied to opaque models) is itself an architectural decision. Hence the consolidated practice of model cards (Mitchell et al., 2019) and datasheets for datasets (Gebru et al., 2021), now part of the technical documentation required by AI Act art. 11.
4. Lineage, audit trail, and verifiable traceability
Article 12 of the AI Act requires that high-risk systems implement automatic logging throughout the entire life cycle. This is not a cosmetic constraint: it is an architectural prescription. It means that every production inference must be reconstructible ex post - which model version generated it, which input data snapshot, which feature store state, which system configuration. The operational concept of data lineage (Singh et al., 2018; Polyzotis et al., 2018) becomes, under the AI Act, evidence of compliance: no longer an optional debugging tool, but a deliverable required at conformity assessment.
Technical implementation flows through three integrated components: a metadata store tracking every pipeline execution (MLflow Tracking, Neptune.ai, Weights & Biases are industrial embodiments); a model registry versioning every model artefact with its signature, dependencies, and validation metrics; an immutable audit trail - typically append-only - recording all relevant operational events, including human oversight interventions documented under art. 14.
The engineering challenge is the coherent preservation of these three traces over time. A system running in production for five years accumulates a lineage history that must remain queryable for the entire imposed retention period - typically ten years for healthcare systems, seven for financial systems, under applicable sectoral regulations. Lineage storage dimensioning is not secondary to operational data storage: in many cases it exceeds it in volume.
A mature pipeline, under the AI Act, is a pipeline that produces two parallel outputs for each inference: the decision and its traceability. Governance does not add a downstream control - it modifies the structure of the flow itself, requiring every computational transition to also produce a verifiable evidence of its occurrence. This is a paradigm shift in architecture not yet fully internalised by organisations that built their ML pipelines before 2024.
5. The irreducible remainder
No oversight architecture, no complete audit trail, no model card exhausts the responsibility of the entity that has placed the system in production. This is not an ethical reminder external to the discipline: it is a methodological observation. Article 12 logging attests to the history of a decision; it does not attest to its rightness. Article 11 documented compliance attests that the followed process matched the planned one; it does not attest that the system should have been built that way. Article 14 oversight foresees human intervention; it does not guarantee that the intervention was substantive.
Mature engineering does not seek to close this gap: it declares it. It measures it - where possible - through uncertainty quantification (Abdar et al., 2021), conformal prediction (Angelopoulos & Bates, 2023), out-of-distribution detection. It reduces it, where technically possible, through safety-by-design architectures. But it does not eliminate it, because decision responsibility is a property of the socio-technical system as a whole, not an attribute distillable from any of its computational components.
The methodological point can be stated thus: system governance is a project invariant. It is not a property emerging downstream from performance metrics; it is an initial constraint conditioning the space of admissible architectures. A system designed without this invariant - even if technically optimal - is structurally non-compliant. Not because it violates a particular rule, but because it has missed the category within which rules acquire operational meaning.
An information system designed with this awareness does not renounce analytical power - it makes it locatable. It knows which part of its behaviour is specified by the pipeline and which part is matter of governance. It knows that the first is optimised, the second is argued. It knows that optimisation and argument obey different logics, and that confusing the two generates, alternately, paralysing over-control or algorithmic over-confidence. Engineering maturity consists in keeping them distinct without separating them.
The pipeline is executed. Governance is inhabited. They are not, and never will be, the same kind of object. The information system we need is the one that recognises this - and designs in both planes with their proper primitives. Recognising the boundary is not engineering abdication: it is the highest form of rigour.