Modelos de Gobernanza

Resumen

ULedger no impone un modelo de gobernanza. El smart contract define las reglas; el sistema de billeteras y capabilities hace cumplir los principales; la capa de pruebas STARK preserva el registro. Dentro de esas restricciones, cualquier modelo de gobernanza es implementable.

Este documento cataloga cuatro patrones de gobernanza arquetípicos, desde totalmente autónomo hasta totalmente controlado por humanos, y describe cómo se implementa cada uno en ULedger.

---

Patrón 1: Totalmente Autónomo

Descripción: Los agentes actúan sin ninguna aprobación humana en tiempo de ejecución. El contract define las reglas; los agentes operan de forma autónoma dentro de esas reglas. Los humanos configuran el sistema y conservan la capacidad administrativa de anulación (override), pero no participan en las operaciones del día a día.

Cuándo usarlo: Automatización bien comprendida y de bajo riesgo. Pipelines de monitoreo, ingesta de datos, reportes rutinarios, seguimiento de cadena de suministro, registro de sensores IoT.

Estructura:

ORGANIZATION: "acme-corp"
└── SERVICE: "pipeline-service"
    └── Wallet: pipeline-agent (capabilities: data:submit, contract:invoke on pipeline-contract)

Contract: pipeline-contract
    - No human approval required
    - Agent calls logDataPoint(data) autonomously
    - Any wallet can query the recorded data
    - Owner wallet (human) can pause or upgrade the contract

Implementación en ULedger:

• La billetera del agente tiene capabilities limitadas al contract específico y a las acciones de datos.
• El contract no tiene funciones restringidas a humanos; todas las funciones pueden ser llamadas por cualquier agente autorizado.
• La billetera padre humana conserva el poder ALTER_WALLET para deshabilitar al agente en cualquier momento.
• Todas las acciones del agente están on-chain y con pruebas STARK; incluso en modo totalmente autónomo, la pista de auditoría está completa.

Compromiso (trade-off): Máximo rendimiento, mínima latencia. Cero participación humana en tiempo de ejecución. El riesgo está enteramente en la lógica del contract; si el contract tiene un error, el agente ejecutará fielmente el comportamiento defectuoso a escala. Se debe auditar minuciosamente el contract antes de desplegar agentes autónomos.

---

Patrón 2: Human-in-the-Loop

Descripción: Los agentes preparan, proponen o calculan, pero un humano debe aprobar explícitamente antes de que se finalice cualquier acción consecuente. La aprobación del humano es en sí misma una transaction firmada.

Cuándo usarlo: Decisiones de alto riesgo: transacciones financieras por encima de un umbral, publicación de contenido, comunicaciones externas, registros médicos, acciones legales.

Estructura:

PERSONAL: "alice"
├── Wallet: alice-wallet (human, holds private key)
└── AGENT: "alice-research-agent"
    └── Wallet: agent-wallet (capabilities: contract:invoke on research-contract, data:submit)

Contract: research-contract
    - proposeAction(data, analysis) → agent submits proposal, sets status = "pending"
    - approveAction(proposalId) → owner-only, executes the action, sets status = "approved"
    - rejectAction(proposalId) → owner-only, cancels, sets status = "rejected"
    - getProposalStatus(proposalId) → any caller

Implementación en ULedger:

• La billetera del agente solo puede llamar a proposeAction; su capability está limitada al selector de esa función o al contract en general, pero el contract hace cumplir internamente la restricción humana.
• La billetera de Alice es la propietaria del contract. Solo ella puede llamar a approveAction o rejectAction.
• Cada propuesta y cada aprobación/rechazo es una transaction firmada; el rastro completo de decisiones está on-chain.

Compromiso (trade-off): Mayor latencia (el humano debe actuar), pero el criterio humano se inyecta en el punto crítico de decisión. El agente realiza el trabajo computacional; el humano asume la responsabilidad del resultado.

---

Patrón 3: Council Híbrido

Descripción: Un grupo de principales humanos (el council) delega cada uno en un agente votante. Los agentes votan de forma autónoma dentro de la ventana de votación. El presidente del council (o cualquier billetera autorizada) finaliza la decisión una vez cerrada la ventana. Los humanos conservan poder de veto al abstenerse de finalizar, o al votar directamente.

Cuándo usarlo: Gobernanza organizacional donde múltiples partes interesadas deben estar de acuerdo, pero la participación asíncrona es aceptable: decisiones de junta directiva, paneles de revisión de investigación, acuerdos de consorcio, aprobaciones de contracts entre múltiples partes.

Estructura:

ORGANIZATION: "council-org"
│
├── PERSONAL: "alice" (council chair)
│   └── Wallet: alice-wallet (contract owner)
│
├── PERSONAL: "bob" (council member)
│   ├── Wallet: bob-wallet (human, addMember caller)
│   └── AGENT: "bob-director"
│       └── Wallet: bob-agent (capabilities: contract:invoke on council-contract)
│
├── PERSONAL: "charlie" (council member)
│   └── AGENT: "charlie-director"
│       └── Wallet: charlie-agent
│
...

Contract: council-contract (council-voting.wat)
    - addMember(memberAddr) → owner only
    - authorizeAgent(agentAddr) → member only
    - createProposal(...) → member only
    - issueWorkToken(agentAddr, proposalId) → member only
    - submitWork(proposalId, vote, evidence) → agent only (work token required)
    - finalizeProposal(proposalId) → any caller, after deadline

Implementación en ULedger: Se puede consultar el Ejemplo de Board Council para el recorrido completo.

Compromiso (trade-off): Combina la votación autónoma de agentes con supervisión humana. Los agentes pueden votar según razonamiento de IA sin esperar a los humanos, pero los humanos pueden participar directamente si lo desean. La finalización está condicionada por la fecha límite (altura de bloque), no por una acción humana, pero un presidente humano puede retrasar la finalización al no enviarla, actuando como un veto implícito.

Variaciones de gobernanza dentro de este patrón:

• Supermayoría: se establece quorum en ceil(2/3 * memberCount): requiere un acuerdo sólido.
• Unánime: se establece quorum en memberCount: todos los agentes deben votar a favor.
• Votación ponderada: se implementan los pesos de voto en el storage del contract (no en el contract base council-voting, pero es extensible).
• Anulación humana (override): se agrega una función emergencyVeto(proposalId) que solo pueda llamar una billetera humana designada, estableciendo el estado en "vetoed" independientemente del recuento de votos.

---

Patrón 4: Agentic Mesh (Totalmente Agente-a-Agente)

Descripción: No hay ningún humano en el ciclo en tiempo de ejecución. Múltiples agentes interactúan: algunos proponen, otros revisan, otros aprueban y otros ejecutan. Las reglas de gobernanza están enteramente en el código del contract. Los humanos definen las reglas y mantienen la anulación administrativa, pero las operaciones del día a día no requieren ninguna acción humana.

Cuándo usarlo: Sistemas automatizados de alto rendimiento donde múltiples modelos de IA deben coordinarse: pipelines de investigación multiagente, operaciones de mercado automatizadas, redes IoT con consensus local, gestión autónoma de la cadena de suministro.

Estructura:

ORGANIZATION: "autonomous-org"
│   Owner: admin-wallet (human, administrative)
│
├── SERVICE: "orchestrator-service"
│   └── Wallet: orchestrator-wallet (capabilities: contract:invoke on workflow-contract)
│
├── SERVICE: "reviewer-service-a"
│   └── Wallet: reviewer-a-wallet (capabilities: contract:invoke on workflow-contract)
│
├── SERVICE: "reviewer-service-b"
│   └── Wallet: reviewer-b-wallet (capabilities: contract:invoke on workflow-contract)
│
└── SERVICE: "executor-service"
    └── Wallet: executor-wallet (capabilities: contract:invoke on workflow-contract, token:transfer)

Contract: workflow-contract
    - submitWork(data) → orchestrator submits a work item
    - review(workId, approved) → reviewer approves or rejects
    - execute(workId) → executor finalizes if quorum of reviewers approved
    - escalate(workId) → any service can escalate to the human admin's on-chain address

Implementación en ULedger:

• Todas las billeteras son entities de tipo SERVICE con capabilities limitadas.
• La billetera de administrador (en poder de un humano) no tiene un rol en tiempo de ejecución, pero conserva el poder ALTER_WALLET para deshabilitar cualquier servicio.
• El contract hace cumplir las reglas de coordinación multiagente.
• Todas las interacciones entre agentes están on-chain y con pruebas STARK; se preserva la pista de auditoría completa de cada interacción agente-a-agente.

Compromiso (trade-off): Máxima autonomía y rendimiento. La pista de auditoría está completa independientemente del nivel de autonomía; esto no es un compromiso con ULedger, solo con el modelo de gobernanza. El riesgo está enteramente en la lógica del contract y en las implementaciones de los agentes. La única palanca del administrador humano en tiempo de ejecución es el cascade disable de billeteras.

---

Elección de un Modelo de Gobernanza

Pregunta	Implicación
¿Cuál es el costo de una decisión equivocada?	Costo alto → human-in-the-loop. Costo bajo y alto volumen → autónomo.
¿Qué tan rápido deben tomarse las decisiones?	Menos de un segundo → autónomo. De minutos a horas → council híbrido. Días → human-in-the-loop.
¿Cuántos principales deben estar de acuerdo?	Uno → billetera única. Varios → patrón council.
¿Se puede confiar en que los agentes tomen decisiones en los casos extremos?	Sí → totalmente autónomo. No → requerir finalización humana.
¿Se requiere auditabilidad regulatoria?	ULedger la proporciona en todos los patrones; el modelo no afecta la pista de auditoría.
¿Cuál es el modo de fallo ante un error del agente?	Reversible → autónomo. Irreversible → requerir aprobación humana.

---

Combinación de Modelos

Los modelos de gobernanza pueden combinarse dentro de un mismo despliegue. Un solo contract puede tener:

• Funciones rutinarias de bajo riesgo que cualquier agente autorizado puede llamar.
• Funciones de alto valor que requieren una firma humana.
• Funciones de emergencia restringidas al propietario del contract.
• Funciones con restricción temporal que solo están disponibles después de una fecha límite.

El código del contract es la política de gobernanza. Se recomienda diseñarlo para que se ajuste al perfil de riesgo de cada función, no solo del sistema en su conjunto.