Responsible AI framework

Responsible AI fails when it stays a values statement. Fairness, transparency, and accountability are outcomes. They do not tell an engineer what to put in front of a model call on Tuesday. A framework that works is a short set of controls, mapped to risk, that you can show an auditor and a developer without translating.

This is the practical cut. It is the same work as AI governance done as engineering: a secure AI gateway (logging, PII redaction, cost controls), a living model inventory (owner, data, risk tier, last eval), risk-tiering, and a light map to the NIST AI Risk Management Framework. Discover what is running. Risk-tier it. Implement guardrails in your environment. Operationalize so the controls still hold next quarter.

If you want the pass/fail list, use the AI governance checklist. If you want the company shape, use the enterprise AI governance framework. This post is the responsible-AI layer: which controls produce the outcomes the ethics deck already promised.

Name systems, owners, and data before you write principles

You cannot be accountable for a model you have not listed. The first responsible-AI artifact is a living inventory, not a principle. Every production model, agent, embedded copilot, and vendor feature that calls a model gets a row.

Each row needs:

• Purpose and environment (dev, staging, prod).
• A person who can stop it, not a department.
• Data class it may see, and whether output is customer-facing.
• Risk tier, assigned with a written rubric.
• Last eval result and last review date.

Yes/no:

• Someone can produce the list in a day without pinging five teams.
• Shadow tools found this quarter are on the list or explicitly closed. See shadow AI.
• Retired systems stay marked retired so an auditor can see history.

This is GOVERN and MAP in NIST AI RMF. Principles without a register are a speech. The register is what you update when a vendor turns on a summarize button inside software you already bought.

Risk-tier use cases so controls stay proportionate

A single "responsible AI review" for every idea is how low-risk work waits months and high-risk work sneaks out a side door. Three tiers are enough for most companies.

• Low: internal draft, public or non-sensitive input, a human reads the output, no write-back.
• Medium: confidential business data, internal decision support, a human still signs.
• High: customer-facing, restricted data (PII, health, payment, credentials), or any write into a system of record.

The rubric should use data class, audience, blast radius, and write permission — not "how visible the sponsor is." Changing a tier is a recorded decision by the owner plus security.

Yes/no:

• Every inventory row has a tier.
• Low-risk work has a path measured in days: approved tool, logged, owner named.
• High-risk work cannot use a personal chatbot or an unlogged API key.
• "Responsible" is not a fourth tier that bypasses the rubric.

Proportion is the difference between a freeze and a paved road. If everything is high, people will route around you. If nothing is high, you will learn it on a customer file.

Enforce the rules on the request, not in a PDF

Transparency and data protection are gateway properties. A secure AI gateway is the governed entry point for LLM usage: logging, PII redaction, cost controls, and allow/deny applied on the request.

What "enforced" looks like:

• Sanctioned prompts and completions pass through a path you operate or contractually control.
• Restricted data is redacted or blocked before it leaves your tenancy.
• Approved tools and data classes are the same list employees can find and the same list the gateway applies.
• Cost and rate limits turn a runaway agent into an operations event.

Yes/no:

• Security can reconstruct last week's traffic for a named service.
• A policy change (new banned pattern, new data class) can be deployed without rewriting every app.
• Personal accounts of otherwise-approved products are out of band. The contract does not cover them.

A responsible-AI policy that lives only in Confluence will not see the paste. MEASURE requires a log. If you cannot see the prompt, you cannot claim you controlled it.

Eval and human review are how you show the system is fit for use

"We care about fairness and accuracy" is not evidence. Evidence is a held-out set, a pass bar, and a human who can stop a write. Fit-for-use is specific: the cases look like your documents, your languages, your failure modes, and the groups of people the system will actually affect.

Build eval as a product artifact:

• Cases for stale policy, conflicting sources, prompt injection, PII in the input, and the decisions you care about getting wrong.
• A bar that blocks promote for high-risk systems.
• A re-run when the prompt, model, or retrieval source changes.
• A note on who the system will affect, and at least a few cases that represent those people, not only happy-path staff examples.

Human-in-the-loop:

• High-risk write-backs wait for an explicit approve, logged with the proposed change.
• Medium-risk outputs that people will trust (a recommended denial, a triage code) have a named signer.
• Low-risk drafts can skip the queue. Do not staff a review that nobody will use.

Yes/no:

• The last promote has an eval record on the inventory row.
• You can show a rejected write-back. If you cannot, the loop is decorative.
• A known failure was added to the set after an incident or a drill.

This is MEASURE feeding MANAGE. It is also how you answer "why did it say that" without a philosophy seminar.

Put an incident path and a review cadence on the calendar

Accountability is who gets paged and what they shut off. It is not a committee name on a slide. Write two paths: the model was wrong, and data left the tenancy. They have different severity and different comms.

Incident path, minimum:

• Who is paged, what gets disabled (write-backs first), who talks to a customer or regulator.
• How you pull logs and the inventory row in the first hour.
• A post-incident note that updates eval and, if needed, the tier.

Review cadence, minimum:

• Monthly for high-risk rows, quarterly for the rest, is a workable default.
• The meeting uses the inventory, not a strategy deck.
• Outcomes are keep, restrict, or retire, written back to the row.
• Training is the allow/deny list and two examples (low-risk draft vs customer file).

Yes/no:

• A drill has used the path. A handbook-only path is a wish.
• No-shows have a deputy. The review happens anyway.
• New vendor AI features are a discover input, not a surprise in a customer complaint.

Operationalize is the word for this. Responsible AI that ends when the first project ends was never a framework.

Map the same controls to NIST instead of writing a second binder

You do not need a 40-page crosswalk to start. You need to know which artifact satisfies which function so legal and security are not inventing a parallel program.

Light map:

• GOVERN: owners, approved tools, data classes, cadence, who can stop a system.
• MAP: inventory, intended use, data class, risk tier, who is affected.
• MEASURE: gateway logs, eval records, cost and policy violations, drift checks.
• MANAGE: human-in-the-loop, incident path, rollback, restrict or retire decisions.

Keep the map short. When a regulator or a customer asks, you hand them the inventory, the tier rubric, an eval record, and a log sample — not a new essay about responsibility.

If those artifacts exist in your environment, you have a responsible AI framework you can operate. If they exist only as principles, you have homework. The implementation path is the same one we use in delivery: discover, risk-tier, implement guardrails, operationalize.

See the AI governance page for what that looks like as a gateway, an inventory, and NIST-mapped deliverables — not as a slide about values.