AI Policy

This page sets out the baseline commitments that apply when Syndicai uses AI in our own work and in systems we deliver. It is intended to support buyer, procurement, privacy, and security review.

Engagement-specific details — including approved data categories, providers, processing locations, retention periods, and any permitted exceptions — are recorded in the relevant contract, DPA, or technical schedule. Stricter engagement terms take precedence. Any departure from this baseline must be identified expressly in writing; it is not implied by a general permission to use AI.

1. AI in our own work

We use AI-assisted tools in engineering, research, and internal document work. These tools support people; they do not replace responsibility for the result.

AI-assisted code is reviewed, tested, and owned by a person before it is merged or shipped. Research and written material are checked against their sources before publication. Nothing on this site or in a delivered system is published solely on the authority of a model output.

Client data may be used in an internal AI-assisted workflow only when that workflow is approved for the engagement and the relevant data categories, purpose, provider, location, and retention settings have been documented. Credentials, private keys, authentication tokens, and other operational secrets must not be entered into AI tools.

People who design, review, or operate AI-assisted workflows receive guidance appropriate to their role, including the limits of model output, secure data handling, and when to stop or escalate a process.

2. AI in systems we build

AI has to earn its place. Most of what we deliver is ordinary, deterministic software. We use AI where it provides a measurable benefit, commonly in data preparation, document extraction, classification, summarisation, and search. We keep it out of calculations and rules that must be exact.

We distinguish between systems that:

• read or classify information;
• draft or recommend an output;
• prepare a reversible change for approval; and
• execute an action in another system.

The permitted level of autonomy is documented for each AI touchpoint. Consequential or irreversible actions are not executed solely on the basis of model output unless the engagement expressly defines the action, safeguards, approval path, and recovery procedure.

In quoting systems, a model may propose data — for example, extract a price book, suggest a mapping, or draft a summary — but it is not the system of record and does not perform the final calculation of a live price, discount, tax, or compatibility rule. Prices come from a versioned catalogue through deterministic code.

An AI-proposed value that can affect a live quote must be traceable to its source and pass the documented validation and approval process before it is published. Deterministic calculation does not by itself make an AI-derived input correct, so input quality is tested and monitored separately. The architecture is described in Where an AI quoting system gets its prices.

3. Client data and model use

For this policy, client data includes production and non-production data, documents, prompts, outputs, metadata, and datasets derived from them. Test or sample data remains client data if it contains, reproduces, or can be linked to client information.

We process client data only for the documented purpose of the engagement. We do not use it to build products for other clients, create shared datasets, or improve our own or a provider's general-purpose models unless the client has given a separate, explicit, purpose-specific written instruction.

In current engagements, we do not train or fine-tune models on client data. We use existing models and, where appropriate, ground requests in client-controlled information at request time. Runtime processing is still processing: data included in prompts, retrieved context, outputs, caches, evaluations, and logs remains subject to the same contractual and security controls.

Before an external AI service receives data, we minimise the fields and context sent to what the task requires. Trade secrets, pricing strategy, personal data, HR data, and other confidential fields are not sent to an external AI service in clear form unless the engagement expressly identifies the data category, provider, purpose, and safeguards.

Where identifiers are replaced before an external call and restored afterwards, we describe the process as tokenisation or pseudonymisation, not anonymisation. Pseudonymised information remains protected as client data and, where applicable, personal data. We use the term anonymised only where the information cannot reasonably be linked back to a person or client record.

4. Processing location and international access

Client systems run in EU regions by default, or on the client's own infrastructure where the engagement requires it.

For each engagement, the written processing description covers not only primary storage, but also model inference, caches, logs, monitoring, backups, support access, subprocessors, and disaster recovery where those functions may process client data.

Client data is not made available for processing or support access outside the locations agreed for the engagement without the client's prior written agreement and, where personal data is involved, the required transfer mechanism and safeguards. Hosting data in an EU region does not by itself authorise access from another jurisdiction.

The agreed hosting, export, and deletion arrangements are documented per engagement, alongside the deletion and export path.

5. Model providers and the AI supply chain

We select models and providers per engagement according to the task, data involved, security requirements, and client constraints. Providers we work with include Anthropic, OpenAI, and Mistral. We also deploy open-weight or open-source models in controlled environments where the engagement requires data to remain within client-controlled infrastructure.

The AI service register for a delivered system identifies, as applicable:

• the provider and service;
• the model or model family and the versioning approach;
• the purpose for which it is used;
• the data categories it may receive;
• processing and storage locations;
• retention and prompt-caching settings; and
• relevant subprocessors or externally managed supporting services.

We use external AI services for client data only under terms that prohibit the provider from using client inputs and outputs to train its models, unless the client has given the separate, explicit instruction described in Section 3. Where the service provides additional technical controls, we configure them consistently with those terms. Retention settings and available abuse-monitoring controls are recorded for the engagement.

Material provider or model changes go through change control and relevant testing before release. The client is informed in advance where a change alters an agreed provider, processing location, data use, security control, or material system behaviour.

6. Verification and effective human oversight

Every AI touchpoint in a delivered system is documented with its purpose, inputs, outputs, provider or deployment environment, permitted actions, reasonably foreseeable failure modes, and the controls applied to it.

AI-proposed data is classified before publication as:

• supported and ready for the normal approval path;
• uncertain and requiring confirmation; or
• missing or rejected.

Where human approval is required, the reviewer must have access to the relevant source or evidence, sufficient context to understand the recommendation, authority to reject or stop the process, and an escalation path. Review design and workload must allow meaningful checking rather than routine confirmation.

Model-dependent behaviour is tested before release and after material changes. Testing uses a versioned reference set together with newly sampled and risk-focused cases. Depending on the system, this includes extraction accuracy, unsupported output, unsafe tool use, prompt injection, access control, and failures at system boundaries.

Production monitoring is proportionate to the impact of the AI touchpoint. Material failures are investigated, affected outputs can be traced, and versioned publishes can be rolled back. The publication process is described in Who updates the price list.

7. Logs, retention, and incidents

AI processing logs are collected only to the extent needed for traceability, security, operation, and agreed evaluation. Because prompts and outputs may themselves contain confidential or personal data, logs receive appropriate access controls, redaction, retention limits, and deletion procedures.

The engagement documentation states what is logged, who can access it, how long it is retained, and what the client can inspect or export. The client has access to the audit information needed to understand processing performed in its system, subject to proportionate protection of security-sensitive information and the rights of others.

Suspected AI-related security incidents, unauthorised data exposure, and material systematic output failures are handled through the engagement's incident process, including client notification where contract or law requires it.

8. Transparency to users

Users are informed when they are directly interacting with an AI system or when disclosure of AI-generated or AI-assisted content is required by the context, contract, or applicable law.

User-facing documentation describes the purpose and material limitations of AI-assisted features, the role of human review, and how a user can report a problem or request correction where relevant.

9. Review and exceptions

This policy is reviewed at least annually and whenever our practice, provider chain, or applicable obligations change materially. The date above moves when the published policy changes.

Exceptions must be specific, documented, approved by an authorised person, limited to the relevant engagement and purpose, and accompanied by appropriate safeguards and an expiry or review date.

Questions

Procurement questionnaires, DPAs, AI schedules, and security reviews are part of normal engagements. Send them to contact@syndicai.co.