Ethical AI Policy

1. Purpose and scope

This policy defines how YPAI manages ethical and operational risk in AI Data & Evaluation and AI Implementation. It covers data collection, sourcing, annotation, human review, quality assurance, model and workflow evaluation, trajectory data, agent evaluation and governance, assistants, agents, retrieval augmented generation and knowledge systems, workflow and document automation, integrations, deployment, monitoring, regression testing, and movement from pilot to production.

It applies to work performed by YPAI and to the controls, records, decisions and handover materials produced for each engagement. It is written for customers, procurement teams, security reviewers, risk functions and regulated sector buyers assessing YPAI as a supplier.

YPAI applies Controlled Delivery across both service lines. Scope, rights, quality, security, change control and acceptance are defined from the first project decision through handover.

2. Principles

Documented purpose and rights. YPAI uses training and evaluation data under documented per-contributor consent and provenance records. The permitted purpose, relevant rights and project context are recorded rather than inferred.

Defined quality. YPAI evaluates work against criteria agreed before delivery begins. Results are recorded as pass, review or fail, and are not reduced to a single opaque total score.

Recorded human judgement. Human review, sampling, escalation and decision criteria are defined for the engagement. Reviewer decisions are recorded and remain traceable through acceptance and handover.

Transparent limitations. YPAI states known limitations in data, model behaviour and evaluation coverage.

Documented scope. YPAI documents the controls and evidence within its assigned scope, including the named contacts for acceptance, unresolved issues and follow-up.

3. Data foundations

YPAI uses training and evaluation data obtained under documented per-contributor consent. Provenance records connect data to its contributor or source, collection context, consent basis and the use defined for the engagement.

The Responsible Data Collection Policy sets out the operating requirements for collection, consent and provenance. This Ethical AI Policy applies those foundations to evaluation and implementation work, including the use of data in model testing, workflow testing and post-deployment monitoring where included in scope.

European storage is the default. Data residency, subprocessors and transfer controls are defined for each project. YPAI provides subprocessor transparency so the customer can assess the processing arrangement and its own obligations.

4. Quality and evaluation

YPAI evaluates quality through deterministic checks, statistical checks, learned quality models and cross-modal consistency checks. The methods used depend on the data, model, workflow and risk addressed by the engagement.

Quality is not represented by one opaque total score. Evidence is separated so that technical validity, statistical performance, learned assessments and consistency across modalities can be reviewed on their own terms.

Acceptance criteria are agreed before work begins. Each assessed item, batch, model behaviour or workflow outcome is assigned a documented pass, review or fail result according to those criteria.

Evaluation work can include human evaluation, multilingual testing, failure analysis, regression testing and monitoring after deployment. The evaluation design identifies what is being tested, the relevant baseline, the observed limitations and the conditions under which a result applies.

5. Human oversight and accountability

Human review is part of YPAI delivery. Reviewer roles, sampling methods, escalation paths and pass or fail criteria are defined per engagement.

Human quality assurance follows the acceptance and sampling plan agreed for that engagement. Decisions are recorded with enough context to establish what was reviewed, which criterion was applied, what outcome was reached and whether escalation or corrective work was required.

Human-review coverage follows the agreed sampling and acceptance design. The handover record states that coverage.

At handover, the engagement record identifies the named YPAI contact and the named customer contact for acceptance, unresolved issues, agreed changes and follow-up actions.

6. Limitations and known risks

AI behaviour can vary across languages, domains, accents and demographic groups. A result observed in one context may not hold in another context, and evaluation coverage does not remove that variation.

No AI system can be guaranteed free from bias or perfectly accurate. YPAI records known limitations, observed failure patterns, gaps in evaluation coverage and material assumptions rather than concealing them.

Where multilingual or group-specific performance matters, the evaluation scope defines the languages, domains, accents and demographic groups included. Findings are communicated with the applicable baseline, version and test conditions so the customer can decide whether further evaluation, corrective work or deployment restrictions are required.

7. Regulatory posture

YPAI aligns its data governance work with EU AI Act Article 10 for engagements supporting high-risk AI. YPAI provides documentation that can support a conformity assessment, including records relevant to data governance, quality, provenance, limitations, change control and acceptance.

For healthcare engagements, YPAI may describe work as HIPAA compliant where the engagement is handled accordingly. HIPAA has no certification or accreditation scheme. Controls in place for a given engagement are documented in the statement of work.

For financial services, YPAI can support work performed in MiFID II recording and retention contexts and DORA operational resilience contexts. YPAI documents the controls within its assigned scope, while the customer determines applicability, retention decisions, resilience requirements and regulatory sufficiency.

8. What YPAI is accountable for

YPAI supports compliance through documented data governance, evaluation evidence, delivery controls, subprocessor transparency and project records.

YPAI is accountable for performing the agreed work, recording the applicable evidence, communicating known limitations and reporting whether acceptance criteria were met.

9. Change, versioning and monitoring after deployment

Baselines, revisions, known limitations and change control are defined per engagement. Changes to data, models, prompts, workflows, integrations, evaluation criteria or operating conditions are recorded where they affect the agreed scope or the interpretation of results.

Regression testing compares the changed system or workflow against the agreed baseline. The test record identifies the version assessed, the criteria applied, material differences and any new or unresolved limitations.

Where monitoring after deployment is included, YPAI records the monitored behaviour, evaluation conditions, observed failures and agreed escalation path.

Material changes are handled through the engagement's change control process. Acceptance after a change is based on the criteria and evidence agreed for that revision.

10. Governance of this policy

This policy is reviewed according to YPAI's assigned review cadence and when material changes to services, evaluation methods, regulatory posture, subprocessors, residency controls or monitoring practices affect its content.

Questions about this policy are raised through the YPAI contact used for procurement, risk, security or the relevant engagement. YPAI records the question, provides a documented response and updates this policy where a change is required.