ResponsibleAI-4C
Turn an AI use case into a repeatable risk tier, 4C assurance card, control plan, evidence checklist and review-ready framework draft.
Deterministic checksSynthetic data only Human approval requiredAssessment result
| Finding | 4C | Severity | What to do next |
|---|---|---|---|
| C1-GEN — Generative output failure modes have not been tested. | Correctness | High | Test unsupported claims, unsafe answers and known refusal conditions. |
| C3-KNOW — The approved knowledge set is 14 months old. | Currency | Medium | Refresh and reapprove the knowledge sources before expanding use. |
| C4-INC — AI incident and complaint handling is not defined. | Coverage | High | Create an AI incident route with containment, notification and learning steps. |
| Required control | Priority | Evidence expected |
|---|---|---|
| CTRL-GEN-01 — Generative AI output testing | High | Hallucination, unsafe-output and failure-mode test report |
| CTRL-KNOW-01 — Current approved knowledge | Planned | Knowledge inventory, source owner, version and refresh record |
| CTRL-INC-01 — AI incident and complaint response | High | Incident procedure, reporting channel and exercise record |
Source IDs below indicate the public guidance associated with a demo control; they are not a legal compliance determination.
- AU-GFAI-2026 — Australian Government — Guidance for AI Adoption (Department of Industry, Science and Resources)
- ISO-IEC-42001-2023 — ISO/IEC 42001:2023 — AI management systems (International Organization for Standardization)
- NIST-AI-RMF-1.0 — NIST AI Risk Management Framework 1.0 (US National Institute of Standards and Technology)
Draft Responsible AI Framework
Organisation profile
- Industry: Cross-sector
- Organisation size: Medium (50–999 staff)
- AI governance maturity: Emerging
- Demonstration use case: Customer service GenAI reply assistant (RAI-DEMO-001)
1. Purpose and scope
This draft sets a practical baseline for governing AI across its lifecycle. It applies to AI built internally, purchased from vendors, embedded in software, and used by staff. Every use must be registered and assessed in context.
2. Governance principles
- A person remains accountable for every AI use case.
- Risk controls are proportionate to impact, data sensitivity and automation.
- Material decisions require meaningful human oversight and a route to challenge or correct outcomes.
- Testing, monitoring and evidence continue after deployment.
- Affected people receive appropriate information about AI use.
- Privacy, security, fairness and accessibility are considered together.
3. Roles
- Board or executive: sets risk appetite and reviews material AI exposure.
- Responsible AI owner: maintains the framework, inventory and review cycle.
- Business owner: owns the purpose, benefit, risk and operational outcome of a use case.
- Technical owner: owns system design, testing, monitoring, security and change records.
- Independent reviewer: challenges high-risk assessments and approval conditions.
4. AI lifecycle
Discover → register → classify → assess impacts → implement controls → independently review → approve → monitor → respond to incidents → retire.
5. Risk classification and 4C assurance
Each use case is assessed for impact, automation, data sensitivity, affected groups and human oversight. The 4C review then checks Correctness, Consistency, Currency and Coverage. A green 4C display is not an automated approval.
6. Priority controls indicated by this assessment
- Generative AI output testing
- Current approved knowledge
- AI incident and complaint response
7. Human oversight
Human review must be meaningful: the reviewer needs authority, information, time and a usable override or escalation path. High-impact outputs must not be actioned automatically when required controls are missing.
8. Data, privacy and security
Use only authorised data for the approved purpose. Record data flows, minimise collection, apply access controls, assess privacy impacts and prohibit sensitive information from unapproved public AI tools.
9. Testing and monitoring
Define acceptance criteria before deployment. Test representative and affected groups, record limitations, monitor real outcomes and reassess after material changes, incidents or overdue review dates.
10. Vendors and supply chain
Assess vendor data use, security, model or service changes, subcontractors, exit arrangements and the evidence available to the organisation. Vendor claims do not replace internal accountability.
11. Incident response
Provide a reporting channel, containment authority, affected-person response, investigation record, corrective actions and escalation thresholds. Feed lessons back into controls and staff training.
12. Approval and review
- Current demo recommendation: Hold or approve only with conditions
- Required route: Senior business owner plus Responsible AI/risk reviewer
- Condition: Close high-severity gaps and record signed approval conditions.
- Review at least annually and earlier after material changes, complaints, failures or new obligations.
13. Records
Retain the use case profile, risk assessment, 4C findings, control evidence, reviewer comments, approval conditions, monitoring results, incidents and retirement decision.
Draft for discussion only. It is not legal advice, certification, an audit opinion or formal approval. Adapt it to applicable law, regulation, contracts and internal policy, then obtain qualified review.
| rai4c_13r7qwqy .md | 6.7 KB ⇣ |
A practical review sequence
- Register the use case. Describe the real purpose, users, data, impact and deployment state.
- Check the risk triggers. Correct any facts the tool inferred from the selected demo.
- Review every 4C finding. A finding is a prompt for evidence and professional judgement, not proof of non-compliance.
- Assign controls and owners. Record what must change, who owns it and what evidence will show completion.
- Use the approval route. High-impact cases need independent review; critical gaps block approval in this demo.
- Keep monitoring. Reassess after material changes, incidents, complaints, overdue reviews or new obligations.
4C meaning
- Correctness: Is the system tested and are its outputs sufficiently reliable for the intended use?
- Consistency: Does the real workflow match policy, accountability and human-oversight requirements?
- Currency: Are the system review, knowledge and vendor checks still current?
- Coverage: Are privacy, fairness, monitoring, incidents, training and affected groups adequately covered?
One-page case note
What problem does it solve?
Organisations often have AI principles but no consistent way to turn an individual AI use into a risk decision, control list and evidence request. ResponsibleAI-4C provides a quick, repeatable first review.
Who is it for?
Business owners, risk and compliance teams, internal auditors, AI/data teams, procurement staff and executives who need to discuss AI governance in practical language.
What goes in?
A structured description of one AI use case: its purpose, impact, data, affected users, human oversight, testing, monitoring and existing governance evidence. This public demo contains synthetic examples only.
What comes out?
An illustrative risk tier, a Correctness–Consistency–Currency–Coverage card, prioritised gaps, required controls, evidence expectations, an approval route and a draft Responsible AI framework section.
What are the safety boundaries?
- It does not make a legal or regulatory determination.
- It does not certify ISO/IEC 42001 compliance or provide an audit opinion.
- It must not be used to automatically approve, reject or deploy an AI system.
- All inputs and outputs require review by suitably qualified people.
- Do not upload confidential, personal or sensitive information to the public demo.
- High-impact cases should be assessed against applicable laws, regulations and internal policy.
Public versus commercial scope
This Space demonstrates the user experience and a deliberately small, illustrative ruleset. The commercial platform adds private organisational knowledge, richer evidence handling, controlled review workflows, enterprise integrations and ongoing assurance capabilities.
Assessment engine: public-demo-0.1.0
LLM dependency: none — risk and 4C outcomes are deterministic.