Don’t trust us. Check.Try to break a sealed record
Coriqo
Case studies · illustrative scenarios · fintech, AI vendors, banking, clinical AI and privacy

Twenty-one places a governance gap became a finding on the record instead of a fine, a lost deal or a headline.

Illustrative composites, labelled as such, with no real customer named. Each one starts with the person who had to answer for the AI (a fintech's head of risk, a CRO, a vendor's clinical lead, a privacy officer), then what was flagged and when, then what the examiner, committee or auditor was handed.

These are illustrative sample scenarios composited from the problems Coriqo is built to solve, consistent with the illustrative sample data used in our demo. The organization profiles and figures below are examples for explanation, not claims about named customers or guaranteed results. Coriqo has no named healthcare or privacy customer yet. The healthcare and privacy scenarios describe workflows the shipped rulepacks support, and the fintech and AI-vendor scenarios describe workflows the product runs today. None of them are deals that happened. The regulatory dates cited in the privacy scenarios come from the deadline ladder published on our campaign pages (verified 11 September 2026; re-verify with your counsel).

Fintech 01 · Sponsor bank review

The sponsor bank asked what the payouts agent was allowed to do, and who said so

Payments fintech · bank-sponsored card and payouts program · AI agent clearing held payouts · Accountable: head of risk and compliance

The challenge

The sponsor bank's third-party risk team opened its annual review of the program. Its examiner had asked the bank about AI at partners, so the questions were specific: what the agent clearing held payouts was allowed to do, who approved that, and what happened the last time it went outside those limits.

The answers sat in a slide deck, a Jira epic and the engineering team's memory. The bank's reviewer said plainly that a description written by the fintech was not evidence.

How Coriqo is used

The agent's mandate (what it may do and which tools it may call) became a versioned record that the head of risk approved by name. The agent's runs reach Coriqo as OpenTelemetry traces, and each one is checked against the mandate version in force at the time.

One run called a refund tool the mandate did not cover. A finding opened at that moment with an owner and a due date, and the alert paged the on-call risk analyst. The tool was taken out of reach, the test was run again and passed, and the owner closed the finding with a written reason.

The bank's reviewer got read-only access that expired at the end of the review, plus a proof bundle they ran on their own machine with no Coriqo account.

Illustrative outcomes

Named approver
every mandate version carries the person who approved it and the date
Breach to retest
the one crossing is on the record from the moment it happened to the passing retest that closed it
Checked by the bank
the reviewer verified the record offline instead of reading the fintech's summary
Fintech 02 · Release check and diligence

An engineer widened an agent's permissions in a pull request, and the build failed

Consumer lending fintech · underwriting assistant agent · enterprise partnership in diligence · Accountable: CTO

The challenge

The lender was in diligence for a partnership with a large bank. The bank's security team asked two things: how the company knew that the agent in production was the one its risk team had approved, and whether its SOC 2 controls had run throughout the year or only in the weeks before the audit.

The honest answer to the first was that anyone with merge rights could change the agent's mandate file and ship it the same afternoon.

How Coriqo is used

The release pipeline gained one job ahead of deploy: coriqo-agents mandate check, from the ready-made GitHub Actions job. When an engineer added a new tool to the mandate file in a pull request, the file no longer matched the approved version Coriqo held. The check exited 1, the CI job failed the build, and the change went through approval before it shipped.

The company's SOC 2 controls live in Coriqo with owners and a schedule. Each control is re-checked on that schedule, and evidence past its date is flagged to its owner. The bank's reviewer saw when each control last ran, not a policy saying it would.

Illustrative outcomes

Build failed
the changed mandate file did not match the approved one, so the pipeline stopped the release
Approved first
the wider permissions shipped only after a named person approved the new mandate version
Dated evidence
each control shows when it was last checked, through the whole period
AI vendor 01 · Customer security review

Every bank prospect asked the same questions about what the agents can do

AI agent platform · selling to banks and credit unions · several vendor reviews open at once · Accountable: head of trust

The challenge

Each bank's vendor-risk team asked the same three questions in a different spreadsheet: what can your agents do, who approved it, and what happens when one oversteps. The head of trust answered each by hand from internal docs, and the answers drifted from one bank to the next.

Two reviewers asked a harder question: whether the agents had been tested against prompt injection, and whether the results could be shown rather than described.

How Coriqo is used

Each agent's mandate is a versioned record approved by a named person on the vendor's side. The agents are tested against prompt injection, and each run and its result is recorded on the same record as the mandate.

Each bank's reviewer gets their own expiring, read-only access and a proof bundle to check offline. The vendor answers from one record instead of rewriting the answer for every questionnaire.

Illustrative outcomes

One record
the same mandates, tests and findings answer every bank's questionnaire
Access per bank
each reviewer's access is read-only and expires on its own date
Tests on the record
each bank's reviewer opens the prompt-injection runs and their results
Banking 01 · Inventory consolidation

Four inventories that disagreed, and the ~15% of models none of them governed

$40B regional bank · 120+ models across 6 business lines · Accountable: head of model risk

The challenge

Model risk lived in at least four spreadsheets that disagreed with each other, which an OCC examiner would have written up as a finding. Credit, treasury, BSA/AML, and finance each kept their own list, and no single record could answer "how many models do we run, who owns each, and what state is validation in." With an OCC exam scheduled, leadership could not confidently produce a complete inventory, and that is the first document every exam request list asks for.

How Coriqo is used

By the time the exam request arrived, the inventory answered it as a query. Getting there meant importing each business line's spreadsheet into Coriqo, previewing it first and having a second person approve it. Duplicates and orphaned models were reconciled into one authoritative record. Every model was given a risk tier and a named owner, and mapped to the models that depend on it, so the impact of any one model could be traced downstream.

Vendor and end-user-computing models that had never been formally tracked were pulled into scope as full inventory records.

Illustrative outcomes

~15%
of vendor and EUC models were ungoverned. The bank found them before the examiner did
4 → 1
disagreeing spreadsheets replaced by a single authoritative inventory
1 export
the exam's inventory request answered with one query
Banking 02 · Effective challenge

The same analyst built the model and signed off on it. Examiners look for that independence gap first

Mid-size lender · $9B in assets · 30+ credit and pricing models · Accountable: head of model validation

The challenge

Examiners had already raised the question out loud: reviews did not look genuinely independent, since the same analysts who built models also appeared to sign them off. The record showed only conclusions, without the substance of the challenge SR 26-2 expects, and the reasoning behind each approval lived in email threads that were hard to reconstruct.

How Coriqo is used

Coriqo enforces segregation of duties by role: a model's owner can never be recorded as its independent approver, and self-approval is blocked outright. Each validation captures what was challenged, the limitations identified, the conditions attached to approval, and the named, independent person who signed off.

The full challenge history is saved to a record that can only be added to, so the reasoning behind every approval is evidence rather than recollection.

Illustrative outcomes

0
models approvable by their own owner, because the role rules block self-approval
Every model
carries a dated, attributable record of what was actually challenged
Days → minutes
to evidence independent challenge on a sampled model during review
Banking 03 · Small team, full record

Examiner expectations sized for a validation department, met by two people wearing other jobs

Credit union · $3B in assets · 2-person risk function · Accountable: both of them

The challenge

The credit union's entire model risk function was two people holding the title alongside their day jobs. Examiners write their expectations for a full department, whatever the headcount. Those expectations hadn't gone away: an inventory, a validation cadence proportional to risk, documented approvals, ongoing monitoring. But hiring a validation department was never on the table.

How Coriqo is used

What a reviewer sees is a model whose recorded state matches reality, and a validation cadence applied by rule rather than by whoever had time. Underneath, Coriqo gives the two-person team one lifecycle (draft → submitted → validated → approved → production → retired). Each model's risk tier sets how often it is validated, automatically, so low-risk calculators don't get the same depth as material models.

For the highest-risk models where internal independence is hard, the workflow supports engaging an external validator and recording that review in the same trail.

Illustrative outcomes

Audit-ready
from day one, with each finding raised as the work happens
2 people
running a program with the structural discipline of a far larger team
Proportional
validation cadence keyed to model tier, applied consistently by rule
Banking 04 · Governed communications

"Ship it," typed into a Teams thread, was a decision the examiner could not find anywhere on paper

$22B commercial bank · Microsoft 365 · Teams-first culture · Accountable: model owner

The challenge

When an examiner asked who decided a model was acceptable despite back-testing drift, and on what basis, there was no evidence behind the answer. The decisions that mattered, such as "the recalibration looks fine, ship it," happened in Teams channels and email threads, then vanished from the evidence record, which kept only the conclusion.

How Coriqo is used

Coriqo captures Microsoft Teams communications as evidence that a person has to approve. A named person reviews a thread, approves it into the record and attaches it to the relevant model or governance event. It then goes into the same examiner package as everything else, where any later change would show.

Capture never decides anything on its own. The record credits the person who approves, never the chat message or an AI summary. The conversation becomes visible evidence behind a human sign-off.

Illustrative outcomes

In place
the sign-off that mattered, made in a Teams thread, recovered as a finding instead of left to vanish
Same seal
Teams threads land in the same checkable package as governance events
No runtime dependency
works over the Teams and email workflows the bank already runs
Banking 05 · Verifiable audit trail

The examiner found nothing to trust, because nothing needed to be trusted

$15B regional bank · preparing for a supervisory model risk review · Accountable: CRO

The challenge

Every claim in the bank's records rested on "trust our database," and that would turn into a supervisory finding the moment an examiner asked to check one. An examiner had no way to confirm a validation record hadn't been edited after the fact, or that an approval was as old as it appeared, and the team knew the first hard question would be whether the record could be taken on faith.

How Coriqo is used

Every governance event (approvals, validations, monitoring breaches, findings) is added to a chain in which each record carries the SHA-256 fingerprint of the one before it. The chain is grouped into Merkle checkpoints and signed with Ed25519. The examiner downloads a small proof, then verifies a single event offline with the public key alone. No Coriqo server is involved.

A one-button examiner package assembles the dated, self-contained, independently checkable record for the full review.

Illustrative outcomes

Tamper-evident
any later alteration breaks the chain, so a doctored finding shows up as soon as anyone checks
Offline
verification: the examiner checks the record with a public key, on their own machine
One button
to produce the sealed, dated examiner package for the review
Banking 06 · Agent mandate breach

An agent acted outside its mandate, and the record showed it before anyone asked

Regional bank · payments operations · vendor copilot with a standing release mandate · Accountable: second-line risk officer

The challenge

A payments-operations team had given a vendor copilot standing permission to release held transactions under a set of conditions. The mandate was approved once, in a meeting, and then relied on for months while the agent worked through the queue.

When second line asked whether the agent had ever acted outside those conditions, the material available was the vendor's console and the team's recollection. Neither is evidence.

How Coriqo is used

A read-only discovery scan surfaced the copilot as an agent acting on live systems, alongside others nobody had put on an inventory. The permission the bank had given (the mandate) became a governed, versioned record, with its conditions, its approver and its date. Every release the agent performed was recorded as a decision trace tied to the mandate version it ran under.

One batch ran against a condition the mandate did not cover. Because each trace carries the mandate version it was checked against, the crossing was recorded at the moment it happened and opened a tracked finding with a named owner and a due date. The bank set the boundary. Coriqo recorded the crossing and routed it to an owner; it did not rule on whether the crossing mattered.

The fix and the closure were added to the same record. Second line pulled that one trace and verified it offline against the public key, rather than accepting a summary from the vendor or from Coriqo.

Illustrative outcomes

Out of mandate
one batch crossed it, and the finding was on the record the moment it happened
Owner and due date
a crossing opens a tracked finding. The bank sets the line and Coriqo routes the crossing to an owner
Verified offline
the reviewer checks the individual trace against a public key, with no Coriqo server in the path
Healthcare 01 · Committee review

Nine stalled health-system deals, waiting on the same evidence assembled nine different ways

Clinical AI vendor · one deployed model, deals pending at 9 health systems · Accountable: vendor's clinical lead

The challenge

Nine deals stalled in committee for reasons that had nothing to do with model accuracy. Every health system's AI-governance committee asked for a different slice of the same evidence. One wanted the bias-management approach, the next demographic representativeness of the training data, a third the retirement and change-management policy. Each request was answered by hand from slides and a shared drive, and the answers drifted between deals.

The harder question came from counsel: the vendor's own deck reported a clinician override rate, and nobody could say who computed it or whether it could have been edited since.

How Coriqo is used

The vendor runs Coriqo's healthcare checks, built from the Joint Commission's RUAIH certification domains, cross-referenced to the ONC HTI-1 predictive DSI source attributes. Each requirement is answered from records already in the chain rather than a document reassembled for every deal, so a committee asking about bias management and one asking about lifecycle policy are answered from the same sealed record.

Human review of the model's recommendations is recorded as it happens: time on each decision, agreement with the model, volume, and reviewer. The vendor's medical director sets the threshold at which that pattern opens a tracked finding. Coriqo reports the number and never judges a named clinician.

Each committee gets time-boxed, read-only access to the record and verifies the chain against a public key instead of accepting the vendor's summary.

Illustrative outcomes

A set threshold
a concordance pattern crossing the medical director's line opens a tracked finding automatically
1 record
answers all five RUAIH domains instead of a pack rebuilt per health system
Public key
the committee verifies the evidence itself rather than trusting the vendor's summary
Healthcare 02 · Payer utilization management

Evidencing that a licensed human, not the model, made the denial

Regional health plan · utilization management · 2026 state AI statutes in scope · Accountable: plan's medical director

The challenge

Every 2026 state statute on AI in utilization management says the same thing: a licensed clinician, not an algorithm, has to make an adverse determination. The plan could not rule out that it was in violation. The plan believed it complied. It could not show it.

The figure that defined this whole problem publicly, roughly a second per claim, came from journalism and discovery. No plan could have produced it from its own systems on request. When the state regulator asked how long the plan's own reviewers spent, the honest answer was that nobody was measuring.

How Coriqo is used

Each determination records who reviewed it, how long they spent, and whether they departed from the model's recommendation, sealed into the same append-only chain as everything else. The plan cannot revise the figure after the fact, which is the property that makes it worth producing.

The medical director sets the thresholds. When dwell time or concordance crosses one on a class of determinations, Coriqo opens a tracked finding with an owner and a due date. A person gets the fact to act on, and Coriqo never passes a verdict on a named reviewer.

External review organizations and state regulators get time-boxed, read-only access and verify the record against a public key.

Illustrative outcomes

Plan-set threshold
the plan sets the line; Coriqo reports the crossing and names an owner
Per determination
reviewer, dwell time, and concordance recorded as it happens
Regulator-checkable
the regulator verifies the record against a public key
Healthcare 03 · Retraining and change control

Nine customers running approved documentation for a model version that no longer existed

Clinical AI vendor · quarterly retraining cadence · 9 deployed customers · Accountable: vendor's regulatory lead

The challenge

Each quarterly retrain invalidated part of the documentation every customer held, and each customer's AI committee had approved a specific version under specific claims about its data and performance. RUAIH asks about exactly this lifecycle-policy gap.

Nobody could answer, per customer, which version they were running, which validation evidence applied to it, or whether they had been told about the last change. RUAIH wants lifecycle policy to cover change management and retirement as well as the initial validation, and this was where the vendor fell short.

How Coriqo is used

Every retrain is recorded as a new version with its own lineage: the training data description, the demographic representativeness, the external validation, and the bias-management approach that belong to that specific version.

Because the requirement checks resolve to records rather than documents, each customer's package regenerates against the version that customer actually runs. A committee reviewing v4 sees v4's evidence, and the fact that v3 was superseded on a dated, sealed event.

Retirement of an old version is a recorded governance event rather than an email nobody kept.

Illustrative outcomes

Dated supersession
the v3-to-v4 changeover that used to slip past a committee unannounced is a finding on the chain the day it happens
Per version
evidence bound to the exact version it describes
9 packages
regenerated from one record instead of nine documents maintained by hand
Healthcare 04 · Agentic clinical workflow

One signature that covered 4,000 actions, and no way to say what it actually authorized

Clinical AI vendor · agentic prior-authorization workflow · mandate-scoped agent · Accountable: clinician who approved the mandate

The challenge

The product stopped scoring and started acting, so one clinician's approval of a mandate now authorized thousands of downstream actions, and nobody could say what that signature actually covered.

Override rate stops being a meaningful number when almost nothing reaches a human individually. The committee's question became sharper and harder: how much action did one signature cover, and did the person signing see anything representative of what they were authorizing?

How Coriqo is used

The mandate is a governed, versioned record, and a material change to it is a new version requiring fresh approval rather than an edit. Every action the agent takes is sealed as a decision trace anchored to the mandate version it ran under.

That makes the ratio answerable from the record instead of estimated: this approval, this mandate version, this many sealed actions, over this window, with these escalations back to a human. A committee can sample the traces rather than accept a summary.

Actions falling outside the mandate's scope are recorded as such, so the boundary is evidenced rather than asserted.

Illustrative outcomes

Out of scope, on the record
any action outside the mandate is flagged the moment it runs
1 mandate → 4,000 actions
the ratio comes straight off the record
Samplable
the committee inspects sealed traces instead of trusting a rollup
Privacy 01 · ADMT risk assessment · employment

The assessment promised human review; the auditor asked who measured it

HR-tech vendor · AI résumé screening · enterprise customers in regulated states · Accountable: vendor's privacy officer

The challenge

The vendor's ADMT risk assessment said a human reviews every adverse screening outcome before it counts. Under the CCPA regulations in force since 2026-01-01 (risk assessments now, the ADMT rules from 2027-01-01), that claim has to hold up when the regulator or a trial counsel asks how it was measured. They will want to know over how many decisions, by whom, and whether the record could have been edited afterward.

Nobody could answer per decision who reviewed, or how long the "review" took. Sampling real cases for the audit would have meant pulling candidate records into a new audit file, an exposure the privacy team did not want to create.

How Coriqo is used

Each review records who took it, how long they spent, and whether they departed from the model, sealed into the append-only chain at the moment it happens. Coriqo holds only reviewer facts. The résumés and candidate data stay where they are, so evidencing review creates no new personal-data exposure.

The privacy office sets the threshold above which a pattern, such as a 100% concordance streak, opens a tracked finding with an owner and due date. Coriqo reports the number and never judges whether a given review was meaningful.

The auditor gets time-boxed, read-only access and verifies the chain against a public key instead of accepting the vendor's summary.

Illustrative outcomes

Measured
median time-on-decision and reviewer counts come off the sealed record
No new exposure
the record holds review facts without payloads, so the audit never touches candidates' data
Vendor-set threshold
the vendor sets the line; a crossing opens a finding, and the judgment stays with the privacy office
Privacy 02 · Material change · consumer deployment

A retrained model, a stale pre-use notice, and six months of no record between them

Consumer fintech · credit-path AI · monthly retraining cadence · Accountable: compliance lead

The challenge

The product's pre-use notice described v12 of the decision model, which was narrowly scoped and low-impact, with an opt-out routed to a human. Then the monthly retrain changed the feature set, and the notice nobody re-read stopped describing the system that ran it. If an auditor or a regulator asked when material change happened, the honest answer was that the process existed on paper but nowhere on the record.

The same gap applied to the opt-out: some consumers had declined, and nobody could evidence the effective date or what changed about their path.

How Coriqo is used

Every retrain is recorded as a new version with its own lineage, so the notice is filed against the version it describes and a material change re-opens materiality as a dated governance event. The change-management articles of the EU AI Act rulepack check for that mechanism.

Opt-out decisions are recorded against the consumer request that produced them: the effective date and the path change, sealed as events rather than kept as a ticket. The controller's notice and the processing stop being separate stories.

An auditor samples the sealed events instead of trusting an attestation, and verifies each one with the public key.

Illustrative outcomes

Dated divergence
the day the system and its notice disagree is recorded as a governance event
Per version
notice and evidence bound to the model version they describe
Opt-out on the chain
who declined and what changed is a sealed event checkable by anyone they show it to
Privacy 03 · Housing screening · TRAIGA

The AG's 60-day cure letter, and no way to show the screening decisions it names

Rental screening vendor · tenant-risk scoring · Texas TRAIGA in force 2026-01-01 · Accountable: vendor's general counsel

The challenge

An inquiry letter arrived about the vendor's applicant-scoring system. The Texas Attorney General enforces TRAIGA's intent-based prohibitions with a 60-day cure period, so the state's clock was the one that mattered. The inquiry named adverse outcomes but not dates or decisions, and the vendor kept its screening records in a tool where an approver can edit a note after the fact.

The honest problem: the vendor could not produce per-decision review evidence that nobody had touched, and a 60-day cure window is not long enough to rebuild it.

How Coriqo is used

Each applicant-screening decision class runs as its own track, and the review evidence (reviewer, time on decision, override or concurrence) is sealed at the moment it happens rather than compiled later. When the AG's office asks about the named decisions, the answer is a sealed trace for each one.

The vendor exports the range that covers the inquiry period and verifies it offline before sending anything. Separation of duties stays intact: the operator who runs the platform cannot fulfill the evidence request for it.

Illustrative outcomes

Trace per decision
the inquiry's named decisions each resolve to a sealed review record
Nothing retroactive
review facts captured at review time survive the inquiry without a rebuild
Offline verified
the vendor checks its own export against the public key before relying on it
Privacy 04 · Education AI · EU AI Act Annex III

Obligations land 2 December 2027. The admissions tool's evidence was already fit for a different registry.

EdTech vendor · admissions-rank recommender · EU school customers · Accountable: vendor's data protection officer

The challenge

Education belongs in the EU AI Act's Annex III high-risk list, and the 2027-12-02 general date for those obligations, which the Digital Omnibus moved there, is when risk management, data governance, logging, human oversight and post-market monitoring clauses start to bind. The vendor had a model card and a DPIA skeleton. Neither was the thing educators would need per deployment: the oversight measures that applied to the version the school actually ran.

Each of 14 school districts ran a different version, and the compliance files described the product, not the deployments.

How Coriqo is used

Every district's deployed version is a governed record with its own lineage from one shared tool: the training-data description, accuracy metrics, oversight measures, and the review trail belong to that version in that deployment. The Annex III clause list lives in the rulepack, and each clause resolves to the records for the version the auditor asks about.

School administrators get time-boxed read-only access and verify the chain themselves, which turned one compliance narrative into one record with fourteen audience views.

Illustrative outcomes

Per deployment
14 districts, one record, and no version asking to be described as another
Deadline-anchored
the 2027-12-02 clause list mapped to shipped checks before the date arrived
14 portals
each administrator checks for themselves what their own school runs
Privacy 05 · Consequential decision classes · Colorado

Four consequential decisions, one launch, and the Colorado line approached

Regional lender · loan pathing agent · Colorado SB 26-189 lands 2027-01-01 · Accountable: chief compliance officer

The challenge

The lender's agent writes loan-closure offers and paths borderline files. Colorado's replacement AI law reaches automated decision making that materially influences a consequential decision from 2027-01-01, with the same general problem every state law shares: the statute governs the decision, and the decision's paper trail lives in systems nobody equates with compliance.

Pathing agent activity lived in tool logs. Review happened in Slack threads. Neither one could evidence the human's involvement in a way a state auditor could rely on, and reframed-scope questions do not answer themselves.

How Coriqo is used

Loan pathing is recorded at the agent level: every path chosen, which mandate version it ran under, whether a person reviewed it, and what the agent offered. That gives the consequential-decision class its own evidence layer from day one, rather than a retrofit onto an audit in 2027.

Material changes to the mandate, such as a new fee path or a new eligibility cut, land as sealed governance events with fresh approvals, so when the compliance officer is asked about the new scope, the record has the answer before anyone has to reconstruct it.

Illustrative outcomes

Class-scoped
the loan pathing track holds evidence about one decision class
Human involvement, recorded
approvals live in the chain, where they can be queried later
2027-ready
Colorado scope arrived on the record 12 months before the deadline did
Privacy 06 · Profiling boundary · behavioral targeting

"It's just personalization." Three thousand decisions said otherwise.

Retail media platform · personalized pricing path · 2027 CCPA duties approaching · Accountable: privacy lead

The challenge

The product team described the behavioral model as profiling without significant consequences. The assessment leaned on that claim to keep the system out of the significant-decision scope. Price variant assignments existed deep in a feature store with no human touch at all. When the compliance team asked the questions an auditor would (is the effect material, and how often did the boundary get crossed?), the source was the model's own logs, dimly maintained.

What was missing was the ability to show a boundary recorded by anyone other than the team running the boundary.

How Coriqo is used

The profiling model sits under its own decision class with the risk-tiering banners the platform already uses for other customers. Price proposals inside the "significant" band are recorded, sealed, and counted; those crossing the line open a finding against it, with an owner inside the privacy office and a due date.

The number the team presents in its next risk assessment refresh is "we set a boundary, tracked every decision against it, and here is the crossing rate." Every part of that sentence comes from the record.

Illustrative outcomes

Own the boundary
the platform proves what the pricing model does not know: where the significant-decision line sits, and what crossed it
An owned finding
a boundary crossing creates a finding the product team owns and can act on
Crossing rate
0.41% of decisions, recorded and sealed, ready to show when the 2027 duty lands
Privacy 07 · Access requests · data-subject rights

Three hundred access requests, each asking which AI touched the file, and no way to answer one

Regional insurer · claims support AI · first consumer-request audit cycle · Accountable: insurer's privacy office

The challenge

The insurer's claims AI ranked documents, suggested amounts, and drafted letters. Under CCPA access duties every consumer can ask what the automated decision was, and the insurer could not reconstruct per request which model version produced the suggestion, or who reviewed it. Three hundred outstanding requests on the books, each one needing an answer the current tooling could not produce from its stores.

How Coriqo is used

Each AI-assisted claim output is a sealed event that records the version, suggestion, reviewer and timestamps, but not the claim file's contents. When an access request names a decision, the workspace returns the trace for that decision only, time-boxed and read-only.

The evidence-request turnaround is measured automatically from request to package, so the 2027 deadline becomes a queue the office actually owns rather than a prior-year backlog.

Illustrative outcomes

Request-shaped
one request resolves to exactly the traces behind it and nothing more
Turnaround recorded
every evidence request measures itself from date received to package sent
Backlog zeroed
from reconstructed narratives to 300 sealed traces queryable individually
Privacy 08 · Prohibited practice · Art. 5 retirement

An emotion-inference feature had been live since before its own prohibition date

EU HR-tech vendor · emotion-inference pilot · EU AI Act Art. 5 prohibitions since 2025-02-02 · Accountable: vendor's data protection officer

The challenge

A pilot module inferred candidates' emotional states during ranked interviews. The prohibition on emotion-recognition use in workplace settings has been live since 2 February 2025, and the pilot had run on since then, kept alive by a manager who did not think of it as "a system."

Retiring it was the easy half. What counsel wanted evidence for was when the module had been used, and what its output had influenced in the meantime.

How Coriqo is used

Every interview scored by that module carried a comment route and owner. Retirement is recorded as a governance event. The module is flagged down in the chain, the last governed use is dated, and the decision to end it has an owner and an approver.

Every recorded use since 2 February 2025 is queryable by version and window, so counsel answers the retroactivity question from the chain instead of estimating what "probably" ran.

Illustrative outcomes

Retired on the record
the module was retired in a dated governance event with a named owner
Whole window
every use since the prohibition date can be queried by version and time window
Owner and approver
the retirement decision has a named owner and approver in the chain, uneditable after the fact

Want to walk through a scenario like yours?

Tell us what your models and agents already decide, and where you'd struggle to prove it. We'll work through the record against your own situation.