Google Cloud Model Armor vs Granite Guardian

Google Cloud Model Armor

2 million free tokens a month, then $0.10 per million. OAuth only, and a template must exist in the same location as the endpoint before the first call.

Granite Guardian

One ungated Apache 2.0 model judges harm, jailbreaks, RAG groundedness, function-call errors and custom criteria, with signed weights and published evaluation code. It is trained and tested on English only, each call checks one criterion, the 4.1 prompt format differs from 3.x, and IBM's watsonx.ai lists only the deprecated 3.0 model.

Google Cloud Model Armor

1. Create one template per location you call from. A template in us-central1 doesn't answer on the europe-west2 endpoint
2. Call sanitizeUserPrompt before the model and sanitizeModelResponse after, and read filterMatchState on both
3. Treat EXECUTION_SKIPPED as unchecked, not clean. It means the input went over the filter's 65,536-token cap
4. Pin the template to the Stable alias and move off v1 and v2 before 17 December 2026. In asia-northeast3, v1 stays the Stable version
5. Retry 500, 502, 503 and 504 with truncated exponential backoff, and keep fan-out under the 1,200 queries a minute shared by the project

Granite Guardian

1. Append the <guardian> block as the final user message, with the mode line, ### Criteria: and ### Scoring Schema:. Copy the strings from the model card, because no package builds them
2. Use the no-think instruction for gating and parse <score>. Think mode writes a reasoning trace first, and the card's examples allow up to 2,048 output tokens
3. Treat yes as the criterion being met, which for built-in criteria means the risk is present. Treat a missing <score> tag as a failed check
4. Pass retrieved text through documents= and tool schemas through available_tools= in apply_chat_template, not inside the message text
5. Under Ollama, set num_ctx in the request options. IBM's docs say the default context is short and long requests are truncated