Data, analytics, and AI architecture governance

In plain terms, a data architecture describes what information the enterprise holds, where it lives, who owns it, and how it moves. Analytics and artificial intelligence sit one step beyond that: they turn the recorded information into a judgement. An analytics model summarises data to inform a person. An AI model, as this course uses the term, is a model trained on data that produces an output used to inform or make a decision, often a prediction, a score, or a classification. Both depend entirely on the data architecture beneath them, which is why they belong to the same architectural problem rather than a separate one.

TOGAF places data and applications together in Phase C, its Information Systems Architecture phase, precisely because the two are inseparable. Analytics and AI are the point where that pairing becomes sharpest: a model is an application that consumes data and, in return, produces something the enterprise will act on. If the underlying information authority is unclear, the model inherits that confusion and amplifies it, because it acts on the confused data at scale and speed.

The single most useful reframing in this module is this: a model is not a clever accessory bolted onto the data. A model is a new architecture element that carries authority derived from the data. The moment its output changes a decision, it has the same standing as any other authoritative source in the enterprise, and it needs the same architectural discipline: an owner, a place in the repository, a lifecycle, and a governance control at every point where it could go wrong.

To govern a model, first name it as a thing the architecture recognises. An AI system here is more than the trained model file. It is the model together with the data it was trained on, the code that serves it, the decision it feeds, and the people accountable for it. When you treat all of that as one architecture element, you can give it the things every governed asset needs.

• An owner. A single accountable person or role, exactly as a data domain has an owner. Ownership answers who may change the model and who answers for its output.
• A purpose. The specific decision the model exists to inform, stated narrowly. A load-forecast model informs reinforcement priority; it is not a general-purpose oracle, and its purpose bounds where it may be used.
• A lifecycle. A defined path from proposal, through training and evaluation, into service, and out again at retirement, with review points along the way.
• A place in the repository. An entry in the architecture repository so the model is discoverable, its dependencies are visible, and its governance record travels with it.
• Dependencies made explicit. The data sources it consumes, the systems it calls, and the decisions that depend on it, so a change upstream cannot silently invalidate it.

Naming the AI system this way converts a hidden tool into a governable asset. It is the difference between the opening story, where a model shaped capital decisions with no owner and no record, and an enterprise where the same model is a registered element with a lineage, a risk tier, and a human standing between it and the decision.

People often say AI governance as if it were one thing. It is clearer to separate three distinct governance questions, because each has a different owner and a different failure mode.

Data governance asks whether the information feeding the model is fit to be used. Is each input traced to a source and an owner? Is the consent or legal basis for using it recorded? Is it current, or does it describe a world that has changed? This is ordinary information governance applied to training and inference data. Its failure mode is a model built on data nobody could stand behind.

Model governance asks whether the model itself is sound and controlled. Is it versioned, so you know which model made which decision? Was it evaluated, and evaluated across the groups it will affect rather than only in aggregate? Is its purpose recorded and its use bounded to that purpose? Its failure mode is a model that performs well on average while failing badly for a specific area or group, unnoticed.

Decision governance asks what happens where the model output meets a real decision. Is there a human who can review and override it? Is there a route for someone affected to challenge the outcome? Is the live decision monitored for drift, and is there a defined rollback if the model degrades? Its failure mode is the opening story: a model quietly steering decisions with no control standing in the path.

These three are a chain, not a menu. Good data with an ungoverned model still produces untraceable decisions. A well-governed model fed poor data produces confident errors. Sound data and a sound model with no decision control still let drift reach the decision unchallenged. Governance holds only when all three links hold. The figure below sets each link beside the failure it leaves behind when it is the one missing, which is why none of the three can be traded for effort spent on the other two.

Four controls do most of the work. Each one is an ordinary architecture artefact, recorded in the repository, rather than a piece of new technology.

Data lineage is a record that traces each piece of information back through every transformation to its origin, so you can answer where a value came from and whether you were entitled to use it. For a model, lineage means every training input is traced to a source, an owner, and a consent or legal basis. Without lineage, you cannot answer the first question an auditor or a regulator will ask, which is what the model learned from.

A model registry is a catalogue that records each model as a versioned entry: its owner, its purpose, the data it was trained on, how it was evaluated, its risk tier, and its current status. It is to models what a master-data catalogue is to reference data. The registry is what makes a model discoverable and accountable instead of a file on someone's laptop.

Human oversight means a named person can review, override, and account for a decision the model influences, and that someone affected has a route to challenge it. Oversight is proportionate: a low-stakes internal ranking may need light review, while a decision that affects a customer needs a clear person in the loop and an appeal route. This control is where the enterprise keeps a human answerable for outcomes.

A risk tier is a classification that sets how much of the other controls a given model needs, based on the consequences of it being wrong. A model informing an internal report sits in a low tier and carries light controls. A model influencing money, safety, or a person's treatment sits in a high tier and carries lineage, evaluation across groups, mandatory human oversight, and monitoring. Tiering is the mechanism that stops governance from being either uniformly heavy, which teams route around, or uniformly light, which lets a high-stakes model slip through.

Risk tiers are not only an internal convenience. Regulators are moving towards classifying AI systems by the risk they pose and attaching obligations to each class. The clearest current example is the European Union's AI Act, which is widely reported to sort AI systems into risk categories, from prohibited uses at the top, through a high-risk class that carries the heaviest obligations, down to limited and minimal risk. The exact categories, the systems that fall into each, and the timing of the obligations are matters of legal detail that change as guidance and implementing measures are issued.

This course treats that regulatory picture with deliberate caution. The direction of travel, classifying AI by risk and attaching duties to the higher classes, is well established and useful for architecture. The precise thresholds and duties are a compliance and legal question that an architecture course should not assert as settled. Anyone placing a real model into a real regulatory class must verify the current text of the relevant law and take qualified advice, not rely on a course summary.

What matters architecturally is the shape, not the letter, of the obligation. If a regulator classifies a model as high risk, the architecture must be able to show, for that model, its data lineage, its evaluation record, its human oversight arrangement, and its ongoing monitoring. An enterprise that already runs the four controls above has the evidence a risk classification demands, because the risk tier in its own model registry maps onto the regulator's class. The governance you build for good architecture is the same governance that answers a regulator, which is why placing the risk tier inside the architecture, rather than bolting compliance on later, is the efficient path.

London Grid Distribution runs a distribution network of 36,000 km of cable and 77 primary substations serving 2.3 million customers across Greater London, under Ofgem regulation and the RIIO-ED2 price control. Its planners use an AI load-forecasting model to rank which primary substations are closest to their firm capacity, so that reinforcement money is spent where the network is tightest first. That ranking moves capital, so the model is governed as an architecture element, not a planning spreadsheet.

The model as a repository element

The load-forecast model has an entry in the architecture repository with a named owner in the network planning function, a stated purpose limited to reinforcement prioritisation, and explicit dependencies on the asset register, the metered demand history, and the connections pipeline. It is versioned, so every published ranking can be traced to the exact model that produced it.

The four controls in place

• Data lineage. Each input, demand history, weather, connection forecasts, is traced to its source system and owner, with the basis for using it recorded, so an auditor can see exactly what the model learned from.
• Model registry. The model is a versioned registry entry carrying its owner, purpose, training window, evaluation record, and risk tier. Replacing it means a new version with its own evidence, not an untracked swap.
• Human oversight. A planner reviews the ranking before it drives spend and can override it where operational knowledge contradicts the model. The override and its reason are recorded.
• Risk tier and monitoring. Because the ranking steers capital, the model sits in a higher internal tier: its live output is monitored for drift against actual peak demand, and a defined rollback returns planners to the previous method if it degrades, so the situation from the opening story cannot recur silently.

Why the repository is the right home

Holding the model in the repository, beside the asset and demand data it depends on, is what lets London answer three questions at once: which model produced a given ranking, what it was trained on, and who is accountable for it. Because Ofgem expects distribution operators to justify where reinforcement investment goes, that same governance record doubles as regulatory evidence. The model that shapes the ED2 investment case is the model whose lineage, evaluation, and oversight the enterprise can produce on demand.