Prioritized Register of Technical, Organizational, and Responsible AI Risks

Good to see you again. In the previous lesson, you converted the authorization-aware cited evidence assistant into a testable value hypothesis: a defined unit of work, an expected reduction in evidence-preparation effort, and non-negotiable guardrails for citation quality and authorized access.

Those guardrails are not footnotes to the business case. They are conditions under which the expected value is allowed to exist. This lesson creates the working instrument for making those conditions visible: a prioritized risk register covering technical, organizational, and responsible-AI risks. By the end, you will have an initial register tailored to the capstone, with accountable owners, treatment actions, evidence gates, and a defensible rationale for priority.

---

A risk register is a decision tool, not a list of worries

A risk is an uncertain future event or condition that could affect an objective. An issue is something that has already happened and needs immediate resolution. Keep them separate:

• Risk: “A defect in authorization filtering could expose a source to a user without permission.”
• Issue: “Yesterday’s test exposed a restricted source to an unauthorized test account.”

The risk belongs in the register with preventive controls and a test plan. The issue belongs in an incident or defect tracker, while also prompting an update to the risk’s likelihood, controls, and status.

For this capstone, the objectives at risk are not only delivery schedule and cost. They include:

1. Business value: reduce effort for eligible evidence packs.
2. Decision quality: give analysts evidence they can verify, rather than plausible but unsupported prose.
3. Security and privacy: enforce enterprise authorization boundaries.
4. User trust and adoption: make the platform dependable enough to replace unsafe workarounds.
5. Governance: make responsibility, approval, and escalation paths explicit.

A useful risk statement has three parts:

Because a cause or vulnerability exists, an event may occur, leading to a stated impact.

For example:

Because document metadata may be incomplete or incorrectly classified, the retrieval layer may return a restricted document to an unauthorized user, leading to confidentiality harm, policy breach, and loss of trust.

This form prevents vague entries such as “security risk,” “hallucinations,” or “lack of adoption.” It gives the team something concrete to test, mitigate, monitor, and assign.

The NIST AI Risk Management Framework is useful here because it treats risk as a continuous socio-technical activity. Govern establishes accountability and risk tolerance. Map establishes the use context and identifies scenarios. Measure evaluates likelihood, impact, and control effectiveness. Manage prioritizes and treats the risks. These functions reinforce one another throughout the lifecycle rather than being a one-time checklist.

For the cited evidence assistant, governance begins with a practical risk-tolerance stance. The following draft stance should be reviewed with the stakeholders identified earlier, especially the executive sponsor, data owners, security, and AI-governance representatives:

• Do not accept: unauthorized disclosure of enterprise content; use of the assistant as an autonomous decision-maker; known material citation failures in a consequential workflow.
• Require mitigation before pilot: high-priority vulnerabilities, unclear access-control ownership, unmanaged sensitive-data flows, and absent escalation paths.
• May accept temporarily with explicit approval: limited availability degradation, lower-priority usability gaps, or a noncritical model-provider outage where a safe fallback exists.
• Must be monitored: adoption, citation quality, source freshness, operating cost, model-provider changes, and emergent misuse patterns.

The register does not itself decide what is acceptable. It records the assumptions and evidence needed for accountable leaders to decide.

---

Use three lenses without forcing risks into only one box

The outcome calls for technical, organizational, and responsible-AI risks. Treat these as complementary lenses, not mutually exclusive categories. A single scenario can be technical in cause, responsible-AI in impact, and organizational in its required control.

Technical risks

Technical risks concern the system’s components, integrations, data flows, dependencies, and operational behavior. For the capstone, likely areas include:

• authorization-filter failures in retrieval;
• incorrect metadata, stale indexes, or incomplete ingestion;
• indirect prompt injection embedded in retrieved documents;
• unavailable or changing model-provider APIs;
• latency, cost spikes, or capacity constraints;
• weak observability that makes failures difficult to detect or investigate.

Technical risks are not restricted to code defects. A third-party model, an embedding provider, a document connector, and a cloud logging configuration all form part of the system.

Organizational risks

Organizational risks arise from decisions, incentives, skills, ownership, and operational processes around the technology. They often determine whether an otherwise capable solution creates value.

For the evidence assistant, common examples are:

• no clearly authorized owner for approving a new source;
• analysts bypassing the platform because it is slower, less trusted, or poorly embedded in the workflow;
• unclear accountability when a cited answer is wrong;
• insufficient time from subject-matter experts to validate the pilot;
• delivery teams optimizing for a demo while operational teams inherit an unsupported service;
• Finance, product, and technology using incompatible definitions of realized value.

These risks cannot be solved solely with a model setting or an API gateway. They require decision rights, training, operating routines, and leadership follow-through.

Responsible-AI risks

Responsible-AI risks concern potential negative effects of the system and its use, including impacts on users, affected groups, organizational trust, and legal or policy obligations. NIST frames these through trustworthiness characteristics: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair with harmful bias managed.

For this bounded internal use case, the most immediate responsible-AI concerns are:

• Validity and reliability: the assistant makes a materially incorrect claim, omits key evidence, or attaches a citation that does not support the claim.
• Privacy and security: a user’s query, retrieved passage, or output exposes sensitive information to an unauthorized party or external provider.
• Transparency and accountability: users cannot tell that content is AI-generated, cannot inspect the cited evidence, or do not know who is responsible for resolving errors.
• Fairness and inclusiveness: source coverage, language assumptions, or interface design systematically make the assistant less useful to particular internal groups.
• Human oversight: analysts over-rely on polished output and stop applying appropriate judgment.

The capstone does not make personnel, credit, medical, or legal determinations. That lowers the severity of some possible harms, but does not remove the need to assess privacy, misleading output, and unequal access to useful decision support.

---

Score risks consistently, then use judgment to set priority

A score is a decision aid, not a claim of mathematical precision. Early in a project, a simple qualitative scale is more honest and useful than invented probabilities.

Use a five-point scale for likelihood and impact.

Rating	Likelihood	Impact on the capstone
1	Rare under expected use	Negligible disruption; simple local correction
2	Unlikely, but credible	Minor rework or contained user inconvenience
3	Possible during pilot or normal operation	Material rework, limited service disruption, or measurable trust loss
4	Likely without effective controls	Major workflow, security, financial, or adoption impact
5	Expected or already observed in comparable conditions	Severe confidentiality, compliance, decision-quality, or reputational harm

For each risk, estimate its inherent risk before proposed controls are proven effective:

$$\text{Inherent score}=\text{Likelihood}\times \text{Impact}$$

A practical initial interpretation is:

Score	Initial treatment posture
15–25	Critical: escalation and treatment before pilot or release
8–14	High: named owner, dated mitigation, and regular review
4–7	Moderate: manage through planned controls and monitoring
1–3	Low: record and periodically reassess

However, do not let the arithmetic overrule risk tolerance. A low-likelihood privacy breach with an impact of 5 can remain a release blocker. Similarly, an adoption risk may have no compliance consequence but still invalidate the prior value hypothesis if the platform is never used.

The impact-likelihood matrix below illustrates the key insight: risks in the high-impact/likely quadrant deserve urgent treatment, but high-impact/unlikely scenarios still need deliberate controls and contingency planning.

After controls are implemented and evidenced, reassess the residual risk: the risk that remains in real operation. Do not record a hoped-for residual score as if it were proven. Label it a target residual score until test results, monitoring evidence, or an independent review supports it.

A high-quality prioritization discussion also considers:

• Velocity: how quickly harm could occur after a trigger;
• Detectability: whether the team can notice the problem before it causes harm;
• Control maturity: whether a control is designed, implemented, tested, and monitored;
• Uncertainty: what is not yet known because the system has not been piloted;
• Risk appetite: whether an impact category is unacceptable regardless of score.

---

Build a register that can be operated

A register that is too elaborate will be abandoned; one that has only a title and score cannot guide action. Use the following fields for the initial capstone version.

Field	Purpose
Risk ID and title	Creates a stable reference, such as R-01: Authorization-filter failure. Never reuse retired IDs.
Risk statement	Captures cause, event, and impact in complete language.
Primary category and tags	Classify as technical, organizational, responsible-AI, or multiple; add trustworthiness tags such as privacy or validity.
Affected objective and stakeholders	Shows what is threatened and who needs to be involved.
Inherent likelihood and impact	Records the pre-control assessment and rationale.
Priority	States the action urgency after considering score, risk tolerance, and velocity.
Treatment	Usually mitigate, avoid, transfer, or accept. State the selected action rather than merely naming the risk.
Controls and evidence gate	Specifies what must exist and how the team will prove it works.
Owner	One accountable person or role with authority to coordinate treatment.
Target residual risk	Makes the desired post-control state explicit without treating it as already achieved.
Trigger, status, and review date	Keeps the register alive as conditions change.
Acceptance authority	Identifies who can formally accept a residual risk, especially for high-impact items.

A focused identification method

Create the first register in a cross-functional working session with the product owner, technical lead, security representative, data owner, and an analyst who performs the current workflow. Use the stakeholder map from the earlier lesson to invite people who can surface risks that the delivery team would otherwise miss.

Work through five prompts:

1. Failure: identify what can fail in retrieval, authorization, generation, integrations, monitoring, and support.
2. Misuse: identify how an authorized user, malicious actor, or untrusted document could cause the system to behave outside its intended scope.
3. Change: identify what could change in documents, policies, models, vendors, volumes, or organizational priorities.
4. Human and process: identify ambiguous decisions, missing skills, incentives to bypass controls, and weak handoffs.
5. Impact: identify who could be harmed or disadvantaged, what information could be exposed, and what trustworthiness characteristic would fail.

Record every plausible risk first. Consolidate only when two entries have the same cause, event, impact, owner, and treatment. For example, stale content and unsupported citations may be related, but they need different controls and should normally remain distinct.

---

Initial prioritized register for the cited evidence assistant

The following is a draft register for the MVP. The scores are planning assumptions, not measured facts. Replace them through stakeholder calibration, technical testing, and pilot evidence.

Priority	Risk	Category and trustworthiness tags	Inherent $L\times I$	Treatment, control, and evidence gate	Accountable owner	Target residual
P0	R-01: Authorization-filter failure. Incorrect document metadata or retrieval logic could return content outside a user’s permissions, leading to unauthorized disclosure.	Technical; responsible AI: privacy, security, accountability	$3\times 5=15$	Mitigate. Enforce authorization server-side before content enters the model context; default to deny; test a role-resource access matrix; retain access audit records. Pilot gate: no critical authorization failures in agreed adversarial and regression tests.	Security/IAM lead	$1\times 5=5$
P0	R-02: Indirect prompt injection. A retrieved document could contain hostile instructions that influence system behavior or output, leading to misleading answers or an attempt to exceed the assistant’s intended scope.	Technical; responsible AI: security, reliability	$4\times 4=16$	Mitigate and constrain scope. Treat retrieved content as data rather than instructions; isolate system instructions; test adversarial documents; prohibit tool execution in this MVP. Pilot gate: agreed injection test suite meets pass criteria.	RAG technical lead	$2\times 4=8$
P0	R-03: Unsupported or misleading cited answer. Weak retrieval or generation may produce a plausible statement with irrelevant, incomplete, or incorrect citations, leading to poor analyst decisions and loss of trust.	Responsible AI; validity, reliability, transparency, human oversight	$4\times 4=16$	Mitigate. Require source-linked answers; test citation correctness and completeness on a representative evaluation set; enable abstention when evidence is insufficient; retain human review. Pilot gate: citation-quality threshold is met for defined request types.	AI product lead	$2\times 4=8$
P0	R-04: Sensitive data leakage through prompts, logs, or provider handling. Sensitive query content or retrieved passages may be retained or viewed beyond approved boundaries, leading to privacy or contractual breach.	Technical and responsible AI; privacy, security	$3\times 5=15$	Mitigate. Classify data flows; minimize prompt content; configure retention and access controls; review provider terms and approved regions; redact sensitive fields from logs where appropriate. Pilot gate: privacy and security approval of documented data flows.	Data protection owner	$1\times 5=5$
P1	R-05: Stale, incomplete, or wrongly classified sources. Ingestion delays, missing documents, or weak provenance could cause the assistant to use outdated evidence, leading to inaccurate briefs and rework.	Technical; responsible AI: validity, transparency	$4\times 3=12$	Mitigate. Store source provenance, timestamps, classification, and owner; define freshness expectations; monitor ingestion failures; visibly show source dates. Pilot gate: source inventory and freshness checks are operating for approved repositories.	Enterprise data owner	$2\times 3=6$
P1	R-06: Unclear source-approval and escalation rights. If no role owns source onboarding, policy interpretation, or error escalation, unauthorized scope expansion or prolonged remediation may occur.	Organizational; accountability, governance	$4\times 3=12$	Mitigate. Document decision rights for source approval, access policy, model changes, and incident escalation. Pilot gate: named owners accept the operating procedure.	Product owner	$2\times 3=6$
P1	R-07: Low adoption or unsafe workflow bypass. If analysts find answers unreliable, slow, or difficult to validate, they may avoid the platform or use unapproved alternatives, preventing value realization and increasing data risk.	Organizational; reliability, transparency	$4\times 3=12$	Mitigate. Pilot with real eligible requests; provide onboarding and feedback loops; measure usefulness, rework, and adoption; refine supported request types. Pilot gate: adoption and usefulness meet the agreed threshold without increased rework.	Change/adoption lead	$3\times 3=9$
P1	R-08: Third-party model dependency disruption. A model provider may experience an outage, price increase, API change, or unexpected behavior shift, leading to degraded service or unplanned cost.	Technical and organizational; resilience, third-party governance	$3\times 4=12$	Mitigate. Define timeouts, usage limits, version monitoring, cost alerts, fallback behavior, and an incident communication plan. Pilot gate: controlled dependency-failure test and documented fallback.	Platform engineering lead	$2\times 4=8$
P2	R-09: Unequal usefulness or accessibility. Source coverage, language assumptions, or interface design may make the platform less useful for some employee groups, leading to uneven access to decision support and reduced trust.	Responsible AI; fairness, inclusiveness, accessibility	$3\times 3=9$	Mitigate. Include representative users and request types in evaluation; assess accessibility and source coverage; collect segmented feedback; prioritize material gaps. Pilot gate: documented evaluation findings and remediation plan.	Product and UX lead	$2\times 3=6$

Several design choices now become visibly connected to risk treatment:

• Citations are not merely a user-experience feature; they are a control for validity, transparency, and analyst oversight.
• Authorization-filtered retrieval is not merely an architecture preference; it is the principal control for a non-negotiable confidentiality risk.
• A bounded MVP without tool execution reduces the consequence of prompt injection while the team develops more mature agent controls later in the course.
• Named source owners are not bureaucracy; they are necessary to keep retrieved evidence current, governed, and accountable.
• Adoption measurement protects the value hypothesis from becoming an untested claim.

---

Operate the register as the platform changes

The initial register is a starting point, not a release approval artifact. Review it at a regular cadence:

Moment	What to update
Weekly during pilot preparation	Treatment progress, evidence gates, new risks, changed assumptions, and overdue actions
Before onboarding a new source	Access implications, content sensitivity, provenance, freshness ownership, and source-specific risks
Before a model or prompt change	Evaluation results, performance changes, cost implications, and new failure modes
After an incident or near miss	Root cause, likelihood reassessment, control effectiveness, recovery actions, and stakeholder communication
At the pilot decision gate	Residual risks, unresolved P0/P1 actions, pilot metrics, and the scale, revise, pause, or stop recommendation

A risk may be closed only when the underlying condition is no longer relevant or an implemented control has reduced it to an accepted residual level. “Closed because we discussed it” is not a valid status.

The executive sponsor or designated risk authority should explicitly accept any remaining risk that exceeds normal team authority. Engineering can implement a control, but should not independently decide that a major privacy, legal, or organizational risk is acceptable.

---

Key takeaways

A prioritized risk register makes the capstone’s value hypothesis governable.

• Write each risk as a causal scenario: cause, uncertain event, and impact.
• Use technical, organizational, and responsible-AI lenses together; important risks commonly span more than one.
• Score inherent likelihood and impact simply, but let risk tolerance and severity override false precision.
• Distinguish inherent, target residual, and evidenced residual risk.
• Give every high-priority item a treatment, an accountable owner, a measurable evidence gate, and a review date.
• Treat unauthorized disclosure, misleading cited answers, prompt injection, privacy leakage, source freshness, adoption, and third-party dependency as first-class risks for this evidence assistant.
• Keep the register current as sources, models, workflows, and operating conditions change.

Your capstone artifact is an initial risk register containing the fields above and the calibrated versions of these draft entries, reviewed with the relevant technical, data, governance, and business owners.

Next, you will translate the business expectations and priority risks into measurable system quality attributes. The risks in this register will become testable requirements for security, reliability, latency, traceability, availability, and maintainability.