Marco DPI-IA · Elemento 02

DPI Workflows

La capa de orquestación — recetas estructuradas y auditables que coordinan AI Blocks, sistemas DPI y supervisión humana en servicios públicos coherentes.

La Capa de Orquestación

Los Workflows son recetas — los AI Blocks son ingredientes

Un DPI Workflow define la secuencia, condiciones, flujos de datos y salvaguardas que gobiernan cómo se presta un servicio. La IA opera dentro del flujo de trabajo — nunca fuera de él. El flujo de trabajo es la única fuente de verdad para cualquier interacción de servicio.

El principio clave: Ninguna salida de IA modifica directamente registros autoritativos sin pasar por un paso de gobernanza en el flujo de trabajo. ¿Confianza por debajo del umbral? Se enruta a revisión humana. ¿Excepción detectada? Se escala al gestor de casos. El flujo de trabajo codifica la responsabilidad.

Lo que conecta un DPI Workflow

1

Public Agent

Recibe la intención del ciudadano, inicia la invocación del flujo de trabajo con token de consentimiento

2

DPI: Verificación de identidad

identity.verify(citizen_id) — autenticado contra el sistema de identidad nacional

3

AI Block: Elegibilidad

ai.eligibility_verify() — devuelve elegible + puntaje de confianza

⚠ si confianza < 0.85 → human_escalate()

4

DPI: Intercambio de datos

data_exchange.get_social_record() — extracción de datos con consentimiento del registro

5

DPI: Desembolso

payments.disburse() — pago del beneficio a través del canal gubernamental

Registro de auditoría

Cada paso registrado de forma inmutable — quién, qué, cuándo, con qué nivel de confianza

Por qué los workflows son activos reutilizables

Un flujo de trabajo que encadena la verificación de identidad, la determinación de elegibilidad y los pagos no es solo un servicio — también es una receta compartible.

Publicados en repositorios abiertos, estos flujos de trabajo pueden ser adaptados y reutilizados por otros gobiernos, igual que el código de fuente abierta o las aplicaciones en contenedores. Los países pueden tomar prestado los manuales de otros, instalarlos con un mínimo esfuerzo y adaptarlos a las políticas locales.

Así es como el modelo DPI se extiende a la IA: no como configuración de sistemas de caja negra, sino como código con gobernanza integrada que puede inspeccionarse, auditarse y evolucionar.

→ Ver cómo implementar workflows con OpenFn, n8n o YAML

Plantilla YAML

Plantilla genérica de DPI Workflow

Una plantilla YAML completamente anotada para un flujo de trabajo de desembolso de beneficios de protección social. Adapta los pasos, bloques y reglas de gobernanza a cualquier sector.

# Generic DPI Workflow Template — DPI-AI Framework workflow: id: "benefit_disbursement_v1" version: "0.1.0" description: "Social protection benefit eligibility check and payment disbursement" domain: "social_protection" governance: owner_agency: "<Ministry of Social Welfare>" legal_basis: "<Social Protection Act § 12.3>" audit_logging: true human_oversight: required: true escalation_to: "caseworker_supervisor" retention_policy: "5y" accountability_note: "Public Agents orchestrate steps; institutional authority remains with government." actors: public_agent: id: "social_benefit_agent_v1" channels: ["whatsapp", "ussd", "voice"] languages: ["sw", "en", "am"] human_agent: id: "caseworker" role: "Benefit Caseworker" steps: - id: identity_verify type: dpi_block block: identity.verify inputs: identifier: "{{requester.identifier}}" consent_token: "{{requester.consent_token}}" on_fail: escalate_to_human on_success: eligibility_check - id: eligibility_check type: ai_block block: ai.eligibility_verify_v1 inputs: citizen_id: "{{steps.identity_verify.output.verified_id}}" benefit_code: "{{request.benefit_code}}" consent_token: "{{requester.consent_token}}" confidence_threshold: 0.85 on_low_confidence: human_review on_high_confidence: data_pull on_fail: escalate_to_human - id: human_review type: human_task assign_to: caseworker timeout: "48h" inputs: case_data: "{{steps.eligibility_check.output}}" on_approve: data_pull on_reject: notify_rejection - id: data_pull type: dpi_block block: data_exchange.get_social_record inputs: citizen_id: "{{steps.identity_verify.output.verified_id}}" consent_token: "{{requester.consent_token}}" purpose: "benefit_disbursement" - id: disburse type: dpi_block block: payments.disburse condition: "{{steps.eligibility_check.output.eligible == true}}" inputs: recipient_id: "{{steps.identity_verify.output.verified_id}}" amount: "{{benefit.amount}}" payment_ref: "{{workflow.id}}-{{run.id}}" - id: notify type: action channel: "{{requester.preferred_channel}}" message_template: "benefit_disbursement_confirmation" audit: log_all_steps: true pii_redaction: true immutable: true
Formatos de Implementación

Tres formas de expresar un DPI Workflow

Un flujo de trabajo es una decisión de diseño — no un formato de archivo. La misma lógica de servicio puede expresarse como una especificación YAML portátil, desplegarse en un motor sin código o empaquetarse como una habilidad invocable para un agente de IA. Los equipos eligen el formato que corresponde a su capacidad técnica y arquitectura de agentes.

📄
Formato 01

Especificación YAML

La definición canónica, independiente del motor. Declara pasos, AI Blocks, dependencias DPI, umbrales de confianza, rutas de escalada humana y configuraciones de gobernanza. Legible por personas y procesable por cualquier motor de flujo de trabajo o entorno de ejecución de agentes.

workflow_id: BENEFIT_CHECK_v1
steps: [identity_verify, eligibility_check,
  human_review, disburse]
Ideal para: documentación, intercambio entre equipos, alimentar cualquier motor o herramienta de agente
🔌
Formato 02

Motor de Workflow sin Código

Despliega la especificación YAML en un motor de flujo de trabajo visual. OpenFn (nativo para DPGs, con servidor MCP desde junio de 2025), n8n (más de 400 integraciones) o Prefect. Los equipos de política pueden inspeccionar y ajustar la lógica de cada paso sin escribir código. Los cambios están versionados y son auditables.

openfn deploy --project BENEFIT_CHECK
# o importar el YAML en la UI de n8n
Ideal para: equipos sin gran capacidad de ingeniería, iteración rápida, monitoreo operativo
🤖
Formato 03 · Emergente

Habilidad de Agente

Empaqueta el flujo de trabajo como una herramienta invocable — una función tipada que un Public Agent (LLM) puede invocar directamente mediante llamadas a funciones, el Protocolo de Contexto del Modelo (MCP), o un registro de habilidades. El agente no ve los pasos internos — llama al flujo de trabajo por nombre y recibe un resultado estructurado.

// Como herramienta MCP:
tools: [{ name: "check_eligibility",
  description: "Verify citizen eligibility
  for a benefit program via DPI",
  inputSchema: { national_id, program_id }}]
Ideal para: arquitecturas agénticas donde el Public Agent decide qué flujo de trabajo invocar, orquestación de múltiples servicios, despliegues nativos de MCP
Nota de gobernanza: Los pasos de salvaguarda del flujo de trabajo (consentimiento, revisión humana, registro de auditoría) se ejecutan dentro de la habilidad — el agente que la invoca no puede omitirlos.
Patrones de Diseño

Patrones para construir flujos de trabajo gobernables

Patrón 01

Umbrales de confianza sobre decisiones rígidas

Cada salida de un AI Block incluye un puntaje de confianza. Por debajo del umbral: revisión humana. Por encima del umbral: continuar. El umbral es un parámetro de gobernanza, no una constante técnica.

Patrón 02

Escalada humana como paso de primera clase

Las rutas de escalada se diseñan dentro del flujo de trabajo, no se añaden como manejadores de excepciones. La revisión humana es un paso del flujo — con tiempo límite, responsable asignado y trazabilidad de auditoría.

Patrón 03

Compartir workflows como plantillas

Cada flujo de trabajo puede publicarse como plantilla abierta. Los países adaptan los parámetros de política; la lógica de orquestación se reutiliza. Así es como la DPI se escala hacia la IA.

Patrón 04

El consentimiento es un paso invocable

El consentimiento del ciudadano no es una casilla estática — es una función invocable y auditable en el flujo de trabajo. Se verifica antes de cualquier acceso a datos, y su alcance define lo que el flujo de trabajo puede hacer.

Patrón 05

Inclusión integrada en el flujo de trabajo

Las interfaces con voz como canal principal, la traducción multilingüe y el respaldo por USSD están orquestados como pasos, no como complementos. El flujo de trabajo decide el canal y el idioma según el contexto del ciudadano.

Patrón 06

La IA opera dentro de la gobernanza

El flujo de trabajo es el locus de control. Los AI Blocks se invocan desde dentro del flujo de trabajo — no pueden saltarse los pasos de gobernanza, modificar registros directamente ni actuar fuera del alcance definido.

→ Ver la guía completa de implementación — spec YAML, motores sin código y despliegue como habilidad de agente

Elementos Relacionados

Los Workflows son el tejido conectivo

Los Workflows invocan AI Blocks y son invocados por Public Agents. Son la capa de orquestación que hace funcionar el marco como un sistema.

← 01 AI Blocks 02 DPI Workflows 03 Public Agents → Guía de Implementación → Probar el Sandbox →