Español
English
Proyecto Carpeta Ciudadana
La Carpeta Ciudadana es el espacio digital oficial donde cada persona puede acceder, consultar y gestionar de forma segura sus datos y credenciales públicas.
No almacena duplicados de bases de datos, sino que conecta directamente con las fuentes oficiales (como registro civil, educación, salud, trabajo, seguridad social, impuestos, tránsito o vivienda) mediante contratos ENI, garantizando auditoría y trazabilidad en cada consulta.
Su diseño está basado en momentos de vida como nacer, estudiar, trabajar, emprender o retirarse, para ofrecer una experiencia más útil, ordenada y enfocada en las necesidades reales del ciudadano.
Este proyecto es desarrollado por el Laboratorio de Innovación Digital (LID) y el Departamento de Arquitectura Digital Gubernamental, como parte esencial de la Infraestructura Digital Pública (DPI).
Marco y alineación: sustentado por la Política Nacional de Interoperabilidad, las normas NORTIC, y los estándares de accesibilidad SDD/WCAG 2.1.
Colaboración interinstitucional:
Cada entidad es la fuente oficial de los datos que administra (por ejemplo: actas, historial académico, afiliaciones o licencias).
La interoperabilidad, mediante la ENI, garantiza un intercambio seguro y trazable de información, aplicando el principio de “solo una vez”.
La gobernanza del sistema establece responsabilidades claras sobre actualización, corrección y disponibilidad de datos, con métricas públicas de desempeño.
Descargas móviles
+255kDescargas totales de las tiendas Apple y Android
Usuarios activos por día
+16kDesde febrero 2025
Instituciones conectadas
14Con servicios de datos en producción
¿Qué resuelve?
¿Qué resuelve?
Un solo portal de becas sobre la DPI: una cuenta, datos verificados entre instituciones y seguimiento en tiempo real—menos papeles, decisiones más rápidas.
- Información dispersa y duplicada: datos y documentos oficiales repartidos entre múltiples portales; el ciudadano vuelve a cargar lo que ya existe.
- Poca visibilidad y control: estados de trámites poco claros, sin trazabilidad ni registro de accesos; consentimiento difuso.
- Interacciones fragmentadas: cada institución pide requisitos por su lado; no existe continuidad entre web, 311/462 y Puntos GOB.
- Sin enfoque de “momentos de vida”: la información no se organiza según hitos relevantes (nacer, estudiar, trabajar, emprender, etc.).
La solución se construyó en cadena y de forma multinstitucional: cada entidad aporta su fuente oficial (según su competencia) para organizar la información por momentos de vida y ofrecer a la ciudadanía acceso directo y continuado a sus datos. Aplicamos principios DPI-by-default –fuente única de verdad, “solo una vez”, privacidad por diseño– y un trabajo de entrega con MVP → piloto → operación con SLAs, métricas continuas (KPIs) y mejora iterativa. A continuación se detalla, paso a paso, cómo llegamos a esta solución.
- Diagnóstico del problema: Mapeamos la experiencia ciudadana e institucional y hallamos cuatro ineficiencias: datos dispersos, repetición de requisitos entre entidades, poca visibilidad del estado de trámites y ausencia de consentimiento unificado.
- Hipótesis de valor político: Si aplicábamos principios de DPI – fuente única de verdad, “solo una vez”, privacidad por diseño y contextualización – podríamos reducir pasos, errores y tiempos, manteniendo trazabilidad y control ciudadano.
- Priorización por impacto: Seleccionamos “momentos de vida” y casos de alto volumen (p. ej., educación, seguridad social) y definimos KPIs (documentos no solicitados, tiempo a resolución, % continuidad omnicanal, NPS/CSAT y quejas/atención).
- Decisiones de arquitectura DPI-by-default: Adoptamos building blocks y estándares existentes: CUC/SGO para una sola cuenta, interoperabilidad (ENI) para consultar fuentes maestras, Notificaciones para avisos, Credenciales Verificables/Firma para constancias, SDD/WCAG para UI accesible y OCI/Cloud para operación y SLAs.
- Diseño por contrato (ENI) y gobernanza: Definimos contratos OpenAPI con minimización de datos, flujos de consentimiento por instrucción titular. Acordamos bitácoras firmadas y selladas y políticas de versión/deprecación.
- Modelo de consentimiento: Establecimos consentimiento granular y revocable (qué, con quién, por cuánto tiempo), registro de accesos y evidencias de uso conforme a NORTIC y la Política Nacional de Interoperabilidad.
- MVP en sandbox: Construimos un MVP: autenticación, sincronización de datos oficiales, visualización, compartir con consentimiento y notificaciones. Probamos seguridad (mTLS/OWASP), carga, accesibilidad (WCAG 2.1) subsidiada.
- Piloto Interinstitucional: Integramos 2-3 fuentes maestras (p. ej., registro civil, académico y seguridad social). Ejecutamos formación operativa y soporte; y medimos KPIs (documentos evitados, tiempos, errores por millón y satisfacción).
- Aprendizaje y escalamiento: Rectificamos flujos, afinamos contratos ENI y políticas de notificación. Pasamos a producción con SLAs 24/7, tableros de observabilidad, plan de continuidad/DR y publicación en GOB.XX cuando aplica.
- Expansión por “momentos de vida”: Planificamos la incorporación progresiva de nuevas fuentes oficiales y VCs (educación, trabajo, movilidad, vivienda, salud), manteniendo los estándares (NORTIC, SDD, ENI) y la cogobernanza LID – Arquitectura Gubernamental con las Instituciones titulares del dato.
Ciudadanía: personas que requieren acceso directo a sus datos, menos papeles, estados claros y control de consentimiento, organizados por momentos de vida.
Instituciones titulares del dato: ministerios, entes reguladoras y organismos que aportan su dato oficial vía ENI, ganan trazabilidad, métricas y menor reclamos/tedio.
Operación pública (equipos de servicio): atención en Puntos GOB y Centro de Contacto (311/462) con continuidad, reducción de tiempos y evidencia auditable.