Manage data, risk and responsibility

By the end of this lesson

• Trace data from its source into retrieval, prompts, logs and test copies, with purposes and owners.
• Turn vague risk labels into scenarios that guide containment, investigation and recovery.
• Identify authority over business, data, operations and specialist matters, and record an actionable or pending decision.

Before you begin

• Bring the test notes, unresolved questions and recommendation from Lesson 6. A paper proposal is enough for this lesson.
• Use two synthetic Beichen events: former-region information visible in old sessions after reassignment, and withdrawn material still being cited. Do not assume they share a cause.

Read the Beichen case and introductory data

Start with decision authority, not a risk score

You may be able to recommend a next step without having authority to accept every consequence for the customer. The business owner confirms task scope and business choices. The data owner confirms meaning, use and access. The operations owner confirms support, pausing and recovery. Equipment safety, privacy and other specialist judgments require appropriately qualified and authorized people, rather than a project-team vote.

One person may hold several responsibilities, or they may sit in different teams. Name the person, authority and backup instead of writing “business approval” or “security sign-off.” Before a discussion, state the decision, its owner and required evidence. If authority is disputed, maintain an explicit restricted operating state.

NIST’s published AI RMF 1.0 and generative AI companion resource can help prompt risk questions. They are voluntary frameworks, not customer authorization or evidence of legal compliance. This lesson organizes facts and choices; actual specialist requirements and residual-risk decisions still need confirmation by responsible people in a real project.

Follow the data into every relevant copy

Start with one service record rather than a large diagram labeled “data platform.” Ask where it came from, what fields mean, the permitted purpose, who can see it and whether it goes to a model or another service. Permission to read the source does not automatically cover a new purpose, third-party transfer, export or long-term storage.

Beichen’s public event identifies at least five copies: the retrieval index, model prompt, execution log, evaluation dataset and exported report. Depending on your system, also inspect sessions, caches and backups. For each, record location, purpose, permitted viewers, retention and deletion, propagation of revocation or withdrawal, and a verification owner. In self-study, describe proposed controls without claiming they exist.

Do not log all source text simply because it might aid debugging. Start with identifiers, versions, restricted error information and verification results; content retention needs a defined purpose and permission. Deletion also extends beyond one database row. Remaining copies, required retention and recovery arrangements need owner confirmation, particularly when records may be necessary for investigation.

Write risks so they are useful when something happens

“Privacy risk: improve management” tells nobody what to do. Replace it with a situation: under which condition, what might happen, who is affected, which controls exist, where the gap is, how to contain exposure and who decides whether work can continue. Describe something investigable; incomplete logs do not justify asserting a root cause.

For example: “Two reassigned employees can still see former-region customer information in old sessions. The symptom is confirmed; identity synchronization, session caching and retrieval filtering remain possible causes. Restrict the relevant access and preserve records authorized for investigation. The data owner assesses scope; operations implements the pause and verifies recovery conditions.” This has a practical use that “access-control risk” lacks.

Write a separate scenario for the withdrawn safety material: the assistant cites it, and a copy remains on the shared drive, but the state of every other copy is unknown. Disable the affected material and task path, then verify versions and propagation. A document can be visible to someone and still be invalid. Knowledge validity is not merely an access issue.

Worked example: handle two complaints without merging them

Imagine receiving the Beichen complaints with only their text and limited logs. You cannot yet determine whether other people were affected. The first priority is reducing further exposure, not promising a fix in ten minutes. Authorized people must execute containment. If you lack authority, send a specific pause request and describe the current exposure.

Separate confirmed facts from questions to investigate. Confirmed observations are former-region information visible in two reassigned employees’ sessions and one answer citing withdrawn material. Open questions include affected tasks, content, time window and other copies. “We have two reports” is not “only two people are affected.”

The sequence below is a tabletop exercise. Responsible teams must confirm how to restrict access, preserve evidence, notify people and meet applicable requirements in a live system. Self-study requires no real account or deletion. You are practicing the order of action, limits of judgment and next steps.

• Contain exposure: ask data and operations owners to restrict relevant old sessions and knowledge paths. If scope cannot yet be separated, use the more conservative restricted state.
• Keep separate records for cross-region exposure and invalid-source citations. Preserve authorized sources, timestamps, request identifiers and actions taken.
• Notify people who need to act, with facts, possible impact, unknowns and the specific decision required. Do not broadcast full sensitive content.
• Investigate two paths: authorization changes within active sessions, and withdrawal propagation into indexes, prompts, logs and test copies.
• Define restoration conditions: test known paths, boundaries and regressions with simulated identities and synthetic material. Relevant owners decide which part can resume; operations retains stop authority.
• Update the account: explain containment, progress, unresolved impact and the next update time. Record service restoration separately from handling consequences that already occurred.

Apply tool permissions and stop controls before actions

Beichen’s initial assistant does not submit requests automatically. If submission is proposed later, establish what it can do, whose permissions it uses and when an action is denied. A command inside a document must not grant new authority. External text is input, not a substitute for system policy or business authorization.

Tool controls can cover allowed actions and parameters, eligible users and tasks, approval requirements, rates and scope. Record the request, control decision and final state so authorized support staff can reconstruct events. Test stopping against running tasks, queues and alternate entry points, rather than merely hiding an interface button.

OWASP’s agent-security resources and the Agent Control Standard (ACS) offer reference questions for controls. Before adopting a framework, verify its version, configuration, coverage of actual actions and behavior when the control service is unavailable, then test in a controlled environment. A standard’s name, an installed library or a log alone does not establish effective control or certification.

Write a decision that someone can carry out

Begin with the decision required, rather than asking whether everyone feels comfortable. Have evidence owners correct the facts, users and operations explain consequences, and engineers explain controls and uncertainty. Compare pausing, narrowing, collecting more evidence or restoring a specific part, then have the relevant authorized owner decide.

A practice record might keep relevant access in old sessions restricted, use only synthetic data to test three reassignment scenarios, have engineering submit results, have the data owner confirm restoration criteria, and have operations implement them while retaining stop authority. If in-session revocation is not established, access remains restricted. The three scenarios are your test design; specify them rather than treating the count as an industry requirement.

An escalation needs the decision owner, exact question, containment already performed, remaining unknowns, options and consequences, and a response time. Routine changes do not all need a governance meeting. Check decision authority when a change affects data purposes, permissions, actions, pilot scope or important controls.

Keep unresolved issues visible after approval

Do not make the data owner, security team or legal team responsible for every question. Source-document validity, equipment applicability, interface state and review capacity each need their own evidence. Specialist opinions also have a defined scope. Identify who supplies facts, implements controls and accepts residual risk; a signature does not transfer all of those duties.

Restoring a code version is not the same as resolving every consequence. Restoration changes future behavior; information already shown, retained copies and completed actions may still require investigation and handling. A successful restoration test cannot establish that all past effects have been reversed.

By the end, each unresolved risk should have an owner, next step, restriction and review condition. Without a real owner, write “awaiting data-owner confirmation” rather than using a role name to imply permission. Lesson 8 turns these records into testable conditions for user trials, instead of a form that merely says risks were considered.

Practice the method

Check your understanding

Write your answer before opening the explanation, then check what you might have missed.

Your record and next step

A data ownership map, three risk scenarios and conditions for continued operation.

Bring data purposes, risk scenarios, control tests and ownership decisions into Lesson 8. You will assess who can try which tasks under which conditions, rather than relying on an answer score.