Why the scope statement is a risk decision, not paperwork

Every downstream activity — risk assessment, controls, audits — inherits its boundaries from scope. The judgment lives in the exclusions: I excluded the foundation model internals because OPHP can't control them, so that risk is managed through supplier oversight and contract terms instead of direct controls. I kept the suspended resume-screening pilot out of scope, but with a gate — it can't restart until it passes an AI impact assessment. If something goes wrong later, every exclusion is a documented, defensible decision rather than an oversight.

Why I kept PHI out of the chatbot's knowledge base entirely

The strongest control is architectural. Instead of putting patient data in the RAG corpus and filtering the outputs, OPHP Assist's knowledge base contains only public operational content — locations, hours, insurance, policies. Patient-specific actions flow through authenticated API calls scoped to the current session. "The PHI was never in the corpus" is a fundamentally better answer than "we added a filter and hope it holds."

Why one risk was accepted instead of mitigated

Vendor outage (R-10) is accepted at Low with a contingency: the chatbot fails visibly and safely to phone and portal fallback. A risk register where every line says "mitigate" is a checkbox exercise — real risk management means some risks are consciously accepted, with rationale, an owner, and a review date. Showing the acceptance is showing the discipline.

Why no AI tool at OPHP is approved for PHI — including Copilot

For version 1.0 of a healthcare AI program, a bright line beats a nuanced matrix. "No PHI in any AI tool, period" is a rule 1,850 people can remember and auditors can verify. The policy includes an exception process, so the line can move deliberately later — with a risk assessment, a BAA, and controls — rather than eroding informally through a thousand small judgment calls.

Why the Acceptable Use Policy permits before it prohibits

Staff were already using shadow AI — not because they're reckless, but because AI is useful and nobody offered a safe path. So the policy leads with approved tools, pairs every "no" with a sanctioned alternative, and protects good-faith self-reporting of mistakes. A policy that only says "no" gets ignored; one that makes the secure path the convenient path actually changes behavior.

Why patient harm is scored separately from company harm

ISO/IEC 42001's distinctive requirement (Clause 6.1.4) is assessing impacts on individuals and society, not just the organization. Risks like hallucinated health guidance or unequal chatbot access get evaluated from the patient's perspective in a dedicated impact assessment, and where patient harm scores higher than organizational harm, the higher score drives the risk level. That's the difference between AI governance and rebadged IT risk management.