# Cómo proteger tu agente de IA usando un gate System One

Aprendé a frenar acciones destructivas de tus agentes de IA usando un gate System One rápido, calibrado y con revisión humana.

*agentes · 2026-09-23 · [mauriciosneira.com](https://mauriciosneira.com/blog/gates-system-one-agentes)*

---

Tu agente autónomo decide ejecutar una transferencia bancaria o borrar un registro de la base de datos de producción. Si tu única defensa es pedirle por system prompt que solicite confirmación antes de actuar, estás a un paso de un incidente grave. Esa instrucción no frena un prompt injection ni garantiza autocontrol en un modelo estocástico. Para resolver la seguridad agentes ia en este tipo de flujos, necesitás barreras que no dependan de la buena voluntad del modelo.

Acá te explico cómo proteger tu sistema usando un gate System One: un clasificador rápido, calibrado y barato que frena acciones destructivas y las deriva a revisión humana.

Imaginemos un agente financiero que ejecuta acciones como mover fondos o modificar configuraciones de cuentas. Vamos a usar este caso en todo el post para ver cómo asegurarlo.

## Por qué no usar un LLM generativo como gate

Usar un LLM tradicional para validar cada acción tiene dos problemas claros.

1. **Costo y latencia:** el gate corre en cada llamada a una tool, por lo que sumar cientos de milisegundos de generación autorregresiva en cada paso es inviable.
2. **Confianza ficticia:** si un LLM generativo escribe `"confidence": 0.95`, ese valor es solo texto generado y no una probabilidad estadística real sobre la que puedas fijar un umbral.

Un modelo System One (como Jev de TypeSafe, hosteado, o Laya, open-weights) resuelve esto en un único forward pass sin generar texto. Recibe el estado de la acción y una pregunta tipada (`noul`, un binario probabilístico). Jev responde en ~100 ms (reporta entre 70 y 500 ms según la carga); Laya, corriendo en tu infraestructura local, responde en ~33 ms.

```mermaid
flowchart TD
    A["El agente propone una tool call"] --> H{"Validación dura determinista (RBAC, límites, allowlist)"}
    H -- "viola una regla" --> X["Bloquear"]
    H -- "pasa" --> G["Gate System One: ¿es destructiva? (noul, 1 forward pass)"]
    G -- "riesgo ≥ umbral" --> HITL["Human-in-the-loop"]
    G -- "riesgo < umbral" --> E["Ejecutar la tool"]
    G -. "timeout / error" .-> HITL
```

## El gate en código (API real)

La consulta usa el tipo `noul`, donde la API entrega directamente la probabilidad en el campo `answers`. En este formato no existe un campo `confidence` separado, ya que la probabilidad misma es la señal.

```python
import os
import requests

def gate_risk(action: dict) -> float:
    """Devuelve P(acción destructiva) en 0..1, calibrada."""
    resp = requests.post(
        "https://api.typesafe.ai/v1/systemone",
        headers={"Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}"},
        json={
            "model": "jev-latest",
            "state": action,  # el dict de la tool call: nombre, args, contexto
            "questions": {
                "destructive": {
                    "type": "noul",
                    "instructions": (
                        "Is this action destructive or irreversible? "
                        "(deletes data, moves money, changes prod config, sends to customers)"
                    ),
                }
            },
        },
        timeout=5,
    )
    resp.raise_for_status()
    return resp.json()["answers"]["destructive"]["noul"]  # 0..1


THRESHOLD = 0.5  # calibralo sobre tus datos (ver más abajo)

def guarded_execute(action: dict, tool):
    try:
        risk = gate_risk(action)
    except Exception:
        # FAIL-CLOSED: si el gate no responde, NO ejecutamos. Derivamos a humano.
        return escalate_to_human(action, reason="gate no disponible")

    if risk >= THRESHOLD:
        return escalate_to_human(action, reason=f"riesgo {risk:.2f}")
    return tool(action)
```

Tené en cuenta dos reglas obligatorias para implementar esto:

1. **Diseño fail-closed:** si la llamada da timeout, tira un error 5xx o falla al parsear, no ejecutes la acción y derivala a un operador humano.
2. **Calibración obligatoria:** ajustá la temperatura del modelo con un dataset propio de acciones etiquetadas para que un valor de 0.5 represente exactamente un 50% de probabilidad real. El paper clásico sobre calibración en [arXiv:1706.04599](https://arxiv.org/abs/1706.04599) muestra cómo aplicar temperature scaling para corregir probabilidades descalibradas. Laya publica que su ECE baja de ~0.47 a ~0.08 recién tras este paso; sin calibrar, el modelo muestra sobreconfianza.

## El gate no reemplaza la validación dura en la seguridad agentes ia

Un clasificador probabilístico evaluando los parámetros de una transferencia o una query no representa un límite infranqueable. Como detalla el proyecto [OWASP GenAI Security Project](https://genai.owasp.org/llm-top-10/) en sus guías de amenazas para modelos y aplicaciones autónomas, si un atacante manipula datos de entrada como un ticket o un correo, puede sesgar los embeddings para bajar la puntuación de riesgo del gate.

Por esta razón, tenés que aplicar una estrategia de defensa en capas:

1. **Validación dura en código:** reglas deterministas mediante código tradicional (`if amount > MAX: block`), RBAC, allowlists de recursos e idempotencia que ningún prompt pueda alterar.
2. **Gate System One:** una segunda capa probabilística calibrada para detectar operaciones atípicas o combinaciones imprevistas que las reglas fijas no cubren.
3. **Revisión human-in-the-loop:** intervención manual obligatoria para cualquier acción cuyo score supere el umbral definido (por ejemplo, 0.5).

## Jev o Laya para el gate

| | **Jev** (hosted) | **Laya** (open) |
|---|---|---|
| Latencia | ~100 ms (red) | ~33 ms (local) |
| Dónde corre | infra de TypeSafe | tu red, privado |
| Datos de la acción | salen a un tercero | nunca salen |
| Costo | por input token | cómputo propio |
| Calibración | ajustás temperatura sobre tus datos | ídem |

Para monitorear payloads con datos sensibles en cada ejecución (como montos, cuentas o comandos internos), yo prefiero correr Laya en local. Te da baja latencia, evita costos por request y no saca información de tu red. Jev conviene si buscás una opción administrada sin gestionar infraestructura y aceptás enviar datos afuera en su etapa de early access.

## Cuándo no poner un gate System One

Evitá sumar este componente en estos dos escenarios:

1. **Cuando la lógica es determinista:** restricciones como "no transferir montos mayores a X" o "prohibir el borrado en la tabla de usuarios" deben resolverse con un `if` directo en tu backend.
2. **Cuando el catálogo de acciones es reducido:** si tu agente maneja solo tres operaciones y una es crítica, agregá confirmación humana fija para esa acción puntual.

## Qué hacer el lunes

1. **Identificá las tools con impacto crítico:** hacé un inventario de acciones que escriban datos, borren registros, muevan plata, envíen mensajes a clientes o alteren configuraciones.
2. **Implementá validaciones duras deterministas:** configurá primero tus reglas de RBAC, allowlists y límites numéricos en código.
3. **Integrá el gate System One como filtro secundario:** calibralo con un set de datos propio, definí el umbral de corte y asegurate de aplicar fail-closed.
4. **Conectá el flujo human-in-the-loop:** enviá a aprobación humana cualquier acción riesgosa, mostrando la operación y su probabilidad estimada al revisor.

El control determinista permite llevar adelante una estrategia sólida de seguridad agentes ia en producción. Un gate calibrado y eficiente te da la tranquilidad necesaria para operar sin riesgo de incidentes graves.

---

**Más a fondo:** [qué es Jev y la era de los modelos System One](/blog/jev-system-one-modelos-discriminativos-ia) · [Jev vs Laya, head-to-head real](/blog/laya-vs-jev-system-one-open-vs-cerrado) · [gobernanza de agentes: por qué el tool calling directo es una falla de diseño](/blog/gobernanza-seguridad-agentes-autonomos-capbac).