Aprobaciones y auditoría

Tus agentes trabajan solos, pero nunca a ciegas. Las acciones con efecto en el mundo real esperan tu visto bueno, unos límites de gasto las frenan de forma automática y todo lo que ocurre queda registrado. La gobernanza human-in-the-loop es lo que te permite delegar sin perder el control.

Un agente puede razonar, buscar y redactar por su cuenta, pero cuando una acción es irreversible o tiene efecto externo, se detiene y la deja en la bandeja de Aprobaciones → Pendientes. Nada se ejecuta hasta que un humano con el rol adecuado dice que sí. Estas son las categorías que siempre pasan por revisión:

• Comunicación externa: enviar un correo, responder a un cliente, publicar en un canal o red social, o cualquier mensaje que salga de tu organización.
• Movimientos de dinero: ordenar un pago, emitir o modificar una factura, aprobar un gasto o una transferencia. Sin excepción.
• Decisiones de RRHH con efecto: aprobar vacaciones (PTO), fin de contrato, bonus o nómina. Las gestiona Maslow pero las confirmas tú.
• Modificación de datos críticos: eliminar clientes, vaciar tablas, cambiar configuración global o tocar registros que no se pueden recuperar.
• Invocación de herramientas sensibles: llamadas a herramientas o API externas que no estén en la allowlist, y operaciones del desktop/server agent fuera de lo marcado como seguro de antemano.

Lo que no requiere aprobación: leer, buscar, resumir, analizar, redactar borradores o preparar propuestas. La velocidad se mantiene para todo lo reversible; el freno solo aparece donde hay consecuencias.

La regla que decide es simple: si la acción cambia algo fuera de SHARA o no se puede deshacer, pasa por ti. Un análisis de ventas se ejecuta solo; el correo que ese análisis propone enviar, no. Amadeus orquesta y delega en los especialistas, pero ninguno de ellos, ni siquiera Amadeus, puede saltarse este control.

Cada solicitud aterriza en la bandeja como una tarjeta de aprobación. El tipo de tarjeta te dice de un vistazo qué clase de acción es y qué información relevante trae. Estos son los principales:

No todas las aprobaciones pesan lo mismo. Cada tarjeta lleva una severidad que ordena tu atención y marca el plazo para decidir. La severidad la determina el tipo de acción y su reversibilidad, no el agente que la pide.

La bandeja ordena por severidad y antigüedad, de modo que lo urgente y caro sube arriba. Una tarjeta de severidad alta que caduca no se ejecuta: se marca como expirada en el registro y el agente tendrá que volver a proponerla si sigue teniendo sentido. Ninguna acción se ejecuta «por defecto» al pasar el plazo; el silencio equivale a un no.

Si dejas más de 24 h una aprobación de severidad media, el administrador recibe un aviso. Los pagos y demás acciones de severidad alta caducan antes (12 h por defecto) y se marcan como expiradas si nadie las atiende.

Cada solicitud muestra qué agente la pide (por ejemplo, Carnegie para una oferta comercial o Graham para un pago), la acción descrita en lenguaje natural, el contexto que la motivó, la severidad y el coste estimado en STU. Decides con dos botones: Aprobar o Rechazar. Quien resuelve deja traza en el registro de auditoría.

Cuando rechazas, puedes (y conviene) dejar un motivo. Ese comentario vuelve al agente y sirve para dos cosas: que no repita el intento a ciegas y que aprenda tu criterio a través de su IDENTITY.md, que evoluciona en parches versionados. Un «no» bien explicado hace que la siguiente propuesta sea mejor.

Para acciones que producen contenido (un correo, un post, la respuesta a un ticket) no solo apruebas o rechazas: ves el resultado propuesto como un diff. Puedes editarlo en línea antes de aceptarlo, de modo que corriges el tono o un dato y Aceptas la versión final, o Rechazas y devuelves el trabajo al agente con tu comentario. La versión que se ejecuta es exactamente la que has visto y validado, no una que el agente cambie después.

La capacidad de aprobar depende del rol de cada persona (los seis roles están en Seguridad). No todo el mundo puede dar el visto bueno a todo: el poder de aprobación se reparte según responsabilidad.

Una aprobación es un acto personal, no automatizable: requiere una credencial ligada a una persona con el permiso adecuado. Un bot o un token de servicio no puede resolver aprobaciones, por diseño. Así, la firma humana de cada acción con efecto queda garantizada, y en el registro aparece siempre quién aprobó, no «el sistema».

Este reparto es coherente con el modelo de permisos: un operador ejecuta trabajo pero no autoriza dinero; un director gobierna su área; el administrador y el CEO tienen la última palabra. Lee los roles completos.

Imagina que pides a Amadeus cerrar la semana de soporte y escribir a los clientes con más incidencias. Carlzon (atención al cliente) resume los tickets (acción reversible: se ejecuta sola) y redacta tres correos de seguimiento. Esos correos no se envían: aparecen en tu bandeja como tres tarjetas de Correo saliente, severidad media.

1. Abres la primera tarjeta: ves destinatario, asunto y cuerpo, con el contexto («cliente con 4 incidencias esta semana»).
2. Corriges una frase del cuerpo en el diff y Aceptas. El correo sale con tu versión.
3. La segunda te parece innecesaria: Rechazas con el motivo «este cliente ya cerró por teléfono». Carlzon lo anota.
4. La tercera la dejas para más tarde; sigue pendiente hasta las 24 h, cuando avisaría al admin.
5. Cada decisión (aceptar, rechazar, editar) queda en el registro de auditoría con tu nombre y el antes/después.

Más allá de tu revisión manual, tres límites de gasto detienen la ejecución sin intervención humana en cuanto se superan. Protegen frente a un bucle inesperado, un prompt malicioso o una tarea mal calibrada. Se miden en euros de consumo real de STU:

Los umbrales son fijos y no se cambian desde el panel. Los cortes de hora y día se levantan solos cuando su ventana baja del umbral; el de ejecución, al cabo de una hora. Un administrador puede levantarlos antes, o dejar una pausa manual que no se levanta sola.

Los kill-switches son defensa, no facturación: cuando saltan, la actividad se detiene y el administrador recibe una alerta. Un run frenado queda en el registro como killswitch_tripped con el umbral que se cruzó, para que puedas revisar qué lo provocó y ajustar el encargo.

Todo queda trazado. Por cada acción se guarda qué agente la ejecutó, qué hizo, el coste en STU, el nivel de modelo (Symphony · Sonata · Prelude · Concerto, siempre por alias), quién aprobó y el estado antes/después de los datos afectados. El registro es append-only e inmutable: ni siquiera el equipo de Shara puede editarlo o borrarlo, y cada registro encadena el hash del anterior, de modo que cualquier manipulación rompe la cadena. Todo se aloja en la UE.

{
  "id": "audit_9f2c…",
  "timestamp": "2026-07-10T09:41:22Z",
  "agent": "Carnegie",
  "action": "email.send",
  "resource": "lead:acme-corp",
  "severity": "medium",
  "status": "approved",
  "approved_by": "user:adrian",
  "cost_stu": 1840,
  "model_alias": "Sonata",
  "before": { "lead_stage": "contactado" },
  "after":  { "lead_stage": "propuesta_enviada" }
}

El registro se consulta con filtros por agente, por tipo de acción, por recurso afectado y por quién aprobó. Y se puede verificar la cadena en cualquier momento: la comprobación recorre los hashes encadenados y devuelve el primer registro que no cuadre, si es que hay alguno.

Qué queda registrado en cada aprobación, en concreto: la solicitud original del agente, la severidad, quién la resolvió y cuándo, si fue aprobación limpia o edición (con el diff aplicado), el motivo del rechazo si lo hubo, y las caducidades por plazo. Es la trazabilidad que te permite demostrar, ante un cliente o una inspección, que cada acción con efecto tuvo una firma humana detrás.

Más contexto sobre las capas de seguridad, los roles, el cifrado del vault y el cumplimiento en Seguridad y cumplimiento.