Responsible-AI Architecture Gates for the ARB

Tier: Core · Hands-on time: ~30 minutes

The framework layer has matured into reviewable form: AWS shipped a Responsible AI Lens at re:Invent 2025, joining NIST AI RMF and ISO 42001 as the corpus that phase-1 research shows now appearing in architect job descriptions as required mapping knowledge. The boundary discipline matters here — security depth belongs to the security function and org-wide policy to governance — while the architect owns exactly what this playbook produces: the gate design, meaning the questions every AI system answers at the ARB, the evidence each answer requires, and the risk classification that decides how hard the gate presses.

When to use

• The ARB is seeing AI systems and reviewing them with pre-AI checklists that miss model risk entirely.
• A responsible-AI policy exists as prose and needs translation into per-review, per-design mechanics.
• A client or regulator asks how AI risk is governed at design time and the answer needs to be a process with artifacts.
• Skip AI when the org has no ARB or review forum — build the basic review practice first; a responsible-AI gate needs a gate to attach to.

Prerequisites

• The source frameworks at hand: NIST AI RMF (its govern/map/measure/manage structure), an ISO 42001 overview, and the AWS Responsible AI Lens — as the question quarry, not as documents to reproduce.
• The ARB's existing process and templatesthe gate extends what exists; a parallel process will be bypassed.
• Two or three recent AI designs (a RAG copilot, an agent) to pilot the checklist against.
• A chat assistant for checklist drafting and question pruning.

The workflow

1. 1.

   Design the risk classification first — it sets gate pressure. A workable scheme: Class 1 — internal, advisory, human-in-the-loop by construction (drafting aids, internal search); light gate. Class 2 — customer-facing or decision-influencing (support copilots, recommendation surfaces); full gate. Class 3 — consequential-action systems (agents with write access per pb-38, anything touching credit, employment, health); full gate plus named senior sign-off and mandated oversight design. Classification happens at intake, on a one-page questionnaire, and the class — not reviewer mood — determines everything downstream.

2. 2.

   Quarry the frameworks into architecture-answerable questions. Vikram, building his ARB's gate:

   Copy

   Draft an ARB responsible-AI checklist by translating framework
   intent into questions an architect can answer with design evidence.
   
   Sources to draw from: NIST AI RMF core functions, ISO 42001 management-
   system themes, AWS Responsible AI Lens focus areas. Do not quote or
   reproduce the frameworks — write original questions in our house style.
   
   Rules: every question must be answerable with a design artifact
   (diagram, ADR, eval report, test record) — no yes/no self-attestation.
   Group by: model risk & classification evidence; data provenance &
   consent (link to our DPDP data-flow standard); human-oversight points
   (where a human can inspect, override, halt); evaluation evidence
   (pre-deploy and in-production); incident & rollback readiness;
   documentation duties (what must exist before launch).
   Mark each question Class 1/2/3 applicability. Max 25 questions —
   prune ruthlessly; a 60-item checklist gets rubber-stamped.
   

   Then prune again by hand: every surviving question must have failed at least one imaginable real design, or it is ceremony.

3. 3.

   Attach evidence requirements to every question. "Where are the human-oversight points?" is answered by the pb-38 approval-tier table; "what evaluation evidence exists?" by pb-33/pb-46 reports with numbers; "what is the rollback path?" by a tested procedure reference, not intent. The gate reviews artifacts this track already teaches architects to produce — that alignment is what makes it runnable rather than aspirational.

4. 4.

   Design the oversight points as architecture, not aspiration. For Class 2+ systems, the checklist demands named, drawn oversight mechanisms: where a human can inspect model behavior (sampled review queues), where they can override (pb-38's Tier C gates), and where they can halt (kill switches with tested timings). "A human reviews outputs" without a queue, an owner, and a capacity number fails the gate.

5. 5.

   Wire incident and rollback readiness into the gate. Every reviewed system names its rollback unit (model version, prompt version, feature flag to the pb-45 static rung), the trigger conditions, and evidence the path was exercised. AI incidents are architecture-shaped — a bad model update rolls back like a bad deploy only if someone designed it to.

6. 6.

   Pilot on real designs before mandating. Run the two or three pilot designs through the draft gate; measure review time, count questions that produced no signal, and collect architect friction honestly. Cut and reword accordingly. A gate that adds three weeks to every review will be routed around, and a routed-around gate is worse than none — it produces compliance theater plus resentment.

7. 7.

   Ship the gate kit and its maintenance loop. Intake classification questionnaire, the per-class checklists with evidence requirements, reviewer guidance (what good evidence looks like per question), and the revisit machinery: framework updates (the lens corpus moved twice in 2025 alone), incident learnings feeding new questions, and a question-retirement rule for items that stop producing signal.

Verify before you trust it

• Framework translations are checked against the sources. Sample the drafted questions against the actual NIST AI RMF and lens documents to confirm the intent survived translation — AI-drafted "framework-based" checklists drift into generic best-practice mush, and citing a framework you've misrepresented is worse than citing none.
• Every question is evidence-answerable in practice. In the pilot, confirm each question was answered with an artifact that exists in your delivery process; questions requiring artifacts nobody produces get the artifact added to the process or the question cut.
• The classification scheme is calibrated on real systems. Classify five existing systems and check the results against senior judgment — if the questionnaire puts a credit-decision agent in Class 1, fix the questionnaire before it ships.
• Gate outcomes are recorded and auditable. Verify the review record captures class, evidence reviewed, findings, conditions, and sign-off — the gate's own audit trail is what a regulator or client assessment will ask for.
• The pilot's friction numbers are honest. Review time and rework cost from the pilot go in the rollout proposal as measured, not massaged — the gate's survival depends on leadership trusting its cost story.

Restricted-environment variant

The gate design itself is org-internal and safe to draft with any approved assistant — the frameworks are public and no client data is involved. Client dimensions appear in two places: consulting engagements may need a client-specific overlay (their risk classes, their regulators, their sign-off chain) applied over the house gate, extracted from their governance requirements at engagement start; and gate reviews of client-facing systems handle client design artifacts under MSA rules — review inside client-approved tooling where required. For fully offline drafting, a local Ollama-served model plus the downloaded framework documents produces a workable first draft; the pruning, calibration, and pilot — where all the real quality comes from — never needed an external service anyway.