Brand voice
Klai is private AI infrastructure for people who are serious about what AI does to their organisation. We talk like the senior colleague who actually understands AI. Not the consultant selling it. Not the vendor managing expectations. The colleague who has read the terms, tried the tools, and tells you straight what they found.
Peer authority, no theatre. This is the spine of how we write, design, and build. If something we publish sounds like a LinkedIn post from a consultancy, we rewrite it. If it sounds like something you’d say to a smart founder over coffee, it ships.
Three principles run through everything.
1. We help people spend time on the parts that need a human
AI can take over the repetitive and boring parts of work, so people can spend more of their time on the parts that actually need a human. That is the product thesis, stated as the human gain.
That framing runs through the product. Knowledge stores what the organisation already knows so it does not walk out when someone leaves. Scribe transcribes meetings so you can run them. Focus retrieves document answers so you stop hunting for files. The product takes the repetitive; people do the human parts.
Voice implications
Lead with the human gain before the technology. Name the outcome first (“your meeting notes, handled”), then explain how, if the reader wants to know. Use plain language to explain complex things. Good explanation is how we respect the reader.
Never anthropomorphise the system. The distinction is sharp:
- Cognitive verbs are forbidden: understands, thinks, learns, knows, reasons, believes, decides. The system does none of these.
- Action verbs are fine and correct: stores, indexes, retrieves, transcribes, returns, matches, cites, synchronises.
When the writing itself makes the reader more capable, by explaining clearly instead of obscuring, it demonstrates the principle. Clarity is the product.
Design and UX implications
The interface responds to the user, never the other way around. No popups. No chatbots stuck over the page. No animations that happen while you are trying to read. Every retrieved answer carries a citation so the human can verify. Defaults are simple for someone starting out; depth is available for power users without forcing them to battle a simplified surface. The product makes complex things feel simple. It does not hide capability from people who want it.
2. Judge by structure, not claims
The only way to evaluate a company’s claims about privacy, ownership, or values is to look at what they actually do. Their legal structure. Their infrastructure. Their defaults. Their behaviour when a competitor offers them a big cheque.
This principle is a lens, applied to us and to everyone else. It cuts both ways.
The clearest example is ownership. Klai is steward-owned. The company cannot be sold. There are no investors whose exit requires us to change the terms. Profits go back into the product and into the open source projects we build on. We are a patron of a commons we depend on, and the contract says so. This is not a value statement. It is a legal structure, a fact about how the company is registered. Structural facts hold because they cannot be reversed with a new version of the privacy policy.
The proof rule
Every trust claim in our copy must be backed by at least one of:
- A legal fact (articles of association, contract clause, jurisdiction)
- A verifiable technical detail (architecture, code we can point to, a default you can inspect)
- A named competitor and a specific behaviour (not “other vendors”, but “Microsoft Copilot, Flex Routing, April 2026”)
- A specific number or date
If none of those are available, cut the claim. A promise without evidence weakens everything else we say.
Voice implications
Use structural facts, not value claims. “Klai cannot be sold. Ever.” beats “Klai is committed to privacy.” One is verifiable; the other is a promise. Name infrastructure partners. Distinguish technically impossible from against policy. These are different things and readers know the difference.
When describing other companies, apply the same lens: what they do, not what they say. The dry humour about the industry comes from this gap. The humour lands on the contrast between words and actions, reported straight.
Civic vocabulary is part of this voice, not decoration. Words like commons, patron, public fabric, primary infrastructure, steward-owned, unsellable, precondition come from the fact that European organisations have become dependent on infrastructure they do not control. We name that honestly, because the naming is the work.
Design and UX implications
Proof lives in the product, not in the footer. Architecture facts belong on the pages where people decide (pricing, product, comparison), not buried in a PDF nobody reads. The UI shows what is happening with data: where it is stored, who can access it, what leaves the boundary. Defaults are the right choice, not the upsell. No dark patterns. The cancellation flow is as simple as signup.
3. Real transparency, with a stated scope
Transparency in most of the industry has become performative. A report published once a year. A privacy page written by lawyers for lawyers. A cookie banner designed to make “reject all” harder than “accept all.”
We do transparency on the front of the package. On the product page itself: what happens to your data, what does not yet exist, what is on the roadmap and what is not.
What we share: architecture, sub-processors, code, DPA, incident reports, roadmap, pricing mechanics, what a feature does and does not do today.
What we do not share: customer data, personal data of staff, commercial negotiations in progress, vulnerabilities before they are patched. Saying this out loud matters. A company that claims to share everything is not credible. A company that states its scope is.
TRMNL wrote a line we admire. “We log nothing about your usage. Including us.” The “including us” is the honest part. It is what most companies leave out.
Voice implications
Say what does not exist yet. Use “not yet” for roadmap features; say “not planned” when that is true. Publish what we are still figuring out. Tell the full story including the footnotes, and trust that honesty makes us more credible than vendors who only share the highlights.
Humour is welcome when it lands on the absurdity of the situation: self-deprecation, observations, dry jokes about the gap between industry claims and industry actions. Puns do not suit us. Trying to be clever does not suit us.
Design and UX implications
Status is visible in the product. If a feature is in development, the UI says so. If something is not yet supported, the empty state explains why rather than hiding behind a generic “coming soon.” Changelogs are written for humans, not for marketing. When the product updates, users find out because the interface tells them, not because we sent an email campaign. Nothing that matters hides in a settings panel the user will never open.
How our voice flexes: two registers
The voice is one voice. It runs at two speeds, depending on what the reader needs.
Register A. Practical
Used on the product pages, pricing, FAQ, onboarding, support replies, microcopy, changelog entries, error messages.
The reader needs to decide something. Short sentences. Direct address. The buyer’s own objection as the heading, answered in one line. Triplets and stacked negations. The setup plus accent-word format (see Signatures below). Closes with a concrete action or a plain fact.
Example: “You already know AI works. The question is whether you can trust it.” / “No infrastructure project, no IT tickets, no lengthy procurement.”
Register B. Principled
Used on founding principles, about, longer blog posts, positioning essays, keynote outlines, press responses.
The reader needs to understand what is at stake. Longer argumentation that opens with what is wrong in the world, earns the claim, and lands on a structural fact. The Belief, Commitment, In practice structure (see Signatures). Closes with a fact, not a slogan.
Example: “Every major AI platform treats privacy as a configuration state. Tick this box, enable this mode, sign this addendum. For organisations handling client data, that is not how it works.”
Which to use: if the reader is about to make a buying decision, go Practical. If the reader is about to decide whether Klai is their kind of company, go Principled. If the reader is already using the product and something broke, go Practical and short.
Vocabulary
Words we use
structural, architecture, articles of association, commons, patron, public fabric, primary infrastructure, sovereignty, steward-owned, unsellable, precondition, welcome (for sensitive data), yours, approved, plain language, collective memory, quietly (as in “quietly reconfigured”), conditional, asymmetry, not yet, not planned, including us, public, auditable, verifiable, colleague (never “agent” for people)
Words we do not use
leverage, empower, unlock, seamless, solution, journey, transform, cutting-edge, innovate, synergy, ecosystem, game-changing, revolutionary, powerful, intuitive, easy, effortless, smart (as adjective), we believe, we’re excited to, please (as softener), thrilled, passionate, mission-driven (as slogan), work smarter, next-gen, state-of-the-art
We also do not use cognitive verbs for the product: understands, thinks, learns, knows, reasons.
Signature moves
These are patterns that appear in Klai writing and should keep appearing. They are our handwriting.
The accent-word heading
Every heading ends on a short phrase that lands the punch. That phrase is rendered in the Parabole display variant (our font-accent), but the rhetorical effect works even without typography. The accent must carry content. It cannot be filler.
Rule: one short accent phrase per heading, usually one to three words, always at the end, always doing the work.
- “Your AI. Your data. Your rules.”
- “Compliance isn’t a checkbox.”
- “AI that knows your organisation.”
- “Simple pricing. No surprises.”
- “Something built from all of us should be for all of us.”
- “Built for the people who need to be able to say yes.”
- “Questions we get. Answered directly.”
Length is flexible (one to three words works). The discipline is that the accent must be the word doing the work, and it must sit at the end of the line.
Belief, commitment, in practice
Our long-form structure. Used for principled pieces and wherever we make a structural claim.
- Belief: how the world works and what is wrong with it
- Commitment: what Klai concretely does about it
- In practice: a real incident (named company, date, number) that proves the point
This three-beat format is what makes a Klai statement read as argued rather than asserted.
Bait, then flip
“Not a values page. A contract with ourselves.” / “You already know AI works. The question is whether you can trust it.”
Open with a frame the reader expects, then turn it. Works in both registers.
Question, one-word answer
“Can Klai be acquired by a US company?” → “No.”
Then the explanation. Never lead with the explanation.
Tone across surfaces
One voice, calibrated for the moment.
| Surface | Pose |
|---|---|
| Hero headings, landing pages | Declarative, short, accent-word signature |
| Feature descriptions | Outcome first, mechanism second, one sentence each |
| Pricing | Flat, specific, no softeners around cost |
| FAQ | Buyer’s objection as the question, Yes or No upfront, then the reasoning |
| Changelog | Action verb, what changed, who benefits, one line |
| Error messages | What happened, what the user can do next, no apology theatre |
| Empty states | Say why it is empty, say what fills it |
| Support replies | Direct answer first, context second, no “great question” |
| Sales emails | No boilerplate opener, one specific reason this fits this organisation, one ask |
| Outage and incident | Tell it straight, include the timeline, say what we are doing now and what is still unknown |
| Legal docs | Written so a non-lawyer can read them; where that is not possible, link to a plain-language summary alongside |
| Blog posts | Principled register, long-form, argued, named sources |
| Peer authority, no theatre. If it reads like a motivational poster, rewrite it. |
Dutch and English
One voice, two languages. The voice does not change; the register adjusts slightly.
Dutch (NL): More direct, more informal. “Gewoon”, “onwijs”, “gaaf” are welcome where they fit. Dry humour travels well; sharp humour travels better. Self-deprecation is natural. English terms are fine where they read naturally (we say deployment, not uitrol), but explain briefly for non-technical readers.
“Je kent het: je test ChatGPT met klantdata, het werkt geweldig, en dan belt de compliance officer. Herkenbaar? Dacht ik al.”
English (international): Slightly more polished than Dutch, still warm and conversational. Avoid Americanisms when talking about European values. Humour is dry and understated. Avoid idioms that do not travel.
“You tested ChatGPT with real customer data. It worked beautifully. Then your compliance team had questions. Sound familiar?”
The voice test
Before anything goes out, read it aloud and ask:
Peer authority or theatre?
- Does this sound like a senior colleague who has done the work, or like a consultant performing confidence?
- Can every trust claim be traced to a legal fact, a technical detail, a named competitor, or a number?
- Did we name what does not yet exist?
- Did we avoid cognitive verbs for the system?
- Did we resist being clever for the sake of it?
If any answer is no, rewrite. The test is not whether the copy is polished. The test is whether it is something we would defend in a conversation.