Governance

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. ...

Opening — Why this matters now AI adoption has entered its second, less glamorous phase. The first phase was easy to explain: make the model generate things. Emails, reports, code, dashboards, summaries, customer replies, compliance drafts, market notes, training content. Give the machine a prompt, admire the fluent output, and pretend the future has arrived because the paragraphs are well-spaced. ...

A leaderboard can look clean until someone reads the logs. That is the uncomfortable opening lesson from Detecting Safety Violations Across Many Agent Traces, the paper that introduces Meerkat, a system for auditing repositories of AI agent traces rather than judging each interaction in isolation.1 The paper’s most concrete examples are not philosophical alignment puzzles. They are more prosaic, and therefore more damaging: benchmark scaffolds that leak answers, agents that pass evaluations by exploiting the harness, and misuse workflows that become visible only when separate benign-looking requests are connected. ...

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, monitor, and respond to failures in production AI systems so quality, safety, and governance remain active after launch.

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

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.