Un servicio público no es un formulario colocado sobre la base de datos de una institución. Es un expediente de larga duración y múltiples canales que acredita identidad, reutiliza datos autorizados, reúne evidencias, coordina organismos, recibe pagos, muestra estado, notifica, admite recursos y conserva trazabilidad.
El portal es solo un canal. El servicio vive en web, app, ventanilla asistida, teléfono, kiosco, mensajería, herramientas internas y sistemas institucionales. Comience por el resultado ciudadano y el procedimiento legal: quién puede solicitar, qué evidencia se exige, quién resuelve, qué plazos rigen, cómo se paga, qué estado puede mostrarse y cómo subsanar o apelar.
La persona necesita una referencia pública y una línea de tiempo aunque participen cinco instituciones. Internamente conserve identificadores de cada organismo y correlation IDs, pero no exponga la integración como cinco trámites desconectados. El expediente reúne versión del servicio, solicitante, representación, manifiesto de evidencias, decisiones, pagos, plazos, comunicaciones y auditoría.
ClaveÚnica y Login Único gov.br muestran cómo centralizar autenticación. El servicio todavía decide si la persona puede actuar, qué nivel de confianza necesita y si representa a un menor, empresa, sucesión o tercero. El ID token identifica la sesión; la API recibe un access token apropiado. RFC 9700, redirect URI exacta, PKCE, tokens breves, scopes mínimos, rotación de claves y ambientes separados son baseline.
PIDE y Conecta GOV.BR buscan que la ciudadanía no vuelva a presentar información que el Estado ya posee. No significa copiar todos los registros a un data lake. Consulte la fuente competente para una finalidad declarada, devuelva los campos mínimos, preserve origen y vigencia, separe hechos de inferencias, registre base jurídica y permita corregir datos erróneos.
Modele preguntas, validaciones, secciones condicionales, evidencias, ayuda, idioma y accesibilidad como schemas versionados. Guarde borradores sin exigir máxima confianza demasiado pronto. Soporte conexiones lentas, cargas reanudables, teclado, lector de pantalla, errores claros, asistencia humana y alternativas imprimibles u offline. Un rediseño no debe volver ilegibles expedientes antiguos.
No exponga estados internos como QUEUE_17_RETRY. Traduzca el workflow a vocabulario estable con última actualización, siguiente paso, organismo responsable, plazo y acción ciudadana. Cada transición guarda actor, timestamp, motivo, estado anterior, nuevo estado y evidencia.
Cree una obligación ligada al expediente, monto, regla de tasa, pagador, vencimiento e idempotency key. El éxito del redirect no demuestra liquidación. Procese callbacks firmados, consulte cuando corresponda, concilie extractos, emita recibos, gestione exenciones/reembolsos y evite que un callback duplicado genere dos documentos.
Correo, SMS, push, WhatsApp y casilla digital pueden fallar o ser vistos por otra persona. El mensaje incluye pocos datos sensibles y enlaza al estado autenticado. Registre plantilla, versión, canal, destino tokenizado, envío, resultado, entrega, idioma, preferencia de accesibilidad y evento disparador.
OpenAPI describe endpoints, pero no resuelve el significado institucional. Defina identificadores, semántica, organismo responsable, finalidad, lifecycle del schema, errores, límites, soporte, sandbox, deprecación y avisos. Los adapters aíslan SOAP, archivos, colas y sistemas propietarios del contrato ciudadano.
| Capacidad | Registro oficial | Contrato API | Comportamiento ante falla | Evidencia de auditoría |
|---|---|---|---|---|
| Identidad digital | Proveedor de identidad más autorización del servicio. | OIDC/OAuth, claims, scopes, nivel y representación. | Conservar borrador y ofrecer canal asistido. | Evento, confianza, consentimiento y metadatos. |
| Consulta registral | Registro de la institución competente. | Finalidad, respuesta mínima, vigencia y procedencia. | Reintentar o pedir evidencia; nunca inventar ausencia. | Solicitante, propósito, campos, versión y hash. |
| Solicitud | Servicio de expedientes y schema del formulario. | Borrador, presentación, ajuste, carga, validación y retiro. | Retry idempotente y carga reanudable. | Snapshot, declaraciones, firma y timestamps. |
| Pago | Ledger de tesorería/proveedor. | Intent, callback, liquidación, recibo, devolución y conciliación. | Mantener pendiente hasta confirmación financiera. | IDs, monto, transiciones y lote. |
| Resolución | Acto autorizado del organismo. | Motivos, documento, vigencia, condiciones y recurso. | Escalar vencimiento o conflicto. | Actor, autoridad, norma y evidencias. |
| Notificación | El estado del expediente sigue siendo oficial. | Evento, preferencia, envío y comprobante de entrega. | Retry por política y cambio autorizado de canal. | Plantilla, disparador, destino y recibos. |
Separe historia de negocio, telemetría de seguridad, gestión documental y analítica. Use transiciones append-only, almacenamiento resistente a alteraciones cuando aplique, relojes sincronizados, identidad del actor, finalidad, procedencia, motivo, versión normativa y correlation IDs. Consultar un expediente también deja trazabilidad.
Los sistemas institucionales estarán fuera de servicio. Use colas durables, timeouts, circuit breakers, idempotencia, replay, dead-letter con revisión, caché con antigüedad explícita y estado visible “esperando institución”. Conserve borradores localmente y en servidor. Un timeout downstream no puede convertirse en rechazo ni obligar a comenzar de nuevo.
WCAG 2.2 es el punto de partida. Pruebe tecnologías de asistencia y personas reales, considere idioma y alfabetización regional, evite expiraciones arbitrarias, permita guardar y retomar, explique el avance y atribuya toda asistencia a un agente identificado. La ventanilla debe usar las mismas APIs y estados, no un proceso paralelo.
Mida descubrimiento a inicio, borradores completados, errores, evidencias rechazadas, uso asistido, demora de conciliación, cola institucional, finalización integral, plazos vencidos, entrega de mensajes, recursos, defectos de accesibilidad, contactos repetidos y costo por resultado. Segmente por territorio, dispositivo, conectividad, idioma y canal.
Una plataforma compartida con adapters de identidad y representación, catálogo de servicios, formularios por schema, almacenamiento de evidencias, máquina de estados, orquestación, gateway de interoperabilidad, adapter financiero, documentos/firma, API de estado, hub de notificaciones, stream de auditoría, pruebas de accesibilidad, consola de soporte y modelo analítico. Las instituciones poseen la política y resolución; la plataforma, los contratos y la confiabilidad.
Un buen GovTech oculta la fragmentación institucional sin ocultar la responsabilidad. La persona debe comprender qué necesita el Estado, qué información ya posee, quién actúa, qué sigue, cuánto debería demorar, qué se resolvió y cómo subsanar o apelar.
Artículo sobre servicios públicos digitales y APIs GovTech en América Latina, identidad, formularios, evidencias, pagos, estado, notificaciones, interoperabilidad, accesibilidad y auditoría.