Read the rule before the claim. The published example matches an assignment from `$MODEL.predict(...)` or `$CLIENT.chat.completions.create(...)`, and suppresses the finding with two `pattern-not-inside` clauses, one for an `if $APPROVED:` block and one for `$RESULT = require_human_approval(...)` [10]. `pattern-not-inside` is an enclosure test. The message says the finding fires when there is no oversight hook nearby [11], and nearby is not something a Semgrep pattern expresses. Now look at the passing version the post offers: `result = model.predict(applicant_data)`, then `if require_human_approval(result): finalize_decision(result)` [12]. The predict call sits above the gate, so nothing encloses it, and the rule as printed still matches the code it presents as compliant. The post says the example is simplified and that the production ruleset covers more oversight idioms and confidence handling [13]. I believe that. The simplification also removed the hard part, which is deciding what counts as a hook when the approval lives behind a decorator, or in a queue a human drains an hour later.
The number that governs planning is the three-to-six-month one. Take the post's own dates: a team that started work the morning after 2 August 2026 hands over its Annex IV package somewhere between 2 November 2026 and 2 February 2027 [14]. Teams that have not started are counting from today. Against that, the Article 14 delta in the example is one line of code weighed against a nine-section file [20], which is a fair map of where the effort actually sits.
The claim about governance tooling is the most checkable part. According to the post, OneTrust, Vanta and Credo AI read cloud configuration and identity systems, plus questionnaire answers, and do not read code [8]. Put the risk in a scoring function or an inference call that feeds a hiring or lending decision and a cloud-config scan sees nothing of it [9].
What would have to be true for "nearly every one failed" to say something about your service? The sample would need systems in scope the way yours is. The post gives no repository count and does not explain how it decided which repos were high-risk [15], while the Annex III categories it lists run to credit scoring, CV screening and hiring tools, biometric categorisation, insurance underwriting and exam scoring [2]. A public repo can implement any of those without a provider shipping it into the EU, which is the condition the post itself attaches to the obligation [17]. So the result reads as evidence about awareness, which is how the authors frame it [18], rather than as a base rate you can apply to your own codebase. The 3-6 month figure is the part worth stealing for a plan.
