Responsible AI Policy

We build systems that act on our clients' operational data. This policy sets out the rules we hold ourselves to, the uses we refuse, and the controls we implement by default. It forms part of the service description in every engagement.

1. Scope

This policy applies to AI components we design, build, deploy, evaluate or operate — including third-party models we integrate, agents that take actions in client systems, and any assistant that faces a client's customers or staff.

2. Principles

• Purpose limitation — we automate a defined process, not "AI transformation". Every system has a written remit.
• Human accountability — an accountable person is named for every deployed system, on the client side and ours.
• Measured, not asserted — quality claims come from evaluation runs on client data, with the sample and the working shown.
• Least privilege — agents receive the minimum permissions, scoped tools and typed actions required for the task.
• Reversibility — where an action has consequences, it is either reversible, staged behind approval, or both.
• Transparency — affected people can find out that automation is involved and how to reach a human.

3. Human Oversight and Confidence Thresholds

• Every model-driven step has a calibrated confidence threshold, tuned on the client's evaluation set and recorded in the solution documentation.
• Below the threshold, the item goes to a human review queue with the evidence attached — the source text, the extracted fields, and the reason for the low score.
• Decisions with legal, financial, safety or employment consequences are never made autonomously. They may be prepared by a model and must be approved by a person.
• Every automated action is logged with its inputs, model version, threshold applied and resulting action, in a form the client can audit.
• Clients can raise a threshold at any time; this reduces automation volume and is a legitimate, supported configuration.

4. Data and Training

• We do not train models on client data. Not ours, and not a third party's.
• Where a task does not need personal data to reach the model, direct identifiers are redacted or tokenised before inference.
• Third-party model providers are used with zero-retention or no-training configurations where offered, and this is recorded in the solution documentation.
• Data residency — US or EU — is fixed in writing before development begins and reflected in the DPA.
• Synthetic or public data may be used for generic engineering tests; client data is never used to benchmark our work for other clients.

5. Model Selection and Provenance

• We select models against the task and the client's constraints, and document why: quality on the evaluation set, latency, cost, licence terms, and whether the model can be self-hosted.
• Where a client requires that data not leave its environment, we deploy open-weight models inside the client's infrastructure and accept the quality trade-off explicitly, in writing.
• Model versions are pinned. Upgrades are treated as changes: evaluated against the golden set before deployment, never silently applied.
• We prefer providers that document training data provenance, evaluation practices and known limitations, and we avoid providers whose terms would claim broad rights over client inputs.

6. Evaluation and Monitoring

• A golden evaluation set is built from the client's real documents or cases, with expected outputs agreed by the client's reviewers.
• Every prompt, model or pipeline change runs against that set in continuous integration; a regression blocks deployment.
• Quality, cost, latency and exception-rate dashboards are produced per deployment, plus drift review at an agreed cadence.
• Accuracy figures are reported with the sample size and the definition used. We do not publish a single "accuracy %" without its context.
• Where measurable harm or systematic error is detected in production, we raise it with the client even when it is not contractually required.

7. Transparency

• Where AI interacts with a client's end users, the client is advised to disclose it plainly; we provide the wording and the escalation path to a human.
• Automated actions in client systems are attributable — a log entry identifies what ran, when, with which model version.
• Staff of the client whose work is affected are informed of what the system does and what it will not do. Automation is not introduced quietly against the people who run the process.

8. Prohibited Uses

We decline projects, and do not build components, for the following:

• Social scoring, ranking or categorisation of people by behaviour or characteristics
• Biometric identification, face recognition, gait or emotion inference
• Real-time or retrospective surveillance of individuals, including employees
• Fully automated decisions with legal, financial or similarly significant effect without meaningful human review
• Systems designed to deceive people about whether they are interacting with a machine
• Manipulative design intended to bypass informed choice
• Generation of disinformation, or content intended to harass or discriminate
• Processing of children’s data, or any project targeting minors
• Uses subject to sectoral prohibition where the client operates, such as certain credit, housing, employment and medical decisions

Where a client's intended use falls outside this policy after work has started, we will stop the affected work and discuss remediation or termination, with fees for work performed payable.

9. Roles and Responsibilities

• Delivery lead — confirms the use case is within this policy before a proposal is signed.
• AI engineer — implements thresholds, redaction, logging and evaluation; documents model choice and limitations.
• Evaluation & QA — owns the golden set, runs regressions, signs off before production changes.
• Client process owner — owns the operational decision, the review queue staffing and the escalation policy.

10. Incidents and Raising a Concern

Suspected misuse, unexpected model behaviour or harm caused by a system we built should be reported to info@helixworks.site with "AI concern" in the subject line. We acknowledge within one business day and investigate regardless of whether the reporter is a client, an employee of a client, or a member of the public. Security incidents follow the notification commitments in the DPA.

11. Policy Review

This policy is reviewed at least annually and whenever applicable law or our practice changes. We welcome scrutiny: clients may request the documentation behind any statement on this page.