AI governance: a living register, evidence attached, decisions signed
Inventory every AI use case, assign accountable owners, assess risks and build audit-ready evidence — without outsourcing legal or business decisions. The agent connects AI systems, models, suppliers, data, evaluations, approvals, incidents and deadlines in a living register. Material conclusions remain sourced, explainable and subject to accountable human review.
Updated on
A Blue Lemon Agent AI governance agent keeps the living register of your systems, models, versions and suppliers, connects risks, requirements, controls, evidence and deadlines, and prepares your regulatory qualifications with their dated sources. On screen and in exports alike, it separates what is established, what is assumed, what is proposed and what has been decided. Qualification, risk acceptance and go-live authorisation are signed by your accountable people, named and dated.
Reference points describing our offer, not results measured at a client. The scale of the gain on systems inventoried and on the time taken to prepare an audit file is confirmed by a pilot.
What does an AI agent bring to the governance of your AI systems?
Organisations rarely know how much AI they run, who answers for it, and where the evidence sits. The question always lands at the worst moment: an audit, a client, an authority.
! What is at stake
Governing AI requires three mechanical things, and that is exactly what makes them tractable: knowing what is running, knowing who answers for it, and being able to show the evidence attached to the right version. Today those three live in spreadsheets, mailboxes and people's heads. Rebuilding the picture takes weeks, and it is out of date the day it is finished. The agent keeps it continuously: every system carries its purpose, owner, version, supplier and dated evidence; every rule cited carries its address, its consultation date and its version.
✓ Our answer
The AI committee, the executive team and the control functions work from one shared body of material, dated and traceable, instead of rebuilding the inventory for every request. What the agent has prepared is visibly distinct from what has been decided: a proposed classification carries the label "not approved" everywhere, exports included. Qualifying under the regulation, accepting a residual risk, authorising a go-live and notifying an authority are binding acts: they stay signed by the accountable people, named and dated. Local inference or an isolated resource hosted in France.
What the register holds, and what it never holds
A governance register holds system metadata. That is an architectural rule, and it protects your data as much as your exposure.
Local inference
The agent can run on a machine of your own: no register data and no audit file leaves your network.
Metadata, not your data
The register holds a system's name, purpose, version, supplier and owner — never the data that system processes.
Evaluation datasets stay with you
A test set containing personal data stays on your side. The register keeps its reference, its protocol and its result.
Access by role and by entity
Qualifying, accepting a risk and authorising a go-live are named roles, separate from the role that enters data. No implicit cross-entity access.
Every rule carries its source
Address, consultation date and version. A rule without those three is not applied by the agent.
Full, reversible export
You take your whole register back in an open format, with no dependency on the tool.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
See the agent at work
4 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
The company in this demonstration
Fictional companyVaubrenne Mutuelle — a mutual health and protection insurer, six legal entities including a union and two brokerage arms
- Sector
- Personal lines insurance: individual and group health cover, protection, direct settlement and a care provider network
- Headcount
- 1,400 staff, including a nine-strong risk function, a head of compliance and an actuarial team of six
- Members served
- 620,000 people covered, 4,300 group contracts, and two managing general agents under delegated authority
- Orders of magnitude
- 4.1 million claims processed a year, 38,000 complaints, 37 declared AI use cases across nine suppliers and four environments
- Tools in place
- Model inventory kept on a spreadsheet by the risk function, claims system, configuration database, contract vault, complaints tool, internal control document store
- Who decides
- The head of compliance settles every regulatory qualification; the risk committee accepts residual risks and authorises go-lives; the technical director approves any model touching pricing or the assessment of a benefit claim
- Room for improvement
- Five use cases are declared two or three times under different names depending on the entity, eight records are incomplete, and four of the 22 controls have no evidence dated within the last twelve months
Vaubrenne's risk committee has always overseen its actuarial models, with independent validation and a file for each. AI came in through other doors: automated claim reading, complaint triage, assistance with protection claim assessment, fraud detection. Those use cases have no file, and three of them bear directly on a member's access to a benefit. The last stocktake requested by the reinsurer took the head of compliance eleven days. The agent is connected to four internal sources and works continuously; every qualification, every risk acceptance and every go-live authorisation goes through the person who answers for it.
This company, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real client.
The five duplicates, and where I get them from:
· Three entities declare the same claim-reading engine under three in-house names — "Health OCR", "Claim Reader", "Benefits Flow". Same supplier, same version 4.2, same contract number in your vault.
· Two complaint-triage use cases are a single deployment, seen from the parent mutual and from the union.
The eight incomplete records, field by field: four with no named owner — two of them at your managing general agents under delegated authority —, three with no written purpose, one with no model version.
The figure that will interest you most is this one: I cover four of the six sources you named to me. Off-framework purchasing and end-user devices are not open to me. I can therefore assert nothing about what sits there, and I would rather that be written down than counted as zero.
What I have already done: the 32 records are drafted, each with the source it comes from and the date of the finding; the eight incomplete ones carry a precise question addressed to their presumed owner. inventory-status_37-declared-32-real.pdf5 duplicates resolved, 8 incomplete records, coverage 4 sources out of 6
⛓ Source · configuration database, contract vault, complaints tool, internal control document store
Delegated authority moves the execution, not the duty to know what runs on your members. So for each of the two use cases I have built three lines: what the delegation agreement says, what the agent declares, and what I can verify myself.
· Agent A — pre-assessment tool for pre-authorisation requests. The delegation agreement mentions no automated processing. The agent has declared it since March. A contractual gap, not an inventory gap: the clause did not follow the tool.
· Agent B — incoming document classification. Declared, documented, version known. Nothing to report, and that is worth knowing too.
The possible roles are prepared, not settled: depending on whether you supply the tool, mandate it in the contract, or the agent chose it alone, the role you hold under the regulation changes — and with it your obligations. I have written the three hypotheses with their consequences; your head of compliance settles which one applies. delegated-authority_roles-to-settle.pdf2 use cases, 3 role hypotheses each, consequences in obligations duplicates-reconciled_5-rows.csv3 confirmed by contract, 2 by deployment identifier
⛓ Source · delegation agreements, declarations from both agents, configuration database
For the four use cases with no owner, I have found who signed the contract, who raised the installation ticket, and which department calls the service most often — three indications, never a conclusion. Each message names the most likely candidate and asks them to confirm or point to the right person.
The message is written, the list is made, the send awaits your mandate. You set the list, the tone and the date; I follow up at day 7 and day 21, and I report the response rate back to you.
Data and rights — the first question your DPO will ask, and I have already worked it through: of the 32 real use cases, 19 process members' personal data. For each one I have brought together the stated purpose, the declared legal basis, the announced retention period and whether a transfer outside the Union takes place, and I have set against it the line of the record of processing your DPO keeps. It exists for 14. The other five are AI use cases that no declared processing activity accounts for: I hand them to the DPO by name, with the source that surfaced them and the date of the finding. The record of processing stays theirs — I do not keep it, I give them what they were missing to keep it.
What I do on top, and that nobody has time for: I watch new supplier contracts and new application endpoints continuously. A use case opened next month by the commercial division will appear in your register without anyone having to think about it, with the source that flagged it and the date.
⛓ Source · contract vault, installation tickets, application service call logs
Four reasoned proposals, labelled "proposal — not approved": for each, the decision tree worked through, the rule cited with its address, its consultation date and its version, and the part of my reasoning that rests on an assumption rather than on a fact you gave me.
Two files I am not putting to you, and I tell you exactly why:
· Assistance with protection claim assessment — sick leave and disability. The affected population is described nowhere, and above all: depending on whether the tool proposes a route that a case handler arbitrates, or conditions access to the benefit, the reading changes entirely. One question, a single one, for the benefits director.
· Drafting assistant for member correspondence — the supplier does not publish whether its model is a general-purpose AI model. I have written the question to put to them, with your contract reference and the clause that entitles you to ask.
The applicable timetable, as I read it on 7 September 2026: transparency rules have applied since 2 August 2026; the rules on general-purpose AI models and on governance, since 2 August 2025; those for high-risk systems in Annex III are set for 2 December 2027, and those for systems embedded in regulated products for 2 August 2028. six-qualifications_4-proposed-2-pending.pdfTree worked through, dated sources, assumptions flagged, reservations named
⛓ Source · European Commission, "Regulatory framework for AI", consulted 07/09/2026 · Regulation (EU) 2026/1744
Regulation (EU) 2026/1744, adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and in force on 27 July 2026, moved two deadlines: the obligations for high-risk systems in Annex III to 2 December 2027, and those for systems embedded in products under Annex I to 2 August 2028.
What it did not move: 2 August 2026 remains the general date of application of the regulation. And two obligations have bound you since 2 February 2025: prohibited practices, and the AI literacy duty in Article 4, whose supervision by national authorities began on 2 August 2026.
What that changes for you, concretely: your two use cases that would approach Annex III — protection claim assessment and individual pricing — have time ahead of them, and that is time to build the file, not time to wait. Your duty to train the case handlers and advisers who use these tools is already running. You have 214 people in daily contact with one of them, and I hold the record of what has been done for them: three sessions, 41 people.
I have reproduced the six deadlines in the appendix, each with the address consulted and the date. regulatory-timetable_dated-sources.pdf6 deadlines, each with its address and consultation date ai-literacy-log_214-people-41-trained.csvSessions, attendees, tools concerned, people still to cover
✎ Framework · Regulation (EU) 2024/1689 and Regulation (EU) 2026/1744, sources recorded 07/09/2026
With 11,000 member files a year, the deciding point is no longer volume: it is whether the tool proposes a route that a case handler arbitrates, or conditions access to the benefit. I have gone back over six months of your logs: out of 4,180 pre-assessed files, 118 were rerouted by a case handler after the proposal, that is 2.8%.
And this is why I give you that figure rather than an opinion: a 2.8% override rate reads two opposite ways — either the tool proposes well, or the override is no longer genuinely exercised. The test that settles it takes two weeks: record, on the files ahead, the time the case handler spends before approving. Under a few seconds, the override is formal; beyond that, it is real.
A sector benchmark, and I give it as indicative: on comparable assessment chains, published override rates most often sit between 5% and 15%. You are below, and that deserves to be explained before it is defended — either your files are more uniform than average, or the override has eroded.
The proposed qualification is written under both hypotheses, each with its consequences in obligations. Your head of compliance signs, and the file reaches them with both branches already worked through, not with a question. protection-claims_file-with-two-branches.pdf2.8% override measured, two qualifications worked through, one test proposed
⛓ Source · protection pre-assessment tool logs, six months, 4,180 files
· Three risks have no control against them — including silent drift of the fraud detection engine after a supplier update you do not control.
· Four controls have no evidence dated within twelve months. They are written, they may well be applied, but nothing shows it. To your internal control function as to the reinsurer, a control with no recent evidence is worth an absent control, and that is the kind of gap fixed in a week if you see it in time.
· Two controls cover a propensity-scoring model withdrawn from service in February. I propose archiving them rather than counting them.
What I have already done: for the four missing pieces of evidence, I have identified who holds the document and drafted the request. For the three uncovered risks, I have written three candidate controls, each with the evidence it would produce and the time cost of running it — between two and six hours a quarter. You choose on figures. risk-control-map_14-22.pdf3 risks with no control, 4 expired pieces of evidence, 2 controls to archive candidate-controls_3-proposals.pdfEvidence produced and running cost quantified for each
⛓ Source · 14 risks, 22 controls, dates of the latest evidence taken from the internal control document store
The protocol, versioned: 640 claim files drawn from your last twelve months, pseudonymised, four families — routine treatments, atypical treatments and rare provider types, degraded wording, and expected refusal on out-of-scope files.
Results on version 5.0, against your 4.2 in service:
· routine treatments: 94.1% against 92.6% — the new version does better;
· atypical treatments: 71.3% against 78.0% — it does worse, and the gap is clear;
· degraded wording: 88.4% against 88.1%, not significant at this volume;
· out-of-scope refusal: 99.2% against 99.4%.
What that means for a member, and this is where it counts: a drop on atypical treatments means fraud flags on files that are not fraud, and therefore delayed reimbursements for people who have done nothing wrong.
What this dataset leaves out, and it must be said: the 640 files come from your past. A treatment that has never come up with you is not tested.
My proposal: move to 5.0 on routine treatments, keep 4.2 on the atypical queue until a second campaign. The risk committee authorises, and the authorisation will carry its name, its date and this reason. evaluation_v5-0-against-v4-2.pdf640 files, 4 families, thresholds written in advance, dataset limits named evaluation-protocol_v3.pdfAuthorised datasets, pseudonymisation, thresholds, reproduction conditions
⛓ Source · evaluation campaign, 640 pseudonymised files, protocol v3, thresholds set before execution
· The decision: move to 5.0 on routine treatments; keep 4.2 on the atypical queue.
· Who: the risk committee, today's sitting, with the technical director approving the model side.
· On what: evaluation report v3, its four families of results and its written limits.
· The reservation: a second campaign on atypical treatments, deadline set, owner named.
· The rollback: 4.2 stays deployed and reachable; the reverse switch is written and tested.
What the change log keeps, and it is not the decision: the version you leave, the version you move to, the impact analysis that said what had to be revalidated, the approvals this circuit requires — the risk committee for the risk, the technical director for the model — and the tested rollback plan. Three lines of that log still carry a revalidation pending; they stay visible until it is done, and that is the only way a forgotten revalidation does not pass for a completed one.
What I have armed without asking, because it undoes with a word: an alert if the flag rate on atypical treatments exceeds 4.2's by half, and a freeze on any supplier update until the second campaign has taken place. Both are undone from the version screen, and the removal is logged exactly as the setting was.
Why those two and no others: they protect the member, not the indicator. A wrongful fraud flag costs somebody something; a dashboard costs nobody anything. go-live-decision_v5-0-with-reservation.pdfDecision, signatory, date, reason, reservation, rollback plan
✎ Framework · decision log, one entry per approval, sealed after signature
The timeline, linked to the exact version:
· 08:12 — first report from the member contact centre;
· 08:31 — I traced version 5.0 of the triage model deployed on 2 September at 22:40 and isolated the window: every misfiled complaint post-dates it;
· 08:47 — population measured: 47 members, 9 of whom still have an open complaint, out of 1,240 complaints received in the window.
What produced the gap: the wording "cover refused" was linked by 4.2 to the vocabulary of refusals; 5.0 links it first to the vocabulary of information requests. This is exactly the atypical family where the evaluation gave 71.3% against 78.0% — the committee's reservation was on this point, and it was right.
What I have already done: the 9 open complaints are at the head of the queue, the other 38 are identified with their actual handling date, the corrective plan is written with its owner and deadline, and the draft letter to the members concerned is prepared. Nothing has gone out: the decision to write to a member is yours, and the screen gives you the two elements that govern it — the number of members affected and how long their complaint sat waiting.
This file joins your incident register, and it is not alone there: four incidents opened over twelve months — two closed with their corrective actions verified, one closed with no evidence of verification, which I have reopened while writing to whoever holds the missing item, and this morning's. Every corrective action carries its owner, its deadline and the evidence that closes it: without that evidence the incident stays open on screen, even when everyone believes it settled. incident-file_47-misfiled-complaints.pdfTimeline, version 5.0, population 47 members, corrective plan, letter prepared
⛓ Source · deployment log, complaint triage log, 1,240 complaints in the window
What it contains: the 32 real systems with their purpose, owner, version and supplier; the six qualifications, with the four approved kept separate from the two still pending; the 14 risks and 22 controls, each with the date of its latest evidence; the evaluations and their limits; the risk committee's decisions, each with its signatory and reason; today's incident and its corrective plan; the two use cases under delegated authority and the role still to settle; the schedule at 30, 60 and 90 days; the record of your awareness activities.
What the first page states, deliberately: this document is a file; it is neither a certification nor an attestation of conformity. Those acts belong to the conformity assessment procedures and to the competent authorities. A file presenting itself as a certificate would turn against you at the first inspection.
And what it admits: inventory coverage is four sources out of six, and the two missing ones are named. A stocktake that hides its blind spots is not a stocktake — and a reinsurer who finds the blind spot alone draws a far worse conclusion than the one you would have handed them. governance-file_vaubrenne-mutuelle.pdf32 systems, 6 qualifications, 14 risks, 22 controls, signed decisions, blind spots named risk-committee-dashboard_indicators.csv10 descriptive indicators, with no guarantee and no market comparison
⛓ Source · full register as at today, every line linked to its source and its date
· Stocktakes on request: eleven last year — internal control, statutory auditors, the reinsurer, the two managing general agents and six group contracts of over a thousand employees. Eleven days for the first, four on average thereafter: 386 hours. What remains with the agent is the read-through: 44 hours.
· Manual listing of deadlines and expired evidence: 96 hours last year, carried by the head of compliance. The schedule returns them continuously.
· Rebuilding the inventory at every change of perimeter: 118 hours, most of which disappears.
That is 600 hours today against roughly 60 left by hand: 540 hours returned, more than fifteen weeks of work on the statutory basis of 35 hours — rounded down, and I prefer it that way.
What this calculation leaves out, and must be weighed against it: the agent creates new work where there was none. The four expired pieces of evidence, the three uncovered risks and the delegation clause that did not follow the tool existed before me; nobody could see them. Dealing with them will take time you were not spending. That is a cost, and it is the exact counterpart of the gain.
The next step I propose: open the two missing sources — off-framework purchasing and end-user devices. That is the only move that shifts coverage, and until it is made, your inventory remains an inventory of four sources out of six. year-review_600h-against-60h.pdfBreakdown item by item, new work created counted against it who-decides-what_allocation.pdfWhat the agent triggers alone, what awaits a signature, and how each action is undone
⛓ Source · time records from compliance and internal control, last twelve months · statutory basis 35 h a week
Your case is not here? That is exactly what a 15-minute conversation is for. Book the free audit →
What does the agent actually do?
Eleven modules included in the core offer. All operate in support, under the approval of the people you name.
Discovery and inventory
Reconciles the sources you open to it, de-duplicates, flags incomplete records and runs confirmation campaigns with the owners.
Register of systems and models
System, model, version, deployment and use lineage, with a dated history and a dependency map.
Roles and accountabilities
Prepares the role held under the regulation, builds the responsibility matrix and names the points left to settle.
Regulatory qualification prepared
Works through the sourced decision tree, returns a reasoned proposal with its reservations, and flags missing information.
Risks, requirements, controls and evidence
Connects each risk to its requirements, controls, evidence, owner and deadline.
Data and rights
Reconciles sources, purposes, legal bases, retention and transfers with the record held by your DPO, and hands over to them.
Evaluations before go-live
Versioned protocol, authorised datasets, thresholds written in advance, reproducible results with their gaps and their limits.
Suppliers and general-purpose AI models
Checks the completeness of the supplier file, tracks dependencies, restrictions, reversibility and announced changes.
Approvals, changes and versions
Impact analysis, revalidation requirements, approval workflow, change log and rollback plan.
Incidents and corrective actions
Triage, timeline, linkage to the deployed version, action plan and follow-up to closure.
Evidence file, deadlines and AI literacy
Regulatory deadline schedule, log of awareness activities and an exportable audit file.
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
DPO / GDPR support
The record of PROCESSING activities, impact assessments and processor monitoring belong to the DPO support agent. This agent keeps the register of AI SYSTEMS, including those that touch no personal data at all. When an AI use does touch it, this agent flags it and hands the line to the DPO: it does not keep a second record of processing.
DPO / GDPR support from 668 € excl. VAT / month Discover the agent →Regulatory control
Applying a rulebook to documents and returning qualified findings is the business of the regulatory control agent. This agent inventories the system, cites the rule with its address and version, and names the question to be settled; the regulatory control agent then answers it on the documents.
Regulatory control from 721 € excl. VAT / month Discover the agent →Cybersecurity & logs
Correlating events and running the technical investigation of a security incident belong to security monitoring. This agent ties the incident to the deployed model version and follows the corrective action through to closure: a handover, not a duplicate.
Cybersecurity & logs from 601 € excl. VAT / month Discover the agent →End-to-end contracts
Drafting, negotiating and tracking a clause is the business of the contracts agent. This agent reads a model's supplier file — documentation, usage restrictions, announced changes, exit terms — and flags what is missing or what the contract failed to follow.
End-to-end contracts from 702 € excl. VAT / month Discover the agent →In 15 minutes we identify the most relevant agent — without oversizing the project.
How long does preparing a file take today?
By keeping the inventory and the evidence current, effort shifts towards the decisions that need an accountable person. The scale of the gain depends on your portfolio and is confirmed by a pilot.
The stages of your AI agent project
Audit & scoping
15 minutes to target the use case with the best return.
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
Design
We design the agent and its guardrails.
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
Rollout
Going live and training your team.
Operation
Continuous supervision and improvement.
On quotation
Scoping, perimeter, integrations and level of oversight to be confirmed. The price depends on the number of systems, entities and connected sources: it is set after a scoping session, never before.
Four commitments that matter for your governance
Related resources
Your questions, our answers
Does the agent certify compliance with the AI Act?
Can it detect every AI used across the organisation?
Does it replace the GDPR record of processing?
Can it handle external suppliers' models?
How are decisions controlled?
Can sensitive data be used?
Other agents for compliance
Let us scope your AI portfolio
15 minutes to scope your systems, entities and sources — hosted in France, supervised, no commitment.