🏛️ Politics — Dashboard Legislativo
DatosVerExportarAyuda
Congreso Nacional de Chile
Dashboard Legislativo
Datos historicos desde 1990. Selecciona una camara para explorar.
Datos de fuente abierta · camara.cl · senado.cl
◆ Resumen
Avisos de calidad
Cargando analytics…
NombrePartidoRegión % Asist.Interv.
Seleccione un período.
NºFechaTipoTema principal PresidenteAsist.
Seleccione un período.
Acuerdos de Sala
¿Para qué sirve?
Sirve para expresar la posición de la Sala sobre una materia determinada o impulsar una solicitud que no requiere una ley.
Cargando proyectos…
Comisiones vigentes
Selecciona una comisión para revisar su integración, sesiones y documentos asociados.
Selecciona una comisión
Sobre este proyecto
Cobertura por período
Votaciones
Marcadores de sesión
Limitaciones
Notas técnicas
36
años de historial
10
períodos legislativos
+630
diputados históricos
+4.4k
sesiones registradas
+110k
votos individuales
+500
proyectos de ley

Dashboard de acceso público a los datos históricos de la Cámara de Diputadas y Diputados de Chile. Centraliza asistencia individual, intervenciones en sala, votaciones detalladas, tramitación legislativa y análisis de sentimiento desde 1990 hasta hoy. Todo el flujo —desde la descarga hasta la visualización— es automatizado y reproducible.

Pipeline de datos — end to end
1
Tres fuentes de datos — tres formatos distintos Fuente
Los datos provienen de tres fuentes independientes, cada una con su propio protocolo y formato:

① opendata.camara.cl (SOAP/XML + HTTP GET) — API web service del Web Service oficial de la Cámara (.asmx). Entrega legislaturas, períodos, diputados, sesiones y sus metadatos, votaciones en sala, comisiones y el boletín XML completo de cada sesión plenaria. El boletín es un XML semi-estructurado que contiene la asistencia nominal, el orden del día, intervenciones y votaciones. No requiere autenticación.

② camara.cl (HTML / ASP.NET scraping) — La capa web complementa a la API en varios frentes: directorio y actividad de diputados, sesiones y votaciones de sala y los listados completos de proyectos de acuerdo, resolución y ley. Todo esto se obtiene parseando páginas ASP.NET con BeautifulSoup, simulando la paginación mediante __doPostBack y resolviendo formularios/ViewState en cada request.

③ tramitacion.senado.cl/wspublico (XML API) — API pública del Senado que entrega la lista de senadores vigentes y los proyectos de ley en tramitación con una ventana de días configurable. Respuesta en XML plano parseado con xml.etree.ElementTree.
Formatos: XML boletín (sesiones) JSON/XML API HTML ASP.NET (proyectos) XML Senado PDF OCR (P1/P2)
2
Scraping automático — tres scripts, cron diario 06:00 Ingesta
Un cron job diario (06:00 hrs) ejecuta los scrapers de la Cámara y del Senado en secuencia:

scrape_camara.py — consulta la API SOAP/XML de la Cámara descargando en modo incremental: nuevas sesiones del período activo, diputados del período actual, votaciones y el XML completo del boletín de cada sesión nueva. Organizado en 9 capas (A–I) por dependencia: catálogos → listados → detalles → votaciones → comisiones.

scrape_camara_web.py — recorre camara.cl para complementar el directorio de diputados, actividad legislativa individual, sesiones y votaciones de sala con detalle nominal cuando la web lo publica, además de otras tablas raw usadas como backfill.

scrape_proyectos.py — parsea las páginas HTML de camara.cl (proyectos de acuerdo, resolución y ley), simulando la paginación ASP.NET con __doPostBack. Se detiene automáticamente cuando todos los proyectos de una página ya existen en BD.

scrape_senado.py — consume la API XML del Senado obteniendo senadores vigentes y proyectos con una ventana configurable de días (variable SENADO_FETCH_DAYS).
Escribe en: sesiones_detalle votaciones_boletin raw_diputados_web raw_sala_votaciones proyectos_ley_api raw_proyectos raw_senado_*
3
Almacenamiento raw — arquitectura del sitio y base legislativa Ingesta
La capa legislativa se construye con dos fuentes complementarias de la Cámara: la API/opendata oficial y el sitio web camara.cl. Todo eso se consolida en camara_diputados, que actúa como fuente de verdad de esta aplicación. Dentro de esa base, los datos crudos se guardan según origen:

API Cámara: catalogos y listados almacenan las respuestas JSON/XML como jsonb. La columna sesiones_detalle.boletin_xml guarda el XML íntegro de cada sesión (texto, sin parsear) para permitir re-procesamiento. Los períodos 1 y 2, que no tienen boletín XML publicado, cuentan con una columna adicional boletin_pdf_texto con el texto extraído por OCR.

Scraping HTML: raw_proyectos almacena proyectos de acuerdo, resolución y ley extraídos del sitio web como jsonb, indexados por id_proyecto y tipo.

API Senado: raw_senado_senadores y raw_senado_proyectos guardan las respuestas XML del Senado también como jsonb.
Tablas raw: sesiones_detalle catalogos / listados raw_proyectos raw_senado_senadores raw_senado_proyectos votaciones_boletin
4
Normalización — cuatro estrategias según formato de origen Proceso
normalize_congreso_data.py aplica una estrategia distinta según el formato del boletín disponible para cada período:

P1–P2 (1990–1998) — PDF con OCR: los boletines de estos períodos solo están disponibles como PDFs escaneados. El texto extraído por OCR se parsea con expresiones regulares en modo dotall para identificar la sección de asistencia y el nombre de cada diputado. Al no haber IDs numéricos ni formato estructurado, se aplica fuzzy matching sobre el texto libre (NFKD + thefuzz) para asociar cada nombre al id_diputado correcto.

P3–P8 (1998–2018) — XML sin IDs: el XML de estos períodos incluye asistencia y secciones estructuradas, pero los nodos de diputado no tienen atributo ID numérico — solo nombre y partido en texto. Se usa fuzzy matching contra el catálogo de diputados del período para resolver la identidad.

P9–P58 (2018–presente) — XML con IDs: el formato moderno incluye el atributo DIPUTADOValue con el ID numérico directamente, permitiendo un join exacto y determinista sin fuzzy matching.

En todos los casos el XML del boletín es semi-estructurado (contiene entidades HTML, <br> y markup mixto) y se parsea con regex en dotall mode, no con un parser XML estándar.
Produce: norm_sesion_asistencia norm_boletin_intervenciones norm_boletin_secciones norm_boletin_metadata
5
Análisis de sentimiento — RoBERTa + Ollama Proceso
Se usan dos modelos distintos según el nivel de granularidad:

pysentimiento / RoBERTa — clasifica cada intervención individual como positiva, neutra o negativa con un score de confianza. Opera a nivel de diputado y sesión: cada texto extraído del XML (atributo DIPUTADOValue) pasa por este modelo y los resultados se agregan por diputado y por sesión. Es determinista y reproducible.

Ollama / llama3.2 — genera el análisis cualitativo a nivel de período completo: el resumen de clima político, las tensiones identificadas y la clasificación de tono general (propositivo, confrontacional, etc.). Recibe como input los datos agregados del período y produce texto interpretativo. Corre localmente, sin envío de datos a servidores externos.
Produce: sentimiento_diputado sentimiento_sesion análisis_periodo (Ollama)
6
Analytics precomputados — métricas agregadas + normalización de coaliciones Proceso
compute_analytics.py genera tablas de métricas ya calculadas que el dashboard consume directamente:

analytics_diputado_periodo — asistencia %, intervenciones y rankings por diputado y período.
analytics_partido_periodo — comparativas por bloque con normalización de coaliciones: en el Período 10 (2022–2026), los partidos RD, Convergencia Social y Comunes se agrupan como Frente Amplio (FA), reflejando la fusión formal de 2023. En períodos anteriores (P9) se mantiene RD como partido independiente.
analytics_sesion — resumen por sesión incluyendo partido_dominante: el partido con más intervenciones en esa sesión, también con normalización de coalición FA aplicada.

Esto permite que todas las vistas carguen instantáneamente — sin cálculos en tiempo de consulta.
Produce: analytics_diputado_periodo analytics_partido_periodo analytics_sesion (+ partido_dominante)
Cómo acceder a los datos — guía para desarrolladores
1
Acceder al portal de datos abiertos
Visita opendata.camara.cl. El portal es completamente público: no se requiere registro, autenticación ni API key. Está disponible para uso libre bajo la política de datos abiertos del Estado de Chile.
2
Explorar los recursos disponibles
El portal expone recursos en formato JSON y XML organizados por categoría: Diputados (catálogo por período, militancias, comisiones), Sesiones (metadatos y boletines), Proyectos (tramitación legislativa) y Votaciones. Cada recurso está documentado con sus parámetros de filtrado disponibles (período, fecha, ID).
3
Obtener la lista de sesiones de un período
Consulta el endpoint de sesiones filtrando por número de legislatura o período. La respuesta incluye metadatos de cada sesión: número, fecha, tipo (ordinaria / extraordinaria / especial) y si el boletín XML ya fue publicado. Cada sesión devuelve un id_sesion único necesario para los pasos siguientes.
4
Descargar el boletín XML de una sesión
Usando el id_sesion, solicita el boletín en formato XML. Este documento contiene: la asistencia nominal de todos los diputados (con código de asistencia: Presente, Justificado, Ausente, etc.), el orden del día con los temas y proyectos tratados, y el texto de las intervenciones en sala. No todas las sesiones tienen boletín publicado — ver la pestaña Cobertura.
5
Entender la estructura del XML (y sus límites)
El XML no es XML estándar: contiene entidades HTML no escapadas (&amp;, &nbsp;), tags <br> sin cerrar y markup mixto. No lo proceses con un parser XML convencional — usa regex en modo dotall. La estructura varía por período: <SESION> contiene <ASISTENCIA> (diputados con atributos de nombre, partido, código de asistencia) e <INTERVENCIONES> (discursos anotados con DIPUTADOValue en P9+). El atributo VALID="False" en el nodo raíz indica sesión fracasada por falta de quórum.
6
Resolver identidad según el período histórico
P1–P2 (1990–1998): solo disponibles en PDF escaneado. Extrae texto con OCR, luego aplica fuzzy matching contra el catálogo del período usando thefuzz + normalización NFKD Unicode.
P3–P8 (1998–2018): XML disponible, pero los nodos de diputado no tienen ID numérico — solo nombre en texto libre. Aplica el mismo fuzzy matching ajustando el umbral según el período y los apellidos compuestos comunes en Chile.
P9–P58 (2018–presente): el atributo DIPUTADOValue contiene el ID numérico directamente, permitiendo un join exacto sin heurísticas.

Disponibilidad de boletines XML (actas oficiales) por período legislativo. Sin boletín no hay datos de asistencia, temas ni intervenciones.

Cargando…

Diagnóstico de cobertura real de votaciones. Esta pestaña distingue entre límites del frontend y límites estructurales de las fuentes históricas.

Período
Años
Detalle por diputado
Tema de la votación
P3
1998–2002
No disponible0 / 2
Sin votos nominales recuperables en la base actual.
Muy débil0%
2 de 2 votaciones siguen con tema genérico.
P4
2002–2006
No disponible0 / 2508
La fuente almacenada solo conserva resultados agregados.
Muy débil3.5%
2421 de 2508 votaciones siguen sin tema legible.
P5
2006–2010
No disponible0 / 3001
No hay capa nominal utilizable en la extracción histórica cargada.
Muy débil8.2%
2756 de 3001 sin tema legible después de fallbacks.
P6
2010–2014
No disponible0 / 4475
No se puede mostrar voto por diputado con la base actual.
Muy débil4.7%
4264 de 4475 permanecen con texto genérico.
P8
2014–2018
Parcial604 / 4466
Hay detalle nominal en parte del período, no en toda la serie.
Parcial40.7%
1817 de 4466 ya muestran un tema legible.
P9
2018–2022
Parcial311 / 5331
Cobertura nominal baja, pero existente.
Parcial41.6%
2218 de 5331 ya muestran un tema legible.
P10
2022–2026
Parcial1065 / 6480
La fuente web nominal mejora cobertura, pero no completa la serie.
Parcial54.7%
3544 de 6480 ya muestran un tema legible.
P58
2026–2030
Completo72 / 72
Cobertura nominal completa en la legislatura actual.
Legible100%
No quedan títulos genéricos residuales en el período actual.
Dos fuentes complementarias para la capa de votaciones
La visualización de votaciones combina dos fuentes de la Cámara. La primera es la API/opendata oficial, que entrega cobertura histórica amplia pero normalmente solo con totales agregados y una descripción breve. La segunda es el sitio web camara.cl, desde donde se scrapean listados y detalles nominales cuando están publicados. El pipeline normaliza ambas en norm_votaciones y norm_votacion_votos.
P3–P6: no hay voto nominal recuperable con la base actual
En P3 (1998–2002), P4 (2002–2006), P5 (2006–2010) y P6 (2010–2014) la cobertura nominal es 0: las votaciones históricas cargadas en la base solo conservan resultado agregado. En estos períodos la app no puede mostrar qué votó cada diputado sin construir una extracción histórica nueva desde otra fuente.
P8–P10: cobertura nominal parcial
Desde P8 en adelante sí aparecen votos nominales, pero de forma incompleta. Cobertura medida en la base publicada: P8 604/4466, P9 311/5331 y P10 1065/6480. En esos períodos la app muestra el detalle por diputado cuando existe; cuando no, solo puede presentar el resultado agregado de la votación.
P58: cobertura nominal completa
En la legislatura actual P58 la fuente web nominal está disponible y la cobertura en la base es completa: 72 de 72 votaciones con detalle por diputado. Por eso la pestaña de votaciones de sesiones y diputados funciona completa en este período.
Temas de votación: muchos casos históricos siguen siendo genéricos
El título visible de una votación intenta resolverse con tres niveles: descripción de la votación, título del proyecto y descripción de tramitación. Aun así, en muchos casos históricos la fuente solo publica textos como Boletín N° 4970-04 o Proyecto de Acuerdo N°. Tras aplicar todos los fallbacks, siguen sin tema legible P4 2421/2508, P5 2756/3001, P6 4264/4475, P8 2649/4466, P9 3113/5331 y P10 2936/6480.
Qué se puede resolver y qué no
Sí se puede mejorar donde exista una fuente adicional para backfill de títulos o detalle nominal. No se puede inventar el voto individual en períodos donde la fuente almacenada solo conserva totales agregados. Cuando falte detalle, el límite es del pipeline de extracción histórica y no de la interfaz.

Cada sesión en la tabla puede mostrar uno de estos iconos indicando una situación especial. Haz clic sobre el icono directamente en la tabla para ver el detalle completo de esa sesión.

⚠
Acta no disponible
La Cámara no ha publicado el boletín para esta sesión. La asistencia registrada es 0 y no refleja datos reales. Más frecuente en el Período 1 (1990–1994, ~17% de sesiones) y Período 2 (1994–1998, ~5%). Esporádico en períodos posteriores.
✕
Sin quórum reglamentario
La sesión fue declarada oficialmente nula al no alcanzar el mínimo de diputados presentes. El acta XML registra VALID="False". Los asistentes mostrados son los que se presentaron, pero insuficientes para constituir quórum.
§
Solo Cuenta parlamentaria
El acta existe y está procesada, pero la sesión estuvo compuesta únicamente por la lectura de la Cuenta (comunicaciones al pleno). No hubo debate legislativo ni orden del día con proyectos identificables. No es un error de datos.
ℹ
Sin tema registrado
El acta fue publicada y procesada, pero el tema de la sesión no pudo determinarse de ninguna de las fuentes disponibles (etiqueta XML <OBJETO_SESION>, sección "V. TABLA" del boletín, ni el texto PDF de la sesión). Ocurre en sesiones secretas, sesiones de instalación de período y algunas actas históricas muy breves de P1/P2.

Restricciones de origen en los datos fuente que afectan la completitud o comparabilidad de ciertas métricas.

Períodos 1 y 2 (1990–1998) — Boletines PDF, sin partido ni región
Los boletines de estos períodos no tienen versión XML publicada: solo existen como PDFs escaneados. El texto se extrae por OCR y la asistencia se reconstruye con fuzzy matching de nombres. Cobertura: P1 ~83% de sesiones (358/429), P2 ~95% (413/434). Ninguno registra partido, región ni distrito — la sección de asistencia del PDF era texto libre sin esa información. Los datos son comparables con reservas — ver marcadores ⚠/ℹ en la vista de sesiones.
Región y distrito faltantes en Períodos 9 y 10 (2018–2026)
El formato XML de las actas cambió en el Período 9 (2018–2022): la sección de Asistencia dejó de incluir región y distrito. Ningún diputado de P9 o P10 tiene datos geográficos disponibles directamente desde las actas. Solo un porcentaje menor tiene región derivada de mandatos anteriores en períodos con datos. La API de la Cámara tampoco expone este campo para estos períodos.
Asistencia reducida en Período 9 (2020–2022) por COVID-19
Las sesiones de 2020–2022 muestran asistencia reducida real (promedio 67–90 diputados) por las modalidades remotas e híbridas adoptadas durante la pandemia. No es un error de datos: refleja el funcionamiento real del Congreso en ese período. Todas las 568 sesiones de P9 tienen boletín publicado (100%).
Período 10 (2022–2026) — Cobertura completa, partidos normalizados
El período 10 finalizó en marzo 2026 con cobertura prácticamente total: 542 de 543 sesiones con boletín (99.8%). Los partidos RD, Convergencia Social y Comunes fueron agrupados como Frente Amplio (FA) en las métricas agregadas, reflejando la fusión formal de 2023. Región y distrito no disponibles para este período.
Período 2026–2030 (P58) — En curso, boletines parciales
La legislatura actual comenzó el 11/03/2026. Se registran 17 sesiones; 11 tienen boletín publicado y 6 aún no. Los datos se actualizan automáticamente cada mañana con las publicaciones de la Cámara.
Proyectos, acuerdos y resoluciones — cobertura desde 2018 en adelante
La pestaña Proyectos solo aparece desde P9 (2018–2022) porque la fuente que permite enlazar acuerdos y resoluciones a una sesión concreta y a su documento pertenece al archivo moderno de camara.cl. En los períodos anteriores la Cámara no publica esa estructura de forma consistente, por lo que no existe una base confiable para reconstruir tarjetas comparables período a período.

Decisiones de implementación y procesamiento que pueden afectar la interpretación de los datos.

Arquitectura
Dos fuentes complementarias dentro de la capa legislativa
La app del Congreso integra dos fuentes de la Cámara: la API/opendata oficial y el sitio camara.cl. Ambas se consolidan en la base camara_diputados, que es la única fuente consultada por esta interfaz para sesiones, proyectos, votaciones y analytics.
Formatos de origen
Cuatro formatos de entrada, un pipeline unificado
Los datos de entrada llegan en cuatro formatos distintos que el pipeline maneja de forma independiente: (1) XML semi-estructurado (boletines de sala P3–P58) — parseado con regex en modo dotall por no ser XML válido. (2) Texto OCR de PDF (boletines P1–P2) — texto plano extraído de PDFs escaneados, con ruido de OCR. (3) HTML/ASP.NET (proyectos camara.cl) — scraping con BeautifulSoup simulando navegación de formularios. (4) XML estándar (API del Senado tramitacion.senado.cl) — XML bien formado parseado con xml.etree.ElementTree.
Intervenciones
Texto extraído en tiempo real desde el XML
El texto de las intervenciones no está almacenado en la base de datos: se extrae en tiempo real desde el XML del boletín cuando se solicita. Las sesiones sin boletín publicado, o cuyo XML no contenga intervenciones atribuidas al diputado (períodos P1–P2), mostrarán el mensaje correspondiente al intentar verlas.
Partidos
Normalización de siglas + fusiones de coalición
Los nombres de partidos han sido normalizados a sus siglas oficiales según SERVEL y BCN. Variantes frecuentes unificadas: DC → PDC, EVOPOLI → EVOP, PRD → RD, PCS → CS. Errores de parseo (ej. "Abel PRSD") corregidos manualmente.
Adicionalmente, en el Período 10 (2022–2026) los partidos RD, Convergencia Social (CS) y Comunes se agrupan como Frente Amplio (FA) en todas las métricas agregadas, reflejando la fusión formal de octubre 2023. El agrupamiento no afecta los datos históricos del diputado individual.
Proyectos y Senadores
Proyectos: tres tipos, dos fuentes
Los proyectos de ley, acuerdo y resolución provienen de dos fuentes complementarias: scraping HTML de camara.cl (listados paginados por tipo, actualizados diariamente) y los boletines de sala para reforzar el enlace con votaciones y sesiones. La API oficial de la Cámara no expone listados completos de proyectos, y el archivo HTML moderno con documentos/sesiones solo es consistente desde 2018 en adelante; por eso la pestaña se limita a P9, P10 y P58. Los senadores son exclusivamente del período en curso (API del Senado, ventana diaria).
Sentimiento — RoBERTa
pysentimiento — análisis por diputado y sesión
El análisis a nivel de diputado individual y sesión usa pysentimiento, un modelo RoBERTa fine-tuned en texto en español de redes sociales y prensa. Cada fragmento de intervención extraído del XML es clasificado como positivo, neutro o negativo; los scores se promedian para el perfil del diputado o sesión. Es determinista: mismo texto, mismo resultado. Puede cometer errores en lenguaje técnico-legislativo e ironía.
Sentimiento — Ollama
llama3.2 — análisis cualitativo por período
El análisis a nivel de período completo (tono general, clima político, tensiones, logros) es generado por Ollama con llama3.2, un LLM que corre localmente — sin envío de datos a servidores externos. Recibe los datos agregados del período como contexto y produce texto interpretativo. Al ser generativo puede variar entre ejecuciones y contener imprecisiones; siempre se muestra con advertencia explícita.
Sincronización
Pipeline diario automático — 06:00 hrs
El pipeline completo se ejecuta cada mañana a las 06:00 mediante un agente launchd en macOS: scraping incremental de la Cámara (solo sesiones/boletines nuevos), scraping de proyectos (HTML paginado), fetch de senadores, normalización de todos los datos nuevos y recomputo de métricas analytics. Los boletines XML se almacenan íntegramente para reprocesamiento sin necesidad de re-scrapear la fuente.
Código
Repositorio público en GitHub
El pipeline de scraping, normalización y análisis es de código abierto: github.com/jahadd/Analisis_congreso_Chile