Product
Five parts, one file your underwriter can actually work.
RiskBorne turns a vague question — are our AI agents insurable? — into a computed answer with a clause reference behind every line of it.
The insurability scan
Twenty minutes, no integrations, no code.
Six guided steps collect everything the requirement corpus needs to evaluate you. You describe each agent in plain language and the scan structures it for you; you confirm every field before it is stored. Nothing connects to your systems, so nothing has to clear a security review before you can start.
What comes out is an attested record: who said what about which agent, and when. That record is what makes the rest of the product defensible.
- 1Organisation profile — sector, footprint, regulated data
- 2Insurance history — current tower, claims, endorsements in flight
- 3Data & security — controls, retention, access, incident history
- 4Agents — one register entry per agent, with autonomy and audience
- 5Governance — human review, guardrails, drift monitoring, disclosure
- 6Attestation — a named person signs what has been stated
The coverage gap map
See exactly which agent breaks which clause.
Agents across the top, carrier requirements down the side, a verdict in every cell. Open a cell and you get the requirement text, the evidence the carrier expects, the inputs that drove the verdict and the clause reference. Structural exclusions that apply to every insured are banded separately, so you can tell what you can act on from what is simply how the market is written.
Coverage gap map · Meridian Health Partners
index 66 · grade D
| Requirement | Patient Intake | Claims Triage | Provider Copilot |
|---|---|---|---|
| A written AI usage policy is in force across the organisationTestudo · §4.L(i) | Coveredsatisfied | Coveredsatisfied | Coveredsatisfied |
| Vendor guardrails have not been altered or removedTestudo · §4.L(ii) | Coveredsatisfied | Excluded§4.L(ii) | Coveredsatisfied |
| Privacy notices reviewed by counsel where protected data is processedTestudo · §4.L(v) | Coveredsatisfied | Insufficient§4.L(v) | Insufficient§4.L(v) |
| Drift detection with a scheduled model refreshArmilla · MON-04 | Coveredsatisfied | ConditionalMON-04 | ConditionalMON-04 |
| Role of the model in the decision path is disclosed at underwritingArmilla · UW-11 | Coveredsatisfied | ConditionalUW-11 | Coveredsatisfied |
| Human review stands between output and irreversible actionaiSure · SCH-2(b) | Coveredsatisfied | ExcludedSCH-2(b) | ConditionalSCH-2(b) |
Inside a verdict
The clause, in the carrier's own words.
Every non-covered result opens onto the requirement text, the rule that fired, the inputs you attested to, and the cure window the carrier allows. Nothing is paraphrased into vagueness, and nothing is decided by a model.
Verdict detail
rule TES-CP-002“The Applicant must not have altered or removed any of the Generative AI System guardrails provided by the model vendor.”
- Rule fired
- Guardrails modified = true
- Your answer
- Prompt filters relaxed for throughput
- Cure window
- 30 days · attestation
A condition precedent is not a preference. Until the guardrails are restored and attested, this agent sits outside the grant of coverage on Testudo paper — and the file says so in the carrier's own words.
The underwriting packet
Hand your broker something they can submit.
One export, print-ready, laid out like a policy document rather than a dashboard screenshot. It is the difference between a submission that gets worked and a submission that gets questions.
- Cover sheet with the organisation and scan date
- Executive summary of the portfolio position
- Coverage gap map across every agent and requirement
- Agent register with autonomy, audience and data profile
- Findings with clause references and evidence status
- Signed attestation
The cure clock
Every gap gets an owner and a date.
A finding is only useful if someone closes it. Each open gap becomes a cure with the evidence required, the person accountable, and a deadline set against your renewal. Overdue items surface first; items falling due inside thirty days sit right behind them.
Re-run the scan when the evidence exists and the verdict moves on its own. No one marks their own homework — the engine re-evaluates from the stored inputs.
Continuous compliance
Insurability is a moving target. We watch it move.
Continuous compliance monitoring is scheduled re-attestation, the cure clock, the renewal radar, requirement-change alerts, the evidence vault and unlimited underwriting packets. We verify and evidence that your monitoring obligations are being met, in the form an underwriter accepts. We are not an agent observability tool — we connect to the one you already run.
Because requirements are versioned, you can always see what changed, when, and what it did to your position.
How the verdict engine works
Verdicts are computed. They are never generated.
No model decides whether you are insurable. Each requirement is stored with its clause reference, the evidence it expects and a severity, and a deterministic rule evaluates your attested inputs against it. The same inputs always produce the same verdict, and every non-covered result displays the clause that caused it alongside the specific inputs that triggered it.
The insurability index works the same way: a published deduction schedule, applied to the findings, shown as a line-by-line breakdown you can audit. Structural exclusions that apply to every insured regardless of controls are marked informational and never deducted — they are visible, but they are not your failure.
AI does the work around the verdict, never the verdict itself: structuring your plain description of an agent into fields you confirm, summarising computed results for an executive audience, answering questions strictly from the requirement text on screen, and drafting remediation guidance. Every AI-assisted surface is marked in gold so you always know what was computed and what was generated.
Coming soon
On the roadmap, not yet available.
We list these because customers ask where the evidence gets stronger. None of it ships today, and nothing in your current position depends on it.
Agent registration
PlannedAgents register with RiskBorne directly and emit lifecycle events — deployed, model changed, guardrail modified, incident — so the record updates itself between scans.
AMS integrations
PlannedPush client records and packets into the agency management systems brokers already run, instead of re-keying them.
Carrier API
PlannedProgrammatic submission triage and pre-bind checks against a carrier's own requirement corpus.
See where your agents stand.
Run a free scan and get a per-carrier insurability verdict with the exact gaps blocking coverage.