Skip to main content
Kerah

Responsible AI

AI that recommends. People that decide.

AI is straightforward to demonstrate and difficult to put into production responsibly — particularly where an output touches a person's money, entitlement, employment or care, and particularly where the system acts rather than only answers. These are the principles Kerah applies when a system uses it, decided before deployment rather than after an incident.

These principles apply to systems Kerah builds for clients and to Kerah’s own products. They are delivery commitments, not assertions about any model’s behaviour.

Human authority

Decisions no Kerah system makes.

Systems Kerah builds may recommend, rank, reconcile, draft and flag in every one of these areas, and an agent may carry out the steps that lead up to one. The act itself requires a person holding the relevant authority, and the system records who exercised it.

The system's arrow stops at the boundary. Only the person's arrow continues past it.
  • Releasing, transferring or disbursing money
  • Granting, refusing or withdrawing a person's entitlement, benefit or access
  • Overriding a control, a permission or an approval limit
  • Publishing anything externally, including a performance claim or an impact figure
  • Awarding, suspending or terminating a supplier, partner or contract
  • Making an employment, credit or admission decision about a person
  • Submitting a regulatory filing, a statutory return or a formal response to an authority
  • Taking or withholding an action on which a person's safety depends
  • Closing a financial-crime or sanctions alert
  • Making or altering a record of a person's health
  • Approving or refusing assistance to a beneficiary
  • Determining religious eligibility, or resolving a Sharia exception

Client data does not train general models.

Neither Kerah nor any subprocessor uses a client's data, prompts, documents, images, metadata or model outputs to train, fine-tune or improve a general-purpose or shared model. This applies to every engagement by default and is written into the AI governance schedule. It is not conditional on a setting, a tier or a configuration choice.

It closes, it does not end

Every stage constrains the next, and the last one returns to the first. Exactly one step in the cycle is a person deciding.

An AI feature is never finished. Model pricing, capability and terms change underneath it, so the loop closes rather than the line ending.

Nine decisions, made before deployment

Most AI projects fail somewhere in this list rather than at the model. The order matters: each decision constrains the next.

  1. 01

    Start with a real operational use case

    The work begins with a specific, bounded task that costs the organization something today. An open-ended assistant is not a use case, and neither is an agent with a general mandate — neither can be evaluated.

  2. 02

    Define success and failure before deployment

    What counts as a good output, and what counts as an unacceptable one, is agreed in writing first. Otherwise every result can be rationalised after the fact.

  3. 03

    Identify allowed and prohibited data

    The data the system may receive is listed explicitly, and so is the data it may not. Where the system calls tools, the same list governs what each tool may reach. Confidential, personal or production data is not sent to a public AI service unless the contract, data processing agreement, configuration and security review all permit it.

  4. 04

    Evaluate using representative scenarios

    Accuracy is measured against a set drawn from real work, including the malformed, ambiguous and multilingual cases that a curated demonstration leaves out.

  5. 05

    Keep human review for consequential decisions

    Where an output affects a person's money, entitlement, care or standing — or would cause an action to be taken on the organization's behalf — a person with the relevant authority decides. Which decisions those are is defined explicitly.

  6. 06

    Preserve source references where the use case requires them

    For retrieval and knowledge tasks, an answer without a citation cannot be checked. Where the use case demands verifiability, the system returns its sources.

  7. 07

    Log and monitor outputs where appropriate

    Traceability is designed proportionate to impact, so that a decision can be explained months later without reconstructing it from memory.

  8. 08

    Define fallback behaviour

    What the system does when the model is unavailable, rate-limited or below a confidence threshold is specified as part of the design, not discovered in production.

  9. 09

    Reassess cost, risk and value after launch

    Model pricing, capability and terms change. An AI feature is reviewed after launch to confirm it still earns its place.

Where this stops

  • Kerah does not claim guaranteed accuracy. What can honestly be offered is measured performance against a defined evaluation set.
  • Kerah does not offer, and will not build, autonomous approval of money, a person's entitlement, a contract, a partner's status or a religious ruling. This is not a configuration option.
  • An agent acts only through tools defined for the task, within the permissions held by the person on whose behalf it runs, and with every effect recorded and reversible. Kerah does not build an agent that grants itself access, moves money or contacts a third party unattended.
  • Kerah does not make claims about the safety, legality or compliance of any third-party model.
  • Autonomous medical, employment, credit, eligibility and similarly high-impact decisions are out of scope without specialist governance and explicit written approval.
  • Where a deterministic rule solves the problem at lower cost and lower risk, Kerah recommends the rule.

How Kerah uses AI in its own delivery work

AI-assisted tooling is used in engineering, including tooling that acts on a repository or an environment rather than only suggesting text, and it is governed the same way as anything else that touches client material. Tools are classified before an engagement begins, client data is only submitted where the contract permits it, and generated code, decisions and communications are reviewed by a person before they are used.

AI and intelligent automation as a service

What is preserved, so a decision can be explained later

Traceability is the difference between a system that can be audited and one that can only be trusted. Where an AI output contributes to a consequential decision, the record below is retained with it.

  • The input, and the source records it was drawn from
  • Any tool or data the system called, and what each returned
  • The permissions the system held at that moment, and the person on whose behalf it acted
  • The model and version that produced the output
  • The policy or rule version in force at that moment
  • The recommendation, with its confidence or exception signals
  • The person who reviewed it, their decision and their reasoning

Escalation and appeal

A person affected by a decision a system contributed to needs a route that does not depend on that system. It is designed alongside the workflow, not added after a complaint.

The person is told a system was involved
Where a recommendation contributed to a decision affecting someone, that is disclosed in the decision itself. A person cannot contest what they were not told about.
A human review route exists and is reachable
The route to a review by a person who did not make the original decision is designed alongside the workflow, with a stated response expectation set by the client organization.
The reviewer sees the evidence, not only the output
A reviewer is shown the inputs, the sources, the policy version and what the system flagged as uncertain — enough to reach a different conclusion if one is warranted.
Outcomes feed back into evaluation
Overturned decisions are treated as evaluation data. A pattern of reversals is a signal about the system, not only about the cases.

When the system is working and the outcome is still wrong

An AI incident is not a security incident. The software is behaving as built and producing an unacceptable result anyway, which is why suspension has to be designed in advance.

Kerah’s assurance position
  • A defined threshold at which an AI feature is suspended rather than monitored
  • A named person able to suspend it, and a system that continues to function without it
  • Withdrawal of an agent's tool permissions as a first response, so the system stops acting before it stops answering
  • Preservation of the traceability record for the affected period
  • Review of whether the evaluation set failed to represent the case
  • A record of the disposition, and notification to the client under the agreed terms

Have a use case in mind?

Describe the repetitive work and the decision that follows it. That is enough to say whether AI is the right instrument.

Request a consultationSecurity