Governance & Risk

Building an AI Governance Framework

Framework · 3 min read

An AI governance framework is not a policy document that sits on a shelf. It is the set of structures, decision rights, and routines that determine who may deploy which system, on what evidence, and under what oversight.

Start with the decisions, not the artefacts

Most organisations begin by writing an acceptable-use policy and drafting a page of principles. That produces artefacts without authority. A more durable sequence is to identify the decisions that actually need governing — whether to build or buy a model, whether a system may act without review, who owns a model once it is live, how an incident is escalated — and then assign an owner and a test to each. The framework is the sum of those assignments.

Governance should attach to machinery you already have: the risk register, the change board, the procurement gate, the incident process. AI does not warrant a parallel bureaucracy. Where existing controls can be extended — model risk treated as a class of operational risk, data lineage treated as part of data governance — extend them. Add a dedicated body only where the existing one genuinely cannot carry the decision.

Build the framework in layers

A workable framework matures in layers. The first is an inventory: what AI systems exist, who owns each, what data feeds them, what decisions they influence. The second is a lightweight tiering model that sorts systems by the consequence of failure, so oversight is proportionate. The third is an operating cadence — a forum that meets, reviews exceptions, and can say no. The fourth is evidence: documentation, testing, and monitoring that let an outsider reconstruct why a decision was made.

• Inventory before policy — you cannot govern systems you have not counted, so the register comes first.
• Tier by consequence — a summariser and a system that moves money or controls plant do not need the same controls.
• One owner per system — shared accountability is no accountability.
• Cadence over ceremony — a forum that meets and decides beats a committee that only ratifies.

Make the framework legible

No framework survives contact with a deadline if it is understood only by its authors. Brief the people who live under it — product owners, engineers, risk, procurement — on the decision rights that apply to them. Governance people can recite from memory is governance that holds when speed argues against it.

A governance framework earns its keep when people can use it under pressure. Publish the decision rights, not just the principles. Make clear what a product team may do without asking, what requires review, and how long a review takes. Ambiguity does not produce caution; it produces shadow deployments.

Questions to ask

• Who owns each AI system, and can they name the last decision they made about it?
• Which existing control — risk, change, procurement — does each new AI decision attach to?
• How does a frontline team escalate a concern about a model, and what happens next?
• What evidence would let an external reviewer reconstruct a significant decision six months later?

Decision Rights for Autonomous Systems

Governance · 3 min read

Autonomy is not a property of a system; it is a property of a decision. The governance question is not how autonomous a model is, but which specific decisions it may take alone, which it may take with review, and which it must hand back to a person.

Separate the four modes

A useful frame sorts decisions into four modes: fully automated, automated with notification, human approval before action, and human-led with AI support. Assigning a decision to a mode should follow from its reversibility, its consequences, and the reliability of the system in that context. Reversible, low-consequence decisions can sit at the automated end; irreversible or high-consequence decisions belong nearer the human end until trust is earned with evidence.

The modes are not fixed. A decision can move toward automation as performance data accumulates, and should move back when monitoring shows drift, a change of conditions, or an incident. Decision rights are therefore a living register, reviewed on a cadence, not a one-time certification.

Design the boundary conditions

The hard part is not the happy path but the edges. Define the confidence threshold below which the system must defer. Define the inputs it is not permitted to act on. Define what happens when the system is uncertain, unavailable, or contradicted by a person. Every autonomous action should have a named human accountable for its consequences, an override that works under time pressure, and a log that records the inputs, the decision, and the intervention.

• Name the accountable person per decision, not per system.
• Set the deferral threshold in advance, and monitor against it.
• Make override fast and safe — an override that is hard to use will not be used.
• Log the reasoning, not just the outcome.

Keep the audit trail usable

The value of this discipline is not caution for its own sake. It is that autonomy becomes defensible: when a decision goes wrong, you can show what the system was permitted to do, what it was not, and how a person could have intervened. That record is what lets a board, a regulator, or a customer extend trust, and what lets the organisation widen automation without waiting for an incident to teach it caution.

An audit trail exists so that a decision can be explained after the fact — to a regulator, a customer, or an internal reviewer. That requires capturing the model version, the data and context, the threshold applied, the outcome, and any human intervention, in a form that survives staff turnover and vendor change. Logs that record only the final answer satisfy nobody.

Questions to ask

• For each autonomous action, who is accountable when it goes wrong?
• What is the system's deferral threshold, and who set it?
• How quickly can a person override a decision mid-flight, and is that tested?
• If the model changed last month, would your records show it?

OT Cybersecurity & IEC 62443

Compliance · 3 min read

Operational technology — the controllers, sensors, and networks that run plant and processes — faces a different risk profile from office IT. Where IT prioritises confidentiality, OT prioritises availability and safety; a breach that stops a line or moves a physical process is an operational and human-safety event, not merely a data incident.

The IT and OT divide

OT environments are long-lived, often patched only in maintenance windows measured in weeks or months, and frequently run protocols and equipment never designed to face a network. Flattening them into the IT security model, with its assumptions of frequent patching and confidentiality-first priorities, produces both resistance and risk. Security work in OT has to respect uptime, process safety, and the realities of legacy equipment.

The IEC 62443 series provides a framework for industrial automation and control systems built around two ideas: zones and conduits. Assets with similar security requirements are grouped into zones; the communication paths between them are conduits, and controls are applied where zones meet. Each zone and conduit is assigned a target security level, and controls are chosen to meet that target. This lets an organisation protect the plant without trying to harden every device equally, which is rarely possible.

Where AI changes the picture

AI enters OT in several places: predictive maintenance, vision-based quality inspection, process optimisation, and increasingly as an interface between operators and control systems. Each adds a pathway in and a data flow out. A model that reads sensor data and writes setpoints is a control element and must sit within the zone model, not outside it. Data leaving the plant for training or analytics crosses a conduit and needs the same scrutiny as any other boundary.

• Segment before you connect — extend the zone and conduit model to every AI data path, including cloud training pipelines.
• Assign a target security level per zone and hold to it as systems change.
• Treat AI control loops as control elements, with the same change control as any other.
• Assume legacy equipment cannot be hardened; isolate and monitor it instead.

Integrate from the start

This matters most where OT and IT teams have historically been separate. The controls protecting a plant and those protecting a data centre were designed against different threats and are often owned by different functions. AI projects sit across that line, so successful deployments establish a shared review in advance — network, control, and security engineers together — rather than handing a finished data path from one team to the next.

For organisations pursuing Industry 4.0 and AI-native operations, OT security is not a phase two activity. Retrofitted controls are more expensive, more disruptive, and more likely to be bypassed under production pressure. Decide the zone architecture and the data paths as part of the design, and make security review a gate in the deployment process rather than a postscript.

Questions to ask

• Which AI or analytics data paths cross between zones, and who approved each?
• What target security level applies to the zone an AI system sits in?
• Can a model influence a physical process, and if so, what limits it?
• How is the plant patched without jeopardising uptime, and does AI change that window?

Data Sovereignty in Cross-Border AI

Legal · 3 min read

Cross-border AI raises a question that is easy to defer and expensive to get wrong: where does the data live, which law governs it, and under what terms may it move. The answer is rarely a single location, and rarely the same across an organisation.

Map the data, then the law

Start with the flows. A model may be trained on data collected in one country, fine-tuned on data from another, served from a third, and monitored from a fourth. Each hop is a transfer, and each jurisdiction it touches may impose duties. Producing a data sovereignty map — the systems, the data categories, the locations, and the transfer mechanisms — turns an abstract legal question into a concrete register that can be reviewed and updated as deployments change.

Two families of regime commonly apply. Consent-and-localisation regimes, in the style of India's data-protection law, attach duties around purpose limitation, consent for processing, and in some cases requirements to keep certain data within national borders. Transfer-safeguard regimes, in the style of the GDPR, permit cross-border movement but require a lawful mechanism — adequacy, contractual safeguards, or a defined derogation — and place conditions on onward transfers. A single AI service can be subject to both.

Embed sovereignty in procurement and design

Sovereignty is decided in architecture and contracts, not in a legal memo after launch. Model hosting region, sub-processor lists, data residency commitments, deletion on termination, and the right to audit are commercial terms that determine whether a deployment is lawful. Build them into vendor due diligence and into the design of systems you build yourself. Where a provider cannot commit, that is a design constraint, not a legal formality.

• Maintain a data sovereignty map as a living register, reviewed when deployments change.
• Classify data by category and sensitivity before choosing a region or provider.
• Match the transfer mechanism to the regime — consent and localisation duties differ from adequacy and contractual safeguards.
• Contract for residency, deletion, sub-processors, and audit rights up front.

Govern the ongoing position

The practical trap is treating sovereignty as a question of where the server sits. Residence of stored data is one variable among several; access, support, and telemetry can cross borders even when the primary store does not. Vendor support staff, remote monitoring, and model updates are all potential transfer points, and they belong on the map alongside the data store itself.

Sovereignty is not a launch checkpoint. Providers move infrastructure, sub-processors change, and the data an AI system touches grows over time. Assign ownership of the map, tie it to procurement and change processes, and revisit it at contract renewal. Where the law is unsettled, record the position taken and the reasoning, so a future reviewer can see the judgement rather than guess at it. This is guidance on practice; specific obligations depend on the jurisdictions involved and should be confirmed with counsel.

Questions to ask

• Do you have a current map of where AI data is stored, processed, and transferred?
• Which regimes apply to each flow, and what mechanism legitimises each transfer?
• What do your contracts say about residency, sub-processors, deletion, and audit?
• Who owns the map, and when was it last reviewed?

Preparing for an AI Audit

Checklist · 3 min read

An AI audit asks a deceptively simple question: can you show what your system does, how you know it works, and what you would do if it did not. Readiness is not a scramble before scrutiny; it is the by-product of running systems with evidence from the start.

What auditors look for

The precise scope varies by regulator, sector, and system, but the underlying evidence categories are stable. An auditor wants to see that the system is documented and owned, that its performance and risks have been assessed and are monitored, that decisions can be explained, that data use is lawful, and that there is a functioning process for remediation when something goes wrong. These are the same artefacts good governance produces; audit readiness and good practice are the same work seen from different angles.

Build readiness continuously

Organisations that pass audits comfortably are those that treat documentation as part of building the system, not as an exercise before review. Model cards, decision logs, and monitoring dashboards are produced as systems are built and updated, so the evidence exists when it is requested. Where it does not, reconstructing it after the fact is slow, incomplete, and exposes gaps that were avoidable.

• Keep documentation with the system, in version control, updated on change.
• Set baselines before deployment, so drift has something to be measured against.
• Log decisions and overrides automatically, not by hand.
• Run internal reviews on a cadence, and record what you fixed.
• Own each system explicitly, with a named accountable person.

Practise before you are tested

A common failure is evidence that exists but cannot be connected: a model documented in one system, its monitoring in another, and its approvals in an email trail nobody can retrieve. Auditors ask for a chain, not a pile. Design the record so a system, its changes, its decisions, and its reviews can be pulled together from one place, in an order a reviewer can follow.

A periodic internal audit — even a light one — surfaces the questions an external reviewer will ask while there is still time to answer them. Treat findings as a remediation backlog with owners and dates, and close the loop by re-checking. The goal is not a perfect record but an honest, current one, and a demonstrable process for acting on what it shows.

Questions to ask

• Could you produce documentation for every live AI system today?
• Do you have baselines, and is drift monitored against them?
• Are decisions and overrides logged automatically and retained?
• Is there a named owner, and a tested remediation process, for each system?