Pilar 3 — Gobernanza y Democracia
La tesis. Poner los resultados de los modelos al servicio de la gobernanza democrática y de los reguladores de la región: observatorios citados de resiliencia democrática y regulación, monitoreo de elecciones y transparencia, inteligencia situacional verificable, cada cifra con su fuente, cada alerta auditable. La región regula desde sus propias tradiciones legales, no con plantillas de EE. UU. o la UE.
Infraestructura de decisión institucional. Visto como infraestructura, este pilar toma indicadores verificables (el Índice de Resiliencia Democrática, la capa de libertades del observatorio, el Índice de Cobertura Regulatoria) y los convierte en insumos para decidir: alertas auditables, feeds legibles por máquina, un tablero de calibración de pronósticos y un registro público de correcciones. La cadena es indicadores → decisiones, con cada eslabón trazable. Una precisión de honestidad: hoy "resultados verificables" significa procedencia verificable, cada cifra remonta a su fuente; el historial demostrado de pronósticos acertados y correcciones publicadas todavía está por acumularse, y las dos superficies que lo harán visible (el tablero de calibración y el registro de correcciones) ya están en vivo, empezando desde cero.
Es el tercer pilar del ciclo: consume la capa de inteligencia y frontera (2 → 3), y las instituciones que dependen de esos resultados se vuelven contribuyentes del fideicomiso (3 → 1).
Desde las tradiciones legales de la región, no plantillas importadas
El principio rector del pilar es un rechazo explícito: no se toma un marco de gobernanza de IA de EE. UU. o la UE y se le renombra. Se parte de las tradiciones legales latinoamericanas, las realidades de la economía informal y los marcos constitucionales de la región. Un observatorio de regulación que mide a la región contra una plantilla europea mide la cosa equivocada; el diseño empieza desde el derecho de la región hacia afuera.
Las superficies en vivo
Observatorio de Resiliencia Democrática
/gobernanza/observatorio: el Índice de Resiliencia Democrática, un compuesto citado de tres sub-índices (estado de derecho, transparencia y anticorrupción, integridad democrática) construidos sobre WGI, V-Dem, WJP, IDEA GSoD, BTI, TI-CPI y OWID, con normalización goalpost (p5–p95), pesos iguales y relleno de brechas documentado. Más allá del ranking, el observatorio ofrece cinco vistas: ranking, retrocesos (backsliding), deriva autoritaria, libertad (ranking de libertad económica sobre el índice de la Heritage Foundation; el detalle por país añade capas de libertad humana, de prensa y digital, cada una con su propia fuente) y un explorador. Cada componente del índice se remonta a su fuente; la construcción del compuesto, los pesos y los supuestos se documentan en su página de metodología. No es un ranking opaco: es un índice cuya receta está a la vista y cuyas cifras se pueden auditar una por una.
Cómo se construye el índice
El compuesto se precalcula con scripts/build-democracy-index.ts (bun run) y se sirve estático desde public/data/democracy/resilience.json; la página lo lee, no lo recalcula.
Los goalposts se calculan sobre el pool regional completo, el outlier de un país no define la escala de nadie. Composición de los sub-índices (19 indicadores esperados por país):
| Sub-índice | Indicadores | Fuentes |
|---|---|---|
estado_derecho | 10 — wjp_rol_overall, factores 1 y 8 de WJP, vdem_rule_of_law, vdem_liberal_democracy, rl_est, ge_est, rq_est, idea_gsod_rule_law, bti_governance_index | WJP, V-Dem, WGI, IDEA GSoD, BTI |
anticorrupcion | 3 — ticpi_score, cc_est, owid_corruption_vdem | TI-CPI, WGI, OWID/V-Dem |
integridad_democratica | 6 — vdem_electoral_democracy, idea_gsod_representation, idea_gsod_rights, va_est, owid_political_regime, bti_democracy_status | V-Dem, IDEA GSoD, WGI, OWID, BTI |
Invariantes del script (todas verificables en el código):
| Regla | Valor exacto |
|---|---|
| Ventana temporal | 2010–2025 (YEAR_MIN/YEAR_MAX) |
| Relleno por año | valueAt lleva la observación más cercana anterior al año; si no hay ninguna, back-fill desde la más temprana |
| Trayectoria | Δ5a ≥ +2 → mejora; ≤ −2 → retroceso; si no, estable |
| Confianza | observados/esperados ≥ 0,85 → alta; ≥ 0,6 → media; menos → baja |
| Cachés en cuarentena | se leen como vacíos — nunca alimentan el índice |
| Restricción vinculante | el sub-índice de menor puntaje (la prioridad de reforma) |
| Auditabilidad | cada entrada de contributing[] lleva citation_id → registro de fuente en citations.json |
La cobertura 25/25 está garantizada por diseño: Cuba (sin WJP) o Surinam (V-Dem/BTI delgados) aparecen con confianza media/baja en vez de desaparecer del ranking. El tablero de retrocesos ordena los países por caída del compuesto a 5 años y, para cada uno, identifica el indicador individual con la caída normalizada más pronunciada en ~5 años (el worst_indicator, con su cita). Corte de julio de 2026 del archivo precalculado: 25/25 puntuados, mediana regional 51,9, mejor Uruguay, peor Venezuela, 12 países en retroceso y 4 en mejora.
Observatorio de regulación
/gobernanza/regulacion: el rastreador de regulación de los 10 ejes en los 25 países: 2.283 instrumentos legales (precálculo del 14 de octubre de 2026; leyes, decretos, marcos), de los cuales 2.120 verificados y 163 marcados synthetic: el conteo crece con cada ingesta, extraídos hoy de seis catálogos conectados: Constitute y Climate Change Laws of the World como fuentes externas, más el catálogo legal curado de Futuros (verificado en la web) y tres rastreadores internos del proyecto. El registro de fuentes lista 18 catálogos en total; NATLEX, ECOLEX, FAOLEX, WIPO Lex y SHERLOC ya están cableados en src/lib/source-registry.ts (cite-only, con deep link al catálogo) y pendientes de ingesta al catálogo precalculado; Digital Policy Alert y OECD.AI siguen registrados y pendientes. Una vista de exploración de instrumentos en /gobernanza/regulacion/instrumentos busca y filtra el índice plano public/data/regulation/_instruments.json (país, eje, tipo, estado, texto libre). El Índice de Cobertura Regulatoria (ICR) tiene fórmula pública (0,45·amplitud + 0,30·vigencia + 0,25·actualidad) y se calcula solo sobre instrumentos verificados: los registros sintéticos provenientes de trackers internos del proyecto van marcados (synthetic: true) y quedan excluidos del índice. Una capa temporal muestra cómo evoluciona la cobertura en el tiempo. Los instrumentos verificados van citados a su fuente, de modo que un regulador puede ver qué existe y de dónde viene la afirmación de que existe.
La fórmula del ICR, componente por componente
El ICR se calcula en scripts/bake-regulation.ts y se publica en public/data/regulation/_analytics.json: la fórmula que muestra la página es la misma que corre el código:
| Componente | Peso | Definición operativa |
|---|---|---|
| Amplitud | 0,45 | pilares con ≥ 1 instrumento registrado / 10 × 100 |
| Vigencia | 0,30 | pilares con framework_status in-effect o partial / 10 × 100 |
| Actualidad | 0,25 | pilares con instrumento promulgado en los últimos 6 años / 10 × 100 |
Dos invariantes de honestidad protegen el índice: (1) un instrumento sin URL oficial debe ir marcado synthetic: true: el precálculo descarta cualquier registro que viole esta regla: y (2) el rollup por celda país×pilar que alimenta el ICR filtra synthetic !== true antes de contar, así que ningún registro de demo mueve el puntaje. Cada fila por país publica sus insumos completos (amplitud, vigencia, actualidad, covered_pillars, inforce_pillars, recent_pillars, total_instruments, gaps, rank), el puntaje se puede recomputar a mano. El ranking ordena por ICR con desempate por pilares cubiertos; en el corte actual Brasil encabeza con ICR 95 (10/10 pilares cubiertos; actualidad verificada 80/100, no 100: los proyectos de ley sintéticos no cuentan). El puntaje no premia volumen bruto: 289 instrumentos y 30 dan el mismo ICR si cubren los mismos pilares con la misma vigencia verificada.
Gobernanza de IA
/gobernanza/ia: ¿quién regula la IA en cada país de LATAM, hoy? El mapa por país para los 25: ley de datos, estrategia nacional de IA, marco específico de IA, sandbox regulatorio y autoridad designada. Es quizá la superficie más alineada con la tesis del pilar: regular la IA desde los marcos propios de la región, no desde plantillas importadas.
Procesos constitucionales
/gobernanza/constitucional: el rastreador de procesos constitucionales de la región: los dos intentos constituyentes de Chile, la reforma judicial de México, el debate constituyente en Colombia. Las constituciones se reescriben mientras nadie mira; esta superficie mira.
Oracle: lectura anticipada de proyectos de ley
/gobernanza/oracle: el rastreador de proyectos de ley por país: cada proyecto se resume, se cruza con los 10 ejes Futuros y se marca con una bandera de riesgo, conflicto, oportunidad o vigilancia. Es demo: la propia página lo marca, y la mayoría de los proyectos son escenarios sintéticos sin patrocinador real. La superficie muestra el formato de lectura anticipada, no un feed legislativo en vivo.
Elecciones
/gobernanza/elecciones: el monitoreo electoral de la región: calendario, resultados de elecciones concluidas con porcentajes de votación y señales, con fuentes por evento. Sirve a instituciones y observadores que necesitan un panorama comparable entre países sin renunciar a la trazabilidad de cada cifra. La capa ADM1 añade el comparecimiento electoral del TSE por UF (Brasil) y la participación de la contratación directa SECOP II por departamento (Colombia), cada celda con deep link al registro. El calendario también existe como superficie propia en /calendario: más de 130 eventos regionales y electorales en los 25 países más la categoría regional.
Transparencia
/gobernanza/transparencia: el registro de IA que Futuros propone que los estados adopten, mostrado con datos de demostración: registros de ejecuciones de modelos, prompts y corridas de agentes, en el formato que un registro público de IA exigiría. La propia página lo advierte: los datos son ilustrativos y todavía no están conectados a telemetría real. La superficie existe para publicar el formato antes de pedir su adopción (predicar con el ejemplo) no para reportar indicadores institucionales.
Sala de situación
/sala: la sala de situación: un agregador personalizado que reúne, por capa (inestabilidad, movimientos de indicadores, anomalías, contradicciones, pronósticos, elecciones, atención), la señal más severa del momento, todo con un contrato de integridad de citas, de modo que cada alerta es auditable. Es la inteligencia situacional del pilar: no "el sistema dice que hay riesgo", sino "esta cifra, de esta fuente, movió esta cantidad, y aquí está el registro".
Consenso
/consenso: deliberación al estilo Pol.is: cada persona con cuenta responde 12 afirmaciones (acuerdo, desacuerdo, paso) y el sistema agrupa todas las respuestas en grupos de opinión (k-means). Desde octubre de 2026 las respuestas son identificadas: una por cuenta, como filas de civic_action servidas por /api/civic, y se suman a una línea de base anónima congelada anterior a esa fecha (/api/consensus, almacén Redis de Upstash, ahora de solo lectura: su POST responde 410). La página declara el origen en pantalla ("incluye respuestas anónimas anteriores a octubre de 2026"). Una condición operativa que conviene decir sin rodeos: la línea de base solo aparece si las variables de entorno de Upstash Redis están configuradas en producción; sin ellas el agregado usa solo las respuestas con cuenta. Los dos ejes son tensiones de política fijadas editorialmente (soberanía ↔ integración global y estado ↔ mercado) no emergen del clustering como en Pol.is real. Es el canal por el que la sociedad civil entra al pilar de gobernanza, no como dato observado, sino como voz deliberativa.
Mecánica del agregado
La respuesta de una persona es un vector de 12 caracteres a|d|p (acuerdo/desacuerdo/paso), uno por afirmación, validado por regex en el servidor y guardado como una fila civic_action de tipo consensus sobre el objetivo consenso:latam-2035; un índice único parcial en la base de datos impone una sola respuesta vigente por persona (volver a responder la actualiza; "Reiniciar" la retira con revoked_at). La línea de base es un único HASH de Redis (consensus:v1; la versión de la clave se rota si cambia el set de afirmaciones) que ya nadie escribe: se lee acotada a 20.000 vectores y los vectores identificados a 5.000 por lectura. La respuesta de /api/consensus distingue dos modos de fallo (configured: false (sin Redis) y degraded: true (Redis presente, llamada fallida)); en ambos el agregado se calcula solo con las respuestas con cuenta.
El clustering corre enteramente en el cliente: cada vector se proyecta a los 2 ejes (cada eje suma 6 afirmaciones con signo ±1; los "paso" no cuentan; el puntaje es la media de voto×signo) y sobre esos puntos 2D corre un k-means con k=3, semillas deterministas (puntos ordenados por x y luego y, sin RNG, el mismo conjunto de votos produce siempre los mismos grupos) y máximo 20 iteraciones; requiere ≥ 3 vectores para activarse. Sobre los grupos se clasifican las afirmaciones (solo las con ≥ 2 votos no-paso): consenso = dispersión de la tasa de acuerdo entre grupos ≤ 0,34 y extremidad general ≥ 15 puntos; divisivas = las 3 de mayor dispersión entre grupos.
Propuestas
/gobernanza/propuestas: propuestas de política redactadas por IA (modelos Opus 4.7, con prompts públicos): cada una lleva la posición de Futuros, la contra-posición en su versión más fuerte (steel-man) y la consulta con cuenta: una posición por persona (apoyo, reserva, oposición; se puede retirar), enmiendas y comentarios publicados con el nombre visible de la cuenta (ver Participación identificada). Es una consulta, no un voto institucional: la propia página lo dice. La superficie existe para mostrar el formato de deliberación asistida por IA y recoger posiciones identificadas, no para sustituir una decisión de una institución.
Prioridades
/prioridades: el índice según sus prioridades: el visitante fija sus propios pesos sobre los 10 pilares y ve recalcularse el ranking regional en vivo (la mecánica del Better Life Index de la OCDE) con los pesos compartibles por URL (?w=). No hay un único ranking verdadero: la superficie hace explícito que todo índice compuesto depende de sus pesos. Todo el cálculo corre en el cliente sobre la caché de puntajes en memoria, sin archivos de datos ni API.
Foresight: tablero de calibración
/foresight es el tablero de pronósticos con calibración pública: cada pronóstico lleva probabilidad, horizonte y criterio de falsación, y el tablero agrupa los resueltos en bins de calibración para mostrar si un "70%" de la plataforma ocurre de verdad cerca del 70% de las veces. La página separa con honestidad dos poblaciones. La primera es un archivo semilla de predicciones marcadas illustrative: ejemplos de metodología redactados retroactivamente, con insignia propia en cada tarjeta, que no cuentan como historial real. La segunda son los 13 pronósticos generados por el pipeline de pulso social: mecanismo en vivo, datos desactualizados, el único lote data del 6 de mayo de 2026 y ningún pronóstico vencido ha sido adjudicado todavía. El historial de pronóstico demostrado está por construirse; el formato y la mecánica de calibración ya están publicados.
Registro de correcciones
El registro público de correcciones, falsifications.json, es el compromiso de la plataforma de documentar cada cifra que publicó y luego corrigió: cada entrada exige el citation_id de una afirmación realmente publicada, el valor anterior, el valor corregido, la fecha, la razón y el enlace a la fuente corregida. El mecanismo está en vivo y se muestra en /confianza y /linaje. Su estado actual se declara sin maquillaje: cero entradas desde la purga del 23 de julio de 2026, cuando se eliminaron dos entradas ilustrativas de demo que describían correcciones que nunca ocurrieron, contra citation_id que nunca existieron. El registro parte vacío y solo acumula correcciones reales y verificables: un registro vacío y honesto vale más que uno lleno de ficciones.
API y feeds institucionales
El Motor de Gobernanza no termina en tableros: publica sus datos en formatos que una institución puede consumir directamente, sin scraping y sin pedir permiso.
- API pública v1. Todo el corpus precalculado se sirve estático bajo
/api/v1: observaciones en JSON y CSV, un export SDMX-CSV (ISO 17369,observations.sdmx.csv) para oficinas de estadística, y un libro XLSX (futuros-data.xlsx) con las citas incluidas. Referencia completa en la guía de la API pública. - Servidor MCP. El endpoint
api/mcp.ts(POST https://futuros.xyz/api/mcp) expone el corpus citado como herramientas del Model Context Protocol: un agente de IA institucional puede consultar indicadores, citas y geografías desde Claude, Cursor o cualquier cliente MCP. Guía en el capítulo MCP. - Embeds. Los gráficos citados pueden incrustarse en el sitio de un ministerio o un medio vía iframe, conservando sus citas. Guía en embeds y marca blanca.
Por qué "cada alerta auditable" no es negociable
La diferencia entre un observatorio democrático confiable y otro que no lo es está en si un actor institucional puede defender lo que la plataforma le dice. Un regulador que actúa sobre una alerta necesita poder mostrar la cadena: qué cifra, de qué fuente, medida cuándo. Por eso el pilar hereda el contrato de trazabilidad en dos clics de toda la plataforma: y por eso la sala de situación lleva un contrato explícito de integridad de citas. Una alerta sin fuente es ruido; una alerta auditable es acción defendible.
Pilotos de punta a punta: hoja de ruta
ROADMAP, no realidad operativa. El corpus de pilotos de Futuros contiene 67 propuestas diseñadas (conteo de /data/pilots/_index.json al 2026-08-13; la cifra viva es la que muestra /pilotos) con criterio de bancabilidad: problema, diseño, costeo, financiamiento y KPIs, muchas con ministros nombrados como contraparte potencial. Ninguna corre hoy operativamente con una institución: cero pilotos en ejecución. La distinción importa, porque el Motor de Gobernanza completo (indicador → decisión → intervención → medición) solo quedará demostrado cuando el primer piloto corra de punta a punta con un socio institucional real. Hasta entonces, los pilotos son diseños listos para negociar, y esta sección se declara como hoja de ruta.
Compras públicas de Chile, agregadas
ChileCompra publica cada mes el universo de órdenes de compra como un ZIP keyless. Futuros pliega ese archivo a totales nacionales (conteo, miles de millones de pesos, participación del trato directo, de Compra Ágil y del convenio marco) y no guarda proveedor, comprador ni ítem. Es la vía abierta que reemplaza el ticket de Mercado Público para el histórico. El feed está registrado en la capa de alta frecuencia y no se publica en la interfaz hasta que exista un consumidor. La ventana de refresco son los tres meses completos más recientes.
En paralelo, la API de Mercado Público aporta conteos diarios por estado de ciclo de vida (licitaciones y órdenes con evento ese día). Solo se guardan agregados; ni RUT, ni montos, ni códigos de expediente. Ese feed complementa el ZIP mensual: uno mide flujo diario, el otro el valor mensual. Ambos siguen sin publicarse en la interfaz.
Participación identificada
Desde octubre de 2026 la capa de participación del pilar (posiciones y enmiendas sobre /gobernanza/propuestas, comentarios, respuestas en /consenso y votos a pilotos propuestos) se registra con cuenta. Cada acto es una fila de civic_action con el identificador de la persona, el tipo (vote, amendment, consensus, comment, qvote), el objetivo y la fecha; donde la superficie admite una sola posición por persona, la base de datos lo impone con una restricción de unicidad. Lo que eso cambia, en concreto:
| Antes (demo, por navegador) | Ahora (con cuenta) |
|---|---|
Las posiciones y enmiendas vivían en localStorage; un mismo visitante contaba varias veces desde varios navegadores y nada se agregaba entre personas. | Una posición por persona y propuesta; los conteos que muestra la página son los de toda la comunidad registrada. |
| Comentarios tras una compuerta de correo simulada. | Comentarios publicados con el nombre visible de la cuenta; la persona autora puede editarlos o retirarlos (revoked_at), y lo retirado deja de contar. |
| Respuestas de consenso anónimas, identificadas por un id aleatorio del navegador. | Respuestas atadas a la cuenta. El agregado que muestra /consenso suma las respuestas identificadas más la línea de base anónima congelada anterior a octubre de 2026, y lo declara en pantalla: "incluye respuestas anónimas anteriores a octubre de 2026". Esa línea de base no se atribuye retroactivamente ni crece. |
Lo que no cambia: ninguna cifra cívica publica el correo de nadie; el nombre visible lo define cada persona en /cuenta; una persona que elimina su cuenta deja de contar en todos los agregados a los siete días (ver el aviso de privacidad, §9). El objetivo es el mismo que el del resto del pilar: que un regulador pueda defender el número, incluido el de cuántas personas apoyan una propuesta.
El retorno al ciclo
Las instituciones que llegan a depender de estos observatorios y de la sala de situación se vuelven contribuyentes: aportan sus propios datos al fideicomiso, cerrando el bucle 3 → 1. El observatorio no es un punto final, es un imán de datos que alimenta la siguiente vuelta del volante.
Superficies relacionadas
- Hub de gobernanza: /governance: punto de entrada a todo el pilar.
- /gobernanza/observatorio, /gobernanza/regulacion, /gobernanza/ia, /gobernanza/constitucional, /gobernanza/oracle, /gobernanza/elecciones, /gobernanza/transparencia, /gobernanza/propuestas.
- /sala, /calendario, /consenso, /prioridades.
- Verificabilidad y feeds: /foresight, /confianza, /linaje, API pública, MCP, embeds.
Sigue el ciclo hacia el Pilar 1 — Fideicomiso de Datos: más instituciones que confían en la evidencia vuelven a contribuir al corpus.