AI Principles

Human oversight

AI systems built by Navitra are designed with human approval steps in front of any action that could affect money, contracts, customers, or safety. We treat this as a default, not an option clients can quietly remove.

• Money: any action involving financial transactions, invoicing, payments, or budget commitments above a threshold agreed with the client requires explicit human authorisation before execution. In the absence of a client-specified threshold, any financial action requires human authorisation.
• Contracts: no agent we build will sign, accept, modify, or terminate a contract or legal agreement without a human approving that specific action. Model output that constitutes a draft proposal is distinct from sending it.
• Customer-facing communications: messages sent in the client's name to their customers will pass through a human review step unless the client has explicitly accepted automated sending in writing and has tested and approved the failure modes.
• Safety: any output that could affect the physical safety of a person — for example in healthcare, manufacturing, or logistics applications — requires human review before acting on it.

Clients who wish to reduce or remove oversight steps for a specific workflow must accept the residual risk in writing, with the specific automated actions and their conditions documented in the engagement contract. We will advise against configurations we believe are unsafe.

Evaluation before deployment

A model is not ready to deploy because it produces plausible outputs on a few examples. We require structured evaluation before any system goes into use, and the terms of that evaluation are agreed before training begins — not after the outputs are visible.

• Evaluation set agreed in advance: the test set, the metrics, and the pass/fail thresholds are agreed with the client before model training starts. This prevents the evaluation being shaped by the model's observed strengths after the fact.
• Coverage: evaluation sets include representative examples, edge cases, adversarial examples, and examples drawn from the actual deployment context — not only clean, well-formed inputs.
• Failure modes shared with the client: before go-live we document the ways in which the system is known to fail and share these with the client. A client should know the boundaries of the system before their users encounter them.
• No deployment until criteria are met: if a model does not meet the agreed evaluation criteria, it is not deployed. We will not release a system on the understanding that the client accepts the gaps.
• Production monitoring: ongoing monitoring criteria are agreed at the same time as deployment criteria. A model that passes evaluation can degrade in production as input distributions shift.

Honesty about limitations

We tell clients about the structural limitations of language models at the start of every engagement. These are not edge cases or implementation details — they are properties of how the technology works.

• Confident text is not accurate text: language models generate fluent, confident-sounding output regardless of whether the content is correct. A model that does not know the answer will produce a plausible-sounding wrong answer, not a refusal. Confidence in the output is not evidence of accuracy.
• Models can be influenced by content they are given: if a model is processing documents, emails, or other external content, that content can contain instructions that shift the model's behaviour — a class of attack known as prompt injection. A model that is fed untrusted content should be treated as potentially compromised.
• Training data shapes outputs: a model's knowledge is bounded by its training data, which has a cutoff date and reflects the coverage and biases of whatever it was trained on. It does not know what it does not know.
• Stochastic outputs: a model given the same input twice may produce different outputs. For applications where consistency matters, this must be accounted for in the system design — not treated as a defect that will be fixed later.

We document these properties in writing for each client engagement. An AI system that fails in a predictable way is manageable; one whose limitations were not communicated creates liability.

Scope of use

A model evaluated and approved for one purpose is not automatically fit for a different purpose, even when the new task appears similar.

• A model trained and evaluated for summarising internal documents is not validated for answering customer queries, generating client reports, or making operational recommendations — each requires its own evaluation.
• Extending a deployed model to a new use case is a new project with its own evaluation and sign-off, not an increment to an existing approval.
• This applies to agents as well as models: an agent evaluated to read from a system is not cleared to write to it, and vice versa.

Clients who identify a new use case for an existing model should raise it with Navitra before deploying. We will advise on whether the existing evaluation is sufficient or whether new testing is needed.

Data minimisation

We apply data minimisation principles across the full lifecycle of an AI system — from training data selection through to inference inputs. Full detail of how we handle data when training and deploying models is in our Data and Models statement.

• Training data: training datasets are scoped to what is necessary for the intended task. We do not include personal data in training corpora unless there is a documented lawful basis under UK GDPR and the data subject has been informed in a way consistent with that basis.
• Inference inputs: data passed to a model at inference time should be limited to what the specific query requires. Sending a full customer record to answer a question about one field is not minimisation.
• Context window hygiene: in multi-turn agent systems, prior context is retained in the model's context window and can influence future outputs. Context retention policies should be explicit, not assumed.
• Model outputs: outputs should not reproduce personal data or confidential content beyond what is needed to answer the query. Outputs surfaced to users should be reviewed for unintended data disclosure.

Fairness

A model trained on historical data reproduces the patterns in it. If historical decisions were unfair, the model will learn and replicate those patterns — often at a scale and consistency that exceeds what a human system would produce.

• The fact that a decision is made by a model does not make it neutral. A model reflects the data it was trained on, and that data reflects decisions made by people.
• Any system that makes or informs decisions affecting individuals — hiring, access to services, credit, healthcare prioritisation, or similar — requires fairness evaluation before deployment. This evaluation must consider the protected characteristics defined in the Equality Act 2010: age, disability, gender reassignment, marriage and civil partnership, pregnancy and maternity, race, religion or belief, sex, and sexual orientation.
• Fairness evaluation is not a checkbox. It requires disaggregated analysis of outcomes across relevant groups, not just aggregate accuracy metrics.
• Where a client's historical data reflects past discriminatory patterns, we will identify this during scoping and recommend a mitigation strategy. In some cases the right answer is not to train on that data at all.

Security of AI systems

AI systems introduce security risks that are distinct from those of conventional software. The three most significant in the systems Navitra builds are prompt injection, data leakage through outputs, and misuse of agent tools.

Prompt injection

A language model processes text as instructions. Content that the model reads — documents, emails, web pages, user messages — can contain instructions that override the system prompt and alter the model's behaviour. An attacker who can put content in front of a model can potentially redirect it, extract information it should not reveal, or cause it to call tools it should not call. All external content fed to a model should be treated as untrusted, regardless of its source. Tool calls derived from model output should be validated before execution.

Data leakage through outputs

Models can reproduce content from their training data, their context window, and their system prompt in outputs. A model with access to multiple users' data — or to a confidential system prompt — may surface that content to the wrong user. System prompts should be treated as potentially readable. Outputs should be reviewed for unintended disclosure before being surfaced to users, especially in multi-tenant deployments.

Misuse of agent tools

An agent given access to external tools — APIs, code execution environments, email, databases, or payment systems — can be manipulated into misusing those tools if it is vulnerable to prompt injection or if its tool access is not properly constrained. Tool permissions should follow the principle of least privilege: an agent is given access only to the tools required for its specific task. Irreversible actions — sending an email, writing to a database, calling a payment API — should require an explicit confirmation step rather than being executed automatically from model output alone.

Security requirements for AI systems are covered in our Information Security statement and in the technical design documentation for each engagement.

Traceability and logging

A system whose decisions and actions cannot be reconstructed after the fact cannot be audited, investigated, or corrected. We require logging to be designed in from the start of every engagement.

• Inputs and outputs: model inputs, outputs, and tool calls are logged with timestamps, session identifiers, and user identifiers where applicable.
• Agent actions: every action an agent takes in an external system — a database write, an API call, a message sent — is attributable to a specific session and user. An agent that takes an action should leave a record of what it did, why it was authorised to do it, and when.
• Retention: logs are retained for a period agreed per engagement and are accessible to the client for audit purposes. Retention periods are defined before deployment.
• Evaluation records: evaluation results, evaluation set versions, and pass/fail decisions are retained and versioned alongside model versions. A deployed model version is traceable to the evaluation that cleared it.
• Human decisions: where a human approval step is triggered, the approver, the decision, and the timestamp are recorded.

What we will not build

The following types of AI system fall outside the scope of what Navitra will build, regardless of commercial terms or client instruction:

• Systems that make fully autonomous decisions about individuals' access to credit, lending, insurance, employment, housing, healthcare, or social services — including mortgage underwriting decisions — without a documented human approval step and a right of appeal for the affected individual.
• Tools designed to monitor, score, or surveil employees, customers, or other individuals covertly — without their knowledge — where informing them is practicable.
• Models trained or fine-tuned to generate disinformation, synthetic media designed to misrepresent its origin, or content designed to induce a specific person to take an action they would not take if informed.
• Weapons guidance, targeting, or trajectory systems, or dual-use tools whose primary foreseeable application is to enable or assist a military or paramilitary strike capability.
• Systems whose primary purpose is to help an organisation circumvent data subject rights under UK GDPR or the Data Protection Act 2018 — for example, tools designed to suppress, identify and delay, or systematically obscure subject access requests.
• Systems that automate decisions producing disproportionate adverse outcomes for individuals sharing a protected characteristic under the Equality Act 2010, without a proportionate legitimate aim, documented impact assessment, and effective human oversight.

Clients who wish to discuss how the scope of a proposed engagement relates to these constraints are welcome to contact us. We will decline an engagement that falls within this list regardless of how it is framed.

How to raise a concern

If you believe that a system Navitra has built or is building is being used in a way that conflicts with these principles, or if you have a concern about an AI system you have encountered that may involve Navitra, contact us at contact@navitratech.com.

• We will acknowledge your concern within two business days.
• Concerns raised in good faith will not result in any detriment to the person raising them.
• Where a concern relates to processing of personal data, you may also contact the Information Commissioner's Office at ico.org.uk/make-a-complaint.

Jaydev Bhatt, Director, is the named individual responsible for AI ethics decisions within Navitra Technologies.

Regulatory context

AI systems built and deployed in the UK operate within an existing body of law. There is no single UK AI Act as of the date of this page, but several existing legal frameworks apply directly to AI systems depending on how they are used.

Always applicable

• UK GDPR and Data Protection Act 2018: applies wherever an AI system processes personal data. Obligations include lawful basis, transparency, data minimisation, accuracy, and rights of data subjects. The ICO has published specific guidance on AI and data protection.
• Equality Act 2010: applies wherever an AI system makes or informs decisions that affect individuals. Outputs that result in less favourable treatment on the basis of a protected characteristic — directly or indirectly — can constitute unlawful discrimination, regardless of whether the decision was made by a human or a model.

Applicable in specific contexts

• EU AI Act: applies where Navitra or its clients operate in the EU, where EU users are affected, or where AI systems are placed on the EU market. The Act classifies AI systems by risk level and imposes obligations on both developers and deployers. High-risk systems — including those affecting employment decisions, access to services, and critical infrastructure — carry the most significant requirements.
• Sector-specific regulation: AI systems used in financial services (FCA), healthcare (CQC, MHRA), legal services (SRA), or audit (FRC) are subject to the rules of those regulators in addition to the above. Clients deploying Navitra-built systems in regulated sectors are responsible for ensuring their use is compliant with their own regulatory obligations.
• Consumer protection: where an AI system is used in a consumer-facing product, consumer protection law — including requirements for accuracy of claims and prohibitions on unfair commercial practices — applies to outputs the system produces.

This section states the regulatory frameworks as understood at the review date below. It is not legal advice. Clients deploying AI systems in regulated sectors should take independent legal advice on compliance with their own regulatory obligations.

Document information

Questions about these principles or requests to discuss them in the context of a specific engagement can be sent via the contact page.

Version 1.0  ·  Last reviewed 25 September 2026  ·  Owner Jaydev Bhatt, Director