Case Studies
Corporate IT
Use Case: Prevent leakage of sensitive internal information via AI chatbots
Education
Use Case: Safe student interaction with GenAI assistants
Healthcare
Use Case: Redact patient PII in GenAI applications
Customer Service
Use Case: Enforce tone and compliance in AI-generated responses
Jarvis AI Guardrails are the controls that sit between your users and every language model call: content governance, audit, policy enforcement, and human review. These 6 rows summarise what each layer covers and where it runs.
| Layer | What it enforces |
|---|---|
| PII redaction | Personally identifiable information is detected and blocked before a prompt leaves your environment. |
| Word and topic filtering | Predefined and custom filters for sensitive terms, plus denied topics such as legal, HR, or competitive intelligence. |
| Context-aware filtering | Moderation thresholds vary by use case or domain instead of applying 1 blunt rule to every workload. |
| Audit and alerting | Full message logging for compliance, with real-time alerts when a violation or suspicious prompt occurs. |
| Policy enforcement | 100+ prebuilt compliance policies plus integration hooks into existing DLP, IAM, and compliance systems. |
| Human in the loop | Flagged prompts and outputs route to a reviewer, and reviewer feedback improves later responses. |
Guardrails are judged on where they run and what they are allowed to block. These rows fix both, and name the regulatory frameworks the control set is designed against so the mapping can be checked.
| Specification | Value |
|---|---|
| Enforcement point | On the request path, before the prompt leaves the customer environment |
| Control layers | 4 — content governance, audit, policy enforcement, human review |
| Policy library | 100+ prebuilt compliance policies, extensible with custom rules |
| PII handling | Detection and redaction applied to 1 shared path for all clients |
| Topic control | Predefined and custom word filters plus denied-topic categories |
| Context awareness | Moderation thresholds scoped per use case or domain, not 1 global rule |
| Message logging | Full inbound and outbound capture for compliance review |
| Alerting | Real-time alerts on violations and suspicious prompts |
| Access control | RBAC plus per-resource ACL on model and tool usage |
| Escalation | Human-in-the-loop review with reviewer feedback fed back into responses |
| Integration hooks | DLP, IAM, and SIEM systems already in place |
| Denial responses | HTTP 403 for policy denial, HTTP 401 for unauthenticated callers |
| Vendor-side copies | 0 — logs stay in the customer account |
| AI governance reference | NIST AI RMF 1.0 (2023) |
| Zero-trust reference | NIST SP 800-207 (2020) |
| Health-sector reference | HIPAA Security Rule, 45 CFR Part 164 Subpart C |
Guardrails that arrive as a hard block on day one get routed around. The 5 stages below start in observation mode and tighten only once the traffic pattern is understood.
The two halves of a workable guardrail programme are automated filtering on the request path and a human review route for the cases automation should not decide alone.
Guardrail conversations almost always start with the same question — why is the protection built into the model endpoint not enough on its own?
Endpoint guardrails protect the model provider’s boundary. They do not give you centralised control over every inbound and outbound interaction across the different models and clients your organisation uses.
Jarvis applies policy centrally, which is what ensures no sensitive data leaves your environment regardless of which model a given team happens to be calling.
Detected personally identifiable information is removed or blocked before the request leaves your environment, so the model never receives the raw values.
Because the redaction happens on the shared request path, the same behaviour applies to chat, copilots, and agents without each client implementing it separately.
Yes. Context-aware filtering lets moderation thresholds vary by use case or domain, and role-based access controls scope which models a given team may use at all.
A legal team and a support team can therefore operate under genuinely different rules without running 2 separate deployments.
Integration hooks connect guardrail events to the DLP, IAM, and compliance systems already in place, and full message logs can be forwarded to your SIEM.
The goal is that AI interactions appear in the same evidence trail as everything else, rather than in a separate console nobody reviews.
Filtering runs on the request path, so it does add work before the model call. The controls are designed to be cheap relative to inference: pattern-based PII detection and topic classification complete in a fraction of the time a language model takes to produce its first token.
The comparison that matters is not guardrails versus no guardrails, but guardrails versus the alternative control — routing every sensitive prompt through a human queue, which costs hours rather than milliseconds.
Where a specific policy does prove expensive, context-aware filtering lets you scope it to the 1 or 2 domains that need it instead of applying it to all traffic.
Guardrails are one control in a wider governance layer. These pages cover what sits around them.
ASCENDING is an AWS Advanced Tier Services Partner with the AWS Generative AI Competency, and builds Jarvis as licensed software that runs inside your own cloud account. The frameworks below are the reference points for the controls described above.
