Cómo diseñar un control plane on-prem para agentes que preparan operaciones financieras sin entregarles las claves ni la autorización final

Paso 1 — Define un objeto de intención separado de la transacción ejecutable. El agente produce transactionintent con monto, activo, contraparte, propósito, evidencia y referencias, pero no contiene claves ni una firma válida. El schema debe ser determinista y versionado. Validadores revisan formato y datos mínimos antes de pasar a la capa regulada. Esta separación permite usar modelos para interpretar documentos y preparar operaciones sin darles capacidad directa de mover valor. Si el agente comete un error, todavía existe una frontera donde reglas deterministas y humanos pueden bloquearlo. La intención es información; la transacción firmada es autoridad.

Paso 2 — Coloca policy y key custody fuera del runtime del agente. El control plane recibe la intención y aplica límites, allowlists, roles, horarios, segregación de funciones y requisitos de aprobación. Las claves viven en HSM o infraestructura equivalente y nunca se exponen como texto al modelo. El agente puede solicitar una operación, pero la firma solo ocurre cuando policy produce una decisión verificable. Guarda policy version y approvals con cada acción. Este patrón protege tanto contra errores como contra prompt injection o compromiso del agente. La seguridad no depende de que el modelo se niegue; depende de que carezca de la capacidad técnica para saltar el control.

Paso 3 — Usa adapters que preserven semántica entre rieles. Si una organización conecta mensajería ISO 20022, un ledger permissioned y sistemas internos, cada adapter debe mapear campos con reglas explícitas. Conserva identificadores de origen y destino para reconciliación. Valida unidades, moneda, timestamps y estados. Evita que el modelo genere directamente mensajes financieros complejos cuando un transformer determinista puede construirlos desde la intención aprobada. El agente ayuda a interpretar y reunir contexto; el adapter garantiza consistencia protocolaria. Así podemos cambiar red o proveedor sin cambiar la definición de la operación de negocio.

Paso 4 — Diseña reconciliación como parte de la ejecución. Después de enviar una transacción, el sistema vuelve a leer estado en el ledger y en los sistemas tradicionales que correspondan. Define estados intermedios: submitted, acknowledged, pending settlement, settled, failed, compensating. No marques completed por haber recibido un ID inicial. Si dos rieles divergen, activa un workflow de excepción con evidencia y bloquea acciones dependientes cuando sea necesario. En entornos 24/7, esta máquina de estados es crítica porque la capa tokenizada puede moverse mientras la liquidación final sigue otro calendario. La consistencia necesita tiempo y reglas, no fe.

Paso 5 — Emite un transaction receipt auditable. Incluye intentId, policy version, approvals, adapter version, transactionId, timestamps, hashes y estados de reconciliación. No guardes secretos. El receipt debe permitir a auditoría reconstruir qué pidió el agente, qué controles lo permitieron y qué ocurrió realmente. Para acciones rechazadas, conserva la razón sin crear una transacción. Esa evidencia también mejora producto: podemos medir cuántas intenciones son bloqueadas por datos incompletos, límites o riesgo. El objetivo no es hacer el proceso invisible, sino hacer que la automatización produzca mejores rastros que una cadena manual de emails y hojas de cálculo.

Paso 6 — Prueba fallos de control antes de dinero real. Simula claves no disponibles, aprobación tardía, mensajes duplicados, respuestas fuera de orden, caída del ledger y divergencia de estados. Verifica idempotencia y recuperación. Usa entornos sandbox y activos sintéticos hasta que el control plane demuestre invariantes. En Goatify, la propuesta comercial puede ser orquestar documentación, decisiones y seguimiento alrededor de este control plane sin poseer custodia. Esa posición reduce responsabilidad y aumenta utilidad: el agente acelera trabajo cognitivo, mientras la infraestructura del cliente mantiene autoridad. Automatizar finanzas no significa darle una cartera a un modelo; significa conectarlo a un sistema que sabe decir sí, no y todavía no.