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.
Six questions, and our own answers
§5 answers all six about us, including the five where the answer is “not yet”, and when each changes.
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 can fail closed – refuse the request when the check cannot run – and a vendor who has built it that way will say so immediately, because the answer is a design consequence they have already had to live with; ask whether it does on every path. A vendor whose governance is advisory will reach for the roadmap.
2. Surface and substrate, applied to a vendor
Our diligence method uses a frame 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. By that test our own pilots fall short today: they run on copies of your files, on your own machines, not on the system itself (§5 says where each connector stands).
3. Ask for the confidence flag
Our diligence method gives every finding 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, and when each gap closes. The months are our dated commitments as at 6 November 2026; we update this page when an item ships or a date moves.
When the policy service is unavailable, does a data request fail or proceed?
Not yetNot on every route yet. On the routes Kovac checks, the policy check sits on the route to data rather than beside it. Four of the seven routes to data are not checked yet (the denial answer below names them), so a request on those reaches data without a policy decision. And three failure cases still let a request through when they should stop it: a deploy whose policy call fails, a read of a record whose clearance lookup errors, and a plan that cannot be signed, which runs unsigned rather than halting. The guide's questions 1 and 3 are how to test it.
When: Every route blocks a request when the policy check cannot run, by the end of November 2026.
Which connectors are in production with a paying customer today, and which appear only in the demo?
Not yetNone: Kovac is not yet in production anywhere. What connects today: PostgreSQL and MySQL, for connection tests and schema discovery. SharePoint and OneDrive, with Microsoft Entra ID sign-in, are in alpha testing. Google Drive and shared drives, Gmail, and Docs and Sheets content, with Google sign-in, by November 2026. Kovac cannot yet read straight from your database tables. Microsoft Dynamics and HiBob are in development and are not shipping. Xero and Sage appear in our demo materials and are not shipping yet, and we will not scope work that depends on them until they ship.
When: SharePoint and OneDrive, with Microsoft Entra ID sign-in, are in alpha testing. Google Drive and shared drives, Gmail, and Docs and Sheets content, with Google sign-in, by November 2026. Xero and Sage by November 2026. Reading straight from your database tables, Microsoft Dynamics and HiBob by December 2026.
Show me a denial.
3 of 7 routes to data checkedYes, on the routes Kovac checks. An object, action or deploy request that policy refuses is denied, and the refusal is recorded. File reads, previews, code run directly (/execute) and connection reads are not checked today, so on those paths there is no denial to show. Ask to see the denial on the route you care about.
When: All seven routes to data checked against your policy by the end of November 2026.
Who can read the audit log, and can they alter it?
Not yetThe record is searchable, but any signed-in user can add an entry in anyone's name, and entries are not signed or linked together when written. By question 4's own test – an audit trail that can be quietly edited is a log – ours is a log today.
When: By the end of November 2026, only Kovac itself can write to the record; by then, every entry is signed and linked to the one before it as it is written, permitted requests as well as refusals.
What certifications do you hold today, and which are in progress?
Not yetNone today: Cyber Essentials is due by the end of November 2026, and SOC 2 Type II is not held. If your procurement requires either today, we do not clear that bar yet.
When: Cyber Essentials by the end of November 2026. SOC 2 Type II: not started. We will publish a date when an auditor is engaged.
Where does my data physically sit, and what would have to change for it to sit somewhere else?
Not yetKovac is packaged to run on AWS, Azure or Google Cloud and is not yet running in production. Pilots run locally, on the client's own machines. There is no multi-tenant model. Jurisdiction-specific hosting, and customer-hosted or air-gapped deployment for production, are not shipped. We will tell you which applies to you before scoping rather than during implementation.
When: First pilot deployment, in beta, by the end of November 2026; UK and EU hosting, and customer-hosted and air-gapped options, by December 2026.
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. Ask us again as that changes.
When: When our design partner clears us to name them – their decision, not a build.
Does Kovac make us GDPR-compliant?
NoNo, 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.
When: Not planned, by design.
What a pilot would do for your team: Bids and work-winning, finance, sales and account management, marketing, groups and private equity, risk and audit and IT, security and AI leads.
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 connector ships today; that one 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 governance; not legal compliance advice.
Run these questions on us
Every question above is one we expect to be asked. Bring them to a free Scoping Review and we will answer them in order.