AI usage policy

The single org-wide statement of what AI tools and agents may be used for, with what data, under what terms. Everything else — engineer guidance, commercial talking points, client answers — derives from this one document, so there is never a second, contradictory policy in circulation.

Draft — requires Legal, Security and Leadership sign-off before adoption

This is a drafted position for review. Nothing in it is authorised for external use, and no tool or data-handling decision should cite it as approved policy until Legal, Security and Leadership have signed.

Scope

• One policy — this page is the canonical source. It covers every use of AI models, agents and AI-assisted tools by anyone working under the RAPID model, in the UK and India, on company or client work.
• Per-audience one-pagers derive from it — an engineer's version, a commercial/client-facing version, a support version. Each is a condensation of this page, regenerated when this page changes, never independently edited.
• It binds tools, not just people — the agent guardrails are the technical enforcement of this policy; where the two could diverge, this policy wins and the guardrail config is fixed.

What agents and tools may do

• Build, test, refactor and document within the guardrail sandbox — repo-scoped filesystem access, allowlisted network, no production access.
• Analyse and summarise internal material (code, backlogs, docs) in approved tools.
• Support discovery and research on client problems — only with data prepared under the anonymisation rules below.
• Draft client-facing content — but a human reviews and sends; nothing AI-drafted leaves the company unreviewed (client transparency).

What agents and tools may not do

• Touch production or execute anything irreversible — a human authorises those, always (authorise the irreversible).
• Receive secrets — no credential, key or token in a prompt, context window or uploaded file (secrets management).
• Receive regulated personal data in raw form — see the matrix below; policyholder and claims data never enters a third-party model un-anonymised.
• Make decisions about individuals — no AI-driven underwriting, claims or personnel decisions; RAPID uses AI to build software, not to decide about people. Anything approaching automated decision-making triggers a DPIA (insurance data protection).
• Be used outside the approved list — no company or client material in personal/consumer AI accounts, ever.

Data classification matrix

Four tiers, three classes of destination. If a piece of data isn't classified, treat it as the highest tier it could plausibly be.

Data class	Examples	Approved vendors (no-training terms)	Local-only models	Unapproved / consumer tools
Public	published docs, marketing copy, open-source code	Allowed	Allowed	Not permitted — work happens in approved tools only
Internal	source code, backlogs, architecture docs, this handbook	Allowed	Allowed	Never
Client-confidential	client contracts and commercials, client system detail, unreleased product features	Allowed only where the client contract and DPA permit	Allowed	Never
Regulated PII	policyholder records, claims files (including health data), payment data, employee data	Never in raw form — anonymised or synthetic only, and only where a DPIA covers the processing	Case-by-case with DPO approval and a DPIA	Never

Approved-vendor rules

A vendor enters the approved list only through the tooling intake, and only if all of the following hold:

• No-training terms are mandatory — contractual commitment that our inputs and outputs are not used to train or improve the vendor's models. No exceptions, no "opt-out pending".
• A DPA is in place — a data-processing agreement covering UK GDPR processor obligations before any personal data (even anonymised-adjacent) flows.
• Residency is known and acceptable — where the vendor processes and stores data, and whether that is compatible with client contracts and the residency rules.
• The list is maintained, dated and short — an unlisted tool is an unapproved tool; "it's probably fine" is not a state.

Anonymisation for discovery and research

Using AI on client problems is encouraged — with prepared data:

• Anonymise, don't pseudonymise — under UK GDPR, pseudonymised data is still personal data. Names, policy numbers, claim references, addresses, dates of birth and free-text narrative must be removed or generalised so no individual is identifiable, including by combination.
• Prefer synthetic data — for structural work (schemas, MTAs, claims flows) synthetic records are usually as good and carry zero risk (see test data).
• Free text is the trap — claims notes and correspondence leak identity in prose; they are regulated-PII until proven otherwise.
• When in doubt, DPIA — if the research design needs data closer to real than this allows, that is a DPIA conversation, not a judgement call.

UK and India applicability

• One policy, both jurisdictions — UK GDPR governs UK-client personal data wherever it is processed; India's DPDP Act additionally applies to processing in India. The stricter rule wins wherever they differ.
• India delivery works to UK GDPR standards by default — because the data is predominantly UK policyholder data; DPDP compliance is then largely a by-product.
• Cross-border specifics (transfer mechanisms, access-vs-storage) live in the insurance data-protection standard.

Pending decisions before sign-off

Legal to confirm the approved-vendor contractual checklist against current vendor terms; Security to ratify the matrix against the guardrail config; Leadership to name the policy owner and review cadence. The per-audience one-pagers are produced only after sign-off.

Standards referenced: ISO/IEC 42001, NIST AI RMF, UK GDPR, India DPDP Act, EU AI Act.