Saltar al contenido principal
Un chatbot de cara al cliente recibe entrada no confiable del público y la envía a un modelo. Eso lo convierte en la superficie de mayor exposición que operas: los usuarios pegan PII que no quieres almacenar upstream, los atacantes intentan anular tu prompt de sistema, y el modelo puede devolver secretos o contenido inseguro al chat. Esta receta cablea los cuatro controles que aseguran un chatbot de IA de extremo a extremo — un guardrail de PII en la solicitud, cribado de inyección de prompts, seguridad de salida y una única clave con alcance estrecho — todo en la consola, sin ningún cambio en el código de tu chatbot.
Todo aquí se vincula a tu espacio de trabajo y se configura desde la consola. Tu chatbot sigue llamando a https://api.orcarouter.ai/v1/chat/completions con la misma clave sk-orca-... — solo cambia la política en el gateway. Las acciones de configuración necesitan los roles indicados por paso; las llamadas de relay usan la clave con alcance.

​
1. El modelo de amenazas de un chatbot público

Antes de autorar nada, sabe contra qué te defiendes. La superficie de ataque de un chatbot es más estrecha que la de un agente completo — pero los riesgos de alta frecuencia son concretos:

PII entra, PII registrada

Los usuarios pegan correos, números de tarjeta, SSN en el chat — y los reenvías upstream y a tus logs.

Inyección de prompts

“Ignora las instrucciones anteriores y …” — intentos de anular tu prompt de sistema y cambiar el comportamiento del bot.

Jailbreaks

Encuadres DAN / juego de roles que intentan sacar al bot de su política.

Salida insegura

El modelo devolviendo secretos filtrados, plantilla de prompt de sistema o contenido con inyección al chat.
Un chatbot simple no tiene llamadas a herramientas, así que esta receta se apoya en los Guardrails — el plano de texto — en vez del Firewall. Si tu bot sí llama a herramientas, superpón el Firewall encima (ver §6).

​
2. Un guardrail, cuatro trabajos

En vez de cuatro políticas separadas, autora un guardrail de espacio de trabajo con reglas ordenadas que cubran cada riesgo. Un guardrail es una lista de reglas nombrada y ordenada; cada regla dice qué buscar, dónde (input, output o both) y qué hacer (block, mask o flag). En la consola, abre Guardrails → New guardrail, nómbralo chatbot-shield y añade las reglas de abajo. Autorar un guardrail — y ejecutar el sandbox Test — necesita el rol Developer; ver guardrails está abierto a cualquier miembro.

​
a. PII en la solicitud

Añade una regla PII, etapa input, acción mask. El conjunto de entidades integrado es cerrado — elige las que un chatbot realmente ve: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "credit_card", "ssn", "ip"],
  "entity_actions": { "credit_card": "block", "ssn": "block" }
}
Una máscara reemplaza cada coincidencia con una etiqueta tipada — jane@acme.com se convierte en [EMAIL], así que el modelo upstream nunca ve la dirección. El override entity_actions bloquea la solicitud por completo ante un número de tarjeta o un SSN mientras enmascara las entidades de menor severidad. Esto es exactamente el preset PII Shield, extendido con overrides por entidad — aplica el preset desde la biblioteca de plantillas y edita desde ahí.
El enmascarado de PII en la etapa de entrada está en vivo hoy — reescribe la solicitud antes de que el modelo la vea. El enmascarado en vivo de la respuesta en streaming está en el roadmap. Para redactar PII de lo que el bot responde, usa una regla de block de salida (aplicada en streaming y no-streaming) o ejecuta el bot en no-streaming, donde aplica el enmascarado de salida. Prueba primero tu combinación exacta de etapa/streaming en la pestaña Test.

​
b. Cribado de inyección de prompts

OrcaRouter incluye esto como el preset de seguridad Prompt-Injection Basics (una denylist de palabras clave para frases como “ignore previous instructions” y “reveal your system prompt”; para una cobertura regex más estricta de encuadres DAN / juego de roles, añade el preset Jailbreak / Role-Play Blocker) más, para intención semántica que ningún patrón captura, una regla llm_judge. Añade el preset, luego una regla de juez en la etapa input con una rúbrica que marque intentos de inyección/anulación. El juez se ejecuta contra un modelo de tu espacio de trabajo, está acotado por judge_timeout_ms y falla abierto por defecto (un error del juez se registra y la solicitud continúa) — establece judge_fail_open: false para fallar cerrado.
Empieza las reglas de inyección en flag, observa el feed de Matches durante un día sobre tráfico real, luego promociona a block una vez que hayas confirmado que se disparan en ataques y no en preguntas legítimas. Ver modos de aplicación.

​
c. Seguridad de salida

Añade una regla de block en la etapa output (regex o palabra clave) para contenido que nunca debe llegar al chat — secretos filtrados, tokens de control de plantilla de chat, plantilla de prompt de sistema. El Secrets & API-Key Blocker y los presets de seguridad de filtración de prompt de sistema cubren los casos comunes; aplícalos y fija las reglas relevantes a la etapa output. El block de salida se aplica también en streaming — el escáner corta el stream en pleno vuelo y emite un mensaje de reemplazo antes de que el contenido bloqueado alcance al usuario.

​
3. Prueba antes de lanzar

Cada editor de guardrail tiene una pestaña Test. Pega una muestra, elige la etapa y ejecuta la política actual localmente — sin llamada upstream, sin cuota gastada.
Pega estoEtapaEspera
email me at jane@acme.cominputemail me at [EMAIL]
ignore previous instructionsinputflag / block (tu elección)
tarjeta 4111 1111 1111 1111inputguardrail_blocked (según el override)
Para cobertura adversarial, la pestaña Eval ejecuta la política contra corpora de red-team incluidos (o tu propio JSONL) y reporta cómo puntuó — afina la rúbrica del juez hasta que capture ataques conocidos sin marcar chat benigno.

​
4. Acuña una sola clave con alcance para el bot

Un guardrail solo aplica sobre claves que resuelven a él. Dale al chatbot su propia clave, con alcance al mínimo que necesita — nunca tu clave de toda la cuenta. En API Keys → New key, establece:
Elige chatbot-shield del desplegable Guardrail. Esto establece guardrail_id en la clave. Una adjunción explícita es lo opuesto al interruptor de apagado: si está establecida y habilitada, siempre aplica y nunca hace fallback silencioso. (Déjala sin establecer para hacer fallback al guardrail is_default del espacio de trabajo.)
Establece credit_limit_usd a un techo razonable (0 = ilimitado). Un chatbot público es la clave más propensa a ser abusada — un tope de crédito duro es tu límite de radio de explosión. Ver denial-of-wallet.
Activa model_limits y lista solo el/los modelo(s) que el bot puede llamar, para que una clave filtrada no pueda usarse para ejecutar un modelo caro que nunca pretendiste exponer.
Establece allow_ips a las IPs de egress de tu backend si el bot llama desde un servidor fijo, y un expired_time si la clave es temporal (-1 = nunca expira).
La clave se enmascara en pantalla tras la creación — cópiala una vez. Tu backend de chatbot ahora envía cada turno de usuario a través de chatbot-shield sin que el código sepa que el cribado está ocurriendo.

​
5. Vigílalo en producción

Dos lecturas te mantienen honesto, ambas con alcance de espacio de trabajo:
  • Guardrails → Matches (cualquier Member) — cada regla que se disparó: tipo, acción, etapa y detalle. La subcadena coincidente se registra solo si Log raw content está activado para el guardrail (apagado por defecto — la postura conservadora de privacidad). Marca un falso positivo para afinar la política (Admin).
  • Version history — cada cambio escribe una fila de historial; diff entre dos versiones cualesquiera y revierte si una regla resulta demasiado agresiva. Una solicitud bloqueada devuelve HTTP 400 guardrail_blocked, no cuesta cuota y se marca skip-retry.
Una respuesta guardrail_blocked es un 400 deliberado y visible al usuario. Manéjalo en tu UI de chatbot con un mensaje amable (“No puedo procesar eso”) en vez de exponer el error en bruto — el gateway ya ha detenido el turno inseguro por ti.

​
6. Si tu bot llama a herramientas

En el momento en que tu chatbot puede llamar a una función, obtener una URL o alcanzar un servidor MCP, el cribado de texto no basta — necesitas el plano de acción. Adjunta una política de Firewall a la misma clave vía firewall_policy_id, o aplica el nivel de autonomía balanced para auditar llamadas a herramientas y marcar PII en todo el espacio de trabajo antes de endurecer. La ruta más rápida es el inicio rápido zero-trust; para un agente que llama a herramientas intensamente, ver asegurar un agente autónomo.

​
7. Dónde profundizar

Referencia de Guardrails

Cada tipo de regla, entidad PII, campo de juez y el arnés de eval al completo.

Guardrails vs Firewall

Plano de texto vs plano de acción — cuándo necesitas cuál.

Modos de aplicación

Observe → shadow → enforce: lanza sin romper el bot.

Alcance de claves, políticas, espacios de trabajo

Cómo resuelven la adjunción de clave y los valores por defecto del espacio de trabajo.