AI Governance Consulting: Insurance Group Case Study

Executive Summary

AI governance consulting was brought into a European insurance group after an internal audit asked a simple question that nobody could answer. Which artificial intelligence systems are in production, who owns them, and what happens when one of them is wrong? Six generative AI pilots had reached real users without passing through any control gate.

The group had a written responsible AI policy. It had been approved a year earlier and referenced in board papers. No delivery team had ever used it, because it described principles rather than decisions.

YlogX ran a discovery exercise across business units, then built a risk tiered control model that maps each system to a defined set of obligations rather than to a general commitment.

Discovery found nine systems rather than the four the executive team expected. Two had no identifiable owner. One was summarising claims correspondence with no logging of its outputs at all.

The programme delivered an inventory, a tiering model, an evaluation harness, human oversight requirements per tier, and a decommissioning route. Projected outcomes include an estimated 60 to 70 percent reduction in the time taken to approve a new use case.

Could your team produce a list of every AI system in production today? Talk to us.

Client Overview

The client is a mid sized insurance group operating across the United Kingdom and two European markets, writing commercial lines and specialty risk. It runs a central data function and several business unit technology teams.

Technology delivery is federated by design. Business units can commission their own work, which had made the group faster than its peers at getting generative AI in front of users.

That same structure meant central functions had no reliable view of what had been built. Procurement saw software purchases, not internally assembled systems using an existing model subscription.

The group already had mature governance for actuarial and pricing models. Those controls had been built over years and were genuinely respected internally.

None of that model governance applied to generative AI, because the existing framework assumed a statistical model with a defined training set, a validation report and a named model owner.

Business Challenges

This was not a case of a business ignoring risk. It was a business whose existing controls had been designed for a different kind of model, and whose speed came from a structure that made oversight difficult.

Four problems surfaced during discovery, and the first one made the other three invisible.

Why could nobody list the AI systems in production?

Because there was no register, and because the usual detection method does not work for generative AI. Procurement catches a software purchase, but not a system assembled internally on an existing model subscription.

Two of the nine systems found had been built by business analysts rather than engineers, using tools already licensed to the group.

Neither had gone through architecture review, because neither had required infrastructure or a new supplier. Nothing had been circumvented, the process simply had no trigger.

Discovery had to be run as interviews across business units rather than as a query against a system, which is slower and is the only reliable method at this stage.

Why did the responsible AI policy have no effect?

It described principles. Fairness, transparency, accountability and human oversight are all correct and none of them tells an engineer what to do on a Tuesday.

There was no mapping from a principle to a control, and no way to tell whether a given system needed one control or ten.

The policy also had no owner in delivery. It sat with a risk function that had no visibility of what was being built.

Teams that read it came away unsure whether it applied to them, and in the absence of a trigger they reasonably concluded it did not.

Why did the existing model governance framework not cover GenAI?

The framework assumed a model with a defined training set, a validation report, measurable performance against a holdout and a named model owner in the actuarial function.

A generative system built on a third party foundation model fits almost none of those assumptions. There is no training set to review and no single accuracy number to validate.

Attempts to force generative systems through the existing gate had stalled twice, because the validation template could not be completed honestly.

That failure had an unintended consequence. Teams learned that the formal route did not work, so they stopped attempting it.

What was the actual exposure?

One system was summarising claims correspondence for handlers with no logging of inputs or outputs. If a summary had been wrong, there was no way to reconstruct what it had said.

Another was drafting customer communications from policy documents, with no evaluation set and no recorded behaviour for questions outside its scope.

Two systems had no owner at all. The people who built them had moved roles, and no handover had happened because no register existed to trigger one.

None of this had caused a known incident. The exposure was that the group had no means of detecting one, which is the finding that moved the board.

Not sure whether your model governance framework covers generative systems? Read more at AI consulting capability.

Business Objectives

The instruction from the audit committee was to get control without stopping delivery. That second half mattered as much as the first, and it shaped every design decision in the programme.

What did the group need to be able to prove?

That it knows what is running. A current inventory with a named owner against every system was the first and most basic requirement.

That each system carries controls proportionate to what it actually does, rather than a single heavy process applied to everything equally.

That outputs affecting a customer can be reconstructed after the fact, which means logging and retention rather than principles.

And that a system can be stopped. The absence of a decommissioning route was as serious a finding as the absence of a register.

Why was speed of approval treated as a governance objective?

Because a slow gate is the reason teams route around governance. The two stalled attempts had taught the organisation that the formal path did not work.

Making approval fast for low risk uses is what buys the right to be demanding about high risk ones.

Tier one registration was designed to take minutes and to require no committee at all. Most internal productivity uses land there.

The heavy controls were reserved for systems that inform a decision about a person, which is a much smaller set than the group expected.

What defined success for this programme?

A live inventory that stays current without a quarterly chase, because a register that decays is worse than none at all.

A tiering decision that a delivery lead can make themselves in under an hour using a documented question set.

Evaluation results and refusal behaviour recorded for every tier two and tier three system, so oversight has evidence rather than assurances.

And measurable reduction in approval time, which was tracked from the first month as the honest indicator of whether teams would cooperate.

Want approval to take days rather than quarters? Start a conversation.

Solution Strategy

The programme inverted the usual order. Inventory first, tiering second, controls third, policy last. The written policy was rewritten at the end to describe what had actually been built.

Existing frameworks were mapped rather than replaced, because the group had spent years earning internal respect for its model governance.

How does AI governance consulting build a system inventory?

Through structured interviews across every business unit, using a question set designed to surface systems people did not think of as AI.

Asking what AI systems are you running produces a short list. Asking where does software write text that a person then sends to a customer produces a longer and more accurate one.

Model subscription usage logs were reviewed alongside the interviews, which surfaced two systems nobody had mentioned.

Every entry carries an owner, a business purpose, the data it touches, whether it affects a decision about a person, and its current tier.

How does risk tiering work in practice?

A delivery lead answers a documented question set. The questions are factual rather than judgemental, which is what makes the outcome consistent between teams.

The decisive question is whether the system informs or influences a decision affecting an individual. That single answer moves a system from tier two to tier three.

Tiering is recorded with the answers, so a later reviewer can see why a system landed where it did rather than having to retake the decision.

Systems are retiered when their purpose changes. A summarisation tool that starts being used to support a claims decision has moved tier, whatever its original design.

What controls were attached to each tier?

Tier one requires registration and an owner. That is deliberately all, because most internal productivity use carries little risk and heavy process there destroys credibility.

Tier two adds input and output logging, an evaluation set with a documented pass threshold, disclosure to the user, and quarterly review.

Tier three adds human review before a decision takes effect, recorded refusal behaviour, fairness testing, retention, an approved fallback and monthly review.

Nothing in the model is novel. The value is that every obligation is attached to a tier rather than left to interpretation.

How was evaluation made concrete?

Each tier two and tier three system got an evaluation set drawn from its own real traffic, reviewed and labelled by the business team that owns it.

Refusal behaviour was tested explicitly. A claims summarisation system should decline to answer a coverage question, and that behaviour is asserted rather than hoped for.

Results are recorded per release. A system that drops below its threshold does not ship, which is the same discipline the group already applied to pricing models.

The harness runs in the delivery pipeline rather than as a governance activity, so it produces evidence without requiring a separate meeting.

How were systems decommissioned?

Two systems had no owner and no surviving business case. The route for stopping them had to be invented, because the group had never retired an AI system before.

Decommissioning covers user notification, data retention decisions, log preservation and removal of access, in a defined order.

Both were stopped within the programme. Nobody objected, which suggested the systems had been running on momentum rather than need.

The route now exists as a standing process, and its absence is treated as a governance gap wherever it is found in other organisations.

Need a tiering model your delivery teams will actually use? Read more at generative AI capability.

Frameworks and Tools Used

Nothing was invented where a published framework already existed. The group is regulated, and defending a bespoke approach to a supervisor is harder than defending a recognised one.

Which external frameworks were mapped?

The NIST AI Risk Management Framework provided the functional structure, since its govern, map, measure and manage functions map cleanly onto an operating model.

ISO and IEC 42001 was used as the management system reference, because the group intends to seek certification and wanted the control set aligned from the start.

The European Union AI Act shaped the tier definitions, given that the group writes business in two European markets and expects obligations to apply by risk category.

The OWASP guidance on large language model application risks informed the technical control set, including prompt injection and data leakage considerations.

How were existing internal controls reused?

The model governance framework already in place for actuarial and pricing work supplied the committee structure, the escalation route and the review cadence.

Reusing it mattered politically. A new parallel governance structure would have competed with a respected one and probably lost.

What changed was the validation approach. A generative system is validated on behaviour against an evaluation set rather than on a training set review.

The model owner role was extended rather than duplicated, so accountability language stayed consistent across statistical and generative systems.

What tooling supported the programme?

The inventory lives in the existing governance register rather than in a new tool, which removed an adoption barrier and a licence discussion.

Logging uses the group's existing observability platform, with retention configured per tier rather than uniformly.

The evaluation harness runs in the same delivery pipeline the engineering teams already use, invoked as a stage rather than as an external gate.

Dashboards report inventory coverage, evaluation pass rates and overdue reviews. Those three numbers go to the audit committee each quarter.

Implementation Process

The programme ran about twenty weeks. Discovery was the longest phase and the one most often underestimated, because it depends on people volunteering things they may not want to disclose.

The tone set in the first two weeks determined how much the discovery interviews actually surfaced.

How was discovery run without triggering defensiveness?

By stating clearly and repeatedly that nothing found during discovery would be treated as a breach. Amnesty was explicit and it was honoured.

Interviews were framed around what the software does rather than around whether it counts as artificial intelligence, which is a definitional argument nobody needs.

Business analysts and operations leads were interviewed alongside engineers, since two of the nine systems had been built outside engineering entirely.

The two ownerless systems only surfaced because a colleague mentioned them in passing. Discovery is a social exercise before it is a technical one.

How was the tiering model tested before rollout?

It was applied retrospectively to the nine discovered systems, then to four historical use cases that had been approved or rejected under the old process.

Two of those historical decisions came out differently under the new model. Both differences were examined and the model was adjusted once.

Delivery leads from three business units then tiered a system each without assistance, to test whether the question set produced consistent answers.

Consistency was the acceptance criterion. A tiering model that different people apply differently gives the appearance of control without the substance.

How were the high risk systems remediated?

The claims summarisation system received logging, an evaluation set built from real correspondence, recorded refusal behaviour and a human review requirement before any summary informs a decision.

The customer communication drafting system received the same controls plus a disclosure change, since customers had not been told the drafting was assisted.

Remediation was sequenced by exposure rather than by ease. The system with no logging went first because it was the one that could not be reconstructed.

Both systems stayed in production throughout. Stopping them was considered and rejected, because the operational disruption outweighed the assessed risk once logging was in place.

How was the programme handed over?

Ownership sits with the existing model governance function, extended rather than replaced, with a named lead for AI systems specifically.

Delivery leads own tiering for their own systems, with quality assurance sampling rather than central re approval.

The audit committee receives three numbers quarterly, which was chosen over a detailed report that nobody would read consistently.

A rediscovery exercise runs every six months, because a federated organisation will keep producing systems that nobody registered.

Handover included a written operating guide for the AI systems lead, covering the tiering question set, the review calendar and the rediscovery method.

Have systems in production that nobody has evaluated? Talk to us.

Business Results

The figures below are estimated business outcomes, modeled on the engagement scope and on published benchmarks for comparable governance programmes. They are projections rather than audited client results.

Findings from discovery are stated as counts, because those were observed during the work rather than modeled.

What did discovery actually find?

Nine generative AI systems in production or in front of real users, against an executive expectation of four.

Two systems with no identifiable owner, both built by people who had since changed roles.

One system operating with no logging of inputs or outputs at all, in a claims context.

Zero systems with a documented evaluation set or recorded refusal behaviour before the programme began.

It also found that no route existed to stop an AI system, and that no system carried a documented owner in the governance register. Both gaps were closed during the programme.

What changed about approval speed?

Time to approve a new use case is projected to fall by an estimated 60 to 70 percent, driven mostly by tier one registration requiring no committee.

Most internal productivity use now clears in the same working day, where previously it either waited for a committee or bypassed the process entirely.

Tier three approvals take longer than before, which is the intended trade. The group accepted that deliberately.

The number of systems reaching production without registration is projected to approach zero, though that will only be confirmed at the next rediscovery cycle.

What changed about oversight quality?

Every tier two and tier three system now has an evaluation set with a documented threshold, where none did before.

Refusal behaviour is asserted and tested rather than assumed, which closed the single largest gap identified in the claims context.

Outputs affecting a customer can be reconstructed, because logging and retention are now configured per tier.

The audit committee receives coverage, pass rate and overdue review figures quarterly, which replaced a narrative report with three numbers.

Overdue reviews are now visible rather than discovered at audit, which changed how business units treat their own review dates.

What changed commercially?

Two systems were decommissioned, releasing an estimated licence and maintenance saving in the low tens of thousands annually. That figure is modeled from comparable retirements.

Preparation time for regulatory and audit information requests is projected to fall by an estimated 40 to 50 percent, because the inventory answers most of the questions directly.

The group considers itself materially closer to an ISO and IEC 42001 certification effort, having built the control set against that reference from the start.

Delivery teams report that the route is now usable, which is the outcome that determines whether any of the rest holds.

Want your AI inventory to answer an audit request directly? Contact us.

Lessons Learned

The written policy was the least useful artefact in the original state and the last one rebuilt. That ordering is the main transferable lesson.

What surprised the client most?

That there were nine systems rather than four. The gap was not concealment, it was that nobody had a definition that would have caught the other five.

That two systems had no owner. Both had been running for months and neither had a person who would have been called if it misbehaved.

That the respected model governance framework was actively harmful here, because its validation template could not be completed for a generative system.

That decommissioning had never been done before, and that nobody objected when it happened.

What worked better than expected?

The amnesty. Stating plainly that discovery findings would not be treated as breaches is what surfaced the systems built outside engineering.

Making tier one nearly frictionless. It bought credibility for the demanding controls at tier three, which nobody argued about.

Running the evaluation harness inside the delivery pipeline. Governance evidence produced automatically is governance evidence that actually exists.

Reusing the existing committee structure instead of building a parallel one. The political saving was larger than the design cost.

Rewriting the policy last also helped. Describing what had been built produced a document people recognised, rather than one they had to interpret.

What would be done differently next time?

Discovery would include model subscription usage logs from day one rather than as a supplement, since that route surfaced two systems interviews missed.

The decommissioning process would be designed early, not when the first ownerless system needed stopping.

Retiering triggers would be defined at the start. A system whose purpose drifts is the most likely future gap and it was addressed late.

The tiering question set would be tested for consistency across business units before any system is tiered, not after the first few.

What should other regulated firms check first?

Ask whether anyone can produce a current list of AI systems in production with a named owner against each. That single question tends to end the debate about whether a programme is needed.

Check whether the existing model governance template can actually be completed for a generative system. If it cannot, teams have already learned to avoid it.

Check whether any customer facing system logs its outputs. Reconstruction after an incident is impossible without it.

Check whether a route exists to stop an AI system. Most organisations have never retired one and have no process for doing so.

Frequently Asked Questions

What does AI governance consulting actually deliver?

In practice it delivers four things. A current inventory of AI systems with named owners, a risk tiering model that delivery teams can apply themselves, a control set attached to each tier rather than to general principles, and evidence that those controls operate. A written policy is the output of that work rather than the starting point.

Why do written responsible AI policies so often have no effect?

Because principles do not tell an engineer what to do. Fairness, transparency and accountability are all correct and none of them specifies whether a given system needs logging, an evaluation set or human review. Without a mapping from principle to control, and without a trigger that tells a team the policy applies to them, the document is never used.

What is risk tiering and why does it matter more than policy?

Tiering sorts systems by what they actually do, using a factual question set rather than judgement. The decisive question is usually whether the system informs a decision affecting an individual. Tiering matters because it lets low risk uses clear quickly while concentrating demanding controls where they are justified, which is what stops teams routing around governance.

Why does existing model risk governance often fail for generative AI?

Because it assumes a defined training set, a validation report and a single accuracy measure against a holdout. A system built on a third party foundation model has none of those. Attempts to force generative systems through that gate stall, and teams learn that the formal route does not work, which drives activity underground.

Which frameworks should a regulated firm map to?

The NIST AI Risk Management Framework provides a workable functional structure. ISO and IEC 42001 supplies the management system reference if certification is intended. Firms operating in the European Union should shape tier definitions around the AI Act risk categories. OWASP guidance on large language model risks is useful for the technical control set.

How do you find AI systems nobody registered?

Interviews, not queries. Asking what AI systems are you running produces a short list. Asking where does software write text that a person then sends to a customer produces a longer one. Model subscription usage logs surface systems that interviews miss. An explicit amnesty, honoured, is what makes people volunteer things.

What is an evaluation harness for a generative system?

A set of representative cases drawn from the system's own real traffic, labelled by the business team that owns it, with a documented pass threshold. It should test refusal behaviour explicitly, since a summarisation system should decline questions outside its scope. Running it inside the delivery pipeline produces evidence without requiring a separate governance activity.

Should ungoverned AI systems be switched off immediately?

Rarely. In this engagement both high risk systems stayed in production while logging and evaluation were added, because the operational disruption outweighed the assessed risk once outputs could be reconstructed. Two other systems were decommissioned, but only because no owner and no surviving business case could be found for either.

How long does a programme like this take?

This one ran about twenty weeks, with discovery consuming roughly a third of it. Discovery is the phase most often underestimated, because it depends on people volunteering systems rather than on querying a source. Remediation length depends entirely on how many high risk systems exist and what state their logging is in.

Are the results in this case study real client figures?

The discovery counts are observed findings from the engagement. The percentage improvements are estimated business outcomes, modeled on the engagement scope and on published benchmarks for comparable programmes, and every one is labelled as projected. Client identity and commercially sensitive details are withheld throughout.

Conclusion

AI governance consulting delivered here by inverting the usual order. Inventory first, tiering second, controls third, and the written policy rewritten last to describe what had actually been built. That sequence matters because the group already had a responsible AI policy, approved and referenced in board papers, that no delivery team had ever used. Discovery found nine generative systems where the executive team expected four, two of them with no owner and one summarising claims correspondence with no logging at all. None of that reflected carelessness. It reflected a control framework designed for statistical models with training sets, applied to systems that have neither. Once tiering existed, most internal use cleared in a day and the demanding controls landed where they were justified. Projected outcomes include an estimated 60 to 70 percent reduction in approval time and an estimated 40 to 50 percent reduction in audit response effort, both modeled rather than measured. The observed findings need no projection. If nobody in your organisation can produce a current list of AI systems with a named owner against each, that is the whole business case.

Figures shown are estimated business outcomes modeled on the engagement scope and on published benchmarks, not audited client data. Client identity and commercially sensitive details have been withheld. Nothing here is regulatory or legal advice.