A practical ethics decision framework

Write the purpose as a benefit to a person or process, not as a technical capability. “Use a language model to generate replies” describes a method. “Help support agents produce accurate, respectful first drafts so customers receive faster resolutions” names an intended benefit.

Then name what the system will and will not do. The complaint assistant may draft text but may not send it, approve refunds, change account records, infer a customer’s emotional state for marketing, or provide regulated advice. Boundaries prevent a low-risk pilot from drifting into a higher-impact role without review.

Ask why AI is appropriate. Compare it with templates, search, workflow improvements, more staff, or no intervention. AI may be useful when language varies and a draft is easy to review. A deterministic rule may be better for refund limits. “We already bought the tool” is not evidence of suitability.

Define success and unacceptable outcomes before testing. Faster drafts are not successful if agents spend equal time correcting fabricated policy or if customers receive more inconsistent decisions. Include quality, access, safety, privacy, fairness, and human workload in the success picture.

List direct users, affected non-users, operators, decision-makers, data subjects, maintainers, vendors, and people who handle failures. For each, ask what benefit they may receive, what burden they may carry, and how much choice or influence they have.

Power matters. A customer can leave a music app more easily than an employee can refuse a mandatory workplace system. A person appealing a benefit decision has less control than the agency operating the model. People with less power may need stronger notice, alternatives, representation, and remedy.

Do not use a single “user” box. In the complaint assistant, the support agent uses the tool, the customer is affected by the reply, managers see productivity data, policy owners define allowed resolutions, and vendor staff may process examples. Their goals overlap but are not identical.

Seek evidence from stakeholders rather than imagining all their needs. Use interviews, accessibility tests, domain experts, frontline observation, community input, complaints, and prior incidents. Participation should be meaningful: tell people what can still change and avoid asking them to legitimize a decision already made.

Map inputs, sources, inferences, model outputs, logs, downstream actions, storage, access, and deletion. Mark sensitive data, uncertain sources, and places where one person’s information enters through another person. Identify secondary uses such as analytics, evaluation, or provider training.

Next, imagine failures across the whole workflow:

• The source record is wrong or incomplete.
• The model fabricates a policy or reveals private details.
• The agent accepts a polished but incorrect draft.
• A retry sends the message twice.
• The customer cannot reach an appeal route.
• Monitoring reports average quality while one language performs poorly.

For each failure, estimate severity, scale, likelihood, reversibility, detection speed, and distribution. Use ranges when evidence is weak. The purpose is prioritization, not false precision. A rare but irreversible privacy disclosure may deserve stronger prevention than a common typo.

Consider misuse and purpose drift as well as accidental error. Could managers turn draft analytics into performance surveillance? Could a user prompt the assistant to retrieve another account? Could a later team connect logs to advertising? Boundaries need technical and organizational enforcement.

Develop at least three options: do not proceed, run a narrow version, and run a broader version with controls. This prevents the discussion from becoming a yes-or-no vote on one favorite design.

Safeguards can prevent, detect, contain, or remedy harm. Prevention includes data minimization, allowlisted sources, permission limits, and excluded uses. Detection includes evaluations, sampled review, alerts, subgroup measures, and complaint analysis. Containment includes rate limits, staged rollout, human approval, and a kill switch. Remedy includes correction, appeal, restoration, notification, and compensation where appropriate.

Prefer controls that change what the system can do over warnings that shift responsibility to users. A disclaimer may set expectations, but it cannot stop the assistant from sending a refund promise. A permission boundary and required approval can.

Examine control quality. Human review fails when staff lack time, evidence, authority, or safe disagreement options. Monitoring fails when nobody owns the alert. An appeal fails when it is hidden or slower than the consequence. State how each safeguard works under real workload.

Make one of four clear decisions:

1. Proceed within stated scope because evidence and controls are proportionate.
2. Pilot with limited people, actions, or time because important uncertainty remains.
3. Revise the design before use because a gap can be addressed.
4. Decline the use because harm, rights, obligations, or control limits make it inappropriate.

Record the rationale, evidence, disagreements, conditions, owners, and review date. A decision log should be short enough to use and detailed enough to reconstruct why the choice was reasonable at the time. Do not hide minority concerns; they may become important when conditions change.

Define operational signals before launch. Track model quality, policy errors, privacy incidents, subgroup patterns, overrides, appeals, time to remedy, user exits, and reviewer workload as relevant. Assign thresholds that pause or narrow the system and name who has that authority. Schedule review after model, data, population, vendor, policy, or purpose changes.

For the complaint assistant, the team might choose a voluntary pilot where AI drafts from approved policy sources, agents see citations, messages cannot send automatically, sensitive fields are redacted from logs, and non-English cases remain outside scope until evaluated. A product owner owns use boundaries, an operations lead owns agent training and appeals, and a privacy owner reviews retention. Expansion requires measured time savings without an increase in material corrections or uneven service.

Use these headings for a compact record:

• Purpose and excluded uses
• People, benefits, burdens, and power
• Data flow and important failure paths
• Options considered
• Chosen safeguards and evidence
• Decision, owners, and unresolved concerns
• Metrics, pause triggers, and review date

Keep links to deeper evaluation, security, privacy, or legal materials where needed. The record coordinates expertise; it does not pretend one generalist can resolve every domain. High-impact employment, health, finance, education, public-service, or safety uses often need qualified specialist review.

The framework should scale with consequence. A brainstorming assistant may need a quick review. A system shaping access to essential services needs deeper evidence, independent challenge, governance approval, and continuing oversight. Proportionate process protects attention for the decisions where errors matter most.