Saltar al contenido
🟠 Builder

Agent Trust Stack — Policy file en YAML

Cómo traducir el Agent Trust Stack en archivo YAML versionado. Schema completo + 3 ejemplos reales (HR scoring, financial transaction, content generation). Output runnable por agente.

Por qué policy file en YAML

El Agent Trust Stack define 5 dimensiones para decidir delegación a IA: Reversibility, Blast radius, Auditability, Cost, Time sensitivity. El framework existe en texto. Pero para empresas operando agentes en escala, texto no escala.

Solución: codificar la policy en archivo YAML versionado en git, leído por el agente en runtime. Ventajas:

  • Versionamiento: cada cambio es PR + review.
  • Auditabilidad: historial completo de cambios de policy.
  • Reuso: misma policy aplicada a múltiples agentes.
  • Compliance-as-code: jurídico/DPO puede revisar policy YAML directamente.

Schema completo

# policy.yaml
version: "1.0"
metadata:
  name: "Production agent policy"
  owner: "ivan@skillab.co"
  updated: "2026-05-15"
  policy_id: "POL-2026-001"

actions:
  - name: <action_name>
    description: <one-line description>
    trust_dimensions:
      reversibility: <high|medium|low>
      blast_radius: <personal|internal|external>
      auditability: <full|partial|none>
      cost_of_error: <low|medium|high>
      time_sensitivity: <not-sensitive|sensitive|critical>
    total_score: <auto-computed>
    autonomy_level: <auto-computed>
    required_gates:
      - <gate1>
    review_required: <true|false>
    reviewer_role: <role|null>
    audit_retention: <duration>
    notes: <free-form>

Computed fields

total_score es suma de las 5 dimensiones. autonomy_level deriva de total_score:

  • 5-7: Level 1 (autonomous + log)
  • 8-10: Level 2 (assistive, human approve)
  • 11-13: Level 3 (auxiliary, human decide)
  • 14-15: Level 4 (don’t delegate)

Required gates

Lista de gates específicos que el agente precisa cumplir:

  • schema_validation, dry_run, idempotency_check, human_approval, sandbox, confidence_threshold:<N>, audit_log.

Ejemplo 1 — HR Scoring (high-risk)

actions:
  - name: candidate_score
    description: "AI generates 0-100 fit score for job candidate"
    trust_dimensions:
      reversibility: high
      blast_radius: external
      auditability: full
      cost_of_error: high
      time_sensitivity: not-sensitive
    total_score: 12
    autonomy_level: 3
    required_gates:
      - schema_validation
      - human_approval
      - audit_log
      - confidence_threshold:0.7
    review_required: true
    reviewer_role: "recruiting_manager"
    audit_retention: "5y"
    notes: |
      LGPD Art. 20 + LFPDPPP Art. 17 require human review on automated
      decisions affecting individuals. TST Brasil 2025 case reforzó eso.

Ejemplo 2 — Financial Transaction (medium-risk reversible)

actions:
  - name: invoice_classification
    description: "AI categorizes invoice into cost center"
    trust_dimensions:
      reversibility: high
      blast_radius: internal
      auditability: full
      cost_of_error: medium
      time_sensitivity: not-sensitive
    total_score: 8
    autonomy_level: 2
    required_gates:
      - schema_validation
      - confidence_threshold:0.85
      - audit_log
    review_required: false
    reviewer_role: "accountant"
    audit_retention: "5y"

Ejemplo 3 — Content Generation (low-risk, high volume)

actions:
  - name: marketing_copy_draft
    description: "AI generates first draft of marketing copy"
    trust_dimensions:
      reversibility: high
      blast_radius: personal
      auditability: partial
      cost_of_error: low
      time_sensitivity: sensitive
    total_score: 6
    autonomy_level: 1
    required_gates:
      - schema_validation
      - audit_log
    review_required: false
    reviewer_role: null
    audit_retention: "1y"
    sampling_review:
      enabled: true
      rate: 0.1

Cómo el agente lee la policy

import yaml from 'js-yaml';
import { readFileSync } from 'fs';

const policy = yaml.load(readFileSync('policy.yaml', 'utf8'));

async function executeAction(actionName, args) {
  const policyEntry = policy.actions.find(a => a.name === actionName);
  if (!policyEntry) throw new Error(`Action ${actionName} not in policy`);

  for (const gate of policyEntry.required_gates) {
    const passed = await applyGate(gate, args);
    if (!passed) return { rejected: true, reason: `Gate ${gate} failed` };
  }

  if (policyEntry.autonomy_level >= 3) {
    return { pending: true, reason: 'Awaiting human approval' };
  }

  const result = await executeReal(actionName, args);
  await auditLog({ action: actionName, args, result, policy_id: policy.metadata.policy_id });
  return { executed: true, result };
}

Versionamiento de policy

Cambio de policy = PR + review del DPO + log de cambio en el commit. Cada policy version persistida.

Anti-patrones

  1. Policy file gigante y desorganizado. Quebrá en múltiples files por dominio.
  2. Policy editada directo sin PR. Anula la ganancia de versionamiento.
  3. Gates implementados pero no testeados. CI debe tener test para cada gate.
  4. Policy no enforced en el código. Tiene que correr en runtime.

Próximos pasos

  • Codificá 1 action tuya en policy.yaml esta semana. Empezá por la acción de mayor riesgo.
  • Workshop SkilLab — Consultoría & Capacitación. Implementación de Trust Stack as code. Detalles.
  • Newsletter SkilLab AI. Inscribite abajo.

Lee también


Por Ivan Prado · SkilLab AI · Mayo de 2026. Traducido y adaptado del original PT-BR.