Governance

How to decide when a business workflow should avoid public LLM endpoints, based on data sensitivity, contractual exposure, and safer design alternatives.

How to build a risk-tiered human review model so oversight is meaningful, efficient, and matched to business impact rather than added as a vague slogan.

How to design access controls, prompt/output logging, and retention rules for AI systems so governance remains practical, auditable, and proportional to risk.

How to evaluate AI vendors before rollout, using a practical checklist for data handling, governance, contract risk, security posture, and operational fit.

How to evaluate, monitor, and respond to failures in production AI systems so quality, safety, and governance remain active after launch.

TL;DR for operators A personal assistant can hear a confident user claim, store it as a preference or rule, and rely on it during a later task after the original conversation is gone. The safety problem is therefore not only the agreeable reply. It is the write that lets the claim survive. ...

Business AI has acquired a slightly dangerous reflex: when a system underperforms, reach for a stronger model, a faster pipeline, or a more elaborate scoring function. Very enterprise. Very expensive. Occasionally useful. The more interesting failure mode is quieter. A system may have enough intelligence, enough data, and enough compute, yet still be solving the wrong version of the problem because it inherited the wrong reference frame. It reads a wearable signal as if it were clinical instrumentation. It schedules network traffic as if packets only matter after they announce themselves. It ranks alternatives as if the best and worst items in the current dataset were the same thing as business aspiration and business refusal. ...

The number looked safe. Then someone ran it twice. A familiar business problem: one vendor says its model resists jailbreaks. Another red-team report says a new attack reaches a spectacular Attack Success Rate. A compliance team sees a percentage, puts it into a risk register, and moves on. Unfortunately, that percentage may be doing more acting than measuring. ...

Security testing is not a screenshot. A model gives a dangerous answer. Someone posts the transcript. A vendor says the model has been updated. A consultant turns the incident into a slide titled “AI risk is real.” Everyone nods gravely. Very mature. Very enterprise. The harder question is less theatrical: can the same vulnerability be tested again, under controlled conditions, with visible logs, a consistent evaluator, repeatable statistics, and enough human inspection to make the result defensible? ...

A benchmark score is easy to quote. It is harder to know what broke. In Jailbreak Mimicry: Automated Discovery of Narrative-Based Jailbreaks for Large Language Models, Pavlos Ntais reports an 81.0% attack success rate against GPT-OSS-20B on a held-out 200-item test set.1 That number is attention-grabbing. It is also not the main lesson. ...