MLOps, AI Governance & Model Security

Releasing a change stops being an event

A defined path from build to production, with automated checks and a rehearsed way back, turns a model or prompt update into routine work instead of a scheduled risk.

Improvement compounds instead of stalling

When any change can be withdrawn safely, teams change things more often, and the system keeps pace with the business it serves.

The second AI system costs less than the first

Pipelines, registry, deployment patterns and release gates are built once and inherited by every model, application and agent that follows.

Delivery stops depending on one person's machine

Reproducible builds, versioned artefacts and a documented promotion path remove the single point of knowledge most early AI work is quietly built around.

The business can be told what is running and why

A registry and change record answer which version is live, what it was evaluated against and who approved it, without anyone starting an investigation.

Incidents get shorter

Version history, traced execution and a tested rollback mean a bad release is identified and reversed rather than debugged while users wait.

Build

Turn training, packaging and configuration into an automated pipeline that produces the same artefact from the same inputs.

Reproducible build pipeline

Evaluate

Run the checks the artefact must pass before release: quality thresholds, safety and security checks, and regression against prior behaviour.

Pass or fail against agreed gates

Register

Record the artefact with its lineage: the data, code, configuration and results that stand behind it.

Versioned entry in the registry

Deploy

Promote through environments into production using the pattern the workload needs, with rollout criteria stated in advance.

Controlled release into production

Observe

Emit and route the quality, latency, cost and drift signals the owning team needs, with thresholds and alert routing agreed.

Instrumented production system

Govern

Hold the record of what is live, what it passed and who approved it, and enforce who may promote a change at all.

Controlled change record

Improve

Feed findings and triggers into the next build, and release that change through the same gates as the last one.

Repeatable improvement cycle

Is this just DevOps for AI?

It borrows most of its principles and adds the inputs software delivery does not have. Application delivery versions code, while AI delivery has to version data, models, prompts, retrieval configurations and tool permissions as well, because any of those can change behaviour with the code untouched. The release gate differs too: a passing test suite is not the same as a quality evaluation on representative tasks. Where an organisation already has strong application delivery practice, the work is usually extending it rather than starting again.

We have language-model applications, not trained models. Does this still apply?

Yes, and the artefacts are different rather than absent. A prompt, a retrieval configuration, a model version, a set of tool permissions and a guardrail policy each change behaviour, and each needs versioning, review and a way back. Teams usually discover this the first time an untracked prompt edit changes output for every user with no record of what was altered or by whom. The controls are lighter than for trained models, but the discipline is the same.

How much of this do we need at the start?

Less than a full platform, and rather more than most teams begin with. The increments that pay first are version control over everything that affects behaviour, a rollback that has been tested, and a recorded answer to what is live. Automated pipelines, progressive rollout and retraining triggers arrive as the number of systems and the frequency of releases grow. Building an entire platform before the first system is in production is a well-worn way to spend a year without shipping.

Who operates this once it is built?

Your team, unless you ask ARRIX to operate it under a managed arrangement. Handover covers the runbook, the promotion policy, the rollback procedure and an ownership map saying which team is accountable for which system. An operating model without named owners fails quietly: the pipelines keep running, the alerts keep firing and nobody acts on either. Deciding ownership is part of the design work, not an administrative step afterwards.

Does this tell us whether our AI is any good?

It wires the signals and enforces the gate; the depth of the measurement itself is separate work. The concern here is that quality, latency, cost and drift are emitted from the first release, that nothing is promoted without passing an agreed threshold, and that results stay attached to the version they describe. Defining what good enough means for a use case, building representative evaluation sets and interpreting production quality belongs with the evaluation and observability offering. The two fit together: one decides the standard, this one enforces it at the point of release.

Can this work across cloud and on-premises together?

In most estates it has to, and the design assumes it. Pipelines, registry and promotion can span environments while deployment patterns differ by location, and residency or classification rules often decide where a workload runs rather than convenience. What matters is that the record of what is live and how it got there stays in one place, whatever it runs on. Splitting that record across environments is how organisations lose the ability to answer basic questions about their own systems.

The organisation knows what AI it is actually running

A maintained inventory covering what was built, what was bought, what is embedded in existing software and what arrived without approval.

Scrutiny becomes proportionate rather than uniform

Risk classification separates low-consequence uses that may proceed under standing conditions from those needing real examination, so review effort lands where consequences are.

Questions from boards, regulators, insurers and customers have prepared answers

Decisions, conditions and supporting records are maintained as a normal operating record instead of being assembled during the enquiry.

Valuable use cases stop being blocked by unresolved doubt

Where exposure is understood and conditions are met, approval can be given with stated reasons, which is faster than an indefinite pause nobody owns.

Unsanctioned use falls because there is a sanctioned route

A published position on what is permitted, with an approval path people can actually use, removes most of the incentive to work around it.

Accountability is assigned before an incident rather than during one

Each use has a named owner, an approver and a defined response path, so the first hour of a problem is spent responding rather than working out who decides.

Inventory

Find the AI actually in use across built, bought, embedded and unsanctioned sources, and record purpose, owner and data.

AI use inventory

Classify risk

Assess each use by consequence, how far it acts rather than advises, data sensitivity and who is affected.

Risk tier per use

Select controls

Attach a proportionate set of conditions to each tier, covering data, access, testing, oversight and disclosure.

Control set per tier

Assign oversight

Specify where a person reviews, decides or intervenes, and give that person the information, time and authority to do it.

Human oversight specification

Evidence and audit

Make the controls produce records as they operate, and examine those records on a defined cycle.

Retained control records

Respond

Define and rehearse what happens when an AI system fails, harms somebody or is misused.

Tested incident procedure

Enforce and review

Hold the approval route, apply it to new proposals, and revisit classifications as uses and obligations change.

Operating governance cycle

Does this make us NIST certified or ISO certified?

No, and it is worth being precise about why. Control sets can be designed to align with the NIST AI Risk Management Framework, the NIST Generative AI Profile, the NIST Cybersecurity Framework 2.0, the NIST Privacy Framework and ISO/IEC 42001, which means practices are mapped to recognised structures and the remaining gaps are stated openly. NIST publishes voluntary frameworks and certifies nobody against them, so NIST certification does not exist and any supplier offering it is describing something imaginary. ISO/IEC 42001 does have a certification path, but that certificate is awarded to your organisation by an independent certification body after an audit, and aligned controls are preparation for that rather than a substitute for it. Alignment is not certification, and ARRIX will not describe it as such.

Will governance slow our AI programme down?

Badly designed governance does, usually by applying the same review to a marketing draft and a credit decision. Proportionate classification is what prevents that: most uses should proceed under standing conditions with no individual review, so examination concentrates where the consequences are real. The programme also removes a common source of delay, which is a security or legal function declining to approve something because nobody has assessed it. Speed comes from having a decision route, not from having no rules.

We already do model risk management for statistical models. Is this different?

The foundations transfer and some of the assumptions do not hold. Traditional practice assumes a model you can specify, validate against a known distribution and revalidate on a cycle, whereas a language model's behaviour shifts when a prompt, a retrieval source or the underlying version changes. Agents add a further dimension, because the system takes actions rather than producing an estimate for somebody else to act on. The work is usually extending the framework you have to cover behaviour, oversight and action, instead of running a second process alongside it.

How do we handle AI that arrived inside software we already bought?

Treat it as in scope, because your obligations follow the data and the decision rather than who wrote the code. That means recording the feature in the inventory, establishing what data it processes and where that data goes, and asking the supplier what changes when they change the model underneath. Contractual terms deserve real attention here: notice of material model change, whether your data trains anything, subprocessing and retention. Embedded AI is where most organisations find their largest unassessed exposure.

What does human oversight actually mean in practice?

It means a named person with the information, the time and the authority to reach a different conclusion, and it fails when any one of those three is missing. A reviewer shown a recommendation with no reasoning, given moments per case and measured on throughput is producing the appearance of oversight rather than oversight itself. The design work is deciding where review is genuinely required, what the reviewer must see, what they may change and how a disagreement is recorded. Where meaningful review is impossible at the volume involved, that is a finding about the use case rather than a detail to wave through.

Where should we start if we have nothing in place?

Start with the inventory, because every other decision depends on knowing what is in use, and the discovery itself usually changes how people see the exposure. Classify what you find, then attach conditions to the few uses carrying real consequence rather than to everything equally. A short, specific acceptable-use position and a working approval route come next, since together they reduce unsanctioned use faster than any technical control. Formal alignment mapping is more useful once there is something real to map.

Can you assess AI systems we did not build?

Yes, and in most organisations that is the larger part of the work. Assessment covers what the system does, what data reaches it, what it can act on, what oversight surrounds it and what the supplier commits to contractually. Where the internals are not visible, the assessment concentrates on data paths, permitted actions, observed behaviour on representative cases and the contractual position. What you get is an assessed exposure and a set of conditions for use, not a declaration that the system is safe.