The OSBR Handbook
Sign in

AI Data-Handling

This is the highest-priority page of OSBR's AI operating model, and the one the Quality Gate's Security lens holds work to whenever a project uses AI. The AI Usage Guideline is the operating-model overview; this page is its load-bearing core. AI-assisted work is OSBR's default way of building — humans and AI agents together, not an exception a project opts into — and that default is only safe when one thing is settled before the first commit: a written, client-agreed, version-controlled record of which data classes may enter which AI providers, under what configuration. No developer, human or AI, should ever have to guess whether a given file, secret, or dataset is allowed into a given model. The record answers that in advance, for everyone. It builds on the Security Policy and the Data Protection standard, and — as everywhere in the handbook — deviations must be deliberate and justified in the project's design notes.

This is where OSBR's values become a boundary the machine can see. Be Kind: we protect a client's data — their code, their users' personal data, their secrets — as if it were our own, so it never leaks into a service that could learn from it or retain it. Be Strong: we do not rely on good intentions or a developer's memory in the moment; we draw the boundary of what the AI may see in writing, agreed with the client, before the first commit, and hold generation, review, and audit to that same standard. Be Nice: the record is documentation first — one document a new teammate opens to learn, without asking anyone, exactly what is permitted where. Cooperation between humans and AI is only trustworthy when that boundary is drawn deliberately and written down.

How to read this policy

1. Goal

The goal is that on any OSBR project a developer — human or AI agent — can open one document and see, without asking anyone: what data classes exist, which are permitted into which providers, under which data-handling configuration (no-training / minimal-retention / region-pinned), and which are prohibited outright. Concretely:

This is standard large-enterprise practice at OSBR's scale. A Data Processing Agreement (DPA) governs a processor's use of a controller's data (GDPR Art. 28); a data-classification scheme decides how each class may be handled; and an AI Acceptable Use Policy binds those two to the specific AI services in play. We adopt the same three instruments and right-size them into a single record.

2. Responsibility

Before a project starts, the AI Data-Handling Record MUST exist, be agreed with the client in writing, and be consultable by every developer on the project. It is a precondition of the first commit — the same gate class as the security onboarding in the Security Policy. A project that has not produced this record is not ready to write code.

The record is OSBR's project-level AI Acceptable Use Policy, and it sits inside (or is referenced by) the client DPA. It MUST state, per project:

  1. Data-classification tiers — every data class the project touches, sorted into named tiers (e.g. Public → Internal → Confidential → Restricted, the conventional 3–4 tier model behind ISO/IEC 27001 information classification). Personal data, secrets/credentials, and regulated data are called out explicitly.
  2. Permitted providers — which AI services are approved, named exactly, and for which tiers.
  3. Required configuration per provider — the data-handling posture each approved provider MUST run under: no-training / opt-out, zero or minimal retention, model/tenant isolation, and data residency / region. Each posture MUST cite the provider's current enterprise data-handling terms as the authoritative source, not memory.
  4. Prohibited data classes — the classes that MUST NOT enter any AI service under any configuration (secrets/credentials, and any Restricted-tier or regulated data the client has not cleared).

Accountability follows the GDPR processor model: the client is the data controller, OSBR is a processor, and any AI provider is a sub-processor. Under GDPR Art. 28 a processor MUST NOT engage a sub-processor without the controller's authorization and MUST bind it by contract to equivalent protection. The AI Data-Handling Record is that authorization, made explicit. Where client data falls under OSBR's home regime — Malaysia's Personal Data Protection Act 2010 (PDPA) — or another regime (e.g. Japan's APPI for cross-border transfer and third-party handling, or the EU's GDPR), the record MUST satisfy it too — see Data Protection.

Every developer is responsible for staying inside the record. If a task seems to need data or a provider the record does not permit, the answer is never to proceed and work around it — it is to stop and get the record amended and re-agreed with the client first.

3. Practices

3-1. The record itself — committed, version-controlled, plugin-expressed

3-2. Data classification — every class tiered before it touches a model

3-3. Provider configuration — no-training, minimal-retention, region-pinned

3-4. Vendor / sub-processor assurance

3-5. Governance — mapped risk, reviewed cadence

References

Data protection & processor obligations

AI governance & management standards

Vendor / sub-processor assurance

Provider enterprise data-handling terms

Related OSBR standards