Why the RICS framing matters
RICS responsible-use guidance is often read as a compliance checklist - tick the boxes and move on. It is not. It is a competence framework, and competence is what professional indemnity insurers, regulators and clients actually want evidence of when something goes adversarial.
The four pillars - data integrity, professional judgement, disclosure, accountability - map cleanly onto policies, workflow gates and audit trails. The work is in turning principle-level statements into the specific artefacts that survive review.
Pillar 1: Data integrity
Data integrity in practice means three things: known provenance for every input, classification of sensitivity at the point of upload, and a hard block on the highest-risk class reaching any AI service.
- Provenance: every uploaded file carries the source (client name, project ref, date), the uploader's role, and a checksum so later changes are detectable.
- Classification: Green / Amber / Red against published rules. Red includes personal data, security-sensitive data and regulated data - and it does not enter AI prompts under any circumstance in the MVP.
- Audit row per upload, per classification decision, per AI invocation - so the provenance chain reconstructs months later.
Pillar 2: Professional judgement
Professional judgement is what the regulated practitioner applies to AI output. The framework is simple in principle: AI assists drafting and classification; the practitioner exercises judgement and signs off; the deliverable carries the practitioner's name. It is harder to enforce than to state - so the workflow has to make the judgement step structurally unavoidable.
- QA1 + QA2 gates on every AI-assisted deliverable. QA1 is the drafter's peer; QA2 is a competent person not involved in the draft.
- Each gate writes an audit row - reviewer identity, time, outcome (accepted / amended / rejected), comments.
- Deliverable is locked at issue - the issued version is the version reviewed, not a later edit. Amendments after issue create a new revision row.
Pillar 3: Disclosure
Disclosure is where most AI rollouts fail in practice. Clients and regulators ask 'was this AI-assisted', and the honest answer needs to be on the deliverable, not retrofitted later. The bar is simple: every AI-assisted output discloses the use, names the human reviewer, and identifies the model class involved.
- Standard disclosure footer on AI-assisted deliverables - one line, plain English, present at issue.
- AI Schedule attached to the SOW - five canonical clauses naming definitions, permitted use, approved tools, human approval gate, AI output IP. Procurement reads it once at engagement start, not in the moment of crisis.
- Internal disclosure to the regulator on request - the audit log answers 'how was this AI used' with timestamps, classification and reviewer identities.
Pillar 4: Accountability
Accountability is what keeps the other three pillars honest under pressure. It means the named human is identified before, during and after the AI step - not retrofitted to the artefact when something goes wrong. RICS-aligned accountability is a chain, not a single point.
- Named uploader for every input.
- Named QA1 + QA2 reviewer for every AI-assisted output.
- Named approver for every issued deliverable.
- Named admin for any override (e.g. raising the liability cap, releasing a deliverable past a soft block) - the override creates an immutable AdminOverride row.
What this looks like in BuiltAI
The AI Governance Policy Pack ships a one-page policy aligned to all four pillars, an AI Schedule for the SOW, and the platform-level enforcement: classification at upload, QA1 + QA2 gates server-side, disclosure footer on every AI-assisted output, audit row per action. The pack does not interpret RICS for you - it gives you the artefacts a competent practitioner can defend in front of an auditor, an insurer or a client.