Responsible AI

1. Scope

This policy applies to every engagement in which we design, build or operate systems that use machine learning, large language models or other AI techniques, whether as the primary deliverable or as a component of a wider system.

Where an engagement has its own governance requirements, those are recorded in the Statement of Work. Where they are stricter than this policy, the stricter terms apply.

2. Principles

Four commitments shape how we build. Each is set out in detail, with the practices that make it checkable rather than aspirational, in the section noted:

• Human oversight. Where a decision matters, a named person can see it, understand it and overturn it (section 5).
• Explainability. We favor approaches that can be explained, and avoid black-box designs where an explanation is required (section 4).
• Data boundaries. We do not use client data to train or fine-tune models, unless a client asks us to in writing for their own dedicated model. Client data stays within the agreed boundary (section 6).
• Continuous evaluation. Systems are measured before go-live and monitored after it (section 8 and section 9).

3. What we will not build

Some applications of AI cannot be made safe by better engineering. We decline work in these categories, and we will say so early rather than late:

• systems that assign people a social score, or rank them for general trustworthiness, from unrelated behavioral data
• untargeted scraping of facial images, or biometric surveillance of people in public spaces
• inference of emotion, or of sensitive characteristics such as beliefs or orientation, in hiring, education or the workplace
• systems that decide on credit, employment, housing, benefits, insurance or access to essential services without a person able to review and overturn the outcome
• systems designed to deceive people about whether they are dealing with a machine, or to manipulate behavior against their interests
• deployments where a decision must be explained but the proposed design cannot explain it

This list is not exhaustive. Where a proposed use sits close to one of these categories, we raise it before work begins rather than after.

4. Risk-appropriate design

We match AI capabilities to risk levels. High-stakes decisions in regulated environments receive more conservative designs with greater human oversight, while lower-risk applications may benefit from more automation. We avoid black-box deployments in contexts where explainability and auditability are required.

Before design begins, we assess where a proposed system sits on that scale: what decision it influences, who is affected, what the consequence of a wrong output is, and whether that consequence can be caught and reversed. That assessment drives the level of oversight, logging and evaluation we build in, and it is written down rather than assumed.

Where an engagement falls within a regulatory regime for AI — including the EU AI Act, sectoral supervisory guidance, or a client’s own model risk framework — we design against the obligations that apply to the system’s risk tier and produce the documentation those obligations call for.

How our delivery aligns with AI frameworks

The table below shows how our delivery practice lines up with the main AI frameworks. This is alignment, not certification: YatiSphere holds no AI certification, and none of these frameworks has assessed us.

5. Human oversight in practice

Human oversight means a named person can see what the system decided, understand why, and change the outcome. In practice, that means:

• approval steps sit where liability sits: the person accountable for a decision is the person who approves it
• reviewers see the basis for a recommendation, not only the recommendation, and can act on the underlying material
• the interface makes it as easy to reject or amend an output as to accept it, so that review does not become rubber-stamping
• every automated and every overridden decision is logged, with who acted and when
• there is a documented way to turn the system off, and an escalation path when it behaves unexpectedly

6. Data and training

We do not use client data to train or fine-tune models, unless a client asks us to in writing for their own dedicated model. Client data is not added to shared training sets, not used to fine-tune shared models, and not retained for that purpose.

Client data stays within the boundary agreed in the engagement. Where a system is built in your cloud accounts, it stays in the region you choose. Where personal data is processed, we do so as your processor under a data processing agreement, as described in our Privacy Policy.

We keep training data, evaluation sets and production data separate, collect only what the purpose requires, and apply defined retention and deletion rules to each.

7. Third-party models

Most production AI work builds on models operated by third parties rather than models trained from scratch. Where we do so:

• we tell you which models an engagement uses, and where they run
• we configure provider settings so that your prompts and outputs are not retained for provider training, and we confirm that in writing
• we prefer deployments where the model runs within your cloud tenancy or a region you have approved
• we record the model version a system depends on, so that a change in provider behavior can be traced and re-evaluated

Model providers publish their own terms, and those terms change. We monitor the ones we depend on and raise material changes with you.

8. Evaluation before go-live

No AI system we build goes to production on the strength of a demonstration. Before go-live we measure it against a target you set, on data representative of your own.

• accuracy and failure modes are measured and reported, not asserted
• we test the cases that matter most, including the ones the system is expected to find hard
• where outcomes affect people, we look for systematically different performance across the groups the system will encounter
• the evaluation result is written down, and forms part of the decision to deploy

If a system does not meet the target, we say so. We would rather report that plainly than ship something that will fail in front of your users.

9. Monitoring and incidents

A model that performed well at launch will not necessarily perform well six months later. Inputs shift, providers update models, and the world the system was measured against changes.

• we instrument production systems so that accuracy, volume and failure patterns are visible over time
• we set thresholds that trigger review rather than waiting for a complaint
• where we operate a system, we review its outcomes on a schedule agreed with you

Where an AI system causes or contributes to harm, we treat it as an incident: contain it, tell you without undue delay, establish what happened, and agree the fix. Where a regulator or affected person must be notified, we support you in doing so.

10. Accountability

Responsibility for this policy sits with the company’s leadership, and applies to everyone who works on an engagement. It is not delegated to the individual engineer on a project.

We review this policy as standards, regulation and our own practice develop, and we update it rather than letting it drift out of date.

Anyone — a client, a person affected by a system we built, or a member of the public — may raise a concern with us, and we will respond.

11. What we ask of clients

Responsible deployment is a shared obligation. Where we build a system and hand it over, we ask that you:

• keep the human review steps in place rather than removing them for throughput
• tell us if you intend to use the system for a materially different purpose than the one it was evaluated for
• maintain the monitoring we hand over, and act on what it reports
• tell affected people that AI is in use, where the law or fairness requires it

We will say clearly when a proposed change to a system we built takes it outside what we evaluated.