A buyer's guide
Testing a governed-AI claim: a buyer's guide.
Every vendor selling AI over your data says it is governed. The words are free; the controls underneath them are not. This is the test we would apply – including to ourselves.
The claim is not the control
Governance is an architectural property or it is a marketing adjective, and the difference shows in one question: what happens when the policy service is unavailable.
Control on the path
The AI cannot reach data except through a component that evaluates policy first. The system fails closed, because it has no other option.
Control beside the path
The AI reaches data, and a policy layer decides afterwards whether that was allowed. It can report a violation but could not have prevented one.
Ask what the system does when its own guardrail breaks.
Read the full guide →Six questions, and our own answers
Each is answerable in a sentence by a vendor who has built the thing, and produces a paragraph of context from one who has not. None require technical expertise to ask.
A guide like this is worthless if its author is exempt from it, so §5 answers all six about Koralis — including the two where the honest answer is “not yet”.
1. The claim is not the control
“Governed” is an architectural property or it is a marketing adjective, and the two are distinguishable in about ten minutes if you ask the right thing. The distinction that matters is where the control sits. If an AI system reaches your data and a policy layer decides afterwards whether that was allowed, the governance is advisory: it can report a violation but it could not have prevented one. If the AI cannot reach data except through a component that evaluates policy first, the governance is structural — the control is on the path, not beside it.
Both are described with the same vocabulary in a pitch. Only one survives the question “what happens if the policy service is unavailable — does the request fail, or does it proceed unchecked?” A system with the control on the path fails closed, and a vendor who has built it that way will answer immediately, because the answer is a design consequence they have already had to live with. A vendor whose governance is advisory will reach for the roadmap.
2. Surface and substrate, applied to a vendor
We use a frame in technical due diligence that transfers directly to buying decisions. AI-assisted development has made large parts of most software cheap to reproduce, so it is worth separating the part of a product that is now quick to build from the part that is not.
Surface
What a demo shows: the chat interface, the dashboards, the connector logos on a slide, the audit view with three tidy rows in it. A polished demo is now weak evidence of anything except that someone can build a polished demo.
Substrate
The permission model that survives contact with a real directory of five hundred users; connectors that hold up against a production instance rather than a sandbox; the audit record's behaviour when someone asks it a question in an investigation eighteen months later.
The buying implication is narrow and useful: ask to be shown the substrate on your own data, not the surface on theirs. A vendor whose substrate is real will want to do this, because it is where they win. A vendor whose product is mostly surface will steer you back to the demo environment, and the steering itself is the finding.
Be specific about what “your own data” means here. Not a copy of a spreadsheet — a system you already run, with your real permission structure attached, and at least one user who is supposed to be denied something.
3. Ask for the confidence flag
In our diligence work every finding carries one of three flags, and the flag is the finding rather than a hedge appended to it. You can apply the same three words to a vendor's answers, and you should, because a sales conversation runs all three together in a single confident register.
“We support that” can mean a customer runs it in production today, we built it and nobody has used it in anger, or it is in the next release. Those are three different purchases and only one of them is the one being described.
The mechanism is simple. When a vendor says a capability exists, ask: is that shipped and in production with a customer today, built but not yet deployed, or on the roadmap? Then ask what would let you verify the answer. A vendor comfortable with the distinction will make it themselves, unprompted, and will tell you which of their own features are demo-grade. Reluctance to separate the three is itself information — and it is the single most reliable signal in the whole process.
How the flags are defined →4. Six questions that separate shipped from roadmap
Each of these is answerable in a sentence by a vendor who has built the thing, and produces a paragraph of context from one who has not.
1. When the policy service is unavailable, does a data request fail or proceed?
Fail-closed is a design decision with operational costs; a vendor who made it will say so plainly.
2. Which connectors are in production with a paying customer today, and which appear only in the demo?
Every vendor has both. Only some will tell you which is which.
3. Show me a denial.
Not an approval – a user who is refused, and the record it leaves. The denial path is where governance is actually implemented or actually missing.
4. Who can read the audit log, and can they alter it?
An audit trail an administrator can quietly edit is a log, not an audit trail.
5. What certifications do you hold today, and which are in progress?
“In progress” is a legitimate answer. “ISO-aligned” or “SOC 2 ready” is a way of not answering, and both should be read as no.
6. Where does my data physically sit, and what would have to change for it to sit somewhere else?
Vendors frequently describe hosting options that exist as a roadmap item. Ask which are running today.
None of these require technical expertise to ask, and all of them are hard to answer smoothly without the underlying thing being real.
5. Now run it on us
A guide like this is worthless if its author is exempt from it, so here are our own answers. Where the honest answer is “not yet”, it says so.
When the policy service is unavailable, does a data request fail or proceed?
Not yetToday it depends on the path, which is a worse answer than the one we gave here until 19 September 2026. The architecture is right: policy evaluation sits on the path to data rather than beside it, so AI and users do not reach data directly. Three paths still proceed when they should stop — a deploy whose policy call fails, an object read whose clearance lookup errors, and a plan that cannot be signed, which degrades to unsigned rather than halting. This is the claim of ours most worth testing, and questions 1 and 3 above are how to test it. Test it now and you will find this.
Tracked as: Roadmap T8-04 — fail closed, everywhere (koralis-roadmap/05 §3, Phase 0)
Which connectors are in production with a paying customer today, and which appear only in the demo?
PartlySQL, and less than that word implies: Postgres and MySQL, for connection tests and schema discovery. Database tables cannot yet be pipeline inputs. OAuth, Microsoft Dynamics and HiBob are on the roadmap and are not shipping. Xero and Sage appear in our demo materials and are not shipping — we will not scope work that depends on them until that changes. If you saw any of these in a demonstration, that is what you saw.
Tracked as: Roadmap T8-06a (tables as pipeline inputs), T8-06b (Dynamics), T8-06c (HiBob); Xero/Sage gated on T6-03
Show me a denial.
PartlyYes, on the paths that are gated. An object or action request that policy refuses is denied and the refusal is recorded, and that is the demonstration §4 is asking for. Be aware of what it does not cover: file reads, preview, /execute and connection reads are not gated today, so on those paths there is nothing to deny and no denial to show you. Ask to see the denial on the path you actually care about.
Tracked as: Roadmap T8-03 — close ungated reads (koralis-roadmap/05 §3, Phase 0)
Who can read the audit log, and can they alter it?
Not yetWorse than it should be, and this is the question on the list we would least like to be asked. The trail is queryable, but any authenticated user can write a trace for any principal, so it is both readable and writable by anyone with an account. It is not signed or hash-chained at write. Our own §4 says an audit trail an administrator can quietly edit is a log, not an audit trail, and by that test ours is a log today. T8-07 signs the trail and records allows as well as denials; T8-02 authorises the administrative mutations that should never have been open.
Tracked as: Roadmap T8-07 — signed, complete decision trail; T8-02 — authorise administrative mutations
What certifications do you hold today, and which are in progress?
PartlyCyber Essentials, held. SOC 2 Type II: not held. It is on our roadmap and it is a long calendar item, not a near-term one. If your procurement requires SOC 2 today, we do not currently clear that bar, and you should weigh that before spending time with us.
Tracked as: Roadmap T5-06 — SOC 2 Type II, Next horizon
Where does my data physically sit, and what would have to change for it to sit somewhere else?
PartlyContainerised, on AWS, Azure or GCP. Tenancy isolation is built and is not yet running in production – we described it as available today until 19 September 2026, and it was not. Jurisdiction-specific hosting profiles and air-gapped deployment are roadmap items and are not shipped. We will tell you which applies to you before scoping rather than during implementation.
Tracked as: Roadmap T8-08 tenancy in production; D7; T6-07 hosting profiles (Next), T6-08 BYOC/VPC (Later)
Can you give me a reference customer?
Not yetNot a named one. We work with a design partner whose name we have not been cleared to use, and we would rather say that than imply a reference list we do not have. Ask us again as that changes.
Tracked as: Tracker D7 — proof-point naming clearance; pipeline BD3
Is this GDPR compliance?
Not yetNo, and it will not become so. We build with GDPR-aware handling in mind; that is a design discipline, not a claim of legal compliance. Any vendor telling you their product makes you compliant is describing something a product cannot do on its own.
Tracked as: Not a roadmap item by design — see the guide's §6 red flags
6. What a good answer looks like
Across every question above, the pattern that distinguishes a trustworthy answer is the same: it is specific, it is dated, and it volunteers its own limits. “That ships today for SQL and Dynamics; for Xero it is demo-only and I would not scope against it” is a good answer from any vendor, including one telling you something you did not want to hear.
The unprompted superlative
“Fully compliant”, “completely secure”, “governed by design” with nothing after the phrase. The mechanism should follow the claim; if it does not, the claim is decorative.
The roadmap answered in the present tense
Watch for a tense shift between the capability and the evidence: “we support air-gapped deployment” followed by “we can talk about timelines” is a roadmap item wearing a shipped item’s grammar.
Reluctance to show a denial
Any vendor can show you the system working. A vendor who cannot readily show you the system refusing has usually not finished building the part you are paying for.
A supplier who overstates a control during a sale will overstate an incident after one. Testing that early costs an afternoon, and it is the cheapest diligence available to you.
This guide describes a buying method and is deliberately vendor-neutral. Statements about Koralis's own capability are accurate as at publication and will date; ask us to confirm current status rather than relying on this page. GDPR-aware handling is a buying discipline, not legal compliance advice.
Run these questions on us
Every question above is one we expect to be asked. Bring them to a walkthrough and we will answer them in order.